Ringkasan keamanan Cloud Service Mesh
Cloud Service Mesh dengan keamanan Istio API membantu Anda memitigasi ancaman orang dalam dan mengurangi risiko pelanggaran data dengan memastikan bahwa semua komunikasi antar-workload dienkripsi, diautentikasi dua arah, dan diotorisasi.
Secara tradisional, segmentasi mikro yang menggunakan aturan berbasis IP telah digunakan untuk mitigasi risiko pihak internal. Namun, penggunaan penampung, layanan bersama, dan lingkungan produksi terdistribusi yang tersebar di beberapa cloud membuat pendekatan ini lebih sulit dikonfigurasi dan bahkan lebih sulit dikelola.
Dengan Cloud Service Mesh, Anda dapat mengonfigurasi lapisan keamanan jaringan berbasis konteks layanan dan berbasis konteks permintaan yang independen dari keamanan jaringan yang mendasarinya. Oleh karena itu, Cloud Service Mesh memungkinkan Anda mengadopsi postur pertahanan menyeluruh yang konsisten dengan prinsip keamanan Zero Trust. Hal ini memungkinkan Anda mencapai postur ini melalui kebijakan deklaratif dan tanpa mengubah kode aplikasi apa pun.
TLS bersama
Cloud Service Mesh menggunakan TLS timbal balik (mTLS) untuk autentikasi peer. Autentikasi mengacu pada identitas: siapa layanan ini? siapa pengguna akhir ini? dan dapatkah saya memercayai bahwa mereka adalah orang yang mereka katakan?
mTLS memungkinkan workload memverifikasi identitas satu sama lain dan melakukan autentikasi satu sama lain. Anda mungkin sudah terbiasa dengan TLS sederhana melalui penggunaannya di HTTPS untuk memungkinkan browser memercayai server web dan mengenkripsi data yang ditukarkan. Saat TLS sederhana digunakan, klien menetapkan bahwa server dapat dipercaya dengan memvalidasi sertifikatnya. mTLS adalah implementasi TLS yang menampilkan sertifikat kepada klien dan server, serta memverifikasi identitas satu sama lain.
mTLS adalah cara Cloud Service Mesh menerapkan autentikasi dan enkripsi antarlayanan.
Di Cloud Service Mesh, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy sidecar klien akan otomatis mendeteksi apakah server memiliki sidecar. Sidecar klien mengirim mTLS ke workload dengan sidecar dan mengirim teks biasa ke workload tanpa sidecar. Namun, perhatikan bahwa layanan menerima traffic teks biasa dan mTLS. Untuk mengamankan service mesh, sebaiknya migrasikan layanan Anda agar hanya menerima traffic mTLS.
Untuk informasi selengkapnya tentang cara menerapkan mTLS saja, lihat Cloud Service Mesh dengan contoh: mTLS.
Manfaat keamanan
Cloud Service Mesh memberikan manfaat keamanan berikut:
Mengurangi risiko serangan replay atau peniruan identitas yang menggunakan kredensial yang dicuri. Cloud Service Mesh mengandalkan sertifikat mTLS untuk mengautentikasi peer, bukan token pembawa seperti Token Web JSON (JWT). Karena sertifikat mTLS terikat dengan saluran TLS, entitas dalam lingkungan produksi Anda tidak dapat meniru identitas entitas lain dengan memutar ulang token autentikasi tanpa akses ke kunci pribadi.
Memastikan enkripsi saat dalam pengiriman. Menggunakan mTLS untuk autentikasi juga memastikan bahwa semua komunikasi TCP dienkripsi saat transit.
Memastikan bahwa hanya klien yang diberi otorisasi yang dapat mengakses layanan dengan data sensitif. Hanya klien yang diotorisasi yang dapat mengakses layanan dengan data sensitif, terlepas dari lokasi jaringan klien dan kredensial tingkat aplikasi. Anda dapat menentukan bahwa hanya klien dengan identitas layanan yang diotorisasi atau di namespace Kubernetes yang diotorisasi yang dapat mengakses layanan. Anda juga dapat menggunakan kebijakan akses berbasis IP untuk memberikan akses ke klien yang di-deploy di luar klien di luar mesh.
Memitigasi risiko pelanggaran data pengguna dalam jaringan produksi Anda. Anda dapat memastikan bahwa orang dalam hanya dapat mengakses data sensitif melalui klien yang diberi otorisasi. Selain itu, Anda dapat memastikan bahwa klien tertentu hanya dapat memperoleh akses ke data pengguna jika klien dapat menampilkan token pengguna yang valid dan berumur pendek. Hal ini mengurangi risiko bahwa kompromi satu kredensial klien memberi penyerang akses ke semua data pengguna.
Mengidentifikasi klien mana yang mengakses layanan dengan data sensitif. Logging akses Cloud Service Mesh merekam identitas mTLS klien selain alamat IP. Dengan demikian, Anda dapat memahami workload mana yang mengakses layanan meskipun workload bersifat sementara dan di-deploy secara dinamis, serta di cluster atau jaringan Virtual Private Cloud (VPC) yang berbeda.
Fitur
Bagian ini menjelaskan fitur yang disediakan Cloud Service Mesh untuk mewujudkan manfaat keamanannya.
Rotasi kunci dan sertifikat otomatis
Menggunakan mTLS berdasarkan identitas layanan memungkinkan enkripsi semua komunikasi TCP dan memberikan kredensial yang tidak dapat diputar ulang dan lebih aman untuk kontrol akses. Salah satu tantangan utama penggunaan mTLS dalam skala besar adalah mengelola kunci dan sertifikat untuk semua beban kerja target. Cloud Service Mesh menangani rotasi kunci dan sertifikat mTLS untuk workload mesh tanpa mengganggu komunikasi. Konfigurasi interval refresh sertifikat yang lebih kecil dapat dilakukan untuk mengurangi risiko.
Certificate authority Cloud Service Mesh
Cloud Service Mesh menyertakan otoritas sertifikat pribadi multi-regional terkelola, otoritas sertifikat Cloud Service Mesh, untuk menerbitkan sertifikat bagi mTLS. Certificate authority Cloud Service Mesh adalah layanan yang sangat andal dan skalabel yang dioptimalkan untuk beban kerja yang diskalakan secara dinamis di platform cloud. Dengan otoritas sertifikat Cloud Service Mesh, Google mengelola keamanan dan ketersediaan backend CA. Certificate authority Cloud Service Mesh memungkinkan Anda mengandalkan satu root of trust di seluruh cluster. Saat menggunakan certificate authority Cloud Service Mesh, Anda dapat mengandalkan kumpulan identitas beban kerja untuk memberikan isolasi tingkat kasar. Secara default, autentikasi gagal jika klien dan server tidak berada dalam workload identity pool yang sama.
Sertifikat dari Certificate Authority Cloud Service Mesh menyertakan data berikut tentang layanan aplikasi Anda:
- ID project Google Cloud
- Namespace GKE
- Nama akun layanan GKE
Certificate Authority Service
Sebagai alternatif untuk otoritas sertifikasi Cloud Service Mesh, Anda dapat mengonfigurasi Cloud Service Mesh untuk menggunakan Certificate Authority Service, yang cocok untuk kasus penggunaan berikut:
- Jika Anda memerlukan otoritas sertifikasi yang berbeda untuk menandatangani sertifikat workload di cluster yang berbeda.
- Jika Anda perlu mencadangkan kunci penandatanganan di HSM terkelola.
- Jika Anda berada di industri yang diatur dengan regulasi ketat dan tunduk pada kepatuhan.
- Jika Anda ingin membuat rantai CA Cloud Service Mesh ke sertifikat root perusahaan kustom untuk menandatangani sertifikat workload.
Biaya otoritas sertifikasi Cloud Service Mesh sudah termasuk dalam harga Cloud Service Mesh. Biaya CA Service tidak disertakan dalam harga Cloud Service Mesh dasar dan ditagih secara terpisah. Selain itu, CA Service dilengkapi dengan SLA eksplisit, tetapi certificate authority Cloud Service Mesh tidak.
Untuk integrasi ini, semua beban kerja di Cloud Service Mesh diberi dua peran IAM:
Kebijakan kontrol akses (firewall) berbasis identitas
Dengan Cloud Service Mesh, Anda dapat mengonfigurasi kebijakan keamanan jaringan yang didasarkan pada identitas mTLS, bukan alamat IP peer. Hal ini memungkinkan Anda membuat kebijakan yang tidak bergantung pada lokasi jaringan workload. Hanya komunikasi di seluruh cluster dalam project Google Cloud yang sama yang didukung.
Meminta kebijakan kontrol akses (firewall) berbasis klaim
Selain identitas mTLS, Anda dapat memberikan akses berdasarkan klaim permintaan di header JWT permintaan HTTP atau gRPC. Cloud Service Mesh memungkinkan Anda menyatakan bahwa JWT ditandatangani oleh entitas tepercaya. Artinya, Anda dapat mengonfigurasi kebijakan yang mengizinkan akses dari klien tertentu hanya jika klaim permintaan ada atau cocok dengan nilai yang ditentukan.
Autentikasi pengguna dengan Identity-Aware Proxy
Anda mengautentikasi pengguna yang mengakses layanan apa pun yang ditampilkan di gateway masuk Cloud Service Mesh menggunakan Identity-Aware Proxy (IAP). IAP dapat mengautentikasi pengguna yang login dari browser, berintegrasi dengan penyedia identitas kustom, dan menerbitkan token JWT berjangka pendek atau RCToken yang kemudian dapat digunakan untuk memberikan akses di gateway Ingress atau layanan downstream (dengan menggunakan side-car). Untuk mengetahui informasi selengkapnya, lihat Mengintegrasikan IAP dengan Cloud Service Mesh.
Autentikasi pengguna dengan Penyedia Identitas yang ada
Anda dapat mengintegrasikan Penyedia Identitas yang ada dengan Cloud Service Mesh untuk menyediakan autentikasi pengguna akhir berbasis browser dan kontrol akses ke beban kerja yang di-deploy. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi autentikasi pengguna Cloud Service Mesh.
Logging dan pemantauan akses
Cloud Service Mesh memastikan bahwa log dan metrik akses tersedia di Google Cloud Observability, dan menyediakan dasbor terintegrasi untuk memahami pola akses layanan atau beban kerja berdasarkan data ini.
Sesuai FIPS
Komponen bidang data menggunakan modul enkripsi yang divalidasi FIPS 140-2.
Batasan
Keamanan Cloud Service Mesh memiliki batasan berikut:
- Autentikasi pengguna yang menggunakan IAP mengharuskan layanan dipublikasikan ke internet. IAP dan Cloud Service Mesh memungkinkan Anda mengonfigurasi kebijakan yang dapat membatasi akses ke pengguna dan klien yang diotorisasi dalam rentang IP yang diizinkan. Jika Anda memilih untuk hanya mengekspos layanan ke klien dalam jaringan yang sama, Anda perlu mengonfigurasi mesin kebijakan kustom untuk autentikasi pengguna dan penerbitan token.
Langkah selanjutnya
- Praktik terbaik keamanan Cloud Service Mesh
- Mengonfigurasi keamanan transpor
- Memperbarui kebijakan otorisasi