Praktik terbaik untuk menggunakan CMEK

Halaman ini menjelaskan praktik terbaik untuk mengonfigurasi enkripsi dalam penyimpanan dengan kunci enkripsi yang dikelola pelanggan (CMEK) di resource Google 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 telah membaca pendalaman Cloud KMS.

Keputusan awal

Rekomendasi di halaman ini ditujukan untuk pelanggan yang menggunakan CMEK untuk mengenkripsi data mereka. Jika Anda tidak yakin apakah akan menggunakan CMEK yang dibuat secara manual atau otomatis sebagai bagian dari strategi keamanan, bagian ini memberikan panduan untuk keputusan awal ini.

Menentukan apakah akan menggunakan CMEK

Sebaiknya gunakan CMEK untuk mengenkripsi data dalam penyimpanan di layanan Google 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 Google 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.

Jika Anda tidak memerlukan kemampuan ini, evaluasi apakah enkripsi default saat data dalam penyimpanan dengan kunci yang dikelola Google sesuai untuk kasus penggunaan Anda. Jika memilih untuk hanya menggunakan enkripsi default, Anda dapat berhenti membaca panduan ini.

Memilih pembuatan kunci manual atau otomatis

Panduan ini menguraikan praktik terbaik untuk keputusan yang harus Anda buat saat menyediakan CMEK sendiri. Cloud KMS Autokey membuat beberapa keputusan ini untuk Anda dan mengotomatiskan banyak rekomendasi dari panduan ini. Menggunakan Autokey lebih mudah daripada menyediakan kunci sendiri, dan merupakan pilihan yang direkomendasikan jika kunci yang dibuat oleh Autokey memenuhi semua persyaratan Anda.

Autokey menyediakan CMEK untuk Anda. CMEK yang disediakan oleh Autokey memiliki karakteristik berikut:

  • Tingkat perlindungan: HSM.
  • Algoritma: AES-256 GCM.

  • Periode rotasi: Satu tahun.

    Setelah kunci dibuat oleh Autokey, administrator Cloud KMS dapat mengedit periode rotasi dari default.

  • Pemisahan tugas:
    • Akun layanan untuk layanan tersebut akan otomatis diberi izin enkripsi dan dekripsi pada kunci.
    • Izin administrator Cloud KMS berlaku seperti biasa untuk kunci yang dibuat oleh Autokey. Administrator Cloud KMS dapat melihat, memperbarui, mengaktifkan atau menonaktifkan, dan menghancurkan kunci yang dibuat oleh Autokey. Administrator Cloud KMS tidak diberi izin enkripsi dan dekripsi.
    • Developer kunci otomatis hanya dapat meminta pembuatan dan penetapan kunci. Mereka tidak dapat melihat atau mengelola kunci.
  • Kekhususan kunci atau tingkat perincian: Kunci yang dibuat oleh Autokey memiliki tingkat perincian yang bervariasi menurut jenis resource. Untuk mengetahui detail khusus layanan tentang perincian kunci, lihat Layanan yang kompatibel.

  • Lokasi: Autokey membuat kunci di lokasi yang sama dengan resource yang akan dilindungi.

    Jika Anda perlu membuat resource yang dilindungi CMEK di lokasi tempat Cloud HSM tidak tersedia, Anda harus membuat CMEK secara manual.

  • Status versi kunci: Kunci yang baru dibuat dan diminta menggunakan Kunci Otomatis dibuat sebagai versi kunci utama dalam status diaktifkan.
  • Penamaan key ring: Semua kunci yang dibuat oleh Autokey dibuat di key ring yang disebut autokey dalam project Autokey di lokasi yang dipilih. Key ring di project Autokey Anda dibuat saat developer Autokey meminta kunci pertama di lokasi tertentu.
  • Penamaan kunci: Kunci yang dibuat oleh Autokey mengikuti konvensi penamaan ini: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Ekspor kunci: Seperti semua kunci Cloud KMS, kunci yang dibuat oleh Autokey tidak dapat diekspor.
  • Pelacakan kunci: Seperti semua kunci Cloud KMS yang digunakan di layanan terintegrasi CMEK yang kompatibel dengan pelacakan kunci, kunci yang dibuat oleh Autokey dilacak di dasbor Cloud KMS.

Jika Anda memiliki persyaratan yang tidak dapat dipenuhi dengan kunci yang dibuat oleh Autokey, seperti tingkat perlindungan selain HSM atau layanan yang tidak kompatibel dengan Autokey, sebaiknya gunakan CMEK yang dibuat secara manual, bukan Autokey.

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.

Struktur folder dan project Cloud KMS yang direkomendasikan

Jika Anda menggunakan Kunci Otomatis Cloud KMS, setiap folder yang mengaktifkan Kunci Otomatis harus memiliki project kunci Cloud KMS khusus.

Membuat key ring Cloud KMS untuk setiap lokasi

Anda harus membuat key ring Cloud KMS di lokasi tempat Anda men-deploy resource Google 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 zona tunggal dan zona tidak dapat menggunakan key ring multi-region selain global.
  • Resource multi-region (seperti set data BigQuery di multi-region us) harus menggunakan key ring dan CMEK di multi-region atau dual-region yang sama. Resource multi-region tidak dapat menggunakan key ring regional.
  • 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 panduan tentang residensi data, lihat Menerapkan persyaratan residensi dan kedaulatan data.

Untuk beban kerja yang memerlukan ketersediaan tinggi atau kemampuan disaster recovery di beberapa lokasi, Anda bertanggung jawab untuk menilai apakah beban kerja Anda tangguh jika Cloud KMS tidak tersedia di region tertentu. Misalnya, disk persisten Compute Engine yang dienkripsi dengan kunci Cloud KMS dari us-central1 tidak dapat dibuat ulang di us-central2 dalam skenario disaster recovery saat us-central1 tidak tersedia. Untuk memitigasi risiko skenario ini, Anda dapat merencanakan enkripsi resource dengan kunci global.

Untuk informasi selengkapnya, lihat Memilih jenis lokasi terbaik.

Jika Anda menggunakan Autokey Cloud KMS, key ring akan dibuat untuk Anda di lokasi yang sama dengan resource yang Anda lindungi.

Memilih strategi tingkat perincian kunci

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 disediakan secara manual 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. Karena harga Cloud KMS didasarkan pada jumlah versi kunci aktif, memilih tingkat perincian kunci yang lebih tinggi akan menghasilkan biaya yang lebih tinggi.
  • 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. Jika Anda memerlukan kunci dengan tingkat perincian tinggi, Autokey mungkin merupakan pilihan yang tepat untuk mengotomatiskan penyediaan. Untuk mengetahui informasi selengkapnya tentang granularitas kunci Autokey untuk setiap layanan, lihat Layanan yang kompatibel.

Kunci dengan tingkat 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 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. Untuk banyak jenis resource, Anda dapat melihat penggunaan kunci untuk membantu mengidentifikasi tempat kunci telah digunakan. 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: Menggunakan kunci yang kurang terperinci memerlukan lebih sedikit versi kunci yang harus dibuat, dan harga Cloud KMS didasarkan pada jumlah versi kunci yang aktif.
  • 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:

  1. Apakah Anda memerlukan salah satu kemampuan CMEK? Anda dapat meninjau kemampuan yang tercantum di bagian Menentukan apakah akan menggunakan CMEK di halaman ini.

  2. Apakah Anda mewajibkan materi kunci tetap berada dalam batas fisik modul keamanan hardware (HSM)?

  3. Apakah Anda mewajibkan materi kunci disimpan di luar Google Cloud?

Autokey hanya mendukung tingkat perlindungan HSM. Jika memerlukan level perlindungan lain, Anda harus menyediakan kunci sendiri.

Gunakan materi kunci yang dibuat Google jika 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 dibuat di luar Google 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 disimpan di luar Google 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 mendasari kunci. 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 perkirakan 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.

Jika Anda menggunakan Autokey, kunci dibuat menggunakan periode rotasi kunci default selama satu tahun. Anda dapat mengubah periode rotasi untuk kunci setelah kunci dibuat.

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.

Pelanggaran terhadap prinsip ini dan masalah terkait dapat otomatis terdeteksi oleh temuan kerentanan Security Command Center untuk IAM.

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 Google Cloud, peran IAM untuk menggunakan kunci enkripsi ditetapkan ke agen layanan layanan Google 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 dalam project yang sama (seperti service-PROJECT_NUMBER@gs-project-accounts.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

Pelanggaran terhadap prinsip ini dan masalah terkait dapat dideteksi secara otomatis oleh temuan kerentanan Security Command untuk Cloud KMS.

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 restore 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

Google 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 yang terkait dengan 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.

Memantau penggunaan kunci

Anda dapat melihat penggunaan kunci dengan API inventaris Cloud KMS untuk membantu mengidentifikasi resource Google Cloud di organisasi Anda yang bergantung pada dan dilindungi oleh kunci Cloud KMS. Dasbor ini dapat digunakan untuk memantau status, penggunaan, dan ketersediaan versi kunci Anda serta resource terkait yang dilindunginya. Dasbor juga mengidentifikasi data yang tidak dapat diakses karena kunci yang dinonaktifkan atau dihancurkan sehingga Anda dapat mengambil tindakan seperti menghapus data yang tidak dapat diakses atau mengaktifkan kembali kunci.

Anda juga dapat menggunakan Cloud Monitoring dengan Cloud KMS untuk menetapkan notifikasi untuk peristiwa penting seperti menjadwalkan kunci untuk dihancurkan. Cloud Monitoring memberi Anda kesempatan untuk melakukan triage alasan operasi tersebut dilakukan dan memicu proses downstream opsional untuk memulihkan kunci jika diperlukan.

Sebaiknya buat rencana operasional untuk mendeteksi secara otomatis peristiwa yang Anda anggap penting dan tinjau dasbor penggunaan utama secara berkala.

Mengaktifkan Security Command Center untuk temuan kerentanan Cloud KMS

Security Command Center menghasilkan temuan kerentanan yang menyoroti kesalahan konfigurasi yang terkait dengan Cloud KMS dan resource lainnya. Sebaiknya aktifkan Security Command Center dan integrasikan temuan ini ke dalam operasi keamanan yang ada. Temuan ini mencakup masalah seperti kunci Cloud KMS yang dapat diakses secara publik, project Cloud KMS dengan peran owner yang terlalu permisif, atau peran IAM yang melanggar pemisahan tugas.

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 Google 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.
Memilih pembuatan kunci manual atau otomatis Gunakan Autokey Cloud KMS jika karakteristik kunci yang dibuat oleh Autokey memenuhi kebutuhan Anda.
Project kunci Cloud KMS Gunakan satu project kunci terpusat untuk setiap lingkungan. Jangan membuat resource Cloud KMS di project yang sama dengan resource Google Cloud yang dilindungi kunci.
Key ring Cloud KMS Buat key ring Cloud KMS untuk setiap lokasi tempat Anda ingin melindungi resource Google Cloud.
Perincian kunci Pilih pola tingkat perincian kunci yang sesuai dengan kebutuhan Anda, atau gunakan Autokey untuk menyediakan kunci secara otomatis dengan tingkat perincian yang direkomendasikan untuk setiap layanan.
Level perlindungan Pilih Cloud EKM jika materi kunci Anda harus disimpan di luar Google Cloud. Pilih Cloud HSM jika materi kunci Anda dapat dihosting di modul keamanan hardware (HSM) milik Google. Pilih kunci software jika kebutuhan Anda tidak memerlukan Cloud HSM atau Cloud EKM. Tinjau panduan untuk memilih tingkat perlindungan.
Key material Untuk materi kunci yang dihosting di Google Cloud, gunakan materi kunci yang dihasilkan Google jika 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 Mengelola 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.
Memantau penggunaan kunci Gunakan API inventaris Cloud KMS atau konsol Google Cloud untuk memahami penggunaan kunci. Secara opsional, gunakan Cloud Monitoring untuk menetapkan pemberitahuan untuk operasi sensitif seperti menjadwalkan kunci untuk dihancurkan.
Mengaktifkan Security Command Center untuk Cloud KMS Tinjau temuan kerentanan dan integrasikan peninjauan temuan kerentanan ke dalam operasi keamanan Anda.
Menilai persyaratan kepatuhan Tinjau arsitektur Cloud KMS Anda dan bandingkan dengan persyaratan kepatuhan yang harus Anda patuhi.

Langkah selanjutnya

  • Pelajari lebih lanjut cara Cloud KMS Autokey mengurangi upaya Anda untuk menggunakan CMEK secara konsisten.