Bagikan melalui

Jaringan dan konektivitas untuk beban kerja misi penting di Azure

  • Artikel

Jaringan adalah area mendasar untuk aplikasi misi penting, mengingat pendekatan desain aktif-aktif yang didistribusikan secara global yang direkomendasikan.

Area desain ini mengeksplorasi berbagai topik topologi jaringan pada tingkat aplikasi, mempertimbangkan konektivitas yang diperlukan dan manajemen lalu lintas yang berlebihan. Lebih khusus lagi, ini menyoroti pertimbangan dan rekomendasi penting yang dimaksudkan untuk menginformasikan desain topologi jaringan global yang aman dan dapat diskalakan untuk aplikasi misi penting.

Penting

Artikel ini adalah bagian dari seri beban kerja misi penting Azure Well-Architected. Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan apa itu beban kerja misi penting?

Perutean lalu lintas global

Penggunaan beberapa stempel penyebaran regional aktif memerlukan layanan perutean global untuk mendistribusikan lalu lintas ke setiap stempel aktif.

Azure Front Door, Azure Traffic Manager, dan Azure Standard Load Balancer menyediakan kemampuan perutean yang diperlukan untuk mengelola lalu lintas global di seluruh aplikasi multi-wilayah.

Atau, teknologi perutean global pihak ketiga dapat dipertimbangkan. Opsi ini hampir dapat ditukar dengan mulus untuk menggantikan atau memperluas penggunaan layanan perutean global asli Azure. Pilihan populer termasuk teknologi perutean oleh penyedia CDN.

Bagian ini menjelajahi perbedaan utama layanan perutean Azure untuk menentukan bagaimana masing-masing dapat digunakan untuk mengoptimalkan skenario yang berbeda.

Pertimbangan Desain

  • Layanan perutean yang terikat ke satu wilayah mewakili satu titik kegagalan dan risiko signifikan sehubungan dengan pemadaman regional.

  • Jika beban kerja aplikasi mencakup kontrol klien, seperti dengan aplikasi klien seluler atau desktop, dimungkinkan untuk menyediakan redundansi layanan dalam logika perutean klien.

    • Beberapa teknologi perutean global, seperti Azure Front Door dan Azure Traffic Manager, dapat dipertimbangkan secara paralel untuk redundansi, dengan klien dikonfigurasi untuk melakukan failover ke teknologi alternatif ketika kondisi kegagalan tertentu terpenuhi. Pengenalan beberapa layanan perutean global memperkenalkan kompleksitas yang signifikan seputar cache tepi dan kemampuan Web Application Firewall, dan manajemen sertifikat untuk offload SSL dan validasi aplikasi untuk jalur masuk.
    • Teknologi pihak ketiga juga dapat dipertimbangkan, memberikan ketahanan perutean global ke semua tingkat kegagalan platform Azure.

  • Perbedaan kemampuan antara Azure Front Door dan Traffic Manager berarti bahwa jika kedua teknologi diposisikan bersama satu sama lain untuk redundansi, jalur masuk atau perubahan desain yang berbeda akan diperlukan untuk memastikan tingkat layanan yang konsisten dan dapat diterima dipertahankan.

  • Azure Front Door dan Azure Traffic Manager adalah layanan terdistribusi secara global dengan redundansi dan ketersediaan multi-wilayah bawaan.

    • Skenario kegagalan hipotetis dari skala yang cukup besar untuk mengancam ketersediaan global layanan perutean tangguh ini memberikan risiko yang lebih luas bagi aplikasi dalam hal kegagalan berjenjang dan berkorelasi.
      • Skenario kegagalan skala ini hanya mungkin disebabkan oleh layanan dasar bersama, seperti Azure DNS atau MICROSOFT Entra ID, yang berfungsi sebagai dependensi platform global untuk hampir semua layanan Azure. Jika teknologi Azure redundan diterapkan, kemungkinan layanan sekunder juga akan mengalami tidak tersedia atau layanan yang terdegradasi.
      • Skenario kegagalan layanan perutean global sangat mungkin berdampak signifikan pada banyak layanan lain yang digunakan untuk komponen aplikasi utama melalui dependensi antar layanan. Bahkan jika teknologi pihak ketiga digunakan, aplikasi kemungkinan akan berada dalam keadaan tidak sehat karena dampak yang lebih luas dari masalah yang mendasar, yang berarti bahwa perutean ke titik akhir aplikasi di Azure tetap memberikan sedikit nilai.

  • Redundansi layanan perutean global memberikan mitigasi untuk sejumlah kecil skenario kegagalan hipotetis, di mana dampak pemadaman global dibatasi pada layanan perutean itu sendiri.

    Untuk memberikan redundansi yang lebih luas pada skenario pemadaman global, pendekatan penyebaran aktif-aktif multicloud dapat dipertimbangkan. Pendekatan penyebaran aktif-aktif multicloud memperkenalkan kompleksitas operasional yang signifikan, yang menimbulkan risiko ketahanan yang signifikan, kemungkinan jauh melebihi risiko hipotetis pemadaman global.

  • Untuk skenario di mana kontrol klien tidak dimungkinkan, dependensi harus diambil pada satu layanan perutean global untuk menyediakan titik masuk terpadu untuk semua wilayah penyebaran aktif.

    • Ketika digunakan dalam isolasi, mereka mewakili satu titik kegagalan pada tingkat layanan karena dependensi global, meskipun redundansi dan ketersediaan multi-wilayah bawaan disediakan.
    • SLA yang disediakan oleh layanan perutean global yang dipilih mewakili SLO komposit maksimum yang dapat dicapai, terlepas dari berapa banyak wilayah penyebaran yang dipertimbangkan.

  • Ketika kontrol klien tidak dimungkinkan, mitigasi operasional dapat dipertimbangkan untuk menentukan proses migrasi ke layanan perutean global sekunder jika pemadaman global menonaktifkan layanan utama. Migrasi dari satu layanan perutean global ke layanan lainnya biasanya merupakan proses panjang yang berlangsung beberapa jam, terutama di mana penyebaran DNS dipertimbangkan.

  • Beberapa layanan perutean global pihak ketiga menyediakan SLA 100%. Namun, SLA bersejarah dan dapat dicapai yang disediakan oleh layanan ini biasanya lebih rendah dari 100%.

    • Meskipun layanan ini memberikan reparasi keuangan untuk tidak tersedia, itu datang dari sedikit signifikansi ketika dampak ketidaktersediaan signifikan, seperti dengan skenario keselamatan-kritis di mana kehidupan manusia pada akhirnya dipertaruhkan. Oleh karena itu, redundansi teknologi atau mitigasi operasional yang memadai masih harus dipertimbangkan bahkan ketika SLA hukum yang diiklankan adalah 100%.

Azure Front Door

  • Azure Front Door menyediakan penyeimbangan beban HTTP/S global dan konektivitas yang dioptimalkan menggunakan protokol Anycast dengan TCP terpisah untuk memanfaatkan jaringan backbone global Microsoft.

    • Sejumlah koneksi dipertahankan untuk setiap titik akhir backend.
    • Permintaan klien masuk pertama kali dihentikan di simpul tepi yang paling dekat dengan klien asal.
    • Setelah pemeriksaan lalu lintas yang diperlukan, permintaan diteruskan melalui backbone Microsoft ke backend yang sesuai menggunakan koneksi yang ada, atau dilayani dari cache internal simpul tepi.
    • Pendekatan ini efisien dalam menyebarkan volume lalu lintas tinggi melalui koneksi backend.

  • Menyediakan cache bawaan yang menyajikan konten statis dari simpul tepi. Dalam banyak kasus penggunaan, ini juga dapat menghilangkan kebutuhan akan Content Delivery Network (CDN) khusus.

  • Azure Web Application Firewall (WAF) dapat digunakan di Azure Front Door, dan karena disebarkan ke lokasi tepi jaringan Azure di seluruh dunia, setiap permintaan masuk yang dikirimkan oleh Front Door diperiksa di tepi jaringan.

  • Azure Front Door melindungi titik akhir aplikasi dari serangan DDoS menggunakan Azure DDoS protection Basic. Azure DDoS Standard menyediakan kemampuan perlindungan dan deteksi tambahan dan lebih canggih dan dapat ditambahkan sebagai lapisan tambahan ke Azure Front Door.

  • Azure Front Door menawarkan layanan sertifikat yang dikelola sepenuhnya. Mengaktifkan keamanan koneksi TLS untuk titik akhir tanpa harus mengelola siklus hidup sertifikat.

  • Azure Front Door Premium mendukung titik akhir privat, memungkinkan lalu lintas mengalir dari internet langsung ke jaringan virtual Azure. Ini akan menghilangkan kebutuhan menggunakan IP publik di VNet untuk membuat backend dapat diakses melalui Azure Front Door Premium.

  • Azure Front Door bergantung pada pemeriksaan kesehatan dan titik akhir kesehatan backend (URL) yang dipanggil secara interval untuk mengembalikan kode status HTTP yang mencerminkan apakah backend beroperasi secara normal, dengan respons HTTP 200 (OK) yang mencerminkan status sehat. Segera setelah backend mencerminkan status yang tidak sehat, dari perspektif simpul tepi tertentu, simpul tepi tersebut akan berhenti mengirim permintaan ke sana. Oleh karena itu backend yang tidak sehat dihapus secara transparan dari sirkulasi lalu lintas tanpa penundaan.

  • Hanya mendukung protokol HTTP/S.

  • Azure Front Door WAF dan Application Gateway WAF menyediakan set fitur yang sedikit berbeda, meskipun mendukung aturan bawaan dan kustom dan dapat diatur untuk beroperasi dalam mode deteksi atau mode pencegahan.

  • Ruang IP backend Front Door dapat berubah, tetapi Microsoft akan memastikan integrasi dengan Rentang IP Azure dan Tag Layanan. Dimungkinkan untuk berlangganan Rentang IP Azure dan Tag Layanan untuk menerima pemberitahuan tentang perubahan atau pembaruan apa pun.

  • Azure Front Door mendukung berbagai konfigurasi distribusi beban:

    • Berbasis latensi: pengaturan default yang merutekan lalu lintas ke backend "terdekat" dari klien; berdasarkan latensi permintaan.
    • Berbasis prioritas: berguna untuk penyiapan pasif aktif, di mana lalu lintas harus selalu dikirim ke backend utama kecuali tidak tersedia.
    • Tertimbang: berlaku untuk penyebaran kenari di mana persentase lalu lintas tertentu dikirim ke backend tertentu. Jika beberapa backend memiliki bobot yang sama yang ditetapkan, perutean berbasis latensi digunakan.

  • Secara default Azure Front Door menggunakan perutean berbasis latensi yang dapat menyebabkan situasi di mana beberapa backend mendapatkan lalu lintas yang jauh lebih masuk daripada yang lain, tergantung dari mana klien berasal.

  • Jika serangkaian permintaan klien harus ditangani oleh backend yang sama, Afinitas Sesi dapat dikonfigurasi pada frontend. Ini menggunakan cookie sisi klien untuk mengirim permintaan berikutnya ke backend yang sama dengan permintaan pertama, asalkan backend masih tersedia.

Azure Traffic Manager

  • Azure Traffic Manager adalah layanan pengalihan DNS.

    • Payload permintaan aktual tidak diproses, tetapi sebaliknya Traffic Manager mengembalikan nama DNS dari salah satu backend kumpulan, berdasarkan aturan yang dikonfigurasi untuk metode perutean lalu lintas yang dipilih.
    • Nama DNS backend kemudian diselesaikan ke alamat IP akhirnya yang kemudian langsung dipanggil oleh klien.

  • Respons DNS di-cache dan digunakan kembali oleh klien untuk periode Time-To-Live (TTL) tertentu, dan permintaan yang dibuat selama periode ini akan langsung masuk ke titik akhir backend tanpa interaksi Traffic Manager. Menghilangkan langkah konektivitas tambahan yang memberikan manfaat biaya dibandingkan dengan Front Door.

  • Karena permintaan dibuat langsung dari klien ke layanan backend, protokol apa pun yang didukung oleh backend dapat dimanfaatkan.

  • Mirip dengan Azure Front Door, Azure Traffic Manager juga bergantung pada pemeriksaan kesehatan untuk memahami apakah backend sehat dan beroperasi secara normal. Jika nilai lain dikembalikan atau tidak ada yang dikembalikan, layanan perutean mengenali masalah yang sedang berlangsung dan akan menghentikan permintaan perutean ke backend tertentu tersebut.

    • Namun, tidak seperti Azure Front Door, penghapusan backend yang tidak sehat ini tidak seketika karena klien akan terus membuat koneksi ke backend yang tidak sehat sampai DNS TTL kedaluwarsa dan titik akhir backend baru diminta dari layanan Traffic Manager.
    • Selain itu, bahkan ketika TTL kedaluwarsa, tidak ada jaminan bahwa server DNS publik akan menghormati nilai ini, sehingga penyebaran DNS sebenarnya dapat memakan waktu lebih lama untuk terjadi. Ini berarti bahwa lalu lintas mungkin terus dikirim ke titik akhir yang tidak sehat untuk jangka waktu yang berkelanjutan.

Azure Standard Load Balancer

Penting

Load Balancer Standar Lintas Wilayah tersedia dalam pratinjau dengan batasan teknis. Opsi ini tidak disarankan untuk beban kerja misi penting.

Rekomendasi desain

  • Gunakan Azure Front Door sebagai layanan perutean lalu lintas global utama untuk skenario HTTP/S. Azure Front Door sangat dianjurkan untuk beban kerja HTTP/S karena menyediakan perutean lalu lintas yang dioptimalkan, failover transparan, titik akhir backend privat (dengan SKU Premium), penembolokan tepi, dan integrasi dengan Web Application Firewall (WAF).

  • Untuk skenario aplikasi di mana kontrol klien dimungkinkan, terapkan logika perutean sisi klien untuk mempertimbangkan skenario failover di mana teknologi perutean global utama gagal. Dua atau beberapa teknologi perutean global harus diposisikan secara paralel untuk redundansi tambahan, jika SLA layanan tunggal tidak cukup. Logika klien diperlukan untuk merutekan ke teknologi redundan jika terjadi kegagalan layanan global.

    • Dua URL berbeda harus digunakan, dengan satu diterapkan ke masing-masing layanan perutean global yang berbeda untuk menyederhanakan pengalaman manajemen sertifikat secara keseluruhan dan logika perutean untuk failover.
    • Prioritaskan penggunaan teknologi perutean pihak ketiga sebagai layanan failover sekunder, karena ini akan mengurangi jumlah skenario kegagalan global terbesar dan kemampuan yang ditawarkan oleh penyedia CDN terkemuka di industri akan memungkinkan pendekatan desain yang konsisten.
    • Pertimbangan juga harus diberikan untuk perutean langsung ke stempel regional tunggal daripada layanan perutean terpisah. Meskipun ini akan mengakibatkan tingkat layanan yang terdegradasi, ini mewakili pendekatan desain yang jauh lebih sederhana.

Gambar ini menunjukkan konfigurasi penyeimbang beban global yang berlebihan dengan failover klien menggunakan Azure Front Door sebagai load balancer global utama.

Konfigurasi Load Balancer Global Yang Sangat Penting

Penting

Untuk benar-benar mengurangi risiko kegagalan global dalam platform Azure, pendekatan penyebaran aktif-aktif multicloud harus dipertimbangkan, dengan stempel penyebaran aktif yang dihosting di dua penyedia cloud atau lebih dan teknologi perutean pihak ketiga yang berlebihan yang digunakan untuk perutean global.

Azure dapat secara efektif diintegrasikan dengan platform cloud lainnya. Namun, sangat disarankan untuk tidak menerapkan pendekatan multicloud karena memperkenalkan kompleksitas operasional yang signifikan, dengan definisi stempel penyebaran yang berbeda dan representasi kesehatan operasional di berbagai platform cloud. Kompleksitas ini pada gilirannya memperkenalkan banyak risiko ketahanan dalam operasi normal aplikasi, yang jauh melebihi risiko hipotetis dari pemadaman platform global.

  • Meskipun tidak disarankan, untuk beban kerja HTTP menggunakan Azure Traffic Manager untuk redundansi perutean global ke Azure Front Door, pertimbangkan untuk membongkar Web Application Firewall (WAF) ke Application Gateway untuk lalu lintas yang dapat diterima yang mengalir melalui Azure Front Door.
    • Ini akan memperkenalkan titik kegagalan tambahan ke jalur masuk standar, komponen jalur kritis tambahan untuk dikelola dan diskalakan, dan juga akan dikenakan biaya tambahan untuk memastikan ketersediaan tinggi global. Namun, ini akan sangat menyederhanakan skenario kegagalan dengan memberikan konsistensi antara jalur masuk yang dapat diterima dan tidak dapat diterima melalui Azure Front Door dan Azure Traffic Manager, baik dalam hal eksekusi WAF tetapi juga titik akhir aplikasi privat.
    • Hilangnya penembolokan tepi dalam skenario kegagalan akan berdampak pada performa keseluruhan, dan ini harus diselaraskan dengan tingkat layanan yang dapat diterima atau pendekatan desain mitigasi. Untuk memastikan tingkat layanan yang konsisten, pertimbangkan untuk membongkar penembolokan tepi ke penyedia CDN pihak ketiga untuk kedua jalur.

Disarankan untuk mempertimbangkan layanan perutean global pihak ketiga sebagai pengganti dua layanan perutean global Azure. Ini memberikan tingkat maksimum mitigasi kesalahan dan pendekatan desain yang lebih sederhana karena sebagian besar penyedia CDN terkemuka di industri menawarkan kemampuan tepi yang sebagian besar konsisten dengan yang ditawarkan oleh Azure Front Door.

Azure Front Door

  • Gunakan layanan sertifikat terkelola Azure Front Door untuk mengaktifkan koneksi TLS, dan menghapus kebutuhan untuk mengelola siklus hidup sertifikat.

  • Gunakan Azure Front Door Web Application Firewall (WAF) untuk memberikan perlindungan di tepi dari eksploitasi dan kerentanan web umum, seperti injeksi SQL.

  • Gunakan cache bawaan Azure Front Door untuk menyajikan konten statis dari simpul tepi.

    • Dalam kebanyakan kasus, ini juga akan menghilangkan kebutuhan akan Content Delivery Network (CDN) khusus.

  • Konfigurasikan titik masuk platform aplikasi untuk memvalidasi permintaan masuk melalui pemfilteran berbasis header menggunakan X-Azure-FDID untuk memastikan semua lalu lintas mengalir melalui instans Front Door yang dikonfigurasi. Pertimbangkan juga mengonfigurasi IP ACLing menggunakan Tag Layanan Front Door untuk memvalidasi lalu lintas yang berasal dari ruang alamat IP backend Azure Front Door dan layanan infrastruktur Azure. Ini akan memastikan arus lalu lintas melalui Azure Front Door pada tingkat layanan, tetapi pemfilteran berbasis header masih akan diperlukan untuk memastikan penggunaan instans Front Door yang dikonfigurasi.

  • Tentukan titik akhir kesehatan TCP kustom untuk memvalidasi dependensi hilir penting dalam stempel penyebaran regional, termasuk replika platform data, seperti Azure Cosmos DB dalam contoh yang disediakan oleh implementasi referensi dasar. Jika satu atau beberapa dependensi menjadi tidak sehat, pemeriksaan kesehatan harus mencerminkan ini dalam respons yang dikembalikan sehingga seluruh stempel regional dapat diambil dari edaran.

  • Pastikan respons pemeriksaan kesehatan dicatat dan menyerap semua data operasional yang diekspos oleh Azure Front Door ke ruang kerja Analitik Log global untuk memfasilitasi sink data terpadu dan tampilan operasional tunggal di seluruh aplikasi.

  • Kecuali beban kerja sangat sensitif latensi, sebarkan lalu lintas secara merata di semua stempel regional yang dianggap paling efektif menggunakan sumber daya yang disebarkan.

    • Untuk mencapai hal ini, atur parameter "Sensitivitas Latensi (Latensi Tambahan)" ke nilai yang cukup tinggi untuk memenuhi perbedaan latensi antara berbagai wilayah backend. Pastikan toleransi yang dapat diterima oleh beban kerja aplikasi mengenai latensi permintaan klien secara keseluruhan.

  • Jangan aktifkan Afinitas Sesi kecuali diperlukan oleh aplikasi, karena dapat berdampak negatif pada keseimbangan distribusi lalu lintas. Dengan aplikasi yang sepenuhnya stateless, jika pendekatan desain aplikasi misi-kritis yang direkomendasikan diikuti, permintaan apa pun dapat ditangani oleh salah satu penyebaran regional.

Azure Traffic Manager

  • Gunakan Traffic Manager untuk skenario non HTTP/S sebagai pengganti Azure Front Door. Perbedaan kemampuan akan mendorong keputusan desain yang berbeda untuk kemampuan cache dan WAF, dan manajemen sertifikat TLS.

  • Kemampuan WAF harus dipertimbangkan dalam setiap wilayah untuk jalur masuk Traffic Manager, menggunakan Azure Application Gateway.

  • Konfigurasikan nilai TTL rendah yang sesuai untuk mengoptimalkan waktu yang diperlukan untuk menghapus titik akhir backend yang tidak sehat dari sirkulasi jika backend menjadi tidak sehat.

  • Mirip dengan Azure Front Door, titik akhir kesehatan TCP kustom harus didefinisikan untuk memvalidasi dependensi hilir penting dalam stempel penyebaran regional, yang harus tercermin dalam respons yang disediakan oleh titik akhir kesehatan.

    Namun, untuk pertimbangan tambahan Traffic Manager harus diberikan kepada failover regional tingkat layanan. seperti 'legging anjing', untuk mengurangi potensi penundaan yang terkait dengan penghapusan backend yang tidak sehat karena kegagalan dependensi, terutama jika tidak memungkinkan untuk mengatur TTL rendah untuk catatan DNS.

  • Pertimbangan harus diberikan kepada penyedia CDN pihak ketiga untuk mencapai penembolokan tepi saat menggunakan Azure Traffic Manager sebagai layanan perutean global utama. Di mana kemampuan WAF tepi juga ditawarkan oleh layanan pihak ketiga, pertimbangan harus diberikan untuk menyederhanakan jalur masuk dan berpotensi menghapus kebutuhan akan Application Gateway.

Layanan pengiriman aplikasi

Jalur masuk jaringan untuk aplikasi penting misi juga harus mempertimbangkan layanan pengiriman aplikasi untuk memastikan lalu lintas ingress yang aman, andal, dan dapat diskalakan.

Bagian ini dibangun berdasarkan rekomendasi perutean global dengan menjelajahi kemampuan pengiriman aplikasi utama, mempertimbangkan layanan yang relevan seperti Azure Standard Load Balancer, Azure Application Gateway, dan Azure API Management.

Pertimbangan Desain

  • Enkripsi TLS sangat penting untuk memastikan integritas lalu lintas pengguna masuk ke aplikasi misi penting, dengan Offloading TLS hanya diterapkan pada titik masuk stempel untuk mendekripsi lalu lintas masuk. Offloading TLS Memerlukan kunci privat sertifikat TLS untuk mendekripsi lalu lintas.

  • Web Application Firewall memberikan perlindungan terhadap eksploitasi dan kerentanan web umum, seperti injeksi SQL atau pembuatan skrip lintas situs, dan sangat penting untuk mencapai aspirasi keandalan maksimum aplikasi yang sangat penting.

  • Azure WAF memberikan perlindungan siap pakai terhadap 10 kerentanan OWASP teratas menggunakan seperangkat aturan terkelola.

    • Aturan kustom juga dapat ditambahkan untuk memperluas seperangkat aturan terkelola.
    • Azure WAF dapat diaktifkan dalam Azure Front Door, Azure Application Gateway, atau Azure CDN (saat ini dalam pratinjau publik).
      • Fitur yang ditawarkan pada setiap layanan sedikit berbeda. Misalnya, Azure Front Door WAF menyediakan pembatasan tarif, pemfilteran geografis, dan perlindungan bot, yang belum ditawarkan dalam Application Gateway WAF. Namun, semuanya mendukung aturan bawaan dan kustom dan dapat diatur untuk beroperasi dalam mode deteksi atau mode pencegahan.
      • Peta strategi untuk Azure WAF akan memastikan set fitur WAF yang konsisten disediakan di semua integrasi layanan.

  • Teknologi WAF pihak ketiga seperti NVA dan pengontrol ingress tingkat lanjut dalam Kubernetes juga dapat dipertimbangkan untuk memberikan perlindungan kerentanan yang diperlukan.

  • Konfigurasi WAF yang optimal biasanya memerlukan penyetelan halus, terlepas dari teknologi yang digunakan.

    Azure Front Door

  • Azure Front Door hanya menerima lalu lintas HTTP dan HTTPS, dan hanya akan memproses permintaan dengan header yang diketahui Host . Pemblokiran protokol ini membantu mengurangi serangan volumetrik yang tersebar di protokol dan port, serta amplifikasi DNS dan serangan keracunan TCP.

  • Azure Front Door adalah sumber daya Azure global sehingga konfigurasi disebarkan secara global ke semua lokasi tepi.

    • Konfigurasi sumber daya dapat didistribusikan dalam skala besar untuk menangani ratusan ribu permintaan per detik.
    • Pembaruan untuk konfigurasi, termasuk rute dan kumpulan backend, mulus dan tidak akan menyebabkan waktu henti selama penyebaran.

  • Azure Front Door menyediakan layanan sertifikat yang dikelola sepenuhnya dan metode bawa sertifikat Anda sendiri untuk sertifikat SSL yang menghadap klien. Layanan sertifikat yang dikelola sepenuhnya menyediakan pendekatan operasional yang disederhanakan dan membantu mengurangi kompleksitas dalam desain keseluruhan dengan melakukan manajemen sertifikat dalam satu area solusi.

  • Azure Front Door secara otomatis memutar sertifikat "Terkelola" setidaknya 60 hari sebelum kedaluwarsa sertifikat untuk melindungi dari risiko sertifikat yang kedaluwarsa. Jika sertifikat yang dikelola sendiri digunakan, sertifikat yang diperbarui harus disebarkan paling lambat 24 jam sebelum kedaluwarsa sertifikat yang ada, jika tidak, klien mungkin menerima kesalahan sertifikat yang kedaluwarsa.

  • Pembaruan sertifikat hanya akan mengakibatkan waktu henti jika Azure Front Door dialihkan antara "Dikelola" dan "Gunakan Sertifikat Anda Sendiri".

  • Azure Front Door dilindungi oleh Azure DDoS Protection Basic, yang diintegrasikan ke dalam Front Door secara default. Ini menyediakan pemantauan lalu lintas yang selalu aktif, mitigasi real-time, dan juga melindungi dari banjir kueri DNS Lapisan 7 umum atau serangan volumetrik Lapisan 3/4.

    • Perlindungan ini membantu menjaga ketersediaan Azure Front Door bahkan ketika dihadapkan dengan serangan DDoS. Serangan Distributed Denial of Service (DDoS) dapat merender sumber daya yang ditargetkan tidak tersedia dengan membanjirinya dengan lalu lintas yang tidak sah.

  • Azure Front Door juga menyediakan kemampuan WAF pada tingkat lalu lintas global, sementara Application Gateway WAF harus disediakan dalam setiap stempel penyebaran regional. Kemampuan termasuk aturan firewall untuk melindungi dari serangan umum, pemfilteran geografis, pemblokiran alamat, pembatasan laju, dan pencocokan tanda tangan.

    Penyeimbang Beban Azure

  • SKU Azure Basic Load Balancer tidak didukung oleh SLA dan memiliki beberapa batasan kemampuan dibandingkan dengan SKU Standar.

Rekomendasi desain

  • Lakukan Offloading TLS di beberapa tempat sesedikit mungkin untuk menjaga keamanan sambil menyederhanakan siklus hidup manajemen sertifikat.

  • Gunakan koneksi terenkripsi (misalnya HTTPS) dari titik di mana offloading TLS terjadi ke backend aplikasi aktual. Titik akhir aplikasi tidak akan terlihat oleh pengguna akhir, sehingga domain yang dikelola Azure, seperti azurewebsites.net atau cloudapp.net, dapat digunakan dengan sertifikat terkelola.

  • Untuk lalu lintas HTTP, pastikan kemampuan WAF diterapkan dalam jalur masuk untuk semua titik akhir yang diekspos secara publik.

  • Aktifkan kemampuan WAF di satu lokasi layanan, baik secara global dengan Azure Front Door atau secara regional dengan Azure Application Gateway, karena ini menyederhanakan penyempurnaan konfigurasi dan mengoptimalkan performa dan biaya.

    Konfigurasikan WAF dalam mode Pencegahan untuk langsung memblokir serangan. Hanya gunakan WAF dalam mode Deteksi (yaitu hanya pengelogan tetapi tidak memblokir permintaan yang mencurigakan) ketika hukuman performa mode Pencegahan terlalu tinggi. Risiko tambahan tersirat harus sepenuhnya dipahami dan selaras dengan persyaratan spesifik skenario beban kerja.

  • Prioritaskan penggunaan Azure Front Door WAF karena menyediakan kumpulan fitur asli Azure terkaya dan menerapkan perlindungan di tepi global, yang menyederhanakan desain keseluruhan dan mendorong efisiensi lebih lanjut.

  • Gunakan Azure API Management hanya saat mengekspos sejumlah besar API ke klien eksternal atau tim aplikasi yang berbeda.

  • Gunakan SKU Azure Standard Load Balancer untuk skenario distribusi lalu lintas internal apa pun dalam beban kerja layanan mikro.

    • Menyediakan SLA sebesar 99,99% saat disebarkan di seluruh Zona Ketersediaan.
    • Menyediakan kemampuan penting seperti diagnostik atau aturan keluar.

  • Gunakan Azure DDoS Network Protection untuk membantu melindungi titik akhir publik yang dihosting dalam setiap jaringan virtual aplikasi.

Penembolokan dan pengiriman konten statis

Perlakuan khusus konten statis seperti gambar, JavaScript, CSS, dan file lainnya dapat berdampak signifikan pada pengalaman pengguna secara keseluruhan serta pada biaya keseluruhan solusi. Penembolokan konten statis di tepi dapat mempercepat waktu pemuatan klien yang menghasilkan pengalaman pengguna yang lebih baik dan juga dapat mengurangi biaya untuk lalu lintas, operasi baca, dan daya komputasi pada layanan backend yang terlibat.

Pertimbangan Desain

  • Tidak semua konten yang tersedia solusi melalui Internet dihasilkan secara dinamis. Aplikasi melayani aset statis (gambar, JavaScript, CSS, file pelokalan, dll.) dan konten dinamis.
  • Beban kerja dengan manfaat konten statis yang sering diakses sangat diuntungkan dari penembolokan karena mengurangi beban pada layanan backend dan mengurangi latensi akses konten untuk pengguna akhir.
  • Penembolokan dapat diimplementasikan secara asli dalam Azure menggunakan Azure Front Door atau Azure Content Delivery Network (CDN).
    • Azure Front Door menyediakan kemampuan penembolokan tepi asli Azure dan fitur perutean untuk membagi konten statis dan dinamis.
      • Dengan membuat aturan perutean yang sesuai di Azure Front Door, /static/* lalu lintas dapat dialihkan secara transparan ke konten statis.
    • Skenario penembolokan yang lebih kompleks dapat diimplementasikan menggunakan layanan Azure CDN untuk membuat jaringan pengiriman konten lengkap untuk volume konten statis yang signifikan.
      • Layanan Azure CDN kemungkinan akan lebih hemat biaya, tetapi tidak menyediakan kemampuan perutean tingkat lanjut dan Web Application Firewall (WAF) yang sama yang direkomendasikan untuk area lain dari desain aplikasi. Namun, hal ini menawarkan fleksibilitas lebih lanjut untuk berintegrasi dengan layanan serupa dari solusi pihak ketiga, seperti Akamai dan Verizon.
    • Saat membandingkan layanan Azure Front Door dan Azure CDN, faktor keputusan berikut harus dieksplorasi:
      • Dapat menyelesaikan aturan penembolokan yang diperlukan menggunakan mesin aturan.
      • Ukuran konten yang disimpan dan biaya terkait.
      • Harga per bulan untuk eksekusi mesin aturan (dibebankan per permintaan di Azure Front Door).
      • Persyaratan lalu lintas keluar (harga berbeda menurut tujuan).

Rekomendasi desain

  • Konten statis yang dihasilkan seperti salinan berukuran file gambar yang tidak pernah atau hanya jarang berubah juga dapat memperoleh manfaat dari penembolokan. Penembolokan dapat dikonfigurasi berdasarkan parameter URL dan dengan durasi penembolokan yang bervariasi.
  • Pisahkan pengiriman konten statis dan dinamis kepada pengguna dan kirimkan konten yang relevan dari cache untuk mengurangi beban pada layanan backend mengoptimalkan performa bagi pengguna akhir.
  • Mengingat rekomendasi yang kuat (Area desain jaringan dan konektivitas ) untuk menggunakan Azure Front Door untuk tujuan perutean global dan Web Application Firewall (WAF), disarankan untuk memprioritaskan penggunaan kemampuan penembolokan Azure Front Door kecuali ada celah.

Integrasi jaringan virtual

Aplikasi penting misi biasanya akan mencakup persyaratan untuk integrasi dengan aplikasi lain atau sistem dependen, yang dapat dihosting di Azure, cloud publik lain, atau pusat data lokal. Integrasi aplikasi ini dapat dicapai menggunakan titik akhir yang menghadap publik dan internet, atau jaringan privat melalui integrasi tingkat jaringan. Pada akhirnya, metode di mana integrasi aplikasi tercapai akan berdampak signifikan pada keamanan, performa, dan keandalan solusi, dan sangat berdampak pada keputusan desain dalam area desain lainnya.

Aplikasi misi penting dapat disebarkan dalam salah satu dari tiga konfigurasi jaringan yang menyeluruh, yang menentukan bagaimana integrasi aplikasi dapat terjadi pada tingkat jaringan.

  1. Aplikasi publik tanpa konektivitas jaringan perusahaan.
  2. Aplikasi publik dengan konektivitas jaringan perusahaan.
  3. Aplikasi privat dengan konektivitas jaringan perusahaan.

Perhatian

Saat menyebarkan dalam zona pendaratan Azure, konfigurasi 1. harus disebarkan dalam Zona Pendaratan Online, sementara 2) dan 3) harus disebarkan dalam Corp. Connected Landing Zone untuk memfasilitasi integrasi tingkat jaringan.

Bagian ini mengeksplorasi skenario integrasi jaringan ini, lapisan dalam penggunaan Azure Virtual Networks yang sesuai dan layanan jaringan Azure di sekitarnya untuk memastikan persyaratan integrasi terpenuhi secara optimal.

Pertimbangan Desain

Tidak ada jaringan virtual

  • Pendekatan desain yang paling sederhana adalah tidak menyebarkan aplikasi dalam jaringan virtual.

    • Konektivitas antara semua layanan Azure yang dipertimbangkan akan disediakan sepenuhnya melalui titik akhir publik dan backbone Microsoft Azure. Konektivitas antara titik akhir publik yang dihosting di Azure hanya akan melintasi tulang punggung Microsoft dan tidak akan melalui internet publik.
    • Konektivitas ke sistem eksternal apa pun di luar Azure akan disediakan oleh internet publik.

  • Pendekatan desain ini mengadopsi "identitas sebagai perimeter keamanan" untuk memberikan kontrol akses antara berbagai komponen layanan dan solusi dependen. Ini mungkin solusi yang dapat diterima untuk skenario yang kurang sensitif terhadap keamanan. Semua layanan aplikasi dan dependensi dapat diakses melalui titik akhir publik membuat mereka rentan terhadap vektor serangan tambahan yang berorientasi pada mendapatkan akses yang tidak sah.

  • Pendekatan desain ini juga tidak berlaku untuk semua layanan Azure, karena banyak layanan, seperti AKS, memiliki persyaratan keras untuk jaringan virtual yang mendasar.

Jaringan virtual terisolasi

  • Untuk mengurangi risiko yang terkait dengan titik akhir publik yang tidak perlu, aplikasi dapat disebarkan dalam jaringan mandiri yang tidak terhubung ke jaringan lain.

  • Permintaan klien masuk masih akan mengharuskan titik akhir publik untuk diekspos ke internet, namun, semua komunikasi berikutnya dapat berada dalam jaringan virtual menggunakan titik akhir privat. Saat menggunakan Azure Front Door Premium, Dimungkinkan untuk merutekan langsung dari simpul tepi ke titik akhir aplikasi privat.

  • Meskipun konektivitas privat antara komponen aplikasi akan terjadi melalui jaringan virtual, semua konektivitas dengan dependensi eksternal masih akan mengandalkan titik akhir publik.

    • Konektivitas ke layanan platform Azure dapat dibuat dengan Titik Akhir Privat jika didukung. Jika dependensi eksternal lainnya ada di Azure, seperti aplikasi hilir lainnya, konektivitas akan disediakan melalui titik akhir publik dan backbone Microsoft Azure.
    • Konektivitas ke sistem eksternal apa pun di luar Azure akan disediakan oleh internet publik.

  • Untuk skenario di mana tidak ada persyaratan integrasi jaringan untuk dependensi eksternal, menyebarkan solusi dalam lingkungan jaringan terisolasi memberikan fleksibilitas desain maksimum. Tidak ada batasan alamat dan perutean yang terkait dengan integrasi jaringan yang lebih luas.

  • Azure Bastion adalah layanan PaaS yang dikelola sepenuhnya platform yang dapat disebarkan di jaringan virtual dan menyediakan konektivitas RDP/SSH yang aman ke Azure VM. Saat Anda terhubung melalui Azure Bastion, komputer virtual tidak memerlukan alamat IP publik.

  • Penggunaan jaringan virtual aplikasi memperkenalkan kompleksitas penyebaran yang signifikan dalam alur CI/CD, karena sarana data dan akses sarana kontrol ke sumber daya yang dihosting di jaringan privat diperlukan untuk memfasilitasi penyebaran aplikasi.

    • Jalur jaringan privat yang aman harus dibuat untuk memungkinkan alat CI/CD melakukan tindakan yang diperlukan.
    • Agen build privat dapat disebarkan dalam jaringan virtual aplikasi untuk mem-proksi akses ke sumber daya yang diamankan oleh jaringan virtual.

Jaringan virtual terhubung

  • Untuk skenario dengan persyaratan integrasi jaringan eksternal, jaringan virtual aplikasi dapat dihubungkan ke jaringan virtual lain dalam Azure, penyedia cloud lain, atau jaringan lokal menggunakan berbagai opsi konektivitas. Misalnya, beberapa skenario aplikasi mungkin mempertimbangkan integrasi tingkat aplikasi dengan aplikasi lini bisnis lain yang dihosting secara privat dalam jaringan perusahaan lokal.

  • Desain jaringan aplikasi harus selaras dengan arsitektur jaringan yang lebih luas, terutama mengenai topik seperti alamat dan perutean.

  • Ruang alamat IP yang tumpang tindih di seluruh wilayah Azure atau jaringan lokal akan membuat ketidakcocokan utama saat integrasi jaringan dipertimbangkan.

    • Sumber daya jaringan virtual dapat diperbarui untuk mempertimbangkan ruang alamat tambahan, namun, ketika ruang alamat jaringan virtual dari jaringan yang di-peering mengubah sinkronisasi pada tautan peering diperlukan, yang akan menonaktifkan peering untuk sementara waktu.
    • Azure mencadangkan lima alamat IP dalam setiap subnet, yang harus dipertimbangkan saat menentukan ukuran yang sesuai untuk jaringan virtual aplikasi dan subnet yang dicakup.
    • Beberapa layanan Azure memerlukan subnet khusus, seperti Azure Bastion, Azure Firewall, atau Azure Virtual Network Gateway. Ukuran subnet layanan ini sangat penting, karena mereka harus cukup besar untuk mendukung semua instans layanan saat ini mempertimbangkan persyaratan skala di masa mendatang, tetapi tidak begitu besar untuk alamat limbah yang tidak perlu.

  • Saat integrasi jaringan lokal atau lintas cloud diperlukan, Azure menawarkan dua solusi berbeda untuk membangun koneksi yang aman.

    • Sirkuit ExpressRoute dapat berukuran untuk menyediakan bandwidth hingga 100 Gbps.
    • Virtual Private Network (VPN) dapat berukuran untuk menyediakan bandwidth agregat hingga 10 Gbps di jaringan hub dan spoke, dan hingga 20 Gbps di Azure Virtual WAN.

Catatan

Saat menyebarkan dalam zona pendaratan Azure, ketahuilah bahwa konektivitas yang diperlukan ke jaringan lokal harus disediakan oleh implementasi zona pendaratan. Desain ini dapat menggunakan ExpressRoute dan jaringan virtual lainnya di Azure menggunakan Virtual WAN atau desain jaringan hub-and-spoke.

  • Dimasukkannya jalur jaringan dan sumber daya tambahan memperkenalkan keandalan tambahan dan pertimbangan operasional untuk aplikasi guna memastikan kesehatan tetap terjaga.

Rekomendasi desain

  • Disarankan agar solusi penting misi disebarkan dalam jaringan virtual Azure jika memungkinkan untuk menghapus titik akhir publik yang tidak perlu, membatasi permukaan serangan aplikasi untuk memaksimalkan keamanan dan keandalan.

    • Gunakan Titik Akhir Privat untuk konektivitas ke layanan platform Azure. Titik Akhir Layanan dapat dipertimbangkan untuk layanan yang tidak mendukung Private Link, asalkan risiko eksfiltrasi data dapat diterima atau dimitigasi melalui kontrol alternatif.

  • Untuk skenario aplikasi yang tidak memerlukan konektivitas jaringan perusahaan, perlakukan semua jaringan virtual sebagai sumber daya sementara yang diganti ketika penyebaran regional baru dilakukan.

  • Saat menyambungkan ke jaringan Azure atau lokal lainnya, jaringan virtual aplikasi tidak boleh diperlakukan sebagai sementara karena menciptakan komplikasi signifikan di mana peering jaringan virtual dan sumber daya gateway jaringan virtual khawatir. Semua sumber daya aplikasi yang relevan dalam jaringan virtual harus terus bersifat ephemeral, dengan subnet paralel yang digunakan untuk memfasilitasi penyebaran biru-hijau dari stempel penyebaran regional yang diperbarui.

  • Dalam skenario di mana konektivitas jaringan perusahaan diperlukan untuk memfasilitasi integrasi aplikasi melalui jaringan privat, pastikan bahwa ruang alamat IPv4 yang digunakan untuk jaringan virtual aplikasi regional tidak tumpang tindih dengan jaringan terhubung lainnya dan berukuran tepat untuk memfasilitasi skala yang diperlukan tanpa perlu memperbarui sumber daya jaringan virtual dan menimbulkan waktu henti.

    • Sangat disarankan untuk hanya menggunakan alamat IP dari alokasi alamat untuk internet privat (RFC 1918).
      • Untuk lingkungan dengan ketersediaan terbatas alamat IP privat (RFC 1918), pertimbangkan untuk menggunakan IPv6.
      • Jika penggunaan alamat IP publik diperlukan, pastikan bahwa hanya blok alamat yang dimiliki yang digunakan.
    • Selaras dengan rencana organisasi untuk alamat IP di Azure untuk memastikan bahwa ruang alamat IP jaringan aplikasi tidak tumpang tindih dengan jaringan lain di seluruh lokasi lokal atau wilayah Azure.
    • Jangan membuat jaringan virtual aplikasi yang tidak perlu besar untuk memastikan bahwa ruang alamat IP tidak-.

  • Prioritaskan penggunaan Azure CNI untuk integrasi jaringan AKS, karena mendukung set fitur yang lebih kaya.

    • Pertimbangkan Kubenet untuk skenario dengan alamat IP yang tersedia kemarahan terbatas agar sesuai dengan aplikasi dalam ruang alamat yang dibatasi.

    • Prioritaskan penggunaan plugin jaringan Azure CNI untuk integrasi jaringan AKS dan pertimbangkan Kubenet untuk skenario dengan berbagai alamat IP yang tersedia. Lihat Segmentasi mikro dan kebijakan jaringan kubernetes untuk detail selengkapnya.

  • Untuk skenario yang memerlukan integrasi jaringan lokal, prioritaskan penggunaan Rute Ekspres untuk memastikan konektivitas yang aman dan dapat diskalakan.

    • Pastikan tingkat keandalan yang diterapkan ke Rute Ekspres atau VPN sepenuhnya memenuhi persyaratan aplikasi.
    • Beberapa jalur jaringan harus dipertimbangkan untuk memberikan redundansi tambahan jika diperlukan, seperti sirkuit ExpressRoute yang terhubung silang atau penggunaan VPN sebagai mekanisme konektivitas failover.

  • Pastikan semua komponen pada jalur jaringan penting sejalan dengan persyaratan keandalan dan ketersediaan alur pengguna terkait, terlepas dari apakah manajemen jalur ini dan komponen terkait dikirimkan oleh tim aplikasi tim IT pusat.

    Catatan

    Saat menyebarkan dalam zona pendaratan Azure dan berintegrasi dengan topologi jaringan organisasi yang lebih luas, pertimbangkan panduan jaringan untuk memastikan jaringan dasar selaras dengan praktik terbaik Microsoft.

  • Gunakan Azure Bastion atau koneksi privat yang diproksi untuk mengakses bidang data sumber daya Azure atau melakukan operasi manajemen.

Jalan keluar internet

Internet egress adalah persyaratan jaringan dasar untuk aplikasi misi penting untuk memfasilitasi komunikasi eksternal dalam konteks:

  1. Interaksi pengguna aplikasi langsung.
  2. Integrasi aplikasi dengan dependensi eksternal di luar Azure.
  3. Akses ke dependensi eksternal yang diperlukan oleh layanan Azure yang digunakan oleh aplikasi.

Bagian ini mengeksplorasi bagaimana keluarnya internet dapat dicapai sambil memastikan keamanan, keandalan, dan performa berkelanjutan dipertahankan, menyoroti persyaratan keluar utama untuk layanan yang direkomendasikan dalam konteks misi penting.

Pertimbangan Desain

  • Banyak layanan Azure memerlukan akses ke titik akhir publik untuk berbagai fungsi manajemen dan sarana kontrol untuk beroperasi seperti yang dimaksudkan.

  • Azure menyediakan metode konektivitas keluar internet langsung yang berbeda, seperti gateway Azure NAT atau Azure Load Balancer, untuk komputer virtual atau instans komputasi di jaringan virtual.

  • Ketika lalu lintas dari dalam jaringan virtual berjalan ke Internet, Network Address Translation (NAT) harus berlangsung. Ini adalah operasi komputasi yang terjadi dalam tumpukan jaringan dan karenanya dapat memengaruhi performa sistem.

  • Ketika NAT terjadi dalam skala kecil, dampak performa harus dapat diabaikan, namun, jika ada sejumlah besar masalah jaringan permintaan keluar dapat terjadi. Masalah-masalah ini biasanya datang dalam bentuk 'Sumber NAT (atau SNAT) port kelelahan'.

  • Di lingkungan multipenyewa, seperti Azure App Service, ada sejumlah port keluar terbatas yang tersedia untuk setiap instans. Jika port ini habis, tidak ada koneksi keluar baru yang dapat dimulai. Masalah ini dapat dimitigasi dengan mengurangi jumlah traversal tepi privat/publik atau dengan menggunakan solusi NAT yang lebih dapat diskalakan seperti Azure NAT Gateway.

  • Selain keterbatasan NAT, lalu lintas keluar juga dapat tunduk pada pemeriksaan keamanan yang diperlukan.

    • Azure Firewall menyediakan kemampuan keamanan yang sesuai untuk mengamankan keluarnya jaringan.

    • Azure Firewall (atau NVA yang setara) dapat digunakan untuk mengamankan persyaratan keluar Kubernetes dengan memberikan kontrol terperinci atas arus lalu lintas keluar.

  • Keluarnya internet dalam volume besar akan dikenakan biaya transfer data.

Azure NAT Gateway

  • Azure NAT Gateway mendukung 64.000 koneksi untuk TCP dan UDP per alamat IP keluar yang ditetapkan.

    • Hingga 16 alamat IP dapat ditetapkan ke satu gateway NAT.
    • Batas waktu diam TCP default selama 4 menit. Jika batas waktu diam diubah ke nilai yang lebih tinggi, alur akan ditahan lebih lama, yang akan meningkatkan tekanan pada inventori port SNAT.

  • Gateway NAT tidak dapat menyediakan isolasi zona di luar kotak. Untuk mendapatkan redundansi zona, subnet yang berisi sumber daya zona harus selaras dengan gateway NAT zona yang sesuai.

Rekomendasi desain

  • Minimalkan jumlah koneksi Internet keluar karena ini akan berdampak pada performa NAT.

    • Jika koneksi terikat internet dalam jumlah besar diperlukan, pertimbangkan untuk menggunakan Azure NAT Gateway untuk mengabstraksi arus lalu lintas keluar.

  • Gunakan Azure Firewall di mana persyaratan untuk mengontrol dan memeriksa lalu lintas internet keluar ada.

    • Pastikan Azure Firewall tidak digunakan untuk memeriksa lalu lintas antar layanan Azure.

Catatan

Saat menyebarkan dalam zona pendaratan Azure, pertimbangkan untuk menggunakan platform dasar sumber daya Azure Firewall (atau NVA yang setara). Jika dependensi diambil pada sumber daya platform pusat untuk keluarnya internet, maka tingkat keandalan sumber daya tersebut dan jalur jaringan terkait harus selaras dengan persyaratan aplikasi. Data operasional dari sumber daya juga harus tersedia untuk aplikasi untuk menginformasikan potensi tindakan operasional dalam skenario kegagalan.

Jika ada persyaratan skala tinggi yang terkait dengan lalu lintas keluar, pertimbangan harus diberikan ke sumber daya Azure Firewall khusus untuk aplikasi penting misi, untuk mengurangi risiko yang terkait dengan penggunaan sumber daya bersama secara terpusat, seperti skenario tetangga yang bising.

  • Ketika disebarkan dalam lingkungan Virtual WAN, pertimbangan harus diberikan kepada Firewall Manager untuk menyediakan manajemen terpusat instans Azure Firewall aplikasi khusus untuk memastikan postur keamanan organisasi diamati melalui kebijakan firewall global.
  • Pastikan kebijakan firewall inkremental didelegasikan ke tim keamanan aplikasi melalui kontrol akses berbasis peran untuk memungkinkan otonomi kebijakan aplikasi.

Konektivitas antar-zona dan antar-wilayah

Meskipun desain aplikasi sangat menganjurkan stempel penyebaran regional independen, banyak skenario aplikasi mungkin masih memerlukan integrasi jaringan antara komponen aplikasi yang disebarkan dalam zona atau wilayah Azure yang berbeda, bahkan jika hanya dalam keadaan layanan yang terdegradasi. Metode di mana komunikasi antar-zona dan antar-wilayah tercapai memiliki bantalan signifikan pada kinerja dan keandalan keseluruhan, yang akan dieksplorasi melalui pertimbangan dan rekomendasi dalam bagian ini.

Pertimbangan Desain

  • Pendekatan desain aplikasi untuk aplikasi misi penting mendukung penggunaan penyebaran regional independen dengan redundansi zona yang diterapkan di semua tingkat komponen dalam satu wilayah.

  • Zona Ketersediaan (AZ) adalah lokasi pusat data yang terpisah secara fisik dalam wilayah Azure, menyediakan isolasi kesalahan fisik dan logis hingga tingkat pusat data tunggal.

    Latensi pulang pergi kurang dari 2 mdtk dijamin untuk komunikasi antar-zona. Zona akan memiliki variansi latensi kecil yang diberikan jarak yang bervariasi dan jalur serat antar zona.

  • Konektivitas Zona Ketersediaan tergantung pada karakteristik regional, dan oleh karena itu lalu lintas yang memasuki suatu wilayah melalui lokasi tepi mungkin perlu dirutekan antar zona untuk mencapai tujuannya. Ini akan menambahkan latensi ~1ms-2ms yang diberikan perutean antar-zona dan batasan 'kecepatan cahaya', tetapi ini seharusnya hanya memiliki bantalan untuk beban kerja sensitif hiper.

  • Zona Ketersediaan diperlakukan sebagai entitas logis dalam konteks satu langganan, sehingga langganan yang berbeda mungkin memiliki pemetaan zona yang berbeda untuk wilayah yang sama. Misalnya, zona 1 di Langganan A dapat sesuai dengan pusat data fisik yang sama dengan zona 2 di langganan B.

  • Dengan skenario aplikasi yang sangat cerewet antara komponen aplikasi, menyebarkan tingkat aplikasi di seluruh zona dapat menimbulkan latensi yang signifikan dan peningkatan biaya. Dimungkinkan untuk mengurangi ini dalam desain dengan membatasi stempel penyebaran ke satu zona dan menyebarkan beberapa stempel di berbagai zona.

  • Komunikasi antara wilayah Azure yang berbeda dikenakan biaya transfer data yang lebih besar per GB bandwidth.

    • Tingkat transfer data yang berlaku tergantung pada benua wilayah Azure yang dipertimbangkan.
    • Data yang melintas di benua dikenakan tarif yang jauh lebih tinggi.

  • Metode konektivitas Rute Ekspres dan VPN juga dapat digunakan untuk secara langsung menghubungkan wilayah Azure yang berbeda bersama-sama untuk skenario tertentu, atau bahkan platform cloud yang berbeda.

  • Agar komunikasi layanan ke layanan Private Link dapat digunakan untuk komunikasi langsung menggunakan titik akhir privat.

  • Lalu lintas dapat disematkan melalui sirkuit Rute Ekspres yang digunakan untuk konektivitas lokal untuk memfasilitasi perutean antara jaringan virtual dalam wilayah Azure dan di berbagai wilayah Azure dalam geografi yang sama.

    • Lalu lintas penyematan rambut melalui Rute Ekspres akan melewati biaya transfer data yang terkait dengan peering jaringan virtual, sehingga dapat digunakan sebagai cara untuk mengoptimalkan biaya.
    • Pendekatan ini mengharuskan lompatan jaringan tambahan untuk integrasi aplikasi dalam Azure, yang memperkenalkan risiko latensi dan keandalan. Memperluas peran Rute Ekspres dan komponen gateway terkait dari Azure/lokal untuk juga mencakup konektivitas Azure/Azure.

  • Ketika latensi submillisecond diperlukan antara layanan, Grup Penempatan Kedekatan dapat digunakan saat didukung oleh layanan yang digunakan.

Rekomendasi desain

  • Gunakan peering jaringan virtual untuk menyambungkan jaringan dalam suatu wilayah dan di berbagai wilayah. Sangat disarankan untuk menghindari penyematan rambut dalam Rute Ekspres.

  • Gunakan Private Link untuk membangun komunikasi langsung antara layanan di wilayah yang sama atau di seluruh wilayah (layanan di Wilayah A berkomunikasi dengan layanan di Wilayah B.

  • Untuk beban kerja aplikasi yang sangat cerewet antar komponen, pertimbangkan untuk membatasi stempel penyebaran ke satu zona dan menyebarkan beberapa stempel di berbagai zona. Ini memastikan redundansi zona dipertahankan pada tingkat stempel penyebaran yang dienkapsulasi daripada satu komponen aplikasi.

  • Jika memungkinkan, perlakukan setiap stempel penyebaran sebagai independen dan terputus dari stempel lain.

    • Gunakan teknologi platform data untuk menyinkronkan status di seluruh wilayah daripada mencapai konsistensi pada tingkat aplikasi dengan jalur jaringan langsung.
    • Hindari lalu lintas 'legging anjing' di antara berbagai wilayah kecuali diperlukan, bahkan dalam skenario kegagalan. Gunakan layanan perutean global dan pemeriksaan kesehatan end-to-end untuk mengambil seluruh stempel keluar dari sirkulasi jika satu tingkat komponen penting gagal, daripada merutekan lalu lintas di tingkat komponen yang rusak tersebut ke wilayah lain.

  • Untuk skenario aplikasi sensitif latensi hiper, prioritaskan penggunaan zona dengan gateway jaringan regional untuk mengoptimalkan latensi jaringan untuk jalur masuk.

Segmentasi mikro dan kebijakan jaringan Kubernetes

Segmentasi mikro adalah pola desain keamanan jaringan yang digunakan untuk mengisolasi dan mengamankan beban kerja aplikasi individual, dengan kebijakan yang diterapkan untuk membatasi lalu lintas jaringan antar beban kerja berdasarkan model Zero Trust. Ini biasanya diterapkan untuk mengurangi permukaan serangan jaringan, meningkatkan penahanan pelanggaran, dan memperkuat keamanan melalui kontrol jaringan tingkat aplikasi berbasis kebijakan.

Aplikasi penting misi dapat memberlakukan keamanan jaringan tingkat aplikasi menggunakan Network Security Groups (NSG) baik di tingkat subnet atau antarmuka jaringan, Daftar Kontrol Akses layanan (ACL), dan kebijakan jaringan saat menggunakan Azure Kubernetes Service (AKS).

Bagian ini mengeksplorasi penggunaan kemampuan ini secara optimal, memberikan pertimbangan dan rekomendasi utama untuk mencapai segmentasi mikro tingkat aplikasi.

Pertimbangan Desain

  • AKS dapat disebarkan dalam dua model jaringan yang berbeda:

    • Jaringan Kubenet: Simpul AKS terintegrasi dalam jaringan virtual yang ada, tetapi pod ada dalam jaringan overlay virtual pada setiap simpul. Lalu lintas antar pod pada simpul yang berbeda dirutekan melalui kube-proxy.
    • Jaringan Azure Container Networking Interface (CNI): Kluster AKS terintegrasi dalam jaringan virtual yang ada dan node, pod, dan layanannya menerima alamat IP dari jaringan virtual yang sama yang dilampirkan oleh node kluster. Ini relevan untuk berbagai skenario jaringan yang membutuhkan konektivitas langsung dari dan ke pod. Kumpulan simpul yang berbeda dapat disebarkan ke subnet yang berbeda.

    Catatan

    Azure CNI memerlukan lebih banyak ruang alamat IP dibandingkan dengan Kubenet. Diperlukan perencanaan dan ukuran jaringan di muka yang tepat. Untuk informasi selengkapnya, lihat dokumentasi Azure CNI.

  • Secara default, pod tidak terisolasi dan menerima lalu lintas dari sumber apa pun dan dapat mengirim lalu lintas ke tujuan mana pun; sebuah pod dapat berkomunikasi dengan setiap pod lain dalam kluster Kubernetes tertentu; Kubernetes tidak memastikan isolasi tingkat jaringan apa pun, dan tidak mengisolasi namespace di tingkat kluster.

  • Komunikasi antara Pod dan Namespace dapat diisolasi menggunakan Kebijakan Jaringan. Kebijakan Jaringan adalah spesifikasi Kube yang mendefinisikan kebijakan akses untuk komunikasi antar Pod. Menggunakan Kebijakan Jaringan, sekumpulan aturan yang diurutkan dapat didefinisikan untuk mengontrol bagaimana lalu lintas dikirim/diterima, dan diterapkan ke kumpulan pod yang cocok dengan satu atau beberapa pemilih label.

    • AKS mendukung dua plugin yang menerapkan Kebijakan Jaringan, Azure dan Calico. Kedua plugin menggunakan Linux IPTables untuk memberlakukan kebijakan yang ditentukan. Lihat Perbedaan antara kebijakan Azure dan Calico dan kemampuannya untuk detail selengkapnya.
    • Kebijakan jaringan tidak bertentangan karena aditif.
    • Agar aliran jaringan antara dua pod diizinkan, kebijakan keluar pada pod sumber dan kebijakan ingress pada pod tujuan perlu mengizinkan lalu lintas.
    • Fitur kebijakan jaringan hanya dapat diaktifkan pada waktu instansiasi kluster. Tidak dimungkinkan untuk mengaktifkan kebijakan jaringan pada kluster AKS yang ada.
    • Pengiriman kebijakan jaringan konsisten terlepas dari apakah Azure atau Calico digunakan.
    • Calico menyediakan set fitur yang lebih kaya, termasuk dukungan untuk simpul windows dan mendukung Azure CNI serta Kubenet.

  • AKS mendukung pembuatan kumpulan simpul yang berbeda untuk memisahkan beban kerja yang berbeda menggunakan simpul dengan karakteristik perangkat keras dan perangkat lunak yang berbeda, seperti simpul dengan dan tanpa kemampuan GPU.

    • Menggunakan kumpulan simpul tidak menyediakan isolasi tingkat jaringan apa pun.
    • Kumpulan simpul dapat menggunakan subnet yang berbeda dalam jaringan virtual yang sama. NSG dapat diterapkan di tingkat subnet untuk mengimplementasikan segmentasi mikro antar kumpulan simpul.

Rekomendasi desain

  • Konfigurasikan NSG pada semua subnet yang dipertimbangkan untuk menyediakan IP ACL untuk mengamankan jalur masuk dan mengisolasi komponen aplikasi berdasarkan model Zero Trust.

    • Gunakan Tag Layanan Front Door dalam NSG pada semua subnet yang berisi backend aplikasi yang ditentukan dalam Azure Front Door, karena ini akan memvalidasi lalu lintas yang berasal dari ruang alamat IP backend Azure Front Door yang sah. Ini akan memastikan arus lalu lintas melalui Azure Front Door pada tingkat layanan, tetapi pemfilteran berbasis header masih akan diperlukan untuk memastikan penggunaan instans Front Door tertentu dan untuk juga mengurangi risiko keamanan 'IP spoofing'.

    • Lalu lintas internet publik harus dinonaktifkan pada port RDP dan SSH di semua NSG yang berlaku.

    • Prioritaskan penggunaan plugin jaringan Azure CNI dan pertimbangkan Kubenet untuk skenario dengan berbagai alamat IP yang tersedia terbatas agar sesuai dengan aplikasi dalam ruang alamat yang dibatasi.

      • AKS mendukung penggunaan Azure CNI dan Kubenet. Pilihan jaringan ini dipilih pada waktu penyebaran.
      • Plugin jaringan Azure CNI adalah plugin jaringan yang lebih kuat dan dapat diskalakan, dan direkomendasikan untuk sebagian besar skenario.
      • Kubenet adalah plugin jaringan yang lebih ringan, dan direkomendasikan untuk skenario dengan berbagai alamat IP yang tersedia.
      • Lihat Azure CNI untuk detail selengkapnya.

  • Fitur Kebijakan Jaringan di Kubernetes harus digunakan untuk menentukan aturan untuk lalu lintas masuk dan keluar antara pod dalam kluster. Tentukan Kebijakan Jaringan terperinci untuk membatasi dan membatasi komunikasi lintas pod.

    • Aktifkan Kebijakan Jaringan untuk Azure Kubernetes Service pada waktu penyebaran.
    • Prioritaskan penggunaan Calico karena menyediakan set fitur yang lebih kaya dengan adopsi dan dukungan komunitas yang lebih luas.

Langkah selanjutnya

Tinjau pertimbangan untuk mengukur dan mengamati kesehatan aplikasi.

Pemodelan dan pengamatan kesehatan