Anda sedang melihat dokumentasi Service Mesh v1.20 lama.

Versi yang tersedia

Cloud Service Mesh
Arsip 1.20
arsip 1.19
Arsip 1.18

Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan keamanan Cloud Service Mesh

Keamanan Cloud Service Mesh membantu Anda memitigasi ancaman orang dalam dan mengurangi risiko pelanggaran data dengan memastikan bahwa semua komunikasi antara workload dienkripsi, diautentikasi bersama, dan diotorisasi.

Secara tradisional, segmentasi mikro yang menggunakan aturan berbasis IP telah digunakan untuk mengurangi risiko pihak internal. Namun, adopsi container, layanan bersama, dan lingkungan produksi terdistribusi yang tersebar di beberapa cloud membuat pendekatan ini lebih sulit untuk dikonfigurasi dan bahkan lebih sulit dikelola.

Dengan Cloud Service Mesh, Anda dapat mengonfigurasi lapisan keamanan jaringan berbasis konteks layanan dan meminta konteks yang tidak bergantung pada keamanan jaringan yang mendasarinya. Oleh karena itu, Cloud Service Mesh memungkinkan Anda menerapkan postur defense in depth 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 bersama (mTLS) untuk autentikasi peer. Autentikasi mengacu pada identitas: siapa layanan ini? siapa pengguna akhir ini? dan dapatkah saya percaya bahwa mereka memang yang mereka katakan?

mTLS memungkinkan beban kerja memverifikasi identitas satu sama lain dan melakukan autentikasi satu sama lain. Anda mungkin telah mengenal TLS sederhana melalui penggunaannya di HTTPS agar browser dapat memercayai server web dan mengenkripsi data yang dipertukarkan. Jika TLS sederhana digunakan, klien akan menetapkan bahwa server dapat dipercaya dengan memvalidasi sertifikatnya. mTLS adalah implementasi TLS di mana klien dan server saling menyajikan sertifikat dan memverifikasi identitas satu sama lain.

mTLS adalah sarana yang digunakan Cloud Service Mesh untuk menerapkan autentikasi dan enkripsi antarlayanan.

Di Cloud Service Mesh 1.6 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy file bantuan klien akan otomatis mendeteksi apakah server memiliki file bantuan. File bantuan klien mengirimkan mTLS ke workload yang memiliki file bantuan dan mengirimkan teks biasa ke beban kerja tanpa file bantuan. Namun, perlu diketahui bahwa layanan menerima traffic teks biasa dan mTLS. Untuk mengamankan mesh layanan, sebaiknya migrasikan layanan Anda agar hanya menerima traffic mTLS.

Untuk mengetahui informasi selengkapnya tentang cara menerapkan mTLS saja, lihat Cloud Service Mesh menurut contoh: mTLS.

Konfigurasi Cipher Suite

Daftar berikut mencakup cipher suite default Cloud Service Mesh yang sesuai dengan FIPS:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

Untuk keamanan yang lebih baik, versi TLS minimum sisi server yang didukung oleh workload Cloud Service Mesh adalah 1.2, yang mendukung penyesuaian cipher suite. Perlu diperhatikan bahwa Cloud Service Mesh juga mendukung TLS v1.3, yang melakukan hard code cipher suite dan tidak mendukung perubahannya.

Untuk mengetahui informasi selengkapnya tentang cipher suite, lihat Konfigurasi TLS umum Envoy dan Autentikasi TLS Mutual Istio.

Manfaat keamanan

Cloud Service Mesh memberikan manfaat keamanan berikut:

Memitigasi risiko serangan replay atau peniruan identitas yang menggunakan kredensial yang dicuri. Cloud Service Mesh mengandalkan sertifikat mTLS untuk mengautentikasi peer, bukan token pemilik seperti JSON Web Token (JWT). Karena sertifikat mTLS terikat dengan saluran TLS, entitas dalam lingkungan produksi tidak dapat meniru identitas lainnya hanya dengan memutar ulang token autentikasi tanpa akses ke kunci pribadi.
Memastikan enkripsi saat proses pengiriman. Penggunaan mTLS untuk autentikasi juga memastikan bahwa semua komunikasi TCP dienkripsi saat transit.
Memastikan hanya klien yang diotorisasi yang dapat mengakses layanan dengan data sensitif. Hanya klien yang diberi otorisasi 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 resmi atau dalam namespace Kubernetes resmi yang dapat mengakses layanan. Anda juga dapat menggunakan kebijakan akses berbasis IP untuk memberikan akses ke klien yang di-deploy di luar lingkungan GKE Enterprise.
Memitigasi risiko pelanggaran data pengguna dalam jaringan produksi Anda. Anda dapat memastikan bahwa orang dalam hanya dapat mengakses data sensitif melalui klien yang diotorisasi. Selain itu, Anda dapat memastikan bahwa klien tertentu hanya bisa mendapatkan akses ke data pengguna jika klien tersebut dapat menyajikan token pengguna yang valid dan berumur pendek. Tindakan ini mengurangi risiko penyusupan satu kredensial klien yang memberikan akses ke semua data pengguna kepada penyerang.
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 dengan mudah memahami workload mana yang diakses ke layanan meskipun workload tersebut bersifat efemeral dan di-deploy secara dinamis, serta berada 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 sertifikat dan kunci otomatis

Dengan menggunakan mTLS berdasarkan identitas layanan, Anda dapat mengenkripsi semua komunikasi TCP dan memberikan kredensial yang tidak dapat diputar ulang yang lebih aman untuk kontrol akses. Salah satu tantangan utama dalam menggunakan mTLS dalam skala besar adalah mengelola kunci dan sertifikat untuk semua workload target. Cloud Service Mesh menangani sertifikat dan kunci mTLS yang berputar untuk workload GKE Enterprise tanpa mengganggu komunikasi. Konfigurasi interval refresh sertifikat yang lebih kecil dapat mengurangi risiko.

Certificate authority Cloud Service Mesh

Cloud Service Mesh mencakup otoritas sertifikat pribadi multi-regional yang terkelola, Cloud Service Mesh certificate authority, guna menerbitkan sertifikat untuk mTLS. Certificate authority Cloud Service Mesh adalah layanan sangat andal dan skalabel yang dioptimalkan untuk workload yang diskalakan secara dinamis di platform cloud. Dengan certificate authority Cloud Service Mesh, Google mengelola keamanan dan ketersediaan backend CA. Dengan certificate authority Cloud Service Mesh, Anda dapat mengandalkan satu root kepercayaan di seluruh cluster GKE Enterprise. Saat menggunakan certificate authority Cloud Service Mesh, Anda dapat mengandalkan kumpulan workload identity untuk menyediakan isolasi secara menyeluruh. Secara default, autentikasi akan gagal jika klien dan server tidak berada dalam kumpulan workload identity yang sama.

Sertifikat dari certificate authority Cloud Service Mesh mencakup data berikut tentang layanan aplikasi Anda:

ID project Google Cloud
Namespace GKE
Nama akun layanan GKE

Certificate Authority Service

Sebagai alternatif untuk certificate authority Cloud Service Mesh, Anda dapat mengonfigurasi Cloud Service Mesh untuk menggunakan Certificate Authority Service, yang cocok untuk kasus penggunaan berikut:

Jika Anda memerlukan certificate authority yang berbeda untuk menandatangani sertifikat workload di cluster yang berbeda.
Jika Anda ingin menggunakan sertifikat plugin CA Kustom Istio.
Jika Anda perlu mendukung kunci penandatanganan di HSM terkelola.
Jika Anda berada di industri yang diatur dengan regulasi ketat dan harus mematuhi kebijakan.
Jika Anda ingin menggabungkan Cloud Service Mesh CA ke root certificate perusahaan kustom untuk menandatangani sertifikat workload.

Biaya certificate authority Cloud Service Mesh termasuk dalam harga Cloud Service Mesh. 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 workload di Cloud Service Mesh diberi dua peran IAM:

Kebijakan kontrol akses kontekstual (firewall)

Dengan Cloud Service Mesh, Anda dapat mengonfigurasi kebijakan keamanan jaringan berdasarkan identitas mTLS versus alamat IP peer. Hal ini memungkinkan Anda membuat kebijakan yang tidak bergantung pada lokasi jaringan workload. Hanya komunikasi lintas cluster dalam project Google Cloud yang sama yang saat ini didukung.

Meminta kebijakan kontrol akses berbasis klaim (firewall)

Selain identitas mTLS, Anda dapat memberikan akses berdasarkan klaim permintaan di header JWT permintaan HTTP atau gRPC. Dengan Cloud Service Mesh, Anda dapat menyatakan bahwa JWT ditandatangani oleh entitas tepercaya. Artinya, Anda dapat mengonfigurasi kebijakan yang mengizinkan akses dari klien tertentu hanya jika ada klaim permintaan yang cocok dengan nilai yang ditentukan.

Autentikasi pengguna dengan Identity-Aware Proxy

Anda mengautentikasi pengguna yang mengakses layanan apa pun yang diekspos di gateway masuk Cloud Service Mesh menggunakan Identity-Aware Proxy (IAP). IAP dapat mengautentikasi pengguna yang login dari browser, berintegrasi dengan penyedia identitas khusus, dan menerbitkan token JWT berumur pendek atau RCToken yang kemudian dapat digunakan untuk memberikan akses di gateway Ingress atau layanan downstream (dengan menggunakan mobil samping). Untuk mengetahui informasi selengkapnya, lihat Mengintegrasikan IAP dengan Cloud Service Mesh.

Autentikasi pengguna dengan Penyedia Identitas yang sudah ada

Anda dapat mengintegrasikan Penyedia Identitas yang ada dengan Cloud Service Mesh untuk menyediakan autentikasi pengguna akhir berbasis browser dan kontrol akses ke workload yang di-deploy. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi autentikasi pengguna Cloud Service Mesh.

Mengakses logging dan pemantauan

Cloud Service Mesh memastikan bahwa log dan metrik akses tersedia di Google Cloud Observability, dan menyediakan dasbor terintegrasi untuk memahami pola akses untuk layanan atau workload berdasarkan data ini. Anda juga dapat memilih untuk mengonfigurasi tujuan pribadi. Dengan Cloud Service Mesh, Anda dapat mengurangi derau dalam log akses dengan hanya mencatat akses yang berhasil ke dalam log satu kali dalam jangka waktu yang dapat dikonfigurasi. Permintaan yang ditolak oleh kebijakan keamanan atau mengakibatkan error akan selalu dicatat dalam log. Hal ini memungkinkan Anda mengurangi biaya yang terkait dengan penyerapan, penyimpanan, dan pemrosesan log secara signifikan, tanpa kehilangan sinyal keamanan utama.

Sesuai dengan FIPS

Semua komponen dan proxy bidang kontrol dalam cluster pada arsitektur x86 menggunakan modul enkripsi yang divalidasi FIPS 140-2.

Batasan

Keamanan Cloud Service Mesh saat ini memiliki batasan berikut:

Autentikasi pengguna yang menggunakan IAP mengharuskan layanan dipublikasikan ke internet. IAP dan Cloud Service Mesh dapat Anda gunakan untuk mengonfigurasi kebijakan yang dapat membatasi akses ke pengguna dan klien yang diberi otorisasi dalam rentang IP yang diizinkan. Jika memilih untuk hanya mengekspos layanan ke klien dalam jaringan yang sama, Anda harus mengonfigurasi mesin kebijakan kustom untuk autentikasi pengguna dan penerbitan token.