Praktik terbaik untuk mengelola kunci akun layanan.

Tidak seperti pengguna normal, akun layanan tidak memiliki sandi. Sebagai gantinya, akun layanan menggunakan pasangan kunci RSA untuk autentikasi: Jika Anda mengetahui kunci pribadi dari pasangan kunci akun layanan, Anda dapat menggunakan kunci tersebut untuk membuat token pemilik JWT dan menggunakan token pemilik untuk meminta token akses. Token akses yang dihasilkan mencerminkan identitas akun layanan dan Anda dapat menggunakannya untuk berinteraksi dengan Google Cloud API atas nama akun layanan.

Karena kunci pribadi memungkinkan Anda melakukan autentikasi sebagai akun layanan, memiliki akses ke kunci pribadi serupa halnya dengan mengetahui sandi pengguna. Kunci pribadi disebut sebagai kunci akun layanan. Pasangan kunci yang digunakan oleh akun layanan dibagi menjadi dua kategori, Dikelola Google dan dikelola pengguna.

Kunci akun layanan dapat menjadi risiko keamanan jika tidak dikelola dengan hati-hati. Sebaiknya Anda memilih alternatif yang lebih aman untuk autentikasi jika memungkinkan. Ancaman utama terkait dengan kunci akun layanan adalah:

  • Kebocoran kredensial: Kunci akun layanan mungkin secara tidak sengaja berakhir di tempat yang tidak seharusnya disimpan. Pihak tidak bertanggung jawab dapat menggunakan kunci akun layanan yang bocor untuk mengautentikasi dan mendapatkan akses di lingkungan Anda.
  • Eskalasi akses: Jika pihak tidak bertanggung jawab mendapatkan akses ke kunci akun layanan yang kurang aman, mereka mungkin dapat menggunakan kunci tersebut untuk mengeskalasikan hak istimewanya.
  • Pengungkapan informasi: Kunci akun layanan mungkin secara tidak sengaja mengungkapkan metadata rahasia.
  • Non-repudiasi: Dengan mengautentikasi menggunakan kunci akun layanan dan mengizinkan akun layanan menjalankan operasi atas nama mereka, pihak tidak bertanggung jawab dapat menyembunyikan identitas dan tindakannya.

Cara terbaik memitigasi ancaman ini adalah dengan menghindari kunci akun layanan yang dikelola pengguna dan menggunakan metode lain untuk mengautentikasi akun layanan jika memungkinkan. Anda juga dapat menggunakan IAM conditions dan Kontrol Layanan VPC untuk membatasi resource yang berpotensi diakses oleh akun layanan yang disusupi.

Jika Anda tidak dapat menggunakan alternatif yang lebih aman untuk kunci akun layanan, panduan ini menunjukkan praktik terbaik untuk mengelola, menggunakan, dan mengamankan kunci akun layanan.

Melindungi dari kebocoran kredensial

Seperti nama pengguna dan sandi, kunci akun layanan adalah bentuk kredensial. Jika dapat mengakses kunci akun layanan yang valid, pengguna dapat menggunakannya untuk mengautentikasi dan mengakses resource yang aksesnya telah diberikan kepada akun layanan.

Bagi pihak tidak bertanggung jawab, kunci akun layanan dapat lebih berharga daripada sandi yang bocor: Mencoba login menggunakan sandi yang bocor tidak akan berhasil jika akun pengguna telah dikonfigurasi untuk menggunakan verifikasi 2 langkah dan verifikasi login. Sebaliknya, autentikasi menggunakan kunci akun layanan yang bocor lebih memungkinan akan berhasil karena akun layanan tidak tunduk pada verifikasi login tambahan apapun.

Pihak tidak bertanggung jawab dapat mencari kunci akun layanan di berbagai tempat, termasuk:

  • Repositori kode sumber project open source
  • Bucket Cloud Storage publik
  • Dump data publik dari layanan yang dilanggar

Selain lokasi publik, pihak tidak bertanggung jawab mungkin mencari kunci akun layanan di lokasi pribadi yang disusupi. Beberapa contoh di antaranya:

  • Kotak masuk email
  • Fitur berbagi file
  • Penyimpanan cadangan
  • Direktori sistem file sementara

Cara efektif untuk menurunkan risiko kebocoran kunci akun layanan adalah dengan mengurangi jumlah kunci yang beredar dan mencegah pembuatan kunci baru. Bagian berikut menjelaskan cara membatasi jumlah kunci akun layanan yang beredar, dan tindakan lain yang dapat membantu Anda membatasi risiko kebocoran akun layanan.

Praktik terbaik:

Menyediakan alternatif lain untuk membuat kunci akun layanan.
Menggunakan batasan kebijakan organisasi untuk membatasi project mana yang dapat membuat kunci akun layanan.
Tidak meninggalkan kunci akun layanan di lokasi sementara.
Tidak meneruskan kunci akun layanan antar-pengguna.
Tidak mengirimkan kunci akun layanan ke repositori kode sumber.
Tidak menyematkan kunci akun layanan dalam biner program.
Menggunakan insight dan metrik untuk mengidentifikasi kunci akun layanan yang tidak digunakan.
Merotasikan kunci akun layanan untuk mengurangi risiko keamanan yang disebabkan oleh kebocoran kunci.
Menggunakan expiry times untuk mengakhiri masa berlaku kunci secara otomatis.
Menggunakan batasan kebijakan organisasi untuk menonaktifkan kunci yang bocor secara otomatis.

Menyediakan alternatif untuk membuat kunci akun layanan

Pastikan pengguna di organisasi Anda mengetahui berbagai alternatif dan dapat menjustifikasi resiko tambahan dan mengelola biaya overhead dari penggunaan kunci akun layanan:

  • Berikan edukasi kepada developer Anda tentang alternatif yang lebih aman untuk kunci akun layanan.
  • Tetapkan proses untuk membantu developer memutuskan metode autentikasi yang sesuai untuk kasus penggunaan mereka sebelum membuat kunci akun layanan baru.
  • Gunakan batasan kebijakan organisasi untuk mencegah pembuatan kunci akun layanan baru, dan izinkan pengecualian hanya untuk project yang telah menunjukkan bahwa project tersebut tidak dapat menggunakan alternatif yang lebih aman.

Menggunakan batasan kebijakan organisasi untuk membatasi project yang dapat membuat kunci akun layanan

Dengan adanya alternatif yang lebih aman untuk kunci akun layanan, sebaiknya pertimbangkan penggunaan kunci akun layanan sebagai pengecualian, bukan sebagai standar.

Untuk mencegah penggunaan kunci akun layanan yang tidak perlu, gunakan batasan kebijakan organisasi:

Mengubah batasan kebijakan organisasi memerlukan izin orgpolicy.policy.set. Karena baik peran Pemilik (roles/owner) maupun Editor (roles/editor) tidak menyertakan izin ini, batasan juga dapat berlaku di lingkungan non-produksi yang mana beberapa akun utama mungkin memiliki akses Pemilik atau Editor proyek.

Jangan meninggalkan kunci akun layanan di lokasi sementara

Saat Anda membuat kunci akun layanan menggunakan Konsol Google Cloud, kebanyakan browser akan langsung mendownload kunci baru tersebut dan menyimpannya di folder download di komputer Anda. Anda harus segera memindahkan kunci ke lokasi tempat Anda ingin menyimpannya. Pastikan tidak ada salinan yang tertinggal di folder download atau recycle bin komputer Anda secara tidak sengaja.

Anda dapat mengurangi risiko salinan kunci akun layanan yang tidak sengaja tertinggal di lokasi sementara dengan menggunakan Google Cloud CLI: Perintah gcloud iam service-accounts keys create memungkinkan Anda menulis layanan file kunci akun langsung ke lokasi tempat Anda membutuhkannya. Selain itu, pada sebagian besar sistem operasi, gcloud CLI secara otomatis menyesuaikan izin file sehingga hanya Anda yang dapat mengakses file tersebut.

Jangan meneruskan kunci akun layanan antar-pengguna

Saat men-deploy aplikasi yang memerlukan kunci akun layanan, Anda mungkin tidak memiliki izin untuk membuat kunci akun layanan sendiri. Sebagai gantinya, Anda mungkin harus meminta orang lain untuk membuat kunci akun layanan untuk Anda.

Dalam skenario ketika beberapa pengguna terlibat dalam pembuatan dan deployment kunci akun layanan, ada peningkatan risiko bahwa salinan kunci tetap berada di kotak surat, histori chat, atau lokasi lainnya. Setiap kali pengalihan antar pengguna diperlukan, mengupload kunci akun layanan akan lebih aman:

  1. Saat pengguna men-deploy aplikasi, buat sertifikat yang ditandatangani sendiri menggunakan pasangan kunci RSA 2048-bit pada mesin target. Untuk membuat sertifikat, Anda dapat menggunakan openssl, certutil, New-SelfSignedCertificate, atau alat sistem operasi lainnya.
  2. Teruskan file sertifikat ke pengguna yang memiliki izin untuk mengupload sertifikat dengan tetap mempertahankan kunci pribadi di komputer target. Saat meneruskan sertifikat, pastikan sertifikat tersebut tidak dapat diganti atau dirusak, tetapi Anda tidak perlu merahasiakannya.
  3. Sebagai pengguna yang memiliki izin yang diperlukan untuk mengelola kunci akun layanan, upload sertifikat untuk mengaitkannya dengan akun layanan.

Dengan mengikuti proses ini, Anda tidak akan meneruskan kunci pribadi dan hanya bertukar informasi publik antar-pengguna.

Jangan kirimkan kunci akun layanan ke repositori kode sumber

Kunci akun layanan adalah kredensial, dan harus dilindungi dari akses yang tidak sah. Jika Anda mengirimkan kunci akun layanan ke repositori kode sumber, ada peningkatan risiko bahwa kunci menjadi dapat diakses oleh pengguna yang tidak sah dan pihak tidak bertanggung jawab:

  • Pihak tidak bertanggung jawab dapat memindai kode sumber repositori sumber publik untuk menemukan kunci yang bocor.
  • Di masa mendatang, Anda dapat memutuskan untuk mengubah repositori sumber pribadi menjadi repositori publik, tanpa memeriksanya untuk kunci terlebih dahulu.
  • Anggota tim lain mungkin menyimpan salinan kode sumber di workstation mereka.

Saat Anda mengerjakan kode yang menggunakan kunci akun layanan, selalu simpan kunci akun layanan terpisah dari kode sumber untuk mengurangi risiko pengiriman kunci secara tidak sengaja ke repositori sumber. Dalam banyak kasus, Anda dapat mengurangi risiko ini lebih lanjut dengan tidak menggunakan kunci akun layanan sama sekali selama pengembangan dan menggunakan kredensial pribadi, bukan kunci akun layanan.

Selain itu, siapkan sistem kontrol sumber untuk mendeteksi pengiriman kunci akun layanan yang tidak disengaja:

Tidak Menyematkan kunci akun layanan dalam biner program

Kunci akun layanan adalah string yang cocok dengan pola tertentu, dan dapat diidentifikasi meskipun disematkan dalam file atau biner lain. Jika pihak tidak bertanggung jawab memiliki akses ke biner, mereka dapat mengekstrak kunci akun layanan yang disematkan dalam biner.

Biner program untuk aplikasi sisi server mungkin dihosting di repositori artefak atau dapat disalin ke workstation developer untuk tujuan proses debug. Memisahkan kunci akun layanan dari biner program membantu memastikan bahwa pengguna yang dapat mengakses biner tidak secara implisit mendapatkan akses ke kredensial akun layanan.

  • Untuk aplikasi sisi klien, seperti alat, program desktop, atau aplikasi seluler, jangan gunakan akun layanan. Sebagai gantinya, izinkan pengguna melakukan autentikasi dengan kredensialnya sendiri dengan menggunakan alur izin OAuth.
  • Untuk aplikasi sisi server, jangan sematkan kunci akun layanan ke dalam biner. Sebagai gantinya, pisahkan kunci dari biner aplikasi.

Gunakan insight dan metrik untuk mengidentifikasi kunci akun layanan yang tidak digunakan

Untuk meminimalkan jumlah kunci akun layanan valid yang beredar, sebaiknya nonaktifkan kunci segera setelah tidak diperlukan lagi, lalu hapus kunci tersebut jika Anda yakin kunci tersebut tidak lagi diperlukan. Jika tidak yakin apakah kunci masih digunakan atau tidak, Anda dapat menggunakan insight akun layanan dan metrik autentikasi:

Karena akun layanan termasuk dalam project Google Cloud, insight dan metrik harus dilacak satu per satu untuk setiap project.

Merotasikan kunci akun layanan untuk mengurangi risiko keamanan yang disebabkan oleh kebocoran kunci.

Meskipun Anda dapat mengurangi kemungkinan kebocoran kunci akun layanan secara tidak sengaja, akan sulit untuk menghilangkan risiko tersebut sepenuhnya.

Rotasi kunci adalah proses mengganti kunci Anda yang ada dengan kunci baru, kemudian membatalkan validasi kunci yang lama. Sebaiknya Anda secara rutin merotasi semua kunci yang Anda kelola, termasuk kunci akun layanan.

Merotasi kunci akun layanan dapat membantu mengurangi risiko yang disebabkan oleh kunci yang bocor atau dicuri. Jika kunci bocor, pihak tidak bertanggung jawab mungkin memerlukan waktu berhari-hari atau berminggu-minggu untuk menemukan kuncinya. Jika Anda merotasi kunci akun layanan Anda secara teratur, kemungkinan besar kunci yang bocor akan menjadi tidak valid saat pihak tidak bertanggung jawab mendapatkannya.

Memiliki proses yang telah ditetapkan untuk merotasi kunci akun layanan juga membantu Anda bertindak cepat jika Anda mencurigai bahwa kunci akun layanan telah disusupi.

Jika Anda membuat pasangan kunci publik/pribadi sendiri, menyimpan kunci pribadi dalam modul keamanan hardware (HSM), dan mengupload kunci publik ke Google, maka Anda mungkin tidak perlu merotasi kunci secara teratur. Sebagai gantinya, Anda dapat merotasi kunci jika yakin bahwa kunci mungkin telah disusupi.

Menggunakan expiry times untuk mengakhiri masa berlaku kunci secara otomatis.

Secara default, kunci akun layanan yang Anda buat dan download dari IAM tidak memiliki masa berlaku dan akan tetap valid hingga Anda menghapusnya. Menetapkan expiry time untuk kunci akun layanan dapat membatasi risiko keamanan Anda dengan mengurangi masa pakai kredensial persisten. Namun, ada risiko lain yang terkait dengan penetapan expiry times; misalnya, menetapkan expiry times dapat menyebabkan beban kerja gagal saat masa berlaku kunci berakhir.

Gunakan expiry times saat Anda memerlukan akses sementara ke sistem yang memerlukan kunci akun layanan. Misalnya, gunakan expiry time jika Anda melakukan hal berikut:

  • Mengembangkan kode dalam lingkungan non-produksi untuk aplikasi yang hanya dapat melakukan autentikasi dengan kunci akun layanan
  • Menggunakan alat pihak ketiga yang hanya dapat mengautentikasi dengan kunci akun layanan

Hindari penggunaan expiry time untuk skenario berikut:

  • Workload produksi. Dalam proses produksi, kunci akun layanan yang sudah tidak berlaku dapat menyebabkan penghentian yang tidak disengaja. Sebagai gantinya, gunakan kunci yang tidak memiliki masa berlaku dan kelola siklus prosesnya dengan rotasi kunci.
  • Workload non-produksi yang memerlukan akses permanen, seperti pipeline continuous integration (CI).
  • Sistem rotasi kunci yang mencegah kunci digunakan setelah jangka waktu tertentu. Untuk mempelajari strategi rotasi kunci yang direkomendasikan, lihat Rotasi kunci akun layanan.

Untuk membatasi validitas kunci akun layanan, Anda dapat mengonfigurasi expiry time untuk kunci yang baru dibuat di project, folder, atau organisasi Anda. expiry time tidak berlaku untuk kunci yang ada.

Atau, Anda dapat mengupload kunci akun layanan dan menentukan tanggal Valid To di file sertifikat X.509. Setelah tanggal habis masa berlaku berlalu, kunci tidak dapat digunakan untuk autentikasi. Namun, layanan tetap terkait dengan akun layanan sampai Anda menghapusnya.

Menggunakan batasan kebijakan organisasi untuk menonaktifkan kunci yang bocor secara otomatis

Meskipun Anda mengikuti semua praktik terbaik untuk kunci akun layanan, kunci akun layanan Anda mungkin bocor.

Untuk membantu mengelola kredensial yang bocor, pastikan Batasan Respon Eksposur Kunci Akun Layanan ditetapkan ke DISABLE_KEY. Jika Anda menetapkan batasan ke nilai ini, Google Cloud akan otomatis menonaktifkan kunci yang bocor yang terdeteksi.

Jika kunci dinonaktifkan karena bocor, kolom berikut akan ditambahkan ke metadata kunci:

  • "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": menunjukkan bahwa kunci dinonaktifkan karena terekspos.
  • "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED"": menunjukkan bahwa kunci pernah diekspos secara publik. Nilai ini tetap ada meskipun Anda mengaktifkan kembali kunci.
  • "extended_status_message": "LINK_TO_EXPOSURE": jika tersedia, metadata berisi link ke tempat kunci terdeteksi, yang dapat Anda gunakan untuk perbaikan.

Kunci ini dapat diaktifkan kembali jika diperlukan untuk memitigasi pemadaman layanan. Namun, sebaiknya nonaktifkan kembali sesegera mungkin, karena kunci yang diekspos secara publik menimbulkan risiko keamanan, meskipun eksposur awal telah dihapus.

Untuk mempelajari praktik terbaik lainnya dalam mengelola kredensial yang disusupi, lihat Menangani kredensial Google Cloud yang disusupi.

Melindungi dari eskalasi akses

Menggunakan kunci akun layanan dapat menyebabkan Anda terkena serangan eskalasi hak istimewa jika kunci tersebut kurang aman dibandingkan dengan resource yang aksesnya mereka berikan.

Misalnya, pihak tidak bertanggung jawab telah menguasai lingkungan Anda dan sekarang mencoba mengakses resource Google Cloud tertentu. Mereka mungkin masih tidak memiliki izin untuk mengakses resource ini, tetapi hak istimewa mereka mungkin hanya cukup untuk mengakses kunci akun layanan yang disimpan di VM, fileshare, atau lokasi lainnya yang kurang aman. Dengan mengautentikasi menggunakan kunci akun layanan, pihak tidak bertanggung jawab dapat mengambil identitas akun layanan. Akun layanan mungkin mengizinkan pihak tidak bertanggung jawab mengakses resource yang sebelumnya tidak dapat mereka akses, sehingga mengeskalasikan hak istimewa pihak tidak bertanggung jawab.

Karena kunci akun layanan secara tidak langsung memberikan akses ke resource di Google Cloud, Anda harus menganggap kunci itu sama berharganya, dan sama berharganya untuk dilindungi, seperti halnya resource itu sendiri.

Bagian berikut menjelaskan praktik terbaik untuk melindungi kunci akun layanan dan mengurangi risiko akses tidak sah serta eskalasi hak istimewa yang dihasilkan.

Praktik terbaik:

Menghindari menyimpan kunci di sistem file.
Menggunakan HSM atau TPM untuk menyimpan kunci.
Menggunakan penyimpanan kunci berbasis software.
Tidak menyimpan kunci di Secret Manager atau penyimpanan rahasia berbasis cloud lainnya.
Tidak menggunakan peran Editor dalam project yang mengizinkan pembuatan atau upload kunci akun layanan.
Menghindari penggunaan kunci akun layanan untuk delegasi seluruh domain.

Menghindari menyimpan kunci pada sistem file

Kunci akun layanan yang dibuat menggunakan Konsol Google Cloud atau gcloud CLI berupa file JSON, dan Anda dapat menyalin file ini ke sistem file mesin tempat file tersebut diperlukan. Namun, menyimpan kunci akun layanan sebagai file pada sistem file dapat menyebabkan beberapa risiko, termasuk:

  • Beberapa sistem file seperti NTFS menggunakan izin yang diwariskan secara default. Kecuali jika dinonaktifkan, izin yang ditambahkan ke folder induk mungkin secara tidak sengaja menyebabkan file kunci menjadi lebih mudah diakses dan terlihat oleh pengguna yang tidak sah.
  • Dalam lingkungan tervirtualisasi, pihak tidak bertanggung jawab mungkin dapat merusak keamanan sistem file dengan mengakses disk virtual yang mendasarinya.
  • Akses sistem file dan perubahan izin sering kali tidak dicatat dalam log audit. Jika izin file berubah secara tidak sengaja dan kunci menjadi terlihat oleh pengguna yang tidak berwenang, mungkin akan sulit untuk menganalisis kapan dan oleh siapa perubahan ini dilakukan.
  • File dapat dengan mudah disalin sehingga dapat dieksfiltrasi jika ada pihak tidak bertanggung jawab yang mendapatkan akses.

Bila memungkinkan, hindari menyimpan kunci akun layanan di sistem file. Jika Anda tidak dapat menghindari penyimpanan kunci di disk, pastikan untuk membatasi akses ke file kunci, mengonfigurasi pengauditan akses file, dan mengenkripsi disk yang mendasarinya.

Menggunakan HSM atau TPM untuk menyimpan kunci

Saat Anda membuat kunci akun layanan menggunakan Konsol Google Cloud atau gcloud CLI, kunci pribadi akan dibuat oleh Google Cloud dan ditampilkan kepada Anda. Banyak risiko keamanan yang terkait dengan kunci akun layanan berasal dari fakta bahwa kunci pribadi, untuk sementara atau permanen, tersedia dalam teks yang jelas dan oleh karena itu sulit dilindungi.

Daripada mengizinkan Google Cloud membuat pasangan kunci, Anda dapat menggunakan modul keamanan hardware (HSM) atau Trusted Platform Module (TPM) untuk membuat dan mengelola kunci:

  1. Menggunakan HSM atau TPM untuk membuat pasangan kunci RSA.
  2. Menggunakan pasangan kunci untuk membuat sertifikat yang ditandatangani sendiri.
  3. Mengupload sertifikat sebagai kunci akun layanan.
  4. Mengizinkan aplikasi menggunakan API ditandatangani HSM atau TPM untuk mengisi JWT guna mengautentikasi akun layanan.

HSM atau TPM memungkinkan Anda menggunakan kunci pribadi tanpa pernah mengungkapkan kunci dalam teks yang jelas. Dengan menggunakan HSM atau TPM untuk mengelola kunci akun layanan Anda dapat menerapkan kontrol akses sekaligus mengurangi risiko kunci disalin ke sistem lain.

Beberapa platform menyediakan abstraksi yang memungkinkan Anda memanfaatkan TPM tanpa harus berinteraksi langsung dengannya. Misalnya, Windows memungkinkan Anda mengelola kunci yang dilindungi TPM menggunakan CryptoNG API yang dikombinasikan dengan Microsoft Platform Crypto Provider.

Kunci akun layanan yang dikelola TPM bersifat unik untuk mesin fisik atau virtual. Anda tetap dapat mengizinkan beberapa mesin untuk berbagi akun layanan dengan mengaitkan kunci setiap mesin dengan akun layanan yang sama.

Menggunakan penyimpanan kunci berbasis software

Dalam situasi ketika penggunaan penyimpanan kunci berbasis hardware tidak memungkinkan, gunakan penyimpanan kunci berbasis software untuk mengelola kunci akun layanan. Seperti opsi berbasis hardware, kunci berbasis software memungkinkan pengguna atau aplikasi menggunakan kunci akun layanan tanpa mengungkapkan kunci pribadi. Solusi penyimpanan kunci berbasis software dapat membantu Anda mengontrol akses kunci secara terperinci dan juga dapat memastikan bahwa setiap akses kunci dicatat ke dalam log.

Keamanan penyimpanan kunci berbasis software biasanya tergantung pada cara perlindungan kunci masternya. Sebelum Anda menggunakan key store berbasis software, pastikan untuk meninjau:

  • bagaimana kunci master diamankan saat diam,
  • bagaimana proses penyegelan, dan siapa yang dapat memulainya,
  • bagaimana kunci dilindungi agar tidak diekstrak dari memori,
  • bagaimana penyimpanan kunci dilindungi agar tidak dirusak jika pihak tidak bertanggung jawab mendapatkan akses shell atau akses hypervisor ke sistem pokok.

Tidak menyimpan kunci di Secret Manager atau penyimpanan rahasia berbasis cloud lainnya

Sebaiknya tidak menggunakan Secret Manager Google Cloud untuk menyimpan dan merotasi kunci akun layanan. Hal ini karena, untuk mengakses secret dari Secret Manager, aplikasi Anda memerlukan identitas yang dapat dikenali oleh Google Cloud. Jika aplikasi Anda sudah memiliki identitas yang dapat dikenali Google Cloud, maka aplikasi Anda dapat menggunakan identitas tersebut untuk melakukan autentikasi ke Google Cloud, bukan menggunakan kunci akun layanan.

Konsep yang sama berlaku untuk layanan pengelolaan rahasia berbasis cloud lainnya, seperti Azure KeyVault dan AWS Secret Manager. Jika sudah memiliki identitas yang dapat dikenali oleh penyedia cloud, aplikasi Anda akan dapat menggunakan identitas tersebut untuk melakukan autentikasi ke Google Cloud, bukan menggunakan kunci akun layanan.

Jangan gunakan peran Editor dalam project yang mengizinkan pembuatan atau upload kunci akun layanan

Perbedaan utama antara peran dasar Editor (roles/editor) dan Pemilik (roles/owner) adalah bahwa peran Editor tidak mengizinkan Anda mengubah kebijakan atau peran IAM. Dengan peran Editor, Anda tidak dapat memperluas akses Anda sendiri atau memberi pengguna lain akses ke resource project dengan mudah.

Batasan peran Editor dapat dirusak jika project berisi akun layanan. Karena peran Editor memberikan izin untuk membuat atau mengupload kunci akun layanan, pihak tidak bertanggung jawab dapat membuat kunci baru untuk akun layanan yang sudah ada dan menggunakan kunci ini untuk mengeskalasi akses mereka sendiri, atau untuk menyerahkan kunci kepada pihak lain untuk memperoleh akses ke resource proyek.

Daripada menggunakan peran Editor, atau peran dasar lainnya, sebaiknya gunakan peran bawaan yang lebih sempit, atau buat peran khusus yang hanya memberikan izin yang diperlukan.

Jika Anda perlu menggunakan peran Editor, nonaktifkan upload kunci akun layanan dan pembuatan kunci dengan menggunakan batasan kebijakan organisasi untuk membantu memastikan bahwa peran Editor tidak dapat disalahgunakan untuk eskalasi hak istimewa.

Menghindari penggunaan kunci akun layanan untuk delegasi seluruh domain

Delegasi tingkat domain memungkinkan Anda meniru identitas pengguna sehingga Anda dapat mengakses data pengguna tanpa otorisasi manual apa pun dari pengguna. Meskipun contoh yang mengilustrasikan penggunaan delegasi di seluruh domain biasanya menyarankan penggunaan kunci akun layanan, penggunaan kunci akun layanan tidak diperlukan untuk melakukan delegasi tingkat domain.

Saat menggunakan delegasi seluruh domain, hindari kunci akun layanan dan gunakan signJwt API sebagai gantinya:

  1. Mengautentikasi akun layanan menggunakan akun layanan terlampir, Workload Identity Federation untuk GKE, atau Workload Identity Federation terlebih dahulu.
  2. Membuat JWT dan gunakan klaim sub untuk menentukan alamat email pengguna yang Anda minta akses yang didelegasikan.
  3. Menggunakan signJwt API untuk menandatangani JWT.
  4. Meneruskan JWT yang ditandatangani ke resource Token OAuth2 untuk mendapatkan token akses.

Dengan mengikuti pendekatan ini, Anda tidak perlu mengelola kunci akun layanan, sehingga penyiapan dapat lebih aman dengan lebih mudah.

Melindungi dari ancaman pengungkapan informasi

Praktik terbaik:

Menghindari pengungkapan informasi rahasia di sertifikat X.509 yang diupload.

Menghindari pengungkapan informasi rahasia di sertifikat X.509 yang diupload

Untuk setiap kunci akun layanan, IAM memungkinkan Anda mendownload sertifikat X.509 dari endpoint https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL. Endpoint ini bersifat publik dan tidak memerlukan autentikasi.

Untuk kunci yang dikelola Google dan kunci yang dikelola pengguna yang Anda buat menggunakan Konsol Google Cloud atau gcloud CLI, sertifikat X.509 dibuat secara otomatis dan hanya berisi metadata dasar seperti alamat email dan tanggal habis masa berlaku.

Untuk kunci akun layanan yang diupload, sertifikat X.509 yang diberikan oleh endpoint publik adalah sertifikat yang sama dengan yang Anda upload. Jika sertifikat yang Anda upload berisi atribut opsional (seperti informasi alamat atau lokasi yang disematkan dalam nama umum), informasi ini juga akan dapat diakses secara publik. Pihak tidak bertanggung jawab dapat menggunakan informasi ini untuk mempelajari lingkungan Anda lebih lanjut.

Untuk menghindari pengungkapan informasi rahasia, jangan tambahkan atribut opsional ke sertifikat X.509 yang diupload dan gunakan Subject generik.

Melindungi dari ancaman non-repudiasi

Jika Anda melihat aktivitas mencurigakan yang memengaruhi resource Google Cloud dan ingin menganalisis asalnya, Anda memerlukan data yang dapat digunakan untuk merekonstruksi rantai peristiwa yang mengarah ke aktivitas mencurigakan. Sumber utama data untuk melakukan analisis tersebut biasanya adalah log audit.

Menganalisis log audit dapat menjadi lebih sulit jika akun layanan terlibat: jika suatu aktivitas diinisiasi oleh akun layanan, entri log akan berisi alamat email akun layanan, tetapi Anda juga perlu mencari tahu pengguna atau aplikasi mana yang menggunakan akun layanan pada saat itu.

Bagian berikut berisi praktik terbaik untuk menggunakan kunci akun layanan dengan cara yang membantu Anda melacak penggunaannya.

Praktik terbaik:

Menggunakan akun layanan khusus untuk setiap aplikasi.
Menggunakan kunci khusus untuk setiap mesin yang menjalankan aplikasi.

Menggunakan akun layanan khusus untuk setiap aplikasi

Semua catatan log audit berisi kolom principalEmail yang mengidentifikasi akun utama yang memulai aktivitas. Jika Anda membagikan kunci akun layanan ke beberapa aplikasi, akan sulit untuk mengidentifikasi aplikasi mana yang melakukan aktivitas karena catatan log audit berisi nilai principalEmail yang sama.

Daripada membagikan kunci ke beberapa aplikasi, buatlah akun layanan khusus untuk setiap aplikasi. Dengan demikian, kolom principalEmail memungkinkan Anda mengidentifikasi aplikasi yang terkait dengan akun layanan yang dapat membantu Anda merekonstruksi rantai peristiwa yang mengarah ke aktivitas mencurigakan.

Menggunakan kunci khusus untuk setiap mesin yang menjalankan aplikasi

Jika Anda menjalankan beberapa salinan aplikasi yang sama di beberapa mesin, kolom principalEmail mungkin memungkinkan Anda mengidentifikasi aplikasi, tetapi bukan mesin tempat aktivitas tertentu berasal.

Untuk membantu Anda mempersempit potensi sumber aktivitas yang mencurigakan, buat kunci individual untuk setiap salinan aplikasi. Dengan begitu, Anda dapat menggunakan kolom serviceAccountKeyName yang ditambahkan oleh banyak layanan ke data log audit untuk membedakan mesin tempat aktivitas berasal.

Langkah selanjutnya