Praktik terbaik keamanan Cloud Service Mesh

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

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

Cloud Service Mesh menyediakan fitur dan alat yang membantu Anda mengamati, mengelola, dan mengamankan layanan secara terpadu. Layanan ini menggunakan pendekatan yang berpusat 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 menyediakan 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 partisipasi dalam mesh. Penting untuk memiliki kontrol guna mengatur konfigurasi mesh dan pengecualian keamanan.

Google Cloud

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 mencakup:

  • Serangan pemindahan data yang tidak sah. Misalnya, serangan yang menguping data atau kredensial sensitif dari traffic layanan ke layanan.
  • Serangan man-in-the-middle. 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 ke layanan lain.

Serangan juga dapat dikategorikan berdasarkan target serangan:

  • Serangan jaringan internal mesh. Serangan yang bertujuan untuk merusak, menguping, atau menipu komunikasi layanan ke layanan internal mesh atau layanan ke bidang kontrol.
  • Serangan bidang kontrol. Serangan yang bertujuan menyebabkan bidang kontrol tidak berfungsi (seperti serangan DoS), atau memindahkan data sensitif dari bidang kontrol secara tidak sah.
  • Serangan edge mesh. Serangan yang bertujuan untuk merusak, menguping, atau menipu komunikasi di ingress atau egress mesh.
  • Serangan operasi mesh. Serangan yang bertujuan untuk 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, mesh juga menghadapi risiko keamanan lainnya. Daftar berikut menjelaskan beberapa kemungkinan risiko keamanan:

  • Perlindungan keamanan yang tidak lengkap. Mesh layanan 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.
  • Pengabaian upgrade image. Kerentanan dapat ditemukan untuk image yang digunakan dalam mesh. Anda harus terus mengupdate komponen mesh dan image workload dengan perbaikan kerentanan terbaru.
  • Kurangnya pemeliharaan (tidak ada keahlian atau resource). Konfigurasi software dan kebijakan mesh memerlukan pemeliharaan rutin untuk memanfaatkan mekanisme perlindungan keamanan terbaru.
  • Kurangnya visibilitas. Konfigurasi yang salah atau tidak aman dari kebijakan mesh dan traffic/operasi mesh yang tidak normal tidak diperhatikan oleh administrator mesh.
  • Penyimpangan konfigurasi. Konfigurasi kebijakan dalam mesh menyimpang 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. Tujuan tingkat tinggi dari postur keamanan Cloud Service Mesh yang diusulkan adalah mengamankan mesh layanan melalui integrasi 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 menyediakan keamanan di beberapa lapisan, termasuk:

  • Keamanan edge mesh
  • Keamanan cluster
    • Cloud Service Mesh mutual TLS (mTLS) menerapkan enkripsi dan autentikasi traffic workload ke workload.
    • CA terkelola, seperti certificate authority Cloud Service Mesh dan Certificate Authority Service, menyediakan dan mengelola sertifikat yang digunakan oleh workload dengan 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 pada bidang kontrol. Perlindungan ini mencegah penyerang mengubah, mengeksploitasi, atau membocorkan data konfigurasi layanan dan mesh.
  • Keamanan workload
    • Selalu ikuti 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 dengan aman.
    • Kubernetes CNI (Container Network Interface) mencegah serangan eskalasi akses 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 mengurangi serangan yang berasal dari operator berbahaya atau peniruan identitas operator.
    • Pengontrol Kebijakan GKE Enterprise memvalidasi dan mengaudit konfigurasi kebijakan dalam mesh untuk mencegah konfigurasi yang salah.
    • Google Cloud Otorisasi Biner memastikan bahwa image workload dalam mesh adalah image yang diizinkan oleh administrator.
    • Google Cloud Logging Audit mengaudit operasi mesh.

Diagram di bawah menunjukkan alur komunikasi dan konfigurasi 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 menguping atau memanipulasi komunikasi. Cloud Service Mesh melindungi dari serangan MitM dan pemindahan data yang tidak sah dengan menerapkan autentikasi dan enkripsi mTLS untuk semua pihak yang berkomunikasi. Mode permisif menggunakan mTLS jika kedua sisi mendukungnya, tetapi memungkinkan koneksi tanpa mTLS. Sebaliknya, mTLS yang ketat mengharuskan traffic dienkripsi dan diautentikasi dengan mTLS dan 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.

Untuk mengetahui informasi selengkapnya, lihat Cloud Service Mesh berdasarkan 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 alasan 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 untuk mencegah akses tidak sah ke layanan. Penerapan mTLS mengenkripsi dan mengautentikasi permintaan, tetapi mesh masih memerlukan kebijakan otorisasi Cloud Service Mesh untuk menerapkan kontrol akses pada layanan. Misalnya, menolak permintaan yang 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 Token Web JSON (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 mengotorisasi 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 ingress untuk traffic eksternal atau ke layanan internal untuk traffic dalam mesh. Autentikasi JWT dapat digabungkan dengan autentikasi mTLS saat JWT digunakan sebagai kredensial untuk mewakili 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 workload Anda. Solusi ini mengintegrasikan mesh layanan dengan Penyedia Identitas (IdP) yang ada untuk menerapkan alur login dan izin OpenID Connect (OIDC) berbasis web standar dan 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 dijalankan layanan, properti lapisan aplikasi (Lapisan 7) dari traffic (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 yang diautentikasi yang berasal dari hasil autentikasi untuk melindungi dari akses tidak sah ke layanan atau data.

Secara default, akses ke layanan harus ditolak kecuali jika kebijakan otorisasi secara eksplisit ditentukan 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 dapat diautentikasi dan diotorisasi oleh layanan mesh. Token dari luar mesh mungkin memiliki masa aktif yang lama. Untuk melindungi dari serangan replay token, token dari luar mesh harus ditukar dengan token internal mesh yang memiliki masa aktif singkat dengan cakupan terbatas di ingress mesh. Layanan mesh mengautentikasi token internal mesh dan mengotorisasi permintaan akses berdasarkan token internal mesh.

Langkah berikutnya