Enkripsi Cloud Key Management Service

Konten ini terakhir diperbarui pada Januari 2025, 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.

Dokumen ini menjelaskan cara Cloud Key Management Service (Cloud KMS) menyediakan layanan pengelolaan kunci di Google Cloud untuk enkripsi data dalam penyimpanan. Google Cloud berfungsi berdasarkan premis dasar bahwa Google Cloud pelanggan 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 KMS, Anda dapat memperoleh kontrol yang lebih besar terkait cara data dienkripsi dalam penyimpanan dan cara kunci enkripsi dikelola.

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.

Tombol di Google Cloud

Tabel berikut menjelaskan berbagai jenis kunci di Google Cloud.

Jenis kunci	Cloud KMS Autokey	Cloud KMS yang dikelola pelanggan (manual)	Google-owned and Google-managed encryption key (Enkripsi default Google)
Dapat melihat metadata kunci	Ya	Ya	Tidak
Kepemilikan kunci^1	Pelanggan	Pelanggan	Google
Dapat mengelola^2 dan mengontrol^3 kunci	Pembuatan dan penetapan kunci dilakukan secara otomatis. Kontrol manual pelanggan didukung sepenuhnya.	Pelanggan, hanya kontrol manual	Google
Mendukung persyaratan peraturan untuk kunci yang dikelola pelanggan	Ya	Ya	Tidak
Berbagi kunci	Unik untuk pelanggan	Unik untuk pelanggan	Data dari beberapa pelanggan biasanya dilindungi oleh kunci enkripsi kunci (KEK) bersama.
Kontrol rotasi kunci	Ya	Ya	Tidak
Kebijakan organisasi CMEK	Ya	Ya	Tidak
Mencatat akses administratif dan data ke kunci enkripsi	Ya	Ya	Tidak
Pemisahan data logis melalui enkripsi	Ya	Ya	Tidak
Harga	Bervariasi	Bervariasi	Gratis

¹ Pemilik kunci menunjukkan siapa yang memegang hak atas kunci tersebut. Kunci yang Anda miliki memiliki akses yang sangat dibatasi atau tidak ada akses oleh Google.

² Pengelolaan kunci mencakup tugas berikut:

• Membuat kunci.
• Pilih tingkat perlindungan kunci.
• Tetapkan otoritas untuk pengelolaan kunci.
• Mengontrol akses ke kunci.
• Mengontrol penggunaan kunci.
• Menetapkan dan mengubah periode rotasi kunci, atau memicu rotasi kunci.
• Mengubah status kunci.
• Menghancurkan versi kunci.

³ Kontrol kunci berarti menetapkan kontrol pada jenis kunci dan cara kunci digunakan, mendeteksi varian, dan merencanakan tindakan korektif jika diperlukan. Anda dapat mengontrol kunci, tetapi mendelegasikan pengelolaan kunci kepada pihak ketiga.

Prinsip 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 prinsip-prinsip 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.
• Pemisahan data logis: Enkripsi Cloud KMS menyediakan pemisahan data logis melalui enkripsi. Pemisahan data logis berarti pemilik data tidak berbagi kunci enkripsi (KEK dan DEK).

Sumber dan opsi pengelolaan untuk kunci kriptografis

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.

Portofolio Google Cloud untuk kunci mencakup hal 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 dilindungi software: Anda dapat mengontrol kunci yang dihasilkan di Cloud KMS. 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 dilindungi 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 Anda hanya digunakan di FIPS 140-2 Level 3–HSM yang divalidasi. Anda dapat menyediakan kunci yang dilindungi hardware menggunakan metode manual yang memerlukan administrator Cloud KMS atau secara otomatis menggunakan Cloud KMS Autokey. Autokey memungkinkan Anda mengotomatiskan proses penyediaan kunci dan penetapan kunci untuk kunci enkripsi yang dikelola pelanggan (CMEK). Kunci HSM konvensional mengharuskan administrator KMS membuat kunci berdasarkan permintaan.

• 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 luarGoogle 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 selengkapnya tentang pengelolaan kunci eksternal dan Cloud EKM, lihat Arsitektur referensi untuk Cloud EKM.

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

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

Diagram berikut mengilustrasikan hierarki kunci dan enkripsi amplop untuk Cloud KMS dan Keystore internal Google. Enkripsi envelope adalah proses mengenkripsi satu kunci menggunakan kunci lain, agar dapat menyimpannya atau mengirimkannya melalui saluran yang tidak tepercaya. Semua kunci dalam diagram ini adalah kunci simetris.

Dalam hierarki kunci, kunci enkripsi data (DEK) mengenkripsi potongan data. 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. Materi kunci tidak pernah keluar dari batas sistem Cloud KMS.

Untuk kunci yang dilindungi software, kunci master KMS khusus lokasi mengenkripsi KEK. Kunci master KMS disimpan di Keystore. Ada kunci master KMS terpisah di Keystore untuk setiap lokasi Cloud KMS. 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 menggunakan kunci master Keystore di Keystore. Kunci master Keystore dilindungi oleh kunci master Keystore root.

Untuk kunci yang dilindungi hardware, kunci pelapis HSM khusus lokasi mengenkripsi KEK, dan kunci pelapis HSM kemudian dienkripsi dengan kunci master KMS. Untuk mengetahui informasi selengkapnya, lihat Membuat kunci. Untuk kunci eksternal, kunci wrapper EKM mengenkripsi DEK yang dibungkus, dan kunci wrapper EKM kemudian dienkripsi dengan kunci master KMS.

Cloud KMS menggunakan Keystore, yang merupakan key management service internal Google, sebagai pelapis kunci yang dienkripsi Cloud KMS. Cloud KMS menggunakan root of trust yang sama dengan Keystore. Untuk informasi selengkapnya tentang Keystore, lihat Pengelolaan kunci dalam Enkripsi saat penyimpanan eksternal.

Batasan operasional

Cloud KMS beroperasi dalam batasan berikut:

• Project: Resource Cloud KMS termasuk dalam projectGoogle Cloud, sama seperti semua resource Google Cloudlainnya. Kunci Cloud KMS Anda dapat berada di project yang berbeda dengan data yang dilindungi kunci tersebut. Jika Anda menyimpan kunci dalam project yang sama dengan data yang dilindungi resource, untuk mendukung praktik terbaik pemisahan tugas antara administrator utama dan administrator data, Anda dapat menghapus peran pemilik dari project.
• 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.

Kunci enkripsi yang dikelola pelanggan

Secara default, Google Cloud mengenkripsi semua data pelanggan yang tersimpan dalam penyimpanan, dengan Google yang mengelola kunci yang digunakan untuk enkripsi. Untuk produk Google Cloud yang kompatibel yang terus-menerus menyimpan konten pelanggan Anda (misalnya, Cloud Storage), Anda dapat menggunakan Cloud KMS untuk mengelola kunci enkripsi yang dikelola pelanggan (CMEK). CMEK adalah kunci enkripsi yang Anda miliki dan dapat digunakan dengan kunci eksternal, kunci yang dilindungi software, dan kunci yang dilindungi hardware.

CMEK memungkinkan Anda memiliki kontrol yang lebih besar atas kunci yang digunakan untuk mengenkripsi data dalam penyimpanan dalam layanan Google Cloud yang kompatibel, dan memberikan batas kriptografis di sekitar data Anda. Anda dapat mengelola CMEK langsung di Cloud KMS, atau mengotomatiskan penyediaan dan penetapan menggunakan Autokey. Saat layanan menggunakan CMEK, workload Anda dapat mengakses resource dengan cara yang sama seperti saat Anda hanya menggunakan enkripsi default.

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.

Karena Cloud KMS menggunakan enkripsi amplop, CMEK adalah KEK yang mengenkripsi DEK. Untuk mengetahui informasi selengkapnya, lihat Hierarki kunci.

Rotasi CMEK berfungsi secara berbeda bergantung pada jenis resource yang dilindungi oleh kunci. Perhatikan contoh berikut:

• Di Spanner, versi kunci baru mengenkripsi ulang DEK.
• Untuk jenis resource lainnya, seperti bucket Cloud Storage, hanya resource yang baru dibuat yang dienkripsi menggunakan versi kunci yang baru, yang berarti bahwa versi kunci yang berbeda melindungi subset data yang berbeda.
• Dalam beberapa skenario, resource cloud harus dibuat ulang dengan versi kunci baru. Misalnya, secara default, BigQuery tidak otomatis memutar kunci enkripsi tabel saat kunci Cloud KMS yang terkait dengan tabel dirotasi. Tabel BigQuery yang sudah ada akan terus menggunakan versi kunci yang digunakan untuk membuat tabel tersebut.

Untuk informasi selengkapnya tentang rotasi kunci, 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, dan tingkat perlindungan untuk kunci tersebut.

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.

Cloud KMS Autokey

Autokey memungkinkan Anda menyederhanakan proses penyediaan CMEK. Selama proses penyediaan CMEK manual, administrator Cloud KMS harus merencanakan jenis key ring, kunci, dan akun layanan sebelum diperlukan dan berkoordinasi dengan developer untuk menyediakan kunci. Dengan Autokey, administrator Cloud KMS mendelegasikan otoritasnya kepada agen layanan Cloud KMS dalam project. Saat Anda mengaktifkan Autokey, developer dapat meminta kunci dari Cloud KMS, dan agen layanan akan menyediakan kunci yang tepat untuk intent developer. Dengan Autokey, kunci tersedia sesuai permintaan, konsisten, dan mengikuti praktik standar industri.

Autokey menyediakan dan menetapkan key ring, kunci, dan akun layanan sesuai permintaan saat developer membuat resource cloud tersebut, sekaligus menghormati pemisahan tugas. Penyediaan dan penetapan kunci mengikuti praktik dan rekomendasi standar industri untuk keamanan data, termasuk hal berikut:

• Level perlindungan HSM: Kunci yang dibuat menggunakan Autokey selalu kunci HSM sehingga disimpan di backend Cloud HSM. Kunci ini adalah kunci enkripsi AES-256 GCM.
• Pemisahan tugas: Untuk mempertahankan pemisahan tugas, identitas yang dapat menggunakan kunci untuk mengenkripsi dan mendekripsi berbeda dengan identitas yang mengelola kunci (termasuk rotasi, pemusnahan, atau perubahan statusnya).
• Rotasi kunci: Kunci dirotasi setiap tahun.
• Kolokasi kunci dengan resource: Kunci berada di lokasi yang sama dengan resource yang dilindungi oleh kunci.
• Kekhususan kunci: Kekhususan kunci sesuai untuk jenis resource yang dilindungi kunci, berdasarkan per jenis resource. Spesifitas berarti Anda tidak perlu meninjau jenis resource setiap layanan secara manual dan menentukan jumlah setiap jenis resource yang harus dilindungi oleh satu kunci.

Kunci yang diminta menggunakan Autokey berfungsi sama dengan kunci Cloud HSM lainnya dengan setelan yang sama. Autokey menyederhanakan penggunaan Terraform karena tidak perlu menjalankan infrastruktur sebagai kode dengan hak istimewa pembuatan kunci yang ditingkatkan. Autokey tersedia di semua lokasiGoogle Cloud tempat Cloud HSM tersedia.

Kunci otomatis hanya tersedia untuk resource Google Cloud tertentu. Untuk informasi selengkapnya, lihat Ringkasan kunci otomatis.

Arsitektur dan komponen platform Cloud KMS

Platform Cloud KMS mendukung beberapa algoritma kriptografi dan menyediakan metode untuk mengenkripsi dan menandatangani secara digital menggunakan kunci eksternal, kunci yang dilindungi hardware, dan kunci yang dilindungi 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. Anda dapat membuat dan mengelola kunci yang dilindungi software dan dilindungi hardware menggunakan endpoint layanan Cloud KMS. Kunci yang dilindungi software dan kunci yang dilindungi hardware menggunakan perlindungan pencadangan redundan dari Google.

• Jika Anda menggunakan kunci yang dilindungi hardware, HSM bersertifikasi FIPS 140-2 Level 3 di Google Cloud akan menyimpan kunci tersebut. 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.

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 dan tingkat perlindungan

Saat membuat kunci dengan Cloud KMS, Anda dapat memilih tingkat perlindungan untuk menentukan backend kunci mana yang membuat kunci dan menjalankan semua operasi kriptografis di masa mendatang 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 dalam implementasi BoringSSL Google untuk semua pekerjaan kriptografis yang terkait. Modul BoringCrypto divalidasi FIPS 140-2. Biner Cloud KMS dibuat berdasarkan primitif kriptografis yang divalidasi FIPS 140-2 Level 1 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 dilindungi 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. Anda 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 Cloud EKM.

Proses pembuatan kunci

Diagram berikut mengilustrasikan proses pembuatan kunci untuk berbagai backend kunci dan tingkat perlindungan.

Proses pembuatan kunci mencakup hal-hal berikut:

1. Dengan menggunakan Cloud KMS API, pengguna meminta Cloud KMS untuk membuat kunci. Permintaan ini mencakup tingkat perlindungan (baik kunci dilindungi software, dilindungi hardware, atau eksternal).
2. Cloud KMS memverifikasi identitas pengguna dan apakah pengguna memiliki izin untuk membuat kunci.
3. Kunci dibuat sebagai berikut:
   • Untuk kunci yang dilindungi software, Cloud KMS akan membuat kunci pelanggan.
   • Untuk kunci yang dilindungi hardware, Cloud KMS mengirimkan permintaan ke Cloud HSM. Cloud HSM mengirimkan permintaan ke HSM untuk membuat kunci baru. HSM membuat kunci pelanggan dan mengenkripsi (menggabungkan) kunci ini dengan kunci gabungan regional HSM. Cloud HSM mengirim kunci yang digabungkan kembali ke Cloud KMS.
   • Untuk kunci eksternal, Cloud KMS mengirimkan permintaan ke Cloud EKM. Cloud EKM mengirimkan permintaan ke pengelola kunci eksternal untuk membuat kunci baru. EKM membuat kunci baru dan mengenkripsi kunci ini dengan kunci gabungan EKM. Cloud EKM mengirim kunci yang digabungkan kembali ke Cloud KMS.
4. Cloud KMS mengenkripsi kunci pelanggan yang digabungkan dengan kunci master KMS dan mengirimkannya ke datastore KMS untuk disimpan.
5. Cloud KMS mengirimkan respons berhasil dengan URI lengkap untuk versi kunci kepada pengguna.

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

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. Personel di organisasi Anda atau tugas yang berjalan atas nama organisasi Anda akan 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 Anda mengirim permintaan, permintaan tersebut biasanya dirutekan ke GFE yang dekat dengan Anda, terlepas dari lokasi yang ditargetkan permintaan Anda. 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 GFE di 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 layananGoogle Cloud . Framework ini mengautentikasi akun dan melakukan sejumlah pemeriksaan untuk memverifikasi hal berikut:
   • Akun 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.
   • Akun tersebut berada dalam daftar yang diizinkan untuk menggunakan wilayahGoogle 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 menunjukkan apakah kemunculan permintaan harus ditulis ke log audit. Jika Key Access Justifications diaktifkan, notifikasi justifikasi akan dikirim dan Anda harus menyetujuinya.
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 Anda 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, bergantung pada tingkat perlindungan kunci.
8. Setelah operasi kriptografis selesai, respons akan dikirim kembali kepada Anda bersama jenis saluran GFE-ke-KMS yang sama dengan permintaan.
9. Saat respons ditampilkan, Cloud KMS juga akan memicu peristiwa berikut 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 30 hari dalam status 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:

• Tetapkan batasan Durasi minimum pemusnahan terjadwal per kunci ke durasi yang lebih lama. Batasan ini menentukan jumlah waktu minimum untuk periode dijadwalkan untuk dihancurkan untuk kunci baru.
• Terapkan batasan Restrict key destruction to disabled keys sehingga hanya kunci yang dinonaktifkan yang dapat dihancurkan. Untuk informasi selengkapnya, lihat Mewajibkan kunci untuk dinonaktifkan sebelum dihancurkan.
• 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.

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 regionGoogle Cloud tempat Cloud KMS tersedia. Setiap tugas dikaitkan dengan satu region dan dikonfigurasi untuk hanya mengakses data dari sistem yang secara geografis terletak dalam regionGoogle Cloud 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 Cloudterkait. 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.

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 dilindungi 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 lokasiGoogle 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 informasi selengkapnya tentang Google Cloud region, lihat lokasiGoogle 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 dilindungi software dan hardware serta materi kunci hanya di lokasi tersebut. Sistem penyimpanan dan pemrosesan data yang digunakan Cloud KMS dikonfigurasi untuk hanya menggunakan resource dalam regionGoogle 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 dan resource region tunggal dijamin kompatibel dan diterapkan.
• Untuk lokasi dual-region atau multi-region: Pengguna dapat memilih multi-region yang ditetapkan Google untuk kunci dan resource mereka guna menjamin kepatuhan residensi. Google CloudUntuk 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 kuota, 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—catat 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 organisasiGoogle 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 berikutnya

• 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).
• Untuk mempelajari keamanan infrastruktur Google lebih lanjut, lihat Ringkasan desain keamanan infrastruktur Google.