Arsitektur referensi untuk Cloud External Key Manager

Saat mengaktifkan Cloud Key Management Service (Cloud KMS) dengan Cloud External Key Manager (Cloud EKM), Anda dapat menggunakan kunci yang Anda kelola dengan partner pengelolaan kunci eksternal untuk membantu melindungi data di Google Cloud. Dokumen ini menjelaskan arsitektur untuk pelanggan Google Cloud yang ingin men-deploy layanan pengelola kunci enkripsi eksternal (EKM) dengan Cloud KMS dan Cloud EKM.

Menggunakan Cloud EKM dengan layanan EKM Anda melibatkan kompromi risiko eksplisit antara keandalan beban kerja cloud dan kontrol perlindungan data. Mengenkripsi data dalam penyimpanan di cloud dengan kunci enkripsi di luar cloud akan menambahkan risiko kegagalan baru yang dapat mengakibatkan data layanan Google Cloud menjadi tidak dapat diakses. Untuk mengatasi risiko ini, Anda harus menyertakan ketersediaan tinggi dan toleransi error ke dalam arsitektur Cloud EKM.

Ringkasan

Cloud EKM memungkinkan Anda menggunakan materi kunci yang tetap berada di luar Google Cloud untuk mengontrol akses ke data Anda yang disimpan di layanan Google Cloud yang didukung. Kunci EKM Cloud adalah kunci enkripsi yang dikelola pelanggan (CMEK). Cloud EKM memungkinkan Anda membuat dan mengelola resource kunci Cloud KMS menggunakan tingkat perlindungan EXTERNAL dan EXTERNAL_VPC. Saat Anda mengaktifkan Cloud EKM, setiap permintaan operasi kriptografis akan menghasilkan operasi kriptografis pada kunci eksternal. Keberhasilan operasi permintaan awal sangat bergantung pada hasil operasi kriptografis pada kunci eksternal.

Cloud KMS meminta operasi pada kunci eksternal menggunakan API tujuan khusus yang terintegrasi dengan sistem pengelolaan kunci eksternal Anda. Dokumen ini merujuk ke layanan yang menyediakan API ini sebagai layanan EKM.

Jika layanan EKM tidak tersedia, operasi baca dan tulis dari bidang data untuk layanan Google Cloud yang terintegrasi mungkin gagal. Kegagalan ini muncul dengan cara yang serupa dengan kegagalan saat kunci Cloud KMS dependen berada dalam status yang tidak dapat digunakan, misalnya, saat dinonaktifkan. Pesan error menjelaskan sumber error dan tindakan yang harus dilakukan. Selain itu, log audit akses data Cloud KMS menyertakan catatan pesan error ini beserta jenis error deskriptif. Untuk mengetahui informasi selengkapnya, lihat referensi error Cloud EKM.

Praktik terbaik untuk arsitektur Cloud EKM

Buku Site Reliability Engineering Google menjelaskan praktik terbaik untuk membantu memandu pengembangan dan pemeliharaan sistem yang andal. Bagian ini menjelaskan beberapa praktik ini dalam konteks cara layanan EKM Anda terintegrasi dengan Google Cloud. Praktik terbaik berikut berlaku untuk arsitektur referensi EKM Cloud:

• Mengonfigurasi konektivitas jaringan yang andal dan berlatensi rendah
• Aktifkan ketersediaan tinggi
• Mendeteksi dan memitigasi kegagalan dengan cepat

Mengonfigurasi konektivitas jaringan yang andal dan latensi rendah

Cloud KMS terhubung ke layanan EKM menggunakan jaringan Virtual Private Cloud (VPC) atau internet. Solusi VPC sering menggunakan konektivitas hibrida untuk menghosting layanan EKM di pusat data lokal. Koneksi antara Google Cloud dan pusat data harus cepat dan andal. Saat menggunakan internet, Anda memerlukan keterjangkauan yang stabil dan tidak terganggu serta resolusi DNS yang cepat dan andal. Dari sudut pandang Google Cloud, gangguan apa pun dapat mengakibatkan ketidaktersediaan layanan EKM dan potensi ketidakmampuan untuk mengakses data yang dilindungi EKM.

Saat bidang data layanan Google Cloud berkomunikasi dengan layanan EKM, setiap panggilan terikat layanan EKM memiliki periode waktu tunggu yang ditentukan (150 milidetik). Waktu tunggu diukur dari layanan Cloud KMS di lokasi kunci Cloud KMS Google Cloud . Jika lokasiGoogle Cloud adalah multi-region, waktu tunggu akan dimulai di region tempat Cloud KMS menerima permintaan, yang biasanya merupakan tempat operasi pada resource data yang dilindungi CMEK terjadi. Waktu tunggu ini cukup untuk memungkinkan layanan EKM menangani permintaan di wilayah Google Cloud terdekat tempat permintaan berasal.

Waktu tunggu membantu mencegah kegagalan beruntun di layanan downstream yang bergantung pada kunci enkripsi eksternal. Masalah latensi ekor yang biasanya dapat menyebabkan pengalaman pengguna yang buruk di aplikasi tingkat yang lebih tinggi sebenarnya dapat muncul sebagai akses yang gagal ke kunci eksternal yang mengakibatkan kegagalan operasi logika tingkat yang lebih tinggi.

Untuk meminimalkan latensi dan membuat jaringan yang andal, pertimbangkan hal berikut:

• Minimalkan latensi komunikasi bolak-balik dengan Cloud KMS: Konfigurasi layanan EKM untuk menayangkan permintaan sedekat mungkin secara geografis ke lokasi Google Cloud yang sesuai dengan kunci Cloud KMS yang dikonfigurasi untuk menggunakan layanan EKM. Untuk informasi selengkapnya, lihat Praktik terbaik untuk pemilihan region Compute Engine dan Region dan zona.
• Gunakan Cloud Interconnect jika memungkinkan: Cloud Interconnect membuat koneksi berlatensi rendah dan tersedia dengan baik antara Google Cloud dan pusat data Anda menggunakan jaringan VPC dan membantu menghapus dependensi pada internet.
• Deploy solusi jaringan Google Cloud di region yang paling dekat dengan layanan EKM, jika diperlukan: Idealnya, kunci Cloud KMS disimpan di region yang paling dekat dengan layanan EKM. Jika ada regionGoogle Cloud yang lebih dekat ke layanan EKM daripada region yang menyimpan kunci Cloud KMS, gunakan solusi jaringan Google Cloud , seperti Cloud VPN, di region yang paling dekat dengan layanan EKM. Opsi ini membantu memastikan bahwa traffic jaringan menggunakan infrastruktur Google jika memungkinkan, sehingga mengurangi ketergantungan pada internet.
• Gunakan jaringan Paket Premium saat traffic EKM melakukan transit melalui internet: Paket Premium merutekan traffic melalui internet menggunakan infrastruktur Google jika memungkinkan untuk meningkatkan keandalan dan mengurangi latensi.

Aktifkan ketersediaan tinggi

Adanya titik kegagalan tunggal di layanan EKM mengurangi ketersediaan resource Google Cloud dependen terhadap titik kegagalan tunggal. Titik kegagalan tersebut mungkin ada dalam dependensi kritis layanan EKM serta infrastruktur komputasi dan jaringan yang mendasarinya.

Untuk mengaktifkan ketersediaan tinggi, pertimbangkan hal berikut:

• Men-deploy replika di seluruh domain kegagalan independen: Men-deploy setidaknya dua replika layanan EKM. Jika Anda menggunakan lokasi multi-regional Google Cloud, deploy EKM di minimal dua lokasi geografis terpisah dengan minimal dua replika. Pastikan setiap replika tidak hanya mewakili bidang data yang direplikasi dari layanan EKM dengan meminimalkan dan memperkuat vektor kegagalan lintas replika. Perhatikan contoh berikut:
  • Konfigurasikan perubahan produksi, termasuk push biner dan konfigurasi server, untuk hanya mengubah satu replika dalam satu waktu. Pastikan semua perubahan dilakukan di bawah pengawasan, dengan rollback yang telah diuji tersedia.
  • Pahami dan minimalkan mode kegagalan lintas replika dari infrastruktur yang mendasarinya. Misalnya, pastikan replika bergantung pada catu daya independen dan redundan.

• Buat replika tangguh terhadap pemadaman satu mesin: Pastikan setiap replika layanan terdiri dari minimal tiga perangkat, mesin, atau host VM. Konfigurasi ini memungkinkan sistem menayangkan traffic saat satu mesin tidak berfungsi untuk update atau selama pemadaman layanan yang tidak terduga (penyediaan N+2).

  Catatan: Kunci eksternal di lokasi multi-regional Cloud KMS harus menggunakan internet karena layanan EKM tidak dapat mengakses lokasi multi-regional menggunakan Virtual Private Cloud. Untuk informasi selengkapnya, lihat Pengelola kunci enkripsi dan wilayah eksternal.

• Batasi area yang terpengaruh oleh masalah bidang kontrol: Konfigurasikan bidang kontrol (misalnya, pembuatan atau penghapusan kunci) layanan EKM untuk mereplikasi konfigurasi atau data di seluruh replika. Operasi ini umumnya lebih kompleks karena operasi ini memerlukan sinkronisasi dan memengaruhi semua replika. Masalah dapat menyebar dengan cepat untuk memengaruhi seluruh sistem. Beberapa strategi untuk mengurangi dampak masalah meliputi:

  • Kontrol kecepatan penyebaran: Secara default, pastikan perubahan menyebar selambat mungkin agar dapat diterima untuk kegunaan dan keamanan. Siapkan pengecualian jika diperlukan—misalnya, saat mengizinkan akses ke kunci untuk disebarkan dengan cepat agar pengguna dapat mengurungkan kesalahan.
  • Mempartisi sistem menjadi shard: Jika banyak pengguna berbagi EKM, bagi sistem menjadi shard logis yang sepenuhnya independen, sehingga masalah yang dipicu oleh pengguna di satu shard tidak dapat memengaruhi pengguna di shard lain.
  • Lihat pratinjau efek perubahan: Jika memungkinkan, izinkan pengguna melihat efek perubahan sebelum menerapkannya. Misalnya, saat mengubah kebijakan akses kunci, EKM dapat mengonfirmasi jumlah permintaan terbaru yang akan ditolak berdasarkan kebijakan baru.
  • Terapkan canary data: Pertama, kirim data hanya ke sebagian kecil sistem. Jika subkumpulan tetap sehat, kirim data ke seluruh sistem.

• Terapkan health check menyeluruh: Buat health check yang mengukur apakah sistem lengkap berfungsi. Misalnya, health check yang hanya memvalidasi konektivitas jaringan tidak membantu merespons banyak masalah tingkat aplikasi. Idealnya, health check mencerminkan dependensi untuk traffic sebenarnya dengan cermat.

• Menyiapkan failover di seluruh replika: Siapkan load balancing di komponen layanan EKM Anda sehingga menggunakan health check dan secara aktif menghabiskan traffic dari replika yang tidak responsif dan melakukan failover dengan aman ke replika yang responsif.

• Sertakan mekanisme keamanan untuk mengelola kelebihan beban dan menghindari kegagalan beruntun: Sistem mungkin mengalami kelebihan beban karena berbagai alasan. Misalnya, saat beberapa replika menjadi tidak responsif, traffic yang dialihkan ke replika yang responsif dapat membebaninya. Jika menerima lebih banyak permintaan daripada yang dapat ditayangkan, sistem harus mencoba menayangkan sebanyak mungkin dengan aman dan cepat, sekaligus menolak traffic berlebih.

• Memastikan kisah ketahanan yang andal: Data di Google Cloud yang dienkripsi dengan kunci eksternal di layanan EKM tidak dapat dipulihkan tanpa kunci eksternal. Oleh karena itu, ketahanan kunci adalah salah satu persyaratan desain utama layanan EKM. Konfigurasikan layanan EKM untuk mencadangkan salinan redundan materi kunci secara aman di beberapa lokasi fisik. Konfigurasikan langkah-langkah perlindungan tambahan, seperti pencadangan offline, untuk kunci bernilai tinggi. Pastikan mekanisme penghapusan Anda memberikan waktu untuk pemulihan jika terjadi kecelakaan dan bug.

Mendeteksi dan memitigasi kegagalan dengan cepat

Untuk setiap menit layanan EKM mengalami pemadaman, resource Google Cloud yang bergantung mungkin tidak dapat diakses, yang dapat semakin meningkatkan kemungkinan kegagalan beruntun komponen dependen lainnya dari infrastruktur Anda.

Untuk mendeteksi dan memitigasi kegagalan dengan cepat, pertimbangkan hal berikut:

• Konfigurasi layanan EKM untuk melaporkan metrik yang menandakan insiden yang mengancam keandalan: Siapkan metrik seperti rasio error respons dan latensi respons untuk mendeteksi masalah dengan cepat.
• Siapkan praktik operasional untuk notifikasi dan mitigasi insiden yang tepat waktu: Kuantifikasikan efektivitas praktik operasional dengan melacak metrik mean time to detect (MTTD) dan mean time to restore (MTTR), dan tentukan tujuan yang diukur oleh metrik ini. Dengan metrik ini, Anda dapat menemukan pola dan kekurangan dalam proses dan sistem saat ini sehingga dapat merespons insiden dengan cepat.

Arsitektur referensi untuk Cloud EKM

Arsitektur berikut menjelaskan beberapa cara untuk men-deploy layanan EKM menggunakan produk load balancing dan jaringanGoogle Cloud .

Koneksi langsung melalui Cloud VPN atau Cloud Interconnect

Koneksi langsung antara Google Cloud dan pusat data lokal Anda direkomendasikan saat Anda menjalankan aplikasi dengan throughput tinggi di Google Cloud dan layanan EKM berjalan di satu pusat data. Diagram berikut menunjukkan arsitektur ini.

Dalam arsitektur ini, Cloud EKM mengakses layanan EKM yang terletak di pusat data lokal melalui konektivitas hibrida di region tanpa load balancing perantara di Google Cloud.

Jika memungkinkan, deploy koneksi layanan Cloud EKM ke EKM menggunakan konfigurasi ketersediaan 99,9% untuk aplikasi region tunggal. Konfigurasi ketersediaan 99,99% memerlukan penggunaan Cloud Interconnect di beberapa region Google Cloud, yang mungkin tidak memenuhi kebutuhan Anda jika bisnis Anda memerlukan isolasi regional. Jika koneksi ke pusat data lokal menggunakan internet, gunakan VPN dengan ketersediaan tinggi (HA), bukan Cloud Interconnect.

Keuntungan utama arsitektur ini adalah tidak adanya hop perantara di Google Cloud, yang mengurangi latensi dan potensi bottleneck. Jika ingin menyiapkan koneksi langsung saat layanan EKM dihosting di beberapa pusat data, Anda harus mengonfigurasi load balancer di semua pusat data yang menggunakan alamat IP (anycast) yang sama. Jika Anda menggunakan konfigurasi ini, load balancing dan failover di antara pusat data hanya dibatasi pada ketersediaan rute.

Jika Anda menyiapkan jaringan VPC, kunci eksternal yang diakses melalui jaringan VPC harus menggunakan lokasi regional di Cloud KMS. Kunci tidak dapat menggunakan lokasi multi-regional. Untuk informasi selengkapnya, lihat Pengelola kunci enkripsi dan wilayah eksternal.

Load balancing dari internet di Google Cloud

Sebaiknya gunakan load balancer di Google Cloud dengan koneksi internet jika Anda memerlukan kunci Cloud KMS multi-regional. Diagram berikut menunjukkan arsitektur ini.

Dalam arsitektur ini, EKM memiliki replika di dua situs lokal. Setiap backend direpresentasikan di Google Cloud menggunakan grup endpoint jaringan konektivitas hibrida (NEG). Deployment menggunakan Load Balancer Jaringan proxy eksternal untuk meneruskan traffic langsung ke salah satu replika. Tidak seperti pendekatan lain, yang mengandalkan jaringan VPC, Load Balancer Jaringan proxy eksternal memiliki alamat IP eksternal, dan traffic berasal dari internet.

Setiap NEG konektivitas hybrid mungkin berisi beberapa alamat IP, yang memungkinkan Load Balancer Jaringan proxy eksternal menyeimbangkan traffic langsung ke instance layanan EKM. Load balancer tambahan di pusat data lokal tidak diperlukan.

Load Balancer Jaringan proxy eksternal tidak terikat dengan region tertentu. Cloud KMS dapat mengarahkan traffic masuk ke region responsif terdekat, sehingga cocok untuk kunci Cloud KMS multi-regional. Namun, load balancer tidak mengizinkan konfigurasi backend utama dan failover. Traffic didistribusikan secara merata di beberapa backend dalam satu region.

Di-load balance di jaringan VPC di Google Cloud

Penggunaan load balancer di Google Cloud dengan jaringan VPC direkomendasikan untuk sebagian besar layanan EKM tempat Anda men-deploy EKM. Diagram berikut menunjukkan arsitektur ini.

Dalam arsitektur ini, Cloud EKM mengakses layanan EKM yang direplikasi antara dua pusat data lokal melalui konektivitas hibrida dengan lapisan load balancing perantara di region Google Cloud . Jika koneksi ke pusat data lokal menggunakan internet, Anda dapat menggunakan VPN dengan ketersediaan tinggi (HA), bukan Cloud Interconnect.

Load Balancer Jaringan passthrough internal menyediakan satu alamat IP yang dapat digunakan resource untuk mengirim traffic menggunakan virtual networking. Load balancer beralih ke pusat data cadangan berdasarkan status backend.

Grup instance VM diperlukan untuk melakukan proxy traffic, karena load balancer internal tidak dapat merutekan traffic langsung ke backend lokal. Anda dapat men-deploy proxy load balancer untuk menjalankan image Docker Nginx dari Cloud Marketplace di grup instance. Anda dapat menggunakan Nginx sebagai load balancer TCP.

Karena pendekatan ini menggunakan load balancer di Google Cloud, Anda tidak memerlukan load balancer lokal. Load balancer Google Cloud dapat terhubung langsung ke instance layanan EKM dan menyeimbangkan beban di antara instance tersebut. Menghapus load balancer on-premise akan menghasilkan konfigurasi yang lebih sederhana, tetapi mengurangi fleksibilitas yang tersedia di layanan EKM. Misalnya, load balancer L7 lokal dapat otomatis mencoba ulang permintaan jika satu instance EKM menampilkan error.

Jika Anda menyiapkan jaringan VPC, kunci eksternal yang diakses melalui jaringan VPC harus menggunakan lokasi regional di Cloud KMS. Kunci tidak dapat menggunakan lokasi multi-regional. Untuk informasi selengkapnya, lihat Pengelola kunci enkripsi dan wilayah eksternal.

Perbandingan arsitektur referensi

Tabel berikut membandingkan opsi arsitektur referensi untuk Cloud EKM. Tabel ini juga menyertakan kolom untuk arsitektur EKM yang dikelola partner. Dalam skenario ini, partner bertanggung jawab untuk men-deploy dan mengelola EKM serta menyediakan EKM sebagai layanan kepada pelanggan.

Opsi	Koneksi langsung	Load balancing dari internet	Di-load balance di jaringan VPC	EKM terkelola sepenuhnya yang disediakan oleh partner
Jaringan internet atau VPC	VPC	Internet	VPC	Internet
Load balancer di Google Cloud	Tidak	Ya	Ya	Tidak
Load balancer on-premise diperlukan	Ya	Tidak	Tidak	Ya (dikelola oleh partner)
Mendukung lokasi Cloud KMS multi-regional	Tidak	Ya	Tidak	Ya
Direkomendasikan untuk	Aplikasi dengan throughput tinggi tempat layanan EKM berjalan di satu situs.	Jika kunci Cloud KMS multi-region diperlukan.	Sebagian besar layanan EKM tempat Anda men-deploy EKM Anda sendiri.	Anda dapat menggunakan EKM partner, bukan men-deploy EKM Anda sendiri.

Langkah selanjutnya

• Baca selengkapnya tentang keamanan Cloud KMS.
• Buat koneksi EKM melalui jaringan VPC.
• Menyiapkan Cloud EKM melalui internet.