Cloud Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Halaman ini diterjemahkan oleh Cloud Translation API.

Praktik terbaik keamanan Cloud Service Mesh

Dokumen ini menjelaskan praktik terbaik untuk membuat dan mengatur konfigurasi Cloud Service Mesh yang aman yang berjalan di Google Kubernetes Engine (GKE). Panduan dalam dokumen ini tidak hanya membahas setelan yang digunakan untuk mengonfigurasi dan menginstal Cloud Service Mesh, tetapi juga menjelaskan cara menggunakan Cloud Service Mesh dengan produk dan fitur lain untuk melindungi dari ancaman keamanan yang mungkin dihadapi aplikasi dalam mesh. Google Cloud

Target audiens untuk dokumen ini mencakup administrator yang mengelola kebijakan di Cloud Service Mesh dan pengguna yang menjalankan layanan di Cloud Service Mesh. Tindakan keamanan yang dijelaskan di sini juga berguna bagi organisasi yang perlu meningkatkan keamanan mesh layanan mereka untuk memenuhi persyaratan kepatuhan.

Dokumen ini disusun sebagai berikut:

Pengantar
Vektor serangan dan risiko keamanan
- Vektor serangan
- Risiko keamanan
Tindakan untuk melindungi mesh layanan

Pengantar

Cloud Service Mesh menyediakan fitur dan alat yang membantu Anda mengamati, mengelola, dan mengamankan layanan secara terpadu. Pendekatan ini berfokus pada aplikasi dan menggunakan identitas aplikasi tepercaya, bukan pendekatan yang berfokus pada IP jaringan. Anda dapat men-deploy mesh layanan secara transparan tanpa perlu mengubah kode aplikasi yang ada. Cloud Service Mesh memberikan kontrol deklaratif atas perilaku jaringan, yang membantu memisahkan pekerjaan tim yang bertanggung jawab untuk mengirimkan dan merilis fitur aplikasi dari tanggung jawab administrator yang bertanggung jawab atas keamanan dan jaringan.

Cloud Service Mesh didasarkan pada mesh layanan Istio open source, yang memungkinkan konfigurasi dan topologi yang canggih. Bergantung pada struktur organisasi Anda, satu atau beberapa tim atau peran mungkin bertanggung jawab untuk menginstal dan mengonfigurasi mesh. Setelan Cloud Service Mesh default dipilih untuk melindungi aplikasi, tetapi dalam beberapa kasus, Anda mungkin memerlukan konfigurasi kustom atau memberikan pengecualian dengan mengecualikan aplikasi, port, atau alamat IP tertentu dari berpartisipasi dalam mesh. Penting untuk memiliki kontrol guna mengatur konfigurasi mesh dan pengecualian keamanan.

Vektor serangan dan risiko keamanan

Vektor serangan

Keamanan Cloud Service Mesh mengikuti model keamanan zero trust yang mengasumsikan ancaman keamanan berasal dari dalam dan luar perimeter keamanan organisasi. Contoh jenis serangan keamanan yang dapat mengancam aplikasi dalam mesh layanan meliputi:

Serangan pemindahan data yang tidak sah. Misalnya, serangan yang menguping data atau kredensial sensitif dari traffic layanan ke layanan.
Serangan {i>man-in-the-middle<i}. Misalnya, layanan berbahaya yang menyamar sebagai layanan yang sah untuk mendapatkan atau mengubah komunikasi antar-layanan.
Serangan eskalasi akses. Misalnya, serangan yang menggunakan akses tidak sah ke hak istimewa yang ditingkatkan untuk melakukan operasi dalam jaringan.
Serangan denial of service (DoS).
Serangan botnet yang mencoba membahayakan dan memanipulasi layanan untuk meluncurkan serangan pada layanan lain.

Serangan juga dapat dikategorikan berdasarkan target serangan:

Serangan jaringan internal Mesh. Serangan yang ditujukan untuk merusak, menguping, atau memalsukan komunikasi internal layanan ke layanan atau layanan ke panel kontrol mesh.
Serangan bidang kontrol. Serangan yang bertujuan menyebabkan bidang kontrol berfungsi tidak semestinya (seperti serangan DoS), atau mencuri data sensitif dari bidang kontrol.
Serangan tepi mesh. Serangan yang bertujuan untuk merusak, menyadap, atau memalsukan komunikasi di ingress atau egress mesh.
Serangan operasi Mesh. Serangan yang ditujukan pada operasi mesh. Penyerang dapat mencoba mendapatkan hak istimewa yang ditingkatkan untuk melakukan operasi berbahaya dalam mesh, seperti mengubah kebijakan keamanan dan image workload-nya.

Risiko keamanan

Selain serangan keamanan, jaringan mesh juga menghadapi risiko keamanan lainnya. Daftar berikut menjelaskan beberapa kemungkinan risiko keamanan:

Perlindungan keamanan tidak lengkap. Service mesh belum dikonfigurasi dengan kebijakan autentikasi dan otorisasi untuk melindungi keamanannya. Misalnya, tidak ada kebijakan autentikasi atau otorisasi yang ditentukan untuk layanan dalam mesh.
Pengecualian kebijakan keamanan. Untuk mengakomodasi kasus penggunaan tertentu, pengguna dapat membuat pengecualian kebijakan keamanan untuk traffic tertentu (internal atau eksternal) agar dikecualikan dari kebijakan keamanan Cloud Service Mesh. Untuk menangani kasus tersebut dengan aman, lihat bagian Menangani pengecualian terhadap kebijakan dengan aman.
Mengabaikan upgrade gambar. Kerentanan dapat ditemukan untuk gambar yang digunakan dalam mesh. Anda harus terus memperbarui komponen mesh dan image workload dengan perbaikan kerentanan terbaru.
Kurangnya pemeliharaan (tidak ada keahlian atau sumber daya). Konfigurasi kebijakan dan software mesh memerlukan pemeliharaan rutin untuk memanfaatkan mekanisme perlindungan keamanan terbaru.
Kurangnya visibilitas. Salah konfigurasi atau konfigurasi kebijakan mesh yang tidak aman dan traffic/operasi mesh yang tidak normal tidak diketahui oleh administrator mesh.
Penyimpangan konfigurasi. Konfigurasi kebijakan dalam mesh berbeda dari sumber tepercaya.

Tindakan untuk melindungi mesh layanan

Bagian ini menyajikan panduan pengoperasian untuk mengamankan mesh layanan.

Arsitektur keamanan

Keamanan mesh layanan bergantung pada keamanan komponen di berbagai lapisan sistem mesh dan aplikasinya. Maksud tingkat tinggi dari postur keamanan Cloud Service Mesh yang diusulkan adalah untuk mengamankan service mesh dengan mengintegrasikan beberapa mekanisme keamanan di berbagai lapisan, yang secara bersama-sama mencapai keamanan sistem secara keseluruhan dalam model keamanan zero-trust. Diagram berikut menunjukkan postur keamanan Cloud Service Mesh yang diusulkan.

postur keamanan Cloud Service Mesh

Cloud Service Mesh memberikan keamanan di beberapa lapisan, termasuk:

Keamanan edge mesh
- Keamanan ingress Cloud Service Mesh menyediakan kontrol akses untuk traffic eksternal dan mengamankan akses eksternal ke API yang diekspos oleh layanan di mesh.
- Keamanan keluar Cloud Service Mesh mengatur traffic keluar dari workload internal.
- Autentikasi Pengguna Cloud Service Mesh terintegrasi dengan infrastruktur Google untuk mengautentikasi panggilan eksternal dari browser web ke layanan yang menjalankan aplikasi web.
- Pengelolaan sertifikat gateway Cloud Service Mesh melindungi dan merotasi kunci pribadi dan sertifikat X.509 yang digunakan oleh gateway ingress dan egress Cloud Service Mesh menggunakan Certificate Authority Service.
- Cloud Armor dapat memberikan perlindungan terhadap serangan distributed denial-of-service (DDoS) eksternal dan serangan Layer 7. Layanan ini berfungsi sebagai Firewall Aplikasi Web (WAF) untuk melindungi mesh dari serangan jaringan. Misalnya, serangan injeksi dan eksekusi kode jarak jauh.
- VPC dan Kontrol Layanan VPC melindungi edge mesh melalui kontrol akses jaringan pribadi.
Keamanan cluster
- TLS bersama (mTLS) Cloud Service Mesh menerapkan enkripsi dan autentikasi traffic workload-ke-workload.
- CA terkelola, seperti Certificate Authority Service dan Certificate Authority Cloud Service Mesh, menyediakan dan mengelola sertifikat yang digunakan oleh workload secara aman.
- Otorisasi Cloud Service Mesh menerapkan kontrol akses untuk layanan mesh berdasarkan identitas dan atribut lainnya.
- Dasbor keamanan GKE Enterprise menyediakan pemantauan konfigurasi kebijakan keamanan dan Kebijakan Jaringan Kubernetes untuk workload.
- Kebijakan Jaringan Kubernetes menerapkan kontrol akses Pod berdasarkan alamat IP, label Pod, namespace, dan lainnya.
- Keamanan bidang kontrol melindungi dari serangan terhadap bidang kontrol. Perlindungan ini mencegah penyerang mengubah, mengeksploitasi, atau membocorkan data konfigurasi layanan dan mesh.
Keamanan workload
- Selalu perbarui rilis keamanan Cloud Service Mesh untuk memastikan biner Cloud Service Mesh yang berjalan di mesh Anda bebas dari kerentanan yang diketahui publik.
- Workload Identity Federation for GKE memungkinkan workload mendapatkan kredensial untuk memanggil layanan Google secara aman.
- CNI (Container Network Interface) Kubernetes mencegah serangan eskalasi hak istimewa dengan menghilangkan kebutuhan akan container init Cloud Service Mesh yang memiliki hak istimewa.
Keamanan operator
- Kontrol akses berbasis peran (RBAC) Kubernetes membatasi akses ke resource Kubernetes dan membatasi izin operator untuk memitigasi serangan yang berasal dari operator berbahaya atau peniruan identitas operator.
- GKE Enterprise Policy Controller memvalidasi dan mengaudit konfigurasi kebijakan di mesh untuk mencegah kesalahan konfigurasi.
- Google Cloud Otorisasi Biner memastikan bahwa image beban kerja dalam mesh adalah image yang diizinkan oleh administrator.
- Google Cloud Audit Logging mengaudit operasi mesh.

Diagram di bawah menunjukkan alur konfigurasi dan komunikasi dengan solusi keamanan terintegrasi di Cloud Service Mesh.

alur traffic diagram keamanan

Keamanan cluster

Mengaktifkan TLS bersama yang ketat

Serangan man-in-the-middle (MitM) mencoba menyisipkan entitas berbahaya di antara dua pihak yang berkomunikasi untuk menyadap atau memanipulasi komunikasi. Cloud Service Mesh memberikan pertahanan terhadap serangan MitM dan pemindahan data yang tidak sah dengan menerapkan enkripsi dan autentikasi mTLS untuk semua pihak yang berkomunikasi. Mode permisif menggunakan mTLS jika kedua sisi mendukungnya, tetapi mengizinkan koneksi tanpa mTLS. Sebaliknya, mTLS ketat mewajibkan agar traffic dienkripsi dan diautentikasi dengan mTLS serta tidak mengizinkan traffic teks biasa.

Cloud Service Mesh memungkinkan Anda mengonfigurasi versi TLS minimum untuk koneksi TLS di antara workload Anda guna memenuhi persyaratan keamanan dan kepatuhan Anda.

Untuk mengetahui informasi selengkapnya, lihat Cloud Service Mesh menurut contoh: mTLS | Menerapkan mTLS di seluruh mesh.

Mengaktifkan kontrol akses

Kebijakan keamanan Cloud Service Mesh (seperti kebijakan autentikasi dan otorisasi) harus diterapkan pada semua traffic yang masuk dan keluar dari mesh, kecuali jika ada justifikasi yang kuat untuk mengecualikan layanan atau Pod dari kebijakan keamanan Cloud Service Mesh. Dalam beberapa kasus, pengguna mungkin memiliki alasan yang sah untuk melewati kebijakan keamanan Cloud Service Mesh untuk beberapa port dan rentang IP. Misalnya, untuk membuat koneksi native dengan layanan yang tidak dikelola oleh Cloud Service Mesh. Untuk mengamankan Cloud Service Mesh dalam kasus penggunaan tersebut, lihat Menangani pengecualian kebijakan Cloud Service Mesh dengan aman.

Kontrol akses layanan sangat penting dalam mencegah akses tidak sah ke layanan. Penerapan mTLS mengenkripsi dan mengautentikasi permintaan, tetapi mesh tetap memerlukan kebijakan otorisasi Cloud Service Mesh untuk menerapkan kontrol akses pada layanan. Misalnya, menolak permintaan tidak sah yang berasal dari klien yang diautentikasi.

Kebijakan otorisasi Cloud Service Mesh menyediakan cara yang fleksibel untuk mengonfigurasi kontrol akses guna melindungi layanan Anda dari akses yang tidak sah. Kebijakan otorisasi Cloud Service Mesh harus diterapkan berdasarkan identitas yang diautentikasi yang berasal dari hasil autentikasi - autentikasi berbasis mTLS atau JSON Web Token (JWT) harus digunakan bersama sebagai bagian dari kebijakan otorisasi Cloud Service Mesh.

Menerapkan kebijakan autentikasi Cloud Service Mesh

Token Web JSON (JWT)

Selain autentikasi mTLS, administrator mesh dapat mewajibkan layanan untuk mengautentikasi dan mengizinkan permintaan berdasarkan JWT. Cloud Service Mesh tidak bertindak sebagai penyedia JWT, tetapi mengautentikasi JWT berdasarkan endpoint set kunci web JSON (JWKS) yang dikonfigurasi. Autentikasi JWT dapat diterapkan ke gateway masuk untuk traffic eksternal atau ke layanan internal untuk traffic dalam mesh. Autentikasi JWT dapat digabungkan dengan autentikasi mTLS saat JWT digunakan sebagai kredensial untuk merepresentasikan pemanggil akhir dan layanan yang diminta memerlukan bukti bahwa layanan tersebut dipanggil atas nama pemanggil akhir. Menerapkan autentikasi JWT melindungi dari serangan yang mengakses layanan tanpa kredensial yang valid dan atas nama pengguna akhir yang sebenarnya.

Autentikasi pengguna Cloud Service Mesh

Autentikasi pengguna Cloud Service Mesh adalah solusi terintegrasi untuk autentikasi pengguna akhir berbasis browser dan kontrol akses ke beban kerja Anda. Layanan ini mengintegrasikan mesh layanan dengan Penyedia Identitas (IdP) yang ada untuk menerapkan alur izin dan login OpenID Connect (OIDC) berbasis web standar serta menggunakan kebijakan otorisasi Cloud Service Mesh untuk kontrol akses.

Menerapkan kebijakan otorisasi

Kebijakan otorisasi Cloud Service Mesh mengontrol:

Siapa atau apa yang diizinkan untuk mengakses layanan.
Resource mana yang dapat diakses.
Operasi mana yang dapat dilakukan pada resource yang diizinkan.

Kebijakan otorisasi adalah cara serbaguna untuk mengonfigurasi kontrol akses berdasarkan identitas sebenarnya yang digunakan layanan untuk berjalan, properti traffic lapisan aplikasi (Lapisan 7) (misalnya, header permintaan), dan properti lapisan jaringan (Lapisan 3 dan Lapisan 4) seperti rentang IP dan port.

Kebijakan otorisasi Cloud Service Mesh harus diterapkan berdasarkan identitas terautentikasi yang berasal dari hasil autentikasi untuk mencegah akses tidak sah ke layanan atau data.

Secara default, akses ke layanan harus ditolak kecuali jika kebijakan otorisasi didefinisikan secara eksplisit untuk mengizinkan akses ke layanan. Lihat Praktik Terbaik Kebijakan Otorisasi untuk mengetahui contoh kebijakan otorisasi yang menolak permintaan akses.

Kebijakan otorisasi harus membatasi kepercayaan sebanyak mungkin. Misalnya, akses ke layanan dapat ditentukan berdasarkan jalur URL individual yang diekspos oleh layanan sehingga hanya layanan A yang dapat mengakses jalur /admin dari layanan B.

Kebijakan otorisasi dapat digunakan bersama dengan Kebijakan Jaringan Kubernetes, yang hanya beroperasi di lapisan jaringan (Lapisan 3 dan Lapisan 4) dan mengontrol akses jaringan untuk alamat IP dan port di Pod Kubernetes dan namespace Kubernetes.

Menerapkan pertukaran token untuk mengakses layanan mesh

Untuk melindungi dari serangan replay token yang mencuri token dan menggunakan kembali token yang dicuri untuk mengakses layanan mesh, token dalam permintaan dari luar mesh harus ditukar dengan token internal mesh yang memiliki masa aktif singkat di edge mesh.

Permintaan dari luar mesh untuk mengakses layanan mesh harus menyertakan token, seperti JWT atau cookie, agar diautentikasi dan diberi otorisasi oleh layanan mesh. Token dari luar mesh mungkin memiliki masa berlaku yang lama. Untuk melindungi dari serangan replay token, token dari luar mesh harus ditukar dengan token internal mesh yang berumur pendek dengan cakupan terbatas di ingress mesh. Layanan mesh mengautentikasi token internal mesh dan mengizinkan permintaan akses berdasarkan token internal mesh.