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 Google Cloud pelanggan yang ingin men-deploy layanan pengelola kunci eksternal (EKM) dengan ketersediaan tinggi menggunakan Cloud KMS dan Cloud EKM.
Penggunaan Cloud EKM dengan layanan EKM Anda melibatkan pertukaran risiko yang jelas antara keandalan beban kerja cloud dan kontrol perlindungan data. Enkripsi data dalam penyimpanan di cloud dengan kunci enkripsi di luar cloud menambahkan risiko kegagalan baru yang dapat mengakibatkan Google Cloud data layanan menjadi tidak dapat diakses. Untuk mengatasi risiko ini, Anda harus memasukkan ketersediaan tinggi dan fault tolerance 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 yang didukung Google Cloud. Kunci Cloud EKM 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 kriptografi akan menghasilkan
operasi kriptografi pada kunci eksternal. Keberhasilan operasi permintaan awal sangat bergantung pada hasil operasi kriptografi pada kunci eksternal.
Cloud KMS meminta operasi pada kunci eksternal menggunakan API khusus yang terintegrasi dengan sistem pengelolaan kunci eksternal Anda. Dokumen ini merujuk ke layanan yang menyediakan API ini sebagai layanan EKM.
Jika layanan EKM menjadi tidak tersedia, operasi baca dan tulis dari bidang data untuk layanan Google Cloud yang terintegrasi mungkin gagal. Kegagalan ini muncul dengan cara yang serupa seperti kegagalan saat kunci Cloud KMS yang bergantung berada dalam status tidak dapat digunakan, misalnya, saat kunci dinonaktifkan. Pesan error menjelaskan sumber error dan tindakan yang harus dilakukan. Selain itu, log audit akses data Cloud KMS mencakup catatan pesan error ini bersama dengan jenis error deskriptif. Untuk mengetahui informasi selengkapnya, lihat Referensi error Cloud EKM.
Praktik terbaik untuk arsitektur Cloud EKM
Buku Site Reliability Engineering dari Google menjelaskan praktik terbaik untuk membantu memandu pengembangan dan pemeliharaan sistem yang andal. Bagian ini menjelaskan beberapa praktik tersebut dalam konteks cara layanan EKM Anda terintegrasi dengan Google Cloud. Praktik terbaik berikut berlaku untuk arsitektur referensi Cloud EKM:
- Mengonfigurasi konektivitas jaringan yang andal dan latensi 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 akses yang stabil dan tanpa gangguan serta resolusi DNS yang cepat dan andal. Dari sudut pandang Google Cloud, gangguan apa pun dapat mengakibatkan layanan EKM tidak tersedia dan berpotensi tidak dapat mengakses data yang dilindungi EKM.
Saat bidang data Google Cloud layanan berkomunikasi dengan layanan EKM, setiap panggilan yang terikat dengan layanan EKM memiliki periode waktu tunggu yang ditentukan (150 milidetik). Waktu tunggu diukur dari layanan Cloud KMS di Google Cloud lokasi kunci Cloud KMS. Jika Google Cloud lokasi 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 regionGoogle Cloud terdekat tempat permintaan berasal.
Waktu tunggu membantu mencegah kegagalan berjenjang di layanan hilir yang bergantung pada kunci eksternal. Masalah latensi ekor yang biasanya dapat menyebabkan pengalaman pengguna yang buruk dalam aplikasi tingkat yang lebih tinggi sebenarnya dapat muncul sebagai kegagalan akses ke kunci eksternal yang mengakibatkan kegagalan operasi logis tingkat yang lebih tinggi.
Untuk meminimalkan latensi dan membuat jaringan yang andal, pertimbangkan hal berikut:
- Minimalkan latensi komunikasi round-trip dengan Cloud KMS: Konfigurasi layanan EKM untuk melayani permintaan sedekat mungkin secara geografis dengan lokasi Google Cloud yang sesuai dengan kunci Cloud KMS yang dikonfigurasi untuk menggunakan layanan EKM. Untuk mengetahui 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 ketersediaan tinggi antara Google Cloud dan pusat data Anda menggunakan jaringan VPC serta membantu menghilangkan dependensi pada internet.
- Deploy Google Cloud solusi jaringan di region yang paling dekat dengan layanan EKM, jika perlu: Idealnya, kunci Cloud KMS disimpan di region yang paling dekat dengan layanan EKM. Jika ada regionGoogle Cloud yang lebih dekat dengan 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 ditransit melalui internet: Paket Premium merutekan traffic melalui internet menggunakan infrastruktur Google jika memungkinkan untuk meningkatkan keandalan dan mengurangi latensi.
- Gunakan batas waktu klien yang sesuai: Jika Anda memanggil Cloud KMS API secara langsung untuk kunci Cloud EKM, konfigurasikan batas waktu klien minimal 10 detik untuk memberikan waktu yang cukup bagi operasi kunci eksternal agar selesai.
Aktifkan ketersediaan tinggi
Adanya titik tunggal kegagalan dalam layanan EKM mengurangi ketersediaan resource Google Cloud yang bergantung pada titik tunggal kegagalan tersebut. Titik kegagalan tersebut mungkin ada dalam dependensi penting layanan EKM serta infrastruktur komputasi dan jaringan yang mendasarinya.
Untuk mengaktifkan ketersediaan tinggi, pertimbangkan hal berikut:
- Deploy replika di seluruh domain kegagalan independen: 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 di setiap lokasi. Pastikan setiap replika tidak hanya
merepresentasikan bidang data yang direplikasi dari layanan EKM dengan meminimalkan dan
memperkuat vektor kegagalan lintas replika. Perhatikan contoh berikut:
- Konfigurasi perubahan produksi, termasuk push biner dan konfigurasi server, untuk mengubah hanya satu replika dalam satu waktu. Pastikan semua perubahan dilakukan di bawah pengawasan, dengan rollback yang telah diuji dan siap digunakan.
- Memahami dan meminimalkan mode kegagalan lintas replika dari infrastruktur yang mendasarinya. Misalnya, pastikan replika bergantung pada suplai daya yang independen dan redundan.
Membuat replika tahan terhadap gangguan mesin tunggal: Pastikan setiap replika layanan terdiri dari minimal tiga peralatan, mesin, atau host VM. Konfigurasi ini memungkinkan sistem melayani traffic saat satu mesin tidak berfungsi karena update atau selama gangguan yang tidak terduga (penyediaan N+2).
Batasi area masalah bidang kontrol yang terpengaruh: Konfigurasi bidang kontrol (misalnya, pembuatan atau penghapusan kunci) layanan EKM untuk mereplikasi konfigurasi atau data di seluruh replika. Operasi ini umumnya lebih kompleks karena memerlukan sinkronisasi dan memengaruhi semua replika. Masalah dapat menyebar dengan cepat dan memengaruhi seluruh sistem. Beberapa strategi untuk mengurangi dampak masalah meliputi:
- Mengontrol kecepatan propagasi: Secara default, pastikan perubahan dipropagasi seperlunya untuk kegunaan dan keamanan. Siapkan pengecualian jika diperlukan—misalnya, saat mengizinkan akses ke kunci untuk disebarkan dengan cepat agar pengguna dapat mengurungkan kesalahan.
- Membagi sistem menjadi shard: Jika banyak pengguna berbagi EKM, bagi mereka menjadi shard logis yang sepenuhnya independen, sehingga masalah yang dipicu oleh pengguna di satu shard tidak dapat memengaruhi pengguna di shard lain.
- 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 kanarisasi data: Pertama-tama, kirim data hanya ke subkumpulan kecil sistem. Jika subset tetap berfungsi dengan baik, kirimkan data ke seluruh sistem.
Terapkan health check holistik: Buat health check yang mengukur apakah seluruh sistem berfungsi. Misalnya, health check yang hanya memvalidasi konektivitas jaringan tidak akan membantu dalam merespons banyak masalah tingkat aplikasi. Idealnya, health check mencerminkan dependensi untuk traffic sebenarnya.
Menyiapkan failover di seluruh replika: Siapkan load balancing di komponen layanan EKM Anda sehingga menggunakan health check dan secara aktif menghentikan 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 dapat mengalami kelebihan beban karena berbagai alasan. Misalnya, saat beberapa replika menjadi tidak responsif, traffic yang dialihkan ke replika yang responsif dapat membebani replika tersebut. Saat menghadapi lebih banyak permintaan daripada yang dapat dilayaninya, sistem harus mencoba melayani apa yang dapat dilayaninya dengan aman dan cepat, sambil menolak traffic berlebih.
Pastikan ketahanan yang kuat: Data di Google Cloud yang dienkripsi dengan kunci eksternal dalam layanan EKM tidak dapat dipulihkan tanpa kunci eksternal. Oleh karena itu, ketahanan kunci adalah salah satu persyaratan desain utama layanan EKM. Konfigurasi layanan EKM untuk mencadangkan salinan redundan materi kunci secara aman di beberapa lokasi fisik. Konfigurasi 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 gangguan, resource yang bergantung Google Cloud mungkin tidak dapat diakses, yang selanjutnya dapat meningkatkan kemungkinan kegagalan berjenjang pada komponen infrastruktur Anda yang bergantung lainnya.
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 pemberitahuan dan mitigasi insiden yang tepat waktu: Ukur efektivitas praktik operasional dengan melacak metrik waktu rata-rata untuk mendeteksi (MTTD) dan waktu rata-rata untuk memulihkan (MTTR), serta tentukan tujuan yang diukur berdasarkan metrik ini. Dengan menggunakan metrik ini, Anda dapat menemukan pola dan kekurangan dalam proses dan sistem saat ini sehingga Anda dapat merespons insiden dengan cepat.
Arsitektur referensi untuk Cloud EKM
Arsitektur berikut menjelaskan beberapa cara 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 berada di pusat data lokal melalui konektivitas hybrid di region tanpa load balancing perantara di Google Cloud.
Jika memungkinkan, deploy koneksi layanan EKM ke Cloud EKM menggunakan konfigurasi ketersediaan 99,9% untuk aplikasi region tunggal. Konfigurasi ketersediaan 99,99% memerlukan penggunaan Cloud Interconnect di beberapa Google Cloud region, 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) daripada Cloud Interconnect.
Keuntungan utama arsitektur ini adalah tidak ada hop perantara di Google Cloud, yang mengurangi latensi dan potensi hambatan. Jika Anda 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 yang sama (anycast). Jika Anda menggunakan konfigurasi ini, load balancing dan failover di antara pusat data hanya terbatas 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 mengetahui informasi selengkapnya, lihat Pengelola kunci eksternal dan wilayah.
Load balancing dari internet di Google Cloud
Penggunaan load balancer di Google Cloud dengan koneksi internet direkomendasikan jika Anda memerlukan kunci Cloud KMS multi-region. Diagram berikut menunjukkan arsitektur ini.
Dalam arsitektur ini, EKM memiliki replika di dua situs lokal. Setiap backend diwakili di Google Cloud menggunakan grup endpoint jaringan konektivitas hybrid (NEG). Deployment menggunakan Load Balancer Jaringan proxy eksternal untuk meneruskan traffic langsung ke salah satu replika. Tidak seperti pendekatan lainnya, yang mengandalkan jaringan VPC, Load Balancer Jaringan proxy eksternal memiliki alamat IP eksternal, dan traffic berasal dari internet.
Setiap NEG konektivitas hybrid dapat 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 ke region tertentu. Layanan ini dapat mengarahkan traffic masuk ke region responsif terdekat, sehingga cocok untuk kunci Cloud KMS multi-region. Namun, load balancer tidak mengizinkan konfigurasi backend utama dan failover. Traffic didistribusikan secara merata di beberapa backend dalam satu region.
Load balancing 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 hybrid 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) alih-alih Cloud Interconnect.
Load Balancer Jaringan passthrough internal menyediakan satu alamat IP yang dapat digunakan resource untuk mengirim traffic menggunakan jaringan virtual. Load balancer melakukan failover ke pusat data cadangan berdasarkan kesehatan backend.
Grup instance VM diperlukan untuk memproksi 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 dalam 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. Menghilangkan load balancer lokal 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 mengetahui informasi selengkapnya, lihat Pengelola kunci eksternal dan wilayah.
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 balanced dari internet | Load balanced di jaringan VPC | EKM terkelola sepenuhnya yang disediakan oleh partner |
|---|---|---|---|---|
Internet atau jaringan VPC |
VPC |
Internet |
VPC |
Internet |
Load balancer di Google Cloud |
Tidak |
Ya |
Ya |
Tidak |
Load balancer lokal diperlukan |
Ya |
Tidak |
Tidak |
Ya (dikelola oleh partner) |
Mendukung lokasi Cloud KMS multi-regional |
Tidak |
Ya |
Tidak |
Ya |
Direkomendasikan untuk |
Aplikasi dengan throughput tinggi yang menjalankan layanan EKM di satu situs. |
Saat kunci Cloud KMS multi-regional diperlukan. |
Sebagian besar layanan EKM tempat Anda men-deploy EKM Anda sendiri. |
Anda dapat menggunakan EKM partner, bukan men-deploy EKM Anda sendiri. |
Langkah berikutnya
- Baca selengkapnya tentang keamanan Cloud KMS.
- Buat koneksi EKM melalui jaringan VPC.
- Siapkan Cloud EKM melalui internet.