Menerapkan jaringan Zero Trust untuk aplikasi web dengan menggunakan Azure Firewall dan Azure Application Gateway

Artikel ini menjelaskan cara menerapkan keamanan Zero Trust untuk aplikasi web guna mengaktifkan inspeksi dan enkripsi end-to-end. Model Zero Trust mencakup banyak konsep lain, seperti verifikasi identitas berkelanjutan dan meminimalkan ukuran area kepercayaan implisit.

Artikel ini berfokus pada komponen enkripsi dan inspeksi arsitektur Zero Trust untuk lalu lintas masuk dari internet publik. Untuk informasi selengkapnya tentang aspek lain penyebaran aplikasi Anda dengan aman, seperti autentikasi dan otorisasi, lihat dokumentasi Zero Trust. Contoh dalam artikel ini menggunakan pendekatan multilayer. Dalam pendekatan multilayer, keamanan jaringan membentuk salah satu lapisan model Zero Trust. Dalam lapisan ini, appliance jaringan memeriksa paket untuk memastikan bahwa hanya lalu lintas yang sah yang menjangkau aplikasi.

Biasanya, berbagai jenis appliance jaringan memeriksa berbagai aspek paket jaringan:

• Firewall aplikasi web mencari pola yang menunjukkan serangan di lapisan aplikasi web.

• Firewall generasi berikutnya juga dapat mencari ancaman generik.

Arsitektur ini berfokus pada pola umum untuk memaksimalkan keamanan, di mana Azure Application Gateway memeriksa dan memproses lalu lintas sebelum mencapai Azure Firewall Premium. Dalam beberapa skenario, Anda dapat menggabungkan berbagai jenis appliance keamanan jaringan untuk meningkatkan perlindungan. Untuk informasi selengkapnya, lihat Azure Firewall dan Application Gateway untuk jaringan virtual.

Arsitektur

Dalam diagram ini, panah berlabel HTTPS menunjuk dari ikon yang mewakili klien ke ikon yang mewakili Application Gateway dan Azure Web Application Firewall. Panah lain berlabel HTTPS mengarah dari ikon-ikon ini menuju ikon Azure Firewall Premium. Dua panah menunjuk dari ikon Azure Firewall Premium. Satu panah diberi label Sistem Nama Domain (DNS) dan menunjuk ke server DNS atau zona privat. Panah lainnya diberi label HTTPS dan menunjuk ke ikon yang mewakili Azure Virtual Machines.

Unduh file Visio dari arsitektur ini.

Arsitektur ini menggunakan protokol Keamanan Lapisan Transportasi (TLS) untuk mengenkripsi lalu lintas di setiap langkah.

1. Klien mengirim paket ke Application Gateway, load balancer. Ini berjalan dengan penambahan opsional Azure Web Application Firewall.

2. Application Gateway mendekripsi paket dan mencari ancaman terhadap aplikasi web. Jika tidak menemukan ancaman apa pun, ia menggunakan prinsip Zero Trust untuk mengenkripsi paket. Kemudian merilis mereka.

3. Azure Firewall Premium menjalankan pemeriksaan keamanan berikut:

   • Inspeksi TLS mendekripsi dan memeriksa paket.
   • Fitur sistem deteksi dan pencegahan intrusi (IDPS) memeriksa paket untuk niat jahat.

4. Jika paket lulus pengujian, Azure Firewall Premium mengambil langkah-langkah berikut:

   • Ini mengenkripsi paket.
   • Ini menggunakan layanan Sistem Nama Domain (DNS) untuk menentukan komputer virtual aplikasi (VM).
   • Ini meneruskan paket ke VM aplikasi.

Berbagai mesin inspeksi dalam arsitektur ini memastikan integritas lalu lintas:

• Azure Web Application Firewall menggunakan aturan untuk mencegah serangan di lapisan web. Contoh serangan termasuk injeksi kode SQL dan scripting lintas situs. Untuk informasi selengkapnya tentang aturan dan Seperangkat Aturan Inti (CRS) Open Worldwide Application Security Project (OWASP), lihat Grup aturan dan aturan CRS firewall aplikasi web.

• Azure Firewall Premium menggunakan aturan deteksi dan pencegahan intrusi generik. Aturan ini membantu mengidentifikasi file berbahaya dan ancaman lain yang menargetkan aplikasi web.

Arsitektur ini mendukung jenis desain jaringan berikut, yang dibahas artikel ini:

• Jaringan hub dan spoke tradisional
• Jaringan yang menggunakan Azure Virtual WAN sebagai platform
• Jaringan yang menggunakan Azure Route Server untuk menyederhanakan perutean dinamis

Azure Firewall Premium dan resolusi nama

Saat Azure Firewall Premium memeriksa lalu lintas berbahaya, Azure Firewall Premium memverifikasi bahwa header Host HTTP cocok dengan alamat IP paket dan port Protokol Kontrol Transmisi (TCP). Misalnya, Application Gateway mengirim paket web ke alamat IP 172.16.1.4 dan port TCP 443. Nilai header Host HTTP harus diselesaikan ke alamat IP tersebut.

Header Host HTTP biasanya tidak berisi alamat IP. Sebagai gantinya, header berisi nama yang cocok dengan sertifikat digital server. Dalam hal ini, Azure Firewall Premium menggunakan DNS untuk menyelesaikan nama header Host ke alamat IP. Desain jaringan menentukan solusi DNS mana yang paling sesuai.

Nota

Application Gateway tidak mendukung nomor port di header Host HTTP. Akibatnya:

• Azure Firewall Premium mengasumsikan port TCP HTTPS default 443.
• Koneksi antara Application Gateway dan server web hanya mendukung port TCP 443, bukan port nonstandar.

Sertifikat digital

Diagram berikut menunjukkan nama umum (CN) dan otoritas sertifikat (CA) yang digunakan sesi dan sertifikat TLS arsitektur ini.

Dalam diagram ini, panah berlabel HTTPS menunjuk dari ikon yang mewakili klien ke ikon yang mewakili Application Gateway dan Azure Web Application Firewall. Di sisi kiri ikon ini adalah CN, myapp.contoso.com, dan CA, DigiCert. Di sisi kanan ikon ini adalah CA akar Azure Firewall di pengaturan HTTP. Panah lain berlabel HTTPS mengarah dari ikon-ikon ini menuju ikon Azure Firewall Premium. Di sisi kiri ikon ini adalah CN, myapp.contoso.com, dan CA, Azure Firewall CA. Panah lain berlabel HTTPS menunjuk ke ikon yang mewakili Azure Virtual Machines. Di sisi kiri ikon ini adalah CN, myapp.contoso.com, dan CA, DigiCert.

Azure Firewall secara dinamis menghasilkan sertifikatnya sendiri. Kemampuan ini adalah salah satu alasan utama mengapa itu ditempatkan di belakang Application Gateway. Jika tidak, klien aplikasi dihadapkan dengan sertifikat yang dihasilkan sendiri yang ditandai sebagai risiko keamanan.

Koneksi TLS

Arsitektur ini berisi tiga koneksi TLS yang berbeda. Sertifikat digital memvalidasi masing-masing sertifikat.

Dari klien ke Application Gateway

Di Application Gateway, Anda menyebarkan sertifikat digital yang dilihat klien. CA terkenal seperti DigiCert atau Let's Encrypt biasanya mengeluarkan sertifikat seperti itu. Mekanisme ini pada dasarnya berbeda dari bagaimana Azure Firewall secara dinamis menghasilkan sertifikat digital dari CA infrastruktur kunci publik yang ditandatangani sendiri atau internal.

Dari Application Gateway ke Azure Firewall Premium

Untuk mendekripsi dan memeriksa lalu lintas TLS, Azure Firewall Premium secara dinamis menghasilkan sertifikat. Azure Firewall Premium juga menyajikan dirinya ke Application Gateway sebagai server web. CA privat menandatangani sertifikat yang dihasilkan Azure Firewall Premium. Untuk informasi selengkapnya, lihat sertifikat Azure Firewall Premium. Application Gateway perlu memvalidasi sertifikat tersebut. Dalam pengaturan HTTP aplikasi, Anda mengonfigurasi CA akar yang digunakan Azure Firewall Premium.

Dari Azure Firewall Premium ke server web

Azure Firewall Premium membuat sesi TLS dengan server web tujuan. Azure Firewall Premium memverifikasi bahwa CA terkenal menandatangani paket TLS server web.

Peran komponen

Application Gateway dan Azure Firewall Premium menangani sertifikat secara berbeda satu sama lain karena perannya berbeda:

• Application Gateway adalah proksi web terbalik. Ini melindungi server web dari klien berbahaya dengan mencegat permintaan HTTP dan HTTPS. Anda mendeklarasikan setiap server yang dilindungi yang berada di kumpulan back-end Application Gateway dengan alamat IP-nya atau nama domain yang sepenuhnya memenuhi syarat. Klien yang sah harus dapat mengakses setiap aplikasi. Jadi Anda mengonfigurasi Application Gateway dengan sertifikat digital yang ditandatangani CA publik. Gunakan CA yang diterima klien TLS mana pun.

• Azure Firewall Premium adalah proksi web penerusan atau, hanya proksi web. Ini melindungi klien dari server web berbahaya dengan mencegat panggilan TLS dari klien yang dilindungi. Ketika klien yang dilindungi membuat permintaan HTTP, proksi web penerusan meniru server web target dengan membuat sertifikat digital dan menyajikannya kepada klien. Azure Firewall Premium menggunakan CA privat, yang menandatangani sertifikat yang dihasilkan secara dinamis. Anda mengonfigurasi klien yang dilindungi untuk mempercayai CA privat tersebut. Dalam arsitektur ini, Azure Firewall Premium melindungi permintaan dari Application Gateway ke server web. Application Gateway mempercayai CA privat yang digunakan Azure Firewall Premium.

Perutean dan penerusan lalu lintas

Perutean sedikit berbeda tergantung pada topologi desain jaringan Anda. Bagian berikut menjelaskan contoh topologi hub dan spoke, Virtual WAN, dan Route Server. Semua topologi memiliki aspek-aspek berikut yang sama:

• Application Gateway selalu berfungsi sebagai proksi. Azure Firewall Premium juga berfungsi sebagai proksi saat dikonfigurasi untuk inspeksi TLS. Application Gateway mengakhiri sesi TLS dari klien, dan sesi TLS baru dibangun menuju Azure Firewall. Azure Firewall menerima dan mengakhiri sesi TLS yang bersumber dari Application Gateway dan membangun sesi TLS baru menuju beban kerja. Proses ini memengaruhi konfigurasi IDPS Azure Firewall Premium. Untuk informasi selengkapnya, lihat IDPS dan alamat IP privat.

• Beban kerja ini melihat koneksi yang berasal dari alamat IP subnet Azure Firewall. Alamat IP klien asli dipertahankan X-Forwarded-For di header HTTP yang disisipkan Application Gateway. Azure Firewall juga mendukung menyuntikkan alamat IP klien sumber di X-Forwarded-For header. Dalam skenario ini, alamat IP klien sumber adalah alamat IP gateway aplikasi.

• Lalu lintas dari Application Gateway ke beban kerja biasanya dikirim ke Azure Firewall dengan menggunakan mekanisme perutean Azure. Mekanisme ini termasuk rute yang ditentukan pengguna (UDR) yang dikonfigurasi di subnet Application Gateway atau rute yang disuntikkan Virtual WAN atau Route Server. Menentukan alamat IP privat Azure Firewall secara eksplisit di kumpulan back-end Application Gateway dimungkinkan, tetapi kami tidak menyarankan melakukannya karena menghapus beberapa fungsionalitas asli Application Gateway, seperti penyeimbangan beban dan kelekatan sesi.

Bagian berikut ini menjelaskan beberapa topologi paling umum yang bisa Anda gunakan dengan Azure Firewall dan Application Gateway.

Topologi hub dan jari-jari

Desain hub dan spoke biasanya menyebarkan komponen jaringan bersama di jaringan virtual hub dan komponen khusus aplikasi dalam spoke. Di sebagian besar sistem, Azure Firewall Premium adalah sumber daya bersama. Azure Web Application Firewall dapat menjadi perangkat jaringan bersama atau komponen khusus aplikasi. Ini adalah praktik terbaik untuk memperlakukan Application Gateway sebagai komponen aplikasi dan menyebarkannya di jaringan virtual spoke karena alasan berikut:

• Mungkin sulit untuk memecahkan masalah pemberitahuan Azure Web Application Firewall. Anda umumnya memerlukan pengetahuan mendalam tentang aplikasi untuk memutuskan apakah pesan yang memicu alarm tersebut sah.

• Jika Anda memperlakukan Application Gateway sebagai sumber daya bersama, Anda mungkin melebihi batas Application Gateway.

• Anda mungkin menghadapi masalah kontrol akses berbasis peran jika Anda menyebarkan Application Gateway di hub. Situasi ini dapat terjadi ketika tim mengelola aplikasi yang berbeda tetapi menggunakan instans Application Gateway yang sama. Setiap tim kemudian memiliki akses ke seluruh konfigurasi Application Gateway.

Dalam arsitektur hub dan spoke tradisional, zona privat DNS menyediakan cara mudah untuk menggunakan DNS:

1. Mengonfigurasi zona privat DNS.
2. Tautkan zona ke jaringan virtual yang berisi Azure Firewall Premium.
3. Pastikan bahwa ada catatan alamat untuk nilai yang digunakan Application Gateway untuk lalu lintas data dan pemeriksaan kesehatan.

Diagram berikut menunjukkan alur paket saat Application Gateway berada dalam jaringan virtual spoke. Dalam hal ini, klien terhubung dari internet publik.

Diagram terdiri dari dua bagian utama, jaringan virtual hub dan jaringan virtual spoke. Panah biru mewakili perjalanan permintaan klien dari internet ke subnet aplikasi di jaringan virtual spoke. Panah biru dimulai pada ikon yang mewakili internet dan menunjuk ke subnet Application Gateway di jaringan virtual spoke. Panah biru berlanjut dari subnet Application Gateway ke subnet Azure Firewall di jaringan virtual hub. Kemudian mengarah dari subnet Azure Firewall menuju subnet aplikasi dalam jaringan virtual spoke. Panah dua sisi berlabel jaringan virtual peering menghubungkan jaringan virtual hub dan segmen jaringan virtual spoke. Panah hijau mewakili perjalanan permintaan klien dari subnet aplikasi kembali ke klien. Panah hijau dimulai pada subnet aplikasi dan menunjuk ke subnet Azure Firewall. Panah hijau berlanjut dari subnet Azure Firewall ke subnet Application Gateway dan kembali ke klien.

1. Klien mengirimkan permintaan ke server web.

2. Application Gateway mencegat paket klien dan memeriksanya. Jika paket melewati inspeksi, Application Gateway mengirimkan paket ke VM back-end. Saat paket mencapai Azure, UDR di subnet Application Gateway meneruskannya ke Azure Firewall Premium.

3. Azure Firewall Premium menjalankan pemeriksaan keamanan pada paket. Jika mereka lulus pengujian, Azure Firewall Premium meneruskan paket ke VM aplikasi.

4. VM merespons dan mengatur alamat IP tujuan ke gateway aplikasi. UDR di subnet VM mengalihkan paket ke Azure Firewall Premium.

5. Azure Firewall Premium meneruskan paket ke Application Gateway.

6. Application Gateway menjawab klien.

Lalu lintas juga dapat tiba dari jaringan lokal alih-alih internet publik. Lalu lintas mengalir baik melalui jaringan privat virtual situs-ke-situs (VPN) atau melalui Azure ExpressRoute. Dalam skenario ini, lalu lintas pertama kali mencapai gateway jaringan virtual di hub. Alur jaringan lainnya sama dengan diagram sebelumnya.

Diagram terdiri dari dua bagian utama, jaringan virtual hub dan jaringan virtual spoke. Panah biru mewakili perjalanan permintaan klien dari lokal ke VM aplikasi. Panah biru dimulai di klien on-premise dan mengarah ke subnet gerbang jaringan virtual di jaringan virtual hub. Panah biru berlanjut dari subnet gateway jaringan virtual ke subnet Application Gateway di jaringan virtual spoke. Kemudian menunjuk ke subnet Azure Firewall di jaringan virtual hub dan berlanjut ke subnet aplikasi di jaringan virtual spoke. Panah dua sisi berlabel jaringan virtual peering menghubungkan jaringan virtual hub dan segmen jaringan virtual spoke. Panah hijau mewakili perjalanan permintaan klien dari VM aplikasi kembali ke klien lokal. Panah hijau dimulai di VM aplikasi dan menunjuk ke subnet Azure Firewall. Kemudian menunjuk ke subnet Application Gateway, ke gateway jaringan virtual, lalu ke klien.

1. Klien lokal tersambung ke gateway jaringan virtual.

2. Gateway jaringan virtual meneruskan paket klien ke Application Gateway.

3. Application Gateway memeriksa paket. Jika mereka lulus inspeksi, UDR di subnet Application Gateway meneruskan paket ke Azure Firewall Premium.

4. Azure Firewall Premium menjalankan pemeriksaan keamanan pada paket. Jika mereka lulus pengujian, Azure Firewall Premium meneruskan paket ke VM aplikasi.

5. VM merespons dan mengatur alamat IP tujuan ke Application Gateway. UDR di subnet VM mengalihkan paket ke Azure Firewall Premium.

6. Azure Firewall Premium meneruskan paket ke Application Gateway.

7. Application Gateway mengirimkan paket ke gateway jaringan virtual.

8. Gateway jaringan virtual menjawab klien.

Topologi Virtual WAN

Anda juga dapat menggunakan layanan jaringan Virtual WAN dalam arsitektur ini. Komponen ini memberikan banyak manfaat. Misalnya, ini menghilangkan kebutuhan akan UDR yang dikelola pengguna di jaringan virtual spoke. Anda dapat menentukan rute statis dalam tabel rute hub virtual sebagai gantinya. Pemrograman setiap jaringan virtual yang Anda sambungkan ke hub kemudian berisi rute ini.

Saat Anda menggunakan Virtual WAN sebagai platform jaringan, dua perbedaan utama menghasilkan:

• Anda tidak dapat menautkan zona privat DNS ke hub virtual karena Microsoft mengelola hub virtual. Sebagai pemilik langganan, Anda tidak memiliki izin untuk menautkan zona DNS privat. Akibatnya, Anda tidak dapat mengaitkan zona privat DNS dengan hub aman yang berisi Azure Firewall Premium.

  Untuk menerapkan resolusi DNS untuk Azure Firewall Premium, gunakan server DNS sebagai gantinya:

  • Konfigurasikan pengaturan DNS Azure Firewall untuk menggunakan server DNS kustom.

  • Sebarkan server di jaringan virtual layanan bersama yang Anda sambungkan ke WAN virtual.

  • Tautkan zona privat DNS ke jaringan virtual layanan bersama. Server DNS kemudian dapat mengatasi nama yang digunakan Application Gateway di header Host HTTP. Untuk informasi selengkapnya, lihat Pengaturan DNS Azure Firewall.

• Anda hanya dapat menggunakan Virtual WAN untuk memprogram rute dalam spoke jika awalan lebih pendek (kurang spesifik) daripada awalan jaringan virtual. Misalnya, dalam diagram sebelumnya, jaringan virtual spoke memiliki awalan 172.16.0.0/16. Dalam hal ini, Virtual WAN tidak dapat menyuntikkan rute yang cocok dengan awalan jaringan virtual (172.16.0.0/16) atau subnet apa pun (172.16.0.0/24, 172.16.1.0/24). Dengan kata lain, Virtual WAN tidak dapat mengarahkan lalu lintas antara dua subnet yang berada di jaringan virtual yang sama.

  Batasan ini menjadi jelas ketika Application Gateway dan server web tujuan berada di jaringan virtual yang sama. Virtual WAN tidak dapat memaksa lalu lintas antara Application Gateway dan server web untuk melalui Azure Firewall Premium. Salah satu solusinya adalah mengonfigurasi UDR secara manual di Application Gateway dan subnet server web.

Diagram berikut menunjukkan alur paket dalam arsitektur yang menggunakan Virtual WAN. Dalam skenario ini, akses ke Application Gateway berasal dari jaringan lokal. VPN situs-ke-situs atau instans ExpressRoute menghubungkan jaringan tersebut ke Virtual WAN. Akses berbasis internet mengikuti jalur serupa.

Diagram ini terdiri dari empat bagian, jaringan virtual hub, jaringan virtual Application Gateway, jaringan virtual aplikasi, dan jaringan virtual layanan bersama. Panah biru mewakili perjalanan permintaan klien dari lokal ke VM aplikasi. Panah biru dimulai di klien lokal dan menunjuk ke gateway VPN di jaringan virtual hub. Panah biru kemudian menunjuk dari gateway VPN ke subnet Application Gateway di jaringan virtual Application Gateway. Ini berlanjut dari subnet Application Gateway ke ikon yang mewakili Azure Firewall Premium di jaringan virtual hub. Kemudian menunjuk dari ikon Azure Firewall Premium ke subnet DNS di jaringan virtual layanan bersama. Panah hijau mewakili perjalanan permintaan klien kembali ke klien lokal. Panah hijau dimulai di subnet DNS dan menunjuk ke ikon Azure Firewall Premium di jaringan virtual hub. Panah biru mewakili paket yang melewati pemeriksaan keamanan Azure Firewall Premium. Ini menunjuk ke VM aplikasi di jaringan virtual aplikasi. Panah hijau menunjuk kembali ke Azure Firewall Premium dan melanjutkan subnet Application Gateway, lalu gateway VPN, dan akhirnya kembali ke klien.

1. Klien lokal tersambung ke gateway VPN.

2. Gateway VPN meneruskan paket klien ke Application Gateway.

3. Application Gateway memeriksa paket. Jika mereka lulus inspeksi, subnet Application Gateway meneruskan paket ke Azure Firewall Premium.

4. Azure Firewall Premium meminta resolusi DNS dari server DNS di jaringan virtual layanan bersama.

5. Server DNS menjawab permintaan resolusi.

6. Azure Firewall Premium menjalankan pemeriksaan keamanan pada paket. Jika mereka lulus pengujian, Azure Firewall Premium meneruskan paket ke VM aplikasi.

7. VM merespons dan mengatur alamat IP tujuan ke Application Gateway. Subnet aplikasi mengalihkan paket ke Azure Firewall Premium.

8. Azure Firewall Premium meneruskan paket ke Application Gateway.

9. Application Gateway mengirimkan paket ke gateway VPN.

10. Gateway VPN menjawab klien.

Jika Anda menggunakan desain ini, Anda mungkin perlu memodifikasi perutean yang diiklankan hub ke jaringan virtual spoke. Secara khusus, Application Gateway v2 hanya mendukung rute 0.0.0.0/0 yang menunjuk ke internet. Rute dengan alamat ini yang tidak menunjuk ke internet merusak konektivitas yang diperlukan Microsoft untuk mengelola Application Gateway. Jika hub virtual Anda mengiklankan 0.0.0.0/0 rute, cegah rute tersebut menyebar ke subnet Application Gateway dengan mengambil salah satu langkah berikut:

• Buat tabel rute yang memiliki rute untuk 0.0.0.0/0 dan jenis lompatan berikutnya adalah Internet. Kaitkan rute tersebut dengan subnet tempat Anda menyebarkan Application Gateway.

• Jika Anda menyebarkan Application Gateway di spoke khusus, nonaktifkan penyebaran rute default di pengaturan untuk koneksi jaringan virtual.

Topologi Route Server

Route Server menyediakan cara lain untuk menyuntikkan rute secara otomatis dalam spoke. Gunakan fungsionalitas ini untuk menghindari overhead administratif untuk mempertahankan tabel rute. Route Server menggabungkan varian Virtual WAN dan hub dan spoke:

• Anda dapat menggunakan Route Server untuk mengelola jaringan virtual hub. Akibatnya, Anda dapat menautkan jaringan virtual hub ke zona privat DNS.

• Route Server memiliki batasan yang sama dengan virtual WAN mengenai awalan alamat IP. Anda hanya dapat menyuntikkan rute ke spoke jika awalan lebih pendek (kurang spesifik) daripada awalan jaringan virtual. Karena keterbatasan ini, Application Gateway dan server web tujuan harus berada di jaringan virtual yang berbeda.

Diagram berikut menunjukkan alur paket saat Route Server menyederhanakan perutean dinamis. Pertimbangkan poin-poin berikut:

• Route Server saat ini memerlukan perangkat yang menyuntikkan rute untuk mengirimnya melalui Border Gateway Protocol (BGP). Azure Firewall Premium tidak mendukung BGP, jadi gunakan appliance virtual jaringan non-Microsoft (NVA) sebagai gantinya.

• Fungsionalitas NVA di hub menentukan apakah implementasi Anda membutuhkan DNS.

Diagram ini terdiri dari empat bagian, jaringan virtual hub, jaringan virtual Application Gateway, jaringan virtual aplikasi, dan jaringan virtual layanan bersama. Jaringan virtual hub berisi tiga kotak yang mewakili subnet gateway jaringan virtual, subnet Route Server, dan subnet NVA. Panah biru mewakili perjalanan permintaan klien dari lokal ke VM aplikasi. Panah biru dimulai di klien lokal dan menunjuk ke gateway jaringan virtual di bagian jaringan virtual hub. Panah biru kemudian menunjuk ke subnet Application Gateway di jaringan virtual Application Gateway. Panah biru berlanjut ke subnet NVA di jaringan virtual hub. Kemudian, subnet NVA diarahkan ke subnet DNS di jaringan virtual layanan bersama. Panah hijau mewakili perjalanan permintaan klien kembali ke klien lokal. Ini dimulai pada subnet DNS dan menunjuk ke subnet NVA di jaringan virtual hub. Panah biru mewakili paket yang melewati pemeriksaan keamanan NVA. Ini menunjuk ke VM aplikasi di jaringan virtual aplikasi. Panah hijau menunjuk kembali ke subnet NVA dan melanjutkan subnet Application Gateway, lalu ke gateway jaringan virtual, dan akhirnya kembali ke klien.

1. Klien lokal tersambung ke gateway jaringan virtual.

2. Gateway jaringan virtual meneruskan paket klien ke Application Gateway.

3. Application Gateway memeriksa paket. Jika mereka melewati inspeksi, subnet Application Gateway meneruskan paket ke komputer back-end. Route Server menyuntikkan rute di subnet Application Gateway yang meneruskan lalu lintas ke NVA.

4. Subnet NVA meminta resolusi DNS dari server DNS di jaringan virtual layanan bersama.

5. Server DNS menjawab permintaan resolusi.

6. NVA menjalankan pemeriksaan keamanan pada paket. Jika mereka lulus pengujian, NVA meneruskan paket ke VM aplikasi.

7. VM aplikasi merespons dan mengatur alamat IP tujuan ke Application Gateway. Route Server menyuntikkan rute di subnet VM yang mengalihkan paket ke NVA.

8. NVA meneruskan paket ke Application Gateway.

9. Application Gateway mengirimkan paket ke gateway jaringan virtual.

10. Gateway jaringan virtual menjawab klien.

Seperti dengan Virtual WAN, Anda mungkin perlu memodifikasi perutean ketika Anda menggunakan Route Server. Jika Anda mengiklankan 0.0.0.0/0 rute, rute tersebut mungkin disebarluaskan ke subnet Application Gateway. Tetapi Application Gateway tidak mendukung rute tersebut. Dalam hal ini, konfigurasikan tabel rute untuk subnet Application Gateway. Sertakan rute untuk 0.0.0.0/0 dan jenis lompatan berikutnya Internet dalam tabel tersebut.

IDPS dan alamat IP privat

Azure Firewall Premium memutuskan aturan IDPS mana yang akan diterapkan berdasarkan alamat IP sumber dan tujuan paket. Secara default, Azure Firewall memperlakukan alamat IP privat dalam rentang RFC 1918 (10.0.0.0/8, , dan 192.168.0.0/16) dan rentang RFC 6598 (172.16.0.0/12100.64.0.0/10) sebagai internal. Jadi, jika Anda menyebarkan Application Gateway di subnet di salah satu rentang ini, Azure Firewall Premium menganggap lalu lintas antara Application Gateway dan beban kerja menjadi internal. Oleh karena itu, hanya tanda tangan IDPS yang ditandai untuk diterapkan pada lalu lintas internal atau lalu lintas apa pun yang digunakan. Tanda tangan IDPS yang ditandai untuk diterapkan pada lalu lintas yang masuk atau keluar tidak diterapkan pada komunikasi antara Application Gateway dan beban kerja. Untuk informasi selengkapnya, lihat Aturan IDPS Azure Firewall.

Cara termudah untuk memaksa aturan tanda tangan masuk IDPS diterapkan pada lalu lintas antara Application Gateway dan beban kerja adalah dengan menempatkan Application Gateway dalam subnet yang menggunakan awalan di luar rentang pribadi. Anda tidak perlu menggunakan alamat IP publik untuk subnet ini. Sebagai gantinya, Anda dapat menyesuaikan alamat IP yang dianggap sebagai internal oleh Azure Firewall Premium untuk IDPS. Misalnya, jika organisasi Anda tidak menggunakan rentang 100.64.0.0/10, Anda dapat menghapus rentang ini dari daftar awalan internal untuk IDPS dan menerapkan Application Gateway pada subnet dengan alamat IP yang dikonfigurasi di 100.64.0.0/10. Untuk informasi selengkapnya, lihat Rentang IPDS privat Azure Firewall Premium.

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 selanjutnya

• Mengamankan jaringan dengan Zero Trust
• Perutean lalu lintas jaringan virtual
• Cara kerja gateway aplikasi

Sumber daya terkait

• Mengimplementasikan jaringan hibrida yang aman
• Topologi jaringan hub-spoke di Azure
• Topologi jaringan hub-spoke yang menggunakan Virtual WAN