Bagikan melalui

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

Azure Application Gateway
Azure Firewall
Microsoft 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 end-to-end. 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 tanpa kepercayaan lainnya untuk aspek lebih lanjut dalam menyebarkan aplikasi Anda dengan aman, seperti autentikasi dan otorisasi. Untuk tujuan artikel ini, pendekatan multilayer berfungsi paling baik, di mana 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.

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 berfokus 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 di 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. Ini berjalan dengan penambahan opsional Azure Web Application Firewall.

  • 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.

  • Azure Firewall Premium menjalankan pemeriksaan keamanan:

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

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

Berbagai mesin inspeksi dalam arsitektur ini memastikan integritas lalu lintas:

  • Web Application Firewall menggunakan aturan untuk mencegah serangan pada lapisan web. Contoh serangan termasuk injeksi kode SQL dan scripting lintas situs. Untuk informasi selengkapnya tentang aturan dan Seperangkat Aturan Inti Open Web Application Security Project (OWASP), lihat grup aturan dan aturan CRS Web Application Firewall.
  • 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 berbagai jenis desain jaringan, 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 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 bagian selanjutnya.

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 non-standar.

Sertifikat digital

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

diagram Arsitektur memperlihatkan nama umum dan otoritas sertifikat yang digunakan jaringan aplikasi web saat load balancer berada di depan firewall.

Fakta bahwa Azure Firewall menghasilkan sertifikatnya sendiri dengan cepat adalah salah satu alasan utama mengapa itu ditempatkan di belakang Application Gateway, karena jika tidak, klien aplikasi akan dihadapkan dengan sertifikat yang dihasilkan sendiri ini yang akan ditandai sebagai risiko keamanan.

Koneksi TLS

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

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 otoritas sertifikat PKI 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 telah ditandatangani CA publik. Gunakan CA yang akan 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 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 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 X-Forwarded-For yang disisipkan oleh Application Gateway. Azure Firewall juga mendukung menyuntikkan alamat IP klien sumber di X-Forwarded-For header, dalam hal ini alamat IP gateway aplikasi.
  • Lalu lintas dari Application Gateway ke beban kerja biasanya dikirim ke Azure Firewall menggunakan mekanisme perutean Azure, baik dengan User-Defined Rute 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 mengambil beberapa fungsionalitas asli Azure Application Gateway seperti penyeimbangan beban dan kelekatan sesi.

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 dalam 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 di jaringan virtual spoke:

  • Mungkin sulit untuk memecahkan masalah pemberitahuan 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 Azure Application Gateway .
  • Anda mungkin menghadapi masalah kontrol akses berbasis peran jika Anda menyebarkan 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 bahwa catatan A ada untuk nilai yang digunakan Application Gateway untuk lalu lintas dan untuk pemeriksaan kesehatan.

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

diagram Arsitektur memperlihatkan alur 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 melewati inspeksi, Application Gateway akan mengirim paket ke VM backend. Saat paket mengenai 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 pengujian, Azure Firewall Premium meneruskan paket ke VM aplikasi.
  4. VM merespons dan mengatur alamat IP tujuan ke Application Gateway. 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. Arus lalu lintas baik melalui jaringan privat virtual situs-ke-situs (VPN) 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 memperlihatkan alur paket di hub dan jaringan spoke dengan load balancer dan firewall. Klien terhubung dari jaringan lokal.

  1. Klien lokal tersambung ke gateway jaringan virtual.
  2. Gateway 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 menjawab klien.

Topologi Virtual WAN

Anda juga dapat menggunakan layanan jaringan Virtual WAN dalam arsitektur ini. Komponen ini menawarkan 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 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 alur 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 memperlihatkan alur paket di jaringan hub dan spoke yang mencakup load balancer, firewall, dan Virtual WAN.

  1. Klien lokal tersambung ke VPN.
  2. 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 VPN.
  10. VPN menjawab klien.

Dengan 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 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 hop berikutnya 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 menawarkan cara lain untuk menyuntikkan rute secara otomatis dalam spoke. Dengan fungsionalitas ini, Anda menghindari overhead administratif untuk mempertahankan tabel rute. Route Server menggabungkan varian Virtual WAN dan hub dan 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 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. Perhatikan poin-poin ini:

  • Route Server saat ini memerlukan 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 membutuhkan DNS.

diagram Arsitektur memperlihatkan alur paket di jaringan hub dan spoke yang mencakup load balancer, firewall, dan Route Server.

  1. Klien lokal tersambung ke gateway jaringan virtual.
  2. Gateway meneruskan paket klien ke Application Gateway.
  3. Application Gateway memeriksa paket. Jika mereka lulus inspeksi, subnet Application Gateway meneruskan paket ke komputer backend. Rute di subnet ApplicationGateway yang disuntikkan oleh Route Server akan meneruskan lalu lintas ke NVA.
  4. NVA menjalankan pemeriksaan keamanan pada paket. Jika mereka lulus pengujian, NVA meneruskan paket ke VM aplikasi.
  5. VM merespons dan mengatur alamat IP tujuan ke Application Gateway. Rute yang disuntikkan di subnet VM 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 halnya Virtual WAN, Anda mungkin perlu memodifikasi perutean saat menggunakan Route Server. Jika Anda mengiklankan rute 0.0.0.0/0, 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 hop berikutnya dari Internet 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 di 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 ke lalu lintas internal atau ke 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 rentang 100.64.0.0/10, 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 dalam 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