Edit

Jaringan zero trust untuk aplikasi web dengan Azure Firewall dan Application Gateway

Azure Application Gateway
Azure Firewall
Azure Virtual Network
Azure Virtual WAN
Azure Web Application Firewall

Panduan ini menguraikan strategi untuk menerapkan keamanan tanpa kepercayaan untuk aplikasi web untuk inspeksi dan enkripsi. Paradigma zero-trust mencakup banyak konsep lain, seperti verifikasi konstan identitas aktor atau mengurangi ukuran area kepercayaan implisit seminimal mungkin. Artikel ini mengacu pada komponen enkripsi dan inspeksi arsitektur zero-trust untuk lalu lintas masuk dari Internet publik. Silakan baca dokumen zero-trust lainnya untuk aspek penyebaran aplikasi Anda dengan aman, seperti autentikasi. Untuk tujuan artikel ini, pendekatan multilayer berfungsi paling baik, di mana keamanan jaringan membentuk salah satu lapisan model zero-trust. Pada lapisan ini, appliance jaringan memeriksa paket untuk memastikan bahwa hanya lalu lintas yang sah yang mencapai aplikasi.

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

  • Firewall aplikasi web mencari pola yang menunjukkan serangan pada lapisan aplikasi web.
  • Firewall generasi berikutnya juga dapat mencari ancaman generik.

Dalam beberapa situasi, Anda dapat menggabungkan berbagai jenis appliance keamanan jaringan untuk meningkatkan perlindungan. Panduan terpisah, Firewall dan Application Gateway untuk jaringan virtual, menjelaskan pola desain yang dapat Anda gunakan untuk mengatur berbagai appliance. Dokumen ini fokus pada pola umum untuk memaksimalkan keamanan, di mana Azure Application Gateway bertindak sebelum Azure Firewall Premium. Diagram berikut mengilustrasikan pola ini:

Diagram arsitektur memperlihatkan alur paket dalam jaringan aplikasi web yang menggunakan Application Gateway di depan Azure Firewall Premium.

Unduh file Visio arsitektur ini.

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

  • Klien mengirim paket ke Application Gateway, load balancer. Application Gateway menjalankannya dengan tambahan opsi Azure Web Application Firewall.

  • Application Gateway mendekripsi paket dan mencari ancaman terhadap aplikasi web. Jika tidak menemukan ancaman, Application Gateway menggunakan prinsip zero trust untuk mengenkripsi paket. Kemudian Application Gateway melepaskannya.

  • Azure Firewall Premium menjalankan pemeriksaan keamanan:

  • Jika paket lulus tes, Azure Firewall Premium mengambil langkah ini:

    • Mengenkripsi paket
    • Menggunakan layanan Sistem Nama Domain (DNS) untuk menentukan mesin virtual (VM) aplikasi
    • Meneruskan paket ke VM aplikasi

Berbagai mesin inspeksi dalam arsitektur ini memastikan integritas lalu lintas:

  • 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 Open Web Application Security Project (OWASP) Core Rule Set, lihat Aturan dan kelompok aturan Web Application Firewall CRS.
  • Azure Firewall Premium menggunakan aturan deteksi dan pencegahan intrusi generik. Aturan-aturan ini membantu mengidentifikasi file berbahaya dan ancaman lain yang menargetkan aplikasi web.

Arsitektur ini mendukung berbagai jenis desain jaringan, yang artikel ini bahas:

  • Hub tradisional dan jaringan spoke
  • 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 memeriksa lalu lintas berbahaya, Azure Firewall Premium memverifikasi bahwa header HOST HTTP cocok dengan alamat IP paket dan port 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, seperti yang dijelaskan oleh bagian selanjutnya.

Catatan

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 oleh sesi dan sertifikat TLS arsitektur:

Diagram arsitektur yang menunjukkan nama umum dan otoritas sertifikat yang digunakan jaringan aplikasi web saat load balancer berada di depan firewall.

Koneksi TLS

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

Dari klien ke Application Gateway

Di Application Gateway, Anda menerapkan sertifikat digital yang dilihat klien. CA yang dikenal baik seperti DigiCert atau Let's Encrypt biasanya mengeluarkan sertifikat semacam itu.

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 menampilkan dirinya ke Application Gateway sebagai server web. CA pribadi 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 yang dikenal baik menyetujui 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 terbaik. Application Gateway melindungi server web dari klien berbahaya dengan mencegat permintaan HTTP dan HTTPS. Anda mendeklarasikan setiap server yang dilindungi yang ada di kumpulan ujung akhir Application Gateway dengan alamat IP atau nama domain yang memenuhi syarat sepenuhnya. Klien yang sah harus dapat mengakses setiap aplikasi. Jadi Anda mengonfigurasi Application Gateway dengan sertifikat digital yang telah ditandatangani oleh CA publik. Gunakan CA yang akan diterima semua klien TLS.
  • Azure Firewall Premium adalah proksi web maju atau, sederhananya, proksi web. Azure Firewall Premium melindungi klien dari server web berbahaya dengan mencegat panggilan TLS dari klien yang dilindungi. Ketika klien yang dilindungi membuat permintaan HTTP, proksi maju meniru server web target dengan menghasilkan 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 memercayai CA privat tersebut. Dalam arsitektur ini, Azure Firewall Premium melindungi permintaan dari Application Gateway ke server web. Application Gateway mempercayai CA pribadi yang digunakan Azure Firewall Premium.

Perutean dan penerusan lalu lintas

Perutean akan sedikit berbeda tergantung pada topologi desain jaringan Anda, bagian berikut akan merinci spesifikasi contoh topologi Hub dan Spoke, Virtual WAN, dan Route Server. Namun, ada beberapa aspek yang umum untuk semua topologi:

  • Azure Application Gateway selalu berulah sebagai proksi, dan Azure Firewall Premium juga melakukannya ketika dikonfigurasi untuk inspeksi TLS: sesi TLS dari klien akan dihentikan oleh Application Gateway, dan sesi TLS baru akan dibangun menuju Azure Firewall. Azure Firewall akan menerima dan mengakhiri sesi TLS yang bersumber dari Application Gateway, dan membangun sesi TLS baru menuju beban kerja. Fakta ini memiliki implikasi untuk konfigurasi IDPS Azure Firewall Premium, bagian lebih lanjut di bawah ini berisi detail selengkapnya tentang hal ini.
  • Beban kerja akan melihat koneksi yang berasal dari alamat IP subnet Azure Firewall. Alamat IP klien asli dipertahankan di header HTTP yang X-Forwarded-For disisipkan oleh Application Gateway.
  • Lalu lintas dari Application Gateway ke beban kerja biasanya dikirim ke Azure Firewall menggunakan mekanisme perutean Azure, baik dengan Rute yang Ditentukan Pengguna yang dikonfigurasi di subnet Application Gateway atau dengan rute yang disuntikkan oleh Azure Virtual WAN atau Azure Route Server. Meskipun secara eksplisit mendefinisikan alamat IP privat Azure Firewall di kumpulan backend Application Gateway dimungkinkan, secara teknis tidak disarankan karena menghilangkan beberapa fungsionalitas Azure Firewall seperti penyeimbangan beban dan kelengketan.

Bagian berikut masuk ke detail untuk beberapa topologi paling umum yang digunakan dengan Azure Firewall dan Application Gateway.

Topologi hub dan spoke

Biasanya, desain hub dan spoke menyebarkan komponen jaringan bersama di jaringan virtual hub dan komponen khusus aplikasi di spoke. Di sebagian besar sistem, Azure Firewall Premium adalah sumber daya bersama. Tetapi Web Application Firewall dapat menjadi perangkat jaringan bersama atau komponen khusus aplikasi. Untuk alasan berikut, biasanya yang terbaik adalah memperlakukan Application Gateway sebagai komponen aplikasi dan menyebarkannya dalam jaringan virtual spoke:

  • Mungkin sulit untuk memecahkan masalah peringatan Web Application Firewall. Anda biasanya 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 Azure Application Gateway.
  • Anda mungkin menghadapi masalah kontrol akses berbasis peran jika menerapkan Application Gateway di hub. Situasi ini dapat muncul ketika tim mengelola aplikasi yang berbeda tetapi menggunakan instans Application Gateway yang sama. Setiap tim kemudian memiliki akses ke seluruh konfigurasi Application Gateway.

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

  • Mengonfigurasi zona privat DNS.
  • Tautkan zona ke jaringan virtual yang berisi Azure Firewall Premium.
  • Pastikan ada catatan A untuk nilai yang digunakan Application Gateway untuk lalu lintas dan pemeriksaan kesehatan.

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

Diagram arsitektur yang menunjukkan aliran paket di hub dan jaringan spoke dengan load balancer dan firewall. Klien terhubung dari internet publik.

  1. Klien mengirimkan permintaan ke server web.
  2. Application Gateway mencegat paket klien dan memeriksanya. Jika paket lulus inspeksi, Application Gateway akan mengirim paket ke mesin virtual backend. Jika paket sampai di Azure, rute yang ditentukan pengguna (UDR) di subnet Application Gateway meneruskan paket ke Azure Firewall Premium.
  3. Azure Firewall Premium menjalankan pemeriksaan keamanan pada paket. Jika mereka lulus tes, Azure Firewall Premium meneruskan paket ke VM aplikasi.
  4. Mesin virtual merespons dan menetapkan alamat IP tujuan ke Application Gateway. UDR di subnet mesin virtual 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, bukan internet publik. Lalu lintas mengalir baik melalui jaringan privat maya (VPN) situs-ke-situs atau melalui ExpressRoute. Dalam skenario ini, lalu lintas pertama kali mencapai gateway jaringan virtual di hub. Sisa aliran jaringan sama dengan kasus sebelumnya.

Diagram arsitektur yang menunjukkan aliran paket di hub dan jaringan spoke dengan load balancer dan firewall. Klien terhubung dari jaringan lokal.

  1. Klien lokal terhubung ke gateway jaringan virtual.
  2. Gateway meneruskan paket klien ke Application Gateway.
  3. Application Gateway memeriksa paket. Jika 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 tes, Azure Firewall Premium meneruskan paket ke VM aplikasi.
  5. VM merespons dan menetapkan alamat IP tujuan ke Application Gateway. UDR di subnet mesin virtual 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 menjawab klien.

Topologi Virtual WAN

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

Ketika Anda menggunakan Virtual WAN sebagai platform jaringan, dua perbedaan utama dihasilkan:

  • Anda tidak dapat menautkan zona pribadi 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 pribadi 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 khusus.
    • Sebarkan server di jaringan virtual layanan bersama yang Anda hubungkan ke Virtual WAN.
    • Tautkan zona privat DNS ke jaringan virtual layanan bersama. Server DNS kemudian dapat menyelesaikan 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 prefiks lebih pendek (kurang spesifik) dari prefiks jaringan virtual. Misalnya, dalam diagram di atas spoke VNet memiliki awalan 172.16.0.0/16: dalam hal ini, Virtual WAN tidak akan dapat menyuntikkan rute yang cocok dengan awalan VNet (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 menarik lalu lintas antara dua subnet yang berada di VNet 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 (solusinya akan mengonfigurasi Rute yang Ditentukan Pengguna secara manual di subnet Application Gateway dan server web).

Diagram berikut menunjukkan aliran paket dalam kasus yang menggunakan Virtual WAN. Dalam situasi ini, akses ke Application Gateway berasal dari jaringan lokal. VPN situs-ke-situs atau ExpressRoute menghubungkan jaringan tersebut ke Virtual WAN. Akses dari internet serupa.

Diagram arsitektur yang menunjukkan aliran paket di hub dan jaringan spoke yang mencakup load balancer, firewall, dan Virtual WAN.

  1. Klien lokal terhubung ke VPN.
  2. VPN meneruskan paket klien ke Application Gateway.
  3. Application Gateway memeriksa paket. Jika 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 permitaan resolusi.
  6. Azure Firewall Premium menjalankan pemeriksaan keamanan pada paket. Jika mereka lulus tes, Azure Firewall Premium meneruskan paket ke VM aplikasi.
  7. VM merespons dan menetapkan 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 VPN.
  10. VPN menjawab klien.

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

  • Buat tabel rute dengan rute untuk 0.0.0.0/0 dan jenis Internet hop berikutnya. Kaitkan rute itu dengan subnet tempat Anda menerapkan Application Gateway.
  • Jika Anda menerapkan Application Gateway dalam spoke khusus, nonaktifkan penyebaran rute default di pengaturan untuk koneksi jaringan virtual.

Topologi Route Server

Route Server menawarkan cara lain untuk menyuntikkan rute secara otomatis dalam spoke. Dengan fungsi ini, Anda menghindari overhead administratif pemeliharaan tabel rute. Route Server menggabungkan varian Virtual WAN dan hub and spoke:

  • Dengan Route Server, pelanggan mengelola jaringan virtual hub. Akibatnya, Anda dapat menautkan jaringan virtual hub ke zona privat DNS.
  • Route Server memiliki batasan yang sama dengan Virtual WAN terkait prefiks alamat IP. Anda hanya dapat menyuntikkan rute ke spoke jika awalan lebih pendek (kurang spesifik) daripada awalan jaringan virtual. Karena batasan ini, Application Gateway dan server web tujuan harus berada di jaringan virtual yang berbeda.

Diagram berikut menunjukkan aliran paket saat Route Server menyederhanakan perutean dinamis. Perhatikan poin-poin ini:

  • Route Server saat ini membutuhkan perangkat yang menyuntikkan rute untuk mengirimnya melalui Border Gateway Protocol (BGP). Karena Azure Firewall Premium tidak mendukung BGP, gunakan Network Virtual Appliance (NVA) pihak ketiga sebagai gantinya.
  • Fungsionalitas NVA di hub menentukan apakah implementasi Anda memerlukan DNS.

Diagram arsitektur yang menunjukkan aliran paket di hub dan jaringan spoke yang mencakup load balancer, firewall, dan Route Server.

  1. Klien lokal terhubung ke gateway jaringan virtual.
  2. Gateway meneruskan paket klien ke Application Gateway.
  3. Application Gateway memeriksa paket. Jika lulus inspeksi, subnet Application Gateway meneruskan paket ke mesin backend. Rute di subnet Application Gateway yang disuntikkan oleh Route Server akan meneruskan lalu lintas ke NVA.
  4. NVA menjalankan pemeriksaan keamanan pada paket. Jika mereka lulus tes, NVA meneruskan paket ke VM aplikasi.
  5. VM merespons dan menetapkan alamat IP tujuan ke Application Gateway. Rute yang disuntikkan dalam subnet mesin virtual oleh Route Server mengalihkan paket ke NVA.
  6. NVA meneruskan paket ke Application Gateway.
  7. Application Gateway mengirimkan paket ke gateway jaringan virtual.
  8. Gateway menjawab klien.

Seperti Virtual WAN, Anda mungkin perlu mengubah perutean saat menggunakan Route Server. Jika Anda mengiklankan rute 0.0.0.0/0, hal tersebut mungkin menyebar 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 Internet hop berikutnya dalam tabel tersebut.

IDPS dan alamat IP privat

Seperti yang dijelaskan dalam Aturan IDPS Azure Firewall, Azure Firewall Premium akan memutuskan aturan IDPS mana yang akan diterapkan tergantung pada alamat IP sumber dan tujuan paket. Azure Firewall akan memperlakukan per alamat IP privat default dalam rentang RFC 1918 (10.0.0.0/8, 192.168.0.0/16 dan 172.16.0.0/12) dan rentang RFC 6598 (100.64.0.0/10) sebagai internal. Akibatnya, jika seperti dalam diagram dalam artikel ini Application Gateway disebarkan dalam subnet dalam salah satu rentang ini (172.16.0.0/24 dalam contoh di atas), Azure Firewall Premium akan mempertimbangkan lalu lintas antara Application Gateway dan beban kerja menjadi internal, dan hanya tanda tangan IDPS yang ditandai untuk diterapkan pada lalu lintas internal atau lalu lintas apa pun yang akan digunakan. Tanda tangan IDPS yang ditandai untuk diterapkan untuk lalu lintas masuk atau keluar tidak akan diterapkan pada lalu lintas antara Application Gateway dan beban kerja.

Cara term mudah untuk memaksa aturan tanda tangan masuk IDPS diterapkan ke lalu lintas antara Application Gateway dan beban kerja adalah dengan menempatkan Application Gateway dalam subnet dengan awalan di luar rentang privat. Anda tidak perlu menggunakan alamat IP publik untuk subnet ini, tetapi sebagai gantinya Anda dapat menyesuaikan alamat IP yang diperlakukan Azure Firewall Premium sebagai internal untuk IDPS. Misalnya, jika organisasi Anda tidak menggunakan 100.64.0.0/10 rentang, Anda dapat menghilangkan rentang ini dari daftar awalan internal untuk IDPS (lihat Rentang IPDS privat Azure Firewall Premium untuk detail selengkapnya tentang cara melakukannya) dan menyebarkan Application Gateway di subnet yang dikonfigurasi dengan alamat IP di 100.64.0.0/10.

Kontributor

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

Penulis utama:

Langkah berikutnya