Azure Firewall dan Application Gateway untuk jaringan virtual

Azure Application Gateway

Azure Firewall

Azure Front Door

Microsoft Azure Virtual Network

Azure Web Application Firewall

Untuk membantu mengamankan beban kerja aplikasi Azure, gunakan langkah-langkah perlindungan seperti autentikasi dan enkripsi dalam aplikasi itu sendiri. Anda dapat menambahkan lapisan keamanan ke jaringan virtual yang menghosting aplikasi. Lapisan keamanan ini membantu melindungi alur masuk aplikasi dari penggunaan yang tidak diinginkan. Mereka juga membatasi alur keluar ke internet hanya untuk titik akhir yang diperlukan aplikasi Anda. Artikel ini menjelaskan azure Virtual Network layanan keamanan seperti Azure DDoS Protection, Azure Firewall, dan Azure Application Gateway. Ini juga menjelaskan kapan harus menggunakan setiap layanan dan opsi desain jaringan yang menggabungkannya.

• DDoS Protection, dikombinasikan dengan praktik terbaik desain aplikasi, menyediakan fitur mitigasi DDoS yang ditingkatkan yang meningkatkan pertahanan terhadap serangan DDoS. Anda harus mengaktifkan DDoS Protection di setiap jaringan virtual perimeter.

• Azure Firewall adalah firewall terkelola generasi berikutnya yang menyediakan kemampuan terjemahan alamat jaringan (NAT). Azure Firewall memfilter paket berdasarkan alamat IP dan port Protokol Kontrol Transmisi (TCP) atau Protokol Datagram Pengguna (UDP). Ini dapat memfilter lalu lintas dengan menggunakan atribut berbasis aplikasi, seperti HTTP(S) dan SQL. Azure Firewall juga menerapkan inteligensi ancaman Microsoft untuk membantu mengidentifikasi alamat IP berbahaya. Untuk informasi selengkapnya, lihat dokumentasi Azure Firewall.

• Azure Firewall Premium mencakup semua fungsionalitas Azure Firewall Standard, selain fitur seperti inspeksi keamanan lapisan transportasi (TLS) dan sistem deteksi dan pencegahan intrusi (IDPS).

• Application Gateway adalah load balancer lalu lintas web terkelola dan proksi terbalik penuh HTTP(S) yang dapat melakukan enkripsi dan dekripsi Secure Socket Layer (SSL). Application Gateway mempertahankan alamat IP klien asli di header HTTP X-Forwarded-For. Application Gateway juga menggunakan Azure Web Application Firewall untuk memeriksa lalu lintas web dan mendeteksi serangan di lapisan HTTP. Untuk informasi selengkapnya, lihat dokumentasi Application Gateway.

• Web Application Firewall adalah tambahan opsional untuk Application Gateway. Ini memeriksa permintaan HTTP dan mencegah serangan lapisan web, seperti injeksi SQL dan skrip lintas situs. Untuk informasi selengkapnya, lihat dokumentasi Web Application Firewall.

Layanan Azure ini saling melengkapi. Tergantung pada kebutuhan Anda, menggunakan satu layanan mungkin lebih sesuai dengan beban kerja Anda. Namun, Anda dapat menggunakan layanan ini bersama-sama untuk membantu memberikan perlindungan optimal di lapisan jaringan dan aplikasi. Gunakan pohon keputusan berikut dan contoh dalam artikel ini untuk memilih opsi keamanan terbaik untuk jaringan virtual aplikasi Anda.

Azure Firewall dan Application Gateway menggunakan teknologi yang berbeda untuk membantu mengamankan berbagai jenis aliran data.

Alur Aplikasi	Dapat difilter oleh Azure Firewall	Dapat difilter oleh Web Application Firewall di Application Gateway
Lalu lintas HTTP dari lokal atau internet ke Azure (masuk)	Ya	Ya
Lalu lintas HTTP dari Azure ke lokal atau internet (keluar)	Ya	Tidak
Lalu lintas non-HTTP (masuk atau keluar)	Ya	Tidak

Desain dapat bervariasi untuk setiap aplikasi berdasarkan alur jaringan yang diperlukan. Diagram berikut menyediakan pohon keputusan yang disederhanakan yang membantu Anda memilih pendekatan yang direkomendasikan untuk aplikasi Anda. Pilihan ini tergantung pada apakah aplikasi diterbitkan melalui HTTP(S) atau beberapa protokol lainnya.

Artikel ini menjelaskan desain yang direkomendasikan secara luas yang ditunjukkan dalam bagan alur dan desain yang cocok untuk skenario yang kurang umum:

• Azure Firewall hanya: Gunakan desain ini ketika tidak ada aplikasi web di jaringan virtual. Ini mengontrol lalu lintas masuk ke aplikasi dan lalu lintas keluar.

• Application Gateway hanya: Gunakan desain ini ketika hanya aplikasi web yang berada di jaringan virtual dan kelompok keamanan jaringan (NSG) menyediakan pemfilteran output yang memadai. Azure Firewall menyediakan fungsionalitas yang dapat membantu mencegah beberapa skenario serangan, seperti eksfiltrasi data dan IDPS. Akibatnya, desain khusus Application Gateway biasanya tidak direkomendasikan, sehingga tidak disertakan dalam bagan alur sebelumnya.

• Azure Firewall dan Application Gateway secara paralel: Gunakan desain ini saat Anda ingin Application Gateway melindungi aplikasi HTTP dari serangan web dan Azure Firewall untuk melindungi semua beban kerja lainnya dan memfilter lalu lintas keluar. Azure Firewall dan Application Gateway secara paralel adalah desain umum.

• Application Gateway di depan Azure Firewall: Gunakan desain ini saat Anda ingin Azure Firewall memeriksa semua lalu lintas, Web Application Firewall untuk melindungi lalu lintas web, dan aplikasi untuk mengidentifikasi alamat IP sumber klien. Dengan inspeksi Azure Firewall Premium dan TLS, desain ini juga mendukung skenario SSL end-to-end.

• Azure Firewall di depan Application Gateway: Gunakan desain ini saat Anda ingin Azure Firewall memeriksa dan memfilter lalu lintas sebelum mencapai Application Gateway. Karena Azure Firewall tidak mendekripsi lalu lintas HTTPS, fungsionalitas yang ditambahkan ke Application Gateway terbatas. Skenario ini tidak didokumenkan di bagan alur sebelumnya.

Variasi desain mendasar ini dijelaskan nanti dalam artikel ini dan meliputi:

• Klien aplikasi lokal.
• jaringan Hub-and-spoke.
• implementasi Azure Kubernetes Service (AKS).

Anda dapat menambahkan layanan proksi terbalik lainnya, seperti gateway Azure API Management atau Azure Front Door. Atau Anda dapat mengganti sumber daya Azure dengan appliance virtual jaringan (NVA) non-Microsoft .

Nota

Dalam skenario berikut, komputer virtual (VM) Azure digunakan sebagai contoh beban kerja aplikasi web. Skenario ini juga valid untuk jenis beban kerja lainnya, seperti kontainer atau Azure Web Apps. Untuk penyiapan yang menyertakan titik akhir privat, pertimbangkan rekomendasi dalam skenario Azure Firewall untuk memeriksa lalu lintas yang ditujukan ke titik akhir privat.

Desain khusus Azure Firewall

Jika tidak ada beban kerja berbasis web di jaringan virtual yang dapat memperoleh manfaat dari Web Application Firewall, Anda dapat menggunakan desain khusus Azure Firewall. Desain dalam contoh ini sederhana, tetapi Anda dapat meninjau alur paket untuk lebih memahami desain yang lebih kompleks. Dalam desain ini, semua lalu lintas masuk dikirim ke Azure Firewall melalui rute yang ditentukan pengguna (UDR) untuk koneksi dari lokal atau jaringan virtual Azure lainnya. Ini ditujukan ke alamat IP publik Azure Firewall untuk koneksi dari internet publik, seperti yang ditunjukkan dalam diagram berikut. UDR mengarahkan lalu lintas keluar dari jaringan virtual Azure ke Azure Firewall, seperti yang ditunjukkan dalam dialog berikut.

Tabel berikut ini meringkas arus lalu lintas untuk skenario ini.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Tidak tersedia	Ya
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak tersedia	Ya
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak tersedia	Ya
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak tersedia	Ya

Azure Firewall tidak memeriksa lalu lintas HTTP masuk. Tetapi dapat menerapkan aturan lapisan 3 dan lapisan 4 dan aturan aplikasi berbasis nama domain yang sepenuhnya memenuhi syarat (FQDN). Azure Firewall memeriksa lalu lintas HTTP keluar, tergantung pada tingkat Azure Firewall dan apakah Anda mengonfigurasi inspeksi TLS:

• Azure Firewall Standard hanya memeriksa atribut paket lapisan 3 dan lapisan 4 dalam aturan jaringan dan header HTTP Host dalam aturan aplikasi.

• Azure Firewall Premium menambahkan kemampuan, seperti memeriksa header HTTP lainnya (seperti agen pengguna) dan mengaktifkan inspeksi TLS untuk analisis paket yang lebih dalam. Namun, Azure Firewall tidak sama dengan Web Application Firewall. Jika Anda memiliki beban kerja web di jaringan virtual Anda, kami sarankan Anda menggunakan Web Application Firewall.

Contoh panduan paket berikut menunjukkan bagaimana klien mengakses aplikasi yang dihosting VM dari internet publik. Diagram hanya mencakup satu VM untuk kesederhanaan. Untuk ketersediaan dan skalabilitas yang lebih tinggi, ada beberapa instans aplikasi di belakang load balancer. Dalam desain ini, Azure Firewall memeriksa koneksi masuk dari internet publik dan koneksi keluar dari VM subnet aplikasi dengan menggunakan UDR.

• Dalam contoh ini, Azure Firewall secara otomatis menyebarkan beberapa instans dengan alamat IP front-end 192.168.100.4 dan alamat internal dalam rentang 192.168.100.0/26. Biasanya, instans ini tidak terlihat oleh administrator Azure. Namun, menyadarinya dapat membantu untuk memecahkan masalah jaringan.

• Jika lalu lintas berasal dari jaringan privat virtual (VPN) lokal atau gateway Azure ExpressRoute alih-alih internet, klien memulai koneksi ke alamat IP VM. Ini tidak memulai koneksi ke alamat IP firewall, dan firewall tidak melakukan NAT sumber secara default.

Arsitektur

Diagram berikut menunjukkan arus lalu lintas dan mengasumsikan bahwa alamat IP instans 192.168.100.7.

diagram

Alur kerja

1. Klien memulai koneksi ke alamat IP publik Azure Firewall.

   • Alamat IP sumber: ClientPIP
   • Alamat IP tujuan: AzFwPIP

2. Permintaan ke alamat IP publik Azure Firewall didistribusikan ke instans back-end firewall, yang 192.168.100.7 dalam contoh ini. Aturan Azure Firewall Destination Network Address Translation (DNAT) menerjemahkan alamat IP tujuan ke alamat IP aplikasi di dalam jaringan virtual. Azure Firewall juga menerapkan terjemahan alamat jaringan sumber (SNAT) pada paket jika menggunakan DNAT. Untuk informasi selengkapnya, lihat masalah umum Azure Firewall. VM melihat alamat IP berikut dalam paket masuk:

   • Alamat IP sumber: 192.168.100.7
   • Alamat IP tujuan: 192.168.1.4

3. VM menjawab permintaan aplikasi, yang membalikkan alamat IP sumber dan tujuan. Alur masuk tidak memerlukan UDR karena IP sumber adalah alamat IP Azure Firewall. UDR dalam diagram untuk 0.0.0.0/0 adalah untuk koneksi keluar untuk memastikan bahwa paket ke internet publik melalui Azure Firewall.

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.100.7

4. Azure Firewall membatalkan operasi SNAT dan DNAT dan memberikan respons kepada klien.

   • Alamat IP sumber: AzFwPIP
   • Alamat IP tujuan: ClientPIP

Desain khusus Application Gateway

Desain ini menjelaskan skenario di mana hanya aplikasi web yang ada di jaringan virtual, dan memeriksa lalu lintas keluar dengan NSG cukup untuk melindungi alur keluar ke internet.

Nota

Kami tidak merekomendasikan desain ini karena menggunakan Azure Firewall untuk mengontrol alur keluar, alih-alih hanya mengandalkan NSG, membantu mencegah skenario serangan seperti penyelundupan data. Dengan Azure Firewall, Anda dapat membantu memastikan bahwa beban kerja Anda hanya mengirim data ke daftar URL yang disetujui. Selain itu, NSG hanya beroperasi pada lapisan 3 dan lapisan 4 dan tidak mendukung FQDN.

Perbedaan utama dari desain khusus Azure Firewall sebelumnya adalah bahwa Application Gateway tidak berfungsi sebagai perangkat perutean dengan NAT. Sebaliknya, ini berfungsi sebagai proksi aplikasi terbalik penuh. Pendekatan ini berarti bahwa Application Gateway menghentikan sesi web dari klien dan membuat sesi terpisah dengan salah satu server back-end-nya. Koneksi HTTP masuk dari internet dikirim ke alamat IP publik Application Gateway, dan koneksi dari Azure atau lokal menggunakan alamat IP privat gateway. Mengembalikan lalu lintas dari Azure VM mengikuti perutean jaringan virtual standar kembali ke Application Gateway. Untuk informasi selengkapnya, lihat panduan paket nanti di artikel ini. Aliran internet keluar dari Azure VM langsung masuk ke internet.

Tabel berikut ini meringkas arus lalu lintas.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Ya	Tidak tersedia
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak	Tidak tersedia
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak	Tidak tersedia
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak	Tidak tersedia

Arsitektur

Contoh panduan paket berikut menunjukkan bagaimana klien mengakses aplikasi yang dihosting VM dari internet publik.

Alur kerja

1. Klien memulai koneksi ke alamat IP publik Application Gateway.

   • Alamat IP sumber: ClientPIP
   • Alamat IP tujuan: AppGwPIP

2. Permintaan ke alamat IP publik Application Gateway didistribusikan ke instans back-end gateway, yang 192.168.200.7 dalam contoh ini. Instans Application Gateway yang menerima permintaan menghentikan koneksi dari klien dan membuat koneksi baru dengan salah satu ujung belakang. Back end melihat instans Application Gateway sebagai alamat IP sumber. Application Gateway menyisipkan header HTTP X-Forwarded-For dengan alamat IP klien asli.

   • Alamat IP sumber, yang merupakan alamat IP privat instans Application Gateway: 192.168.200.7
   • Alamat IP tujuan: 192.168.1.4
   • header X-Forwarded-For: ClientPIP

3. VM menjawab permintaan aplikasi dan membalikkan alamat IP sumber dan tujuan. VM dapat mencapai Application Gateway, sehingga tidak memerlukan UDR.

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.200.7

4. Instans Application Gateway menjawab klien.

   • Alamat IP sumber: AppGwPIP
   • Alamat IP tujuan: ClientPIP

Application Gateway menambahkan metadata ke header HTTP paket, seperti header X-Forwarded-For yang berisi alamat IP klien asli. Beberapa server aplikasi memerlukan alamat IP klien sumber untuk melayani konten khusus geolokasi, atau untuk pengelogan. Untuk informasi selengkapnya, lihat Cara kerja gateway aplikasi.

• Dalam contoh ini, alamat IP 192.168.200.7 adalah salah satu instans yang disebarkan oleh layanan Application Gateway secara otomatis. Ini memiliki alamat IP front-end internal dan privat 192.168.200.4. Instans individual ini biasanya tidak terlihat oleh administrator Azure. Tetapi perhatikan perbedaannya dapat berguna, seperti ketika Anda memecahkan masalah jaringan.

• Alurnya mirip jika klien berasal dari jaringan lokal melalui vpn atau gateway ExpressRoute. Perbedaannya adalah klien mengakses alamat IP privat Application Gateway alih-alih alamat IP publik.

Nota

Untuk informasi selengkapnya tentang header X-Forwarded-For dan cara mempertahankan nama host berdasarkan permintaan, lihat Mempertahankan host HTTP asli.

Azure Firewall dan Application Gateway dalam desain paralel

Karena kesederhanaan dan fleksibilitasnya, seringkali yang terbaik adalah menjalankan Application Gateway dan Azure Firewall secara paralel.

Terapkan desain ini jika ada beban kerja web dan non-web di jaringan virtual. Web Application Firewall di Application Gateway membantu melindungi lalu lintas masuk ke beban kerja web. Azure Firewall memeriksa lalu lintas masuk untuk aplikasi lain. Azure Firewall mencakup alur keluar dari kedua jenis beban kerja.

Koneksi HTTP masuk dari internet harus dikirim ke alamat IP publik Application Gateway. Koneksi HTTP dari Azure atau lokal harus dikirim ke alamat IP privatnya. Perutean jaringan virtual standar mengirimkan paket dari Application Gateway ke VM tujuan, dan dari VM tujuan kembali ke Application Gateway. Untuk informasi selengkapnya, lihat panduan paket nanti di artikel ini.

Untuk koneksi non-HTTP masuk, lalu lintas harus menargetkan alamat IP publik Azure Firewall jika berasal dari internet publik. Lalu lintas harus dikirim melalui Azure Firewall oleh UDR jika berasal dari jaringan virtual Azure lainnya atau jaringan lokal. Semua alur keluar dari Azure VM diteruskan ke Azure Firewall oleh UDR.

Tabel berikut ini meringkas arus lalu lintas untuk skenario ini.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Ya	Tidak
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak	Ya
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak	Ya
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak	Ya

Desain ini menyediakan pemfilteran keluar yang jauh lebih terperinci daripada hanya menggunakan NSG. Misalnya, jika aplikasi memerlukan konektivitas ke akun Azure Storage tertentu, Anda dapat menggunakan filter berbasis FQDN. Dengan filter berbasis FQDN, aplikasi tidak mengirim data ke akun penyimpanan nakal. Jika Anda hanya menggunakan NSG, Anda tidak dapat mencegah skenario ini. Desain ini sering digunakan ketika lalu lintas keluar memerlukan pemfilteran berbasis FQDN. Salah satu skenarionya adalah ketika Anda membatasi lalu lintas keluar dari kluster AKS.

Arsitektur

Diagram berikut mengilustrasikan arus lalu lintas untuk koneksi HTTP masuk dari klien luar.

Diagram berikut mengilustrasikan arus lalu lintas untuk koneksi keluar dari VM jaringan ke internet. Salah satu contohnya adalah menyambungkan ke sistem back-end atau mendapatkan pembaruan sistem operasi.

Langkah-langkah alur paket untuk setiap layanan sama seperti pada opsi desain mandiri sebelumnya.

Application Gateway di depan desain Azure Firewall

Desain ini dijelaskan secara lebih rinci di jaringan Zero-trust untuk aplikasi web dengan Azure Firewall dan Application Gateway. Artikel ini berfokus pada perbandingan dengan opsi desain lainnya. Dalam topologi ini, lalu lintas web masuk melewati Azure Firewall dan Web Application Firewall. Web Application Firewall memberikan perlindungan pada lapisan aplikasi web. Azure Firewall berfungsi sebagai pencatatan pusat dan titik kontrol, dan memeriksa lalu lintas antara Application Gateway dan server back-end. Dalam desain ini, Application Gateway dan Azure Firewall tidak duduk secara paralel tetapi duduk satu di depan yang lain.

Dengan Azure Firewall Premium, desain ini dapat mendukung skenario end-to-end, di mana Azure Firewall menerapkan inspeksi TLS untuk melakukan IDPS pada lalu lintas terenkripsi antara Application Gateway dan back end web.

Desain ini cocok untuk aplikasi yang perlu mengidentifikasi alamat IP sumber klien yang masuk. Misalnya, dapat digunakan untuk melayani konten khusus geolokasi atau untuk pengelogan. Application Gateway di depan desain Azure Firewall mengambil alamat IP sumber paket masuk di header X-Forwarded-For, sehingga server web dapat melihat alamat IP asli di header ini. Untuk informasi selengkapnya, lihat Cara kerja gateway aplikasi.

Koneksi HTTP masuk dari internet perlu dikirim ke alamat IP publik Application Gateway. Koneksi HTTP dari Azure atau lokal harus dikirim ke alamat IP privatnya. Dari Application Gateway, UDR memastikan bahwa paket dirutekan melalui Azure Firewall. Untuk informasi selengkapnya, lihat panduan paket nanti di artikel ini.

Untuk koneksi non-HTTP masuk, lalu lintas harus menargetkan alamat IP publik Azure Firewall jika berasal dari internet publik. Lalu lintas harus dikirim melalui Azure Firewall oleh UDR jika berasal dari jaringan virtual Azure lainnya atau jaringan lokal. Semua alur keluar dari Azure VM diteruskan ke Azure Firewall oleh UDR.

Aspek penting dari desain ini adalah Azure Firewall Premium melihat lalu lintas dengan alamat IP sumber dari subnet Application Gateway. Jika subnet ini dikonfigurasi dengan alamat IP privat (dalam 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, atau 100.64.0.0/10), Azure Firewall Premium memperlakukan lalu lintas dari Application Gateway sebagai internal dan tidak menerapkan aturan IDPS untuk lalu lintas masuk. Akibatnya, kami sarankan Anda memodifikasi awalan privat IDPS dalam kebijakan Azure Firewall. Modifikasi ini memastikan bahwa subnet Application Gateway tidak dianggap sebagai sumber internal, yang memungkinkan tanda tangan IDPS masuk dan keluar diterapkan ke lalu lintas. Anda dapat menemukan informasi selengkapnya tentang arah aturan IDPS Azure Firewall dan awalan IP privat untuk IDPS di aturan IDPS Azure Firewall.

Tabel berikut ini meringkas arus lalu lintas untuk skenario ini.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Ya	Ya
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak	Ya
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak	Ya
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak	Ya

Untuk lalu lintas web dari lokal atau dari internet ke Azure, Azure Firewall memeriksa alur yang diizinkan Web Application Firewall. Bergantung pada apakah Application Gateway mengenkripsi lalu lintas back-end, yang merupakan lalu lintas dari Application Gateway ke server aplikasi, skenario yang berbeda dapat terjadi:

• Application Gateway mengenkripsi lalu lintas dengan mengikuti prinsip zero-trust seperti enkripsi TLS end-to-end, dan Azure Firewall menerima lalu lintas terenkripsi. Azure Firewall Standard masih dapat menerapkan aturan inspeksi, seperti pemfilteran lapisan 3 dan lapisan 4 dalam aturan jaringan, atau pemfilteran FQDN dalam aturan aplikasi, dengan menggunakan header Indikasi Nama Server TLS (SNI). Azure Firewall Premium memberikan visibilitas yang lebih dalam dengan inspeksi TLS, seperti pemfilteran berbasis URL.

• Jika Application Gateway mengirim lalu lintas yang tidak terenkripsi ke server aplikasi, Azure Firewall akan melihat lalu lintas masuk dalam teks yang jelas. Inspeksi TLS tidak diperlukan di Azure Firewall.

• Jika IDPS diaktifkan di Azure Firewall, idPS memverifikasi bahwa header Host HTTP cocok dengan alamat IP tujuan. Untuk melakukan verifikasi ini, diperlukan resolusi nama untuk FQDN yang ditentukan di header Host. Resolusi nama ini dapat dilakukan dengan menggunakan zona privat Azure DNS dan pengaturan DNS Azure Firewall default. Ini juga dapat dicapai dengan server DNS kustom yang perlu dikonfigurasi di pengaturan Azure Firewall. Jika Anda tidak memiliki akses administratif ke jaringan virtual tempat Azure Firewall disebarkan, metode terakhir adalah satu-satunya opsi Anda. Salah satu contohnya adalah dengan instans Azure Firewall yang disebarkan di hub aman Azure Virtual WAN.

Arsitektur

Untuk alur lainnya, yang mencakup lalu lintas non-HTTP masuk dan lalu lintas keluar apa pun, Azure Firewall menyediakan inspeksi IDPS dan inspeksi TLS jika cocok. Ini juga menyediakan pemfilteran berbasis FQDN dalam aturan jaringan berdasarkan DNS.

diagram

Alur kerja

Lalu lintas jaringan dari internet publik mengikuti alur ini:

1. Klien memulai koneksi ke alamat IP publik Application Gateway.

   • Alamat IP sumber: ClientPIP
   • Alamat IP tujuan: AppGwPIP

2. Permintaan ke alamat IP publik Application Gateway didistribusikan ke instans back-end gateway, yang 192.168.200.7 dalam contoh ini. Instans Application Gateway menghentikan koneksi dari klien dan membuat koneksi baru dengan salah satu ujung belakang. UDR untuk 192.168.1.0/24 di subnet Application Gateway meneruskan paket ke Azure Firewall dan mempertahankan alamat IP tujuan ke aplikasi web.

   • Alamat IP sumber, yang merupakan alamat IP privat instans Application Gateway: 192.168.200.7
   • Alamat IP tujuan: 192.168.1.4
   • header X-Forwarded-For: ClientPIP

3. Azure Firewall tidak menerapkan SNAT ke lalu lintas karena lalu lintas masuk ke alamat IP privat. Ini meneruskan lalu lintas ke VM aplikasi jika aturan mengizinkannya. Untuk informasi selengkapnya, lihat rentang alamat IP privat Azure Firewall SNAT. Namun, jika lalu lintas mencapai aturan aplikasi di firewall, beban kerja melihat alamat IP sumber dari instans firewall tertentu yang memproses paket karena Azure Firewall menproksi koneksi.

   • Alamat IP sumber jika lalu lintas diizinkan oleh aturan jaringan Azure Firewall dan merupakan alamat IP privat dari salah satu instans Application Gateway: 192.168.200.7
   • Alamat IP sumber jika lalu lintas diizinkan oleh aturan aplikasi Azure Firewall dan merupakan alamat IP privat dari salah satu instans Azure Firewall: 192.168.100.7
   • Alamat IP tujuan: 192.168.1.4
   • header X-Forwarded-For: ClientPIP

4. VM menjawab permintaan, yang membalikkan alamat IP sumber dan tujuan. UDR untuk 192.168.200.0/24 menangkap paket yang dikirim kembali ke Application Gateway, mengalihkannya ke Azure Firewall, dan mempertahankan alamat IP tujuan menuju Application Gateway.

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.200.7

5. Sekali lagi, Azure Firewall tidak menerapkan SNAT ke lalu lintas karena masuk ke alamat IP privat dan meneruskan lalu lintas ke Application Gateway.

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.200.7

6. Instans Application Gateway menjawab klien.

   • Alamat IP sumber: AppGwPIP
   • Alamat IP tujuan: ClientPIP

Alur keluar dari VM ke internet publik melalui Azure Firewall, yang didefinisikan UDR ke 0.0.0.0/0.

Sebagai variasi desain ini, Anda dapat mengonfigurasi DNAT privat di Azure Firewall sehingga beban kerja aplikasi melihat alamat IP instans Azure Firewall sebagai sumbernya, dan tidak diperlukan UDR. Alamat IP sumber klien aplikasi sudah dipertahankan di header HTTP X-Forwarded-For oleh Application Gateway. Jadi jika Azure Firewall menerapkan DNAT ke lalu lintas, tidak ada informasi yang hilang. Untuk informasi selengkapnya, lihat Memfilter lalu lintas internet masuk atau intranet dengan DNAT kebijakan Azure Firewall dengan menggunakan portal Microsoft Azure.

Azure Firewall di depan desain Application Gateway

Desain ini memungkinkan Azure Firewall memfilter dan membuang lalu lintas berbahaya sebelum mencapai Application Gateway. Misalnya, ini dapat menerapkan fitur seperti pemfilteran berbasis inteligensi ancaman. Manfaat lain adalah bahwa aplikasi mendapatkan alamat IP publik yang sama untuk lalu lintas masuk dan keluar, terlepas dari protokol. Ada tiga mode di mana Anda dapat mengonfigurasi Azure Firewall secara teoritis:

• Azure Firewall dengan aturan DNAT: Azure Firewall hanya menukar alamat IP di lapisan alamat IP, tetapi tidak memproses payload. Akibatnya, itu tidak mengubah header HTTP apa pun.

• Azure Firewall dengan aturan aplikasi dan inspeksi TLS dinonaktifkan: Azure Firewall dapat melihat header SNI di TLS, tetapi tidak mendekripsinya. Koneksi TCP baru dibuat dari firewall ke hop berikutnya. Dalam contoh ini, ini adalah Application Gateway.

• Azure Firewall dengan aturan aplikasi dan inspeksi TLS diaktifkan: Azure Firewall melihat konten paket dan mendekripsinya. Ini berfungsi sebagai proksi HTTP dan dapat mengatur header HTTP X-Forwarded-For untuk mempertahankan alamat IP. Namun, ini menyajikan sertifikat yang dibuat sendiri kepada klien. Untuk aplikasi berbasis internet, menggunakan sertifikat yang dibuat sendiri bukanlah opsi karena peringatan keamanan dikirim ke klien aplikasi dari browser mereka.

Dalam dua opsi pertama, yang merupakan satu-satunya opsi yang valid untuk aplikasi berbasis internet, Azure Firewall menerapkan SNAT ke lalu lintas masuk tanpa mengatur header X-Forwarded-For. Akibatnya, aplikasi tidak dapat melihat alamat IP asli permintaan HTTP. Untuk tugas administratif, seperti pemecahan masalah, Anda dapat memperoleh alamat IP klien aktual untuk koneksi tertentu dengan menghubungkannya dengan log SNAT Azure Firewall.

Manfaat skenario ini terbatas karena, kecuali Anda menggunakan inspeksi TLS dan menyajikan sertifikat yang dibuat sendiri kepada klien, Azure Firewall hanya melihat lalu lintas terenkripsi yang masuk ke Application Gateway. Skenario ini biasanya hanya dimungkinkan untuk aplikasi internal. Namun, mungkin ada skenario di mana desain ini lebih disukai. Salah satu skenarionya adalah jika Web Application Firewall lain ada sebelumnya di jaringan (misalnya, dengan Azure Front Door), yang dapat menangkap IP sumber asli di header HTTP X-Forwarded-For. Anda mungkin juga lebih suka desain ini jika banyak alamat IP publik yang diperlukan karena Application Gateway mendukung satu alamat IP.

Alur masuk HTTP dari internet publik harus menargetkan alamat IP publik Azure Firewall. Azure Firewall akan DNAT dan SNAT paket ke alamat IP privat Application Gateway. Dari jaringan virtual Azure lainnya atau jaringan lokal, lalu lintas HTTP harus dikirim ke alamat IP privat Application Gateway dan diteruskan melalui Azure Firewall dengan UDR. Perutean jaringan virtual standar memastikan bahwa lalu lintas kembali dari Azure VM kembali ke Application Gateway dan dari Application Gateway ke Azure Firewall jika aturan DNAT digunakan. Untuk lalu lintas dari lokal atau Azure, gunakan UDR di subnet Application Gateway. Untuk informasi selengkapnya, lihat panduan paket nanti di artikel ini. Semua lalu lintas keluar dari Azure VM ke internet dikirim melalui Azure Firewall oleh UDR.

Tabel berikut ini meringkas arus lalu lintas untuk skenario ini.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Ya	Ya
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak	Ya
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak	Ya
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak	Ya

Untuk lalu lintas HTTP masuk, Azure Firewall biasanya tidak mendekripsi lalu lintas. Sebagai gantinya, ini menerapkan kebijakan IDPS yang tidak memerlukan inspeksi TLS, seperti pemfilteran berbasis alamat IP atau menggunakan header HTTP.

Arsitektur

Aplikasi tidak dapat melihat alamat IP sumber asli lalu lintas web. Azure Firewall menerapkan SNAT ke paket saat masuk ke jaringan virtual. Untuk menghindari masalah ini, gunakan Azure Front Door di depan firewall. Azure Front Door menyuntikkan alamat IP klien sebagai header HTTP sebelum memasuki jaringan virtual Azure.

diagram

Alur kerja

Lalu lintas jaringan dari internet publik mengikuti alur ini:

1. Klien memulai koneksi ke alamat IP publik Azure Firewall.

   • Alamat IP sumber: ClientPIP
   • Alamat IP tujuan: AzFWPIP

2. Permintaan ke alamat IP publik Azure Firewall didistribusikan ke instans back-end firewall, yang 192.168.100.7 dalam contoh ini. Azure Firewall menerapkan DNAT ke port web, biasanya TCP 443, ke alamat IP privat instans Application Gateway. Azure Firewall juga menerapkan SNAT saat Anda melakukan DNAT. Untuk informasi selengkapnya, lihat masalah umum Azure Firewall.

   • Alamat IP sumber, yang merupakan alamat IP privat instans Azure Firewall: 192.168.100.7
   • Alamat IP tujuan: 192.168.200.4

3. Application Gateway membuat sesi baru antara instans yang menangani koneksi dan salah satu server back-end. Alamat IP asli klien tidak ada dalam paket.

   • Alamat IP sumber, yang merupakan alamat IP privat instans Application Gateway: 192.168.200.7
   • Alamat IP tujuan: 192.168.1.4
   • header X-Forwarded-For: 192.168.100.7

4. VM menjawab Application Gateway, yang membalikkan alamat IP sumber dan tujuan:

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.200.7

5. Application Gateway membalas alamat IP sumber SNAT instans Azure Firewall. Azure Firewall melihat alamat IP internal Application Gateway, .4, sebagai alamat IP sumber, bahkan jika koneksi berasal dari instans Application Gateway tertentu seperti .7.

   • Alamat IP sumber: 192.168.200.4
   • Alamat IP tujuan: 192.168.100.7

6. Azure Firewall membatalkan SNAT dan DNAT dan menjawab klien.

   • Alamat IP sumber: AzFwPIP
   • Alamat IP tujuan: ClientPIP

Application Gateway memerlukan alamat IP publik sehingga Microsoft dapat mengelolanya, meskipun tidak memiliki listener yang dikonfigurasi untuk aplikasi.

Nota

Rute default untuk 0.0.0.0/0 di subnet Application Gateway yang menunjuk ke Azure Firewall tidak didukung karena merusak lalu lintas sarana kontrol yang diperlukan Application Gateway untuk berfungsi dengan baik.

Klien lokal

Desain sebelumnya semuanya menunjukkan klien aplikasi masuk dari internet publik. Jaringan lokal juga mengakses aplikasi. Sebagian besar informasi sebelumnya dan arus lalu lintas sama dengan untuk klien internet, tetapi ada beberapa perbedaan penting:

• Gateway VPN atau gateway ExpressRoute berada di depan Azure Firewall atau Application Gateway.

• Web Application Firewall menggunakan alamat IP privat Application Gateway.

• Azure Firewall tidak mendukung DNAT untuk alamat IP privat, jadi Anda harus menggunakan UDR untuk mengirim lalu lintas masuk ke Azure Firewall dari gateway VPN atau ExpressRoute.

• Pastikan untuk memverifikasi peringatan di sekitar penerowongan paksa untuk Application Gateway dan untuk Azure Firewall. Bahkan jika beban kerja Anda tidak memerlukan konektivitas keluar ke internet publik, Anda tidak dapat menyuntikkan rute default seperti 0.0.0.0/0 untuk Application Gateway yang menunjuk ke jaringan lokal karena melanggar lalu lintas kontrol. Untuk Application Gateway, rute default perlu menunjuk ke internet publik.

Arsitektur

Diagram berikut menunjukkan desain paralel Application Gateway dan Azure Firewall. Klien aplikasi berasal dari jaringan lokal yang terhubung ke Azure melalui VPN atau ExpressRoute:

Bahkan jika semua klien terletak di lokal atau di Azure, Application Gateway dan Azure Firewall keduanya harus memiliki alamat IP publik. Alamat IP publik ini memungkinkan Microsoft mengelola layanan.

Topologi hub-and-spoke

Desain dalam artikel ini berlaku untuk topologi hub-and-spoke. Sumber daya bersama di jaringan virtual hub pusat terhubung ke aplikasi di jaringan virtual spoke terpisah melalui peering jaringan virtual.

Arsitektur

• Azure Firewall disebarkan di jaringan virtual hub pusat. Diagram sebelumnya memperlihatkan cara menyebarkan Application Gateway di hub. Tim aplikasi sering mengelola komponen seperti Application Gateway atau gateway API Management. Dalam skenario ini, komponen-komponen ini disebarkan di jaringan virtual spoke.

• Beri perhatian khusus pada UDR di jaringan spoke. Saat server aplikasi dalam spoke menerima lalu lintas dari instans Azure Firewall tertentu, seperti alamat IP 192.168.100.7 dalam contoh sebelumnya, server tersebut harus mengirim lalu lintas kembali ke instans yang sama. Jika UDR dalam spoke mengatur hop lalu lintas berikutnya yang ditujukan ke hub ke alamat IP Azure Firewall (192.168.100.4 dalam diagram sebelumnya), paket pengembalian mungkin berakhir pada instans Azure Firewall yang berbeda. Situasi ini menyebabkan perutean asimetris. Jika Anda memiliki UDR di jaringan virtual spoke, pastikan untuk mengirim lalu lintas ke layanan bersama di hub melalui Azure Firewall. UDR ini tidak menyertakan awalan subnet Azure Firewall.

• Rekomendasi sebelumnya berlaku sama untuk subnet Application Gateway dan NVA atau proksi terbalik lainnya yang mungkin disebarkan di jaringan virtual hub.

• Anda tidak dapat mengatur hop berikutnya untuk subnet Application Gateway atau Azure Firewall melalui rute statis dengan jenis hop berikutnya Virtual Network. Jenis hop berikutnya ini hanya valid di jaringan virtual lokal dan tidak di seluruh peering jaringan virtual. Untuk informasi selengkapnya tentang UDR dan jenis hop berikutnya, lihat perutean lalu lintas jaringan virtual .

Perutean asimetris

Diagram berikut menunjukkan bagaimana spoke mengirim lalu lintas SNAT kembali ke penyeimbang muatan Azure Azure Firewall. Penyiapan ini menyebabkan perutean asimetris.

Untuk mengatasi masalah ini, tentukan UDR di spoke tanpa subnet Azure Firewall dan hanya dengan subnet tempat layanan bersama berada. Dalam diagram sebelumnya, UDR yang benar dalam spoke hanya boleh berisi 192.168.1.0/24. Ini tidak boleh berisi seluruh rentang 192.168.0.0/16, yang ditandai dengan warna merah.

Integrasi dengan produk Azure lainnya

Anda dapat mengintegrasikan Azure Firewall dan Application Gateway dengan produk dan layanan Azure lainnya.

Gerbang Manajemen API

Integrasikan layanan proksi terbalik seperti API Management gateway ke dalam desain sebelumnya untuk menyediakan fungsionalitas seperti pembatasan API atau proksi autentikasi. Integrasi gateway API Management tidak secara signifikan memengaruhi desain. Perbedaan utamanya adalah bahwa alih-alih proksi terbalik Application Gateway tunggal, ada dua proksi terbalik yang ditautkan di belakang satu sama lain.

Untuk informasi selengkapnya, lihat panduan desain untuk mengintegrasikan API Management dan Application Gateway dalam jaringan virtual dan pola aplikasi gateway API untuk layanan mikro.

Azure Kubernetes Service (AKS)

Untuk beban kerja yang berjalan pada kluster AKS, Anda dapat menyebarkan Application Gateway secara independen dari kluster. Atau Anda dapat mengintegrasikannya dengan kluster AKS dengan menggunakan Application Gateway Ingress Controller. Saat Anda mengonfigurasi objek tertentu di tingkat Kubernetes, seperti layanan dan ingress, Application Gateway secara otomatis beradaptasi tanpa memerlukan langkah manual tambahan.

Azure Firewall memainkan peran penting dalam keamanan kluster AKS. Ini menyediakan fungsionalitas yang diperlukan untuk memfilter lalu lintas keluar dari kluster AKS berdasarkan FQDN, tidak hanya alamat IP. Untuk informasi selengkapnya, lihat Membatasi lalu lintas jaringan dengan Azure Firewall di AKS.

Saat Anda menggabungkan Application Gateway dan Azure Firewall untuk melindungi kluster AKS, yang terbaik adalah menggunakan opsi desain paralel. Application Gateway dengan Web Application Firewall memproses permintaan koneksi masuk ke aplikasi web di kluster. Azure Firewall hanya mengizinkan koneksi keluar yang diizinkan secara eksplisit. Untuk informasi selengkapnya tentang opsi desain paralel, lihat arsitektur Garis Besar untuk kluster AKS.

Azure Front Door (layanan pengiriman konten dari Microsoft)

Azure Front Door memiliki fungsionalitas yang tumpang tindih dengan Application Gateway di beberapa area. Kedua layanan menyediakan firewall aplikasi web, offloading SSL, dan perutean berbasis URL. Namun, perbedaan utamanya adalah bahwa sementara Application Gateway beroperasi dalam jaringan virtual, Azure Front Door adalah layanan global yang terdesentralisasi.

Anda terkadang dapat menyederhanakan desain jaringan virtual dengan mengganti Application Gateway dengan Azure Front Door terdesentralisasi. Sebagian besar desain yang dijelaskan dalam artikel ini masih berlaku, kecuali opsi untuk menempatkan Azure Firewall di depan Azure Front Door.

Salah satu skenarionya adalah menggunakan Azure Firewall di depan Application Gateway di jaringan virtual Anda. Application Gateway menyuntikkan header X-Forwarded-For dengan alamat IP instans firewall, bukan alamat IP klien. Solusinya adalah menggunakan Azure Front Door di depan firewall untuk menyuntikkan alamat IP klien sebagai header X-Forwarded-For sebelum lalu lintas memasuki jaringan virtual dan mencapai Azure Firewall. Anda juga dapat mengamankan asal Anda dengan Azure Private Link di Azure Front Door Premium.

Untuk informasi selengkapnya tentang perbedaan antara kedua layanan, atau kapan menggunakan masing-masing layanan, lihat Tanya jawab umum untuk Azure Front Door.

NVA lainnya

Produk Microsoft bukan satu-satunya pilihan untuk menerapkan firewall aplikasi web atau fungsionalitas firewall generasi berikutnya di Azure. Berbagai mitra Microsoft menyediakan NVA. Konsep dan desain pada dasarnya sama seperti dalam artikel ini, tetapi ada beberapa pertimbangan penting:

• NVA mitra untuk firewall generasi berikutnya mungkin memberikan lebih banyak kontrol dan fleksibilitas untuk konfigurasi NAT yang tidak didukung Azure Firewall. Contohnya termasuk DNAT dari lokal atau DNAT dari internet tanpa SNAT.

• NVA yang dikelola Azure seperti Application Gateway dan Azure Firewall mengurangi kompleksitas, dibandingkan dengan NVA di mana pengguna perlu menangani skalabilitas dan ketahanan di banyak appliance.

• Saat Anda menggunakan NVA di Azure, gunakan aktif-aktif dan pengaturan penskalaan otomatis sehingga appliance ini bukan hambatan untuk aplikasi yang berjalan di jaringan virtual.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

• Jose Moreno | Insinyur Pelanggan Utama

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya

Pelajari selengkapnya tentang teknologi komponen:

• Apa itu Application Gateway?
• Apa itu Azure Firewall?
• Apa itu Azure Front Door?
• AKS
• Apa itu Virtual Network?
• Apa itu Web Application Firewall?
• Arsitektur garis besar untuk kluster AKS

Sumber daya terkait

Jelajahi arsitektur terkait:

• Menerapkan jaringan hibrid yang aman
• aplikasi web yang dikelola dengan aman
• perangkat lunak multipenyewa sebagai layanan di Azure
• penyebaran Enterprise dengan menggunakan Lingkungan App Service
• Penyebaran perusahaan ketersediaan tinggi dengan menggunakan Lingkungan App Service

Untuk membantu mengamankan beban kerja aplikasi Azure, gunakan langkah-langkah perlindungan seperti autentikasi dan enkripsi dalam aplikasi itu sendiri. Anda dapat menambahkan lapisan keamanan ke jaringan virtual yang menghosting aplikasi. Lapisan keamanan ini membantu melindungi alur masuk aplikasi dari penggunaan yang tidak diinginkan. Mereka juga membatasi alur keluar ke internet hanya untuk titik akhir yang diperlukan aplikasi Anda. Artikel ini menjelaskan azure Virtual Network layanan keamanan seperti Azure DDoS Protection, Azure Firewall, dan Azure Application Gateway. Ini juga menjelaskan kapan harus menggunakan setiap layanan dan opsi desain jaringan yang menggabungkannya.

• DDoS Protection, dikombinasikan dengan praktik terbaik desain aplikasi, menyediakan fitur mitigasi DDoS yang ditingkatkan yang meningkatkan pertahanan terhadap serangan DDoS. Anda harus mengaktifkan DDoS Protection di setiap jaringan virtual perimeter.

• Azure Firewall adalah firewall terkelola generasi berikutnya yang menyediakan kemampuan terjemahan alamat jaringan (NAT). Azure Firewall memfilter paket berdasarkan alamat IP dan port Protokol Kontrol Transmisi (TCP) atau Protokol Datagram Pengguna (UDP). Ini dapat memfilter lalu lintas dengan menggunakan atribut berbasis aplikasi, seperti HTTP(S) dan SQL. Azure Firewall juga menerapkan inteligensi ancaman Microsoft untuk membantu mengidentifikasi alamat IP berbahaya. Untuk informasi selengkapnya, lihat dokumentasi Azure Firewall.

• Azure Firewall Premium mencakup semua fungsionalitas Azure Firewall Standard, selain fitur seperti inspeksi keamanan lapisan transportasi (TLS) dan sistem deteksi dan pencegahan intrusi (IDPS).

• Application Gateway adalah load balancer lalu lintas web terkelola dan proksi terbalik penuh HTTP(S) yang dapat melakukan enkripsi dan dekripsi Secure Socket Layer (SSL). Application Gateway mempertahankan alamat IP klien asli di header HTTP X-Forwarded-For. Application Gateway juga menggunakan Azure Web Application Firewall untuk memeriksa lalu lintas web dan mendeteksi serangan di lapisan HTTP. Untuk informasi selengkapnya, lihat dokumentasi Application Gateway.

• Web Application Firewall adalah tambahan opsional untuk Application Gateway. Ini memeriksa permintaan HTTP dan mencegah serangan lapisan web, seperti injeksi SQL dan skrip lintas situs. Untuk informasi selengkapnya, lihat dokumentasi Web Application Firewall.

Layanan Azure ini saling melengkapi. Tergantung pada kebutuhan Anda, menggunakan satu layanan mungkin lebih sesuai dengan beban kerja Anda. Namun, Anda dapat menggunakan layanan ini bersama-sama untuk membantu memberikan perlindungan optimal di lapisan jaringan dan aplikasi. Gunakan pohon keputusan berikut dan contoh dalam artikel ini untuk memilih opsi keamanan terbaik untuk jaringan virtual aplikasi Anda.

Azure Firewall dan Application Gateway menggunakan teknologi yang berbeda untuk membantu mengamankan berbagai jenis aliran data.

Alur Aplikasi	Dapat difilter oleh Azure Firewall	Dapat difilter oleh Web Application Firewall di Application Gateway
Lalu lintas HTTP dari lokal atau internet ke Azure (masuk)	Ya	Ya
Lalu lintas HTTP dari Azure ke lokal atau internet (keluar)	Ya	Tidak
Lalu lintas non-HTTP (masuk atau keluar)	Ya	Tidak

Desain dapat bervariasi untuk setiap aplikasi berdasarkan alur jaringan yang diperlukan. Diagram berikut menyediakan pohon keputusan yang disederhanakan yang membantu Anda memilih pendekatan yang direkomendasikan untuk aplikasi Anda. Pilihan ini tergantung pada apakah aplikasi diterbitkan melalui HTTP(S) atau beberapa protokol lainnya.

Artikel ini menjelaskan desain yang direkomendasikan secara luas yang ditunjukkan dalam bagan alur dan desain yang cocok untuk skenario yang kurang umum:

• Azure Firewall hanya: Gunakan desain ini ketika tidak ada aplikasi web di jaringan virtual. Ini mengontrol lalu lintas masuk ke aplikasi dan lalu lintas keluar.

• Application Gateway hanya: Gunakan desain ini ketika hanya aplikasi web yang berada di jaringan virtual dan kelompok keamanan jaringan (NSG) menyediakan pemfilteran output yang memadai. Azure Firewall menyediakan fungsionalitas yang dapat membantu mencegah beberapa skenario serangan, seperti eksfiltrasi data dan IDPS. Akibatnya, desain khusus Application Gateway biasanya tidak direkomendasikan, sehingga tidak disertakan dalam bagan alur sebelumnya.

• Azure Firewall dan Application Gateway secara paralel: Gunakan desain ini saat Anda ingin Application Gateway melindungi aplikasi HTTP dari serangan web dan Azure Firewall untuk melindungi semua beban kerja lainnya dan memfilter lalu lintas keluar. Azure Firewall dan Application Gateway secara paralel adalah desain umum.

• Application Gateway di depan Azure Firewall: Gunakan desain ini saat Anda ingin Azure Firewall memeriksa semua lalu lintas, Web Application Firewall untuk melindungi lalu lintas web, dan aplikasi untuk mengidentifikasi alamat IP sumber klien. Dengan inspeksi Azure Firewall Premium dan TLS, desain ini juga mendukung skenario SSL end-to-end.

• Azure Firewall di depan Application Gateway: Gunakan desain ini saat Anda ingin Azure Firewall memeriksa dan memfilter lalu lintas sebelum mencapai Application Gateway. Karena Azure Firewall tidak mendekripsi lalu lintas HTTPS, fungsionalitas yang ditambahkan ke Application Gateway terbatas. Skenario ini tidak didokumenkan di bagan alur sebelumnya.

Variasi desain mendasar ini dijelaskan nanti dalam artikel ini dan meliputi:

• Klien aplikasi lokal.
• jaringan Hub-and-spoke.
• implementasi Azure Kubernetes Service (AKS).

Anda dapat menambahkan layanan proksi terbalik lainnya, seperti gateway Azure API Management atau Azure Front Door. Atau Anda dapat mengganti sumber daya Azure dengan appliance virtual jaringan (NVA) non-Microsoft .

Nota

Dalam skenario berikut, komputer virtual (VM) Azure digunakan sebagai contoh beban kerja aplikasi web. Skenario ini juga valid untuk jenis beban kerja lainnya, seperti kontainer atau Azure Web Apps. Untuk penyiapan yang menyertakan titik akhir privat, pertimbangkan rekomendasi dalam skenario Azure Firewall untuk memeriksa lalu lintas yang ditujukan ke titik akhir privat.

Desain khusus Azure Firewall

Jika tidak ada beban kerja berbasis web di jaringan virtual yang dapat memperoleh manfaat dari Web Application Firewall, Anda dapat menggunakan desain khusus Azure Firewall. Desain dalam contoh ini sederhana, tetapi Anda dapat meninjau alur paket untuk lebih memahami desain yang lebih kompleks. Dalam desain ini, semua lalu lintas masuk dikirim ke Azure Firewall melalui rute yang ditentukan pengguna (UDR) untuk koneksi dari lokal atau jaringan virtual Azure lainnya. Ini ditujukan ke alamat IP publik Azure Firewall untuk koneksi dari internet publik, seperti yang ditunjukkan dalam diagram berikut. UDR mengarahkan lalu lintas keluar dari jaringan virtual Azure ke Azure Firewall, seperti yang ditunjukkan dalam dialog berikut.

Tabel berikut ini meringkas arus lalu lintas untuk skenario ini.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Tidak tersedia	Ya
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak tersedia	Ya
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak tersedia	Ya
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak tersedia	Ya

Azure Firewall tidak memeriksa lalu lintas HTTP masuk. Tetapi dapat menerapkan aturan lapisan 3 dan lapisan 4 dan aturan aplikasi berbasis nama domain yang sepenuhnya memenuhi syarat (FQDN). Azure Firewall memeriksa lalu lintas HTTP keluar, tergantung pada tingkat Azure Firewall dan apakah Anda mengonfigurasi inspeksi TLS:

• Azure Firewall Standard hanya memeriksa atribut paket lapisan 3 dan lapisan 4 dalam aturan jaringan dan header HTTP Host dalam aturan aplikasi.

• Azure Firewall Premium menambahkan kemampuan, seperti memeriksa header HTTP lainnya (seperti agen pengguna) dan mengaktifkan inspeksi TLS untuk analisis paket yang lebih dalam. Namun, Azure Firewall tidak sama dengan Web Application Firewall. Jika Anda memiliki beban kerja web di jaringan virtual Anda, kami sarankan Anda menggunakan Web Application Firewall.

Contoh panduan paket berikut menunjukkan bagaimana klien mengakses aplikasi yang dihosting VM dari internet publik. Diagram hanya mencakup satu VM untuk kesederhanaan. Untuk ketersediaan dan skalabilitas yang lebih tinggi, ada beberapa instans aplikasi di belakang load balancer. Dalam desain ini, Azure Firewall memeriksa koneksi masuk dari internet publik dan koneksi keluar dari VM subnet aplikasi dengan menggunakan UDR.

• Dalam contoh ini, Azure Firewall secara otomatis menyebarkan beberapa instans dengan alamat IP front-end 192.168.100.4 dan alamat internal dalam rentang 192.168.100.0/26. Biasanya, instans ini tidak terlihat oleh administrator Azure. Namun, menyadarinya dapat membantu untuk memecahkan masalah jaringan.

• Jika lalu lintas berasal dari jaringan privat virtual (VPN) lokal atau gateway Azure ExpressRoute alih-alih internet, klien memulai koneksi ke alamat IP VM. Ini tidak memulai koneksi ke alamat IP firewall, dan firewall tidak melakukan NAT sumber secara default.

Arsitektur

Diagram berikut menunjukkan arus lalu lintas dan mengasumsikan bahwa alamat IP instans 192.168.100.7.

diagram

Alur kerja

1. Klien memulai koneksi ke alamat IP publik Azure Firewall.

   • Alamat IP sumber: ClientPIP
   • Alamat IP tujuan: AzFwPIP

2. Permintaan ke alamat IP publik Azure Firewall didistribusikan ke instans back-end firewall, yang 192.168.100.7 dalam contoh ini. Aturan Azure Firewall Destination Network Address Translation (DNAT) menerjemahkan alamat IP tujuan ke alamat IP aplikasi di dalam jaringan virtual. Azure Firewall juga menerapkan terjemahan alamat jaringan sumber (SNAT) pada paket jika menggunakan DNAT. Untuk informasi selengkapnya, lihat masalah umum Azure Firewall. VM melihat alamat IP berikut dalam paket masuk:

   • Alamat IP sumber: 192.168.100.7
   • Alamat IP tujuan: 192.168.1.4

3. VM menjawab permintaan aplikasi, yang membalikkan alamat IP sumber dan tujuan. Alur masuk tidak memerlukan UDR karena IP sumber adalah alamat IP Azure Firewall. UDR dalam diagram untuk 0.0.0.0/0 adalah untuk koneksi keluar untuk memastikan bahwa paket ke internet publik melalui Azure Firewall.

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.100.7

4. Azure Firewall membatalkan operasi SNAT dan DNAT dan memberikan respons kepada klien.

   • Alamat IP sumber: AzFwPIP
   • Alamat IP tujuan: ClientPIP

Desain khusus Application Gateway

Desain ini menjelaskan skenario di mana hanya aplikasi web yang ada di jaringan virtual, dan memeriksa lalu lintas keluar dengan NSG cukup untuk melindungi alur keluar ke internet.

Nota

Kami tidak merekomendasikan desain ini karena menggunakan Azure Firewall untuk mengontrol alur keluar, alih-alih hanya mengandalkan NSG, membantu mencegah skenario serangan seperti penyelundupan data. Dengan Azure Firewall, Anda dapat membantu memastikan bahwa beban kerja Anda hanya mengirim data ke daftar URL yang disetujui. Selain itu, NSG hanya beroperasi pada lapisan 3 dan lapisan 4 dan tidak mendukung FQDN.

Perbedaan utama dari desain khusus Azure Firewall sebelumnya adalah bahwa Application Gateway tidak berfungsi sebagai perangkat perutean dengan NAT. Sebaliknya, ini berfungsi sebagai proksi aplikasi terbalik penuh. Pendekatan ini berarti bahwa Application Gateway menghentikan sesi web dari klien dan membuat sesi terpisah dengan salah satu server back-end-nya. Koneksi HTTP masuk dari internet dikirim ke alamat IP publik Application Gateway, dan koneksi dari Azure atau lokal menggunakan alamat IP privat gateway. Mengembalikan lalu lintas dari Azure VM mengikuti perutean jaringan virtual standar kembali ke Application Gateway. Untuk informasi selengkapnya, lihat panduan paket nanti di artikel ini. Aliran internet keluar dari Azure VM langsung masuk ke internet.

Tabel berikut ini meringkas arus lalu lintas.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Ya	Tidak tersedia
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak	Tidak tersedia
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak	Tidak tersedia
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak	Tidak tersedia

Arsitektur

Contoh panduan paket berikut menunjukkan bagaimana klien mengakses aplikasi yang dihosting VM dari internet publik.

Alur kerja

1. Klien memulai koneksi ke alamat IP publik Application Gateway.

   • Alamat IP sumber: ClientPIP
   • Alamat IP tujuan: AppGwPIP

2. Permintaan ke alamat IP publik Application Gateway didistribusikan ke instans back-end gateway, yang 192.168.200.7 dalam contoh ini. Instans Application Gateway yang menerima permintaan menghentikan koneksi dari klien dan membuat koneksi baru dengan salah satu ujung belakang. Back end melihat instans Application Gateway sebagai alamat IP sumber. Application Gateway menyisipkan header HTTP X-Forwarded-For dengan alamat IP klien asli.

   • Alamat IP sumber, yang merupakan alamat IP privat instans Application Gateway: 192.168.200.7
   • Alamat IP tujuan: 192.168.1.4
   • header X-Forwarded-For: ClientPIP

3. VM menjawab permintaan aplikasi dan membalikkan alamat IP sumber dan tujuan. VM dapat mencapai Application Gateway, sehingga tidak memerlukan UDR.

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.200.7

4. Instans Application Gateway menjawab klien.

   • Alamat IP sumber: AppGwPIP
   • Alamat IP tujuan: ClientPIP

Application Gateway menambahkan metadata ke header HTTP paket, seperti header X-Forwarded-For yang berisi alamat IP klien asli. Beberapa server aplikasi memerlukan alamat IP klien sumber untuk melayani konten khusus geolokasi, atau untuk pengelogan. Untuk informasi selengkapnya, lihat Cara kerja gateway aplikasi.

• Dalam contoh ini, alamat IP 192.168.200.7 adalah salah satu instans yang disebarkan oleh layanan Application Gateway secara otomatis. Ini memiliki alamat IP front-end internal dan privat 192.168.200.4. Instans individual ini biasanya tidak terlihat oleh administrator Azure. Tetapi perhatikan perbedaannya dapat berguna, seperti ketika Anda memecahkan masalah jaringan.

• Alurnya mirip jika klien berasal dari jaringan lokal melalui vpn atau gateway ExpressRoute. Perbedaannya adalah klien mengakses alamat IP privat Application Gateway alih-alih alamat IP publik.

Nota

Untuk informasi selengkapnya tentang header X-Forwarded-For dan cara mempertahankan nama host berdasarkan permintaan, lihat Mempertahankan host HTTP asli.

Azure Firewall dan Application Gateway dalam desain paralel

Karena kesederhanaan dan fleksibilitasnya, seringkali yang terbaik adalah menjalankan Application Gateway dan Azure Firewall secara paralel.

Terapkan desain ini jika ada beban kerja web dan non-web di jaringan virtual. Web Application Firewall di Application Gateway membantu melindungi lalu lintas masuk ke beban kerja web. Azure Firewall memeriksa lalu lintas masuk untuk aplikasi lain. Azure Firewall mencakup alur keluar dari kedua jenis beban kerja.

Koneksi HTTP masuk dari internet harus dikirim ke alamat IP publik Application Gateway. Koneksi HTTP dari Azure atau lokal harus dikirim ke alamat IP privatnya. Perutean jaringan virtual standar mengirimkan paket dari Application Gateway ke VM tujuan, dan dari VM tujuan kembali ke Application Gateway. Untuk informasi selengkapnya, lihat panduan paket nanti di artikel ini.

Untuk koneksi non-HTTP masuk, lalu lintas harus menargetkan alamat IP publik Azure Firewall jika berasal dari internet publik. Lalu lintas harus dikirim melalui Azure Firewall oleh UDR jika berasal dari jaringan virtual Azure lainnya atau jaringan lokal. Semua alur keluar dari Azure VM diteruskan ke Azure Firewall oleh UDR.

Tabel berikut ini meringkas arus lalu lintas untuk skenario ini.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Ya	Tidak
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak	Ya
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak	Ya
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak	Ya

Desain ini menyediakan pemfilteran keluar yang jauh lebih terperinci daripada hanya menggunakan NSG. Misalnya, jika aplikasi memerlukan konektivitas ke akun Azure Storage tertentu, Anda dapat menggunakan filter berbasis FQDN. Dengan filter berbasis FQDN, aplikasi tidak mengirim data ke akun penyimpanan nakal. Jika Anda hanya menggunakan NSG, Anda tidak dapat mencegah skenario ini. Desain ini sering digunakan ketika lalu lintas keluar memerlukan pemfilteran berbasis FQDN. Salah satu skenarionya adalah ketika Anda membatasi lalu lintas keluar dari kluster AKS.

Arsitektur

Diagram berikut mengilustrasikan arus lalu lintas untuk koneksi HTTP masuk dari klien luar.

Diagram berikut mengilustrasikan arus lalu lintas untuk koneksi keluar dari VM jaringan ke internet. Salah satu contohnya adalah menyambungkan ke sistem back-end atau mendapatkan pembaruan sistem operasi.

Langkah-langkah alur paket untuk setiap layanan sama seperti pada opsi desain mandiri sebelumnya.

Application Gateway di depan desain Azure Firewall

Desain ini dijelaskan secara lebih rinci di jaringan Zero-trust untuk aplikasi web dengan Azure Firewall dan Application Gateway. Artikel ini berfokus pada perbandingan dengan opsi desain lainnya. Dalam topologi ini, lalu lintas web masuk melewati Azure Firewall dan Web Application Firewall. Web Application Firewall memberikan perlindungan pada lapisan aplikasi web. Azure Firewall berfungsi sebagai pencatatan pusat dan titik kontrol, dan memeriksa lalu lintas antara Application Gateway dan server back-end. Dalam desain ini, Application Gateway dan Azure Firewall tidak duduk secara paralel tetapi duduk satu di depan yang lain.

Dengan Azure Firewall Premium, desain ini dapat mendukung skenario end-to-end, di mana Azure Firewall menerapkan inspeksi TLS untuk melakukan IDPS pada lalu lintas terenkripsi antara Application Gateway dan back end web.

Desain ini cocok untuk aplikasi yang perlu mengidentifikasi alamat IP sumber klien yang masuk. Misalnya, dapat digunakan untuk melayani konten khusus geolokasi atau untuk pengelogan. Application Gateway di depan desain Azure Firewall mengambil alamat IP sumber paket masuk di header X-Forwarded-For, sehingga server web dapat melihat alamat IP asli di header ini. Untuk informasi selengkapnya, lihat Cara kerja gateway aplikasi.

Koneksi HTTP masuk dari internet perlu dikirim ke alamat IP publik Application Gateway. Koneksi HTTP dari Azure atau lokal harus dikirim ke alamat IP privatnya. Dari Application Gateway, UDR memastikan bahwa paket dirutekan melalui Azure Firewall. Untuk informasi selengkapnya, lihat panduan paket nanti di artikel ini.

Untuk koneksi non-HTTP masuk, lalu lintas harus menargetkan alamat IP publik Azure Firewall jika berasal dari internet publik. Lalu lintas harus dikirim melalui Azure Firewall oleh UDR jika berasal dari jaringan virtual Azure lainnya atau jaringan lokal. Semua alur keluar dari Azure VM diteruskan ke Azure Firewall oleh UDR.

Aspek penting dari desain ini adalah Azure Firewall Premium melihat lalu lintas dengan alamat IP sumber dari subnet Application Gateway. Jika subnet ini dikonfigurasi dengan alamat IP privat (dalam 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, atau 100.64.0.0/10), Azure Firewall Premium memperlakukan lalu lintas dari Application Gateway sebagai internal dan tidak menerapkan aturan IDPS untuk lalu lintas masuk. Akibatnya, kami sarankan Anda memodifikasi awalan privat IDPS dalam kebijakan Azure Firewall. Modifikasi ini memastikan bahwa subnet Application Gateway tidak dianggap sebagai sumber internal, yang memungkinkan tanda tangan IDPS masuk dan keluar diterapkan ke lalu lintas. Anda dapat menemukan informasi selengkapnya tentang arah aturan IDPS Azure Firewall dan awalan IP privat untuk IDPS di aturan IDPS Azure Firewall.

Tabel berikut ini meringkas arus lalu lintas untuk skenario ini.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Ya	Ya
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak	Ya
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak	Ya
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak	Ya

Untuk lalu lintas web dari lokal atau dari internet ke Azure, Azure Firewall memeriksa alur yang diizinkan Web Application Firewall. Bergantung pada apakah Application Gateway mengenkripsi lalu lintas back-end, yang merupakan lalu lintas dari Application Gateway ke server aplikasi, skenario yang berbeda dapat terjadi:

• Application Gateway mengenkripsi lalu lintas dengan mengikuti prinsip zero-trust seperti enkripsi TLS end-to-end, dan Azure Firewall menerima lalu lintas terenkripsi. Azure Firewall Standard masih dapat menerapkan aturan inspeksi, seperti pemfilteran lapisan 3 dan lapisan 4 dalam aturan jaringan, atau pemfilteran FQDN dalam aturan aplikasi, dengan menggunakan header Indikasi Nama Server TLS (SNI). Azure Firewall Premium memberikan visibilitas yang lebih dalam dengan inspeksi TLS, seperti pemfilteran berbasis URL.

• Jika Application Gateway mengirim lalu lintas yang tidak terenkripsi ke server aplikasi, Azure Firewall akan melihat lalu lintas masuk dalam teks yang jelas. Inspeksi TLS tidak diperlukan di Azure Firewall.

• Jika IDPS diaktifkan di Azure Firewall, idPS memverifikasi bahwa header Host HTTP cocok dengan alamat IP tujuan. Untuk melakukan verifikasi ini, diperlukan resolusi nama untuk FQDN yang ditentukan di header Host. Resolusi nama ini dapat dilakukan dengan menggunakan zona privat Azure DNS dan pengaturan DNS Azure Firewall default. Ini juga dapat dicapai dengan server DNS kustom yang perlu dikonfigurasi di pengaturan Azure Firewall. Jika Anda tidak memiliki akses administratif ke jaringan virtual tempat Azure Firewall disebarkan, metode terakhir adalah satu-satunya opsi Anda. Salah satu contohnya adalah dengan instans Azure Firewall yang disebarkan di hub aman Azure Virtual WAN.

Arsitektur

Untuk alur lainnya, yang mencakup lalu lintas non-HTTP masuk dan lalu lintas keluar apa pun, Azure Firewall menyediakan inspeksi IDPS dan inspeksi TLS jika cocok. Ini juga menyediakan pemfilteran berbasis FQDN dalam aturan jaringan berdasarkan DNS.

diagram

Alur kerja

Lalu lintas jaringan dari internet publik mengikuti alur ini:

1. Klien memulai koneksi ke alamat IP publik Application Gateway.

   • Alamat IP sumber: ClientPIP
   • Alamat IP tujuan: AppGwPIP

2. Permintaan ke alamat IP publik Application Gateway didistribusikan ke instans back-end gateway, yang 192.168.200.7 dalam contoh ini. Instans Application Gateway menghentikan koneksi dari klien dan membuat koneksi baru dengan salah satu ujung belakang. UDR untuk 192.168.1.0/24 di subnet Application Gateway meneruskan paket ke Azure Firewall dan mempertahankan alamat IP tujuan ke aplikasi web.

   • Alamat IP sumber, yang merupakan alamat IP privat instans Application Gateway: 192.168.200.7
   • Alamat IP tujuan: 192.168.1.4
   • header X-Forwarded-For: ClientPIP

3. Azure Firewall tidak menerapkan SNAT ke lalu lintas karena lalu lintas masuk ke alamat IP privat. Ini meneruskan lalu lintas ke VM aplikasi jika aturan mengizinkannya. Untuk informasi selengkapnya, lihat rentang alamat IP privat Azure Firewall SNAT. Namun, jika lalu lintas mencapai aturan aplikasi di firewall, beban kerja melihat alamat IP sumber dari instans firewall tertentu yang memproses paket karena Azure Firewall menproksi koneksi.

   • Alamat IP sumber jika lalu lintas diizinkan oleh aturan jaringan Azure Firewall dan merupakan alamat IP privat dari salah satu instans Application Gateway: 192.168.200.7
   • Alamat IP sumber jika lalu lintas diizinkan oleh aturan aplikasi Azure Firewall dan merupakan alamat IP privat dari salah satu instans Azure Firewall: 192.168.100.7
   • Alamat IP tujuan: 192.168.1.4
   • header X-Forwarded-For: ClientPIP

4. VM menjawab permintaan, yang membalikkan alamat IP sumber dan tujuan. UDR untuk 192.168.200.0/24 menangkap paket yang dikirim kembali ke Application Gateway, mengalihkannya ke Azure Firewall, dan mempertahankan alamat IP tujuan menuju Application Gateway.

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.200.7

5. Sekali lagi, Azure Firewall tidak menerapkan SNAT ke lalu lintas karena masuk ke alamat IP privat dan meneruskan lalu lintas ke Application Gateway.

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.200.7

6. Instans Application Gateway menjawab klien.

   • Alamat IP sumber: AppGwPIP
   • Alamat IP tujuan: ClientPIP

Alur keluar dari VM ke internet publik melalui Azure Firewall, yang didefinisikan UDR ke 0.0.0.0/0.

Sebagai variasi desain ini, Anda dapat mengonfigurasi DNAT privat di Azure Firewall sehingga beban kerja aplikasi melihat alamat IP instans Azure Firewall sebagai sumbernya, dan tidak diperlukan UDR. Alamat IP sumber klien aplikasi sudah dipertahankan di header HTTP X-Forwarded-For oleh Application Gateway. Jadi jika Azure Firewall menerapkan DNAT ke lalu lintas, tidak ada informasi yang hilang. Untuk informasi selengkapnya, lihat Memfilter lalu lintas internet masuk atau intranet dengan DNAT kebijakan Azure Firewall dengan menggunakan portal Microsoft Azure.

Azure Firewall di depan desain Application Gateway

Desain ini memungkinkan Azure Firewall memfilter dan membuang lalu lintas berbahaya sebelum mencapai Application Gateway. Misalnya, ini dapat menerapkan fitur seperti pemfilteran berbasis inteligensi ancaman. Manfaat lain adalah bahwa aplikasi mendapatkan alamat IP publik yang sama untuk lalu lintas masuk dan keluar, terlepas dari protokol. Ada tiga mode di mana Anda dapat mengonfigurasi Azure Firewall secara teoritis:

• Azure Firewall dengan aturan DNAT: Azure Firewall hanya menukar alamat IP di lapisan alamat IP, tetapi tidak memproses payload. Akibatnya, itu tidak mengubah header HTTP apa pun.

• Azure Firewall dengan aturan aplikasi dan inspeksi TLS dinonaktifkan: Azure Firewall dapat melihat header SNI di TLS, tetapi tidak mendekripsinya. Koneksi TCP baru dibuat dari firewall ke hop berikutnya. Dalam contoh ini, ini adalah Application Gateway.

• Azure Firewall dengan aturan aplikasi dan inspeksi TLS diaktifkan: Azure Firewall melihat konten paket dan mendekripsinya. Ini berfungsi sebagai proksi HTTP dan dapat mengatur header HTTP X-Forwarded-For untuk mempertahankan alamat IP. Namun, ini menyajikan sertifikat yang dibuat sendiri kepada klien. Untuk aplikasi berbasis internet, menggunakan sertifikat yang dibuat sendiri bukanlah opsi karena peringatan keamanan dikirim ke klien aplikasi dari browser mereka.

Dalam dua opsi pertama, yang merupakan satu-satunya opsi yang valid untuk aplikasi berbasis internet, Azure Firewall menerapkan SNAT ke lalu lintas masuk tanpa mengatur header X-Forwarded-For. Akibatnya, aplikasi tidak dapat melihat alamat IP asli permintaan HTTP. Untuk tugas administratif, seperti pemecahan masalah, Anda dapat memperoleh alamat IP klien aktual untuk koneksi tertentu dengan menghubungkannya dengan log SNAT Azure Firewall.

Manfaat skenario ini terbatas karena, kecuali Anda menggunakan inspeksi TLS dan menyajikan sertifikat yang dibuat sendiri kepada klien, Azure Firewall hanya melihat lalu lintas terenkripsi yang masuk ke Application Gateway. Skenario ini biasanya hanya dimungkinkan untuk aplikasi internal. Namun, mungkin ada skenario di mana desain ini lebih disukai. Salah satu skenarionya adalah jika Web Application Firewall lain ada sebelumnya di jaringan (misalnya, dengan Azure Front Door), yang dapat menangkap IP sumber asli di header HTTP X-Forwarded-For. Anda mungkin juga lebih suka desain ini jika banyak alamat IP publik yang diperlukan karena Application Gateway mendukung satu alamat IP.

Alur masuk HTTP dari internet publik harus menargetkan alamat IP publik Azure Firewall. Azure Firewall akan DNAT dan SNAT paket ke alamat IP privat Application Gateway. Dari jaringan virtual Azure lainnya atau jaringan lokal, lalu lintas HTTP harus dikirim ke alamat IP privat Application Gateway dan diteruskan melalui Azure Firewall dengan UDR. Perutean jaringan virtual standar memastikan bahwa lalu lintas kembali dari Azure VM kembali ke Application Gateway dan dari Application Gateway ke Azure Firewall jika aturan DNAT digunakan. Untuk lalu lintas dari lokal atau Azure, gunakan UDR di subnet Application Gateway. Untuk informasi selengkapnya, lihat panduan paket nanti di artikel ini. Semua lalu lintas keluar dari Azure VM ke internet dikirim melalui Azure Firewall oleh UDR.

Tabel berikut ini meringkas arus lalu lintas untuk skenario ini.

Mengalir	Melewati Application Gateway/Web Application Firewall	Melewati Azure Firewall
Lalu lintas HTTP dari internet atau lokal ke Azure	Ya	Ya
Lalu lintas HTTP dari Azure ke internet atau lokal	Tidak	Ya
Lalu lintas non-HTTP dari internet atau lokal ke Azure	Tidak	Ya
Lalu lintas non-HTTP dari Azure ke internet atau lokal	Tidak	Ya

Untuk lalu lintas HTTP masuk, Azure Firewall biasanya tidak mendekripsi lalu lintas. Sebagai gantinya, ini menerapkan kebijakan IDPS yang tidak memerlukan inspeksi TLS, seperti pemfilteran berbasis alamat IP atau menggunakan header HTTP.

Arsitektur

Aplikasi tidak dapat melihat alamat IP sumber asli lalu lintas web. Azure Firewall menerapkan SNAT ke paket saat masuk ke jaringan virtual. Untuk menghindari masalah ini, gunakan Azure Front Door di depan firewall. Azure Front Door menyuntikkan alamat IP klien sebagai header HTTP sebelum memasuki jaringan virtual Azure.

diagram

Alur kerja

Lalu lintas jaringan dari internet publik mengikuti alur ini:

1. Klien memulai koneksi ke alamat IP publik Azure Firewall.

   • Alamat IP sumber: ClientPIP
   • Alamat IP tujuan: AzFWPIP

2. Permintaan ke alamat IP publik Azure Firewall didistribusikan ke instans back-end firewall, yang 192.168.100.7 dalam contoh ini. Azure Firewall menerapkan DNAT ke port web, biasanya TCP 443, ke alamat IP privat instans Application Gateway. Azure Firewall juga menerapkan SNAT saat Anda melakukan DNAT. Untuk informasi selengkapnya, lihat masalah umum Azure Firewall.

   • Alamat IP sumber, yang merupakan alamat IP privat instans Azure Firewall: 192.168.100.7
   • Alamat IP tujuan: 192.168.200.4

3. Application Gateway membuat sesi baru antara instans yang menangani koneksi dan salah satu server back-end. Alamat IP asli klien tidak ada dalam paket.

   • Alamat IP sumber, yang merupakan alamat IP privat instans Application Gateway: 192.168.200.7
   • Alamat IP tujuan: 192.168.1.4
   • header X-Forwarded-For: 192.168.100.7

4. VM menjawab Application Gateway, yang membalikkan alamat IP sumber dan tujuan:

   • Alamat IP sumber: 192.168.1.4
   • Alamat IP tujuan: 192.168.200.7

5. Application Gateway membalas alamat IP sumber SNAT instans Azure Firewall. Azure Firewall melihat alamat IP internal Application Gateway, .4, sebagai alamat IP sumber, bahkan jika koneksi berasal dari instans Application Gateway tertentu seperti .7.

   • Alamat IP sumber: 192.168.200.4
   • Alamat IP tujuan: 192.168.100.7

6. Azure Firewall membatalkan SNAT dan DNAT dan menjawab klien.

   • Alamat IP sumber: AzFwPIP
   • Alamat IP tujuan: ClientPIP

Application Gateway memerlukan alamat IP publik sehingga Microsoft dapat mengelolanya, meskipun tidak memiliki listener yang dikonfigurasi untuk aplikasi.

Nota

Rute default untuk 0.0.0.0/0 di subnet Application Gateway yang menunjuk ke Azure Firewall tidak didukung karena merusak lalu lintas sarana kontrol yang diperlukan Application Gateway untuk berfungsi dengan baik.

Klien lokal

Desain sebelumnya semuanya menunjukkan klien aplikasi masuk dari internet publik. Jaringan lokal juga mengakses aplikasi. Sebagian besar informasi sebelumnya dan arus lalu lintas sama dengan untuk klien internet, tetapi ada beberapa perbedaan penting:

• Gateway VPN atau gateway ExpressRoute berada di depan Azure Firewall atau Application Gateway.

• Web Application Firewall menggunakan alamat IP privat Application Gateway.

• Azure Firewall tidak mendukung DNAT untuk alamat IP privat, jadi Anda harus menggunakan UDR untuk mengirim lalu lintas masuk ke Azure Firewall dari gateway VPN atau ExpressRoute.

• Pastikan untuk memverifikasi peringatan di sekitar penerowongan paksa untuk Application Gateway dan untuk Azure Firewall. Bahkan jika beban kerja Anda tidak memerlukan konektivitas keluar ke internet publik, Anda tidak dapat menyuntikkan rute default seperti 0.0.0.0/0 untuk Application Gateway yang menunjuk ke jaringan lokal karena melanggar lalu lintas kontrol. Untuk Application Gateway, rute default perlu menunjuk ke internet publik.

Arsitektur

Diagram berikut menunjukkan desain paralel Application Gateway dan Azure Firewall. Klien aplikasi berasal dari jaringan lokal yang terhubung ke Azure melalui VPN atau ExpressRoute:

Bahkan jika semua klien terletak di lokal atau di Azure, Application Gateway dan Azure Firewall keduanya harus memiliki alamat IP publik. Alamat IP publik ini memungkinkan Microsoft mengelola layanan.

Topologi hub-and-spoke

Desain dalam artikel ini berlaku untuk topologi hub-and-spoke. Sumber daya bersama di jaringan virtual hub pusat terhubung ke aplikasi di jaringan virtual spoke terpisah melalui peering jaringan virtual.

Arsitektur

• Azure Firewall disebarkan di jaringan virtual hub pusat. Diagram sebelumnya memperlihatkan cara menyebarkan Application Gateway di hub. Tim aplikasi sering mengelola komponen seperti Application Gateway atau gateway API Management. Dalam skenario ini, komponen-komponen ini disebarkan di jaringan virtual spoke.

• Beri perhatian khusus pada UDR di jaringan spoke. Saat server aplikasi dalam spoke menerima lalu lintas dari instans Azure Firewall tertentu, seperti alamat IP 192.168.100.7 dalam contoh sebelumnya, server tersebut harus mengirim lalu lintas kembali ke instans yang sama. Jika UDR dalam spoke mengatur hop lalu lintas berikutnya yang ditujukan ke hub ke alamat IP Azure Firewall (192.168.100.4 dalam diagram sebelumnya), paket pengembalian mungkin berakhir pada instans Azure Firewall yang berbeda. Situasi ini menyebabkan perutean asimetris. Jika Anda memiliki UDR di jaringan virtual spoke, pastikan untuk mengirim lalu lintas ke layanan bersama di hub melalui Azure Firewall. UDR ini tidak menyertakan awalan subnet Azure Firewall.

• Rekomendasi sebelumnya berlaku sama untuk subnet Application Gateway dan NVA atau proksi terbalik lainnya yang mungkin disebarkan di jaringan virtual hub.

• Anda tidak dapat mengatur hop berikutnya untuk subnet Application Gateway atau Azure Firewall melalui rute statis dengan jenis hop berikutnya Virtual Network. Jenis hop berikutnya ini hanya valid di jaringan virtual lokal dan tidak di seluruh peering jaringan virtual. Untuk informasi selengkapnya tentang UDR dan jenis hop berikutnya, lihat perutean lalu lintas jaringan virtual .

Perutean asimetris

Diagram berikut menunjukkan bagaimana spoke mengirim lalu lintas SNAT kembali ke penyeimbang muatan Azure Azure Firewall. Penyiapan ini menyebabkan perutean asimetris.

Untuk mengatasi masalah ini, tentukan UDR di spoke tanpa subnet Azure Firewall dan hanya dengan subnet tempat layanan bersama berada. Dalam diagram sebelumnya, UDR yang benar dalam spoke hanya boleh berisi 192.168.1.0/24. Ini tidak boleh berisi seluruh rentang 192.168.0.0/16, yang ditandai dengan warna merah.

Integrasi dengan produk Azure lainnya

Anda dapat mengintegrasikan Azure Firewall dan Application Gateway dengan produk dan layanan Azure lainnya.

Gerbang Manajemen API

Integrasikan layanan proksi terbalik seperti API Management gateway ke dalam desain sebelumnya untuk menyediakan fungsionalitas seperti pembatasan API atau proksi autentikasi. Integrasi gateway API Management tidak secara signifikan memengaruhi desain. Perbedaan utamanya adalah bahwa alih-alih proksi terbalik Application Gateway tunggal, ada dua proksi terbalik yang ditautkan di belakang satu sama lain.

Untuk informasi selengkapnya, lihat panduan desain untuk mengintegrasikan API Management dan Application Gateway dalam jaringan virtual dan pola aplikasi gateway API untuk layanan mikro.

Azure Kubernetes Service (AKS)

Untuk beban kerja yang berjalan pada kluster AKS, Anda dapat menyebarkan Application Gateway secara independen dari kluster. Atau Anda dapat mengintegrasikannya dengan kluster AKS dengan menggunakan Application Gateway Ingress Controller. Saat Anda mengonfigurasi objek tertentu di tingkat Kubernetes, seperti layanan dan ingress, Application Gateway secara otomatis beradaptasi tanpa memerlukan langkah manual tambahan.

Azure Firewall memainkan peran penting dalam keamanan kluster AKS. Ini menyediakan fungsionalitas yang diperlukan untuk memfilter lalu lintas keluar dari kluster AKS berdasarkan FQDN, tidak hanya alamat IP. Untuk informasi selengkapnya, lihat Membatasi lalu lintas jaringan dengan Azure Firewall di AKS.

Saat Anda menggabungkan Application Gateway dan Azure Firewall untuk melindungi kluster AKS, yang terbaik adalah menggunakan opsi desain paralel. Application Gateway dengan Web Application Firewall memproses permintaan koneksi masuk ke aplikasi web di kluster. Azure Firewall hanya mengizinkan koneksi keluar yang diizinkan secara eksplisit. Untuk informasi selengkapnya tentang opsi desain paralel, lihat arsitektur Garis Besar untuk kluster AKS.

Azure Front Door (layanan pengiriman konten dari Microsoft)

Azure Front Door memiliki fungsionalitas yang tumpang tindih dengan Application Gateway di beberapa area. Kedua layanan menyediakan firewall aplikasi web, offloading SSL, dan perutean berbasis URL. Namun, perbedaan utamanya adalah bahwa sementara Application Gateway beroperasi dalam jaringan virtual, Azure Front Door adalah layanan global yang terdesentralisasi.

Anda terkadang dapat menyederhanakan desain jaringan virtual dengan mengganti Application Gateway dengan Azure Front Door terdesentralisasi. Sebagian besar desain yang dijelaskan dalam artikel ini masih berlaku, kecuali opsi untuk menempatkan Azure Firewall di depan Azure Front Door.

Salah satu skenarionya adalah menggunakan Azure Firewall di depan Application Gateway di jaringan virtual Anda. Application Gateway menyuntikkan header X-Forwarded-For dengan alamat IP instans firewall, bukan alamat IP klien. Solusinya adalah menggunakan Azure Front Door di depan firewall untuk menyuntikkan alamat IP klien sebagai header X-Forwarded-For sebelum lalu lintas memasuki jaringan virtual dan mencapai Azure Firewall. Anda juga dapat mengamankan asal Anda dengan Azure Private Link di Azure Front Door Premium.

Untuk informasi selengkapnya tentang perbedaan antara kedua layanan, atau kapan menggunakan masing-masing layanan, lihat Tanya jawab umum untuk Azure Front Door.

NVA lainnya

Produk Microsoft bukan satu-satunya pilihan untuk menerapkan firewall aplikasi web atau fungsionalitas firewall generasi berikutnya di Azure. Berbagai mitra Microsoft menyediakan NVA. Konsep dan desain pada dasarnya sama seperti dalam artikel ini, tetapi ada beberapa pertimbangan penting:

• NVA mitra untuk firewall generasi berikutnya mungkin memberikan lebih banyak kontrol dan fleksibilitas untuk konfigurasi NAT yang tidak didukung Azure Firewall. Contohnya termasuk DNAT dari lokal atau DNAT dari internet tanpa SNAT.

• NVA yang dikelola Azure seperti Application Gateway dan Azure Firewall mengurangi kompleksitas, dibandingkan dengan NVA di mana pengguna perlu menangani skalabilitas dan ketahanan di banyak appliance.

• Saat Anda menggunakan NVA di Azure, gunakan aktif-aktif dan pengaturan penskalaan otomatis sehingga appliance ini bukan hambatan untuk aplikasi yang berjalan di jaringan virtual.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

• Jose Moreno | Insinyur Pelanggan Utama

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya

Pelajari selengkapnya tentang teknologi komponen:

• Apa itu Application Gateway?
• Apa itu Azure Firewall?
• Apa itu Azure Front Door?
• AKS
• Apa itu Virtual Network?
• Apa itu Web Application Firewall?
• Arsitektur garis besar untuk kluster AKS

Sumber daya terkait

Jelajahi arsitektur terkait:

• Menerapkan jaringan hibrid yang aman
• aplikasi web yang dikelola dengan aman
• perangkat lunak multipenyewa sebagai layanan di Azure
• penyebaran Enterprise dengan menggunakan Lingkungan App Service
• Penyebaran perusahaan ketersediaan tinggi dengan menggunakan Lingkungan App Service