Praktik terbaik untuk menggunakan CMEK

Halaman ini menguraikan praktik terbaik untuk mengonfigurasi enkripsi saat istirahat 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 kunci enkripsi yang dikelola pelanggan serta telah membaca pembahasan mendalam tentang Cloud KMS.

Keputusan awal

Rekomendasi di halaman ini ditujukan bagi 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 tersebut.

Menentukan apakah akan menggunakan CMEK

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

  • Tetapkan kebijakan terkait tempat kunci Anda harus digunakan.

  • Menghapus data yang dilindungi oleh kunci Anda secara selektif jika terjadi penonaktifan atau untuk memulihkan peristiwa keamanan (penghancuran kripto).

  • 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.

Jika Anda tidak memerlukan kemampuan ini, evaluasi apakah enkripsi saat istirahat default dengan Google-owned and managed keys 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. Kunci Otomatis Cloud KMS membuat beberapa keputusan ini untuk Anda dan mengotomatiskan banyak rekomendasi dari panduan ini. Penggunaan Autokey lebih sederhana 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 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 Autokey hanya dapat meminta pembuatan dan penugasan kunci. Mereka tidak dapat melihat atau mengelola kunci.
  • Spesifisitas atau perincian kunci: Kunci yang dibuat oleh Autokey memiliki 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 Autokey dibuat sebagai versi kunci utama dalam status aktif.
  • Penamaan key ring: Semua kunci yang dibuat oleh Autokey dibuat dalam key ring bernama autokey di project Autokey di lokasi yang dipilih. Gantungan kunci 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
  • Pengeksporan kunci: Seperti semua kunci Cloud KMS, kunci yang dibuat oleh Autokey tidak dapat diekspor.
  • Pelacakan kunci: Seperti semua kunci Cloud KMS yang digunakan dalam layanan yang terintegrasi dengan 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 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.

Struktur folder dan project Cloud KMS yang direkomendasikan

Jika Anda menggunakan Autokey Cloud KMS, setiap folder yang Autokey-nya diaktifkan harus memiliki project kunci Cloud KMS khusus.

Buat key ring Cloud KMS untuk setiap lokasi

Anda harus membuat key ring Cloud KMS di lokasi tempat Anda men-deploy Google Cloud 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 zona dan satu region 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 mewajibkan penggunaan key ring dan kunci di region yang ditentukan, Anda juga mewajibkan agar resource cocok dengan region key ring. Untuk mendapatkan panduan tentang residensi data, lihat Mengontrol residensi data.

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.

Untuk mengetahui 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.

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

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 Google Cloud 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.

Kunci yang dibuat dengan Autokey Cloud KMS mengikuti rekomendasi ini.

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

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 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 perincian rendah dapat meningkatkan potensi dampak dari kunci yang disusupi jika dibandingkan dengan penggunaan kunci dengan perincian tinggi.
  • Biaya: Penggunaan kunci yang kurang terperinci memerlukan lebih sedikit versi kunci yang dibuat, dan harga Cloud KMS didasarkan pada jumlah versi kunci aktif.
  • 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:

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

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

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

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

Gunakan materi kunci yang dibuat Google Cloudjika memungkinkan

Bagian ini tidak berlaku untuk kunci Cloud EKM.

Saat membuat kunci, Anda harus mengizinkan Cloud KMS untuk membuat materi kunci untuk Anda atau mengimpor materi kunci yang dibuat di luar Cloud KMS secara manual. Google CloudJika 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 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 secara konsisten menghasilkan dan mengimpor materi kunci. 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 Google Cloud?
  • 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 dalam 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.

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

Pelanggaran terhadap prinsip ini dan masalah terkait dapat dideteksi secara otomatis 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 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 dalam penyimpanan dengan Google Cloud layanan, peran IAM untuk menggunakan kunci enkripsi ditetapkan ke agen layanan dari layanan Google Cloud , bukan pengguna individu. 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.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
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 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 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. 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

Google Cloud 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.

Memantau penggunaan kunci

Anda dapat melihat penggunaan kunci dengan Cloud KMS Inventory API untuk membantu Anda mengidentifikasi Google Cloud resource 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 ini juga mengidentifikasi data yang tidak dapat diakses karena kunci dinonaktifkan atau dihancurkan sehingga Anda dapat mengambil tindakan seperti menghapus data yang tidak dapat diakses atau mengaktifkan kembali kunci.

Anda dapat menggunakan Cloud Monitoring dengan Cloud KMS untuk menyetel pemberitahuan untuk peristiwa penting seperti menjadwalkan penghancuran kunci. Cloud Monitoring memberi Anda kesempatan untuk menyeleksi alasan operasi tersebut dilakukan dan memicu proses hilir 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 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 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 Google Cloud resource.
Perincian utama Pilih pola perincian kunci yang sesuai dengan kebutuhan Anda, atau gunakan Autokey untuk menyediakan kunci secara otomatis pada 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 Cloud. 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 dibuat Google Cloudjika 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.
Memantau penggunaan kunci Gunakan Cloud KMS Inventory API atau konsol Google Cloud untuk memahami penggunaan kunci. Secara opsional, gunakan Cloud Monitoring untuk menyetel pemberitahuan bagi operasi sensitif seperti menjadwalkan penghancuran kunci.
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 berikutnya