Halaman ini menjelaskan praktik terbaik untuk mengonfigurasi enkripsi dalam penyimpanan dengan kunci enkripsi yang dikelola pelanggan (CMEK) di resource Trusted Cloud Anda. Panduan ini ditujukan untuk arsitek cloud dan tim keamanan, serta menguraikan praktik terbaik dan keputusan 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.Menentukan apakah akan menggunakan CMEK
Sebaiknya gunakan CMEK untuk mengenkripsi data dalam penyimpanan di layanan Trusted Cloud jika Anda memerlukan salah satu kemampuan berikut:
Memiliki kunci enkripsi Anda sendiri.
Mengontrol dan mengelola kunci enkripsi Anda, termasuk pilihan lokasi, tingkat perlindungan, pembuatan, kontrol akses, rotasi, penggunaan, dan pemusnahan.
Buat materi kunci di Cloud KMS atau impor materi kunci yang dikelola di luar Trusted Cloud.
Tetapkan kebijakan terkait tempat kunci Anda harus digunakan.
Menghapus data yang dilindungi oleh kunci Anda secara selektif jika terjadi penghentian layanan atau untuk memperbaiki peristiwa keamanan (crypto-shredding).
Buat dan gunakan kunci yang unik untuk pelanggan, yang menetapkan batas kriptografis di sekitar data Anda.
Mencatat log akses data dan administratif ke kunci enkripsi.
Memenuhi peraturan saat ini atau mendatang yang mewajibkan salah satu sasaran ini.
Mendesain arsitektur CMEK
Saat mendesain arsitektur CMEK, Anda harus mempertimbangkan konfigurasi kunci yang akan digunakan dan cara kunci ini dikelola. Keputusan ini memengaruhi biaya, overhead operasional, dan kemudahan penerapan kemampuan seperti crypto-shredding.
Bagian berikut membahas rekomendasi untuk setiap pilihan desain.
Menggunakan project kunci CMEK terpusat untuk setiap lingkungan
Sebaiknya gunakan project kunci CMEK terpusat untuk setiap folder lingkungan. Jangan membuat resource yang dienkripsi dengan CMEK di project yang sama tempat Anda mengelola kunci Cloud KMS. Pendekatan ini membantu mencegah pembagian kunci enkripsi di seluruh lingkungan dan membantu memungkinkan pemisahan tugas.
Diagram berikut menggambarkan konsep ini dalam desain yang direkomendasikan:
- Setiap folder lingkungan memiliki project kunci Cloud KMS yang dikelola secara terpisah dari project aplikasi.
- Key ring dan kunci Cloud KMS disediakan di project kunci Cloud KMS, dan kunci ini digunakan untuk mengenkripsi resource dalam project aplikasi.
- Kebijakan Identity and Access Management (IAM) diterapkan ke project atau folder untuk mengaktifkan pemisahan tugas. Akun utama yang mengelola kunci Cloud KMS dalam project kunci Cloud KMS bukan akun utama yang menggunakan kunci enkripsi dalam project aplikasi.
Membuat key ring Cloud KMS untuk setiap lokasi
Anda harus membuat key ring Cloud KMS di lokasi tempat Anda men-deploy resourceTrusted Cloud yang dienkripsi dengan CMEK.
- Resource regional dan zonal harus menggunakan key ring dan CMEK di region yang sama dengan resource atau di lokasi
global. - Resource global harus menggunakan key ring dan CMEK di lokasi
global.
Menerapkan kunci regional adalah salah satu bagian dari strategi regionalisasi data. Dengan menerapkan penggunaan key ring dan kunci di region yang ditentukan, Anda juga menerapkan bahwa resource harus cocok dengan region key ring.
Untuk workload yang memerlukan ketersediaan tinggi atau kemampuan disaster recovery di beberapa lokasi, Anda bertanggung jawab untuk menilai apakah workload Anda tahan jika Cloud KMS tidak tersedia di region tertentu. Misalnya, persistent disk Compute Engine yang dienkripsi dengan kunci Cloud KMS dari region A tidak dapat dibuat ulang di region B dalam skenario disaster recovery saat region A tidak tersedia. Untuk memitigasi risiko
skenario ini, Anda dapat merencanakan enkripsi resource dengan kunci global.
Memilih strategi tingkat perincian kunci
Tingkat perincian mengacu pada skala dan cakupan penggunaan yang diinginkan untuk setiap kunci. Misalnya, kunci yang melindungi beberapa resource dikatakan kurang terperinci daripada kunci yang hanya melindungi satu resource.
Kunci Cloud KMS yang digunakan untuk CMEK harus disediakan terlebih dahulu sebelum membuat resource yang akan dienkripsi dengan kunci tersebut, seperti persistent disk Compute Engine. Anda dapat memilih untuk membuat kunci yang sangat terperinci untuk setiap resource atau membuat kunci yang kurang terperinci untuk digunakan kembali di antara resource secara lebih luas.
Meskipun tidak ada pola yang benar secara universal, pertimbangkan kompromi dari berbagai pola berikut:
Kunci dengan perincian tinggi—misalnya, satu kunci untuk setiap resource individual
- Kontrol lebih besar untuk menonaktifkan versi kunci dengan aman: Menonaktifkan atau menghancurkan versi kunci yang digunakan untuk cakupan sempit memiliki risiko lebih rendah untuk memengaruhi resource lain daripada menonaktifkan atau menghancurkan kunci bersama. Hal ini juga berarti bahwa penggunaan kunci yang sangat terperinci membantu mengurangi potensi dampak kunci yang disusupi jika dibandingkan dengan penggunaan kunci dengan tingkat perincian rendah.
- Biaya: Penggunaan kunci terperinci memerlukan pemeliharaan versi kunci yang lebih aktif jika dibandingkan dengan strategi yang menggunakan kunci dengan tingkat perincian yang lebih rendah. Granularitas kunci yang lebih tinggi memerlukan lebih banyak versi kunci aktif, yang menimbulkan biaya tambahan.
- Overhead operasional: Menggunakan kunci yang sangat terperinci mungkin memerlukan upaya administratif atau alat tambahan untuk otomatisasi guna menyediakan resource Cloud KMS dalam jumlah besar dan mengelola kontrol akses untuk agen layanan sehingga mereka hanya dapat menggunakan kunci yang sesuai.
Kunci dengan tingkat perincian rendah—misalnya, satu kunci untuk setiap aplikasi, untuk setiap region, dan untuk setiap lingkungan
- Memerlukan kehati-hatian untuk menonaktifkan versi kunci dengan aman: Menonaktifkan atau menghancurkan versi kunci yang digunakan untuk cakupan yang luas memerlukan lebih banyak kehati-hatian daripada menonaktifkan atau menghancurkan kunci yang sangat terperinci. Anda harus memastikan bahwa semua resource yang dienkripsi oleh versi kunci tersebut dienkripsi ulang dengan aman menggunakan versi kunci baru sebelum menonaktifkan versi kunci lama. Hal ini juga berarti bahwa penggunaan kunci dengan tingkat perincian rendah dapat meningkatkan potensi dampak dari kunci yang disusupi jika dibandingkan dengan penggunaan kunci dengan tingkat perincian tinggi.
- Biaya: Penggunaan kunci yang kurang terperinci memerlukan lebih sedikit versi kunci yang harus dibuat, sehingga biaya yang dikeluarkan lebih rendah.
- Overhead operasional: Anda dapat menentukan dan menyediakan kunci dalam jumlah tertentu secara otomatis, dengan lebih sedikit upaya yang diperlukan untuk memastikan kontrol akses yang sesuai.
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 beban kerja yang dienkripsi dengan CMEK. Pertanyaan berikut dapat membantu Anda dalam penilaian:
Apakah Anda memerlukan salah satu kemampuan CMEK? Anda dapat meninjau kemampuan yang tercantum di bagian Menentukan apakah akan menggunakan CMEK di halaman ini.
- Jika ya, lanjutkan ke pertanyaan berikutnya.
- Jika tidak, sebaiknya gunakan S3NS enkripsi default.
Apakah Anda memerlukan sertifikasi FIPS 140-2 level 2 atau level 3 atau materi kunci disimpan di luar Trusted Cloud?
- Jika ya, sebaiknya gunakan CMEK dengan Cloud External Key Manager.
- Jika tidak, sebaiknya gunakan CMEK dengan kunci yang didukung software.
Gunakan materi kunci yang dibuat Trusted Cloudjika memungkinkan
Bagian ini tidak berlaku untuk kunci Cloud EKM.
Saat membuat kunci, Anda harus mengizinkan Cloud KMS membuat materi kunci untuk Anda atau mengimpor materi kunci secara manual yang dihasilkan di luar Trusted Cloud. Jika memungkinkan, sebaiknya pilih opsi yang dihasilkan. Opsi ini tidak mengekspos materi kunci mentah di luar Cloud KMS dan secara otomatis membuat versi kunci baru berdasarkan periode rotasi kunci yang Anda pilih. Jika Anda memerlukan opsi untuk mengimpor materi kunci Anda sendiri, sebaiknya Anda menilai pertimbangan operasional dan risiko penggunaan pendekatan bawa kunci Anda sendiri (BYOK) berikut:
- Dapatkah Anda menerapkan otomatisasi untuk mengimpor versi kunci baru secara konsisten? Hal ini mencakup setelan Cloud KMS untuk membatasi versi kunci untuk hanya impor, dan otomatisasi di luar Cloud KMS untuk secara konsisten membuat dan mengimpor materi kunci. Apa dampaknya jika otomatisasi Anda gagal membuat versi kunci baru pada waktu yang diharapkan?
- Bagaimana Anda ingin menyimpan atau menyimpan material kunci asli dengan aman?
- Bagaimana cara memitigasi risiko proses impor kunci yang membocorkan materi kunci mentah?
- Apa dampaknya jika mengimpor ulang kunci yang sebelumnya dihancurkan karena materi kunci mentah dipertahankan di luar Trusted Cloud?
- Apakah manfaat mengimpor materi kunci sendiri membenarkan peningkatan overhead dan risiko operasional?
Memilih tujuan utama dan algoritma yang tepat untuk kebutuhan Anda
Saat membuat kunci, Anda harus memilih tujuan dan algoritma yang mendasarinya untuk
kunci tersebut. Untuk kasus penggunaan CMEK, hanya kunci dengan tujuan ENCRYPT_DECRYPT simetris yang dapat digunakan. Tujuan kunci ini selalu menggunakan algoritma GOOGLE_SYMMETRIC_ENCRYPTION, yang menggunakan kunci Advanced Encryption Standard (AES-256) 256-bit dalam Galois Counter Mode (GCM), yang ditambahkan dengan metadata internal Cloud KMS. Saat Anda menggunakan Kunci Otomatis, setelan
ini akan otomatis diterapkan untuk Anda.
Untuk kasus penggunaan lainnya seperti enkripsi sisi klien, tinjau tujuan dan algoritma kunci yang tersedia untuk memilih opsi yang paling sesuai dengan kasus penggunaan Anda.
Memilih periode rotasi
Sebaiknya Anda menilai periode rotasi kunci yang sesuai untuk kebutuhan Anda. Frekuensi rotasi kunci bergantung pada persyaratan beban kerja 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.
Setelah merotasi kunci simetris, versi baru akan ditandai sebagai versi kunci utama dan digunakan untuk semua permintaan baru guna melindungi informasi. Versi kunci lama tetap tersedia untuk digunakan guna mendekripsi data yang sebelumnya dienkripsi dan dilindungi dengan versi tersebut. Saat Anda merotasi kunci, data yang dienkripsi dengan versi kunci sebelumnya tidak akan otomatis dienkripsi ulang.
Rotasi kunci yang sering membantu membatasi jumlah pesan yang dienkripsi dengan versi kunci yang sama, yang membantu mengurangi risiko dan konsekuensi kunci yang disusupi.
Menerapkan kontrol akses yang sesuai
Sebaiknya pertimbangkan prinsip hak istimewa terendah dan pemisahan tugas saat merencanakan kontrol akses. Bagian berikut memperkenalkan rekomendasi ini.
Menerapkan prinsip hak istimewa terendah
Saat menetapkan izin untuk mengelola CMEK, pertimbangkan prinsip hak istimewa terendah dan berikan izin minimum yang diperlukan untuk melakukan tugas. Sebaiknya hindari penggunaan peran dasar. Sebagai gantinya, berikan peran Cloud KMS yang telah ditetapkan untuk memitigasi risiko insiden keamanan yang terkait dengan akses yang terlalu banyak hak istimewanya.
Merencanakan pemisahan tugas
Pertahankan identitas dan izin terpisah untuk orang yang mengelola kunci enkripsi Anda dan orang yang menggunakannya. NIST SP 800-152 menentukan pemisahan tugas antara petugas kriptografi yang mengaktifkan dan mengelola layanan sistem pengelolaan kunci kriptografis dan pengguna yang menggunakan kunci tersebut untuk mengenkripsi atau mendekripsi resource.
Saat Anda menggunakan CMEK untuk mengelola enkripsi dalam penyimpanan dengan layanan Trusted Cloud ,
peran IAM untuk menggunakan kunci enkripsi ditetapkan ke agen
layanan layanan Trusted Cloud , bukan pengguna
individual. Misalnya, untuk membuat objek di bucket Cloud Storage terenkripsi, pengguna hanya memerlukan peran IAM roles/storage.objectCreator, dan agen layanan Cloud Storage di project yang sama (seperti service-PROJECT_NUMBER@gs-project-accounts.s3ns-system.iam.gserviceaccount.com) memerlukan peran IAM roles/cloudkms.cryptoKeyEncrypterDecrypter.
Tabel berikut mencantumkan peran IAM yang biasanya dikaitkan dengan fungsi tugas:
| Peran IAM | Deskripsi | Penetapan NIST SP 800-152 |
|---|---|---|
roles/cloudkms.admin |
Memberikan akses ke resource Cloud KMS, kecuali untuk akses ke jenis resource dan operasi kriptografis yang dibatasi. | Cryptographic officer |
roles/cloudkms.cryptoKeyEncrypterDecrypter |
Memberikan kemampuan untuk menggunakan resource Cloud KMS hanya untuk operasi encrypt dan decrypt. |
Pengguna Sistem Pengelolaan Kunci Kriptografis |
roles/cloudkms.viewer |
Mengaktifkan operasi get dan list. |
Administrator audit |
Menerapkan CMEK secara konsisten
Bagian berikut menjelaskan kontrol tambahan untuk membantu mengurangi risiko seperti penggunaan kunci yang tidak konsisten atau penghapusan atau pemusnahan yang tidak disengaja.
Menerapkan lien project
Sebaiknya lindungi project dengan lien untuk menghindari penghapusan yang tidak disengaja. Saat lien project diterapkan, project kunci Cloud KMS akan diblokir agar tidak dihapus hingga lien dihapus.
Mewajibkan kunci CMEK
Sebaiknya terapkan penggunaan CMEK di seluruh lingkungan Anda menggunakan batasan kebijakan organisasi.
Gunakan constraints/gcp.restrictNonCmekServices untuk memblokir
permintaan guna membuat jenis resource tertentu tanpa menentukan kunci CMEK.
Memerlukan durasi minimum yang dijadwalkan untuk dihancurkan
Sebaiknya tetapkan durasi dijadwalkan untuk dihancurkan minimum. Penghancuran kunci adalah operasi yang tidak dapat dibatalkan dan dapat menyebabkan hilangnya data. 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 dihancurkan serendah 24 jam, yang mungkin tidak cukup waktu bagi Anda untuk mendeteksi masalah dan memulihkan kunci. Durasi dijadwalkan untuk dihancurkan hanya dapat ditetapkan selama pembuatan kunci.
Meskipun dijadwalkan untuk dihancurkan, kunci tidak dapat digunakan untuk operasi kriptografis, dan permintaan apa pun untuk menggunakan kunci akan gagal. Selama waktu ini, pantau log audit untuk memeriksa apakah kunci tidak digunakan. Jika ingin menggunakan kunci lagi, Anda harus memulihkan kunci sebelum akhir periode dijadwalkan untuk dihancurkan.
Untuk memastikan bahwa semua kunci yang dibuat mematuhi durasi dijadwalkan untuk dihancurkan
minimum, sebaiknya konfigurasikan batasan kebijakan organisasi
constraints/cloudkms.minimumDestroyScheduledDuration
dengan minimum 30 hari, atau durasi
pilihan Anda. Kebijakan organisasi ini mencegah pengguna membuat kunci dengan durasi
dijadwalkan untuk dihancurkan yang kurang dari nilai yang ditentukan dalam
kebijakan.
Menerapkan tingkat perlindungan yang diizinkan untuk CMEK
Sebaiknya terapkan persyaratan untuk tingkat perlindungan kunci secara konsisten di seluruh lingkungan menggunakan batasan kebijakan organisasi.
Gunakan constraints/cloudkms.allowedProtectionLevels
untuk menerapkan bahwa kunci baru, versi kunci, dan tugas impor harus menggunakan tingkat perlindungan
yang Anda izinkan.
Mengonfigurasi kontrol detektif untuk CMEK
Trusted Cloud menyediakan berbagai kontrol detektif untuk CMEK. Bagian berikut memperkenalkan cara mengaktifkan dan menggunakan kontrol ini yang relevan untuk Cloud KMS.
Mengaktifkan dan menggabungkan logging audit
Sebaiknya gabungkan log audit Aktivitas Admin Cloud KMS (beserta log Aktivitas Admin untuk semua layanan) di lokasi terpusat untuk semua resource di organisasi Anda. Hal ini memungkinkan tim keamanan atau auditor meninjau semua aktivitas terkait pembuatan atau perubahan resource Cloud KMS sekaligus. Untuk panduan mengonfigurasi sink log gabungan, lihat 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 substansial 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 perkirakan peningkatan biaya logging Anda.
Menilai persyaratan kepatuhan Anda
Framework kepatuhan yang berbeda memiliki persyaratan yang berbeda untuk enkripsi dan pengelolaan kunci. Framework kepatuhan biasanya menguraikan prinsip dan tujuan pengelolaan kunci enkripsi tingkat tinggi, tetapi tidak bersifat preskriptif tentang produk atau konfigurasi tertentu yang mencapai kepatuhan. Anda bertanggung jawab untuk memahami persyaratan framework kepatuhan Anda dan cara kontrol Anda, termasuk pengelolaan kunci, dapat memenuhi persyaratan tersebut.
Untuk panduan tentang cara layanan Trusted Cloud dapat membantu memenuhi persyaratan berbagai framework kepatuhan, lihat referensi berikut:Ringkasan praktik terbaik
Tabel berikut meringkas praktik terbaik yang direkomendasikan dalam dokumen ini:
| Topik | Tugas |
|---|---|
| Menentukan apakah akan menggunakan CMEK | Gunakan CMEK jika Anda memerlukan salah satu kemampuan yang diaktifkan oleh CMEK. |
| Project kunci Cloud KMS | Gunakan satu project kunci terpusat untuk setiap lingkungan. Jangan membuat resource Cloud KMS di project yang sama dengan resource Trusted Cloudyang dilindungi kunci. |
| Key ring Cloud KMS | Buat key ring Cloud KMS untuk setiap lokasi tempat Anda ingin melindungi resource Trusted Cloud. |
| Perincian kunci | Pilih pola tingkat 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 Trusted Cloud atau jika Anda memerlukan sertifikasi FIPS 140-2 level 2 atau level 3. Jika tidak, pilih kunci software. Tinjau panduan untuk memilih tingkat perlindungan. |
| Key material | Untuk materi kunci yang dihosting di Trusted Cloud, gunakan materi kunci yang dibuat Trusted Cloudjika memungkinkan. Jika Anda menggunakan materi kunci yang diimpor, terapkan otomatisasi dan prosedur untuk memitigasi risiko. |
| Tujuan utama dan algoritma | 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 memenuhi 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 | Pertahankan izin terpisah untuk administrator kunci dan akun utama yang menggunakan kunci. |
| Lien 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 dihancurkan | 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 logging operasi menggunakan kunci. |
| Menilai persyaratan kepatuhan | Tinjau arsitektur Cloud KMS Anda dan bandingkan dengan persyaratan kepatuhan yang harus Anda patuhi. |