Mempelajari Cloud Key Management Service secara mendalam

Konten ini terakhir diperbarui pada Juli 2023, dan menampilkan status quo pada saat konten tersebut ditulis. Kebijakan dan sistem keamanan Google dapat berubah di masa mendatang, seiring upaya kami untuk terus meningkatkan perlindungan bagi pelanggan.

Google Cloud bekerja berdasarkan premis dasar bahwa pelanggan Google Cloud adalah pemilik data mereka dan harus mengontrol penggunaannya.

Saat Anda menyimpan data dengan Google Cloud, data Anda secara default dienkripsi dalam penyimpanan. Saat menggunakan platform Cloud Key Management Service (Cloud KMS), Anda dapat memperoleh kontrol yang lebih besar terkait cara data dienkripsi dalam penyimpanan dan cara kunci enkripsi dikelola.

Tabel berikut menjelaskan berbagai jenis kunci Google Cloud.

Jenis kunci	Pengelolaan kunci	Berbagi kunci	Rotasi otomatis	Harga
Kunci enkripsi default	Kunci ini sepenuhnya dikelola oleh Google.	Data dari beberapa pelanggan mungkin menggunakan kunci enkripsi kunci (KEK) yang sama.	Ya, lihat Enkripsi dalam penyimpanan default.	Gratis.
Kunci Cloud KMS	Kunci ini dikontrol oleh pelanggan.	Unik untuk pelanggan.	Ya untuk enkripsi simetris, tidak untuk kunci asimetris. Lihat Rotasi kunci.	Lihat Harga Cloud Key Management Service.

Dokumen ini berfokus pada cara kerja bagian dalam platform Cloud KMS. Opsi ini membantu Anda melindungi kunci dan data rahasia lainnya yang Anda simpan di Google Cloud. Dokumen ini ditujukan untuk pembuat keputusan teknis yang memerlukan detail tentang arsitektur, infrastruktur, dan fitur Cloud KMS. Dokumen ini mengasumsikan bahwa Anda memiliki pemahaman dasar tentang konsep enkripsi dan arsitektur cloud.

Pilar desain Cloud KMS

Dengan Cloud KMS, fokus Google adalah menyediakan solusi yang skalabel, andal, dan berperforma baik, dengan spektrum opsi terluas yang dapat Anda kontrol. Cloud KMS didukung oleh lima pilar desain berikut:

• Kontrol pelanggan: Dengan Cloud KMS, Anda dapat mengontrol kunci software dan hardware Anda sendiri untuk enkripsi dan penandatanganan. Pilar ini mencakup dukungan untuk model bring-your-own-keys (BYOK) dan hold-your-own-keys (HYOK).
• Kontrol dan pemantauan akses: Dengan Cloud KMS, Anda dapat mengelola izin atas kunci individual dan memantau cara kunci digunakan.
• Regionalitas: Cloud KMS menawarkan regionalisasi siap pakai. Layanan dikonfigurasi untuk membuat, menyimpan, dan memproses kunci hanya di lokasi Google Cloud yang Anda pilih.
• Cadangan: Untuk membantu mencegah kerusakan data dan memverifikasi bahwa data dapat berhasil didekripsi, Cloud KMS secara berkala memindai dan mencadangkan semua materi kunci dan metadata.
• Keamanan: Cloud KMS menawarkan perlindungan yang kuat terhadap akses ke kunci yang tanpa izin dan telah terintegrasi sepenuhnya dengan kontrol Identity and Access Management (IAM) dan Cloud Audit Logs.

Sumber dan opsi pengelolaan untuk materi kunci

Platform Cloud KMS dapat Anda gunakan untuk mengelola kunci kriptografis di layanan cloud pusat untuk penggunaan langsung atau untuk digunakan oleh resource dan aplikasi cloud lainnya.

Diagram berikut menunjukkan portofolio Google Cloud untuk kunci, yang disusun dari materi kunci yang dikontrol Google hingga materi kunci yang dikontrol pelanggan.

Opsi yang ditampilkan dalam diagram sebelumnya adalah sebagai berikut:

• Enkripsi default: Semua data yang disimpan oleh Google dienkripsi pada lapisan penyimpanan menggunakan algoritma Advanced Encryption Standard (AES), AES-256. Kami membuat dan mengelola kunci untuk enkripsi default, dan pelanggan tidak memiliki akses ke kunci tersebut atau kontrol rotasi dan pengelolaan kunci. Kunci enkripsi default dapat dibagikan di antara pelanggan. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dalam penyimpanan default.

• Cloud KMS dengan kunci yang dihasilkan oleh software: Dengan Cloud KMS, Anda dapat mengontrol kunci yang dihasilkan oleh Google. Backend software Cloud KMS memberi Anda fleksibilitas untuk mengenkripsi atau menandatangani data dengan kunci simetris atau asimetris yang Anda kontrol.

• Cloud KMS dengan kunci yang dihasilkan hardware (Cloud HSM): Dengan Cloud KMS yang dilengkapi backend Cloud HSM, Anda dapat memiliki kunci yang dibuat dan disimpan di modul keamanan hardware (HSM) yang dimiliki dan dioperasikan oleh Google. Jika memerlukan kunci yang dilindungi hardware, Anda dapat menggunakan backend Cloud HSM untuk membantu memastikan bahwa kunci simetris dan asimetris Anda hanya digunakan di FIPS 140-2 Level 3–HSM yang divalidasi.

• Cloud KMS dengan impor kunci: Untuk memenuhi persyaratan BYOK, Anda dapat mengimpor kunci kriptografis milik Anda yang Anda buat sendiri. Anda dapat menggunakan dan mengelola kunci ini di luar Google Cloud, serta menggunakan materi kunci di Cloud KMS untuk mengenkripsi atau menandatangani data yang Anda simpan di Google Cloud.

• Cloud KMS dengan pengelola kunci eksternal (Cloud EKM): Untuk memenuhi persyaratan HYOK, Anda dapat membuat dan mengontrol kunci yang disimpan dalam pengelola kunci yang berada di luar Google Cloud. Selanjutnya, siapkan platform Cloud KMS untuk menggunakan kunci eksternal guna membantu melindungi data dalam penyimpanan. Anda dapat menggunakan kunci enkripsi ini dengan kunci Cloud EKM. Untuk informasi lebih lanjut tentang pengelolaan kunci eksternal dan Cloud EKM, lihat Arsitektur referensi untuk deployment layanan Cloud EKM yang andal.

Anda dapat memilih untuk menggunakan kunci yang dihasilkan oleh Cloud KMS dengan layanan Google Cloud lainnya. Kunci tersebut dikenal sebagai kunci enkripsi yang dikelola pelanggan (CMEK). Dengan fitur CMEK, Anda dapat membuat, menggunakan, merotasi, dan menghancurkan kunci enkripsi yang membantu melindungi data di layanan Google Cloud lainnya.

Konsep enkripsi dan pengelolaan kunci di Google

Bagian ini menjelaskan beberapa istilah untuk pengelolaan kunci dalam konteks infrastruktur pengelolaan kunci berlapis Google.

Key ring, kunci, dan versi kunci

Diagram berikut mengilustrasikan pengelompokan kunci, serta menunjukkan key ring, dan kunci dengan satu versi utama dan beberapa versi sebelumnya.

Konsep utama yang ditampilkan dalam diagram sebelumnya adalah sebagai berikut:

• Kunci: Objek bernama yang mewakili kunci kriptografis yang digunakan untuk tujuan tertentu. Materi kunci—bit sebenarnya yang digunakan untuk operasi kriptografis—dapat berubah dari waktu ke waktu saat Anda membuat versi kunci baru. Anda dapat menetapkan kebijakan izin IAM pada level kunci dalam hierarki resource.

  Tujuan kunci dan atribut kunci lainnya dihubungkan dan dikelola menggunakan kunci tersebut. Dengan demikian, kunci adalah objek terpenting untuk memahami penggunaan KMS.

  Cloud KMS mendukung kunci asimetris dan kunci simetris. Kunci simetris digunakan untuk membuat atau memvalidasi tanda tangan MAC atau untuk enkripsi simetris guna melindungi beberapa korpus data. Misalnya, Anda dapat menggunakan AES-256 dalam mode GCM untuk mengenkripsi blok teks biasa. Kunci asimetris dapat digunakan untuk enkripsi asimetris atau penandatanganan asimetris. Untuk informasi selengkapnya, lihat Tujuan dan algoritma yang didukung.

• Key ring: Pengelompokan kunci untuk tujuan organisasi. Key ring termasuk dalam project Google Cloud dan berada di lokasi tertentu. Kunci mewarisi kebijakan izin dari key ring-nya. Dengan mengelompokkan kunci dengan izin yang terkait dalam key ring, Anda dapat memberikan, mencabut, atau mengubah izin ke kunci tersebut di level key-ring tanpa perlu mengambil tindakan pada setiap kunci satu per satu. Key ring memberikan kemudahan dan kategorisasi, tetapi jika pengelompokan key ring tidak berguna bagi Anda, Anda dapat mengelola izin langsung pada kunci. Tag memungkinkan Anda mengizinkan atau menolak kebijakan secara bersyarat berdasarkan apakah resource memiliki tag tertentu atau tidak. Anda dapat menerapkan tag pada level key ring dalam hierarki resource.

  Untuk mencegah konflik nama resource, Anda tidak dapat menghapus key ring atau kunci. Key ring dan kunci tidak memiliki biaya yang akan ditagihkan atau batasan kuota, sehingga kelanjutan keberadaannya tidak memengaruhi biaya atau batas produksi.

• Metadata kunci: Nama resource, properti resource KMS seperti kebijakan izin, jenis kunci, ukuran kunci, status kunci, dan data apa pun yang berasal dari kunci dan key ring.

• Versi kunci: Materi kunci yang terkait dengan kunci pada waktu tertentu. Versi kunci adalah resource yang berisi materi kunci sebenarnya. Versi diberi nomor secara berurutan, dimulai dengan versi 1. Saat kunci dirotasi, versi kunci baru akan dibuat dengan materi kunci baru. Kunci logis yang sama dapat memiliki beberapa versi dari waktu ke waktu, yang berarti data Anda dienkripsi menggunakan versi kunci yang berbeda. Kunci simetris memiliki versi utama. Secara default, versi utama digunakan untuk enkripsi. Saat menjalankan dekripsi menggunakan kunci simetris, Cloud KMS otomatis mengidentifikasi versi kunci mana yang diperlukan untuk melakukan dekripsi.

Hierarki kunci software

Diagram berikut mengilustrasikan hierarki kunci untuk Cloud KMS dan Keystore internal Google. Cloud KMS menggunakan Keystore, yang merupakan key management service internal Google, sebagai pelapis kunci yang dienkripsi Cloud KMS. Pelapisan kunci adalah proses mengenkripsi satu kunci menggunakan kunci lain agar dapat menyimpannya atau mengirimkannya melalui saluran yang tidak tepercaya. Cloud KMS menggunakan root of trust yang sama dengan Keystore.

Hierarki kunci yang ditampilkan dalam diagram sebelumnya adalah sebagai berikut:

1. Kunci enkripsi data (DEK) mengenkripsi potongan data.
2. Kunci enkripsi kunci (KEK) digunakan untuk mengenkripsi, atau memberikan lapisan pada, DEK. Semua opsi platform Cloud KMS (software, hardware, dan backend eksternal) memungkinkan Anda mengontrol KEK. KEK disimpan di Cloud KMS.
3. Kunci master KMS mengenkripsi KEK. Kunci master KMS disimpan di Keystore. Ada kunci master KMS terpisah di Keystore untuk setiap lokasi Cloud KMS. KEK di Cloud KMS dilindungi oleh kunci master KMS lokasi. Setiap server Cloud KMS mengambil salinan kunci master KMS selama startup sebagai dependensi tetap, dan salinan baru kunci master KMS diambil setiap hari. Kunci master KMS dienkripsi ulang secara berkala.
4. Kunci master KMS dilindungi oleh kunci master keystore di Keystore.
5. Kunci master keystore dilindungi oleh kunci master keystore root.

Untuk informasi selengkapnya tentang Keystore, lihat Pengelolaan kunci dalam Enkripsi saat penyimpanan eksternal.

Kendala operasional kunci

Cloud KMS beroperasi dalam batasan berikut:

• Project: Resource Cloud KMS termasuk dalam project Google Cloud, sama seperti semua resource Google Cloud lainnya. Anda dapat menghosting data dalam project yang berbeda dengan project tempat kunci Cloud KMS Anda berada. Untuk mendukung praktik terbaik pemisahan tugas antara administrator utama dan administrator data, Anda dapat menghapus peran pemilik dari project utama.
• Lokasi: Dalam sebuah project, resource Cloud KMS dibuat di sebuah lokasi. Untuk informasi selengkapnya tentang lokasi, lihat Geografi dan region.
• Konsistensi: Cloud KMS menyebarkan operasi pada kunci, key ring, dan versi kunci menggunakan konsistensi kuat atau konsistensi tertunda. Untuk mengetahui informasi lebih lanjut, baca Konsistensi resource Cloud KMS.

Ringkasan platform Cloud KMS

Platform Cloud KMS mendukung beberapa algoritma kriptografi dan menyediakan metode untuk mengenkripsi dan menandatangani secara digital menggunakan kunci yang didukung eksternal, hardware, dan software. Platform Cloud KMS terintegrasi dengan Identity and Access Management (IAM) dan Cloud Audit Logs sehingga Anda dapat mengelola izin pada masing-masing kunci dan mengaudit cara penggunaannya.

Diagram sebelumnya menunjukkan komponen utama dari platform Cloud KMS berikut:

• Administrator mengakses key management service menggunakan konsol Cloud atau Google Cloud CLI.

• Aplikasi mengakses key management service dengan mengimplementasikan REST API, gRPC, atau library klien. Aplikasi dapat menggunakan layanan Google yang diaktifkan untuk menggunakan CMEK. Selanjutnya, CMEK akan menggunakan Cloud Key Management Service API. Jika aplikasi Anda menggunakan PKCS #11, Anda dapat mengintegrasikannya dengan Cloud KMS menggunakan library untuk PKCS #11.

• Cloud KMS API memungkinkan Anda menggunakan software, hardware, atau kunci eksternal. Kunci berbasis software dan kunci berbasis hardware menggunakan perlindungan pencadangan redundan dari Google.

• Jika Anda menggunakan kunci hardware, HSM bersertifikasi FIPS 140-2 Level 3 di Google Cloud akan menyimpan kuncinya. Untuk informasi selengkapnya tentang sertifikasi kami, lihat Sertifikat #4399.

• Cloud KMS menggunakan datastore internal Google untuk menyimpan materi kunci pelanggan yang dienkripsi. Datastore ini sangat tersedia dan mendukung banyak sistem penting Google. Lihat Perlindungan Datastore.

• Secara berkala, sistem pencadangan independen mencadangkan seluruh datastore ke penyimpanan online dan arsip. Dengan cadangan ini, Cloud KMS dapat mencapai sasaran ketahanannya. Lihat Perlindungan Datastore.

Validasi FIPS 140-2

Operasi kriptografis Cloud KMS dilakukan oleh modul yang divalidasi FIPS 140-2 kami. Kunci dengan level perlindungan SOFTWARE, dan operasi kriptografis yang dilakukan dengannya, mematuhi FIPS 140-2 Level 1. Operasi kriptografi ini menggunakan BoringCrypto, yang merupakan library kriptografis open source yang dikelola oleh Google. Kunci dengan tingkat perlindungan HSM, dan operasi kriptografis yang dilakukan dengan kunci tersebut, mematuhi FIPS 140-2 Level 3.

Dependensi infrastruktur Google

Elemen platform Cloud KMS berjalan sebagai tugas Borg produksi. Borg adalah pengelola cluster berskala besar dari Google untuk menangani tugas pelayanan API dan tugas batch.

Untuk informasi tentang keamanan infrastruktur fisik dan produksi kami, lihat Ringkasan desain keamanan infrastruktur Google.

Tugas pelayanan Cloud KMS API

Tugas pelayanan Cloud KMS API adalah tugas Borg produksi yang melayani permintaan pelanggan untuk mengelola dan menggunakan kuncinya. Tugas pelayanan Cloud KMS API juga memproses tindakan yang ditangguhkan dari permintaan pelanggan, seperti merotasi kunci sesuai jadwal, membuat kunci asimetris, dan mengimpor kunci. Tugas pelayanan ini berjalan di setiap region Google Cloud tempat Cloud KMS tersedia. Setiap tugas dikaitkan dengan satu region dan dikonfigurasi untuk hanya mengakses data dari sistem yang secara geografis terletak dalam region Google Cloud tersebut terkait.

Tugas batch Cloud KMS

Platform Cloud KMS juga mempertahankan sejumlah tugas batch yang berjalan sebagai tugas Borg produksi pada berbagai jadwal. Tugas batch bersifat spesifik per region dan hanya data gabungan dari, dan dijalankan di dalam, region Google Cloud terkait. Tugas-tugas yang dilakukan pekerjaan ini meliputi:

• Menghitung kunci aktif untuk penagihan pelanggan.
• Menggabungkan resource dari public protocol buffer API untuk Cloud KMS dan meneruskan metadata ke Inventaris Aset Cloud. Resource dalam konteks ini adalah semua resource yang dikelola Cloud KMS—misalnya, kunci dan key ring.
• Menggabungkan semua resource dan informasi pelaporan untuk analisis bisnis.
• Mengambil data snapshot untuk ketersediaan tinggi.
• Memastikan bahwa semua data yang disimpan di datastore pokok tidak rusak.
• Mengenkripsi ulang materi kunci pelanggan saat Kunci Master KMS dirotasi.

Snapshotter kunci Cloud KMS

Untuk mempertahankan ketersediaan tetap tinggi, platform Cloud KMS mempertahankan datastore yang redundan di setiap instance layanan bersama yang menghosting tugas server Cloud KMS API. Setiap layanan bersama men-deploy instance layanan snapshotter-nya sendiri. Redundansi ini membuat layanan menjadi sangat independen, sehingga kegagalan di satu zona akan berdampak terbatas di zona lainnya. Saat tugas Cloud KMS API perlu melakukan operasi kriptografis, tugas ini akan mengkueri datastore utama bersama dengan tugas snapshotter lokal secara paralel. Jika datastore utama berjalan lambat atau tidak tersedia, respons dapat ditayangkan dari snapshot, jika durasi snapshot tersebut tidak lebih dari dua jam. Snapshot dibuat sebagai output dari tugas batch yang berjalan terus-menerus untuk setiap region. Snapshot berada di region cloud yang terkait dengan materi kunci.

Komunikasi klien-server

Google menggunakan Application Layer Transport Security (ALTS) untuk membantu memberikan keamanan bagi komunikasi klien-server yang menggunakan mekanisme remote procedure call (RPC) Google.

Untuk mengetahui informasi selengkapnya, lihat Autentikasi, integritas, dan enkripsi service-to-service.

Arsitektur platform Cloud KMS

Bagian ini menjelaskan detail arsitektur tentang keamanan material utama dan perlindungan datastore.

Keamanan materi kunci

Di Cloud KMS, materi kunci selalu dienkripsi dalam penyimpanan dan dalam pengiriman. Materi kunci didekripsi hanya dalam kasus berikut:

• Saat pelanggan menggunakannya.
• Saat kunci internal Google yang digunakan untuk melindungi materi kunci pelanggan dirotasi atau diperiksa integritasnya.

Permintaan pelanggan ke Cloud KMS dienkripsi saat dalam pengiriman menggunakan TLS antara pelanggan dan Google Front End (GFE).

Autentikasi berjalan di antara semua tugas Cloud KMS, baik di dalam maupun di antara pusat data Google.

Kebijakan Google adalah memastikan bahwa tugas hanya menggunakan kode sumber yang telah dibuat, diuji, dan ditinjau dengan cara yang dapat diverifikasi. Otorisasi Biner untuk Borg (BAB) menerapkan kebijakan ini pada tingkat operasional.

Tugas Cloud KMS API dapat mengakses metadata kunci (misalnya, kebijakan izinkan atau periode rotasi). Karyawan Google dengan justifikasi bisnis yang valid dan terdokumentasi (seperti bug atau masalah pelanggan) juga dapat mengakses metadata utama. Peristiwa akses ini dicatat ke dalam log secara internal, dan log yang berkaitan dengan data yang dicakup oleh Transparansi Akses juga tersedia untuk pelanggan yang memenuhi syarat.

Materi kunci yang didekripsi tidak dapat diekspor atau dilihat melalui antarmuka API atau antarmuka pengguna lainnya. Tidak ada karyawan Google yang memiliki akses ke materi kunci pelanggan yang tidak dienkripsi. Selain itu, materi kunci dienkripsi dengan kunci master di Keystore, yang tidak dapat diakses langsung oleh siapa pun. Pada HSM, materi kunci tidak pernah diakses dalam status terdekripsi oleh tugas Cloud KMS API.

Perlindungan Datastore

Penyimpanan data untuk Cloud KMS sangat tersedia, andal, dan terlindungi.

Ketersediaan. Cloud KMS menggunakan datastore internal Google, yang sangat tersedia dan mendukung sejumlah sistem penting Google.

Ketahanan. Cloud KMS menggunakan enkripsi yang diautentikasi untuk menyimpan materi kunci pelanggan di datastore. Selain itu, semua metadata diautentikasi menggunakan message authentication code berbasis hash (HMAC) untuk memastikan bahwa metadata tidak diubah atau rusak saat disimpan. Setiap jam, tugas batch memindai semua materi dan metadata kunci serta memverifikasi bahwa HMAC valid dan bahwa materi kunci tersebut dapat berhasil didekripsi. Jika ada data yang rusak, engineer Cloud KMS akan segera diberi tahu agar mereka dapat mengambil tindakan.

Cloud KMS menggunakan beberapa jenis cadangan untuk datastore:

• Secara default, datastore menyimpan histori perubahan setiap baris selama empat hari. Dalam keadaan darurat, masa aktif ini dapat diperpanjang untuk memberikan lebih banyak waktu guna menyelesaikan masalah.
• Setiap jam, datastore merekam snapshot. Snapshot dapat divalidasi dan digunakan untuk pemulihan, jika diperlukan. Snapshot ini disimpan selama empat hari.
• Setiap hari, pencadangan penuh disalin ke disk dan ke penyimpanan arsip.

Tim Cloud KMS telah mendokumentasikan prosedur untuk memulihkan cadangan guna mengurangi kehilangan data saat terjadi keadaan darurat pada sisi layanan.

Cadangan. Cadangan datastore Cloud KMS terletak di region Google Cloud yang terkait. Semua cadangan ini dienkripsi saat dalam penyimpanan. Akses ke data dalam cadangan dilindungi berdasarkan justifikasi akses (seperti nomor tiket yang Anda kirimkan ke dukungan Google), dan akses manusia dicatat dalam log Transparansi Akses.

Perlindungan. Pada lapisan aplikasi Cloud KMS, materi kunci Anda dienkripsi sebelum disimpan. Engineer yang memiliki akses ke datastore tidak memiliki akses ke materi kunci pelanggan dalam teks biasa. Selain itu, datastore mengenkripsi semua data yang dikelolanya sebelum menulis ke penyimpanan permanen. Oleh karena itu, akses ke lapisan penyimpanan yang mendasarinya, termasuk disk atau penyimpanan arsip, tidak mengizinkan akses, bahkan ke data Cloud KMS yang dienkripsi tanpa akses ke kunci enkripsi datastore, yang disimpan di Keystore.

Kebijakan rotasi. Rotasi kunci adalah bagian dari praktik terbaik yang diterima secara umum untuk menangani material kunci. Kebijakan rotasi ada untuk kunci yang digunakan untuk melindungi datastore Cloud KMS. Kebijakan rotasi kunci juga diterapkan ke kunci master Keystore yang melapisi kunci master Cloud KMS. Kunci master Keystore memiliki usia maksimum ciphertext terjadwal selama 90 hari dengan usia maksimum kunci yang di-cache klien selama satu hari. Cloud KMS memperbarui kunci master KMS dalam tugas KMS setiap 24 jam dan mengenkripsi ulang semua kunci pelanggan setiap bulan.

Residensi Data. Data yang mendasari setiap datastore Cloud KMS tetap berada secara eksklusif di dalam region Google Cloud yang terkait dengan data tersebut. Hal ini juga berlaku untuk lokasi yang berada di multi-region, misalnya multi-region us.

Ketersediaan kunci setelah pembuatan

Cloud KMS memungkinkan kunci untuk digunakan segera setelah datastore Cloud KMS meng-commit transaksi yang membuat kunci tersebut dan setelah lapisan penyimpanan mengonfirmasi pembuatannya.

Backend kunci

Saat membuat kunci dengan Cloud KMS, Anda dapat memilih tingkat perlindungan untuk menentukan backend kunci mana yang membuat kunci dan menjalankan semua backend kunci di masa mendatang operasi kriptografis pada kunci tersebut. Backend diekspos di Cloud KMS API sebagai tingkat perlindungan berikut:

• SOFTWARE: Berlaku untuk kunci yang dapat dibuka lapisannya oleh modul keamanan software untuk melakukan operasi kriptografis.
• HSM: Berlaku untuk kunci yang hanya dapat dibuka lapisannya oleh HSM yang melakukan semua operasi kriptografis dengan kunci tersebut.
• EXTERNAL atau EXTERNAL-VPC: Berlaku untuk pengelola kunci eksternal (EKM). EXTERNAL-VPC dapat digunakan untuk menghubungkan EKM ke Google Cloud melalui jaringan VPC.

Backend software Cloud KMS: Tingkat perlindungan SOFTWARE

Level perlindungan SOFTWARE berlaku untuk kunci yang operasi kriptografisnya dilakukan di software. Bagian ini menjelaskan detail cara penerapan level ini.

Implementasi algoritmik

Untuk kunci software, Cloud KMS menggunakan modul BoringCrypto (BCM) dalam implementasi BoringSSL Google untuk semua pekerjaan kriptografis yang terkait. BCM divalidasi FIPS 140-2. Biner Cloud KMS dibuat berdasarkan Primitif Kriptografis Tingkat 1 yang divalidasi FIPS 140-2 dari modul ini. Algoritma terbaru yang dicakup oleh modul ini tercantum pada Tujuan dan algoritma kunci, serta mencakup operasi enkripsi, dekripsi, dan tanda dengan kunci kriptografis simetris AES256-GCM, dan RSA 2048, RSA 3072, RSA 4096, EC P256, dan EC P384 asimetris.

Pembuatan dan entropi angka acak

Saat membuat kunci enkripsi, Cloud KMS menggunakan BoringSSL. FIPS 140-2 mengharuskan PRNG-nya sendiri digunakan (juga dikenal sebagai DRBG). Di BoringCrypto, Cloud KMS akan secara eksklusif menggunakan CTR-DRBG dengan AES-256. Hal ini memberikan output untuk RAND_bytes, antarmuka utama yang digunakan sistem lainnya untuk mendapatkan data acak. PRNG ini diisi dari RNG kernel Linux, yang disediakan dari beberapa sumber entropi independen. Pengisian ini mencakup peristiwa entropik dari lingkungan pusat data, seperti pengukuran terperinci pencarian disk dan waktu kedatangan antarpaket, serta instruksi RDRAND Intel jika tersedia. Untuk informasi selengkapnya tentang perilaku generator angka acak untuk BoringSSL (mode yang sesuai dengan FIPS), lihat desain RNG.

Backend Cloud HSM: Tingkat perlindungan HARDWARE

Cloud HSM menyediakan kunci yang didukung hardware ke Cloud KMS. Dengan API ini, Anda dapat menggunakan kunci kriptografi yang dilindungi oleh HSM tersertifikasi FIPS 140-2 Level 3 yang terkelola sepenuhnya di pusat data Google. Cloud HSM sangat tersedia dan menyediakan skala yang elastis, seperti Cloud KMS. Tidak ada perubahan aplikasi yang diperlukan untuk pelanggan Cloud KMS yang ada karena mereka dapat mengakses backend Cloud HSM menggunakan API dan library klien yang sama dengan Cloud KMS. Untuk mengetahui informasi selengkapnya tentang backend Cloud HSM, lihat arsitektur Cloud HSM.

Cloud EKM: Tingkat perlindungan EKSTERNAL

Dengan Cloud EKM, Anda dapat mengenkripsi data menggunakan kunci enkripsi di luar cloud yang tetap ada dalam kontrol Anda.

Kunci dengan tingkat perlindungan EXTERNAL dan EXTERNAL_VPC disimpan dan dikelola dalam sistem pengelolaan kunci eksternal. Untuk mengetahui informasi selengkapnya, lihat Arsitektur referensi untuk deployment layanan Cloud EKM yang andal.

Impor kunci

Anda mungkin ingin mengimpor kunci yang Anda buat sendiri di infrastruktur lokal atau di EKM ke lingkungan cloud Anda. Misalnya, Anda mungkin memiliki persyaratan peraturan bahwa kunci yang digunakan untuk mengenkripsi data cloud Anda dihasilkan dengan cara atau lingkungan tertentu. Impor kunci memungkinkan Anda mengimpor kunci ini dan memenuhi kewajiban peraturan. Untuk memperluas kemampuan penandatanganan ke cloud, Anda juga dapat mengimpor kunci asimetris.

Sebagai bagian dari impor kunci, Cloud KMS menghasilkan kunci pelapis publik yang merupakan pasangan kunci publik/pribadi, menggunakan salah satu metode impor yang didukung. Mengenkripsi material kunci Anda dengan kunci pelapis ini akan melindungi materi kunci saat sedang transit.

Anda dapat menggunakan kunci pelapis publik untuk mengenkripsi kunci yang akan diimpor di klien. Kunci pribadi yang cocok dengan kunci publik disimpan dalam Google Cloud dan digunakan untuk membuka lapisan kunci publik setelah mencapai project Google Cloud. Metode impor yang Anda pilih menentukan algoritma yang digunakan untuk membuat kunci pelapis. Setelah materi kunci diberi lapisan, Anda dapat mengimpornya ke dalam kunci atau versi kunci baru di Cloud KMS.

Anda dapat menggunakan kunci yang diimpor dengan tingkat perlindungan HSM atau SOFTWARE. Untuk Cloud HSM, bagian kunci pribadi dari kunci pelapis hanya tersedia dalam Cloud HSM. Membatasi bagian kunci pribadi ke Cloud HSM akan mencegah Google membuka lapiran materi kunci Anda di luar Cloud HSM.

Kunci enkripsi yang dikelola pelanggan (Customer-Managed Encryption Key/CMEK)

Secara default, Google Cloud mengenkripsi semua data pelanggan yang tersimpan dalam penyimpanan, dengan Google yang mengelola kunci yang digunakan untuk enkripsi. Untuk beberapa produk Google Cloud, Anda dapat menggunakan Cloud KMS guna mengelola kunci yang digunakan untuk enkripsi. CMEK dapat digunakan untuk kunci yang didukung eksternal, software, dan hardware. Dengan Cloud KMS, Anda dapat mengontrol banyak aspek kunci (seperti membuat, mengaktifkan, menonaktifkan, merotasi, dan menghancurkan kunci) serta mengelola izin IAM yang sesuai pada kunci tersebut. Untuk menerapkan pemisahan tugas yang direkomendasikan, Cloud KMS menyertakan beberapa peran IAM yang telah ditetapkan yang memiliki hak istimewa dan batasan khusus dan dapat diberikan kepada pengguna dan akun layanan tertentu.

Merotasi kunci Cloud KMS tidak akan mengenkripsi ulang data dalam layanan CMEK yang terkait. Sebaliknya, resource yang baru dibuat akan dienkripsi menggunakan versi kunci yang baru, yang berarti bahwa versi kunci yang berbeda melindungi subset data yang berbeda. Misalnya, BigQuery tidak otomatis merotasi kunci enkripsi tabel saat kunci Cloud KMS yang dikaitkan dengan tabel yang dirotasi. Tabel BigQuery yang sudah ada akan terus menggunakan versi kunci yang digunakan untuk membuat tabel tersebut. Tabel BigQuery baru menggunakan versi kunci saat ini. Untuk informasi selengkapnya, lihat dokumentasi untuk setiap produk.

Kebijakan organisasi CMEK memberikan kontrol yang lebih besar atas cara penggunaan CMEK dalam project Anda. Kebijakan ini memungkinkan Anda mengontrol layanan dan project yang menyimpan kunci yang diizinkan untuk CMEK.

Google Cloud mendukung CMEK untuk banyak layanan, termasuk Cloud Storage, BigQuery, dan Compute Engine. Lihat integrasi CMEK untuk mengetahui daftar lengkap integrasi CMEK dan layanan yang mematuhi CMEK. Google terus berinvestasi dalam integrasi CMEK untuk produk Google Cloud lainnya.

Siklus proses permintaan Cloud KMS

Bagian ini menjelaskan siklus proses permintaan Cloud KMS, termasuk diskusi tentang penghancuran materi kunci. Diagram berikut menunjukkan klien yang meminta akses ke instance layanan Cloud KMS di us-east1 dan us-west1, dan cara permintaan dirutekan menggunakan Google Front End (GFE).

Langkah-langkah dalam siklus proses ini meliputi:

1. Pelanggan, atau tugas yang berjalan atas nama pelanggan, menulis permintaan ke layanan Cloud KMS, https://cloudkms.googleapis.com. DNS akan menyalurkan alamat ini ke alamat IP anycast GFE.
2. GFE menyediakan hosting IP publik atas nama DNS publiknya, perlindungan denial of service (DoS), dan TLS termination. Saat pelanggan mengirim permintaannya, permintaan biasanya dirutekan ke GFE yang dekat dengan pelanggan, terlepas dari lokasi yang ditargetkan permintaan pelanggan. GFE menangani negosiasi TLS dan, dengan menggunakan URL dan parameter permintaan, menentukan Global Software Load Balancer (GSLB) yang merutekan permintaan tersebut.
3. Terdapat target GSLB terpisah untuk setiap region Cloud KMS. Jika permintaan tiba di Google dalam us-east1, dan permintaan ditujukan untuk us-west1, permintaan akan dirutekan antara pusat data us-east1 dan us-west1. Semua komunikasi antara pusat data dienkripsi selama pengiriman menggunakan ALTS, yang saling mengautentikasi tugas GFE dan Cloud KMS.
4. Saat permintaan mencapai tugas Cloud KMS, permintaan akan diproses terlebih dahulu oleh framework yang menangani sebagian besar pekerjaan yang umumnya dilakukan oleh semua layanan Google Cloud. Framework ini mengautentikasi pengguna dan melakukan sejumlah pemeriksaan untuk memverifikasi hal berikut:
   • Pelanggan memiliki kredensial yang valid dan dapat diautentikasi.
   • Project ini telah mengaktifkan Cloud KMS API dan memiliki akun penagihan yang valid.
   • Kuota cukup untuk menjalankan permintaan.
   • Pelanggan berada dalam daftar yang diizinkan untuk menggunakan region Google Cloud yang relevan.
   • Permintaan tidak ditolak oleh Kontrol Layanan VPC.
5. Setelah lulus pemeriksaan ini, framework akan meneruskan permintaan dan kredensial ke Cloud KMS. Cloud KMS akan mengurai permintaan untuk menentukan resource yang sedang diakses, lalu memeriksa dengan IAM untuk melihat apakah pemanggil diizinkan untuk membuat permintaan. IAM juga akan memberi tahu Cloud KMS apakah kemunculan permintaan harus ditulis ke log audit.
6. Setelah permintaan diautentikasi dan diberi otorisasi, Cloud KMS akan memanggil backend datastore dalam region untuk mengambil resource yang diminta. Setelah resource diambil, materi kunci pelanggan akan didekripsi untuk digunakan.
7. Dengan materi kunci, Cloud KMS kemudian akan melakukan operasi kriptografis, meneruskan versi kunci yang diberi lapisan ke backend software Cloud KMS, backend Cloud HSM, atau backend Cloud EKM, tergantung pada tingkat perlindungan kunci.
8. Setelah operasi kriptografis selesai, respons akan dikirim kembali kepada pelanggan bersama jenis saluran GFE-ke-KMS yang sama dengan permintaan.
9. Saat respons ditampilkan, Cloud KMS juga akan memicu beberapa peristiwa secara asinkron:
   • Log audit dan permintaan akan diisi dan dimasukkan dalam antrean untuk ditulis.
   • Laporan akan dikirim untuk tujuan penagihan dan pengelolaan kuota.
   • Jika permintaan tersebut memperbarui metadata resource, perubahan tersebut akan dikirim ke Inventaris Aset Cloud melalui pembaruan tugas batch.

Integritas data end-to-end

Cloud KMS dapat Anda gunakan untuk menghitung checksum kunci dan material kunci untuk membantu memastikan bahwa kunci dan material tersebut tidak rusak. Checksum ini membantu melindungi Anda dari kehilangan data yang mungkin disebabkan oleh kerusakan hardware atau software. Library helper memungkinkan Anda memverifikasi integritas kunci. Anda dapat menggunakan library helper untuk memverifikasi integritas kunci dengan memberikan checksum ke Cloud KMS yang diverifikasi oleh server. Selain itu, library ini juga memungkinkan Anda menerima checksum untuk memverifikasi data respons pada klien.

Integritas data menyeluruh membantu melindungi lingkungan Anda dari ancaman seperti berikut:

• Kerusakan selama transit; seperti pada tumpukan antara saat data dikirim dan saat data dilindungi oleh TLS.
• Masalah dalam proxy perantara antara endpoint dan KMS (misalnya, untuk permintaan masuk).
• Operasi kripto yang salah, kerusakan memori mesin, atau kerusakan HSM dalam arsitektur Cloud KMS.
• Kerusakan selama komunikasi dengan EKM eksternal.

Untuk informasi selengkapnya, lihat Memverifikasi integritas data menyeluruh.

Penghancuran materi kunci

Materi kunci dianggap sebagai data pelanggan, sehingga pendekatan yang dijelaskan dalam Penghapusan data di Google Cloud juga berlaku untuk Cloud KMS. Materi kunci dihancurkan sesuai permintaan, saat periode Dijadwalkan untuk dimusnahkan telah selesai dan cadangan berakhir. Materi kunci yang masih ada dalam cadangan (setelah periode dijadwalkan untuk dimusnahkan berakhir) hanya dapat digunakan untuk pemulihan dari bencana (disaster recovery) regional, bukan untuk memulihkan kunci individual. Proses ini tidak dijamin untuk salinan kunci yang diimpor yang ada di luar kontrol Cloud KMS.

Secara default, kunci dalam Cloud KMS menghabiskan waktu 24 jam dalam Dijadwalkan untuk dihancurkan (dihapus untuk sementara) sebelum materi kunci dihapus secara logis dari sistem. Anda dapat mengubah durasi ini. Untuk informasi selengkapnya, lihat Durasi variabel dari status Dijadwalkan untuk dimusnahkan.

Meskipun materi kunci dihancurkan, kunci dan key ring tidak dapat dihapus. Versi kunci juga tidak dapat dihapus, tetapi materi versi kunci dapat dihancurkan sehingga resource tidak dapat digunakan lagi. Key ring dan kunci tidak memiliki biaya atau batasan kuota yang dapat ditagih, sehingga keberadaannya tidak memengaruhi biaya atau batas produksi.

Setelah versi kunci dijadwalkan untuk dimusnahkan, versi kunci tersebut tidak akan tersedia untuk operasi kriptografis. Dalam periode penghapusan tertunda, Anda dapat memulihkan versi kunci agar tidak dihancurkan.

Jika tidak sengaja menghapus kunci yang diimpor, Anda dapat mengimpornya ulang. Untuk informasi selengkapnya, lihat Mengimpor ulang kunci yang dihancurkan.

Untuk menghindari penghapusan kunci secara tidak sengaja, pertimbangkan praktik terbaik berikut:

• Buat peran KMS kustom yang tidak menyertakan izin cloudkms.cryptoKeyVersions.destroy.
• Ubah kolom destroy_scheduled_duration ke jangka waktu yang lebih lama.

• Pantau dan tambahkan notifikasi jika ada peristiwa penghancuran kunci. Misalnya, buat filter Cloud Logging berikut:

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• Buat proses yang menonaktifkan kunci selama beberapa hari sebelum kunci dihapus.

Lingkungan operasional platform Cloud KMS

Lingkungan operasional untuk platform Cloud KMS mencakup kebijakan keamanan dan penyimpanan data, pembatasan akses, dan strategi mitigasi risiko yang dirancang untuk mengoptimalkan keandalan, ketahanan, dan ketersediaan sekaligus mengamankan materi kunci. Bagian ini membahas struktur operasi layanan, tanggung jawab atas anggota tim operasi, mekanisme autentikasi, serta protokol audit dan logging. Bagian ini berlaku untuk kemampuan kunci yang didukung software dan hardware.

Software engineer, site reliability engineer (SRE), dan operator sistem

Software engineer bertanggung jawab untuk berpartner dengan pemangku kepentingan lain, seperti product manager dan site reliability engineer (SRE) untuk mendesain sistem serta menulis banyak kode dan pengujian untuk layanan Cloud KMS. Kode ini mencakup tugas utama yang melayani permintaan pelanggan, serta tugas sekunder untuk aktivitas seperti replikasi data dan penagihan. SRE juga dapat menulis kode. Namun, software engineer dan tugas SRE terpisah; SRE pada dasarnya bertanggung jawab memelihara lingkungan produksi untuk tugas Cloud KMS. SRE mengukur dan mencapai keandalan melalui pekerjaan engineering dan operasi.

Operator sistem bertanggung jawab atas proses build dan rilis, pemantauan, pemberitahuan, dan perencanaan kapasitas untuk Cloud KMS. Mereka adalah tim tanggap darurat terhadap masalah pelanggan dan pemadaman layanan Cloud KMS. Misalnya, operator sistem memanfaatkan alat dan otomatisasi untuk meminimalkan pekerjaan sistem manual sehingga mereka dapat berfokus pada upaya yang memberikan nilai jangka panjang.

Tugas untuk operator sistem didefinisikan dalam prosedur operasi standar. Operator sistem tidak mengakses materi kunci pelanggan saat menjalankan tugas mereka.

Regionalitas resource Cloud KMS

Untuk membantu memenuhi persyaratan residensi utama, Anda dapat membuat resource Cloud KMS di salah satu dari empat jenis lokasi Google Cloud:

• Lokasi region terdiri dari zona di tempat geografis tertentu, seperti Iowa.
• Lokasi region ganda terdiri dari zona di dua tempat geografis tertentu, seperti Iowa dan South Carolina.
• Lokasi multi-region terdiri dari zona yang tersebar di wilayah geografis umum, seperti Amerika Serikat.
• Lokasi global terdiri dari beberapa zona yang tersebar di seluruh dunia. Saat Anda membuat resource Cloud KMS di lokasi global, resource tersebut tersedia dari zona di seluruh dunia.

Lokasi mewakili region geografis tempat penanganan permintaan ke Cloud KMS untuk resource tertentu, dan tempat kunci kriptografis yang terkait disimpan.

Untuk informasi lebih lanjut tentang lokasi Cloud KMS yang tersedia, lihat lokasi Cloud KMS.

Region cloud dan pusat data

Region Google Cloud berisi pusat data tertentu atau sekumpulan pusat data tertentu, yang ditentukan berdasarkan penetapannya sebagai satu region, region ganda, multi-region, atau global. Untuk mengetahui informasi selengkapnya tentang region Google Cloud, lihat lokasi Google Cloud.

Setiap pusat data berisi rak mesin untuk komputasi, jaringan, atau penyimpanan data. Mesin ini menjalankan infrastruktur Borg milik Google.

Pusat data Google memiliki persyaratan keamanan fisik yang ketat. Setiap ruang fisik yang mungkin berisi data pengguna memerlukan pintu masuk dengan pembaca badge dan pemindai iris yang digunakan untuk mengautentikasi peserta. Pintu tidak terbuka untuk beberapa orang; setiap orang harus mengautentikasi diri mereka secara individual. Tas tidak diizinkan untuk dibawa masuk atau keluar dari area ini, kecuali tas tersebut jelas, yang diizinkan secara eksplisit setelah diperiksa oleh petugas keamanan. Izin khusus diperlukan untuk membawa atau mengeluarkan perangkat elektronik yang mungkin mengirim atau merekam data.

Residensi kunci

Beberapa industri mengharuskan kunci kriptografis berada di lokasi tertentu. Cloud KMS memiliki persyaratan lokasi data dengan jaminan atas residensi data. Seperti yang diperkenalkan dalam Regionalitas resource Cloud KMS, Cloud KMS menawarkan empat jenis lokasi regional untuk membantu Anda memenuhi persyaratan tersebut.

Untuk lokasi tunggal, lokasi ganda, atau multi-region, Cloud KMS membuat, menyimpan, dan memproses kunci yang didukung software dan hardware serta materi kunci hanya di lokasi tersebut. Sistem penyimpanan dan pemrosesan data yang digunakan Cloud KMS dikonfigurasikan untuk hanya menggunakan resource dalam region Google Cloud yang terkait dengan materi kunci. Materi kunci yang dibuat di lokasi ganda atau multi-region tidak meninggalkan batas lokasi yang dipilih.

Untuk region global, tidak ada jaminan regional yang ditentukan.

Cloud KMS tidak menjamin residensi untuk metadata kunci, log penggunaan, atau untuk materi kunci dalam pengiriman. Metadata kunci mencakup nama resource; properti resource Cloud KMS seperti jenis kunci, ukuran kunci, dan status kunci; Kebijakan IAM; dan data apa pun yang berasal dari metadata.

Saat menggunakan CMEK, pembatasan geografis Cloud KMS berikut berlaku untuk kunci Anda, terlepas dari lokasi kustom, region ganda, atau multi-region yang Anda pilih di produk Google Cloud lain yang mendukung CMEK:

• Untuk region tertentu: Karena region kunci KMS yang dikelola pelanggan harus selalu berkorelasi dengan region resource yang dilindunginya dalam layanan Google Cloud tertentu, pembatasan residensi untuk kunci region tunggal dan resource dijamin kompatibel dan diterapkan.
• Untuk region ganda atau multi-region: Pengguna dapat memilih multi-region yang ditetapkan Google untuk kunci mereka dan resource Google Cloud guna menjamin kepatuhan residensi. Untuk memastikan residensi geografis ini, pastikan region Anda di produk lain sesuai dengan lokasi regional Cloud KMS yang Anda pilih.

Tabel berikut merangkum residensi materi kunci untuk Cloud KMS.

Jenis wilayah	Dalam penyimpanan, sedang digunakan
Satu region	Non-dinamis
Region ganda atau multi-region	Menetap di wilayah yang merupakan region ganda atau multi-region

Pemantauan regional

Layanan pemantauan data internal Google secara aktif memantau residensi kunci. Cloud KMS akan mengirimkan pemberitahuan kepada anggota tim SRE jika mendeteksi kesalahan konfigurasi yang tidak disengaja, atau jika materi kunci meninggalkan batas region yang dikonfigurasi, disimpan di region yang salah, atau diakses dari region yang salah.

Ketersediaan tinggi

Cloud KMS dapat membantu menyederhanakan persyaratan ketersediaan Anda berdasarkan region yang Anda pilih. Semakin terperinci lokasi, semakin banyak redundansi yang harus Anda buat. Untuk aplikasi dengan tingkat ketersediaan yang lebih tinggi, gunakan lokasi multi-region, ketimbang mencoba membuat sistem replikasi kunci Anda sendiri. Anda harus menyeimbangkan kemampuan redundansi bawaan dengan kebutuhan regionalisasi data Anda.

Autentikasi dan otorisasi

Cloud KMS menerima berbagai mekanisme autentikasi, seperti OAuth2, JWT, dan ALTS. Apa pun mekanismenya, Cloud KMS akan menyelesaikan kredensial yang diberikan untuk mengidentifikasi entity utama (entity yang diautentikasi dan memberikan otorisasi permintaan), dan memanggil IAM untuk melihat apakah entity utama tersebut diotorisasi untuk membuat permintaan dan apakah log audit akan ditulis atau tidak.

Cloud KMS menggunakan versi internal Service Control API publik untuk banyak aspek pengelolaan layanan. Sebelum tugas Cloud KMS menangani permintaan, tugas tersebut akan terlebih dahulu mengirimkan permintaan pemeriksaan ke Service Control API, yang menerapkan banyak kontrol yang sama untuk semua layanan Google Cloud, seperti berikut:

• Memeriksa apakah Anda telah mengaktifkan Cloud KMS API dan memiliki akun penagihan yang aktif.
• Memeriksa apakah Anda belum melebihi kuota, dan melaporkan penggunaan kuota.
• Menerapkan Kontrol Layanan VPC.
• Memeriksa apakah Anda tercantum dalam daftar yang diizinkan untuk region cloud pribadi yang berlaku.

Manajemen kuota

Cloud KMS memiliki batas penggunaan, yang disebut quotas, pada permintaan yang dibuat ke layanan. Cloud KMS berisi kuota berikut:

• Kuota Permintaan kriptografis untuk operasi seperti mengenkripsi, mendekripsi, atau menandatangani.
• Kuota permintaan baca untuk operasi seperti mendapatkan metadata kunci atau mendapatkan kebijakan IAM.
• Kuota permintaan tulis untuk operasi seperti membuat kunci atau menetapkan kebijakan IAM.

Kuota ini ditagihkan ke project yang terkait dengan pemanggil. Kuota ini juga bersifat global, yang berarti kuota tersebut diterapkan untuk penggunaan KMS oleh pemanggil di semua region dan multi-region. Kuota ini dievaluasi untuk semua level perlindungan.

Cloud HSM dan Cloud EKM memiliki kuota tambahan untuk operasi kriptografis. Kuota ini harus dipenuhi bersamaan dengan kuota permintaan kriptografis. Kuota Cloud HSM dan Cloud EKM ditagihkan ke project tempat kunci berada, dan kuota diberlakukan untuk setiap lokasi.

Perhatikan contoh berikut:

• Memanggil dekripsi dengan kunci software di asia-northeast1 memerlukan satu unit kuota permintaan kriptografis (global).
• Pembuatan kunci HSM di us-central1 memerlukan satu unit kuota permintaan tulis dan tanpa kuota HSM.
• Pemanggilan enkripsi dengan kunci EKM di europe memerlukan satu unit kuota permintaan kriptografis (global) dan satu unit kuota permintaan KMS eksternal di europe.

Untuk mengetahui informasi lebih lanjut tentang jenis kuota yang tersedia, lihat Kuota penggunaan resource Cloud KMS. Anda dapat melihat batas kuota di konsol Cloud. Batas kuota awal adalah batas lunak yang dapat Anda minta untuk disesuaikan berdasarkan kebutuhan workload Anda.

Logging

Ada tiga jenis log yang terkait dengan Cloud KMS: Log Audit Cloud, log Transparansi Akses, dan log permintaan internal.

Cloud Audit Logs

Cloud KMS mencatat aktivitas Anda di Cloud Audit Logs. Anda dapat melihat log ini di konsol Cloud. Semua aktivitas admin—misalnya, membuat atau menghancurkan kunci—dicatat dalam log ini. Anda juga dapat memilih untuk mengaktifkan logging untuk semua tindakan lain yang menggunakan kunci—misalnya, menggunakan kunci untuk mengenkripsi atau mendekripsi data. Anda dapat mengontrol berapa lama Anda ingin menyimpan log dan siapa saja yang dapat melihat log tersebut.

Log Transparansi Akses

Pelanggan yang memenuhi syarat dapat memilih untuk mengaktifkan log Transparansi Akses, yang memberi mereka log tindakan yang dilakukan karyawan Google di organisasi Google Cloud Anda. Log Transparansi Akses, beserta log dari Cloud Audit Logs, dapat membantu Anda menjawab pertanyaan tentang siapa yang melakukan apa, di mana, dan kapan.

Anda dapat mengintegrasikan log Transparansi Akses dengan alat informasi keamanan dan manajemen peristiwa (SIEM) yang sudah ada untuk mengotomatiskan audit Anda atas tindakan ini. Log ini tersedia di konsol Cloud bersama dengan Cloud Audit Logs Anda.

Entri log Transparansi Akses mencakup jenis detail berikut:

• Tindakan dan resource yang terpengaruh.
• Waktu tindakan.
• Alasan dilakukannya tindakan tersebut. Contoh alasannya mencakup dukungan yang dimulai pelanggan (dengan nomor kasus), dukungan yang dimulai Google, permintaan data pihak ketiga, dan permintaan peninjauan yang dimulai Google.
• Data tentang siapa yang bertindak pada data (misalnya, lokasi anggota staf Google).

Log permintaan internal

Log permintaan menyimpan data untuk setiap permintaan yang dikirim ke platform Cloud KMS. Data ini berisi detail tentang jenis permintaan (seperti metode atau protokol API), dan resource yang diakses (seperti nama resource, algoritma kunci, atau level perlindungan kunci). Log ini tidak menyimpan teks biasa, ciphertext, atau materi kunci pelanggan. Sebelum jenis data baru ditambahkan ke log ini, tim yang berspesialisasi dalam peninjauan privasi harus menyetujui perubahan pada data yang dicatat ke dalam log.

Entri log dihapus secara permanen saat time to live (TTL) yang dikonfigurasi telah berakhir.

SRE dan engineer Cloud KMS dalam rotasi on-call dapat mengakses log permintaan. Akses manusia ke log dan akses apa pun yang menampilkan data pelanggan memerlukan justifikasi bisnis yang valid dan terdokumentasi. Dengan beberapa pengecualian tertentu, akses manusia dicatat dan dapat diakses oleh pelanggan yang memenuhi syarat di log Transparansi Akses.

Monitoring

Cloud KMS terintegrasi dengan Cloud Monitoring. Dengan integrasi ini, Anda dapat memantau, membangun dasbor, dan membuat pemberitahuan di berbagai operasi Cloud KMS. Misalnya, Anda dapat memantau kapan kunci dijadwalkan untuk dimusnahkan, atau memantau dan menyesuaikan kuota Cloud KMS saat operasi kriptografis melewati ambang batas yang Anda tentukan. Untuk mengetahui informasi lebih lanjut tentang metrik Cloud KMS yang tersedia, lihat Menggunakan Cloud Monitoring dengan Cloud KMS.

Selain itu, Security Command Center memiliki pendeteksi kerentanan KMS bawaan. Pendeteksi ini membantu memastikan bahwa project Anda yang menyertakan kunci mengikuti praktik terbaik yang kami rekomendasikan. Untuk informasi lebih lanjut tentang pendeteksi kerentanan KMS, baca Temuan kerentanan untuk Cloud KMS.

Langkah selanjutnya

• Untuk mempelajari Cloud KMS lebih lanjut, pelajari referensi berikut:
  • Dokumentasi Cloud KMS
  • Dokumentasi Cloud HSM
• Untuk mengetahui informasi tentang cara menggunakan kunci enkripsi milik Anda di Google Cloud, lihat Kunci enkripsi yang dikelola pelanggan (CMEK).
• Pelajari cara Google mempersiapkan diri untuk dunia pasca-kuantum.
• Untuk mempelajari keamanan infrastruktur Google lebih lanjut, lihat Ringkasan desain keamanan infrastruktur Google.
• Untuk mengetahui informasi umum tentang keamanan Google Cloud, lihat bagian Keamanan di situs Google Cloud.