Kunci akun layanan biasanya digunakan untuk melakukan autentikasi ke layananGoogle 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 penyangkalan.
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 bagi administrator keamanan yang ingin meningkatkan postur keamanan mereka dengan mengurangi penggunaan kunci akun layanan dan beralih ke 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 pada developer.
Paket migrasi ini mencakup tiga fase:
- Menilai: Pada fase ini, Anda menilai lingkungan yang ada untuk memahami keberadaan kunci akun layanan dan apakah kunci tersebut sedang digunakan.
- Rencanakan: Pada fase ini, Anda memutuskan kontrol mana yang akan di-deploy pada akhirnya dan mengomunikasikan rencana migrasi kepada para 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 membangun kemampuan tambahan untuk terus memantau lingkungan dan memitigasi risiko di masa mendatang.
Menilai penggunaan kunci akun layanan
Pada fase ini, Anda menilai lingkungan yang ada untuk memahami keberadaan kunci akun layanan dan apakah kunci tersebut sedang digunakan.
Bagian berikut menjelaskan data yang dapat Anda kumpulkan untuk lebih memahami cara penggunaan kunci akun layanan di organisasi Anda.
Mengumpulkan data tentang penggunaan utama
Pertama, identifikasi lokasi kunci akun layanan dan cara penggunaannya.
Google Cloud menyediakan alat untuk memahami penggunaan akun layanan. Alat ini membantu Anda menentukan akun layanan dan kunci mana 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 dengan hak istimewa berlebihan.
Anda dapat menggabungkan informasi dari semua alat ini untuk mendapatkan gambaran yang lebih baik tentang cara penggunaan akun dan kunci layanan di seluruh organisasi Anda. Untuk contoh cara menggabungkan informasi dari berbagai sumber ini di seluruh organisasi Anda, lihat arsitektur referensi yang dapat di-deploy di GitHub. Arsitektur referensi ini menggabungkan data dari berbagai alat dan secara rutin mengekspornya ke tabel BigQuery untuk dianalisis.
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? Jumlah 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.
- Kunci mana yang tidak aktif? Anda kemungkinan dapat menghapus kunci ini tanpa penilaian lebih lanjut dari pemilik workload.
- 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 berlebih, terutama yang memiliki peran Pemilik, Editor, atau Pelihat, kunci tersebut mungkin sangat berisiko. Mencari akun layanan yang memiliki rekomendasi peran dapat membantu Anda mengidentifikasi akun layanan mana yang memiliki hak istimewa berlebih. 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 yang dipartisi menurut tanggal. Anda dapat menggunakan tabel ini untuk menyelidiki akun atau kunci layanan tertentu, atau untuk melacak progres perbaikan menggunakan alat dasbor seperti Data Studio.
Memperkaya data penggunaan kunci dengan konteks tambahan
Setelah mengumpulkan data tentang penggunaan kunci, Anda dapat memperkaya data dengan sumber data tambahan. Sebaiknya tambahkan sumber data yang sudah Anda gunakan untuk melacak tata kelola dan asal-usul resource. Bergantung pada tata kelola yang ada, Anda dapat menambahkan data tambahan seperti berikut:
- Informasi kepemilikan dari database manajemen 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 beban kerja di lingkungan eksternal ke Google Cloud.
Membuat rencana untuk mengurangi penggunaan kunci akun layanan
Sebelum dapat men-deploy perubahan apa pun untuk mengurangi penggunaan kunci akun layanan, Anda harus menentukan beban kerja dan lingkungan yang akan terpengaruh serta cara Anda menerapkan perubahan tersebut. Anda juga perlu mengomunikasikan rencana ini di seluruh bisnis Anda dan memastikan bahwa pemilik workload mendukung rencana tersebut.
Bagian berikut memperkenalkan topik utama yang harus dibahas dalam rencana Anda. Paket spesifik Anda akan bervariasi berdasarkan ukuran organisasi dan persyaratan spesifik workload Anda.
Menentukan tanggung jawab pemilik workload saat ini
Meskipun tim keamanan pusat dapat menilai kunci mana yang ada, migrasi yang berhasil memerlukan upaya dari pemilik workload. Untuk kunci yang termasuk dalam cakupan migrasi, pemilik workload harus menentukan metode autentikasi yang tersedia yang akan berfungsi untuk kasus penggunaan mereka, lalu menjalankan migrasi tersebut.
Pertimbangkan cara menyeimbangkan peningkatan postur keamanan yang ada dengan upaya yang diperlukan dari pemilik workload. Bagian berikut menjelaskan dua contoh pendekatan: satu yang sangat memprioritaskan peningkatan postur keamanan Anda, dan satu yang sangat memprioritaskan meminimalkan upaya dari pemilik workload. Pendekatan Anda yang sebenarnya mungkin berbeda—misalnya, Anda dapat memutuskan untuk memilih workload 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 beban kerja yang ada dan yang akan datang. Hal ini melibatkan langkah-langkah seperti berikut:
- Berkolaborasi dengan pemilik beban kerja untuk mengevaluasi penggunaan utama mereka untuk beban kerja yang ada.
- Mewajibkan pemilik workload memigrasikan semua workload yang ada dengan penggunaan kunci, kecuali jika mereka telah diberikan pengecualian.
- Mencegah semua beban kerja mendatang menggunakan kunci akun layanan, kecuali jika telah diberi pengecualian.
Pendekatan ini memprioritaskan peningkatan 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 mendapatkan komitmen dari pemilik workload untuk berpartisipasi dalam peninjauan dan refactoring workload.
Contoh: Tidak ada workload saat ini yang dievaluasi untuk migrasi
Pendekatan lainnya adalah mengizinkan beban kerja yang ada untuk mendapatkan pengecualian otomatis 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, fitur ini tidak meningkatkan postur keamanan beban kerja yang ada.
Mengidentifikasi solusi cepat
Dalam penilaian, Anda dapat mengidentifikasi kunci yang dapat dihapus dengan aman tanpa pekerjaan perbaikan lebih lanjut dari pemilik workload. 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, konfirmasi 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 mengganti kunci. Sebelum Anda memulai fase deployment, tentukan tempat Anda akan menerapkannya dalam hierarki resource untuk meminimalkan gangguan.
Anda mungkin lebih memilih untuk menerapkan batasan di tingkat project atau folder terlebih dahulu, bukan di tingkat organisasi. Misalnya, Anda dapat menerapkan batasan pada folder yang digunakan untuk lingkungan pengembangan sebelum men-deploy-nya 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 Anda 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 beban kerja yang ada yang memerlukan kunci akun layanan, kemungkinan beban kerja pada masa mendatang 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 workload untuk meminta pengecualian yang memungkinkan workload mereka menggunakan kunci akun layanan. Pastikan pengambil 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 memberi tahu pemilik beban kerja tentang praktik terbaik untuk mengelola kunci akun layanan.
Mengomunikasikan perubahan mendatang kepada pemilik workload
Setelah merancang rencana, Anda harus mengomunikasikan rencana tersebut secara jelas di seluruh organisasi dan memastikan bahwa pemangku kepentingan, terutama para pemimpin 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 pada 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 agar kunci akun layanan diizinkan, termasuk seberapa sering pengecualian ini dievaluasi ulang.
- Linimasa untuk menerapkan perubahan yang Anda usulkan.
Bekerja samalah dengan pemilik workload untuk menyempurnakan rencana Anda dan memastikan rencana tersebut berfungsi di seluruh organisasi Anda.
Men-deploy kontrol dan memfaktorkan ulang workload
Setelah membuat rencana dan mengomunikasikannya kepada pemilik beban kerja, Anda dapat mulai bermigrasi dari kunci akun layanan.
Pada fase ini, Anda mulai memfaktorkan ulang workload untuk mengautentikasi dengan alternatif yang lebih aman untuk kunci akun layanan. Anda juga membangun kemampuan tambahan untuk terus memantau lingkungan dan mengurangi risiko di masa mendatang.
Bagian berikut menjelaskan langkah-langkah yang dapat Anda lakukan untuk memfaktorkan ulang workload 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 menerapkan batasan kebijakan organisasi iam.disableServiceAccountKeyCreation.
Namun, sebelum menerapkan batasan ini, Anda perlu menambahkan tag ke project atau folder yang akan dikecualikan dari kebijakan. Anda dapat mengizinkan pengecualian untuk workload yang ada yang tidak dapat dimigrasikan dari kunci akun layanan, atau untuk workload baru yang memiliki alasan yang sah untuk mengautentikasi hanya dengan kunci akun layanan.
Setelah menambahkan tag ke project dan folder yang dikecualikan, Anda dapat menetapkan kebijakan organisasi dengan tag untuk menerapkan batasan iam.disableServiceAccountKeyCreation bagi 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
disableServiceAccountKeyCreationdan nilaienforceddannot_enforced.Untuk mempelajari cara membuat kunci tag dan nilai tag, lihat Membuat dan menentukan tag baru.
-
Lampirkan tag
disableServiceAccountKeyCreationke organisasi dan tetapkan nilainya keenforced. Semua resource dalam organisasi mewarisi nilai tag ini, kecuali jika diganti 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
disableServiceAccountKeyCreationdan tetapkan nilainya kenot_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:
-
Konfigurasi batasan
iam.disableServiceAccountKeyCreationagar tidak diterapkan pada resource apa pun dengan tagdisableServiceAccountKeyCreation: not_enforced. Kondisi dalam aturan ini akan terlihat seperti berikut:"resource.matchTag('ORGANIZATION_ID/disableServiceAccountKeyCreation', 'not_enforced')" -
Konfigurasi batasan
iam.disableServiceAccountKeyCreationagar diterapkan pada semua resource lainnya.
-
Memperbaiki workload yang ada
Untuk setiap workload yang menggunakan kunci akun layanan, berkolaborasilah dengan pemilik workload untuk memilih dan menerapkan metode autentikasi alternatif.
Saat Anda mengakses Google Cloud layanan 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:
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?
- Jika ya, lanjutkan ke pertanyaan 4.
- Jika tidak, lanjutkan ke pertanyaan 2.
- Apakah Anda menjalankan kode di Google Cloud?
- Jika ya, lanjutkan ke pertanyaan 3.
- Jika tidak, lanjutkan ke pertanyaan 5.
- Apakah Anda menjalankan container di Google Kubernetes Engine?
- Jika ya, gunakan Workload Identity Federation untuk GKE untuk melampirkan akun layanan ke pod Kubernetes.
- 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.
-
Apakah workload Anda diautentikasi dengan penyedia identitas eksternal yang mendukung
workload identity federation?
- Jika ya, konfigurasikan Workload Identity Federation agar aplikasi yang berjalan secara lokal atau di penyedia cloud lain dapat menggunakan akun layanan.
- Jika tidak, buat kunci akun layanan.
Dalam beberapa kasus, Anda mungkin tidak dapat menggunakan metode autentikasi selain kunci akun layanan. Contoh situasi saat kunci akun layanan mungkin menjadi satu-satunya opsi yang layak bagi Anda meliputi:
- Anda menggunakan produk komersial siap pakai (COTS) atau aplikasi software-as-a-service (SaaS) yang meminta Anda memasukkan kunci akun layananGoogle 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 memulihkan beban kerja tertentu karena Anda menilai bahwa risiko terus menggunakan kunci akun layanan tidak sebanding dengan biaya beralih ke metode autentikasi lain.
Menghapus kunci yang tidak perlu
Jika Anda yakin bahwa kunci akun layanan tidak diperlukan, Anda harus menghapus kunci tersebut. Kunci yang tidak perlu mencakup hal-hal berikut:
Kunci yang tidak digunakan baru-baru ini atau kunci yang terkait dengan resource yang tidak digunakan, yang Anda identifikasi di bagian Identifikasi solusi cepat di halaman ini.
Kunci untuk workload yang telah dimigrasikan ke metode autentikasi lain.
Setelah Anda menghapus semua kunci akun layanan dalam project, pastikan batasan
iam.disableServiceAccountKeyCreationditerapkan untuk project tersebut. Jika project sebelumnya dikecualikan dari batasan ini, hapus tag yang memungkinkan pengecualian.
Untuk menghapus kunci dengan aman, sebaiknya nonaktifkan kunci sebelum menghapusnya. Penghapusan tidak dapat dibatalkan, tetapi dengan menonaktifkannya, Anda dapat mengaktifkan kembali kunci dengan cepat jika Anda mengidentifikasi masalah yang tidak terduga. Setelah Anda menonaktifkan kunci, tunggu hingga Anda yakin bahwa menghapus 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 proses hingga Anda dapat menghapus kunci dengan aman.
Menggunakan kontrol bawaan untuk membantu merespons kunci yang bocor
Google Cloud menawarkan alat dan layanan untuk membantu Anda mendeteksi dan merespons kebocoran kunci akun layanan. Pertimbangkan untuk menggunakan mekanisme berikut untuk membantu Anda merespons kunci akun layanan yang bocor:
- Dengan batasan Respons Terhadap Keterbukaan Kunci Akun Layanan, Anda dapat otomatis menonaktifkan kunci yang terekspos yang terdeteksi oleh Google Cloud .
Peningkatan berkelanjutan pada pengelolaan akun layanan
Jika memungkinkan, terapkan praktik terbaik untuk mengelola kunci akun layanan. Meningkatkan proses pengelolaan kunci Anda dapat membantu memitigasi risiko kunci akun layanan yang tersisa di organisasi Anda.
Langkah berikutnya
- Praktik terbaik untuk menggunakan akun layanan
- Praktik terbaik untuk mengelola kunci akun layanan
- Membangun proses manajemen insiden kolaboratif