Halaman ini menguraikan praktik terbaik untuk mengonfigurasi enkripsi saat istirahat 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 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 Cloud de Confiance jika Anda memerlukan salah satu kemampuan berikut:
Miliki kunci enkripsi Anda sendiri.
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 dalam kasus penghentian penggunaan atau untuk memulihkan peristiwa keamanan (penghancuran kriptografi).
Buat dan gunakan kunci yang unik untuk pelanggan, dengan membuat batas kriptografi di sekitar data Anda.
Mencatat log akses administratif dan data ke kunci enkripsi.
Memenuhi peraturan saat ini atau mendatang yang mewajibkan salah satu sasaran ini.
Mendesain arsitektur CMEK Anda
Saat mendesain arsitektur CMEK, Anda harus mempertimbangkan konfigurasi kunci yang akan digunakan dan cara pengelolaan kunci tersebut. Keputusan ini memengaruhi biaya, biaya operasional, dan kemudahan penerapan kemampuan seperti penghancuran kripto.
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 dalam project yang sama tempat Anda mengelola kunci Cloud KMS. Pendekatan ini membantu mencegah berbagi kunci enkripsi di seluruh lingkungan dan membantu mengaktifkan 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 di project aplikasi.
- Kebijakan Identity and Access Management (IAM) diterapkan ke project atau folder untuk memungkinkan pemisahan tugas. Principal yang mengelola kunci Cloud KMS dalam project kunci Cloud KMS bukan principal yang sama dengan principal yang menggunakan kunci enkripsi dalam project aplikasi.
Buat key ring Cloud KMS untuk setiap lokasi
Anda harus membuat key ring Cloud KMS di lokasi tempat Anda men-deploy Cloud de Confiance resource yang dienkripsi dengan CMEK.
- Resource regional dan zona 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 mewajibkan penggunaan key ring dan kunci di region yang ditentukan, Anda juga mewajibkan agar resource cocok dengan region key ring.
Untuk beban kerja yang memerlukan kemampuan pemulihan dari bencana atau ketersediaan tinggi di beberapa lokasi, Anda bertanggung jawab untuk menilai apakah beban kerja Anda tangguh jika Cloud KMS tidak tersedia di wilayah tertentu. Misalnya, persistent disk Compute Engine yang dienkripsi dengan kunci Cloud KMS dari region A tidak dapat dibuat ulang di region B dalam skenario pemulihan dari bencana jika region A tidak tersedia. Untuk memitigasi risiko
skenario ini, Anda dapat merencanakan enkripsi resource dengan kunci global.
Pilih 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.
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.
Secara umum, kami merekomendasikan strategi perincian berikut:
- Setiap kunci melindungi resource di satu lokasi—misalnya,
us-central1. - Setiap kunci melindungi resource dalam satu layanan atau produk—misalnya, BigQuery.
- Setiap kunci melindungi resource dalam satu Cloud de Confiance project.
Rekomendasi ini mungkin bukan strategi perincian yang ideal untuk organisasi Anda. 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.
Jika Anda ingin mengikuti strategi perincian yang berbeda, pertimbangkan pertukaran pola yang berbeda berikut:
Kunci perincian tinggi—misalnya, satu kunci untuk setiap resource individu
- Kontrol yang lebih besar untuk menonaktifkan versi kunci dengan aman: Menonaktifkan atau menghancurkan versi kunci yang digunakan untuk cakupan sempit memiliki risiko yang lebih rendah untuk memengaruhi resource lain daripada menonaktifkan atau menghancurkan kunci bersama. Artinya juga bahwa penggunaan kunci yang sangat terperinci membantu mengurangi potensi dampak kunci yang disusupi dibandingkan dengan penggunaan kunci yang kurang terperinci.
- Biaya: Penggunaan kunci terperinci memerlukan pemeliharaan versi kunci yang lebih aktif jika dibandingkan dengan strategi yang menggunakan kunci dengan perincian yang lebih rendah. Granularitas kunci yang lebih tinggi memerlukan jumlah versi kunci aktif yang lebih besar, yang menimbulkan biaya tambahan.
- Overhead operasional: Penggunaan kunci yang sangat terperinci mungkin memerlukan upaya administratif atau alat tambahan untuk otomatisasi guna menyediakan sejumlah besar resource Cloud KMS dan mengelola kontrol akses untuk agen layanan sehingga mereka hanya dapat menggunakan kunci yang sesuai.
Kunci perincian rendah—misalnya, satu kunci untuk setiap aplikasi, untuk setiap wilayah, dan untuk setiap lingkungan:
- Memerlukan kehati-hatian untuk menonaktifkan versi kunci dengan aman: Menonaktifkan atau menghancurkan versi kunci yang digunakan untuk cakupan luas memerlukan kehati-hatian lebih besar 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 perincian rendah dapat meningkatkan potensi dampak dari kunci yang disusupi jika dibandingkan dengan penggunaan kunci dengan perincian tinggi.
- Biaya: Menggunakan kunci yang kurang terperinci memerlukan lebih sedikit versi kunci yang dibuat, sehingga menimbulkan biaya yang lebih rendah.
- Overhead operasional: Anda dapat menentukan dan melakukan pra-penyediaan sejumlah kunci yang diketahui, dengan upaya yang lebih sedikit 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 workload 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 Tentukan 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 tersebut disimpan di luar Cloud de Confiance?
- 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 Cloud de Confiancejika 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 yang dibuat di luar Cloud KMS secara manual. Cloud de ConfianceJika 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 pertimbangkan risiko dan pertimbangan operasional 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 mengurangi risiko kebocoran materi kunci mentah selama proses impor kunci?
- 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 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 utama ini selalu menggunakan algoritma GOOGLE_SYMMETRIC_ENCRYPTION, yang menggunakan kunci 256-bit Advanced Encryption Standard (AES-256) dalam Galois Counter Mode (GCM), yang di-padding dengan metadata internal Cloud KMS. Saat Anda menggunakan Autokey, setelan ini akan otomatis diterapkan untuk Anda.
Untuk kasus penggunaan lain seperti enkripsi sisi klien, tinjau tujuan dan algoritma kunci yang tersedia untuk memilih opsi yang paling sesuai dengan kasus penggunaan Anda.
Pilih periode rotasi
Sebaiknya Anda menilai 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.
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 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, sehingga membantu mengurangi risiko dan konsekuensi jika kunci disusupi.
Menerapkan kontrol akses yang sesuai
Sebaiknya Anda mempertimbangkan 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 ditentukan sebelumnya untuk mengurangi risiko insiden keamanan terkait akses dengan hak istimewa berlebih.
Merencanakan pemisahan tugas
Pertahankan identitas dan izin terpisah untuk orang yang mengelola kunci enkripsi Anda dan orang yang menggunakannya. NIST SP 800-152 mendefinisikan pemisahan tugas antara petugas kriptografi yang mengaktifkan dan mengelola layanan sistem pengelolaan kunci kriptografi dan pengguna yang menggunakan kunci tersebut untuk mengenkripsi atau mendekripsi resource.
Saat Anda menggunakan CMEK untuk mengelola enkripsi saat istirahat dengan layanan Cloud de Confiance , peran IAM untuk menggunakan kunci enkripsi ditetapkan ke agen layanan dari layanan Cloud de Confiance , bukan pengguna perorangan. 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 tertentu:
| Peran IAM | Deskripsi | Penetapan NIST SP 800-152 |
|---|---|---|
roles/cloudkms.admin |
Memberikan akses ke resource Cloud KMS, kecuali akses ke jenis resource terbatas dan operasi kriptografi. | 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 penghancuran yang tidak disengaja.
Menegakkan hak gadai project
Sebaiknya lindungi project dengan lien untuk menghindari penghapusan yang tidak disengaja. Jika 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 untuk membuat 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. 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.
Saat dijadwalkan untuk dimusnahkan, kunci tidak dapat digunakan untuk operasi kriptografis, dan setiap permintaan untuk menggunakan kunci 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 minimum 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 ini yang relevan untuk Cloud KMS.
Mengaktifkan dan menggabungkan logging audit
Sebaiknya gabungkan log audit Aktivitas Admin Cloud KMS (bersama dengan 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 yang terkait dengan pembuatan atau modifikasi resource Cloud KMS sekaligus. Untuk mendapatkan panduan tentang cara 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 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 Anda menentukan kasus penggunaan yang jelas untuk log tambahan dan menilai bagaimana biaya logging Anda akan meningkat.
Menilai persyaratan kepatuhan 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 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 mendapatkan panduan tentang cara layanan Cloud de Confiance 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 Cloud de Confiance resource 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 | Pertahankan izin terpisah untuk administrator utama 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. |