Praktik terbaik untuk melindungi kredensial developer

Pelajari praktik terbaik untuk mengamankan workstation developer dan mencegah pencurian serta penyalahgunaan Google Cloud kredensial, termasuk tokenOAuth bearer Google Cloud CLI, Kredensial Default Aplikasi, dan kunci lokal.

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

Risiko kredensial yang disusupi

Penyerang dapat membahayakan kredensial jika mendapatkan akses ke endpoint yang telah diautentikasi dengan atau gcloud CLI oleh akun layanan atau akun pengguna yang sah. Google Cloud 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.

Ringkasan kredensial developer

Kredensial berikut Google Cloud biasanya ditemukan di workstation developer:

Bagian berikut menjelaskan cara setiap jenis kredensial disimpan dan digunakan.

Token OAuth gcloud CLI

Gcloud CLI menggunakan token akses OAuth 2.0 untuk 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 setelah 60 menit secara default, tetapi dapat bertahan hingga 12 jam dalam batasan masa aktif yang diperpanjang. Namun, jenis kredensial 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. Token refresh yang memiliki masa aktif lama akan tetap ada hingga kondisi habis masa berlakunya met.

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, gcloud CLI akan menggunakan kunci ini untuk meminta token akses secara berkala. Kunci pribadi yang tahan lama disimpan di konfigurasi gcloud CLI dan akan tetap valid hingga Anda menonaktifkan atau 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 layanan. 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.

Kredensial Default Aplikasi

Kredensial Default Aplikasi digunakan oleh aplikasi untuk melakukan autentikasi dengan Google Cloud API. Developer dapat membuat Kredensial Default Aplikasi dengan menjalankan gcloud auth application-default login. Perintah ini menulis file JSON teks biasa ($HOME/.config/gcloud/application_default_credentials.json atau %APPDATA%\gcloud\application_default_credentials.json), yang berisi token refresh OAuth 2.0 dan kredensial klien untuk library klien.

Library klien atau skrip kustom apa pun dapat menggunakan kredensial ini untuk memanggil Google Cloud API.

Karena Kredensial Default Aplikasi disimpan dalam teks biasa, proses atau skrip yang tidak tepercaya yang berjalan dalam konteks pengguna dapat mengakses file secara langsung atau menggunakan perintah seperti gcloud auth application-default print-access-token untuk mengambil token akses aktif.

Malware umum sering menargetkan direktori ~/.config/gcloud/ untuk mengumpulkan application_default_credentials.json.

Untuk mengetahui informasi selengkapnya, lihat Kredensial Default Aplikasi.

Kunci akun layanan

Kunci akun layanan adalah file kunci JSON pribadi yang didownload dari Google Cloud konsol. Kunci ini digunakan oleh aplikasi untuk melakukan autentikasi dengan Google Cloud API. Kunci akun layanan dapat disimpan di lokasi berikut:

  • Direktori konfigurasi gcloud CLI setelah menjalankan gcloud auth activate-service-account
  • Sistem file lokal
  • Repositori kode internal

Kunci akun layanan di endpoint developer tidak terikat oleh Verifikasi 2 Langkah, tidak memiliki batas sesi, dan tidak otomatis habis masa berlakunya.

Penyerang yang mencuri kunci akun layanan dapat membuat token akses akun layanan untuk mempertahankan akses persisten.

Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk mengelola kunci akun layanan.

Kunci SSH

Kunci SSH digunakan untuk melakukan autentikasi dengan instance Compute Engine. Developer dapat membuat kunci SSH menggunakan gcloud compute ssh. Perintah ini membuat kunci pribadi lokal di ~/.ssh/google_compute_engine. Kunci SSH memiliki masa aktif lama.

Penyerang dapat menggunakan kunci SSH yang dicuri untuk mengakses VM, lalu membuat kueri server metadata untuk mengekstrak token akun layanan yang terlampir. Serangan ini mengabaikan firewall perimeter eksternal.

Daripada menggunakan kunci SSH, pertimbangkan Login OS dengan Verifikasi 2 Langkah. Untuk mengetahui informasi selengkapnya, lihat Menerapkan Verifikasi 2 Langkah untuk akses server jarak jauh.

Cookie browser

Cookie browser mengautentikasi permintaan HTTP web ke Google Cloud konsol dan Cloud Shell. Cookie browser dibuat secara otomatis saat pengguna login ke Google Cloud konsol.

Cookie disimpan di direktori profil browser di workstation lokal. Misalnya, Google Chrome menyimpan cookie di ~/.config/google-chrome/ di Linux atau %LOCALAPPDATA%\Google\Chrome\User Data di Windows.

Cookie browser adalah kredensial yang memiliki masa aktif lama yang hanya dibatalkan saat pengguna logout, saat terjadi waktu tunggu sesi, atau saat administrator mereset sesi pengguna di konsol Admin.

Penyerang yang mencuri cookie ini dapat mengimpornya ke browser lain untuk membajak sesi konsol aktif Google Cloud , sehingga mengabaikan autentikasi.

Untuk mengurangi risiko cookie sesi yang dicuri, tetapkan durasi sesi untuk Google Cloud layanan.

Token akses Workforce Identity Federation

Developer dapat menggunakan Workforce Identity Federation untuk melakukan autentikasi melalui penyedia identitas eksternal sehingga mereka dapat mengakses Google Cloud resource.

Untuk login dengan identitas gabungan, developer menggunakan file konfigurasi login (yang dibuat dengan gcloud iam workforce-pools create-login-config perintah) dan login ke gcloud CLI. Setelah autentikasi dengan penyedia identitas eksternal, Security Token Service akan menukar kode otorisasi dengan token akses gabungan yang berumur pendek dan token refresh OAuth.

Gcloud CLI menyimpan metadata kredensial dan token refresh dalam database kredensial lokal, dan menyimpan token akses aktif dalam cache di direktori konfigurasi gcloud CLI. Token akses gabungan adalah kredensial yang berumur pendek yang akan habis masa berlakunya setelah waktu yang ditetapkan (60 menit secara default).

Penyerang yang membahayakan endpoint dapat mengekstrak token akses gabungan aktif atau menggunakan gcloud auth print-access-token untuk meniru identitas utama tenaga kerja. Jika identitas tenaga kerja memiliki hak peniruan identitas, penyerang juga dapat meminta token akses akun layanan untuk meningkatkan hak istimewa.

Untuk mengurangi risiko, konfigurasi durasi sesi di pool identitas tenaga kerja Anda ke durasi minimum yang diperlukan dan sesuaikan durasi dengan kebijakan autentikasi ulang dan waktu tunggu sesi penyedia identitas eksternal Anda. Untuk mengetahui informasi selengkapnya tentang cara menyimpan dan mengelola kredensial, lihat praktik terbaik untuk menggunakan Workload Identity Federation.

Dampak kredensial yang 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 permintaan REST ke Google Cloud layanan saat menggunakan library klien yang tidak didukung. Developer dapat melihat kredensial melalui berbagai metode, termasuk berikut ini:

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

Jika penyerang membahayakan endpoint, ancaman utamanya adalah penyerang dapat menjalankan perintah gcloud CLI atau kode lain dengan kredensial sah dari identitas yang diautentikasi. Selain itu, penyerang dapat menyalin kredensial ke endpoint lain yang mereka kontrol untuk mempertahankan aksesnya. Ketika pencurian kredensial ini terjadi, ancaman sekunder akan muncul. Penyerang tetap dapat menggunakan kredensial yang memiliki masa aktif lama untuk memiliki akses persisten bahkan setelah Anda menghapus akses ke endpoint yang disusupi.

Jika penyerang berhasil membahayakan kredensial developer, mereka dapat melakukan tindakan berikut:

  • Meniru identitas akun layanan atau pengguna 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.
  • Meminta token akses tanpa batas waktu menggunakan token refresh OAuth persisten (dari gcloud CLI atau Kredensial Default Aplikasi) atau kunci pribadi yang terkait dengan akun layanan.
  • Mengabaikan autentikasi dengan sandi atau Verifikasi 2 Langkah karena token diberikan setelah alur login.
  • Menggunakan kunci SSH yang dicuri untuk mengakses instance Compute Engine dan membuat kueri server metadata untuk mencuri token akun layanan yang terlampir.
  • Menggunakan cookie browser yang dicuri untuk membajak sesi konsol aktif Google Cloud tanpa memerlukan sandi pengguna atau Verifikasi 2 Langkah.
  • Menggunakan token akses gabungan yang dicuri untuk mengakses resource yang diberikan ke pool identitas tenaga kerja atau meningkatkan hak istimewa dengan meniru identitas akun layanan.

Praktik terbaik untuk mengurangi risiko

Terapkan kontrol yang dijelaskan pada bagian berikut untuk membantu mengurangi risiko kredensial developer yang disusupi. Jika Anda mengikuti praktik terbaik keamanan yang dijelaskan dalam blueprint enterprise foundations atau desain zona landing di Google Cloud, Anda mungkin sudah memiliki kontrol ini.

Menetapkan durasi sesi untuk Google Cloud layanan

Untuk mengurangi waktu penyerang dapat mengeksploitasi token yang disusupi, tetapkan durasi sesi untuk Google Cloud layanan. Untuk pelanggan baru, a durasi sesi default selama 16 jam akan otomatis diterapkan. Pelanggan yang membuat Google Cloud organisasi mereka sebelum tahun 2023 mungkin memiliki setelan default untuk tidak pernah memerlukan autentikasi ulang. Tinjau setelan ini untuk memastikan bahwa Anda memiliki kebijakan autentikasi ulang dengan durasi sesi antara 1 hingga 24 jam. Kebijakan autentikasi ulang memaksa pengguna untuk melakukan autentikasi ulang gcloud CLI secara teratur dengan sandi atau kunci keamanannya.

Durasi sesi untuk Google Cloud layanan 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 Google Cloud traffic 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 Google Cloud konsol 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 Service 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 Kontrol Layanan VPC mengurangi efektivitas kredensial yang disusupi pada mesin yang dikontrol penyerang dan berada di luar lingkungan Anda.

Menerapkan 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, selesaikan langkah-langkah berikut:

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 kode 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. Selain itu, terapkan constraints/iam.disableServiceAccountKeyCreation dan constraints/iam.disableServiceAccountKeyUpload batasan kebijakan organisasi untuk menonaktifkan pembuatan kunci akun layanan.

Menerapkan prinsip hak istimewa terendah

Saat mendesain kebijakan Identity and Access Management (IAM), pertimbangkan hak istimewa terendah. Hanya berikan peran yang diperlukan pengguna untuk menyelesaikan tugas dalam cakupan terkecil. 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 kredensial yang disusupi merupakan hal yang utama, tetapi pertimbangkan juga risiko penyerang membahayakan endpoint terpercaya Anda. 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 Google Cloud konsol dan konsol Admin. Jika konsol dan konsol Admin dikelola oleh tim yang terpisah, Anda mungkin tertunda selama insiden. Google Cloud

Untuk menilai dan merespons penyusupan, lihat Merespons Google Cloud kredensial yang disusupi.

Memantau penyusupan kredensial

Untuk memantau potensi penyusupan, pertimbangkan hal berikut:

  • Pindai secret di repositori kode Anda, menggunakan alat seperti Deteksi Anomali atau pemindaian secret.

  • Di Cloud Audit Logs, konfigurasi pemberitahuan untuk hal berikut:

    • Metode iamcredentials.googleapis.com (seperti GenerateAccessToken, GenerateIdToken, SignJwt) untuk mengaudit pembuatan token akun layanan

      Log ini mengharuskan Anda mengaktifkan log Akses Data.

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail untuk mengaudit peniruan identitas akun layanan dan pengguna

    • Permintaan pertukaran sts.googleapis.com untuk pernyataan identitas yang anomali

  • Di Security Command Center, pantau temuan ancaman berikut dari Event Threat Detection:

    • Persistensi: Geografi Baru
    • Persistensi: Agen Pengguna Baru
    • Persistensi: Metode API Baru
    • Penghindaran: Akses dari Anonymizing Proxy
    • Peningkatan Hak Istimewa: Peniruan Identitas Akun Layanan yang Anomali untuk Aktivitas Admin
    • Peningkatan Hak Istimewa: Peniru Identitas Akun Layanan yang Anomali untuk Aktivitas Admin
    • Akses Awal: Kunci Akun Layanan yang Bocor Digunakan
    • Persistensi: Kunci Akun Layanan Dibuat
    • Akses Awal: Login Mencurigakan Diblokir
    • Akses Awal: Akun yang Dinonaktifkan Dibajak

    Untuk setiap ancaman, langkah-langkah investigasi yang direkomendasikan akan diberikan untuk membantu respons Anda.

  • Pantau login pengguna di Google Workspace dan Cloud Identity. Untuk melacak masalah dengan lebih baik, pertimbangkan untuk mengekspor log ke Cloud Logging.

  • Pantau log dari Chrome Enterprise Premium dan Kontrol Layanan VPC untuk upaya akses di luar perimeter dengan token yang dicuri.

  • Pantau anomali dalam penggunaan kunci akun layanan menggunakan Cloud Monitoring.

Pastikan pusat operasi keamanan (SOC) Anda segera diberi tahu dan memiliki playbook, alat, dan akses yang diperlukan untuk merespons dengan cepat jika ada dugaan penyusupan kredensial. Anda juga dapat mengintegrasikan Security Command Center dengan SIEM yang ada atau mengimpor log ke Google Security Operations untuk analisis lebih lanjut.

Langkah berikutnya