Halaman ini diterjemahkan oleh Cloud Translation API.

Bermigrasi dari kunci akun layanan

Kunci akun layanan biasanya digunakan untuk melakukan autentikasi ke layanan Google Cloud. Namun, kredensial juga dapat menjadi risiko keamanan jika tidak dikelola dengan benar, sehingga meningkatkan kerentanan Anda terhadap ancaman seperti kebocoran kredensial, eskalasi hak istimewa, pengungkapan informasi, dan non-penolakan.

Dalam banyak kasus, Anda dapat mengautentikasi dengan alternatif yang lebih aman untuk kunci akun layanan. Panduan ini membantu Anda bermigrasi dari penggunaan kunci akun layanan sebagai mekanisme autentikasi utama ke penggunaan alternatif yang lebih aman, dengan pengecualian sesekali jika kunci akun layanan benar-benar diperlukan.

Dokumen ini ditujukan untuk administrator keamanan yang ingin meningkatkan postur keamanan mereka dengan mengurangi penggunaan kunci akun layanan dan memilih mekanisme autentikasi yang lebih aman. Administrator keamanan ini mungkin bertanggung jawab atas keamanan beban kerja produksi yang ada, alur kerja developer, dan proses internal yang menggunakan kunci akun layanan.

Ringkasan

Menghapus kunci akun layanan dari workload yang ada memerlukan perencanaan yang cermat untuk mencegah gangguan yang tidak disengaja. Rencana migrasi berikut dirancang untuk memungkinkan Anda menerapkan kontrol terpusat sekaligus meminimalkan gangguan bagi developer.

Rencana migrasi ini mencakup tiga fase:

Menilai: Pada fase ini, Anda menilai lingkungan yang ada untuk memahami lokasi kunci akun layanan dan apakah kunci tersebut sedang digunakan.
Merencanakan: Pada fase ini, Anda memutuskan kontrol mana yang pada akhirnya akan di-deploy dan menyampaikan rencana migrasi kepada pemangku kepentingan.
Deploy: Pada fase ini, Anda mulai memfaktorkan ulang beban kerja untuk mengautentikasi dengan alternatif yang lebih aman untuk kunci akun layanan. Anda juga mengembangkan kemampuan tambahan untuk terus memantau lingkungan dan memitigasi risiko di masa mendatang.

Menilai penggunaan kunci akun layanan

Pada fase ini, Anda akan menilai lingkungan yang ada untuk memahami tempat kunci akun layanan berada dan apakah kunci tersebut sedang digunakan.

Bagian berikut menjelaskan data yang dapat Anda kumpulkan untuk lebih memahami cara kunci akun layanan digunakan di organisasi Anda.

Mengumpulkan data tentang penggunaan kunci

Pertama, identifikasi tempat kunci akun layanan berada dan cara penggunaannya.

Google Cloud menyediakan alat untuk memahami penggunaan akun layanan. Alat ini membantu Anda menentukan akun layanan dan kunci yang baru-baru ini digunakan untuk melakukan autentikasi, akun layanan mana yang belum digunakan dalam 90 hari terakhir, dan akun layanan mana yang memiliki peran yang terlalu istimewa.

Anda dapat menggabungkan informasi dari semua alat ini untuk mendapatkan gambaran yang lebih baik tentang cara akun layanan dan kunci digunakan di seluruh organisasi Anda. Untuk contoh cara menggabungkan informasi dari berbagai sumber ini di seluruh organisasi, lihat arsitektur referensi yang dapat di-deploy di GitHub. Arsitektur referensi ini menggabungkan data dari berbagai alat dan mengekspornya secara rutin ke tabel BigQuery untuk analisis.

Arsitektur referensi men-deploy pipeline data yang mengkueri Inventaris Aset Cloud untuk mengidentifikasi kunci akun layanan di organisasi Anda. Kemudian, pipeline data menggabungkan data tersebut dengan data tentang penggunaan kunci dan penggunaan izin untuk akun terkait. Tabel yang dihasilkan, sa_key_usage, membantu Anda menjawab pertanyaan seperti berikut:

Berapa banyak kunci persisten yang telah dibuat? Angka ini dapat berguna sebagai metrik tingkat tinggi untuk melacak progres saat Anda bermigrasi dari kunci.
Project dan akun layanan mana yang menggunakan kunci? Informasi ini membantu Anda mengidentifikasi pemilik workload yang menggunakan kunci akun layanan.
Manakah kunci yang tidak aktif? Anda mungkin dapat menghapus kunci ini tanpa penilaian lebih lanjut dari pemilik beban kerja.
Kunci mana yang terkait dengan akun layanan yang memiliki rekomendasi tentang izin berlebih? Jika kunci akun layanan dikaitkan dengan akun layanan yang memiliki hak istimewa yang berlebihan, terutama akun dengan peran Pemilik, Editor, atau Pelihat, kunci tersebut mungkin berisiko tinggi. Mencari akun layanan yang memiliki rekomendasi peran dapat membantu Anda mengidentifikasi akun layanan mana yang memiliki hak istimewa yang berlebihan. Setelah mengidentifikasi akun layanan ini, Anda dapat memutuskan untuk memprioritaskan workload ini untuk migrasi. Anda juga dapat memilih untuk menerapkan rekomendasi peran guna mengurangi izin berlebih secara proaktif.

Pipeline data ini berjalan setiap hari dan menulis ke tabel BigQuery berpartisi tanggal. Anda dapat menggunakan tabel ini untuk menyelidiki akun layanan atau kunci tertentu, atau melacak progres perbaikan menggunakan alat dasbor seperti Looker Studio.

Memperkaya data penggunaan kunci dengan konteks tambahan

Setelah membuat set data penggunaan kunci, Anda dapat memperluasnya dengan sumber data tambahan. Sebaiknya tambahkan sumber data yang sudah Anda gunakan untuk melacak tata kelola dan asal resource. Bergantung pada tata kelola yang ada, Anda dapat menambahkan data tambahan seperti berikut:

Informasi kepemilikan dari database pengelolaan konfigurasi (CMDB) atau sistem serupa.
Informasi tata kelola yang dikonfigurasi di label project, seperti tim atau pusat biaya yang bertanggung jawab atas project.
Informasi lingkungan tentang kunci yang digunakan untuk workload di lingkungan yang bersifat eksternal terhadap Google Cloud.

Membuat rencana untuk mengurangi penggunaan kunci akun layanan

Sebelum dapat men-deploy perubahan apa pun untuk mengurangi penggunaan kunci akun layanan, Anda perlu menentukan beban kerja dan lingkungan mana yang akan terpengaruh dan cara Anda menerapkan perubahan tersebut. Anda juga perlu menyampaikan rencana ini di seluruh bisnis dan memastikan bahwa pemilik beban kerja mendukung rencana tersebut.

Bagian berikut memperkenalkan topik utama yang harus ditangani dalam rencana Anda. Rencana khusus Anda akan bervariasi berdasarkan ukuran organisasi dan persyaratan khusus beban kerja Anda.

Menentukan tanggung jawab pemilik beban kerja saat ini

Meskipun tim keamanan pusat dapat menilai kunci mana yang ada, migrasi yang berhasil memerlukan upaya dari pemilik beban kerja. Untuk kunci dalam cakupan migrasi, pemilik beban kerja harus menentukan metode autentikasi yang tersedia mana yang akan berfungsi untuk kasus penggunaan mereka, lalu menjalankan migrasi tersebut.

Pertimbangkan cara menyeimbangkan peningkatan pada postur keamanan yang ada dengan upaya yang diperlukan dari pemilik beban kerja. Bagian berikut menjelaskan dua contoh pendekatan: satu pendekatan yang sangat memprioritaskan peningkatan postur keamanan Anda, dan satu pendekatan yang sangat memprioritaskan pengurangan upaya dari pemilik workload. Pendekatan Anda yang sebenarnya mungkin berbeda—misalnya, Anda dapat memutuskan untuk memilih workload mana yang termasuk dalam cakupan satu per satu.

Contoh: Semua workload saat ini dievaluasi untuk migrasi

Salah satu pendekatan yang mungkin adalah menerapkan kontrol kunci akun layanan untuk semua workload yang ada dan mendatang. Hal ini melibatkan langkah-langkah seperti berikut:

Berkolaborasi dengan pemilik beban kerja untuk mengevaluasi penggunaan kunci mereka untuk beban kerja yang ada.
Mewajibkan pemilik workload untuk memigrasikan semua workload yang ada dengan penggunaan kunci, kecuali jika mereka telah diberi pengecualian.
Mencegah semua beban kerja mendatang menggunakan kunci akun layanan, kecuali jika kunci tersebut telah diberi pengecualian.

Pendekatan ini memprioritaskan peningkatan pada postur keamanan yang ada, tetapi memerlukan lebih banyak upaya dari developer dan pemilik beban kerja dalam jangka pendek. Agar berhasil menjalankan rencana seperti ini, Anda harus memiliki komitmen dari pemilik workload untuk berpartisipasi dalam peninjauan dan pemfaktoran ulang workload.

Contoh: Tidak ada workload saat ini yang dievaluasi untuk migrasi

Pendekatan lainnya adalah mengizinkan pengecualian otomatis untuk beban kerja yang ada agar dapat terus menggunakan kunci akun layanan dan hanya menerapkan kontrol baru pada beban kerja mendatang.

Pendekatan ini meningkatkan postur keamanan workload mendatang dan meminimalkan tanggung jawab pemilik workload saat ini. Namun, hal ini tidak meningkatkan postur keamanan beban kerja yang ada.

Mengidentifikasi solusi cepat

Dalam penilaian, Anda mungkin mengidentifikasi kunci yang dapat dihapus dengan aman tanpa upaya perbaikan lebih lanjut dari pemilik beban kerja. Misalnya, jika kunci tidak memiliki aktivitas selama 90 hari, atau terkait dengan resource yang tidak lagi aktif, Anda mungkin dapat menghapusnya dengan aman tanpa perlu bermigrasi ke mekanisme autentikasi yang berbeda.

Buat daftar kunci yang memenuhi kriteria ini. Anda akan menggunakan daftar ini selama fase deployment untuk menghapus kunci yang tidak diperlukan. Sebelum Anda menambahkan kunci ke daftar, pastikan apakah ada kasus penggunaan yang jarang memerlukan kunci akun layanan, seperti akses produksi darurat yang mengandalkan kunci akun layanan.

Merencanakan tempat untuk menerapkan perubahan kebijakan organisasi

Agar berhasil bermigrasi dari penggunaan kunci akun layanan, Anda harus mencegah pembuatan kunci baru. Selama fase deployment, Anda menerapkan batasan kebijakan organisasi iam.disableServiceAccountKeyCreation untuk mencegah pembuatan kunci akun layanan baru.

Meskipun batasan ini tidak mencegah penggunaan kunci yang ada, batasan ini dapat mengganggu workload yang ada yang secara rutin merotasi kuncinya. Sebelum memulai fase deployment, tentukan tempat Anda akan menerapkannya dalam hierarki resource untuk meminimalkan gangguan.

Anda mungkin lebih memilih untuk menerapkan batasan di level project atau folder, bukan di level organisasi. Misalnya, Anda dapat menerapkan batasan pada folder yang digunakan untuk lingkungan pengembangan sebelum men-deploynya ke folder produksi. Atau, di organisasi besar dengan banyak tim, Anda dapat menerapkan batasan pada folder untuk satu tim terlebih dahulu, lalu menerapkan batasan untuk folder tambahan saat memigrasikannya.

Anda dapat menggunakan kebijakan organisasi dengan tag untuk menerapkan kebijakan organisasi secara bersyarat di tingkat project atau folder.

Mendesain proses pengecualian

Meskipun tujuan migrasi ini adalah untuk mengurangi atau menghilangkan penggunaan kunci akun layanan, ada beberapa kasus penggunaan yang sah yang memerlukan kunci akun layanan. Meskipun tidak ada workload yang ada yang memerlukan kunci akun layanan, workload mendatang mungkin akan memerlukannya. Oleh karena itu, Anda harus menentukan proses operasional untuk mengevaluasi dan menyetujui pengecualian untuk kasus penggunaan yang memerlukan kunci akun layanan.

Tentukan proses bagi pemilik beban kerja untuk meminta pengecualian yang memungkinkan beban kerja mereka menggunakan kunci akun layanan. Pastikan pembuat keputusan yang bertanggung jawab untuk memberikan pengecualian memiliki pengetahuan teknis untuk memvalidasi kasus penggunaan, berkonsultasi dengan pemilik beban kerja tentang alternatif yang lebih aman untuk kunci akun layanan yang mungkin lebih sesuai, dan beri tahu pemilik beban kerja tentang praktik terbaik untuk mengelola kunci akun layanan.

Menyampaikan perubahan mendatang kepada pemilik workload

Setelah merancang rencana, Anda perlu mengomunikasikan rencana tersebut dengan jelas di seluruh organisasi dan memastikan bahwa pemangku kepentingan, terutama pimpinan senior, bersedia berkomitmen untuk melakukan migrasi.

Meskipun detail migrasi spesifik akan bervariasi untuk organisasi Anda, pertimbangkan untuk menyertakan topik berikut dalam rencana komunikasi Anda:

Dampak negatif yang dapat ditimbulkan oleh kunci akun layanan yang tidak aman terhadap organisasi, dan motivasi yang mendorong migrasi Anda dari kunci akun layanan.
Kontrol keamanan baru untuk mencegah pembuatan kunci akun layanan dan pengaruhnya terhadap proses yang ada.
Panduan bagi developer untuk mengidentifikasi alternatif yang lebih aman untuk kunci akun layanan.
Proses bagi tim untuk meminta pengecualian guna mengizinkan kunci akun layanan, termasuk frekuensi pengevaluasian ulang pengecualian ini.
Linimasa untuk menerapkan perubahan yang Anda usulkan.

Bekerja samalah dengan pemilik beban kerja untuk meningkatkan kualitas rencana Anda dan memastikannya berfungsi di seluruh organisasi Anda.

Men-deploy kontrol dan memfaktorkan ulang workload

Setelah membuat rencana dan menyampaikannya kepada pemilik beban kerja, Anda dapat mulai bermigrasi dari kunci akun layanan.

Pada fase ini, Anda akan mulai memfaktorkan ulang beban kerja untuk mengautentikasi dengan alternatif yang lebih aman untuk kunci akun layanan. Anda juga akan mengembangkan kemampuan tambahan untuk terus memantau lingkungan dan mengurangi risiko di masa mendatang.

Bagian berikut menjelaskan langkah-langkah yang dapat Anda lakukan untuk memfaktorkan ulang beban kerja dan menghapus kunci dengan gangguan minimal. Anda dapat memilih untuk melakukan langkah-langkah ini dalam urutan apa pun, berdasarkan prioritas dan upaya yang diperlukan untuk organisasi Anda.

Menerapkan kontrol untuk menghentikan pembuatan kunci akun layanan baru

Untuk menghentikan pembuatan kunci akun layanan baru, Anda harus menerapkan batasan kebijakan organisasi iam.disableServiceAccountKeyCreation.

Namun, sebelum menerapkan batasan ini, Anda harus menambahkan tag ke project atau folder yang akan dikecualikan dari kebijakan. Anda dapat mengizinkan pengecualian untuk workload yang ada yang tidak dapat bermigrasi dari kunci akun layanan, atau untuk workload baru yang memiliki alasan yang sah untuk mengautentikasi hanya dengan kunci akun layanan.

Setelah menambahkan tag untuk mengecualikan project dan folder, Anda dapat menetapkan kebijakan organisasi dengan tag untuk menerapkan batasan iam.disableServiceAccountKeyCreation untuk project dan folder yang tidak dikecualikan.

Untuk mencegah pembuatan kunci akun layanan di semua project dan folder yang tidak dikecualikan, lakukan hal berikut:

Pastikan Anda memiliki peran Administrator Tag (roles/resourcemanager.tagAdmin) dan peran Administrator Kebijakan Organisasi (roles/orgpolicy.policyAdmin) di tingkat organisasi. Untuk mempelajari cara memberikan peran di tingkat organisasi, lihat Mengelola akses ke project, folder, dan organisasi.
Di tingkat organisasi, buat kunci tag dan nilai tag yang akan Anda gunakan untuk menentukan apakah resource harus dikecualikan dari kebijakan organisasi. Sebaiknya buat tag dengan kunci disableServiceAccountKeyCreation dan nilai enforced dan not_enforced.

Untuk mempelajari cara membuat kunci tag dan nilai tag, lihat Membuat dan menentukan tag baru.
Lampirkan tag disableServiceAccountKeyCreation ke organisasi dan tetapkan nilainya ke enforced. Semua resource di organisasi mewarisi nilai tag ini, kecuali jika ditimpa dengan nilai tag yang berbeda.

Untuk mempelajari cara melampirkan tag ke resource, lihat Melampirkan tag ke resource.
Untuk setiap project atau folder yang ingin Anda kecualikan dari kebijakan organisasi, lampirkan tag disableServiceAccountKeyCreation dan tetapkan nilainya ke not_enforced. Menetapkan nilai tag untuk project atau folder dengan cara ini akan menggantikan nilai tag yang diwarisi dari organisasi.
Buat kebijakan organisasi yang mencegah pembuatan kunci akun layanan untuk semua resource kecuali resource yang dikecualikan. Kebijakan ini harus memiliki aturan berikut:
- Konfigurasikan batasan iam.disableServiceAccountKeyCreation agar tidak diterapkan pada resource apa pun dengan tag disableServiceAccountKeyCreation: not_enforced. Kondisi dalam aturan ini akan terlihat seperti berikut:
```
"resource.matchTag('ORGANIZATION_ID/disableServiceAccountKeyCreation', 'not_enforced')"
```
- Konfigurasikan batasan iam.disableServiceAccountKeyCreation yang akan diterapkan pada semua resource lainnya.

Memperbaiki workload yang ada

Untuk setiap beban kerja yang menggunakan kunci akun layanan, berkolaborasilah dengan pemilik beban kerja untuk memilih dan menerapkan metode autentikasi alternatif.

Saat Anda mengakses layanan Google Cloud menggunakan Google Cloud CLI, Library Klien Cloud, alat yang mendukung Kredensial Default Aplikasi (ADC) seperti Terraform, atau permintaan 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:

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.
Apakah Anda menjalankan kode di Google Cloud?
1. Jika ya, lanjutkan ke pertanyaan 3.
2. Jika tidak, lanjutkan ke pertanyaan 5.
Apakah Anda menjalankan container di Google Kubernetes Engine atau GKE Enterprise?
1. Jika ya, gunakan workload identity federation untuk GKE untuk melampirkan akun layanan ke pod Kubernetes.
2. Jika tidak, lampirkan akun layanan ke resource.
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.
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.

Dalam beberapa kasus, Anda mungkin tidak dapat menggunakan metode autentikasi selain kunci akun layanan. Contoh saat kunci akun layanan mungkin merupakan satu-satunya opsi yang memungkinkan mencakup hal berikut:

Anda menggunakan produk siap pakai (COTS) komersial atau aplikasi software-as-a-service (SaaS) yang meminta Anda memasukkan kunci akun layanan Google Cloud langsung ke antarmuka penggunanya.
Workload Anda berjalan di luar Google Cloud dan tidak diautentikasi dengan penyedia identitas yang dapat mendukung workload identity federation.

Jika Anda harus terus menggunakan kunci akun layanan, pastikan Anda mengikuti praktik terbaik untuk mengelola kunci akun layanan.

Anda juga dapat memutuskan untuk tidak memperbaiki beban kerja tertentu karena menilai bahwa risiko terus menggunakan kunci akun layanan tidak sebanding dengan biaya beralih ke metode autentikasi yang berbeda.

Menghapus kunci yang tidak diperlukan

Jika yakin bahwa kunci akun layanan tidak diperlukan, Anda harus menghapus kunci tersebut. Kunci yang tidak diperlukan mencakup hal-hal berikut:

Kunci tanpa penggunaan terbaru atau kunci yang terkait dengan resource yang tidak digunakan, yang Anda identifikasi di bagian Mengidentifikasi solusi cepat di halaman ini.
Kunci untuk workload yang telah dimigrasikan ke metode autentikasi lainnya.

Setelah Anda menghapus semua kunci akun layanan dalam project, pastikan batasan iam.disableServiceAccountKeyCreation diterapkan untuk project tersebut. Jika project sebelumnya dikecualikan dari batasan ini, hapus tag yang mengizinkan pengecualian.

Untuk menghapus kunci dengan aman, sebaiknya Anda menonaktifkan kunci sebelum menghapusnya. Penghapusan tidak dapat dibatalkan, tetapi dengan menonaktifkannya, Anda dapat mengaktifkan kembali kunci dengan cepat jika mengidentifikasi masalah yang tidak terduga. Setelah menonaktifkan kunci, tunggu hingga Anda yakin bahwa penghapusan kunci secara permanen tidak akan menyebabkan masalah, lalu hapus kunci. Jika, setelah menonaktifkan kunci, Anda mengidentifikasi masalah yang tidak terduga, aktifkan kembali kunci, selesaikan masalah, lalu ulangi prosesnya hingga Anda dapat menghapus kunci dengan aman.

Menggunakan kontrol bawaan untuk membantu merespons kunci yang bocor

Google Cloud menawarkan beberapa alat dan layanan untuk membantu Anda mendeteksi dan merespons kunci akun layanan yang bocor. Pertimbangkan untuk menggunakan mekanisme berikut untuk membantu Anda merespons kunci akun layanan yang bocor:

Aktifkan deteksi anomali Security Command Center untuk memindai kunci di repositori publik. Pemindaian ini akan membuat temuan account_has_leaked_credentials jika kunci yang bocor terdeteksi.
Tinjau Program Perlindungan terhadap Penambangan Kripto Security Command Center dan pastikan Anda memenuhi prasyarat teknis untuk kelayakan. Penyalahgunaan penambangan mata uang kripto adalah eksploitasi umum jika kredensial bocor.
Konfigurasikan Kontak Penting agar tim keamanan Anda menerima notifikasi keamanan dari Google Cloud, termasuk penyalahgunaan akibat kunci yang disusupi. Pastikan alamat email dipantau dan tidak mengandalkan pengguna perorangan sebagai titik kegagalan tunggal.

Untuk mempelajari manajemen insiden lebih lanjut, lihat Membangun proses manajemen insiden kolaboratif.

Peningkatan berkelanjutan pada pengelolaan akun layanan

Jika memungkinkan, terapkan praktik terbaik untuk mengelola kunci akun layanan. Meningkatkan proses pengelolaan kunci enkripsi dapat membantu meminimalkan risiko kunci akun layanan yang tersisa di organisasi Anda.