Praktik terbaik keamanan Cloud Service Mesh

Dokumen ini menjelaskan praktik terbaik untuk membuat dan mengelola konfigurasi Cloud Service Mesh yang aman dan 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 Google Cloud lainnya untuk melindungi dari ancaman keamanan yang mungkin dihadapi aplikasi dalam mesh.

Audiens yang dituju untuk dokumen ini mencakup administrator yang mengelola kebijakan di Cloud Service Mesh dan pengguna yang menjalankan layanan di Cloud Service Mesh. Langkah-langkah 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 dengan cara yang terpadu. Pendekatan ini menggunakan pendekatan yang 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 untuk memberikan pengecualian dengan mengecualikan aplikasi, port, atau alamat IP tertentu agar tidak berpartisipasi dalam mesh. Memiliki kontrol untuk mengatur konfigurasi mesh dan pengecualian keamanan adalah hal yang penting.

Vektor serangan dan risiko keamanan

Vektor serangan

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

  • Serangan pemindahan data yang tidak sah. Misalnya, serangan yang menguping data sensitif atau kredensial 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 gelap ke hak istimewa yang ditingkatkan untuk melakukan operasi di jaringan.
  • Serangan denial of service (DoS).
  • Serangan botnet yang mencoba membahayakan dan memanipulasi layanan untuk meluncurkan serangan terhadap layanan lain.

Serangan juga dapat dikategorikan berdasarkan target serangan:

  • Serangan jaringan internal mesh. Serangan yang bertujuan untuk merusak, menyadap, atau meniru komunikasi layanan ke layanan atau layanan ke panel kontrol internal mesh.
  • Serangan bidang kontrol. Serangan yang bertujuan menyebabkan bidang kontrol berfungsi tidak semestinya (seperti serangan DoS), atau mengeksfiltrasi data sensitif dari bidang kontrol.
  • Serangan tepi mesh. Serangan yang bertujuan untuk merusak, menyadap, atau melakukan spoofing 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, mesh juga menghadapi risiko keamanan lainnya. Daftar berikut menjelaskan beberapa kemungkinan risiko keamanan:

  • Perlindungan keamanan 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 kebijakan dengan aman.
  • Mengabaikan upgrade image. 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). Software mesh dan konfigurasi kebijakan memerlukan pemeliharaan rutin untuk memanfaatkan mekanisme perlindungan keamanan terbaru.
  • Kurangnya visibilitas. Konfigurasi yang salah atau konfigurasi kebijakan mesh yang tidak aman dan traffic/operasi mesh yang abnormal tidak akan menarik perhatian administrator mesh.
  • Drift konfigurasi. Konfigurasi kebijakan dalam mesh menyimpang dari sumber tepercaya.

Langkah-langkah untuk melindungi mesh layanan

Bagian ini menyajikan manual 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 untuk mengamankan mesh layanan melalui integrasi beberapa mekanisme keamanan di berbagai lapisan, yang secara bersama-sama mencapai keamanan sistem secara keseluruhan berdasarkan 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 traffic masuk Cloud Service Mesh menyediakan kontrol akses untuk traffic eksternal dan mengamankan akses eksternal ke API yang diekspos oleh layanan dalam mesh.
    • Keamanan egress 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 masuk dan keluar Cloud Service Mesh menggunakan Certificate Authority Service.
    • Cloud Armor dapat mempertahankan diri dari serangan distributed denial of service (DDoS) eksternal dan serangan Lapisan 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 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 beban kerja
    • Selalu dapatkan info terbaru tentang rilis keamanan Cloud Service Mesh untuk memastikan biner Cloud Service Mesh yang berjalan di mesh Anda bebas dari kerentanan yang diketahui secara publik.
    • Workload Identity Federation for GKE memungkinkan workload mendapatkan kredensial untuk memanggil layanan Google dengan aman.
    • CNI (Container Network Interface) Kubernetes mencegah serangan eskalasi hak istimewa dengan menghilangkan kebutuhan akan penampung 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.
    • Pengontrol Kebijakan GKE Enterprise memvalidasi dan mengaudit konfigurasi kebijakan di mesh untuk mencegah konfigurasi yang salah.
    • Otorisasi Biner Google Cloud memastikan bahwa image beban kerja dalam mesh adalah image yang diotorisasi oleh administrator.
    • Google Cloud Audit Logging mengaudit operasi mesh.

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

diagram keamanan alur traffic

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 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 mengizinkan koneksi tanpa mTLS. Sebaliknya, mTLS ketat mewajibkan 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.

Untuk mengetahui informasi selengkapnya, lihat Cloud Service Mesh dengan 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 mengabaikan 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, baca artikel 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 masih 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 mempertahankan layanan Anda dari akses 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 memberikan otorisasi permintaan berdasarkan JWT. Cloud Service Mesh tidak bertindak sebagai penyedia JWT, tetapi mengautentikasi JWT berdasarkan endpoint kumpulan 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 mewakili pemanggil akhir dan layanan yang diminta memerlukan bukti bahwa layanan tersebut dipanggil atas nama pemanggil akhir. Menerapkan autentikasi JWT akan 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 yang dapat diakses.
  • Operasi 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) 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 terautentikasi yang berasal dari hasil autentikasi untuk mempertahankan diri dari akses tidak sah ke layanan atau data.

Secara default, akses ke layanan harus ditolak kecuali jika kebijakan otorisasi ditentukan 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 setiap jalur URL yang ditampilkan 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 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 mempertahankan diri 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 tepi mesh.

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

Langkah selanjutnya