Halaman ini menguraikan praktik yang direkomendasikan untuk mengonfigurasi enkripsi dalam penyimpanan dengan kunci enkripsi yang dikelola pelanggan (CMEK) di resource Cloud de Confiance Anda. Panduan ini ditujukan untuk arsitek cloud dan tim keamanan serta menguraikan praktik dan keputusan yang direkomendasikan yang harus Anda buat saat mendesain arsitektur CMEK.
Panduan ini mengasumsikan bahwa Anda sudah memahami Cloud Key Management Service (Cloud KMS) dan kunci enkripsi yang dikelola pelanggan.Pilih tempat untuk menggunakan CMEK
Google merekomendasikan agar Anda menggunakan kunci enkripsi yang dikelola pelanggan jika Anda menginginkan batas kriptografi di sekitar data Anda atau pelanggan Anda di cloud. Untuk informasi selengkapnya, lihat Kunci enkripsi yang dikelola pelanggan (CMEK).
Anda dapat menggunakan CMEK di layanan yang kompatibel untuk membantu Anda menerapkan sasaran berikut:Miliki kunci enkripsi Anda.
Kontrol dan kelola kunci enkripsi Anda, termasuk pilihan lokasi, tingkat perlindungan, pembuatan, kontrol akses, rotasi, penggunaan, dan penghancuran.
Buat materi kunci di Cloud KMS atau impor materi kunci yang dikelola di luar Cloud de Confiance.
Tetapkan kebijakan terkait tempat kunci Anda harus digunakan.
Menghapus data yang dilindungi oleh kunci Anda secara selektif jika terjadi penghentian penggunaan atau untuk memulihkan peristiwa keamanan (penghancuran kripto).
Buat dan gunakan kunci yang unik untuk pelanggan, sehingga membuat batas kriptografi di sekitar data Anda.
Mencatat log akses administratif dan akses data ke kunci enkripsi.
Memenuhi peraturan saat ini atau mendatang yang memerlukan salah satu sasaran ini.
Google juga merekomendasikan agar Anda mempertimbangkan framework kepatuhan yang berlaku untuk kebutuhan bisnis Anda. Framework kepatuhan yang berbeda memiliki persyaratan yang berbeda untuk enkripsi dan pengelolaan kunci. Framework kepatuhan biasanya menguraikan prinsip dan tujuan tingkat tinggi pengelolaan kunci enkripsi, tetapi tidak menentukan produk atau konfigurasi tertentu yang mencapai kepatuhan. Anda bertanggung jawab untuk memahami persyaratan framework kepatuhan Anda dan cara kontrol Anda, termasuk pengelolaan kunci, dapat membantu Anda memenuhi persyaratan tersebut.
Untuk mendapatkan panduan tentang cara layanan Cloud de Confiance dapat membantu memenuhi persyaratan berbagai framework kepatuhan, lihat referensi berikut:
Pilih sumber materi utama Anda
Saat membuat kunci, Anda harus mengizinkan Cloud KMS untuk membuat materi kunci untuk Anda atau mengimpor materi kunci secara manual yang dibuat di luar Cloud de ConfianceCloud KMS. Jika memungkinkan, sebaiknya Anda memilih untuk membuat materi kunci di Cloud KMS. Opsi ini tidak berisiko mengekspos materi kunci mentah di luar Cloud KMS dan secara otomatis membuat versi kunci baru berdasarkan periode rotasi kunci yang Anda pilih. Jika Anda harus mengimpor materi kunci Anda sendiri, sebaiknya Anda menilai pertimbangan operasional dan risiko berikut terkait penggunaan pendekatan bawa kunci Anda sendiri (BYOK):
Dapatkah Anda menerapkan otomatisasi untuk mengimpor versi kunci baru secara konsisten? Hal ini mencakup setelan Cloud KMS untuk membatasi versi kunci agar hanya dapat diimpor, dan otomatisasi di luar Cloud KMS untuk menghasilkan dan mengimpor materi kunci secara konsisten. Apa dampaknya jika otomatisasi Anda gagal membuat versi kunci baru pada waktu yang diharapkan?
Bagaimana Anda berencana menyimpan atau mengamankan materi kunci asli dengan aman?
Bagaimana cara memitigasi risiko proses impor kunci Anda membocorkan materi kunci mentah?
Apa dampaknya jika mengimpor ulang kunci yang sebelumnya dihancurkan karena materi kunci mentah dipertahankan di luar Cloud de Confiance?
Apakah manfaat mengimpor materi utama sendiri membenarkan peningkatan overhead dan risiko operasional?
Pilih model tata kelola utama dan penyimpanan kunci Anda
Saat mendesain arsitektur CMEK, Anda harus memutuskan di mana dan bagaimana kunci Anda akan dikelola. Idealnya, Anda akan memilih model tata kelola kunci dan model penyimpanan kunci yang selaras. Model tata kelola dan model penyimpanan yang Anda pilih memengaruhi konfigurasi penting seperti penerapan pemisahan tugas.
Tata kelola utama
Tata kelola kunci menjelaskan siapa di organisasi yang bertanggung jawab untuk mengelola siklus proses resource Cloud KMS Anda dan mempertahankan batas pengamanan untuk mengontrol cara Cloud KMS digunakan. Pendekatan tata kelola kunci ada pada spektrum dari tata kelola terpusat hingga tata kelola yang didelegasikan:
- Tata kelola terpusat: Tim keamanan atau platform khusus bertanggung jawab untuk mengelola siklus proses semua kunci kriptografi di seluruh organisasi. Model ini sering dipilih oleh perusahaan yang sangat diatur dengan persyaratan kepatuhan yang ketat.
- Tata kelola yang didelegasikan: Tim keamanan pusat menggunakan batas aman untuk mewajibkan standar enkripsi, tetapi mendelegasikan tanggung jawab untuk operasi siklus proses utama kepada pemilik aplikasi dalam project mereka. Pembatasan ini dapat mencakup kebijakan organisasi menggunakan batasan terkelola dan batasan kustom serta pemberian dan penolakan kebijakan IAM. Hal ini menghilangkan hambatan operasional pusat.
Penyimpanan kunci
Penyimpanan kunci menjelaskan tempat resource Cloud KMS dibuat dalam organisasi. Ada dua pendekatan utama untuk penyimpanan kunci: penyimpanan kunci project khusus dan penyimpanan kunci project yang sama.
Penyimpanan kunci project khusus: Project kunci khusus berisi kunci yang digunakan untuk beberapa aplikasi. Biasanya, setiap folder lingkungan memiliki project kuncinya sendiri. Anda dapat menggunakan Autokey dengan penyimpanan kunci project khusus. Untuk mengetahui informasi selengkapnya tentang model penyimpanan kunci project khusus, lihat Penyimpanan kunci project khusus.
Penyimpanan kunci dalam project yang sama: Kunci disimpan dalam projectCloud de Confiance yang sama dengan resource yang dilindunginya. Hal ini terkadang dideskripsikan sebagai "kunci mengikuti data". Anda dapat menggunakan Autokey dengan penyimpanan kunci dalam project yang sama. Untuk mengetahui informasi selengkapnya tentang model penyimpanan kunci project yang sama, lihat Penyimpanan kunci project yang sama.
Menyelaraskan tata kelola dan penyimpanan
Matriks berikut memberikan contoh cara menggabungkan model tata kelola dan penyimpanan ini untuk memenuhi berbagai kebutuhan organisasi:
| Model Tata Kelola | Penyimpanan kunci project khusus | Penyimpanan kunci project yang sama |
|---|---|---|
| Tata kelola terpusat | Pendekatan yang sepenuhnya terpusat Penggunaan yang direkomendasikan: Organisasi dengan persyaratan peraturan yang ketat yang mewajibkan isolasi batas project. Dampak operasional: Kompleksitas penyiapan tinggi. Memerlukan otomatisasi yang andal (seperti "project factory") untuk mencegah keterlambatan operasional bagi tim pengembangan. |
Kepemilikan yang diatur Penggunaan yang direkomendasikan: Organisasi yang memerlukan pengawasan keamanan terpusat, tetapi ingin memaksimalkan kecepatan developer. Dampak operasional: Kompleksitas penyiapan rendah. Keamanan terpusat menerapkan kebijakan menggunakan pedoman, sementara kunci ditempatkan bersama resource yang dilindunginya agar mudah dikelola. |
| Tata kelola yang didelegasikan | Tidak direkomendasikan Memperkenalkan kompleksitas IAM lintas project akan mengalahkan tujuan mendelegasikan pengelolaan kunci kepada tim aplikasi. |
DevOps Otonom Penggunaan yang direkomendasikan: Organisasi yang terdesentralisasi dan berkecepatan tinggi dengan budaya DevOps yang kuat. Dampak operasional: Kompleksitas penyiapan minimal. Tim aplikasi memiliki otonomi penuh atas resource dan kunci dalam batas project mereka. |
Menggunakan arsitektur yang konsisten di seluruh lingkungan Anda
Sebaiknya untuk aplikasi tertentu, Anda menggunakan pola penyimpanan kunci yang sama di seluruh lingkungan pengembangan, pengujian, dan produksi. Konsistensi arsitektur ini membantu memastikan bahwa izin IAM, pipeline deployment, dan kontrol keamanan Anda diuji secara menyeluruh di lingkungan yang lebih rendah sebelum Anda men-deploy-nya ke produksi. Jika Anda memilih arsitektur yang berbeda untuk lingkungan, Anda akan menimbulkan risiko penyimpangan konfigurasi yang dapat menyebabkan kegagalan deployment.
Penyimpanan kunci project khusus
Dalam model penyimpanan kunci project khusus, semua kunci untuk folder lingkungan tertentu (misalnya, Produksi) disimpan dalam project kunci bersama yang terpusat. Izin pengelolaan kunci diberikan kepada tim keamanan bersama, yang biasanya juga mengelola operasi dan batas keamanan siklus proses kunci seperti kebijakan organisasi CMEK serta kebijakan IAM dan pemberian peran.
Kasus penggunaan
Sebaiknya gunakan model penyimpanan kunci project khusus jika organisasi Anda memprioritaskan kontrol pusat yang ketat atas kunci enkripsi, yang sering kali didorong oleh persyaratan peraturan, atau saat kunci dihosting di HSM eksternal.
Jika organisasi Anda tunduk pada framework kepatuhan yang memerlukan Petugas Kriptografi atau Pemegang Kunci, seperti PCI DSS atau BSI C5, maka model ini adalah pilihan yang baik. Dengan mengisolasi semua kunci untuk aplikasi dalam satu project kunci khusus, Anda dapat memberikan peran Admin Cloud KMS hanya kepada sekelompok kecil administrator keamanan yang diaudit. Hal ini dapat menyederhanakan audit kepatuhan dengan membatasi jumlah project tempat kebijakan akses administrasi utama harus ditinjau.
Pertimbangan
Pendekatan ini dapat menimbulkan kompleksitas IAM lintas project dan potensi hambatan bagi tim pengembangan. Untuk membantu memitigasi hal ini, Anda dapat menerapkan penyediaan project otomatis—terkadang disebut "Project Factory"—untuk mengotomatiskan pembuatan kunci dan penetapan izin.
Contoh
Diagram berikut menunjukkan contoh hierarki resource untuk lingkungan produksi menggunakan model penyimpanan kunci project khusus:
- Folder Prod berisi folder dan project individual untuk berbagai aplikasi, serta folder Bersama.
- Project aplikasi berisi berbagai resource yang berbeda, seperti instance Compute Engine dan bucket Cloud Storage, tetapi tidak berisi kunci Cloud KMS.
- Folder Bersama berisi resource yang digunakan bersama di antara aplikasi yang berbeda.
- Dalam folder Bersama, ada project kunci khusus tempat Cloud KMS API diaktifkan. Project ini berisi semua kunci yang digunakan untuk melindungi resource dalam folder Prod.
- Pembatasan di level organisasi dan folder seperti batasan kebijakan organisasi dan kebijakan IAM menerapkan pemisahan tugas dan praktik lainnya.
- Developer dapat memiliki hak istimewa yang ditingkatkan seperti peran Project Owner dalam folder atau project aplikasi tertentu tanpa memberikan hak istimewa pada project utama.
Penyimpanan kunci project yang sama
Dalam model ini, kunci disimpan dalam project yang sama dengan resource yang dilindunginya. Pembatasan pengelolaan kunci biasanya diterapkan oleh tim keamanan inti, meskipun developer mengelola siklus proses kunci untuk aplikasi mereka sendiri.
Kasus penggunaan
Sebaiknya gunakan model penyimpanan kunci dalam project yang sama jika prioritas Anda adalah kecepatan, ketangkasan, dan akuntabilitas yang jelas bagi developer. Menempatkan kunci bersama dengan resource yang dilindunginya menyelaraskan kepemilikan kunci dengan kepemilikan data: kunci mengikuti data. Model ini memfasilitasi pendelegasian tanggung jawab pengelolaan kunci kepada pemilik workload, yang dapat mengambil tanggung jawab untuk menyelaraskan dengan kebijakan organisasi CMEK dan mengelola operasi siklus proses kunci dalam project mereka.
Pertimbangan
Meskipun model ini memberdayakan tim aplikasi, model ini memerlukan audit yang cermat terhadap peran IAM dalam setiap project untuk menerapkan hak istimewa terendah. Model ini dapat meningkatkan kompleksitas operasional bagi organisasi yang menerapkan bawa kunci Anda sendiri (BYOK) atau menggunakan kunci Cloud EKM karena overhead untuk berkoordinasi di seluruh sistem.
Contoh
Diagram berikut menunjukkan contoh hierarki resource untuk lingkungan produksi menggunakan model penyimpanan kunci dalam project yang sama:
- Folder Prod berisi folder dan project individual untuk berbagai aplikasi.
- Project aplikasi berisi berbagai resource yang berbeda, seperti instance Compute Engine dan bucket Cloud Storage, termasuk kunci Cloud KMS yang melindungi resource tersebut.
- Pengamanan tingkat organisasi dan folder seperti batasan kebijakan organisasi dan kebijakan IAM menerapkan pemisahan tugas dan praktik lainnya, tetapi penerapan pemisahan tugas mungkin memerlukan konfigurasi yang lebih cermat.
- Developer memerlukan hak istimewa Cloud KMS yang lebih tinggi di project resource agar dapat membuat dan mengelola kunci.
Menerapkan pemisahan tugas
Terlepas dari model penyimpanan Anda, Anda harus mempertahankan prinsipal dan izin terpisah untuk orang yang mengelola kunci enkripsi Anda dan orang yang menggunakannya. Untuk menerapkan prinsip hak istimewa terendah dan pemisahan tugas yang ketat, berikan peran IAM berdasarkan tanggung jawab operasional tertentu.
Tabel berikut merangkum pemisahan peran yang direkomendasikan untuk Cloud KMS:
| Tanggung jawab | Peran yang direkomendasikan | Ringkasan izin |
|---|---|---|
Administrasi kunci, misalnya siklus proses dan tata kelola kunci Hal ini dapat mencakup administrator manusia dan entitas IaC yang memerlukan hak istimewa yang ditingkatkan. |
Cloud KMS Admin (roles/cloudkms.admin) |
|
Penyediaan resource, misalnya membuat resource yang dilindungi CMEK Hal ini dapat mencakup developer manusia dan pokok IaC tanpa hak istimewa yang ditingkatkan. |
Peran editor atau administrasi khusus layanan seperti berikut:
|
Pilih kunci selama pembuatan resource. |
Penggunaan kunci, misalnya enkripsi dan dekripsi Berikan peran ini hanya kepada agen layanan. Untuk kunci yang digunakan dalam integrasi CMEK, prinsipal manusia tidak memerlukan izin ini. |
Cloud KMS CryptoKey Encrypter/Decrypter
(roles/cloudkms.cryptoKeyEncrypterDecrypter) |
Enkripsi dan dekripsi data menggunakan kunci. |
Menerapkan eskalasi hak istimewa terendah untuk pipeline IaC
Banyak organisasi mengotomatiskan penyediaan resource menggunakan pipeline infrastruktur sebagai kode (IaC) seperti runner Terraform. Cara Anda merancang penyimpanan kunci secara langsung memengaruhi postur keamanan pipeline ini.
Untuk mengotomatiskan penyediaan kunci Cloud KMS, pipeline IaC Anda harus diberi peran administratif dengan hak istimewa tinggi untuk membuat kunci dan mengubah kebijakan IAM. Jika penyerang menyusupi pipeline IaC, mereka dapat memperoleh kontrol administratif penuh atas bidang pengelolaan kunci Anda.
- Jika Anda menggunakan penyimpanan kunci project khusus, pipeline memerlukan akses administratif ke project Cloud KMS pusat. Kompromi pada pipeline berpotensi mengekspos bidang pengelolaan kunci untuk seluruh organisasi Anda.
- Jika Anda menggunakan penyimpanan kunci dalam project yang sama, maka pipeline hanya memerlukan akses administratif ke project resource. Hal ini membatasi cakupan potensi risiko pada aplikasi tertentu, tetapi tetap memerlukan pengelolaan hak istimewa yang ditingkatkan dalam project.
Kunci Otomatis Cloud KMS mengatasi risiko ini dengan mendelegasikan penyediaan kunci ke agen layanan yang dikelola Google dan aman, sehingga Anda dapat menerapkan pipeline hak istimewa terendah untuk penyediaan kunci berkelanjutan:
- Pipeline dengan hak istimewa rendah: Pipeline IaC hanya memerlukan peran Pengguna Autokey Cloud KMS dengan hak istimewa rendah (
roles/cloudkms.autokeyUser) untuk meminta kunci dengan membuat resourceKeyHandle. - Penyediaan otomatis: Pembuatan kunci dan update kebijakan IAM yang sebenarnya ditangani di balik layar oleh agen layanan Cloud KMS yang dikelola Google.
- Cakupan risiko terbatas: Dengan meminimalkan izin yang diberikan ke pipeline Anda, desain ini menghindari pemberian hak istimewa pembuatan kunci atau admin keamanan yang lebih tinggi, atau kemampuan untuk menetapkan peran pembantu, yang secara signifikan mengurangi risiko kompromi pipeline.
Pipeline IaC yang mengaktifkan Autokey memerlukan peran yang lebih permisif seperti Admin Autokey Cloud KMS (roles/cloudkms.autokeyAdmin). Jadi, jika Anda menggunakan pipeline IaC untuk mengelola pengaktifan Autokey, Anda juga harus menerapkan pemisahan tugas ke setiap pokok IaC.
Selaras dengan praktik pengelolaan kunci yang direkomendasikan
Google merekomendasikan praktik untuk lokasi kunci, tingkat perlindungan, jadwal rotasi, perincian, dan izin. Anda dapat melihat seberapa baik keselarasan kunci Anda dengan praktik ini menggunakan dasbor Metrik enkripsi. Anda dapat mendeteksi pelanggaran pemisahan tugas dengan menggunakan temuan kerentanan Security Command Center.
Lokasi kunci
Anda harus membuat key ring Cloud KMS di lokasi tempat Anda berencana men-deploy resource Cloud de Confiance yang dienkripsi dengan CMEK. Anda harus melakukannya sebelum dapat membuat kunci.- Resource regional dan zona harus menggunakan key ring dan kunci di region yang sama
dengan resource atau di lokasi
global. - Resource global harus menggunakan key ring dan kunci di lokasi
global.
Dalam sebagian besar kasus, pembatasan ini diberlakukan oleh layanan Cloud de Confiance tersebut.
Menerapkan penggunaan kunci regional adalah salah satu bagian dari strategi regionalisasi data yang berhasil. Dengan menerapkan penggunaan key ring dan kunci di region yang ditentukan, Anda juga menerapkan bahwa resource harus cocok dengan region key ring.
Memilih strategi perincian kunci
Granularitas mengacu pada skala dan cakupan penggunaan yang dimaksudkan untuk setiap kunci. Misalnya, kunci yang melindungi beberapa resource dikatakan kurang terperinci daripada kunci yang melindungi hanya satu resource. Memilih strategi perincian kunci yang sesuai membantu Anda menyelaraskan diri dengan rekomendasi NIST bahwa setiap kunci memiliki tujuan tertentu.
Secara umum, sebaiknya setiap kunci digunakan sebagai berikut:
- Digunakan untuk satu Cloud de Confiance project.
- Digunakan di satu lokasi—misalnya,
us-central1. - Digunakan dalam satu layanan atau produk—misalnya, BigQuery.
- Jika memungkinkan, digunakan untuk satu resource—misalnya, satu bucket Cloud Storage.
Untuk sebagian besar organisasi, strategi ini memberikan keseimbangan yang baik antara overhead pemeliharaan banyak kunci yang sangat terperinci dan potensi risiko penggunaan kunci yang kurang terperinci yang dibagikan di antara banyak project, layanan, atau resource.
Mengikuti panduan perincian ini akan mempermudah penonaktifan atau penghancuran versi kunci dengan aman dan membatasi risiko penghancuran kunci yang tidak disengaja atau berbahaya.
Memilih tingkat perlindungan untuk kunci
Saat membuat kunci, Anda bertanggung jawab untuk memilih tingkat perlindungan
yang sesuai untuk setiap kunci berdasarkan persyaratan Anda untuk data dan
workload yang dienkripsi dengan CMEK.
* Jika Anda mewajibkan materi kunci Anda disimpan di luar
Cloud de Confiance, gunakan kunci Cloud EKM. Sebaiknya gunakan tingkat perlindungan
EXTERNAL_VPC untuk ketersediaan yang lebih baik.
* Jika Anda tidak diwajibkan untuk menyimpan materi kunci di luar
Cloud de Confiance, sebaiknya gunakan kunci yang didukung software.
Pilih periode rotasi
Cloud KMS mendukung rotasi kunci otomatis untuk kunci simetris yang didukung software dan hardware seperti yang digunakan untuk CMEK. Untuk kunci yang didukung software, sebaiknya gunakan periode rotasi standar industri selama 90 hari. Untuk kunci Cloud HSM, sebaiknya gunakan periode rotasi standar industri selama 365 hari. Kunci eksternal harus dirotasi secara manual sesuai jadwal yang Anda pilih.
Sebaiknya tentukan periode rotasi kunci yang sesuai dengan kebutuhan Anda. Frekuensi rotasi kunci bergantung pada persyaratan workload Anda berdasarkan sensitivitas atau kepatuhan. Misalnya, rotasi kunci mungkin diperlukan setidaknya setahun sekali untuk memenuhi standar kepatuhan tertentu, atau Anda dapat memilih periode rotasi yang lebih sering untuk workload yang sangat sensitif.
Rotasi kunci yang sering membantu membatasi jumlah pesan yang dienkripsi dengan versi kunci yang sama, sehingga membantu mengurangi risiko dan konsekuensi jika kunci disusupi.
Menerapkan prinsip hak istimewa terendah
Saat memberikan peran IAM, ikuti prinsip hak istimewa terendah.
Sebaiknya hindari penggunaan peran dasar seperti
Pemilik, Editor, dan Pelihat. Sebagai gantinya, berikan peran Cloud KMS yang telah ditetapkan untuk memitigasi risiko insiden keamanan terkait akses dengan hak istimewa berlebih. Misalnya, jika pokok hanya perlu mengimpor materi kunci, berikan peran Cloud KMS Importer (roles/cloudkms.importer) dan bukan peran Cloud KMS Admin (roles/cloudkms.admin) yang lebih permisif.
Menetapkan batasan operasional
Bagian berikut menjelaskan kontrol yang dapat Anda terapkan untuk membantu memitigasi risiko seperti penggunaan kunci yang tidak konsisten atau penghapusan atau penghancuran yang tidak disengaja.
Menerapkan hak gadai project
Sebaiknya lindungi project dengan lien (Pratinjau) untuk membantu mencegah penghapusan yang tidak disengaja pada project Cloud KMS Anda dan kunci yang ada di dalamnya. Selama lien project diterapkan, project akan diblokir agar tidak dihapus hingga lien dihapus. Untuk project yang berisi kunci Cloud KMS, hal ini mencegah salah satu kemungkinan penyebab penghapusan kunci yang tidak disengaja.
Mewajibkan kunci CMEK
Sebaiknya terapkan penggunaan CMEK di seluruh lingkungan Anda menggunakan batasan kebijakan organisasi.
Gunakan constraints/gcp.restrictNonCmekServices untuk memblokir permintaan pembuatan jenis resource tertentu tanpa menentukan kunci CMEK.
Memerlukan durasi minimum yang dijadwalkan untuk penghancuran
Sebaiknya tetapkan durasi dijadwalkan untuk penghancuran minimum. Penghancuran kunci adalah operasi yang tidak dapat diurungkan dan dapat menyebabkan kehilangan data permanen. Secara default, Cloud KMS menggunakan durasi dijadwalkan untuk dihancurkan (terkadang disebut periode penghapusan sementara) selama 30 hari sebelum materi kunci dihancurkan secara permanen. Hal ini memberikan waktu untuk memulihkan kunci jika terjadi penghancuran yang tidak disengaja. Namun, seseorang dengan peran Admin Cloud KMS dapat membuat kunci dengan durasi dijadwalkan untuk penghancuran serendah 24 jam, yang mungkin tidak cukup waktu bagi Anda untuk mendeteksi masalah dan memulihkan kunci. Durasi dijadwalkan untuk dimusnahkan hanya dapat ditetapkan selama pembuatan kunci.
Selama kunci dijadwalkan untuk dimusnahkan, kunci tersebut tidak dapat digunakan untuk operasi kriptografi, dan setiap permintaan untuk menggunakan kunci tersebut akan gagal. Selama waktu ini, pantau log audit untuk memeriksa bahwa kunci tidak sedang digunakan. Jika ingin menggunakan kunci lagi, Anda harus memulihkan kunci sebelum berakhirnya periode dijadwalkan untuk dihancurkan.
Untuk memastikan semua kunci yang dibuat mematuhi durasi dijadwalkan untuk penghancuran minimum, sebaiknya konfigurasi batasan kebijakan organisasi constraints/cloudkms.minimumDestroyScheduledDuration dengan durasi minimal 30 hari, atau durasi pilihan Anda. Kebijakan organisasi ini mencegah pengguna membuat kunci dengan durasi
dijadwalkan untuk dihancurkan yang lebih pendek dari nilai yang ditentukan dalam
kebijakan.
Menerapkan tingkat perlindungan yang diizinkan untuk CMEK
Sebaiknya terapkan persyaratan Anda untuk tingkat perlindungan kunci secara konsisten di seluruh lingkungan Anda menggunakan batasan kebijakan organisasi.
Gunakan constraints/cloudkms.allowedProtectionLevels
untuk memastikan bahwa kunci baru, versi kunci, dan tugas impor harus menggunakan tingkat perlindungan
yang Anda izinkan.
Mengonfigurasi kontrol detektif untuk CMEK
Cloud de Confiance menyediakan berbagai kontrol detektif untuk CMEK. Bagian berikut menjelaskan cara mengaktifkan dan menggunakan kontrol yang relevan untuk Cloud KMS.
Mengaktifkan dan menggabungkan logging audit
Sebaiknya Anda menggabungkan log audit Aktivitas Admin Cloud KMS di lokasi terpusat untuk semua resource di organisasi Anda. Hal ini memungkinkan tim keamanan atau auditor meninjau semua aktivitas yang terkait dengan pembuatan atau modifikasi resource Cloud KMS sekaligus. Untuk mendapatkan panduan tentang cara mengonfigurasi sink log gabungan, lihat artikel Menggabungkan dan menyimpan log organisasi Anda.
Secara opsional, Anda dapat mengaktifkan log akses data untuk mencatat operasi yang menggunakan kunci, termasuk operasi enkripsi dan dekripsi. Saat menggunakan CMEK, hal ini dapat menghasilkan volume log yang besar dan memengaruhi biaya Anda karena setiap operasi dari setiap layanan yang menggunakan CMEK akan membuat log akses data. Sebelum mengaktifkan log akses data, sebaiknya tentukan kasus penggunaan yang jelas untuk log tambahan dan nilai peningkatan biaya logging Anda.
Ringkasan praktik terbaik
Tabel berikut meringkas praktik terbaik yang direkomendasikan dalam dokumen ini:
| Topik | Tugas |
|---|---|
| Project kunci Cloud KMS | Gunakan satu project kunci terpusat untuk setiap lingkungan. Jangan membuat resource Cloud KMS di project yang sama dengan resource Cloud de Confiance yang dilindungi kunci. |
| Key ring Cloud KMS | Buat key ring Cloud KMS untuk setiap lokasi tempat Anda ingin melindungi Cloud de Confiance resource. |
| Perincian utama | Pilih pola perincian kunci yang memenuhi kebutuhan Anda terkait toleransi risiko, biaya, dan overhead operasional. |
| Level perlindungan | Pilih Cloud EKM jika materi kunci Anda harus disimpan di luar Cloud de Confiance atau jika Anda memerlukan sertifikasi FIPS 140-2 level 2 atau level 3. Atau, pilih kunci software. Tinjau panduan untuk memilih tingkat perlindungan. |
| Key material | Untuk materi kunci yang dihosting di Cloud de Confiance, gunakan materi kunci yang dibuat Cloud de Confiancejika memungkinkan. Jika Anda menggunakan materi kunci yang diimpor, terapkan otomatisasi dan prosedur untuk memitigasi risiko. |
| Tujuan dan algoritma kunci | Semua kunci CMEK harus menggunakan tujuan kunci ENCRYPT_DECRYPT simetris dan algoritma GOOGLE_SYMMETRIC_ENCRYPTION. |
| Rotation period | Gunakan rotasi kunci otomatis untuk memastikan kunci Anda dirotasi sesuai jadwal. Pilih dan terapkan periode rotasi yang sesuai dengan kebutuhan Anda, idealnya tidak kurang dari sekali per tahun. Gunakan rotasi kunci yang lebih sering untuk workload sensitif. |
| Hak istimewa terendah | Berikan peran bawaan paling terbatas yang memungkinkan akun utama Anda menyelesaikan tugasnya. Jangan gunakan peran dasar. |
| Pemisahan tugas | Mempertahankan izin terpisah untuk administrator kunci dan prinsipal yang menggunakan kunci. |
| Hak gadai project | Gunakan lien project untuk mencegah penghapusan project utama Anda secara tidak sengaja. |
| Mewajibkan CMEK | Gunakan batasan constraints/gcp.restrictNonCmekServices. |
| Memerlukan durasi minimum yang dijadwalkan untuk penghancuran | Gunakan batasan
constraints/cloudkms.minimumDestroyScheduledDuration. |
| Menerapkan tingkat perlindungan yang diizinkan untuk CMEK | Gunakan batasan constraints/cloudkms.allowedProtectionLevels. |
| Mengaktifkan dan menggabungkan logging audit | Menggabungkan log audit aktivitas administratif untuk semua resource di organisasi Anda. Pertimbangkan apakah Anda ingin mengaktifkan pencatatan log operasi menggunakan kunci. |
| Menilai persyaratan kepatuhan | Tinjau arsitektur Cloud KMS Anda dan bandingkan dengan persyaratan kepatuhan yang harus Anda patuhi. |