Bermigrasi dari kunci akun layanan

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

Dalam banyak kasus, Anda dapat melakukan autentikasi dengan alternatif yang lebih aman untuk kunci akun layanan. Panduan ini membantu Anda bermigrasi dari menggunakan kunci akun layanan sebagai mekanisme autentikasi utama ke penggunaan alternatif yang lebih aman, dengan pengecualian sesekali ketika 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 mengutamakan 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 digunakan.
Merencanakan: Pada fase ini, Anda memutuskan kontrol mana yang pada akhirnya akan di-deploy dan mengomunikasikan rencana migrasi kepada pemangku kepentingan.
Deploy: Pada fase ini, Anda mulai memfaktorkan ulang workload untuk melakukan autentikasi 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 lokasi adanya kunci akun layanan 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 lokasi keberadaan kunci akun layanan 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 mengautentikasi, akun layanan mana yang belum digunakan dalam 90 hari terakhir, dan akun layanan yang memiliki peran dengan hak istimewa yang terlalu tinggi.

Anda dapat menggabungkan informasi dari semua alat ini untuk mendapatkan gambaran yang lebih baik tentang penggunaan akun layanan dan kunci di seluruh organisasi Anda. Untuk mengetahui 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 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 yang terkait. Tabel yang dihasilkan, sa_key_usage, akan 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.
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 dengan hak istimewa yang terlalu tinggi, terutama yang memiliki peran Pemilik, Editor, atau Viewer, kuncinya mungkin sangat berisiko tinggi. Mencari akun layanan yang memiliki rekomendasi peran dapat membantu Anda mengidentifikasi akun layanan mana yang memiliki hak istimewa terlalu tinggi. Setelah mengidentifikasi akun layanan ini, Anda dapat memutuskan untuk memprioritaskan beban kerja ini untuk migrasi. Anda juga dapat memilih untuk menerapkan rekomendasi peran untuk secara proaktif mengurangi izin berlebih.

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 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 lain seperti berikut:

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

Buat rencana untuk mengurangi penggunaan kunci akun layanan

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

Bagian berikut memperkenalkan topik-topik utama yang harus dibahas dalam rencana Anda. Paket khusus Anda akan bervariasi berdasarkan ukuran organisasi dan persyaratan khusus workload 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 workload. Untuk kunci dalam cakupan migrasi, pemilik workload harus menentukan metode autentikasi 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 workload. Bagian berikut menjelaskan dua contoh pendekatan: pendekatan yang sangat memprioritaskan peningkatan pada postingan keamanan, dan pendekatan yang sangat memprioritaskan meminimalkan upaya dari pemilik beban kerja. Pendekatan Anda yang sebenarnya dapat bervariasi. Misalnya, Anda dapat memutuskan untuk memilih beban kerja mana yang berada dalam cakupan satu per satu.

Contoh: Semua beban kerja saat ini akan dievaluasi untuk migrasi

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

Berkolaborasi dengan pemilik workload untuk mengevaluasi penggunaan utama mereka untuk workload 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 beban kerja tersebut telah diberikan pengecualian.

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

Contoh: Tidak ada beban kerja saat ini yang dievaluasi untuk migrasi

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

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

Identifikasi solusi yang cepat

Dalam penilaian, Anda dapat mengidentifikasi kunci yang dapat dihapus dengan aman tanpa pekerjaan 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 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 di mana perubahan kebijakan organisasi diberlakukan

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

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

Anda mungkin memilih untuk menerapkan batasan di awal pada level project atau folder, bukan level organisasi. Misalnya, Anda dapat menerapkan batasan pada folder yang digunakan untuk lingkungan pengembangan sebelum men-deploy-nya ke folder produksi. Atau, dalam 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 sah yang memerlukan kunci akun layanan. Meskipun tidak ada workload yang memerlukan kunci akun layanan, workload di masa mendatang mungkin akan memerlukannya. Oleh karena itu, Anda harus menentukan proses operasional guna mengevaluasi dan menyetujui pengecualian untuk kasus penggunaan yang memerlukan kunci akun layanan.

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

Menyampaikan perubahan mendatang kepada pemilik workload

Setelah merancang rencana, Anda perlu mengomunikasikan rencana tersebut dengan jelas ke seluruh organisasi dan memastikan bahwa pemangku kepentingan, terutama pemimpin senior, bersedia berkomitmen pada 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 bagaimana hal ini dapat memengaruhi 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 seberapa sering pengecualian ini dievaluasi ulang.
Linimasa untuk menerapkan perubahan yang Anda usulkan.

Bekerja samalah dengan pemilik workload untuk mengoptimalkan 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 akan mulai memfaktorkan ulang workload untuk melakukan autentikasi dengan alternatif yang lebih aman bagi kunci akun layanan. Anda juga membangun kemampuan tambahan untuk terus memantau lingkungan dan memitigasi 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 melakukan langkah-langkah ini dalam urutan apa pun, berdasarkan prioritas dan upaya yang diperlukan untuk organisasi Anda.

Terapkan 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 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 sah untuk melakukan autentikasi 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 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 IAM yang diperlukan untuk mengelola tag dan mengelola kebijakan organisasi di tingkat organisasi.
Di tingkat organisasi, buat kunci tag dan nilai tag yang akan Anda gunakan untuk menentukan apakah project atau folder harus dikecualikan dari kebijakan organisasi. Sebaiknya buat tag dengan kunci disableServiceAccountKeyCreation serta 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 ke nilai enforced. Semua project atau folder 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:
- Konfigurasi 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\")
```
- Konfigurasi batasan iam.disableServiceAccountKeyCreation untuk diterapkan di semua resource lainnya.
Untuk mempelajari cara membuat kebijakan organisasi dengan kondisi tag, lihat artikel Menetapkan kebijakan organisasi dengan tag.

Meremediasi workload yang ada

Untuk setiap beban kerja yang menggunakan kunci akun layanan, berkolaborasilah dengan pemilik beban kerja untuk memilih dan mengimplementasikan 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 menambahkan 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.

Pada beberapa kasus, Anda mungkin tidak dapat menggunakan metode autentikasi apa pun selain kunci akun layanan. Contoh kemungkinan kunci akun layanan menjadi satu-satunya opsi yang layak mencakup hal berikut:

Anda menggunakan aplikasi produk siap pakai (COTS) atau software-as-a-service (SaaS) komersial yang meminta Anda untuk 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 tetap harus 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 Anda menilai bahwa risiko untuk terus menggunakan kunci akun layanan bukan merupakan alasan untuk beralih ke metode autentikasi lain.

Hapus kunci yang tidak diperlukan

Jika Anda yakin bahwa kunci akun layanan tidak diperlukan, Anda harus menghapus kunci tersebut. Kunci yang tidak diperlukan meliputi:

Kunci tanpa penggunaan terbaru atau kunci yang terkait dengan resource yang tidak digunakan, yang telah Anda identifikasi di bagian Mengidentifikasi cara cepat pada halaman ini.
Kunci untuk beban kerja yang telah dimigrasikan ke metode autentikasi lain.

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

Untuk menghapus kunci dengan aman, sebaiknya Anda menonaktifkan kunci sebelum menghapusnya. Penghapusan tidak dapat dibatalkan, tetapi menonaktifkannya akan memungkinkan Anda mengaktifkan kembali kunci dengan cepat jika mengidentifikasi masalah yang tidak terduga. Setelah 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, mengaktifkan kembali kunci, menyelesaikan masalah, lalu mengulangi proses hingga Anda dapat menghapus kunci dengan aman.

Gunakan 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 kebocoran kunci akun layanan:

Aktifkan deteksi anomali Security Command Center untuk memindai repositori publik untuk kunci. Pemindaian ini membuat account_has_leaked_credentials menemukan apakah kunci yang bocor terdeteksi.
Tinjau Program Perlindungan Penambangan Kripto Security Command Center dan pastikan Anda memenuhi prasyarat teknis untuk kelayakan. Penyalahgunaan penambangan mata uang kripto adalah eksploitasi yang umum terjadi jika kredensial bocor.
Konfigurasikan Kontak Penting agar tim keamanan Anda dapat menerima notifikasi keamanan dari Google Cloud, termasuk penyalahgunaan yang disebabkan oleh kunci yang disusupi. Pastikan alamat email dipantau dan tidak mengandalkan pengguna individual 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 dapat membantu mengurangi risiko kunci akun layanan yang tersisa di organisasi Anda.