Ringkasan keamanan Cloud Service Mesh

Keamanan Cloud Service Mesh dengan Istio API membantu Anda mengurangi ancaman orang dalam dan mengurangi risiko pelanggaran data dengan memastikan bahwa semua komunikasi di antara workload dienkripsi, diautentikasi dua arah, dan diotorisasi.

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

Dengan Cloud Service Mesh, Anda dapat mengonfigurasi lapisan keamanan jaringan kontekstual layanan dan kontekstual permintaan yang independen dari keamanan jaringan yang mendasarinya. Karena hal ini, Cloud Service Mesh memungkinkan Anda mengadopsi postur pertahanan mendalam yang konsisten dengan prinsip keamanan Zero Trust. Anda dapat mencapai postur ini melalui kebijakan deklaratif dan tanpa mengubah kode aplikasi apa pun.

mutual TLS

Cloud Service Mesh menggunakan mutual TLS (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 familiar dengan TLS sederhana melalui penggunaannya di HTTPS untuk memungkinkan browser memercayai server web dan mengenkripsi data yang dipertukarkan. Saat TLS sederhana digunakan, klien menetapkan bahwa server dapat dipercaya dengan memvalidasi sertifikatnya. mTLS adalah penerapan TLS yang klien dan servernya saling memberikan sertifikat dan memverifikasi identitas satu sama lain.

mTLS adalah cara Cloud Service Mesh menerapkan autentikasi dan enkripsi antar-layanan.

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 mesh layanan, sebaiknya migrasikan layanan Anda agar hanya menerima traffic mTLS.

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

Manfaat keamanan

Cloud Service Mesh memberikan manfaat keamanan berikut:

  • Mengurangi risiko serangan replay atau peniruan identitas yang menggunakan kredensial curian. Cloud Service Mesh mengandalkan sertifikat mTLS untuk mengautentikasi peer, bukan token pemilik seperti JSON Web Token (JWT). Karena sertifikat mTLS terikat ke 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 dalam pengiriman. Menggunakan mTLS untuk autentikasi juga memastikan bahwa semua komunikasi TCP dienkripsi dalam pengiriman.

  • Memastikan bahwa hanya klien yang diotorisasi 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 kepada klien yang di-deploy di luar klien di luar mesh.

  • Mengurangi 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 dapat memperoleh akses ke data pengguna jika klien dapat memberikan token pengguna yang valid dan berjangka pendek. Hal ini mengurangi risiko kompromi satu kredensial klien yang memberikan akses penyerang ke semua data pengguna.

  • Mengidentifikasi klien mana yang mengakses layanan dengan data sensitif. Logging akses Cloud Service Mesh menangkap identitas mTLS klien selain alamat IP. Dengan demikian, Anda dapat memahami workload mana yang mengakses layanan meskipun workload tersebut bersifat sementara 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 kunci dan sertifikat otomatis

Menggunakan mTLS berdasarkan identitas layanan memungkinkan enkripsi semua komunikasi TCP dan menyediakan kredensial yang lebih aman dan tidak dapat diputar ulang untuk kontrol akses. Salah satu tantangan utama penggunaan mTLS dalam skala besar adalah mengelola kunci dan sertifikat untuk semua workload target. Cloud Service Mesh menangani rotasi kunci dan sertifikat mTLS untuk workload mesh tanpa mengganggu komunikasi. Konfigurasi interval pemuatan ulang sertifikat yang lebih kecil dapat dilakukan untuk mengurangi risiko.

Certificate authority Cloud Service Mesh

Cloud Service Mesh mencakup certificate authority pribadi multi-regional terkelola, certificate authority Cloud Service Mesh, untuk menerbitkan sertifikat untuk 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 certificate authority 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 workload identity pool untuk memberikan isolasi yang kasar. Secara default, autentikasi akan gagal jika klien dan server tidak berada di workload identity pool yang sama.

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

  • The Google Cloud Project ID
  • 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 perlu mencadangkan kunci penandatanganan di HSM terkelola.
  • Jika Anda berada di industri yang diatur dengan regulasi ketat dan tunduk pada kepatuhan.
  • Jika Anda ingin menautkan CA Cloud Service Mesh ke sertifikat root perusahaan kustom untuk menandatangani sertifikat workload.

Biaya certificate authority Cloud Service Mesh disertakan dalam harga Cloud Service Mesh. Biaya CA Service tidak disertakan dalam harga dasar Cloud Service Mesh 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 (firewall) identity-aware

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 independen dari lokasi jaringan workload. Hanya komunikasi di seluruh cluster dalam project Google Cloud yang sama yang didukung.

Kebijakan kontrol akses (firewall) yang mendukung klaim permintaan

Selain identitas mTLS, Anda dapat memberikan akses berdasarkan klaim permintaan di header JWT permintaan HTTP atau gRPC. Cloud Service Mesh memungkinkan Anda menegaskan 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 diekspos di a gateway ingress 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 hilir (dengan menggunakan sidecar). 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 workload 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 untuk layanan atau workload berdasarkan data ini.

Sesuai dengan FIPS

Komponen data plane menggunakan modul enkripsi yang divalidasi FIPS 140-3.

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 kepada klien dalam jaringan yang sama, Anda harus mengonfigurasi Policy Engine kustom untuk autentikasi pengguna dan penerbitan token.

Langkah berikutnya