Pola penjaga gerbang

Lindungi aplikasi dan layanan dengan menggunakan komponen khusus untuk perantara permintaan antara klien dan aplikasi atau layanan. Broker memvalidasi dan membersihkan permintaan, dan dapat memberikan lapisan keamanan tambahan dan membatasi permukaan serangan sistem.

Konteks dan masalah

Banyak layanan cloud mengekspos titik akhir yang memungkinkan aplikasi klien untuk memanggil API mereka di internet atau jaringan lain yang tidak tepercaya. Kode yang mengimplementasikan API memicu atau melakukan beberapa tugas, termasuk tetapi tidak terbatas pada autentikasi, otorisasi, validasi parameter, dan beberapa atau semua pemrosesan permintaan. Kode API kemungkinan akan mengakses penyimpanan dan layanan lain atas nama klien.

Jika pengguna berbahaya mengorbankan sistem dan mendapatkan akses ke lingkungan hosting aplikasi, mekanisme keamanan dan aksesnya ke data dan layanan lain diekspos. Akibatnya, pengguna berbahaya dapat memperoleh akses tidak terbatas ke kredensial, kunci penyimpanan, informasi sensitif, dan layanan lainnya.

Solusi

Salah satu solusi untuk masalah ini adalah memisahkan kode yang mengimplementasikan titik akhir publik dari kode yang memproses permintaan dan mengakses penyimpanan. Pisahkan kode dengan menggunakan lapisan fasad yang berinteraksi dengan klien dan meneruskan permintaan yang disetujui melalui titik akhir internal, antrean, atau broker menuju komponen beban kerja yang menangani operasi bisnis. Diagram memberikan gambaran umum tingkat tinggi tentang pola ini.

Anda dapat menggunakan pola Gatekeeper untuk melindungi penyimpanan, atau Anda dapat menggunakannya sebagai fasad yang lebih komprehensif untuk melindungi semua fungsi aplikasi. Faktor-faktor penting meliputi:

Validasi terkontrol: Penjaga gerbang memvalidasi semua permintaan, dan menolak permintaan yang tidak memenuhi persyaratan validasi.
Risiko dan paparan terbatas: Risiko dan paparan berkurang karena penjaga gerbang tidak mengakses kredensial atau kunci yang digunakan host tepercaya untuk mengakses penyimpanan dan layanan. Jika penjaga gerbang menjadi disusupi, penyerang tidak dapat mengakses kredensial atau kunci ini.
Keamanan yang sesuai: Penjaga gerbang berjalan dalam mode hak istimewa terbatas, sementara aplikasi lainnya berjalan dalam mode kepercayaan penuh yang diperlukan untuk mengakses penyimpanan dan layanan. Jika gatekeeper dikompromikan, ia tidak dapat langsung mengakses layanan aplikasi atau data.

Pola ini bertindak seperti firewall dalam topografi jaringan yang khas. Tidak seperti firewall tradisional, itu memungkinkan penjaga gerbang untuk memeriksa permintaan secara rinci dan membuat keputusan berbasis aplikasi tentang apakah akan meneruskan permintaan ke host tepercaya yang melakukan tugas yang diperlukan. Keputusan ini biasanya mengharuskan penjaga gerbang untuk memvalidasi dan membersihkan konten permintaan sebelum meneruskannya ke host tepercaya. Gatekeepers dapat mengotorisasi permintaan, mencari konten payload yang tidak terduga atau tidak valid, melakukan pembatasan tarif, dan melakukan berbagai pemeriksaan lainnya.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:

Pastikan bahwa host yang tepercaya hanya menyediakan endpoint internal atau terlindungi yang hanya digunakan oleh gatekeeper. Host tepercaya tidak boleh mengekspos titik akhir atau antarmuka eksternal apa pun.
Penjaga gerbang harus berjalan dalam mode hak istimewa terbatas. Dalam praktiknya, tempatkan gatekeeper dan back end tepercaya pada lingkungan komputasi yang terpisah, dan pastikan endpoint back end tetap privat.
Penjaga gerbang tidak boleh melakukan pemrosesan yang terkait dengan aplikasi atau layanan atau data akses. Fungsinya hanya untuk memvalidasi dan membersihkan permintaan. Host tepercaya mungkin perlu melakukan validasi permintaan tambahan, tetapi penjaga gerbang harus melakukan validasi inti.
Gunakan saluran komunikasi yang aman seperti HTTPS, Secure Sockets Layer (SSL), atau Transport Layer Security (TLS) antara penjaga gerbang dan host atau tugas tepercaya jika memungkinkan. Namun, beberapa lingkungan hosting tidak mendukung HTTPS pada titik akhir internal.
Menambahkan lapisan tambahan untuk mengimplementasikan pola Gatekeeper kemungkinan akan memengaruhi performa karena pemrosesan ekstra dan komunikasi jaringan yang diperlukan.
Penjaga gerbang bisa menjadi satu titik kegagalan (SPoF). Untuk meminimalkan dampak kegagalan, pertimbangkan untuk menyebarkan instans redundan dan menggunakan mekanisme penskalaan otomatis untuk memastikan kapasitas dan mempertahankan ketersediaan.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

Anda menangani informasi sensitif.
Anda mengekspos layanan yang memerlukan perlindungan kuat dari lalu lintas berbahaya.
Anda melakukan operasi misi penting yang tidak dapat mentolerir paparan langsung layanan back-end.
Anda perlu memisahkan validasi dan sanitasi permintaan dari pemrosesan logika bisnis inti.

Pola ini mungkin tidak cocok ketika:

Anda dapat memenuhi persyaratan keamanan dan validasi melalui kontrol platform bawaan pada layanan back-end tanpa menambahkan tingkat penjaga gerbang khusus.
Menambahkan hop jaringan dan latensi validasi melanggar persyaratan latensi end-to-end yang ketat.

Desain beban kerja

Evaluasi cara menggunakan pola Gatekeeper dalam desain beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar kerangka kerja Azure Well-Architected. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Prinsip Dasar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda.	Penjaga gerbang dalam alur permintaan membantu Anda memusatkan fungsionalitas keamanan seperti firewall aplikasi web, perlindungan DDoS, deteksi bot, manipulasi permintaan, inisiasi autentikasi, dan pemeriksaan otorisasi. - SE:06 Kontrol jaringan - Pemantauan SE:10 dan deteksi ancaman
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Anda dapat menggunakan pola ini untuk menerapkan pembatasan laju pada tingkat gatekeeper alih-alih melakukan pemeriksaan laju pada tingkat node. Koordinasi status di antara semua node pada dasarnya tidak berkinerja tinggi. - PE:03 Pilih layanan

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

Pola Gatekeeper biasanya menerapkan jalur permintaan berlapis, di mana setiap lapisan memiliki tanggung jawab tertentu dan cakupan kepercayaan terbatas.

Unduh file Visio dari arsitektur ini.

Dalam desain ini, Azure Application Gateway dengan Azure Web Application Firewall adalah penjaga gerbang luar. Ini memeriksa lalu lintas yang menghadap internet dan menerapkan kontrol keamanan sebelum lalu lintas mencapai tingkat API. Azure API Management adalah penjaga gerbang dalam. Ini menerapkan kontrol spesifik API dan hanya meneruskan lalu lintas yang disetujui ke backend privat.

Misalnya, Azure Web Application Firewall dapat mendeteksi dan memblokir injeksi SQL dan pola skrip lintas situs, menerapkan protokol dan aturan ukuran permintaan, dan menerapkan pemfilteran berbasis bot dan IP sebelum permintaan mencapai API Management atau back end privat.

Saat Anda menggunakan API Management di lapisan dalam, API Management menerapkan kebijakan untuk permintaan masuk dan respons keluar di alur gateway. Untuk informasi selengkapnya tentang cara API Management memproses permintaan dan respons, lihat Kebijakan di API Management. Untuk opsi kebijakan seperti validasi JSON Web Token (JWT), pembatasan laju, transformasi header, dan pembentukan respons, lihat referensi kebijakan API Management.

Gunakan identitas terkelola untuk sumber daya Azure secara konsisten untuk autentikasi antarlayanan di jalur ini. Misalnya, API Management dapat menggunakan kebijakan authenticate with managed identity untuk memperoleh token Microsoft Entra saat melakukan panggilan ke backend tanpa menyimpan kredensial rahasia.

Backend tetap privat. Misalnya, back end dapat berupa aplikasi Azure App Service yang menggunakan titik akhir private, sehingga aplikasi dapat diakses secara privat.

Untuk beban kerja terkontainerisasi, salah satu alternatif adalah mengganti alur internal API Management dan App Service dengan komputasi berbasis ingress:

Azure Kubernetes Service (AKS), yang memberi Anda lebih banyak kontrol atas pilihan pengontrol ingress, kebijakan Kubernetes, topologi jaringan, dan operasi kluster.
Azure Container Apps, yang merupakan platform kontainer terkelola tanpa server yang menyediakan kemampuan ingress dan mengurangi manajemen infrastruktur.

Dalam alternatif ini, ingress dapat merutekan berdasarkan host atau jalur, melakukan terminasi TLS, dan mengekspos layanan yang hanya bersifat internal. Kemampuan khusus seperti batas permintaan dan mengizinkan atau menolak aturan bergantung pada implementasi ingress yang dipilih. Dalam semua kasus, jaga batas penjaga gerbang: terapkan validasi dan penegakan kebijakan saat masuk, dan jaga agar layanan ujung belakang hanya dapat dijangkau melalui jalur penjaga gerbang tersebut.

Setiap lapisan dalam jalur ini memancarkan log dan metrik yang harus Anda sentralisasi. Log diagnostik Azure Web Application Firewall mencatat aturan yang cocok dan diblokir untuk setiap permintaan. API Management memancarkan log gateway yang menangkap durasi permintaan, kode respons, dan hasil kebijakan. Layanan back-end menghasilkan telemetri tingkat aplikasi. Kumpulkan log dan metrik ini di Azure Monitor dan rutekan ke ruang kerja Log Analytics untuk kueri terpadu. Standarisasi korelasi permintaan end-to-end dengan membuat atau meneruskan ID korelasi di tepi dan menyebarkannya melalui API Management dan layanan back-end (misalnya, melalui header permintaan dan konteks pelacakan terdistribusi) sehingga satu transaksi tetap dapat dilacak di semua lapisan. Gunakan Microsoft Defender untuk Cloud untuk menampilkan rekomendasi keamanan di seluruh komponen penjaga gerbang. Atur pemberitahuan untuk tingkat pemblokiran Azure Web Application Firewall yang tidak wajar atau lonjakan error pada API Management guna mendeteksi ancaman sebelum ancaman tersebut mencapai back end privat.

Langkah berikutnya

Panduan berikut mungkin relevan saat Anda menerapkan pola ini:

Pola desain cloud berikut sering digunakan bersama dengan pola Gatekeeper:

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-06-03