Firewall dan Application Gateway untuk jaringan virtual

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

• Azure DDoS Protection, dikombinasikan dengan praktik terbaik desain aplikasi, menyediakan fitur mitigasi DDoS yang ditingkatkan untuk memberikan lebih banyak pertahanan terhadap serangan DDoS. Anda harus mengaktifkan Azure DDOS Protection di jaringan virtual perimeter apa pun.
• Azure Firewall adalah firewall generasi berikutnya terkelola yang menawarkan terjemahan alamat jaringan (NAT). Azure Firewall mendasarkan pemfilteran paket di alamat Protokol Internet (IP) dan port Protokol Kendali Transmisi dan Protokol Datagram Pengguna (TCP/UDP), atau pada atribut HTTP atau SQL berbasis aplikasi. Azure Firewall juga menerapkan inteligensi ancaman Microsoft untuk mengidentifikasi alamat IP berbahaya. Untuk informasi selengkapnya, lihat Dokumentasi Azure Firewall.
• Azure Firewall Premium mencakup semua fungsi Azure Firewall Standard dan fitur lainnya, seperti TLS-inspection dan Intrusion Detection and Protection System (IDPS).
• Azure Application Gateway adalah penyeimbang beban lalu lintas web terkelola dan proxy balik penuh HTTP yang dapat melakukan enkripsi dan dekripsi Secure Socket Layer (SSL). Gateway aplikasi mempertahankan alamat IP klien asli di header HTTP X-Forwarded-For. Application Gateway juga menggunakan Web Application Firewall untuk memeriksa lalu lintas web dan mendeteksi serangan pada lapisan HTTP. Untuk informasi selengkapnya, lihat dokumentasi Application Gateway.
• Azure Web Application Firewall (WAF) adalah tambahan opsional untuk Azure Application Gateway. Aplikasi ini menyediakan pemeriksaan permintaan HTTP, dan mencegah serangan berbahaya di lapisan web, seperti Injeksi SQL atau Scripting Lintas Situs. Untuk informasi selengkapnya, lihat dokumentasi Web Application Firewall.

Layanan Azure ini saling melengkapi. Satu atau yang lain mungkin yang terbaik untuk beban kerja Anda, atau Anda dapat menggunakannya bersama-sama untuk perlindungan optimal di lapisan jaringan dan aplikasi. Gunakan pohon keputusan berikut dan contoh dalam artikel ini untuk menentukan opsi keamanan terbaik untuk jaringan virtual aplikasi Anda.

Azure Firewall dan Azure Application Gateway menggunakan teknologi yang berbeda, dan platform tersebut mendukung sekuritisasi alur yang berbeda:

Tergantung pada aliran jaringan yang dibutuhkan aplikasi, desainnya bisa berbeda berdasarkan tiap aplikasi. Diagram berikut menawarkan pohon keputusan yang disederhanakan yang membantu memilih pendekatan yang direkomendasikan untuk aplikasi. Keputusan tergantung pada apakah aplikasi dipublikasikan melalui HTTP atau protokol lainnya:

Artikel ini akan membahas desain yang direkomendasikan secara luas dari diagram alir, dan lainnya yang berlaku dalam skenario yang kurang umum:

• Azure Firewall saja, ketika tidak ada aplikasi web di jaringan virtual. Ini akan mengontrol lalu lintas masuk ke aplikasi dan lalu lintas keluar.
• Application Gateway alone, ketika hanya aplikasi web yang berada di jaringan virtual, dan kelompok keamanan jaringan (NSG) menyediakan pemfilteran keluaran yang cukup. Fungsionalitas yang disediakan oleh Azure Firewall dapat mencegah banyak skenario serangan (seperti eksfiltrasi data, IDPS, dan sebagainya). Karena alasan ini, skenario Application Gateway saja biasanya tidak direkomendasikan dan karenanya tidak didokumentasikan dan tidak ada dalam bagan alur di atas.
• Azure Firewall dan Application Gateway secara paralel, yang merupakan salah satu desain yang paling umum. Gunakan kombinasi ini saat Anda ingin agar Azure Application Gateway melindungi aplikasi HTTP dari serangan web, dan Azure Firewall untuk melindungi semua beban kerja lainnya dan memfilter lalu lintas keluar.
• Application Gateway di depan Azure Firewall, saat Anda ingin Azure Firewall untuk memeriksa semua lalu lintas, WAF untuk melindungi lalu lintas web, dan aplikasi perlu mengetahui 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, ketika Anda ingin Azure Firewall memeriksa dan memfilter lalu lintas sebelum mencapai Application Gateway. Karena Azure Firewall tidak akan mendekripsi lalu lintas HTTPS, fungsionalitas yang ditambahkan ke Application Gateway terbatas. Skenario ini tidak didokumentasikan dalam bagan alir di atas.

Pada bagian terakhir dari artikel ini, variasi desain dasar sebelumnya dijelaskan. Variasi ini meliputi:

• Klien aplikasi lokal.
• Jaringan hub dan spoke.
• Implementasi Azure Kubernetes Service (AKS).

Anda dapat menambahkan layanan proksi terbalik lainnya seperti gateway API Management atau Azure Front Door. Atau Anda dapat mengganti sumber daya Azure dengan peralatan virtual jaringan pihak ketiga.

Hanya Azure Firewall

Jika tidak ada beban kerja berbasis web di jaringan virtual yang dapat memperoleh manfaat dari WAF, Anda hanya dapat menggunakan Azure Firewall. Desain dalam hal ini sederhana, tetapi meninjau alur paket akan membantu 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 Azure VNet lainnya. Ini ditujukan ke alamat IP publik Azure Firewall untuk koneksi dari internet publik, seperti yang ditunjukkan oleh diagram di bawah ini. Lalu lintas keluar dari Azure VNets dikirim ke Firewall melalui UDR, seperti yang ditunjukkan dalam dialog di bawah ini.

Tabel berikut merangkum alur lalu lintas untuk skenario ini:

Azure Firewall tidak akan memeriksa lalu lintas HTTP inbound. Tetapi akan dapat menerapkan aturan lapisan 3 & lapisan 4 dan aturan aplikasi berbasis FQDN. Azure Firewall akan memeriksa lalu lintas HTTP keluar tergantung pada tingkat Azure Firewall dan apakah Anda mengonfigurasi inspeksi TLS:

• Azure Firewall Standard hanya akan memeriksa atribut paket lapisan 3 & lapisan 4 dalam aturan jaringan, dan header HTTP Host dalam aturan aplikasi.
• Azure Firewall Premium menambahkan kemampuan seperti memeriksa header HTTP lainnya (seperti User-Agent) dan mengaktifkan inspeksi TLS untuk analisis paket yang lebih dalam. Azure Firewall tidak setara dengan Web Application Firewall. Jika Anda memiliki beban kerja web di Virtual Network Anda, menggunakan WAF sangat disarankan.

Contoh packet walk 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, Anda akan memiliki beberapa instans aplikasi di belakang penyeimbang beban. Dalam desain ini, Azure Firewall memeriksa koneksi masuk dari internet publik, dan koneksi keluar dari VM subnet aplikasi dengan menggunakan UDR.

• Layanan Azure Firewall menyebarkan beberapa instans di bawah sampul, di sini dengan alamat IP front-end 192.168.100.4 dan alamat internal dari rentang 192.168.100.0/26. Instans individual ini biasanya tidak terlihat oleh administrator Azure. Tetapi memperhatikan perbedaannya berguna dalam beberapa kasus, seperti saat memecahkan masalah jaringan.
• Jika lalu lintas berasal dari jaringan privat maya (VPN) lokal atau gateway Azure ExpressRoute alih-alih internet, klien memulai koneksi ke alamat IP VM. Hal ini tidak memulai koneksi ke alamat IP firewall, dan firewall akan melakukan tanpa NAT Sumber sesuai default.

Arsitektur

Diagram berikut menunjukkan arus lalu lintas dengan asumsi alamat IP instans adalah 192.168.100.7.

Alur kerja

1. Klien memulai koneksi ke alamat IP publik Azure Firewall:
   • Alamat IP sumber: ClientPIP
   • Alamat IP Tujuan: AzFwPIP
2. Permintaan ke IP publik Azure Firewall didistribusikan ke instans back-end firewall, dalam hal ini 192.168.100.7. Aturan Destination NAT (DNAT) Azure Firewall menerjemahkan alamat IP tujuan ke alamat IP aplikasi di dalam jaringan virtual. Azure Firewall juga paket NAT (SNAT) jika melakukan DNAT. Untuk informasi selengkapnya, lihat masalah yang diketahui pada 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 rute yang ditentukan pengguna (UDR),, karena IP sumber adalah alamat IP Azure Firewall. UDR dalam diagram untuk 0.0.0.0/0 adalah untuk koneksi keluar, untuk memastikan paket ke internet publik melalui Azure Firewall.
   • Alamat IP Sumber: 192.168.1.4
   • Alamat IP Tujuan: 192.168.100.7
4. Terakhir, Azure Firewall membatalkan operasi SNAT dan DNAT, dan memberikan respons terhadap klien:
   • Alamat IP Sumber: AzFwPIP
   • Alamat IP Tujuan: ClientPIP

Hanya Application Gateway

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

Perbedaan utama dari desain sebelumnya hanya dengan Azure Firewall adalah bahwa Application Gateway tidak bertindak sebagai perangkat perutean dengan NAT. Ini berperilaku sebagai proksi aplikasi terbalik penuh. Artinya, Application Gateway menghentikan sesi web dari klien, dan menetapkan sesi terpisah dengan salah satu server backend-nya. Koneksi HTTP masuk dari Internet perlu dikirim ke alamat IP publik Application Gateway, koneksi dari Azure atau lokal ke alamat IP privat gateway. Lalu lintas kembali dari Azure VM akan mengikuti perutean VNet standar kembali ke Application Gateway (lihat packet walk lebih jauh untuk lebih jelasnya). Alur internet keluar dari Azure VM akan langsung menuju ke internet.

Tabel berikut ini merangkum alur lalu lintas:

Arsitektur

Contoh packet walk berikut menunjukkan bagaimana klien mengakses aplikasi yang dihosting VM dari internet publik.

Alur kerja

1. Klien memulai koneksi ke alamat IP publik Azure Application Gateway:
   • Alamat IP sumber: ClientPIP
   • Alamat IP Tujuan: AppGwPIP
2. Permintaan ke IP publik Application Gateway didistribusikan ke instans back-end gateway, dalam hal ini 192.168.200.7. Instans Application Gateway yang menerima permintaan menghentikan koneksi dari klien, dan membuat koneksi baru dengan salah satu backend. Backend tersebut melihat instans Application Gateway sebagai alamat IP sumber. Application Gateway menyisipkan header HTTP X-Forwarded-For dengan alamat IP klien asli.
   • Alamat IP Sumber: 192.168.200.7 (alamat IP privat dari instans Application Gateway)
   • Alamat IP Tujuan: 192.168.1.4
   • Header X-Forwarded-For: ClientPIP
3. VM menjawab permintaan aplikasi, yang membalikkan alamat IP sumber dan tujuan. VM sudah tahu cara mencapai Application Gateway, jadi tidak memerlukan UDR.
   • Alamat IP Sumber: 192.168.1.4
   • Alamat IP Tujuan: 192.168.200.7
4. Terakhir, instans Application Gateway menjawab klien:
   • Alamat IP Sumber: AppGwPIP
   • Alamat IP Tujuan: ClientPIP

Azure 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 geolokasi tertentu, atau untuk pengelogan. Untuk info selengkapnya, lihat Cara kerja gateway aplikasi.

• Alamat 192.168.200.7 IP adalah salah satu instans yang disebarkan layanan Azure Application Gateway di bawah sampul, di sini dengan alamat 192.168.200.4IP front-end internal privat . Instans individual ini biasanya tidak terlihat oleh administrator Azure. Tetapi memperhatikan perbedaannya berguna dalam beberapa kasus, seperti saat memecahkan masalah jaringan.

• Alirannya serupa jika klien berasal dari jaringan lokal melalui gateway VPN atau ExpressRoute. Perbedaannya adalah klien mengakses alamat IP privat Application Gateway alih-alih alamat publik.

Firewall dan Application Gateway secara paralel

Karena kesederhanaan dan fleksibilitasnya, menjalankan Application Gateway dan Azure Firewall secara paralel seringkali merupakan skenario terbaik.

Terapkan desain ini jika ada campuran beban kerja web dan non-web di jaringan virtual. Azure WAF di Azure Application Gateway melindungi lalu lintas masuk ke beban kerja web, dan Azure Firewall memeriksa lalu lintas masuk untuk aplikasi lain. Azure Firewall akan 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 ke alamat IP privat. Perutean VNet standar akan mengirim paket dari Application Gateway ke VM tujuan, serta dari VM tujuan kembali ke Application Gateway (lihat packet waalk lebih mendala untuk rincian lebih lanjut). Untuk koneksi non-HTTP masuk, lalu lintas harus menargetkan alamat IP publik Azure Firewall (jika berasal dari Internet publik), atau akan dikirim melalui Azure Firewall oleh UDR (jika berasal dari Azure VNets atau jaringan lokal lainnya). Semua alur keluar dari Azure VM akan diteruskan ke Azure Firewall oleh UDR.

Tabel berikut merangkum alur lalu lintas untuk skenario ini:

Desain ini memberikan pemfilteran keluar yang jauh lebih terperinci daripada NSG. Misalnya, jika aplikasi memerlukan konektivitas ke Akun Azure Storage tertentu, Anda dapat menggunakan filter berbasis nama domain yang sepenuhnya memenuhi syarat (FQDN). Dengan filter berbasis FQDN, aplikasi tidak mengirim data ke akun penyimpanan nakal. Skenario itu tidak dapat dicegah hanya dengan menggunakan NSG. Desain ini sering digunakan di mana lalu lintas keluar membutuhkan pemfilteran berbasis FQDN. Salah satu contoh situasi adalah saat membatasi lalu lintas keluar dari klaster Azure Kubernetes Services.

Arsitektur

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

Diagram berikut menggambarkan alur lalu lintas untuk koneksi keluar dari VM jaringan ke internet. Salah satu contohnya adalah untuk terhubung ke sistem backend atau mendapatkan pembaruan sistem operasi:

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

Application Gateway sebelum Firewall

Desain ini dijelaskan secara lebih rinci di jaringan Zero-trust untuk aplikasi web dengan Azure Firewall dan Application Gateway, dokumen ini akan berfokus pada perbandingan dengan opsi desain lainnya. Dalam topologi ini, lalu lintas web masuk melewati Azure Firewall dan WAF. WAF memberikan perlindungan pada lapisan aplikasi web. Azure Firewall bertindak sebagai pengelogan pusat dan titik kontrol, dan memeriksa lalu lintas antara Application Gateway dan server backend. Application Gateway dan Azure Firewall tidak bertindak secara paralel, tetapi satu demi satu.

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 backend web.

Desain ini sesuai untuk aplikasi yang perlu mengetahui alamat IP sumber klien yang masuk, misalnya untuk melayani konten geolokasi tertentu atau untuk pengelogan. Application Gateway di depan Azure Firewall menangkap alamat IP sumber paket masuk di header X-forwarded-for, sehingga server web dapat melihat alamat IP asli di header ini. Untuk info 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 ke alamat IP privat. Dari Application Gateway, UDR akan memastikan bahwa paket dialihkan melalui Azure Firewall (lihat packet walk lebih mendalam untuk rincian lebih lanjut). Untuk koneksi non-HTTP masuk, lalu lintas harus menargetkan alamat IP publik Azure Firewall (jika berasal dari Internet publik), atau akan dikirim melalui Azure Firewall oleh UDR (jika berasal dari Azure VNets atau jaringan lokal lainnya). Semua alur keluar dari Azure VM akan diteruskan ke Azure Firewall oleh UDR.

Keterangan penting dari desain ini adalah bahwa Azure Firewall Premium akan 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/16172.16.0.0/12 atau 100.64.0.0/10), Azure Firewall Premium akan memperlakukan lalu lintas dari Application Gateway sebagai internal, dan tidak akan menerapkan aturan IDPS untuk lalu lintas masuk. Anda dapat menemukan informasi selengkapnya tentang petunjuk aturan IDPS Azure Firewall dan awalan IP privat untuk IDPS di Aturan IDPS Azure Firewall. Akibatnya, disarankan untuk memodifikasi awalan privat IDPS dalam kebijakan Azure Firewall sehingga subnet Application Gateway tidak dianggap sebagai sumber internal, untuk menerapkan tanda tangan IDPS masuk dan keluar ke lalu lintas.

Tabel berikut merangkum alur lalu lintas untuk skenario ini:

Untuk lalu lintas web dari lokal atau internet ke Azure, Azure Firewall akan memeriksa alur yang telah diizinkan oleh WAF. Bergantung pada apakah Application Gateway mengenkripsi lalu lintas backend (lalu lintas dari Application Gateway ke server aplikasi), Anda akan memiliki skenario potensial yang berbeda:

1. Application Gateway mengenkripsi lalu lintas mengikuti prinsip-prinsip zero-trust (enkripsi TLS End-to-End), dan Azure Firewall akan menerima lalu lintas terenkripsi. Namun, Azure Firewall Standard akan dapat menerapkan aturan inspeksi, seperti pemfilteran lapisan 3 & lapisan 4 dalam aturan jaringan, atau pemfilteran FQDN dalam aturan aplikasi menggunakan header Indikasi Nama Server TLS (SNI). Azure Firewall Premium memberikan visibilitas yang lebih dalam dengan inspeksi TLS, seperti pemfilteran berbasis URL.
2. 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.
3. Jika IDPS diaktifkan di Azure Firewall, itu akan memverifikasi bahwa header Host HTTP cocok dengan IP tujuan. Dengan tujuan itu, perlu resolusi nama untuk FQDN yang ditentukan dalam header Host. Resolusi nama ini dapat dicapai dengan Azure DNS Private Zones dan pengaturan DNS Azure Firewall default menggunakan Azure DNS. Hal ini juga dapat dicapai dengan server DNS kustom yang perlu dikonfigurasi dalam pengaturan Azure Firewall. (Untuk informasi selengkapnya, lihat Azure Firewall DNS Pengaturan.) Jika tidak ada akses administratif ke Virtual Network tempat Azure Firewall disebarkan, metode terakhir adalah satu-satunya kemungkinan. Salah satu contohnya adalah dengan Azure Firewall yang disebarkan di Hub Aman Virtual WAN.

Arsitektur

Untuk sisa alur (lalu lintas non-HTTP masuk dan lalu lintas keluar), Azure Firewall akan menyediakan inspeksi IDPS dan inspeksi TLS jika sesuai. Aplikasi ini juga menyediakan pemfilteran berbasis FQDN dalam aturan jaringan berdasarkan DNS.

Alur kerja

Lalu lintas jaringan dari internet publik mengikuti alur ini:

1. Klien memulai koneksi ke alamat IP publik Azure Application Gateway:
   • Alamat IP sumber: ClientPIP
   • Alamat IP Tujuan: AppGwPIP
2. Permintaan ke IP publik Application Gateway didistribusikan ke instans back-end gateway, dalam hal ini 192.168.200.7. Instans Application Gateway menghentikan koneksi dari klien, dan membuat koneksi baru dengan salah satu backend. UDR ke 192.168.1.0/24 di subnet Application Gateway meneruskan paket ke Azure Firewall, sambil mempertahankan IP tujuan ke aplikasi web:
   • Alamat IP Sumber: 192.168.200.7 (alamat IP privat dari instans Application Gateway)
   • Alamat IP Tujuan: 192.168.1.4
   • Header X-Forwarded-For: ClientPIP
3. Azure Firewall tidak melakukan SNAT lalu lintas, karena lalu lintas akan menuju ke alamat IP pribadi. Aplikasi ini meneruskan lalu lintas ke VM aplikasi jika aturan mengizinkannya. Untuk informasi selengkapnya, lihat SNAT Azure Firewall. Namun, jika lalu lintas mencapai aturan aplikasi di firewall, beban kerja akan melihat alamat IP sumber dari instans firewall tertentu yang memproses paket, karena Azure Firewall akan memproksi koneksi:
   • Alamat IP sumber jika lalu lintas diizinkan oleh aturan jaringan Azure Firewall: 192.168.200.7 (alamat IP privat salah satu instans Application Gateway).
   • Alamat IP sumber jika lalu lintas diizinkan oleh aturan aplikasi Azure Firewall: 192.168.100.7 (alamat IP privat salah satu instans Azure Firewall).
   • Alamat IP Tujuan: 192.168.1.4
   • Header X-Forwarded-For: ClientPIP
4. VM menjawab permintaan aplikasi, yang membalikkan alamat IP sumber dan tujuan. UDR untuk 192.168.200.0/24 menangkap paket yang dikirim kembali ke Application Gateway dan mengalihkannya ke Azure Firewall, sambil mempertahankan IP tujuan menuju Application Gateway.
   • Alamat IP Sumber: 192.168.1.4
   • Alamat IP Tujuan: 192.168.200.7
5. Di sini sekali lagi Azure Firewall tidak melakukan SNAT lalu lintas, karena akan menuju 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. Terakhir, instans Application Gateway menjawab klien:
   • Alamat IP Sumber: AppGwPIP
   • Alamat IP Tujuan: ClientPIP

Aliran keluar dari VM ke internet publik melewati Azure Firewall, seperti yang ditetapkan oleh UDR untuk 0.0.0.0/0.

Application Gateway setelah firewall

Desain ini memungkinkan Azure Firewall memfilter dan membuang lalu lintas berbahaya sebelum mencapai Application Gateway. Misalnya, platform 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. Namun, Azure Firewall SNATs lalu lintas masuk, sehingga aplikasi tidak akan memiliki visibilitas ke alamat IP asli dari permintaan HTTP. Dari perspektif administrasi, misalnya untuk tujuan pemecahan masalah, Anda dapat memperoleh IP klien aktual untuk koneksi tertentu dengan menghubungkannya dengan log SNAT Azure Firewall.

Ada manfaat terbatas dalam skenario ini, karena Azure Firewall hanya akan melihat lalu lintas terenkripsi masuk ke Application Gateway. Mungkin ada skenario di mana desain ini lebih disukai. Satu kasus adalah jika WAF lain lebih awal di jaringan (misalnya, dengan Azure Front Door), yang dapat menangkap IP sumber asli di X-Forwarded-Forheader HTTP. Atau desain tersebut lebih disukai jika banyak alamat IP publik diperlukan.

Aliran masuk HTTP(S) dari Internet publik harus menargetkan alamat IP publik Azure Firewall, dan Azure Firewall akan DNAT (dan SNAT) paket ke alamat IP pribadi Gateway Aplikasi. Dari Azure VNet atau jaringan lokal lainnya, lalu lintas HTTP harus dikirim ke IP privat Application Gateway, dan diteruskan melalui Azure Firewall dengan UDR. Perutean VNet standar akan memastikan bahwa lalu lintas balik dari Azure VM kembali ke Application Gateway, dan dari Application Gateway ke Azure Firewall jika aturan DNAT digunakan. Untuk lalu lintas dari UDR lokal atau Azure di subnet Application Gateway harus digunakan (lihat paket berjalan lebih jauh ke bawah untuk detail selengkapnya). Semua lalu lintas keluar dari Azure VM ke internet akan dikirim melalui Azure Firewall oleh UDR.

Tabel berikut merangkum alur lalu lintas untuk skenario ini:

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

Arsitektur

Aplikasi tersebut tidak dapat melihat alamat IP sumber asli lalu lintas web; Azure Firewall melakukan SNAT paket saat aplikasi 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.

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 IP publik Azure Firewall didistribusikan ke instans back-end firewall, dalam hal ini 192.168.100.7. Azure Firewall melakukan DNAT port web, biasanya TCP 443, ke alamat IP privat instans Application Gateway. Azure Firewall juga melakukan SNAT saat melakukan DNAT. Untuk informasi selengkapnya, lihat Masalah umum Azure Firewall:
   • Alamat IP sumber: 192.168.100.7 (alamat IP privat instans Azure Firewall)
   • Alamat IP Tujuan: 192.168.200.4
3. Application Gateway menetapkan sesi baru antara instans yang menangani koneksi dan salah satu server backend. Alamat IP asli klien tidak ada dalam paket:
   • Alamat IP Sumber: 192.168.200.7 (alamat IP privat dari instans Application Gateway)
   • Alamat IP Tujuan: 192.168.1.4
   • Header X-Forwarded-For: 192.168.100.7
4. VM menjawab Application Gateway, 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 dari instans Azure Firewall. Bahkan jika koneksi berasal dari instans Application Gateway tertentu seperti .7, Azure Firewall melihat alamat IP internal Application Gateway .4 sebagai IP sumber:
   • Alamat IP Sumber: 192.168.200.4
   • Alamat IP Tujuan: 192.168.100.7
6. Akhirnya, Azure Firewall membatalkan SNAT dan DNAT dan menjawab klien:
   • Alamat IP Sumber: AzFwPIP
   • Alamat IP Tujuan: ClientPIP

Bahkan jika Application Gateway tidak memiliki pendengar yang dikonfigurasi untuk aplikasi, itu masih memerlukan alamat IP publik sehingga Microsoft dapat mengelolanya.

Klien lokal

Desain sebelumnya semua menunjukkan klien aplikasi yang berasal dari internet publik. Jaringan lokal juga mengakses aplikasi. Sebagian besar informasi sebelumnya dan alur lalu lintas sama dengan klien internet, tetapi ada beberapa perbedaan penting:

• Gateway VPN atau gateway ExpressRoute berada di depan Azure Firewall atau Application Gateway.
• WAF menggunakan alamat IP privat Application Gateway.
• Azure Firewall tidak mendukung DNAT untuk alamat IP privat. Itu sebabnya Anda harus menggunakan UDR untuk mengirim lalu lintas masuk ke Azure Firewall dari gateway VPN atau ExpressRoute.
• Pastikan untuk memverifikasi peringatan seputar penerowongan paksa untuk Azure Application Gateway dan untuk Azure Firewall. Meski 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 mengarah ke jaringan lokal, atau Anda akan melanggar lalu lintas kontrol. Untuk Azure Application Gateway, rute default perlu mengarah ke internet publik.

Arsitektur

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

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

Topologi hub dan spoke

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

Arsitektur

Pertimbangan

Beberapa pertimbangan untuk topologi ini meliputi:

• Azure Firewall disebarkan di jaringan virtual hub pusat. Diagram di atas menunjukkan praktik penyebaran Application Gateway di hub. Meskipun tim aplikasi sering mengelola komponen seperti Azure Application Gateways atau gateway Azure API Management. Dalam hal ini, komponen-komponen ini disebarkan di jaringan virtual spoke.
• Berikan perhatian khusus pada UDR di jaringan spoke: Ketika server aplikasi dalam spoke menerima lalu lintas dari instans Azure Firewall tertentu, seperti 192.168.100.7 alamat pada contoh sebelumnya, server aplikasi harus mengirim lalu lintas kembali ke instans yang sama. Jika UDR dalam spoke menetapkan hop lalu lintas berikutnya yang ditujukan ke hub ke alamat IP Azure Firewall (192.168.100.4 pada diagram di atas), paket pengembalian mungkin berakhir pada instans Azure Firewall yang berbeda, sehingga menyebabkan perutean asimetris. Pastikan bahwa jika Anda memiliki UDR di VNet yang berbicara untuk mengirim lalu lintas ke layanan bersama di hub melalui Azure Firewall, UDR ini tidak menyertakan prefiks subnet Azure Firewall.
• Rekomendasi sebelumnya berlaku sama untuk subnet Application Gateway dan Network Virtual Appliances lainnya atau proksi terbalik yang mungkin disebarkan di VNet 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 berlaku di VNet lokal dan tidak di seluruh peering VNet. Untuk informasi selengkapnya tentang rute yang ditentukan pengguna dan tipe hop berikutnya, baca Perutean lalu lintas jaringan virtual.

Perutean asimetris

Diagram di bawah ini menunjukkan bagaimana spoke mengirimkan kembali lalu lintas yang di-SNAT kembali ke ALB dari Azure Firewall. Pengaturan ini menyebabkan perutean asimetris:

Untuk mengatasi masalah ini, tentukan UDR dalam spoke tanpa subnet Azure Firewall tetapi hanya dengan subnet tempat layanan bersama berada. Dalam contoh tersebut, UDR yang benar dalam spoke seharusnya hanya berisi 192.168.1.0/24. Seharusnya tidak mengandung seluruh 192.168.0.0/16, seperti yang ditandai dengan warna merah.

Integrasi dengan produk Azure lainnya

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

Gateway API Management

Integrasikan layanan proksi terbalik seperti gateway API Management ke dalam desain sebelumnya untuk menyediakan fungsionalitas seperti throttling API atau proksi autentikasi. Mengintegrasikan gateway API Management tidak memberikan perubahan besar pada desain. Perbedaan utamanya adalah bahwa alih-alih proksi terbalik Application Gateway tunggal, ada dua proksi terbalik yang dirangkai di belakang satu sama lain.

Untuk informasi selengkapnya, lihat Panduan Desain untuk mengintegrasikan API Management dan Application Gateway dalam jaringan virtual dan pola aplikasi API Gateways untuk Microservices.

Azure Kubernetes Service

Untuk beban kerja yang berjalan pada klaster AKS, Anda dapat menyebarkan Azure Application Gateway secara independen dari klaster. Atau Anda dapat mengintegrasikannya dengan klaster AKS menggunakan Pengontrol Masuk Azure Application Gateway. Saat mengonfigurasi objek tertentu pada level Kubernetes (seperti layanan dan masuknya), Application Gateway secara otomatis beradaptasi tanpa memerlukan langkah manual tambahan.

Azure Firewall memainkan peran penting dalam keamanan klaster AKS. Aplikasi ini menawarkan fungsionalitas yang diperlukan untuk memfilter lalu lintas keluar dari klaster AKS berdasarkan FQDN, bukan hanya alamat IP. Untuk informasi selengkapnya, lihat Mengontrol lalu lintas keluar untuk node klaster Azure Kubernetes Service.

Saat Anda menggabungkan Application Gateway dan Azure Firewall untuk melindungi klaster AKS, yang terbaik adalah menggunakan opsi desain paralel. Application Gateway dengan WAF memproses permintaan koneksi masuk ke aplikasi web di klaster. Azure Firewall hanya mengizinkan koneksi keluar yang diizinkan secara eksplisit. Lihat Arsitektur garis besar untuk kluster Azure Kubernetes Service (AKS) untuk contoh opsi desain paralel.

Azure Front Door

Fungsi Azure Front Door sebagian tumpang tindih dengan Azure Application Gateway. Misalnya, kedua layanan menawarkan firewall aplikasi web, pembongkaran SSL, dan perutean berbasis URL. Satu perbedaan utama adalah bahwa meskipun Azure Application Gateway berada di dalam jaringan virtual, Azure Front Door adalah layanan global yang terdesentralisasi.

Terkadang Anda dapat menyederhanakan desain jaringan virtual dengan mengganti Application Gateway dengan Azure Front Door yang terdesentralisasi. Sebagian besar desain yang dijelaskan di sini tetap berlaku, kecuali opsi menempatkan Azure Firewall di depan Azure Front Door.

Kasus penggunaan yang menarik adalah menggunakan Azure Firewall di depan Application Gateway di jaringan virtual Anda. Seperti yang dijelaskan sebelumnya, header X-Forwarded-For yang disuntikkan oleh Application Gateway akan berisi 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 mengenai Azure Firewall. Opsi kedua adalah Mengamankan Asal Anda dengan Private Link di Azure Front Door Premium.

Untuk informasi selengkapnya tentang perbedaan antara kedua layanan, atau kapan menggunakan masing-masing, lihat Pertanyaan yang Sering Diajukan untuk Azure Front Door.

Peralatan virtual jaringan lainnya

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

• NVA mitra untuk firewall generasi berikutnya dapat menawarkan lebih banyak kontrol dan fleksibilitas untuk konfigurasi NAT yang tidak didukung oleh 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 peralatan.
• Saat menggunakan NVA di Azure, gunakan pengaturan aktif-aktif dan penskalaan otomatis, sehingga peralatan ini tidak menjadi hambatan bagi aplikasi yang berjalan di jaringan virtual.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Jose Moreno | Insinyur Pelanggan Utama

Langkah berikutnya

Pelajari selengkapnya tentang teknologi komponen:

• Apa itu Azure Application Gateway?
• Apa itu Azure Firewall?
• Apa itu Azure Front Door?
• Azure Kubernetes Service
• Apa itu Azure Virtual Network?
• Apa itu Azure Web Application Firewall?

Sumber daya terkait

Jelajahi arsitektur terkait:

• Mengimplementasikan jaringan hibrida yang aman
• Aplikasi web yang dikelola dengan aman
• Mengamankan bot saluran dan aplikasi web Microsoft Teams Anda di balik firewall
• Portal kesehatan konsumen di Azure
• Pertimbangan keamanan untuk aplikasi IaaS yang sangat sensitif di Azure
• SaaS Multi-penyewaan di Azure
• Penyebaran Enterprise menggunakan Lingkungan App Services
• Penyebaran perusahaan dengan ketersediaan tinggi menggunakan Lingkungan App Services
• Arsitektur dasar untuk klaster Azure Kubernetes Service (AKS)