Implementasi Zero Trust dengan ASM - Alibaba Cloud Service Mesh

Zero trust adalah model keamanan yang menghilangkan kepercayaan implisit di dalam maupun di luar perimeter jaringan. Alibaba Cloud Service Mesh (ASM) merupakan kerangka kerja utama untuk menerapkan arsitektur zero trust cloud-native. ASM mengintegrasikan otentikasi dan otorisasi ke dalam service mesh sehingga mekanisme tersebut tidak perlu lagi dikodekan langsung di dalam aplikasi. Pendekatan ini menyediakan solusi siap pakai yang dapat dikonfigurasi secara dinamis, memungkinkan pembaruan kebijakan keamanan secara mudah dan langsung berlaku. Topik ini menjelaskan alasan dan cara menggunakan ASM untuk menerapkan sistem zero trust.

Latar Belakang

Layanan mikro menawarkan berbagai manfaat, termasuk skalabilitas, kelincahan, penskalaan independen, isolasi logika bisnis, manajemen siklus hidup independen, serta pengembangan terdistribusi yang lebih sederhana. Namun, arsitektur terdistribusi ini juga membawa tantangan keamanan karena setiap layanan mikro menjadi target potensial serangan. Kubernetes menyediakan platform unggul untuk meng-host dan meng-orchestrate layanan mikro. Secara default, seluruh komunikasi antar layanan mikro tidak aman—mereka berkomunikasi melalui HTTP teks biasa, yang tidak memadai untuk persyaratan keamanan modern. Mengandalkan perimeter jaringan saja tidak cukup; jika sebuah layanan internal dikompromikan, penyerang dapat bergerak lateral untuk menyerang layanan lain di dalam jaringan. Oleh karena itu, trafik internal juga harus diamankan. Di sinilah nilai keamanan zero trust: model ini mensyaratkan verifikasi eksplisit untuk setiap permintaan dan menerapkan prinsip hak istimewa minimal untuk membatasi akses ke sumber daya.

Salah satu manfaat utama teknologi Service Mesh adalah kemampuannya mengamankan lingkungan produksi tanpa mengurangi produktivitas developer. Service Mesh menyediakan fondasi untuk mengadopsi pendekatan keamanan zero trust bagi layanan mikro, membantu Anda mencapai tujuan keamanan seperti otentikasi identitas yang kuat, otorisasi berbasis konteks, serta pencatatan log dan pemantauan menyeluruh untuk semua akses. Dengan memanfaatkan fitur-fitur mesh ini, Anda dapat menerapkan kontrol keamanan pada semua aplikasi dalam mesh. Sebagai contoh, Anda dapat memastikan bahwa seluruh trafik dienkripsi dan semua trafik masuk ke aplikasi diverifikasi oleh titik penegakan kebijakan (PEP).

Selain kebijakan jaringan Kubernetes untuk keamanan Lapisan 3, ASM menyediakan otentikasi peer, otentikasi permintaan, kebijakan otorisasi Istio, serta kebijakan OPA detail halus. Kemampuan keamanan zero trust ini dalam ASM membantu Anda mencapai tujuan keamanan Anda.

Kerangka teoretis untuk kemampuan ASM mencakup aspek-aspek berikut:

Identitas workload: Sebagai fondasi zero trust, ASM menyediakan identitas terpadu untuk setiap Service Mesh cloud-native. ASM menawarkan cara sederhana untuk mendefinisikan identitas bagi setiap workload dalam service mesh dan menyediakan mekanisme kustomisasi untuk memperluas sistem identitas sesuai skenario tertentu. Identitas ini kompatibel dengan standar SPIFFE komunitas.
Sertifikat keamanan: Sertifikat merupakan komponen inti dari zero trust. ASM menyediakan penerbitan sertifikat, manajemen siklus hidup, dan rotasi. Setiap proxy menggunakan sertifikat TLS X.509 untuk menetapkan identitasnya. ASM juga mengelola rotasi sertifikat dan kunci privat.
Penegakan kebijakan: Mesin kepercayaan berbasis kebijakan merupakan inti dari zero trust. Selain mendukung kebijakan Kontrol Akses Berbasis Peran (RBAC) Istio, ASM juga menyediakan kebijakan otorisasi yang lebih granular berbasis OPA.
Visualisasi dan analisis: Untuk memberikan wawasan tentang sistem zero trust, ASM menawarkan mekanisme observabilitas untuk memantau log dan metrik dari eksekusi kebijakan, sehingga Anda dapat mengevaluasi kinerja setiap kebijakan.

Mengapa menggunakan ASM untuk menerapkan zero trust

Arsitektur ASM menawarkan beberapa manfaat keamanan dibandingkan pendekatan tradisional yang membangun mekanisme keamanan langsung ke dalam kode aplikasi:

Siklus hidup proxy sidecar bersifat independen dari aplikasi, sehingga proxy lebih mudah dikelola.
ASM memungkinkan konfigurasi dinamis. Anda dapat memperbarui kebijakan dengan mudah, dan perubahan tersebut langsung berlaku tanpa perlu melakukan redeploy aplikasi.
Arsitektur kontrol terpusat ASM memungkinkan tim keamanan perusahaan untuk membangun, mengelola, dan menerapkan kebijakan keamanan di seluruh organisasi. Hal ini memastikan bahwa aplikasi bisnis aman secara default, dan developer dapat memanfaatkan kebijakan keamanan tersebut tanpa usaha tambahan.
ASM dapat mengotentikasi kredensial pengguna akhir yang dilampirkan pada permintaan, seperti Token Web JSON (JWT).
Dengan arsitektur ASM, Anda dapat menerapkan sistem otentikasi dan otorisasi sebagai layanan dalam mesh. Seperti layanan lain dalam mesh, sistem keamanan ini juga mendapatkan jaminan keamanan dari mesh, termasuk enkripsi transport, identitas kuat, titik penegakan kebijakan, serta otentikasi dan otorisasi kredensial pengguna akhir.

Dengan ASM, Anda dapat menggunakan satu lapisan kontrol untuk menerapkan manajemen identitas dan akses yang kuat, enkripsi TLS transparan, otentikasi, otorisasi, serta pencatatan log audit. Instalasi dan manajemennya yang sederhana memungkinkan developer, administrator sistem, dan tim keamanan melindungi aplikasi layanan mikro mereka.

Menggunakan sistem zero trust ASM

ASM mengurangi permukaan serangan di lingkungan cloud-native dan menyediakan kerangka dasar untuk jaringan aplikasi zero trust. Dengan mengelola keamanan antar layanan, ASM memastikan enkripsi end-to-end, otentikasi tingkat layanan, serta kebijakan otorisasi detail halus.

Kerangka ASM mendukung hal-hal berikut:

Terapkan otentikasi mutual TLS (mTLS) atau otentikasi TLS sisi server antar layanan, dengan dukungan manajemen siklus hidup sertifikat otomatis, termasuk rotasi. Seluruh komunikasi dalam mesh diautentikasi dan dienkripsi.
Aktifkan otorisasi detail halus berbasis identitas, serta otorisasi berdasarkan parameter lainnya. Berdasarkan Kontrol Akses Berbasis Peran (RBAC), ASM mendukung postur "hak istimewa minimal", di mana hanya layanan yang berwenang yang dapat berkomunikasi satu sama lain berdasarkan aturan ALLOW atau DENY.

ASM menyediakan kemampuan keamanan zero trust dasar, termasuk identitas workload, otentikasi peer, otentikasi permintaan, kebijakan otorisasi, dan kebijakan OPA.

Identitas workload

Ketika sebuah aplikasi berjalan di lingkungan ASM, ASM menyediakan identitas unik untuk setiap layanan. Identitas layanan ini dapat digunakan untuk otentikasi timbal balik guna memverifikasi akses antar layanan dan dalam kebijakan otorisasi.

Ketika Anda menggunakan ASM untuk mengelola workload yang berjalan di Kubernetes, ASM menyediakan identitas layanan untuk setiap workload. Identitas ini didasarkan pada token akun layanan workload tersebut.

Identitas layanan dalam ASM sesuai dengan standar SPIFFE dan menggunakan format berikut: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.

Anda dapat login ke Konsol ASM untuk melihat layanan yang terhubung dari kluster Kubernetes.

Login ke Konsol ASM. Di panel navigasi kiri, pilih Service Mesh > Mesh Management.
Di halaman Mesh Management, klik nama instans ASM. Di panel navigasi kiri, pilih Mesh Security Center > Workload Identity.
Di halaman Workload Identity, atur Data Plane ke ID kluster dan pilih Namespaces untuk melihat identitas workload layanan dari kluster Kubernetes yang ditambahkan ke service mesh.

Otentikasi peer

ASM menyediakan dua jenis otentikasi: otentikasi peer dan otentikasi permintaan. Otentikasi peer menggunakan mutual TLS untuk mengotentikasi peer ketika dua layanan mikro berinteraksi.

Jika baik klien maupun server memiliki proxy sidecar yang disuntikkan, komunikasi mTLS diaktifkan secara default di ASM.
Jika hanya klien yang memiliki proxy sidecar yang disuntikkan, klien yang menentukan apakah akan menggunakan komunikasi mTLS berdasarkan konfigurasi server.
Jika hanya server yang memiliki proxy sidecar yang disuntikkan, mode mTLS default adalah PERMISSIVE, yang menerima trafik teks biasa maupun terenkripsi. Jika Anda mengonfigurasi kebijakan PeerAuthentication untuk server dan mengatur mode mTLS ke STRICT, permintaan akan gagal.

Otentikasi permintaan

Otentikasi permintaan memungkinkan pengguna akhir dan sistem berinteraksi dengan layanan mikro. Hal ini biasanya dilakukan menggunakan Token Web JSON (JWT).

Ketika sebuah layanan mikro diminta, Anda dapat membuat kebijakan otentikasi permintaan untuk melakukan validasi JWT pada permintaan masuk. Kebijakan ini memvalidasi permintaan yang berisi JWT. Hanya permintaan dengan JWT yang valid yang dapat berhasil mengakses layanan. Permintaan tanpa JWT tidak divalidasi dan dapat mengakses layanan tanpa batasan.

Catatan

Untuk memastikan bahwa hanya permintaan dengan JWT valid yang dapat mengakses layanan, gabungkan otentikasi permintaan dengan kebijakan otorisasi. Konfigurasi ini menolak permintaan yang memiliki JWT tidak valid atau tidak memiliki JWT.

Deploy aplikasi bookinfo yang akan menerima permintaan. Untuk informasi lebih lanjut, lihat Deploy aplikasi di kluster yang terkait dengan instans ASM.

Deploy aplikasi sleep yang akan mengirim permintaan.

Di lingkungan KubeConfig untuk kluster ACK Anda, buat file sleep.yaml.

File Sleep.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

Jalankan perintah berikut untuk deploy aplikasi sleep.
```
kubectl apply -f sleep.yaml -n default 
```

Buat kebijakan otentikasi permintaan untuk menerapkan otentikasi JWT pada permintaan inbound ke layanan details.
1. Login ke Konsol ASM. Di panel navigasi kiri, pilih Service Mesh > Mesh Management.
2. Di halaman Mesh Management, klik nama instans ASM. Di panel navigasi kiri, pilih Mesh Security Center > RequestAuthentication. Di halaman yang muncul, klik Create.
3. Di halaman pembuatan, atur parameter berikut lalu klik Create untuk mendefinisikan aturan JWT untuk workload details.
  
  Pilih namespace default, atur nama menjadi test, dan tambahkan pemilih label dengan nama app dan nilai details.
  
  Berikut penjelasan beberapa parameter:
  - issuer: Penerbit JWT. Untuk contoh ini, atur ke testing@secure.istio.io.
  - audiences: Daftar audiens untuk JWT. Ini menentukan layanan mana yang dapat menggunakan JWT untuk mengakses layanan target. Untuk contoh ini, biarkan kosong, artinya akses tidak dibatasi ke layanan tertentu.
  - jwks: JSON Web Key Set (JWKS) untuk JWT. Untuk contoh ini, gunakan JWKS berikut. Untuk informasi lebih lanjut, lihat jwks.json.
```
{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}
```

Untuk menghasilkan token yang digunakan pada langkah berikutnya, Anda dapat menggunakan tool JWT. Token harus dibuat menggunakan kunci privat yang sesuai dengan kunci publik dalam JWKS dan mencantumkan issuer testing@secure.istio.io.

{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

Token yang diharapkan adalah:

eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

Verifikasi bahwa kebijakan otentikasi permintaan telah berlaku.

Jalankan perintah berikut untuk mengakses layanan details menggunakan JWT yang telah dikodekan.

export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'

Kode status 200 dikembalikan, menunjukkan akses berhasil.

Jalankan perintah berikut untuk mengakses layanan details menggunakan JWT yang tidak valid.

kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'

Kode status 403 dikembalikan, menunjukkan akses gagal.

Jalankan perintah berikut untuk mengakses layanan details tanpa JWT.
```
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
```
Kode status 200 dikembalikan, menunjukkan akses berhasil.

Hasil ini menunjukkan bahwa permintaan dengan JWT valid berhasil, permintaan dengan JWT tidak valid gagal, dan permintaan tanpa JWT berhasil. Hal ini mengonfirmasi bahwa kebijakan otentikasi permintaan berfungsi sebagaimana diharapkan.

Kebijakan otorisasi

Ketika sebuah layanan mikro diminta, Anda dapat menggunakan kebijakan otorisasi untuk membatasi akses berdasarkan port permintaan, alamat IP, sumber, dan lainnya. Hanya permintaan yang memenuhi persyaratan yang dapat mengakses layanan. Kebijakan otorisasi berikut membatasi akses berdasarkan sumber permintaan dengan mensyaratkan bahwa permintaan berisi JWT dari penerbit tertentu.

Deploy aplikasi bookinfo yang akan menerima permintaan. Untuk informasi lebih lanjut, lihat Deploy aplikasi di kluster yang terkait dengan instans ASM.

Deploy aplikasi sleep yang akan mengirim permintaan.

Buat file sleep.yaml dengan konten berikut.

File Sleep.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep", "3650d"]
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

Di lingkungan KubeConfig untuk kluster ACK Anda, jalankan perintah berikut untuk deploy aplikasi sleep.
```
kubectl apply -f sleep.yaml -n default 
```

Buat kebijakan otorisasi.
1. Login ke Konsol ASM. Di panel navigasi kiri, pilih Service Mesh > Mesh Management.
2. Di halaman Mesh Management, klik nama instans ASM. Di panel navigasi kiri, pilih Mesh Security Center > AuthorizationPolicy. Di halaman yang muncul, klik Create from YAML.

Di halaman Create, pilih namespace default, masukkan YAML berikut, lalu klik Create.

Untuk informasi lebih lanjut tentang bidang-bidang tersebut, lihat Kebijakan Otorisasi.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals:
              - testing@secure.istio.io/testing@secure.istio.io
  selector:
    matchLabels:
      app: details

Jalankan perintah berikut untuk mengirim permintaan tanpa JWT guna mengakses layanan.
```
 kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'
```
Output yang diharapkan:
```
403
```
Permintaan ke layanan details tanpa JWT gagal, yang mengonfirmasi bahwa kebijakan otorisasi telah berlaku. Kebijakan ini mensyaratkan bahwa semua permintaan harus berisi JWT yang diterbitkan oleh testing@secure.istio.io agar berhasil mengakses layanan.

Kebijakan OPA

OPA adalah mesin kebijakan yang memungkinkan kontrol akses detail halus untuk aplikasi Anda. Sebagai mesin kebijakan tujuan umum, OPA dapat dideploy sebagai layanan mandiri bersama layanan mikro Anda. Untuk melindungi aplikasi, setiap permintaan ke layanan mikro harus diautorisasi sebelum diproses. Layanan mikro meng-query API OPA untuk menentukan apakah permintaan tersebut boleh dilanjutkan. Untuk informasi lebih lanjut, lihat OPA.

ASM mengintegrasikan Plugin OPA, yang memungkinkan Anda mendefinisikan kebijakan kontrol akses menggunakan OPA untuk mencapai kontrol akses detail halus bagi aplikasi Anda. Kebijakan OPA ini juga dapat diperbarui secara dinamis. Untuk informasi lebih lanjut, lihat Perbarui kebijakan OPA secara dinamis di ASM.

Rangkuman dan kasus penggunaan

Secara ringkas, ASM menyediakan komponen-komponen berikut yang meningkatkan keamanan:

Infrastruktur sertifikat terkelola dengan manajemen siklus hidup sertifikat lengkap yang menyederhanakan penerbitan sertifikat dan rotasi CA.
API lapisan kontrol terkelola untuk mendistribusikan kebijakan otentikasi, kebijakan otorisasi, dan informasi penamaan aman ke proxy Envoy.
Proxy sidecar yang berfungsi sebagai titik penegakan kebijakan (PEP) untuk membantu mengamankan mesh.
Ekstensi proxy Envoy yang memungkinkan pengumpulan telemetri dan auditing.

Setiap workload menggunakan sertifikat TLS X.509 untuk menetapkan identitasnya. Sertifikat ini kemudian digunakan oleh proxy sidecar workload tersebut. ASM menyediakan dan secara berkala merotasi sertifikat serta kunci privat ini. Jika kunci privat dikompromikan, ASM dapat segera menggantinya dengan yang baru, sehingga secara signifikan mengurangi permukaan serangan.

Kasus penggunaan

Gunakan kebijakan otorisasi pada gerbang masuk untuk menerapkan kontrol akses berbasis IP atau kontrol akses berdasarkan authorizer eksternal kustom.
Seorang pelanggan keuangan internet perlu mengelola izin akses untuk aplikasi multi-bahasa lintas kluster. Mereka menggunakan kebijakan otorisasi ASM untuk mengisolasi zona yang menghadap eksternal dari zona aplikasi internal. Dalam kombinasi dengan gerbang keluar untuk auditing trafik mesh, mereka juga menggunakan kebijakan otorisasi untuk mengontrol akses aplikasi ke layanan pihak ketiga.