Cara terbaik untuk menggunakan akun layanan

Akun layanan mewakili pengguna non-manusia. Class ini ditujukan untuk skenario saat beban kerja, seperti aplikasi kustom, perlu mengakses resource atau melakukan tindakan tanpa interaksi, engagement pengguna akhir.

Akun layanan berbeda dari akun pengguna biasa dalam beberapa hal:

  • Aplikasi tersebut tidak memiliki sandi dan tidak dapat digunakan untuk login berbasis browser.
  • Project dibuat dan dikelola sebagai resource milik project Google Cloud. Sebaliknya, pengguna dikelola di akun Cloud Identity atau Google Workspace.
  • Template ini bersifat khusus untuk Google Cloud. Sebaliknya, pengguna yang dikelola di Cloud Identity atau Google Workspace bekerja di berbagai produk dan layanan Google.
  • Keduanya merupakan resource dan principal:
    • Sebagai akun utama, akun layanan dapat diberi akses ke resource, seperti bucket Cloud Storage.
    • Sebagai resource, akun layanan dapat diakses dan mungkin ditiru identitasnya oleh entity utama lain, seperti pengguna atau grup.

Meskipun akun layanan adalah alat yang berguna, ada beberapa cara yang dapat menyebabkan akun layanan disalahgunakan:

  • Eskalasi akses: Pihak tidak bertanggung jawab mungkin mendapatkan akses ke resource yang tidak dapat mereka akses dengan meniru identitas akun layanan.
  • Spoofing: Pihak tidak bertanggung jawab dapat menggunakan peniruan akun layanan untuk menyamarkan identitas mereka.
  • Non-repudiasi: Pihak tidak bertanggung jawab dapat menyembunyikan identitas dan tindakannya menggunakan akun layanan untuk melakukan operasi atas nama mereka. Dalam beberapa kasus, tindakan ini mungkin tidak dapat dilacak oleh pihak tidak bertanggung jawab.
  • Pengungkapan informasi: Pihak tidak bertanggung jawab dapat memperoleh informasi tentang infrastruktur, aplikasi, atau proses Anda dari keberadaan akun layanan tertentu.

Untuk membantu mengamankan akun layanan, pertimbangkan dua sifat dasar tersebut:

  • Karena akun layanan adalah akun utama, Anda harus membatasi hak istimewanya untuk mengurangi potensi bahaya yang dapat dilakukan oleh akun layanan yang disusupi.
  • Karena akun layanan merupakan resource, Anda harus melindunginya agar tidak disusupi.

Panduan ini menyajikan praktik terbaik untuk mengelola, menggunakan, dan mengamankan akun layanan.

Memilih waktu untuk menggunakan akun layanan

Tidak semua skenario memerlukan akun layanan untuk mengakses layanan Google Cloud, dan banyak skenario dapat mengautentikasi dengan metode yang lebih aman daripada menggunakan kunci akun layanan. Sebaiknya hindari penggunaan kunci akun layanan jika memungkinkan.

Saat Anda mengakses layanan Google Cloud menggunakan Google Cloud CLI, Library Klien Cloud, alat yang mendukung Kredensial Default Aplikasi (ADC) seperti Terraform, atau REST, gunakan diagram berikut untuk membantu Anda memilih metode autentikasi:

Pohon keputusan untuk memilih metode autentikasi berdasarkan kasus penggunaan

Diagram ini memandu Anda melalui pertanyaan-pertanyaan berikut:

  1. Apakah Anda menjalankan kode dalam lingkungan pengembangan pengguna tunggal, seperti workstation, Cloud Shell, atau antarmuka desktop virtual Anda sendiri?
    1. Jika ya, lanjutkan ke pertanyaan 4.
    2. Jika tidak, lanjutkan ke pertanyaan 2.
  2. Apakah Anda menjalankan kode di Google Cloud?
    1. Jika ya, lanjutkan ke pertanyaan 3.
    2. Jika tidak, lanjutkan ke pertanyaan 5.
  3. Apakah Anda menjalankan container di Google Kubernetes Engine atau GKE Enterprise?
    1. Jika ya, gunakan workload identity federation untuk GKE untuk menambahkan akun layanan ke pod Kubernetes.
    2. Jika tidak, lampirkan akun layanan ke resource.

  4. Apakah kasus penggunaan Anda memerlukan akun layanan?

    Misalnya, Anda ingin mengonfigurasi autentikasi dan otorisasi secara konsisten untuk aplikasi Anda di semua lingkungan.

    1. Jika tidak, lakukan autentikasi dengan kredensial pengguna.
    2. Jika ya, tiru identitas akun layanan dengan kredensial pengguna.
  5. Apakah workload Anda diautentikasi dengan penyedia identitas eksternal yang mendukung workload identity federation?
    1. Jika ya, konfigurasikan workload identity federation agar aplikasi yang berjalan secara lokal atau di penyedia cloud lain dapat menggunakan akun layanan.
    2. Jika tidak, buat kunci akun layanan.

Kelola akun layanan

Akun layanan berbeda dari akun pengguna biasa, tidak hanya dalam cara penggunaannya, tetapi juga dalam cara pengelolaannya. Bagian berikut memberikan praktik terbaik untuk mengelola akun layanan.

Praktik terbaik:

Mengelola akun layanan sebagai resource.
Membuat akun layanan satu tujuan.
Ikuti konvensi penamaan dan dokumentasi.
Mengidentifikasi dan menonaktifkan akun layanan yang tidak digunakan.
Nonaktifkan akun layanan yang tidak digunakan sebelum menghapusnya.

Mengelola akun layanan sebagai resource

Akun pengguna reguler biasanya dikelola sesuai dengan proses joiner-mover-leaver organisasi: Saat karyawan bergabung, akun pengguna baru dibuat untuk mereka. Saat mereka memindahkan departemen, akun penggunanya akan diperbarui. Dan saat mereka keluar dari perusahaan, akun penggunanya ditangguhkan atau dihapus.

Sebaliknya, akun layanan tidak terkait dengan karyawan tertentu. Sebagai gantinya, sebaiknya anggap akun layanan sebagai resource yang dimiliki—atau merupakan bagian dari—resource lain, seperti instance VM atau aplikasi tertentu.

Untuk mengelola akun layanan secara efektif, jangan melihat akun layanan secara terpisah. Sebagai gantinya, pertimbangkan mereka dalam konteks resource yang terkait dengannya dan kelola akun layanan dan resource terkait sebagai satu unit: Terapkan proses yang sama, siklus proses yang sama, dan ketekunan yang sama pada akun layanan dan sumber daya yang terkait, dan menggunakan alat yang sama untuk mengelolanya.

Membuat akun layanan satu tujuan

Berbagi satu akun layanan ke beberapa aplikasi dapat mempersulit pengelolaan akun layanan:

  • Aplikasi mungkin memiliki siklus proses yang berbeda. Jika aplikasi dinonaktifkan, mungkin tidak jelas apakah akun layanan juga dapat dinonaktifkan atau masih diperlukan.
  • Seiring waktu, persyaratan akses aplikasi mungkin berbeda. Jika aplikasi menggunakan akun layanan yang sama, Anda mungkin perlu memberi akun layanan akses ke resource yang lebih banyak, yang pada akhirnya meningkatkan risiko keseluruhan.
  • Log Audit Cloud menyertakan nama akun layanan yang melakukan perubahan atau mengakses data, tetapi tidak menampilkan nama aplikasi yang menggunakan akun layanan tersebut. Jika beberapa aplikasi berbagi akun layanan, Anda mungkin tidak dapat melacak aktivitas kembali ke aplikasi yang benar.

Secara khusus, beberapa layanan Google Cloud, termasuk App Engine dan Compute Engine, membuat akun layanan default yang memiliki peran Editor (roles/editor) pada project secara default. Saat Anda membuat resource seperti instance mesin virtual (VM) Compute Engine, dan akun layanan tidak ditentukan, resource tersebut dapat menggunakan akun layanan default secara otomatis. Meskipun akun layanan default memudahkan Anda untuk memulai, berbagi akun layanan yang canggih tersebut di beberapa aplikasi sangat berisiko.

Anda dapat melakukan beberapa langkah untuk menghindari kerumitan ini:

Mengikuti konvensi penamaan dan dokumentasi

Untuk membantu melacak pengaitan antara layanan dan aplikasi atau resource, ikuti konvensi penamaan saat membuat akun layanan baru:

  • Tambahkan awalan ke alamat email akun layanan yang mengidentifikasi cara akun digunakan. Contoh:
    • vm- untuk akun layanan yang terkait dengan instance VM.
    • wi- untuk akun layanan yang digunakan oleh Workload Identity.
    • wif- untuk akun layanan yang digunakan oleh workload identity federation.
    • onprem- untuk akun layanan yang digunakan oleh aplikasi lokal.
  • Sematkan nama aplikasi di alamat email akun layanan, misalnya: vm-travelexpenses@ jika VM menjalankan aplikasi biaya perjalanan.
  • Gunakan kolom deskripsi untuk menambahkan narahubung, link ke dokumentasi yang relevan, atau catatan lainnya.

Jangan sematkan informasi sensitif atau istilah di alamat email akun layanan.

Mengidentifikasi dan menonaktifkan akun layanan yang tidak digunakan

Jika akun layanan tidak digunakan lagi, nonaktifkan akun layanan. Dengan menonaktifkan akun layanan yang tidak digunakan, Anda mengurangi risiko penyalahgunaan akun layanan untuk pemindahan lateral atau eskalasi akses oleh pihak tidak bertanggung jawab.

Untuk akun layanan tujuan tunggal yang terkait dengan resource tertentu, seperti instance VM, nonaktifkan akun layanan segera setelah resource yang terkait dinonaktifkan atau dihapus.

Untuk akun layanan yang digunakan untuk beberapa tujuan atau dibagikan ke beberapa resource, akan lebih sulit untuk mengidentifikasi apakah akun layanan masih digunakan atau tidak. Dalam hal ini, Anda dapat menggunakan Activity Analyzer untuk melihat aktivitas autentikasi terbaru untuk akun layanan Anda.

Menonaktifkan akun layanan yang tidak digunakan sebelum menghapusnya

Jika Anda menghapus akun layanan, lalu membuat akun layanan baru dengan nama yang sama, akun layanan baru akan diberi identitas yang berbeda. Akibatnya, tidak ada binding IAM asli yang berlaku untuk akun layanan baru. Sebaliknya, jika Anda menonaktifkan dan mengaktifkan kembali akun layanan, semua binding IAM tetap utuh.

Untuk menghindari kehilangan binding IAM secara tidak sengaja, sebaiknya jangan langsung menghapus akun layanan. Sebagai gantinya, nonaktifkan akun layanan jika tidak diperlukan lagi dan hanya hapus setelah periode tertentu berlalu.

Jangan pernah menghapus akun layanan default seperti App Engine atau akun layanan default Compute Engine. Akun layanan ini tidak dapat dibuat ulang tanpa menonaktifkan dan mengaktifkan kembali API masing-masing, yang dapat merusak deployment yang ada. Jika Anda tidak menggunakan akun layanan default, nonaktifkan akun tersebut.

Membatasi hak istimewa akun layanan

Akun layanan adalah akun utama dan dapat diberi akses ke resource seperti akun pengguna biasa. Namun, akun layanan sering kali memiliki akses yang lebih besar ke lebih banyak resource daripada pengguna biasa. Selain itu, saat Anda menambahkan fungsionalitas ke aplikasi, akun layanan mereka cenderung mendapatkan lebih banyak akses dari waktu ke waktu; Anda mungkin juga lupa untuk mencabut akses yang tidak lagi diperlukan.

Praktik terbaik:

Jangan gunakan pemberian peran otomatis untuk akun layanan default.
Jangan mengandalkan cakupan akses saat menambahkan akun layanan ke instance VM.
Hindari menggunakan grup untuk memberi akun layanan akses ke resource.
Hindari penggunaan delegasi tingkat domain.
Jangan gunakan akun layanan untuk mengakses data pengguna tanpa persetujuan pengguna.
Gunakan IAM credentials API untuk elevasi hak istimewa sementara.
Gunakan Batas Akses Kredensial untuk melakukan downscope pada token akses.
Gunakan rekomendasi peran untuk mengidentifikasi izin yang tidak digunakan.
Gunakan analisis gerakan lateral untuk membatasi gerakan lateral.

Jangan menggunakan pemberian peran otomatis untuk akun layanan default

Beberapa layanan Google Cloud membuat akun layanan default saat Anda pertama kali mengaktifkan API mereka di project Google Cloud. Secara default, akun layanan ini diberi peran Editor (roles/editor) di project Google Cloud Anda, yang memungkinkan akun layanan ini membaca dan memodifikasi semua resource di project Google Cloud. Peran ini diberikan demi kenyamanan Anda, tetapi tidak penting agar layanan dapat berfungsi: Untuk mengakses resource di project Google Cloud Anda, layanan Google Cloud menggunakan agen layanan, bukan akun layanan default.

Untuk mencegah akun layanan default diberi peran Editor secara otomatis, aktifkan batasan Nonaktifkan Pemberian IAM Otomatis untuk Akun Layanan Default (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) ke organisasi Anda. Untuk menerapkan batasan ke beberapa project Google Cloud, konfigurasikan batasan di folder atau node organisasi. Menerapkan batasan tidak akan menghapus peran Editor dari akun layanan default yang ada.

Jika Anda menerapkan batasan ini, akun layanan default dalam project baru tidak akan memiliki akses apa pun ke resource Google Cloud Anda. Anda harus memberikan peran yang sesuai kepada akun layanan default agar akun layanan tersebut dapat mengakses resource Anda.

Jangan mengandalkan cakupan akses saat memasang akun layanan ke instance VM

Saat memasang akun layanan ke instance VM, Anda dapat menentukan satu atau beberapa cakupan akses. Cakupan akses memungkinkan Anda membatasi layanan yang dapat diakses VM. Pembatasan diterapkan selain kebijakan izinkan.

Cakupan akses bersifat kasar. Misalnya, dengan menggunakan cakupan https://www.googleapis.com/auth/devstorage.read_only, Anda dapat membatasi akses ke operasi hanya baca Cloud Storage, tetapi tidak dapat membatasi akses ke bucket tertentu. Oleh karena itu, cakupan akses bukanlah pengganti yang tepat untuk kebijakan izin yang terperinci.

Daripada mengandalkan cakupan akses, buat akun layanan khusus dan gunakan kebijakan izinkan terperinci untuk membatasi resource mana yang dapat diakses oleh akun layanan.

Menghindari penggunaan grup untuk memberi akun layanan akses ke resource

Dalam sebuah organisasi, sangat umum jika beberapa karyawan melakukan fungsi pekerjaan yang serupa atau tumpang tindih, sehingga memerlukan akses yang sama ke resource. Dengan menggunakan grup, Anda dapat memanfaatkan kesamaan ini untuk mengurangi overhead administratif.

Akun layanan dimaksudkan untuk digunakan oleh aplikasi. Terkadang beberapa aplikasi melakukan fungsi yang sama, sehingga memiliki persyaratan akses yang serupa atau identik. Sebaliknya, aplikasi cenderung unik dan resource yang perlu diakses biasanya berbeda untuk setiap aplikasi.

Menggunakan grup untuk memberi akun layanan akses ke resource dapat menyebabkan beberapa hasil yang buruk:

  • Proliferasi grup, dengan setiap grup hanya berisi satu atau beberapa akun layanan.
  • Izin creep: Seiring waktu, grup diberi akses ke resource yang jumlahnya terus meningkat, meskipun setiap anggota grup hanya memerlukan akses ke sebagian resource.

Sebaiknya hindari penggunaan grup, kecuali tujuan grup telah ditentukan secara spesifik. Sebagai gantinya, langsung berikan akses akun layanan ke resource yang mereka butuhkan.

Menghindari penggunaan delegasi tingkat domain

Delegasi tingkat domain memungkinkan akun layanan meniru identitas pengguna mana pun di akun Cloud Identity atau Google Workspace. Delegasi tingkat domain memungkinkan akun layanan untuk melakukan tugas administratif tertentu di Google Workspace dan Cloud Identity, atau untuk mengakses Google API yang tidak mendukung akun layanan dari luar Google Cloud.

Delegasi tingkat domain tidak membatasi akun layanan untuk meniru identitas pengguna tertentu, tetapi mengizinkannya meniru identitas pengguna mana pun di akun Cloud Identity atau Google Workspace, termasuk admin super. Dengan mengizinkan akun layanan menggunakan delegasi di seluruh domain, akun layanan dapat menjadi target yang menarik untuk serangan eskalasi akses.

Hindari penggunaan delegasi tingkat domain jika Anda dapat menyelesaikan tugas secara langsung dengan akun layanan atau menggunakan alur izin OAuth.

Jika Anda tidak dapat menghindari penggunaan delegasi tingkat domain, batasi kumpulan cakupan OAuth yang dapat digunakan akun layanan. Meskipun cakupan OAuth tidak membatasi pengguna yang dapat ditiru identitasnya oleh akun layanan, cakupan tersebut membatasi jenis data pengguna yang dapat diakses oleh akun layanan.

Aplikasi mungkin memerlukan akses ke data pengguna yang sensitif atau pribadi. Contoh data tersebut mencakup kotak surat atau kalender pengguna, dokumen yang disimpan di Google Drive, atau set data BigQuery yang berisi data sensitif.

Penggunaan akun layanan untuk mengakses data pengguna merupakan langkah yang tepat jika aplikasi melakukan tugas latar belakang tanpa pengawasan, seperti pemindaian pengindeksan atau pencegahan kebocoran data (DLP), atau jika pengguna akhir belum melakukan autentikasi dengan identitas Google. Dalam semua skenario lain saat aplikasi bertindak atas nama pengguna akhir, sebaiknya hindari penggunaan akun layanan.

Daripada menggunakan akun layanan untuk mengakses data pengguna (mungkin melakukan transisi utama), gunakan alur izin OAuth untuk meminta izin pengguna akhir. Kemudian, biarkan aplikasi bertindak dengan identitas pengguna akhir. Dengan menggunakan OAuth, bukan akun layanan, Anda membantu memastikan bahwa:

  • Pengguna dapat meninjau resource yang akan mereka beri akses ke aplikasi, dan dapat menyatakan atau menolak izin mereka secara eksplisit.
  • Pengguna dapat mencabut persetujuan di halaman Akun Saya kapan saja.
  • Anda tidak memerlukan akun layanan yang memiliki akses tidak terbatas ke semua data pengguna.

Dengan mengizinkan aplikasi menggunakan kredensial pengguna akhir, Anda menunda pemeriksaan izin ke Google Cloud API. Pendekatan ini membatasi risiko mengekspos data secara tidak sengaja yang tidak boleh diakses oleh pengguna karena error coding (masalah wakil yang bingung).

Menggunakan IAM Credentials API untuk elevasi hak istimewa sementara

Beberapa aplikasi hanya memerlukan akses ke resource tertentu pada waktu tertentu atau dalam keadaan tertentu. Contoh:

  • Aplikasi mungkin memerlukan akses ke data konfigurasi selama startup, tetapi mungkin tidak memerlukan akses tersebut setelah diinisialisasi.
  • Aplikasi supervisor dapat memulai tugas latar belakang secara berkala ketika setiap pekerjaan memiliki persyaratan akses yang berbeda.

Dalam skenario seperti itu, menggunakan satu akun layanan dan memberikannya akses ke semua resource bertentangan dengan prinsip hak istimewa terendah: Kapan pun, aplikasi cenderung memiliki akses ke lebih banyak resource daripada yang benar-benar dibutuhkan.

Untuk membantu memastikan bahwa berbagai bagian aplikasi Anda hanya memiliki akses ke resource yang diperlukan, gunakan IAM Credentials API untuk elevasi hak istimewa sementara:

  • Buat akun layanan khusus untuk setiap bagian aplikasi atau kasus penggunaan, dan hanya berikan akses akun layanan ke resource yang diperlukan.
  • Buat akun layanan lain yang bertindak sebagai supervisor. Berikan peran Service Account Token Creator kepada akun layanan lain tersebut agar dapat meminta token akses berumur pendek untuk akun layanan tersebut.
  • Memisahkan aplikasi Anda sehingga satu bagian aplikasi berfungsi sebagai perantara token dan hanya mengizinkan bagian aplikasi ini menggunakan akun layanan supervisor.
  • Gunakan broker token untuk menerbitkan akun layanan berjangka pendek ke bagian lain aplikasi.

Untuk bantuan terkait pembuatan kredensial dengan masa berlaku singkat, lihat Membuat kredensial berumur pendek untuk akun layanan.

Menggunakan Batas Akses Kredensial untuk memperkecil token akses

Token akses Google adalah token pemilik, yang berarti bahwa penggunaannya tidak terikat dengan aplikasi tertentu. Jika aplikasi Anda meneruskan token akses ke aplikasi lain, aplikasi lain tersebut dapat menggunakan token tersebut dengan cara yang sama seperti yang dapat dilakukan aplikasi Anda. Demikian pula, jika token akses dibocorkan kepada pihak tidak bertanggung jawab, mereka dapat menggunakan token tersebut untuk mendapatkan akses.

Karena token akses adalah token pemilik, Anda harus melindunginya agar tidak bocor atau terlihat oleh pihak yang tidak berwenang. Anda dapat membatasi potensi kerusakan yang dapat disebabkan oleh token akses bocor dengan membatasi resource yang aksesnya diberikan. Proses ini disebut downscoping.

Gunakan Batas Akses Kredensial untuk melakukan downscope pada token akses setiap kali Anda meneruskan token akses ke aplikasi lain, atau ke komponen aplikasi yang berbeda. Tetapkan batas akses sehingga token memberikan akses yang cukup ke resource yang diperlukan, tetapi tidak lebih.

Menggunakan rekomendasi peran untuk mengidentifikasi izin yang tidak digunakan

Saat pertama kali men-deploy aplikasi, Anda mungkin tidak yakin tentang peran dan izin mana yang benar-benar diperlukan aplikasi. Akibatnya, Anda dapat memberi akun layanan aplikasi izin lebih banyak yang diperlukan.

Demikian pula, persyaratan akses aplikasi dapat berubah dari waktu ke waktu, dan beberapa peran dan izin yang awalnya Anda berikan mungkin tidak diperlukan.

Gunakan rekomendasi peran untuk mengidentifikasi izin yang benar-benar digunakan aplikasi, dan izin mana yang mungkin tidak digunakan. Sesuaikan kebijakan izin resource yang terpengaruh untuk membantu memastikan bahwa aplikasi tidak diberi akses lebih dari yang benar-benar diperlukan.

Menggunakan insight gerakan lateral untuk membatasi gerakan lateral

Pergerakan lateral adalah ketika akun layanan dalam satu project memiliki izin untuk meniru akun layanan di project lain. Misalnya, akun layanan mungkin telah dibuat di project A, tetapi memiliki izin untuk meniru akun layanan di project B.

Izin ini dapat menyebabkan rantai peniruan identitas di seluruh project yang memberi akun utama akses yang tidak diinginkan ke resource. Misalnya, akun utama dapat meniru akun layanan di project A, lalu menggunakan akun layanan tersebut untuk meniru akun layanan di project B. Jika akun layanan di project B memiliki izin untuk meniru identitas akun layanan lain dalam project lain di organisasi Anda, akun layanan utama dapat terus menggunakan peniruan akun layanan untuk berpindah dari satu project ke project lain, dan mendapatkan izin saat akun tersebut digunakan mulai.

Pemberi rekomendasi memberikan insight pergerakan lateral untuk membantu Anda mengurangi masalah ini. Insight gerakan lateral mengidentifikasi peran yang memungkinkan akun layanan dalam satu project untuk meniru akun layanan di project lain. Untuk mempelajari cara melihat dan mengelola insight gerakan lateral secara langsung, lihat Mengelola insight gerakan lateral.

Beberapa analisis pergerakan lateral dikaitkan dengan rekomendasi peran. Anda dapat menerapkan rekomendasi tersebut untuk mengurangi pergerakan lateral di seluruh project Anda. Untuk mempelajari caranya, lihat Meninjau dan menerapkan rekomendasi.

Melindungi dari ancaman eskalasi akses

Akun layanan yang belum diberi peran apa pun, tidak memiliki akses ke resource apa pun, dan tidak dikaitkan dengan aturan firewall apa pun biasanya memiliki nilai terbatas. Setelah Anda memberi akun layanan akses ke resource, nilai akun layanan akan meningkat: Akun layanan menjadi lebih berguna bagi Anda, tetapi juga menjadi target yang lebih menarik untuk serangan eskalasi akses.

Sebagai contoh, pertimbangkan akun layanan yang memiliki akses penuh ke bucket Cloud Storage yang berisi informasi sensitif. Dalam situasi ini, akun layanan secara efektif sama berharganya dengan bucket Cloud Storage itu sendiri: Alih-alih mencoba mengakses bucket secara langsung, pihak tidak bertanggung jawab mungkin mencoba untuk mengambil alih kontrol akun layanan. Jika upaya tersebut berhasil, pihak tidak bertanggung jawab dapat mengeskalasikan hak istimewanya dengan meniru identitas akun layanan, yang kemudian memberi mereka akses ke informasi sensitif dalam bucket.

Teknik eskalasi akses yang melibatkan akun layanan biasanya termasuk dalam kategori berikut:

  • Mengautentikasi sebagai akun layanan: Anda mungkin secara tidak sengaja memberikan izin kepada pengguna untuk meniru identitas akun layanan atau untuk membuat akun layanan untuk akun layanan. Jika akun layanan lebih berhak istimewa daripada pengguna itu sendiri, pengguna dapat melakukan autentikasi sebagai akun layanan untuk mengeskalasikan hak istimewanya dan mendapatkan akses ke resource yang tidak dapat mereka akses.

  • Menggunakan resource yang memiliki akun layanan terpasang: Jika pengguna memiliki izin untuk mengakses dan mengubah pipeline CI/CD, instance VM, atau sistem otomatisasi lainnya yang telah memasang akun layanan, maka mereka mungkin dapat melakukan tindakan menggunakan akun layanan yang terkait dengan sumber daya tersebut. Akibatnya, meskipun tidak memiliki izin untuk meniru identitas akun layanan, mereka mungkin masih bisa menggunakan izin akun layanan untuk melakukan tindakan yang tidak diizinkan diri mereka sendiri.

    Misalnya, jika pengguna memiliki akses SSH ke instance VM Compute Engine, mereka dapat menjalankan kode pada instance untuk mengakses resource apa pun yang dapat diakses oleh akun layanan terkait milik instance.

  • Izinkan perubahan kebijakan, grup, atau peran kustom: Pengguna yang tidak memiliki akses ke akun layanan dengan hak istimewa mungkin masih memiliki izin untuk mengubah kebijakan izinkan akun layanan, yang menyertakan project Google Cloud, atau folder. Pengguna kemudian dapat memperluas salah satu kebijakan yang memungkinkan untuk memberikan izin kepada diri mereka sendiri untuk (secara langsung atau tidak langsung) mengautentikasi sebagai akun layanan.

Bagian berikut memberikan praktik terbaik untuk melindungi akun layanan dari ancaman eskalasi akses.

Praktik terbaik:

Hindari membiarkan pengguna meniru identitas akun layanan yang memiliki hak istimewa lebih dari pengguna itu sendiri.
Hindari mengizinkan pengguna mengubah kebijakan izin akun layanan yang memiliki hak istimewa lebih tinggi daripada pengguna itu sendiri.
Jangan izinkan pengguna membuat atau mengupload kunci akun layanan.
Jangan berikan akses ke akun layanan di tingkat folder atau project Google Cloud.
Jangan menjalankan kode dari sumber yang kurang terlindungi di resource komputasi yang terkait dengan akun layanan dengan hak istimewa.
Batasi akses shell ke VM yang memiliki akun layanan dengan hak istimewa terlampir.
Batasi akses server metadata ke pengguna dan proses yang dipilih.

Menghindari mengizinkan pengguna melakukan autentikasi sebagai akun layanan yang memiliki hak istimewa lebih tinggi daripada pengguna itu sendiri

Dengan meniru identitas akun layanan, pengguna akan mendapatkan akses ke beberapa atau semua resource yang dapat diakses oleh akun layanan. Jika akun layanan memiliki akses yang lebih luas daripada pengguna, akun tersebut secara efektif lebih istimewa daripada pengguna.

Memberikan izin kepada pengguna untuk meniru identitas akun layanan yang lebih berhak dapat dengan sengaja memungkinkan pengguna meningkatkan hak istimewanya untuk sementara waktu—mirip dengan menggunakan alat sudo di Linux, atau menggunakan elevasi proses pada Windows. Kecuali jika Anda berurusan dengan skenario yang memerlukan elevasi hak istimewa sementara tersebut, sebaiknya jangan izinkan pengguna meniru identitas akun layanan dengan hak istimewa yang lebih tinggi.

Pengguna juga bisa secara tidak langsung mendapatkan izin akun layanan dengan melampirkan ke resource, lalu menjalankan kode pada resource tersebut. Menjalankan kode dengan cara ini bukanlah peniruan akun layanan karena hanya melibatkan satu identitas terautentikasi (akun layanan). Namun, tindakan ini dapat memberi pengguna akses yang tidak akan mereka miliki jika tidak melakukannya.

Izin yang memungkinkan pengguna meniru identitas akun layanan atau melampirkan akun layanan ke resource mencakup hal berikut:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.getOpenIdToken
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.implicitDelegation
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccountKeys.create
  • deploymentmanager.deployments.create
  • cloudbuild.builds.create

Peran yang berisi beberapa izin ini mencakup (tetapi tidak terbatas pada):

  • (roles/owner) Pemilik
  • (roles/editor) Editor
  • (roles/iam.serviceAccountUser) Pengguna Akun Layanan
  • (roles/iam.serviceAccountTokenCreator)Pembuat Token Akun Layanan
  • (roles/iam.serviceAccountKeyAdmin) Admin Kunci Akun Layanan
  • (roles/iam.serviceAccountAdmin) Admin Akun Layanan
  • (roles/iam.workloadIdentityUser) Pengguna Workload Identity
  • (roles/deploymentmanager.editor) Editor Pengelola Deployment
  • (roles/cloudbuild.builds.editor) Cloud Build Editor

Sebelum menetapkan salah satu peran ini kepada pengguna, tanyakan pada diri Anda sendiri:

  • Resource mana di dalam dan di luar project Google Cloud saat ini yang dapat diakses pengguna dengan meniru identitas akun layanan?
  • Apakah tingkat akses ini dibenarkan?
  • Apakah ada perlindungan yang memadai yang dapat mengontrol dalam keadaan apa pengguna dapat meniru identitas akun layanan?

Jangan tetapkan peran tersebut jika Anda tidak dapat mengkonfirmasi semua pertanyaan. Sebagai gantinya, pertimbangkan untuk memberi pengguna akun layanan yang berbeda dengan hak istimewa yang lebih rendah.

Menghindari mengizinkan pengguna mengubah kebijakan izin akun layanan dengan hak istimewa lebih

Pengguna yang diizinkan untuk menggunakan atau meniru identitas akun layanan ditentukan oleh kebijakan izin akun layanan. Kebijakan izinkan dapat diubah atau diperluas oleh pengguna yang memiliki izin iam.serviceAccounts.setIamPolicy di akun layanan tertentu. Peran yang berisi izin tersebut meliputi:

  • (roles/owner) Pemilik
  • (roles/iam.securityAdmin) Security Admin
  • (roles/iam.serviceAccountAdmin) Admin Akun Layanan

Peran yang menyertakan izin iam.serviceAccounts.setIamPolicy memberi pengguna kontrol penuh atas akun layanan:

  • Pengguna dapat memberikan izin kepada diri sendiri untuk meniru identitas akun layanan, sehingga pengguna dapat mengakses resource yang sama dengan akun layanan.
  • Pengguna dapat memberi pengguna lain tingkat akses yang sama atau serupa ke akun layanan.

Sebelum menetapkan salah satu peran ini kepada pengguna, tanyakan pada diri sendiri resource mana di dalam dan di luar project Google Cloud saat ini yang dapat diakses pengguna dengan meniru akun layanan. Jangan biarkan pengguna mengubah kebijakan izinkan akun layanan jika akun layanan memiliki lebih banyak hak istimewa daripada pengguna.

Jangan mengizinkan pengguna membuat atau mengupload kunci akun layanan

Kunci akun layanan memungkinkan aplikasi atau pengguna melakukan autentikasi sebagai akun layana. Tidak seperti bentuk peniruan akun layanan lainnya, menggunakan kunci akun layanan tidak memerlukan bentuk autentikasi sebelumnya. Siapa pun yang memiliki kunci akun layanan dapat menggunakannya.

Efek akhir penggunaan kunci akun layanan untuk mengautentikasi mirip dengan efek peniruan akun layanan. Jika pengguna memiliki akses ke kunci akun layanan, atau memberinya izin untuk membuat kunci akun layanan baru, pengguna dapat melakukan autentikasi sebagai akun layanan dan mengakses semua resource yang dapat diakses oleh akun layanan.

Untuk Membuat atau mengupload kunci akun layanan memerlukan izin iam.serviceAccountKeys.create, yang disertakan dalam Admin Kunci Akun Layanan (roles/iam.serviceAccountKeyAdmin) dan Editor (roles/editor).

Sebelum menetapkan peran apa pun yang menyertakan izin iam.serviceAccountKeys.create kepada pengguna, tanyakan pada diri sendiri resource mana di dalam dan di luar project Google Cloud saat ini yang dapat diakses pengguna dengan meniru identitas akun layanan. Jangan izinkan pengguna membuat kunci akun layanan untuk akun layanan yang memiliki lebih banyak hak istimewa.

Jika project Google Cloud Anda tidak memerlukan kunci akun layanan sama sekali, terapkanNonaktifkan pembuatan kunci akun layanan danNonaktifkan upload kunci akun layanan batasan kebijakan organisasi ke project Google Cloud atau folder yang melingkupinya. Batasan ini mencegah semua pengguna membuat dan mengupload kunci akun layanan, termasuk kunci yang memiliki izin iam.serviceAccountKeys.create di akun layanan.

Jangan berikan akses ke akun layanan pada tingkat folder atau project Google Cloud

Akun layanan adalah resource dan bagian dari hierarki resource. Oleh karena itu, Anda dapat mengelola akses ke akun layanan di tingkat berikut:

  • Akun layanan individual
  • Project Google Cloud yang mencakup
  • Folder dalam ancestry project Google Cloud
  • Node organisasi

Mengelola akses di level project Google Cloud atau hierarki resource yang lebih tinggi dapat membantu mengurangi overhead administratif, tetapi juga dapat menyebabkan pemberian hak istimewa yang berlebihan. Misalnya, jika Anda memberi pengguna peran Service Account Token Creator dalam project Google Cloud, pengguna tersebut dapat meniru identitas akun layanan apa pun dalam project Google Cloud. Dapat meniru identitas akun layanan apa pun berarti bahwa pengguna berpotensi mendapatkan akses ke semua resource yang dapat diakses oleh akun layanan tersebut, termasuk resource di luar project Google Cloud.

Untuk menghindari pemberian yang berlebihan, jangan mengelola akses ke akun layanan di level folder atau project Google Cloud. Sebagai gantinya, kelola akses satu per satu untuk setiap akun layanan.

Jangan menjalankan kode dari sumber yang kurang terlindungi pada resource komputasi yang memiliki akun layanan dengan hak istimewa terlampir

Ketika Anda memasang akun layanan ke resource komputasi, seperti instance VM atau aplikasi Cloud Run, proses yang berjalan pada resource tersebut dapat menggunakan server metadata untuk meminta token akses dan ID. Token ini memungkinkan proses melakukan autentikasi sebagai akun layanan dan mengakses resource atas nama akun layanan tersebut.

Secara default, akses ke server metadata tidak dibatasi untuk proses atau pengguna tertentu. Sebagai gantinya, kode apa pun yang dieksekusi pada resource komputasi dapat mengakses server metadata dan memperoleh token akses. Kode tersebut dapat mencakup:

  • Kode aplikasi Anda.
  • Kode yang dikirimkan oleh pengguna akhir, jika aplikasi Anda mengizinkan evaluasi skrip sisi server apa pun.
  • Kode dibaca dari repositori sumber jarak jauh, jika resource komputasi merupakan bagian dari sistem CI/CD.
  • Skrip startup dan shutdown yang disalurkan oleh bucket Cloud Storage.
  • Kebijakan tamu yang didistribusikan oleh VM Manager.

Jika kode dikirimkan oleh pengguna atau dibaca dari lokasi penyimpanan jarak jauh, Anda harus memastikan bahwa kode tersebut dapat dipercaya dan bahwa lokasi penyimpanan jarak jauh setidaknya sebaik-baiknya seperti akun layanan yang terpasang. Jika lokasi penyimpanan jarak jauh kurang terlindungi dengan baik dibandingkan akun layanan, pihak tidak bertanggung jawab mungkin dapat mengeskalasikan hak istimewanya. Mereka dapat melakukannya dengan memasukkan kode berbahaya yang menggunakan hak istimewa akun layanan ke lokasi tersebut.

Membatasi akses shell ke VM yang memiliki akun layanan dengan hak istimewa terlampir

Beberapa resource komputasi mendukung akses interaktif dan memungkinkan pengguna mendapatkan akses shell ke sistem. Contoh:

  • Dengan Compute Engine, Anda dapat menggunakan SSH atau RDP untuk login ke instance VM.
  • Dengan Google Kubernetes Engine, Anda dapat menggunakan kubectl exec untuk menjalankan perintah atau memulai shell dalam container Kubernetes.

Jika instance VM memiliki akun layanan dengan hak istimewa terlampir, setiap pengguna dengan akses shell ke sistem dapat mengautentikasi dan mengakses resource sebagai akun layanan. Agar pengguna tidak menyalahgunakan kemampuan ini untuk mengeskalasikan hak istimewanya, Anda harus memastikan bahwa akses shell setidaknya sama amannya dengan akun layanan yang terpasang.

Untuk instance Linux, Anda dapat menerapkan bahwa akses SSH lebih ketat daripada akses ke akun layanan yang terpasang menggunakan Login OS: Agar terhubung ke instance VM yang mengaktifkan Login OS, pengguna tidak hanya harusdiizinkan menggunakan Login OS , tetapi juga harus memilikiiam.serviceAccounts.actAs izin pada akun layanan yang terpasang.

Tingkat kontrol akses yang sama tidak berlaku untuk instance VM yang menggunakan kunci berbasis metadata atau untuk instance Windows: Memublikasikan kunci SSH ke metadata atau meminta kredensial Windows memerlukan akses ke metadata instance VM dan izin iam.serviceAccounts.actAs pada akun layanan yang terpasang. Namun, setelah kunci SSH dipublikasikan atau kredensial Windows telah diperoleh, login berikutnya tidak akan melalui pemeriksaan izin IAM tambahan.

Demikian pula, jika instance VM menggunakan modul autentikasi pluggable Linux kustom untuk autentikasi, atau merupakan anggota domain Active Directory, kemungkinan pengguna yang tidak memiliki izin untuk melakukan autentikasi sebagai akun layanan diizinkan untuk login. Untuk informasi selengkapnya, lihat Praktik terbaik untuk menjalankan Active Directory di Google Cloud.

Khususnya untuk instance VM yang tidak menggunakan Login OS, pertimbangkan untuk membatasi akses shell dengan Identity-Aware Proxy. Hanya berikan peran IAP-Secured Tunnel User (roles/iap.tunnelResourceAccessor) kepada pengguna yang akan diizinkan untuk melakukan autentikasi sebagai akun layanan yang terpasang pada instance VM.

Membatasi akses server metadata ke pengguna dan proses yang dipilih

Ketika Anda memasang akun layanan ke instance VM, beban kerja yang di-deploy pada VM dapat mengakses server metadata untuk meminta token untuk akun layanan. Secara default, akses ke server metadata tidak terbatas pada proses atau pengguna tertentu di VM: Bahkan proses yang berjalan sebagai pengguna dengan hak istimewa rendah, seperti nobody di Linux atau LocalService di Windows, memiliki akses penuh ke server metadata, dan dapat memperoleh token untuk akun layanan.

Untuk membatasi akses server metadata ke pengguna tertentu, konfigurasikan firewall host sistem operasi tamu agar hanya mengizinkan pengguna ini untuk membuka koneksi keluar ke server metadata.

Di Linux, Anda dapat menggunakan opsi --uid-owner dan --gid-owner untuk menyiapkan aturan iptables yang hanya berlaku untuk pengguna atau grup tertentu. Di Windows, perintah Set-NetFirewallSecurityFilter memungkinkan Anda menyesuaikan aturan firewall sehingga dapat diterapkan ke pengguna atau grup yang dipilih.

Perlindungan dari ancaman pengungkapan informasi

Praktik terbaik:

Hindari mengungkapkan informasi rahasia di alamat email akun layanan.

Menghindari pengungkapan informasi rahasia di alamat email akun layanan

Untuk memberi akun layanan akses ke resource di project Google Cloud lain, Anda dapat menambahkan binding peran ke kebijakan izin resource. Seperti resource itu sendiri, kebijakan izinkan merupakan bagian dari project Google Cloud lainnya dan visibilitasnya juga dikontrol oleh project Google Cloud lainnya tersebut.

Melihat kebijakan izinkan biasanya bukan dianggap sebagai operasi dengan hak istimewa. Banyak peran menyertakan izin *.getIamPolicy yang diperlukan, termasuk peran Viewer dasar.

Pengguna yang dapat melihat kebijakan izinkan juga dapat melihat alamat email akun utama yang telah diberi akses ke resource. Dalam kasus akun layanan, alamat email dapat memberikan petunjuk kepada pihak tidak bertanggung jawab.

Misalnya, kebijakan izinkan mungkin menyertakan binding untuk akun layanan dengan alamat email jenkins@deployment-project-123.gserviceaccount.com. Bagi pihak tidak bertanggung jawab, alamat email ini tidak hanya menunjukkan bahwa ada project Google Cloud dengan ID deployment-project-123, tetapi juga bahwa project Google Cloud menjalankan server Jenkins. Dengan memilih nama yang lebih umum seperti deployer@deployment-project-123.gserviceaccount.com, Anda menghindari pengungkapan informasi tentang jenis software yang Anda jalankan di deployment-project-123.

Jika Anda memberi akun layanan akses ke resource di project Google Cloud yang memiliki akses yang kurang terkontrol (seperti sandbox atau project Google Cloud pengembangan), pastikan alamat email akun layanan tidak mengungkapkan informasi apa pun. Secara khusus, jangan mengungkapkan informasi yang bersifat rahasia atau yang dapat memberikan petunjuk kepada penyerang.

Perlindungan dari ancaman non-repudiasi

Setiap kali Anda melihat aktivitas mencurigakan yang memengaruhi salah satu resource Anda di Google Cloud, Log Audit Cloud merupakan sumber informasi penting untuk mencari tahu kapan aktivitas tersebut terjadi dan pengguna mana yang terlibat.

Setiap kali Cloud Audit Logs menunjukkan bahwa aktivitas dilakukan oleh akun layanan, informasi tersebut mungkin tidak cukup untuk merekonstruksi rantai peristiwa secara lengkap: Anda juga harus dapat mencari tahu pengguna atau aplikasi mana yang menyebabkan akun layanan yang menjalankan aktivitas tersebut.

Bagian ini berisi praktik terbaik yang dapat membantu Anda mempertahankan jejak audit yang tidak dapat disangkal.

Praktik terbaik:

Gunakan kunci akun layanan hanya jika tidak ada alternatif yang memungkinkan.
Aktifkan log akses data untuk IAM API.
Pastikan histori CI/CD dapat dihubungkan dengan Cloud Audit Logs.
Buat entri log kustom untuk setiap pengguna aplikasi.

Menggunakan kunci akun layanan hanya jika tidak ada alternatif lain yang memungkinkan

Jika tidak dapat menggunakan metode autentikasi yang lebih aman, Anda mungkin perlu membuat kunci akun layanan untuk aplikasi tersebut. Namun, mengautentikasi dengan kunci akun layanan akan menimbulkan ancaman non-penyangkalan. Cloud Audit Logs membuat log ketika akun layanan mengubah resource, tetapi jika akun layanan diautentikasi dengan kunci akun layanan, tidak ada cara yang dapat diandalkan untuk mengetahui siapa yang menggunakan kunci tersebut. Sebagai perbandingan, mengautentikasi sebagai akun layanan dengan meniru identitas akun layanan dengan kredensial pengguna akan mencatat akun utama yang bertindak sebagai akun layanan.

Sebaiknya cegah pembuatan kunci akun layanan dengan menerapkan batasan kebijakan organisasi Nonaktifkan pembuatan kunci akun layanan ke project Google Cloud atau folder yang disertakan. Jika Anda harus menggunakan kunci akun layanan untuk skenario yang tidak dapat ditangani dengan alternatif yang direkomendasikan, berikan pengecualian untuk batasan kebijakan, sesempit mungkin, dan tinjau praktik terbaik untuk mengelola kunci akun layanan.

Mengaktifkan log akses data untuk API IAM

Untuk membantu Anda mengidentifikasi dan memahami skenario peniruan akun layanan, layanan seperti Compute Engine menyertakan bagian serviceAccountDelegationInfo di Log Audit Cloud. Bagian ini menunjukkan apakah akun layanan ditiru identitasnya, dan oleh pengguna yang mana.

Tidak semua layanan menyertakan detail peniruan identitas dalam Log Audit Cloud mereka. Untuk merekam semua peristiwa peniruan identitas, Anda juga harus mengaktifkan log akses data untuk API berikut:

  • Identity and Access Management (IAM) API di semua project Google Cloud yang berisi akun layanan
  • Security Token Service API di semua project Google Cloud yang berisi kumpulan workload identity

Dengan mengaktifkan log ini, Anda memastikan bahwa sebuah entri ditambahkan ke Cloud Audit Logs setiap kali pengguna meminta token akses atau token ID untuk akun layanan.

Memastikan histori CI/CD dapat dikorelasikan dengan Cloud Audit Logs

Akun layanan biasanya digunakan oleh sistem CI/CD untuk melakukan deployment setelah perubahan kode berhasil diverifikasi dan disetujui untuk deployment. Biasanya, sistem CI/CD menyimpan histori peristiwa yang mengarah pada deployment. Histori ini mungkin mencakup ID peninjauan kode, commit, dan operasi pipeline yang sesuai, serta informasi tentang siapa yang menyetujui deployment.

Jika deployment memodifikasi resource apa pun di Google Cloud, perubahan ini akan dilacak di Cloud Audit Logs masing-masing resource. Cloud Audit Logs berisi informasi tentang pengguna atau akun layanan yang memulai perubahan. Namun dalam deployment yang dipicu oleh sistem CI/CD, akun layanan itu sendiri sering kali tidak cukup untuk merekonstruksi seluruh rantai peristiwa yang menyebabkan perubahan.

Untuk membuat jejak audit yang konsisten di seluruh sistem CI/CD dan Google Cloud, Anda harus memastikan bahwa data Log Audit Cloud dapat dikorelasikan dengan peristiwa dalam histori sistem CI/CD. Jika menemukan peristiwa yang tidak terduga di Cloud Audit Logs, Anda dapat menggunakan korelasi ini untuk menentukan apakah perubahan tersebut benar-benar dilakukan oleh sistem CI/CD, alasan perubahan tersebut dilakukan, dan siapa yang menyetujuinya.

Cara untuk membuat korelasi antara data dan peristiwa Cloud Audit Logs dalam histori sistem CI/CD meliputi:

  • Log permintaan API yang dilakukan oleh setiap operasi pipeline CI/CD.
  • Setiap kali API menampilkan ID operasi, catat ID tersebut dalam log sistem CI/CD.

  • Tambahkan header HTTP X-Goog-Request-Reason ke permintaan API dan teruskan ID operasi pipeline CI/CD. Terraform dapat menambahkan header ini secara otomatis jika Anda menentukan alasan permintaan.

    Atau, sematkan informasi di header User-Agent sehingga informasi tersebut direkam dalam Cloud Audit Logs.

Untuk membantu memastikan non-repudiability, konfigurasikan file log dan commit histori sehingga tidak dapat diubah dan pihak tidak bertanggung jawab tidak dapat menyembunyikan jejaknya secara retroaktif.

Membuat entri log kustom untuk masing-masing pengguna aplikasi

Akun layanan juga berguna untuk aplikasi yang digunakan pengguna untuk mengautentikasi dengan skema autentikasi khusus, lalu mengakses resource Google Cloud secara tidak langsung. Aplikasi ini dapat mengonfirmasi bahwa pengguna diautentikasi dan diberi otorisasi, lalu menggunakan akun layanan untuk melakukan autentikasi ke layanan Google Cloud dan mengakses resource. Namun, Cloud Audit Logs akan mencatat bahwa akun layanan mengakses resource, bukan pengguna yang menggunakan aplikasi Anda.

Untuk membantu melacak kembali akses tersebut ke pengguna, desain logika aplikasi untuk menulis entri log kustom setiap kali pengguna mengakses resource dan menghubungkan entri log kustom dengan Cloud Audit Logs.

Langkah selanjutnya