Praktik terbaik untuk memitigasi token OAuth yang disusupi untuk Google Cloud CLI

Last reviewed 2024-02-15 UTC

Dokumen ini menjelaskan cara memitigasi dampak penyerang yang membahayakan token OAuth yang digunakan oleh gcloud CLI.

Penyerang dapat membahayakan token OAuth ini jika mendapatkan akses ke endpoint yang telah diautentikasi dengan gcloud CLI oleh akun layanan pengguna atau akun layanan yang sah. Penyerang kemudian dapat menyalin token ini ke endpoint lain yang mereka kontrol untuk membuat permintaan yang meniru identitas yang sah. Bahkan setelah Anda menghapus akses penyerang ke endpoint yang disusupi, penyusup dapat terus membuat permintaan API yang terautentikasi menggunakan token yang disalin. Untuk membantu mengurangi risiko ini, Anda dapat mengontrol akses ke sistem Anda menggunakan kredensial yang berumur pendek dan kontekstual.

Dokumen ini ditujukan untuk tim keamanan atau arsitek cloud yang bertanggung jawab untuk mengamankan resource cloud dari akses yang tidak sah. Dokumen ini memperkenalkan kontrol yang tersedia yang dapat Anda gunakan untuk mengurangi dampak dampak token OAuth gcloud CLI yang disusupi dan memperbaiki lingkungan setelah endpoint Anda secara proaktif.

Ringkasan

Untuk memahami cara kerja ancaman ini, Anda harus memahami cara gcloud CLI menyimpan kredensial OAuth 2.0 dan cara kredensial tersebut dapat disalahgunakan jika disusupi oleh penyerang.

Jenis kredensial yang disimpan oleh gcloud CLI

Gcloud CLI menggunakan token akses OAuth 2.0 guna mengautentikasi permintaan untuk Google Cloud API. Alur OAuth bervariasi berdasar jenis kredensial yang digunakan, tetapi umumnya token akses dan kredensial lainnya dapat diakses secara lokal. Dalam setiap kasus, masa berlaku token akses akan berakhir dalam 60 menit, tetapi kredensial jenis lainnya mungkin bersifat tetap.

Saat Anda memberi otorisasi gcloud CLI dengan akun pengguna, gcloud CLI akan memulai alur izin three-legged OAuth untuk mengakses Google Cloud API atas nama pengguna. Setelah pengguna menyelesaikan alur perizinan gcloud CLI menerima token akses dan token refresh yang memungkinkannya meminta token akses baru. Pada setelan default, token refresh yang memiliki masa aktif lama akan tetap ada hingga kondisi habis masa berlakunya.

Saat Anda memberi otorisasi gcloud ke akun layanan, gcloud CLI akan memulai alur two-legged OAuth untuk mengakses Google Cloud API sebagai identitas akun layanan. Setelah Anda mengaktifkan akun layanan dari file kunci pribadi, kunci ini digunakan untuk meminta token akses secara berkala. Kunci pribadi yang tahan lama disimpan di konfigurasi gcloud CLI dan akan tetap valid hingga Anda menghapus kunci akun layanan.

Saat Anda menjalankan gcloud CLI dalam lingkungan Google Cloud seperti Compute Engine atau Cloud Shell, aplikasi tersebut dapat menemukan kredensial dan melakukan autentikasi sebagai akun layanansecara otomatis. Misalnya, pada Compute Engine, aplikasi seperti gcloud CLI dapat membuat kueri server metadata untuk mendapatkan token akses. Google mengelola dan merotasi kunci penandatanganan pribadi yang digunakan untuk membuat token akses dan kredensial yang memiliki masa berlaku lama. tidak diekspos ke aplikasi.

Saat Anda melakukan autentikasi dengan workload identity federation, aplikasi mengautentikasi berdasarkan kredensial dari penyedia identitas eksternal dan menerima token akses yang memiliki masa berlaku pendek yang digabungkan. Untuk informasi selengkapnya tentang cara menyimpan dan mengelola kredensial yang memiliki masa berlaku panjang yang digunakan oleh penyedia identitas eksternal, lihat praktik terbaik untuk menggunakan workload identity federation.

Cara seorang penyerang dapat menggunakan token OAuth yang telah disusupi

Jika penyerang berhasil menyusupi endpoint, kredensial seperti token OAuth merupakan target berharga karena penyerang dapat mempertahankan atau mengeskalasikan aksesnya.

Developer mungkin memiliki kebutuhan yang sah untuk melihat kredensialnya sendiri saat menulis dan memproses debug kode. Misalnya, developer mungkin perlu melakukan autentikasi untuk menggunakan permintaan REST ke layanan Google Cloud saat menggunakan library klien yang tidak didukung. Developer dapat melihat kredensial melalui berbagai metode, termasuk yang berikut:

Namun, penyerang mungkin menggunakan teknik yang sama dengan ini setelah membobol endpoint.

Jika penyerang membahayakan endpoint, seperti workstation developer, ancaman utamanya adalah penyerang dapat menjalankan perintah gcloud CLI atau kode lain dengan kredensial sah dari identitas yang diautentikasi. Selain itu, penyerang dapat menyalin token OAuth ke endpoint lain yang mereka kontrol untuk mempertahankan aksesnya. Ketika pencurian ini terjadi, terdapat ancaman sekunder bahwa penyerang tetap dapat menggunakan token OAuth yang memiliki masa berlaku panjang untuk memiliki akses persisten bahkan setelah Anda menghapus akses ke endpoint yang disusupi.

Jika penyerang berhasil menyusup ke token OAuth, mereka dapat melakukan tindakan berikut:

  • Penyerang dapat meniru pengguna atau akun layanan yang disusupi. Traffic API yang menggunakan token yang disusupi dicatat ke dalam log seolah-olah berasal dari pengguna atau akun layanan yang disusupi, sehingga sulit membedakan aktivitas normal dan berbahaya dalam log.
  • Penyerang dapat me-refresh token akses tanpa batas waktu menggunakan token refresh persisten yang terkait dengan pengguna atau kunci pribadi yang terkait dengan akun layanan.
  • Penyerang dapat mengabaikan autentikasi dengan sandi atau verifikasi 2 langkah karena token diberikan setelah alur login.

Praktik terbaik untuk mengurangi risiko

Terapkan kontrol yang dijelaskan di bagian berikut untuk membantu mengurangi risiko token gcloud CLI disusupi. Jika Anda mengikuti praktik terbaik keamanan yang dijelaskan dalam blueprint foundation perusahaan atau desain zona landing di Google Cloud, Anda mungkin sudah memiliki kontrol ini.

Menetapkan durasi sesi untuk layanan Google Cloud

Untuk mengurangi waktu penyerang dapat mengeksploitasi token yang disusupi, tetapkan durasi sesi untuk layanan Google Cloud. Secara default, token refresh yang diberikan sistem setelah autentikasi merupakan kredensial yang memiliki masa berlaku panjang dan sesi gcloud SLI yang tidak memerlukan autentikasi ulang. Mengubah setelan ini untuk mengonfigurasi kebijakan autentikasi ulang dengan durasi sesi antara 1 hingga 24 jam. Setelah durasi sesi yang ditentukan, kebijakan autentikasi ulang akan membatalkan validasi token refresh dan memaksa pengguna untuk mengautentikasi ulang gcloud CLI secara teratur dengan sandi atau kunci keamanannya.

Durasi sesi untuk layanan Google Cloud berbeda dari peraturan durasi sesi untuk layanan Google, yang mengontrol sesi web ke sigin layanan Google Workspace, tetapi tidak dapat mengontrol autentikasi ulang untuk Google Cloud. Jika Anda menggunakan layanan Google Workspace, tetapkan durasi sesi untuk keduanya.

Mengonfigurasi Kontrol Layanan VPC

Konfigurasikan Kontrol Layanan VPC di seluruh lingkungan Anda untuk membantu memastikan bahwa hanya traffic Google Cloud API yang berasal dari perimeter yang Anda tentukan yang dapat mengakses resource yang didukung. Perimeter layanan membatasi kegunaan kredensial yang disusupi karena perimeter memblokir permintaan ke layanan yang dibatasi yang berasal dari endpoint yang dikontrol penyerang yang berada di luar lingkungan Anda.

Mengonfigurasi Chrome Enterprise Premium

Konfigurasi kebijakan Chrome Enterprise Premium untuk membantu mengamankan konsol Google Cloud dan Google Cloud API. Konfigurasikan level akses dan binding Chrome Enterprise Premium untuk mengizinkan atribut yang dievaluasi secara selektif pada setiap permintaan API, termasuk akses berbasis IP atau akses berbasis sertifikat untuk TLS bersama. Permintaan yang menggunakan kredensial otorisasi yang disusupi tetapi tidak memenuhi kondisi yang ditentukan dalam kebijakan Chrome Enterprise Premium Anda akan ditolak.

Chrome Enterprise Premium merupakan kontrol yang berpusat pada pengguna dan menolak traffic API yang tidak memenuhi kondisi yang ditentukan. Kontrol Layanan VPC adalah kontrol yang berorientasi pada resource yang menentukan perimeter yang dapat berkomunikasi dengan resource. Kontrol Layanan VPC berlaku untuk semua identitas pengguna dan identitas akun layanan, tetapi Chrome Enterprise Premium hanya berlaku untuk identitas pengguna dalam organisasi Anda. Saat digunakan secara bersamaan, Chrome Enterprise Premium dan Kontrol Layanan VPC mengurangi efektivitas kredensial yang disusupi pada mesin yang dikontrol penyerang dan berada di luar lingkungan Anda.

Memaksakan verifikasi 2 langkah untuk akses server jarak jauh

Jika Anda mengizinkan developer mengakses resource Compute Engine menggunakan SSH konfigurasi Login OS dengan verifikasi 2 langkah. Menerapkan checkpoint tambahan ini, dimana pengguna harus melakukan autentikasi ulang dengan sandi atau kunci keamanan mereka. Penyerang yang memiliki token OAuth yang telah disusupi tetapi tidak memiliki sandi atau kunci keamanan akan diblokir oleh fitur ini.

Akses Protokol Desktop Jarak Jauh (RDP) ke instance Windows di Compute Engine tidak mendukung layanan Login OS, jadi verifikasi 2 langkah tidak dapat diterapkan secara terperinci untuk sesi RDP. Saat menggunakan IAP Desktop atau plugin RDP berbasis Google Chrome, setel kontrol terperinci seperti durasi sesi untuk layanan Google dan verifikasi 2 langkah untuk sesi web pengguna serta nonaktifkan setelan Izinkan pengguna mempercayai perangkat di bagian verifikasi 2 langkah.

Membatasi penggunaan kunci akun layanan

Saat Anda menggunakan kunci akun layanan untuk mengautentikasi, nilai kunci akan disimpan dalam file konfigurasi gcloud CLI, secara terpisah dari file kunci yang didownload. Penyerang yang memiliki akses ke lingkungan Anda, dapat menyalin kunci dari konfigurasi gcloud CLI atau menyalin file kunci dari sistem file lokal Anda atau repositori internal Anda. Oleh karena itu, selain rencana Anda untuk mengurangi token akses yang disusupi, pertimbangkan cara Anda mengelola file kunci akun layanan yang didownload.

Tinjau alternatif yang lebih aman untuk autentikasi untuk mengurangi atau menghapus kasus penggunaan yang bergantung pada kunci akun layanan, dan terapkan batasan kebijakan organisasi iam.disableServiceAccountKeyCreation untuk menonaktifkan pembuatan kunci akun layanan.

Mempertimbangkan prinsip hak istimewa terendah

Saat mendesain kebijakan IAM, pertimbangkan hak istimewa terendah. Berikan peran yang diperlukan pengguna untuk menyelesaikan tugas dalam cakupan terkecil. Jangan memberikan mereka peran yang tidak mereka butuhkan. Tinjau dan terapkan rekomendasi peran untuk menghindari kebijakan IAM dengan peran yang tidak berguna dan berlebihan di lingkungan Anda.

Melindungi endpoint Anda

Pertimbangkan cara penyerang mendapatkan akses fisik atau akses jarak jauh ke endpoint Anda, seperti workstation developer atau instance Compute Engine. Meskipun rencana untuk mengatasi ancaman token OAuth yang disusupi merupakan hal yang utama, tetapi pertimbangkan juga cara merespons ancaman terhadap bagaimana penyerang dapat membobol endpoint terpercaya Anda sejak awal. Penyerang memiliki akses ke endpoint terpercaya Anda, sehingga mereka dapat menjalankan perintah gcloud CLI atau kode lainnya secara langsung di endpoint itu sendiri.

Meskipun perlindungan komprehensif untuk workstation developer berada di luar cakupan dokumen ini, evaluasi bagaimana alat dan operasi keamanan dapat membantu melindungi dan memantau endpoint Anda dari penyusupan. Pertimbangkan pertanyaan berikut:

  • Bagaimana keamanan fisik workstation developer dilindungi?
  • Bagaimana cara Anda mengidentifikasi dan menanggapi pelanggaran jaringan?
  • Bagaimana pengguna mendapatkan akses jarak jauh ke sesi SSH atau RDP?
  • Bagaimana jika kredensial persisten lainnya, seperti kunci SSH atau Kunci akun layanan dapat disusupi?
  • Apakah ada alur kerja yang menggunakan kredensial persisten yang dapat diganti dengan kredensial yang memiliki masa berlaku pendek?
  • Apakah ada perangkat bersama yang dapat digunakan untuk membaca kredensial gcloud CLI di cache pengguna lain?
  • Dapatkah pengguna melakukan autentikasi dengan gcloud CLI dari perangkat yang tidak terpercaya?
  • Bagaimana traffic yang disetujui untuk terhubung ke resource di dalam perimeter Kontrol Layanan VPC Anda?

Pastikan operasi keamanan Anda menjawab setiap pertanyaan berikut.

Menyelaraskan tim respons Anda

Pastikan sebelumnya bahwa tim keamanan yang bertanggung jawab atas respons insiden memiliki akses yang sesuai ke seluruh konsol Google Cloud dan Konsol Admin. Jika konsol Google Cloud dan konsol Admin dikelola oleh tim yang terpisah,respons Anda mungkin tertunda selama insiden.

Untuk menghapus akses dari akun pengguna, tim respons insiden Anda memerlukan peran Konsol Admin, seperti, Admin Pengelolaan Pengguna. Untuk menilai apakah telah terjadi aktivitas yang mencurigakan pada resource Google Cloud Anda, tim ini mungkin juga memerlukan peran IAM, seperti Peninjau Keamanan di semua project atau Log Viewer pada log sink terpusat. Peran yang diperlukan untuk tim keamanan Anda akan bervariasi berdasarkan pada desain dan pengopersian lingkungan Anda.

Praktik terbaik untuk perbaikan setelah terjadi insiden keamanan

Setelah endpoint disusupi, sebagai bagian dari rencana manajemen insiden, tentukan cara merespons ancaman utama dari endpoint yang disusupi dan cara mengurangi potensi kerusakan yang sedang terjadi dari ancaman kedua pada token yang disusupi. Jika penyerang memiliki akses tetap ke workstation developer, mereka dapat menyalin token lagi setelah pengguna yang sah melakukan autentikasi ulang. Jika Anda menduga bahwa token gcloud CLI mungkin disusupi, buka tiket dengan Cloud Customer Care dan selesaikan rekomendasi pada bagian berikut. Tindakan ini dapat membantu membatasi dampak dari peristiwa seperti ini pada organisasi Google Cloud Anda.

Rekomendasi pada bagian ini tumpang tindih dengan panduan umum pada penanganan kredensial Google Cloud yang disusupi, tetapi lebih berfokus pada ancaman token gcloud CLI yang disalin dari endpoint yang disusupi.

Mengakhiri token aktif untuk semua akun pengguna dengan kontrol sesi Google Cloud

Jika Anda belum mengaktifkan kontrol sesi Google Cloud, segera aktifkan kontrol ini dengan frekuensi autentikasi ulang yang singkat. Kontrol ini membantu memastikan masa berlaku semua token refresh yang akan berakhir pada durasi yang Anda tetapkan, yang membatasi durasi penggunaan token disusupi yang dapat digunakan penyerang.

Membatalkan validitas token secara manual untuk akun pengguna yang telah disusupi

Tinjau panduan untuk menangani kredensial yang disusupi untuk identitas pengguna yang mungkin telah disusupi. Secara khusus, menghapus kredensial gcloud CLI adalah metode paling efektif bagi tim keamanan untuk mengatasi token OAuth yang disusupi bagi identitas pengguna. Untuk segera membatalkan token refresh dan token akses gcloud CLI dan memaksa pengguna untuk melakukan autentikasi ulang dengan sandi dan kunci keamanan, hapus gcloud CLI dari daftar aplikasi yang terhubung milik pengguna.

Setiap pengguna juga dapat menghapus kredensial gcloud CLI pada akun individualnya.

Metode lain, seperti menangguhkan pengguna, mereset sandi pengguna, atau menyetel ulang cookie login tidak secara khusus mengatasi ancaman token OAuth yang disusupi. Metode ini umumnya berguna untuk merespons insiden, tetapi tidak membatalkan token akses yang sudah dikontrol penyerang. Misalnya, jika Anda memilih untuk menangguhkan pengguna selama penyelidikan, tetapi tidak mencabut tidak mencabut token gcloud CLI, token akses mungkin masih valid jika pengguna yang ditangguhkan dipulihkan sebelum masa berlaku token akses berakhir.

Membatalkan validitas token secara terprogram untuk banyak akun pengguna

Jika Anda mencurigai adanya pelanggaran, tetapi Anda tidak dapat mengidentifikasi pengguna yang terdampak, pertimbangkan untuk mencabut sesi aktif bagi semua pengguna pada organisasi Anda lebih cepat daripada yang diizinkan oleh kebijakan autentikasi ulang.

Pendekatan ini dapat mengganggu pengguna sah dan menghentikan proses yang berjalan lama bergantung pada kredensial pengguna. Jika Anda memilih untuk menerapkan pendekatan ini, siapkan solusi bernaskah untuk pusat operasi keamanan (SOC) Anda agar dapat dijalankan lebih awal dan mengujinya dengan beberapa pengguna.

Kode contoh berikut menggunakan Workspace Admin SDK untuk mengidentifikasi semua identitas pengguna pada akun Google Workspace dan Cloud Identity Anda yang memiliki akses ke gcloud CLI. Jika penggunaan telah melakukan otorisasi gcloud CLI, skrip akan mencabut token refresh dan token akses serta memaksa untuk melakukan autentikasi ulang dengan sandi atau kunci keamanan. Petunjuk mengaktifkan Admin SDK API dan menjalankan kodem lihat Panduan Manual Google Apps Script.

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

Membatalkan validitas dan merotasi kredensial untuk akun layanan

Tidak seperti token akses yang diberikan ke identitas pengguna, token akses yang diberikan ke layanan akun tidak dapat dibatalkan melalui Konsol Admin atau perintah seperti gcloud auth revoke. Selain itu, durasi sesi yang Anda tentukan di kontrol sesi Google Cloud berlaku untuk akun pengguna di Cloud Identity atau direktori Google Workspace, tetapi tidak untuk akun layanan. Oleh karena itu, respons insiden untuk akun layanan yang disusupi harus mengatasi file kunci persisten dan token akses sementara.

Jika Anda mencurigai kredensial akun layanan yang telah disusupi, nonaktifkan akun layanan, hapus kunci akun layanan jika ada, setelah 60 menit kemudian, aktifkan akun layanan. Menghapus kunci akun layanan dapat membatalkan kredensial yang memiliki masa aktif yang lama sehingga penyerang tidak dapat meminta token akses baru, tetapi tidak membatalkan token akses yang telah diberikan. Untuk memastikan token akses tidak disalahgunakan selama 60 menit, Anda harus menonaktifkan akun layanan selama 60 menit.

Atau cara lain, Anda dapat menghapus dan mengganti akun layanan untuk segera mencabut semua kredensial yang memiliki masa aktif pendek dan panjang, tetapi hal ini mungkin lebih mengganggu untuk mengganti akun layanan di aplikasi.

Langkah berikutnya