Versi 1.16

Versi yang tersedia

1.20 (terbaru)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

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 di antara 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 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 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 klaim?

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 1.6 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy sidecar klien akan otomatis mendeteksi apakah server memiliki sidecar. Sidecar sisi 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.

Konfigurasi cipher suite

Daftar berikut mencakup suite cipher 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 meningkatkan keamanan, versi TLS minimum sisi server yang didukung oleh workload Cloud Service Mesh adalah 1.2, yang mendukung penyesuaian cipher suite. Perhatikan bahwa Cloud Service Mesh juga mendukung TLS v1.3, yang melakukan hard code pada cipher suite dan tidak mendukung perubahannya.

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

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 hanya 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 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 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 akan mengurangi risiko bahwa kompromi satu kredensial klien akan memberikan akses kepada penyerang 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 dengan mudah memahami workload mana yang mengakses layanan meskipun workload bersifat sementara dan di-deploy secara dinamis, dan 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 GKE Enterprise 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 mTLS. Certificate authority Cloud Service Mesh adalah layanan yang sangat andal dan skalabel yang dioptimalkan untuk workload 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 GKE Enterprise. Saat menggunakan otoritas sertifikasi Cloud Service Mesh, Anda dapat mengandalkan workload identity pool untuk memberikan isolasi yang 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 ingin menggunakan sertifikat plugin CA Kustom Istiod.
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. Layanan CA tidak disertakan dalam harga Cloud Service Mesh dasar dan ditagih secara terpisah. Selain itu, Certificate Authority 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 berdasarkan identitas mTLS, bukan alamat IP peer. Hal ini memungkinkan Anda membuat kebijakan yang tidak bergantung pada lokasi jaringan workload. Saat ini, 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 berumur 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. Anda juga dapat memilih untuk mengonfigurasi tujuan pribadi. Cloud Service Mesh memungkinkan Anda mengurangi derau dalam log akses dengan hanya mencatat akses yang berhasil sekali dalam periode waktu yang dapat dikonfigurasi. Permintaan yang ditolak oleh kebijakan keamanan atau menyebabkan error selalu dicatat dalam log. Hal ini memungkinkan Anda mengurangi biaya yang terkait dengan proses transfer, penyimpanan, dan pemrosesan log secara signifikan, tanpa kehilangan sinyal keamanan utama.

Sesuai FIPS

Semua komponen bidang kontrol dalam cluster dan proxy 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 memungkinkan Anda mengonfigurasi kebijakan yang dapat membatasi akses ke pengguna dan klien resmi dalam rentang IP yang diizinkan. Jika Anda memilih untuk hanya mengekspos layanan kepada klien dalam jaringan yang sama, Anda perlu mengonfigurasi mesin kebijakan kustom untuk autentikasi pengguna dan penerbitan token.