Praktik terbaik keamanan Cloud Service Mesh

Catatan: Panduan ini hanya mendukung Cloud Service Mesh dengan Istio API dan memang tidak mendukung Google Cloud API. Untuk informasi selengkapnya, lihat, Ringkasan Cloud Service Mesh.

Dokumen ini menjelaskan praktik terbaik untuk membangun dan mengatur keamanan Mesh Layanan Cloud konfigurasi yang berjalan di Google Kubernetes Engine (GKE). Panduan dalam lebih dari sekadar setelan yang digunakan untuk mengkonfigurasi dan menginstal Mesh Layanan Cloud dan menjelaskan cara menggunakan Cloud Service Mesh dengan produk dan fitur untuk melindungi dari ancaman keamanan yang dalam jaring.

Audiens yang dituju untuk dokumen ini termasuk administrator yang mengelola kebijakan di Mesh Layanan Cloud dan pengguna yang menjalankan layanan di dan Cloud Service Mesh. Langkah-langkah keamanan yang dijelaskan di sini juga berguna untuk organisasi yang perlu meningkatkan keamanan jaringan layanan mereka untuk memenuhi persyaratan kepatuhan.

Dokumen ini disusun sebagai berikut:

• Pengantar
• Vektor serangan dan risiko keamanan
  • Vektor serangan
  • Risiko keamanan
• Mengukur untuk melindungi mesh layanan
  • Arsitektur keamanan
  • Keamanan cluster
    • Mengaktifkan TLS bersama yang ketat
    • Mengaktifkan kontrol akses
      • Menerapkan kebijakan autentikasi Cloud Service Mesh
      • Token Web JSON (JWT)
      • Autentikasi pengguna Cloud Service Mesh
      • Menerapkan kebijakan otorisasi
      • Menerapkan pertukaran token untuk mengakses layanan mesh
    • Menangani pengecualian kebijakan Cloud Service Mesh dengan aman
      • Menerapkan Kebijakan Jaringan Kubernetes
    • Akses bidang kontrol aman
    • Menerapkan batas namespace
      • Menerapkan kebijakan RBAC Kubernetes
  • Keamanan mesh
    • Kontrol akses masuk cluster
    • Mengatur traffic keluar cluster
    • Menggunakan cluster pribadi atau Kontrol Layanan VPC untuk mengunci akses eksternal
    • Bertahan dari serangan DDoS eksternal
  • Keamanan untuk administrasi dan otomatisasi mesh
    • Segmentasikan peran yang digunakan untuk operasi mesh
    • Memvalidasi konfigurasi kebijakan secara otomatis
      • Menggunakan pendekatan GitOps dengan Config Sync untuk mencegah penyimpangan konfigurasi
    • Menerapkan Logging Audit dan pemantauan
    • Melindungi certificate authority untuk sertifikat dalam cluster
  • Keamanan beban kerja
    • Membatasi hak istimewa Pod
    • Image container aman
    • Mengurangi kerentanan mesh
    • Menggunakan Workload Identity Federation for GKE untuk mengakses layanan Google dengan aman
    • Memantau status keamanan melalui telemetri dan dasbor keamanan
  • Keamanan untuk kredensial dan data pengguna yang sensitif

Pengantar

Cloud Service Mesh menyediakan fitur dan alat yang membantu Anda mengamati, mengelola, dan aman secara terpadu. Dibutuhkan 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 memodifikasi mesh yang ada pada kode aplikasi Anda. Cloud Service Mesh menyediakan kontrol deklaratif atas jaringan perilaku, 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, yang memungkinkan konfigurasi dan topologi yang canggih. Tergantung dari strukturnya, organisasi Anda, satu atau beberapa tim atau peran mungkin bertanggung jawab untuk menginstal dan mengkonfigurasi {i>mesh<i}. Setelan Cloud Service Mesh default dipilih untuk melindungi aplikasi, tetapi dalam beberapa kasus, Anda mungkin perlu konfigurasi khusus atau untuk memberikan pengecualian dengan mengecualikan aplikasi, porta, atau alamat IP agar tidak berpartisipasi dalam sebuah jala. Memiliki kontrol untuk mengatur konfigurasi mesh dan pengecualian keamanan penting.

Catatan: Panduan ini melengkapi Dokumentasi praktik terbaik keamanan Istio, yang mencakup rekomendasi konfigurasi mendetail untuk TLS bersama (mTLS), kebijakan otorisasi, {i>gateway<i}, dan konfigurasi keamanan lainnya. Anda seharusnya memperlakukan rekomendasi ini sebagai dasar untuk digunakan bersama dengan rekomendasi praktik yang dibahas dalam panduan ini. Panduan ini menjelaskan tambahan untuk Cloud Service Mesh dan bagaimana teknologi dalam Google Cloud dapat mengamankan semua lapisan, komponen, dan aliran informasi dalam mesh.

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 aplikasi yang mengancam dalam mesh layanan meliputi:

• Serangan pemindahan data yang tidak sah. Misalnya, serangan yang menyadap data data atau kredensial dari traffic layanan-ke-layanan.
• Serangan {i>man-in-the-middle<i}. Misalnya, layanan berbahaya yang menyamar sebagai layanan yang sah untuk mendapatkan atau memodifikasi komunikasi antara layanan IT perusahaan mereka.
• Serangan eskalasi akses. Misalnya, serangan yang menggunakan akses terlarang hingga hak istimewa yang lebih tinggi untuk melakukan operasi di dalam jaringan.
• Serangan {i>denial of service<i} (DoS).
• Serangan {i>botnet<i} yang mencoba menyusupi dan memanipulasi layanan untuk meluncurkan serangan terhadap layanan lain.

Serangan ini juga dapat dikategorikan berdasarkan target serangan:

• Serangan jaringan internal mesh. Serangan yang ditujukan untuk menyadap, menyadap, atau melakukan spoofing terhadap service-to-service internal mesh atau service-to-control-plane komunikasi antarlayanan.
• Serangan bidang kontrol. Serangan yang bertujuan menyebabkan bidang kontrol malfungsi (seperti serangan DoS), atau pemindahan data sensitif yang bidang kontrol.
• Serangan {i>mesh edge<i}. Serangan yang bertujuan untuk merusak, menyadap, atau spoofing komunikasi pada traffic masuk atau keluar mesh.
• Serangan operasi mesh. Serangan yang ditujukan untuk operasi mesh. Penyerang mungkin mencoba mendapatkan hak istimewa yang ditingkatkan untuk melakukan operasi berbahaya di {i>mesh<i}, seperti mengubah kebijakan keamanan dan image workload.

Risiko keamanan

Selain serangan keamanan, mesh juga menghadapi risiko keamanan lainnya. Hal berikut ini menjelaskan beberapa kemungkinan risiko keamanan:

• Perlindungan keamanan tidak lengkap. Mesh layanan belum dikonfigurasi dengan kebijakan otentikasi dan otorisasi untuk melindungi keamanannya. Sebagai misalnya, tidak ada kebijakan otentikasi atau otorisasi yang ditentukan untuk dan layanan dalam jaring.
• Pengecualian kebijakan keamanan. Untuk mengakomodasi kasus penggunaan yang spesifik, para pengguna dapat membuat pengecualian kebijakan keamanan untuk lalu lintas tertentu (internal atau eksternal) untuk dikecualikan dari kebijakan keamanan Cloud Service Mesh. Kepada menangani kasus tersebut dengan aman, lihat bagian Menangani pengecualian kebijakan dengan aman.
• Mengabaikan upgrade gambar. Kerentanan dapat ditemukan untuk gambar tersebut yang digunakan dalam jaring. Anda harus mempertahankan komponen mesh dan image workload pembaruan kerentanan terkini.
• Kurangnya pemeliharaan (tidak ada keahlian atau sumber daya). Perangkat lunak {i>mesh<i} dan konfigurasi kebijakan memerlukan pemeliharaan rutin untuk memanfaatkan mekanisme perlindungan keamanan terbaru.
• Kurangnya visibilitas. Kesalahan konfigurasi atau konfigurasi mesh yang tidak aman dan traffic/operasi mesh abnormal tidak ditujukan ke perhatian administrator mesh.
• Penyimpangan konfigurasi. Konfigurasi kebijakan dalam mesh menyimpang dari sumber kebenaran.

Langkah-langkah untuk melindungi mesh layanan

Bagian ini menampilkan panduan pengoperasian untuk mengamankan mesh layanan.

Arsitektur keamanan

Keamanan mesh layanan bergantung pada keamanan komponen di berbagai lapisan sistem {i>mesh<i} dan penggunaannya. Tingkat tinggi tujuan dari postur keamanan Cloud Service Mesh yang diusulkan adalah untuk mengamankan layanan secara menyeluruh melalui mengintegrasikan mekanisme keamanan di berbagai yang menyeluruh, yang bersama-sama mencapai keamanan sistem secara menyeluruh di bawah model keamanan. Diagram berikut menunjukkan Cloud Service Mesh yang diusulkan keamanan.

Cloud Service Mesh memberikan keamanan di beberapa lapisan, termasuk:

• Keamanan edge mesh
  • Keamanan masuknya Cloud Service Mesh menyediakan kontrol akses untuk traffic eksternal dan mengamankan akses eksternal ke API yang diekspos oleh dan layanan tambahan di jala tersebut.
  • Keamanan keluar Cloud Service Mesh mengatur traffic keluar dari beban kerja internal.
  • Autentikasi Pengguna Cloud Service Mesh berintegrasi dengan infrastruktur Google untuk mengautentikasi panggilan eksternal dari {i>browser<i} 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 masuk dan keluar Cloud Service Mesh menggunakan {i>Certificate Authority Service<i}.
  • Cloud Armor dapat melindungi dari serangan {i>external denial-of-service<i} (DDoS) dan lapisan 7. Ini berfungsi sebagai {i>Web Application Firewall<i} (WAF) untuk melindungi {i>mesh<i} dari serangan jaringan. Misalnya, eksekusi kode injeksi dan jarak jauh serangan.
  • Kontrol Layanan VPC dan VPC melindungi tepian {i>mesh<i} melalui kontrol akses jaringan pribadi.
• Keamanan cluster
  • Cloud Service Mesh mutual TLS (mTLS) menerapkan workload ke workload enkripsi dan otentikasi lalu lintas data.
  • CA terkelola, seperti certificate authority Cloud Service Mesh, Certificate Authority Service, menyediakan dan mengelola sertifikat yang digunakan dengan aman oleh beban kerja.
  • Otorisasi Cloud Service Mesh menerapkan kontrol akses untuk mesh layanan berdasarkan identitas mereka 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 IP alamat, label Pod, namespace, dan lain-lain.
  • Keamanan bidang kontrol melindungi dari serangan di bidang kontrol. Perlindungan ini mencegah penyerang untuk memodifikasi, mengeksploitasi, atau membocorkan data konfigurasi mesh dan layanan.
• Keamanan workload
  • Mendapatkan info terbaru terkait rilis keamanan Cloud Service Mesh untuk memastikan biner Cloud Service Mesh yang berjalan di mesh Anda tidak kerentanan yang telah diketahui oleh publik.
  • Workload Identity Federation untuk GKE memungkinkan workload mendapatkan kredensial untuk memanggil layanan Google dengan aman.
  • CNI Kubernetes (Antarmuka Jaringan Container) mencegah hak istimewa serangan eskalasi dengan menghilangkan kebutuhan akan init container Cloud Service Mesh.
• 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.
  • Pengontrol Kebijakan GKE Enterprise memvalidasi dan mengaudit konfigurasi kebijakan di mesh untuk mencegah dan kesalahan konfigurasi.
  • Otorisasi Biner Google Cloud memastikan bahwa gambar beban kerja dalam mesh adalah gambar yang diizinkan oleh para administrator.
  • Google Cloud Audit Logging mengaudit operasi mesh.

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

Keamanan cluster

Mengaktifkan TLS bersama yang ketat

Serangan {i>man-in-the-middle<i} (MitM) mencoba memasukkan entitas jahat di antara dua pihak yang berkomunikasi untuk menyadap atau memanipulasi komunikasi. Cloud Service Mesh melindungi dari MitM dan serangan pemindahan data yang tidak sah dengan memberlakukan enkripsi dan autentikasi mTLS untuk semua pihak yang berkomunikasi. Mode permisif menggunakan mTLS saat kedua sisi mendukung itu, tetapi mengizinkan koneksi tanpa mTLS. Sebaliknya, mTLS yang ketat mengharuskan lalu lintas dienkripsi dan diotentikasi dengan mTLS dan tidak mengizinkan teks biasa kemacetan.

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

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

Mengaktifkan kontrol akses

Kebijakan keamanan Cloud Service Mesh (seperti autentikasi dan otorisasi kebijakan) harus diberlakukan pada semua lalu lintas masuk dan keluar dari {i>mesh<i} kecuali jika ada adalah justifikasi kuat untuk mengecualikan layanan atau Pod dari Cloud Service Mesh kebijakan keamanan. Dalam beberapa kasus, pengguna mungkin memiliki alasan yang sah untuk mengabaikan Kebijakan keamanan Cloud Service Mesh untuk beberapa port dan rentang IP. Sebagai misalnya, untuk membuat koneksi native dengan layanan yang tidak dikelola oleh dan 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 yang tidak sah ke layanan IT perusahaan mereka. Penerapan mTLS mengenkripsi dan mengotentikasi permintaan tetapi mesh tetap kebutuhan Kebijakan otorisasi Cloud Service Mesh untuk menerapkan kontrol akses pada layanan. Misalnya, menolak penawaran permintaan yang berasal dari klien yang telah diotentikasi.

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

Menerapkan kebijakan autentikasi Cloud Service Mesh

Token Web JSON (JWT)

Selain otentikasi mTLS, administrator mesh dapat meminta 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 layanan internal untuk traffic in-mesh. Autentikasi JWT dapat digabungkan dengan autentikasi mTLS ketika JWT digunakan sebagai kredensial untuk mewakili pemanggil akhir dan permintaan memerlukan bukti bahwa layanan dipanggil atas nama pemanggil akhir. Menerapkan autentikasi JWT melindungi Anda 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 dan akses pengguna akhir berbasis browser mengontrol beban kerja Anda. Alat ini mengintegrasikan mesh layanan dengan Identity yang ada Penyedia (IdP) untuk menerapkan login OpenID Connect (OIDC) berbasis web standar dan alur izin serta menggunakan kebijakan otorisasi Cloud Service Mesh untuk akses kontrol.

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 yang serbaguna untuk mengkonfigurasi kontrol akses berdasarkan identitas aktual yang dijalankan oleh layanan, lapisan aplikasi (Lapisan 7) properti lalu lintas (misalnya tajuk permintaan), dan lapisan jaringan (Lapisan 3 dan Lapisan 4) seperti rentang IP dan porta.

Kebijakan otorisasi Cloud Service Mesh harus diterapkan berdasarkan autentikasi identitas yang diperoleh dari hasil otentikasi untuk melindungi diri dari akses tidak sah ke layanan atau data.

Secara {i>default<i}, akses ke layanan harus ditolak kecuali ada kebijakan otorisasi secara eksplisit ditentukan untuk mengizinkan akses ke layanan. Lihat Praktik Terbaik Kebijakan Otorisasi 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 layanan B.

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

Catatan: Cloud Service Mesh tidak menangani traffic non-TCP (misalnya UDP), sehingga tidak dapat dikontrol oleh kebijakan otorisasi. Administrator {i>mesh<i} dapat menggunakan Kebijakan Jaringan Kubernetes untuk menentukan kebijakan traffic UDP. Misalnya, jika layanan mesh tidak menggunakan UDP maka administrator mesh dapat menentukan kebijakan jaringan untuk memblokir traffic UDP.

Menerapkan pertukaran token untuk mengakses layanan mesh

Untuk bertahan dari serangan replay token yang mencuri token dan menggunakan kembali token yang dicuri token untuk mengakses layanan mesh, token dalam permintaan dari luar mesh harus ditukar dengan token internal mesh berjangka pendek di tepi mesh.

Permintaan dari luar mesh untuk mengakses layanan mesh perlu menyertakan tertentu, seperti JWT atau cookie, agar dapat diotentikasi dan diotorisasi oleh jaringan. Token dari luar mesh mungkin berumur panjang. Untuk bertahan melawan serangan ulang token, token dari luar {i>mesh<i} harus ditukarkan dengan token internal mesh berumur singkat dengan cakupan terbatas saat traffic masuk mesh. Layanan mesh mengautentikasi token internal mesh dan mengizinkan akses permintaan berdasarkan token internal mesh.

Langkah selanjutnya

• Meninjau praktik terbaik untuk menggunakan gateway keluar Cloud Service Mesh di cluster GKE
• Mengonfigurasi keamanan transportasi
• Memperbarui kebijakan otorisasi