Arsitektur dalam artikel ini diperluas pada arsitektur garis besar komputer virtual (VM) untuk mengatasi perubahan dan harapan saat Anda menyebarkannya di zona pendaratan Azure.
Dalam contoh dalam artikel ini, organisasi ingin beban kerja berbasis VM menggunakan sumber daya federasi yang dikelola tim platform secara terpusat. Sumber daya ini mencakup sumber daya jaringan untuk konektivitas lintas tempat, manajemen akses identitas, dan kebijakan. Contoh ini mengasumsikan bahwa organisasi mengadopsi zona pendaratan Azure untuk memberlakukan tata kelola yang konsisten dan efisiensi biaya di beberapa beban kerja.
Sebagai pemilik beban kerja, Anda dapat membongkar manajemen sumber daya bersama ke tim pusat, sehingga Anda dapat fokus pada upaya pengembangan beban kerja. Artikel ini menyajikan perspektif tim beban kerja. Rekomendasi untuk tim platform ditentukan.
Penting
Apa itu zona pendaratan Azure? Zona pendaratan Azure menyajikan dua perspektif jejak cloud organisasi. Zona pendaratan aplikasi adalah langganan Azure tempat beban kerja berjalan. Ini terhubung ke sumber daya bersama organisasi. Melalui koneksi tersebut, ia memiliki akses ke infrastruktur dasar yang menjalankan beban kerja, seperti jaringan, manajemen akses identitas, kebijakan, dan pemantauan. Zona pendaratan platform adalah kumpulan berbagai langganan, masing-masing dengan fungsi tertentu. Misalnya, langganan konektivitas menyediakan resolusi Sistem Nama Domain (DNS) terpusat, konektivitas lintas lokasi, dan appliance virtual jaringan (NVA) yang tersedia untuk digunakan tim aplikasi.
Kami menyarankan agar Anda memahami konsep zona pendaratan Azure untuk membantu Anda mempersiapkan implementasi arsitektur ini.
Tata letak artikel
| Sistem | Keputusan desain | Pendekatan Azure Well-Architected Framework |
|---|---|---|
| ▪ Diagram arsitektur ▪ Sumber daya beban kerja ▪ Sumber daya federasi |
▪ Penyiapan langganan ▪ Persyaratan jaringan ▪ Perubahan desain jaringan dari garis besar ▪ Pemantauan ▪ Kepatuhan patch ▪ Tata kelola organisasi ▪ Mengubah manajemen |
▪ Keandalan ▪ Keamanan ▪ Pengoptimalan Biaya |
Tip
Implementasi referensi ini menunjukkan praktik terbaik yang dijelaskan dalam artikel ini.
Artefak repositori menyediakan fondasi yang dapat disesuaikan untuk lingkungan Anda. Implementasi menyiapkan jaringan hub dengan sumber daya bersama seperti Azure Firewall untuk tujuan demonstrasi. Anda dapat menerapkan pengaturan ini untuk memisahkan langganan zona pendaratan aplikasi untuk beban kerja dan fungsi platform yang berbeda.
Sistem
Unduh file Visio arsitektur ini.
Komponen
Semua arsitektur zona pendaratan Azure memiliki pemisahan kepemilikan antara tim platform dan tim beban kerja. Arsitek aplikasi dan tim DevOps harus memiliki pemahaman yang kuat tentang pemisahan tanggung jawab ini untuk memahami apa yang berada di bawah pengaruh atau kontrol langsung mereka dan apa yang tidak.
Sumber daya milik tim beban kerja
Sumber daya berikut sebagian besar tidak berubah dari arsitektur garis besar.
Azure Virtual Machines adalah platform aplikasi. Sumber daya komputasi didistribusikan di seluruh zona ketersediaan.
Azure Load Balancer digunakan untuk memuat lalu lintas keseimbangan secara privat dari VM front-end ke VM back-end. Load balancer mendistribusikan lalu lintas ke VM di seluruh zona.
Azure Application Gateway digunakan sebagai proksi terbalik untuk merutekan permintaan pengguna ke VM front-end. SKU yang dipilih juga digunakan untuk menghosting Azure Web Application Firewall untuk melindungi VM front-end dari lalu lintas yang berpotensi berbahaya.
Azure Key Vault digunakan untuk menyimpan rahasia dan sertifikat aplikasi.
Azure Monitor, Analitik Log, dan Application Insights digunakan untuk mengumpulkan, menyimpan, dan memvisualisasikan data pengamatan.
Azure Policy digunakan untuk menerapkan kebijakan yang khusus untuk beban kerja.
Tim beban kerja mempertahankan dan memenuhi sumber daya dan tanggung jawab berikut.
Subnet jaringan virtual spoke dan kelompok keamanan jaringan (NSG) yang ditempatkan pada subnet tersebut untuk mempertahankan segmentasi dan mengontrol arus lalu lintas.
Titik akhir privat untuk mengamankan konektivitas ke solusi platform as a service (PaaS) dan zona DNS privat yang diperlukan untuk titik akhir tersebut.
Azure Managed Disks menyimpan file log di server back-end, dan data dipertahankan bahkan ketika VM di-boot ulang. Server front-end memiliki disk yang terpasang yang dapat Anda gunakan untuk menyebarkan aplikasi stateless Anda.
Sumber daya milik tim platform
Tim platform memiliki dan memelihara sumber daya terpusat ini. Arsitektur ini mengasumsikan bahwa sumber daya ini telah disediakan sebelumnya dan mempertimbangkan dependensinya.
Azure Firewall di jaringan hub digunakan untuk memeriksa dan membatasi lalu lintas keluar. Komponen ini menggantikan load balancer standar dalam arsitektur garis besar, yang tidak memberikan batasan pada lalu lintas keluar ke internet.
Azure Bastion di jaringan hub menyediakan akses operasional yang aman ke VM beban kerja. Dalam arsitektur garis besar, tim beban kerja memiliki komponen ini.
Jaringan virtual spoke adalah tempat beban kerja disebarkan.
Rute yang ditentukan pengguna (UDR) digunakan untuk memaksa penerowongan ke jaringan hub.
Batasan tata kelola berbasis Azure Policy dan
DeployIfNotExists(DINE) adalah bagian dari langganan beban kerja.
Penting
Zona pendaratan Azure menyediakan beberapa sumber daya sebelumnya sebagai bagian dari langganan zona pendaratan platform, dan langganan beban kerja Anda menyediakan sumber daya lain. Banyak sumber daya adalah bagian dari langganan konektivitas, yang memiliki sumber daya tambahan, seperti Azure ExpressRoute, Azure VPN Gateway, dan Azure DNS. Sumber daya tambahan ini menyediakan akses lintas tempat dan resolusi nama. Manajemen sumber daya ini berada di luar cakupan artikel ini.
Penyiapan langganan
Dalam konteks zona pendaratan, tim beban kerja Anda harus memberi tahu tim platform tentang persyaratan spesifik mereka.
Tim beban kerja Anda harus menyertakan informasi terperinci tentang ruang jaringan yang dibutuhkan beban kerja Anda, sehingga tim platform dapat mengalokasikan sumber daya yang diperlukan. Tim Anda menentukan persyaratan, dan tim platform menentukan alamat IP yang akan ditetapkan dalam jaringan virtual dan grup manajemen tempat langganan ditetapkan.
Tim platform menetapkan grup manajemen yang sesuai berdasarkan kekritisan bisnis dan persyaratan teknis beban kerja, misalnya jika beban kerja terekspos ke internet. Organisasi menentukan konfigurasi grup manajemen ini, dan tim platform mengimplementasikannya.
Misalnya, grup manajemen dalam skenario aplikasi untuk arsitektur garis besar dipertimbangkan:
Aplikasi privat, seperti aplikasi lini bisnis internal atau solusi off-the-shelf komersial (COTS), yang sering terletak di bawah grup manajemen Corp zona pendaratan Azure.
Aplikasi publik, seperti dalam aplikasi yang terhubung ke internet, yang sering berada di bawah grup manajemen Corp atau Online.
Tim platform juga bertanggung jawab untuk menyiapkan langganan atau sekelompok langganan untuk penyebaran beban kerja.
Bagian berikut ini menyediakan panduan tentang penyiapan langganan awal. Namun, tim platform biasanya membuat perubahan pada layanan terpusat untuk mengatasi persyaratan yang terlewat atau berubah. Perubahan platform memiliki efek yang lebih luas pada semua tim beban kerja.
Oleh karena itu, tim platform harus memastikan bahwa semua beban kerja VM disiapkan untuk setiap perubahan, dan mereka harus menyadari siklus hidup solusi berbasis VM dan siklus pengujian. Untuk informasi selengkapnya, lihat Mengelola perubahan dari waktu ke waktu.
Persyaratan dan pemenuhan beban kerja
Tim beban kerja dan tim platform berbagi dua tanggung jawab utama: penugasan grup manajemen dan penyiapan jaringan. Untuk arsitektur ini, pertimbangkan persyaratan jaringan berikut yang harus Anda komunikasikan ke tim platform. Gunakan poin-poin ini sebagai contoh untuk memahami diskusi dan negosiasi antara kedua tim saat Anda menerapkan arsitektur serupa.
Jumlah jaringan virtual spoke: Dalam arsitektur ini, hanya satu spoke khusus yang diperlukan. Sumber daya yang disebarkan tidak perlu menjangkau beberapa jaringan dan dikolokasikan dalam satu jaringan virtual.
Ukuran jaringan spoke: Pertimbangkan persyaratan operasional dan pertumbuhan beban kerja yang diharapkan. Misalnya, jika Anda berencana untuk menerapkan pembaruan biru/hijau atau kenari, ukuran maksimum harus memperhitungkan ruang yang diperlukan penyebaran berdampingan Anda.
Perubahan di masa mendatang mungkin memerlukan lebih banyak ruang IP, yang dapat salah selaras dengan alokasi saat ini. Integrasi ruang ini dapat memperkenalkan kompleksitas ekstra. Jadilah proaktif dan minta sumber daya jaringan yang cukup di muka untuk memastikan bahwa ruang yang dialokasikan dapat mengakomodasi ekspansi di masa mendatang.
Wilayah penyebaran: Penting untuk menentukan wilayah tempat beban kerja akan disebarkan. Tim platform dapat menggunakan informasi ini untuk memastikan bahwa jaringan virtual spoke-and-hub disediakan di wilayah yang sama. Jaringan di berbagai wilayah dapat menyebabkan masalah latensi karena lalu lintas yang melintasi batas regional dan juga dapat dikenakan biaya bandwidth tambahan.
Karakteristik beban kerja dan pilihan desain: Mengomunikasikan pilihan desain, komponen, dan karakteristik Anda kepada tim platform Anda. Misalnya, jika Anda mengharapkan beban kerja Anda menghasilkan sejumlah besar koneksi bersamaan ke internet (cerewet), tim platform harus memastikan bahwa ada port yang cukup tersedia untuk mencegah kelelahan. Mereka dapat menambahkan alamat IP ke firewall terpusat untuk mendukung lalu lintas atau menyiapkan gateway Network Address Translation (NAT) untuk merutekan lalu lintas melalui jalur alternatif.
Sebaliknya, jika Anda mengharapkan beban kerja Menghasilkan lalu lintas jaringan minimal (kebisingan latar belakang), tim platform harus menggunakan sumber daya secara efisien di seluruh organisasi.
Tim platform perlu memahami dependensi apa pun dengan jelas. Misalnya, beban kerja Anda mungkin memerlukan akses ke database yang dimiliki tim lain, atau beban kerja Anda mungkin memiliki lalu lintas lokal. Apakah beban kerja Anda memiliki dependensi di luar Azure? Informasi tersebut penting untuk diketahui oleh tim platform.
Konfigurasi firewall: Tim platform harus mengetahui lalu lintas yang meninggalkan jaringan spoke dan terowongan ke jaringan hub. Firewall di hub tidak dapat memblokir lalu lintas tersebut.
Misalnya, jika beban kerja Anda perlu mengakses pembaruan Windows agar tetap di-patch, firewall tidak boleh memblokir pembaruan ini. Demikian pula, jika ada agen Monitor, yang mengakses titik akhir tertentu, firewall tidak boleh memblokir lalu lintas tersebut karena dapat mengganggu data pemantauan untuk beban kerja Anda. Aplikasi mungkin memerlukan akses ke titik akhir pihak ketiga. Terlepas dari itu, gunakan firewall terpusat untuk membedakan antara lalu lintas yang diharapkan dan tidak beralasan.
Akses operator: Jika ada grup keamanan ID Microsoft Entra yang digunakan operator untuk mengakses VM melalui Azure Bastion, beri tahu tim platform. Azure Bastion biasanya merupakan sumber daya pusat. Sangat penting untuk memastikan bahwa kelompok keamanan dan VM mendukung protokol aman.
Selain itu, beri tahu tim platform tentang rentang IP yang berisi VM. Informasi ini diperlukan untuk mengonfigurasi NSG di sekitar Azure Bastion di jaringan hub.
IP publik: Beri tahu tim platform tentang profil lalu lintas masuk, termasuk alamat IP publik yang diantisipasi. Dalam arsitektur ini, hanya lalu lintas bersumber internet yang menargetkan IP publik di Application Gateway. Tim platform harus memberi tahu tim beban kerja jika IP ini berada di bawah paket Azure DDoS Protection atau jika itu tanggung jawab tim beban kerja.
Dalam arsitektur ini, ada IP publik lain untuk akses operasional melalui Azure Bastion. Tim platform memiliki IP publik ini dan terdaftar dalam layanan, seperti DDoS Protection, yang juga dikelola tim platform.
Penting
Kami merekomendasikan alur kerja penjual langganan untuk tim platform yang melibatkan serangkaian pertanyaan yang dirancang untuk menangkap informasi dari tim beban kerja. Pertanyaan-pertanyaan ini mungkin bervariasi dari satu organisasi ke organisasi lain, tetapi niatnya adalah untuk mengumpulkan persyaratan untuk menerapkan langganan. Untuk informasi selengkapnya, lihat Penjual langganan.
Pilihan desain VM
Pilihan VM SKU dan disk tetap sama dengan arsitektur garis besar.
Organisasi mungkin memberlakukan persyaratan kepatuhan pada tim beban kerja yang mengamanatkan penggunaan gambar VM tertentu. Mengingat persyaratan seperti itu, tim platform mungkin mengelola sekumpulan gambar standar, sering disebut sebagai gambar emas, yang dibuat untuk digunakan di seluruh organisasi.
Tim platform mungkin menggunakan penawaran terkelola seperti Azure Compute Gallery atau repositori privat untuk menyimpan gambar OS atau artefak beban kerja yang disetujui. Saat Anda memilih gambar OS untuk VM, konsultasikan dengan tim platform Anda tentang sumber gambar, frekuensi pembaruan, dan harapan penggunaan. Pastikan juga bahwa gambar dapat memenuhi persyaratan bisnis yang diperlukan yang dipenuhi beban kerja.
Penting
Untuk tim platform: Jika Anda menggunakan Compute Gallery, beban kerja memerlukan visibilitas jaringan ke galeri privat. Berkolaborasi dengan tim beban kerja untuk membangun konektivitas yang aman.
Jaringan
Dalam arsitektur garis besar, beban kerja disediakan dalam satu jaringan virtual. Tim beban kerja mengelola jaringan virtual.
Dalam arsitektur ini, tim platform menentukan topologi jaringan. Topologi hub-spoke diasumsikan dalam arsitektur ini.
Unduh file Visio arsitektur ini.
Jaringan virtual hub: Hub regional berisi layanan terpusat yang berkomunikasi dengan sumber daya beban kerja di wilayah yang sama. Untuk informasi selengkapnya, lihat Sumber daya milik tim platform. Sebaiknya tempatkan hub di langganan konektivitas.
Jaringan virtual spoke: Dalam arsitektur ini, jaringan virtual tunggal dari arsitektur garis besar adalah jaringan spoke. Ini di-peering ke jaringan hub, yang berisi layanan terpusat. Tim platform memiliki dan mengelola jaringan spoke ini. Jaringan ini berisi sumber daya beban kerja. Tim beban kerja memiliki sumber daya dalam jaringan ini, termasuk subnetnya.
Pastikan Anda mengomunikasikan persyaratan beban kerja kepada tim platform, dan meninjaunya secara berkala.
Penting
Untuk tim platform: Kecuali secara khusus diperlukan oleh beban kerja, jangan langsung melakukan peering jaringan spoke ke jaringan virtual spoke lain. Praktik ini melindungi tujuan segmentasi beban kerja. Tim Anda harus memfasilitasi semua koneksi jaringan virtual transitif.
Subnet jaringan virtual
Di jaringan virtual spoke, tim beban kerja membuat dan mengalokasikan subnet. Menempatkan kontrol untuk membatasi lalu lintas masuk dan keluar dari subnet membantu menyediakan segmentasi. Arsitektur ini menggunakan topologi subnet yang sama dengan arsitektur garis besar, yang memiliki subnet khusus untuk Application Gateway, VM front-end, load balancer, VM back-end, dan titik akhir privat.
Saat menyebarkan beban kerja di zona pendaratan Azure, Anda masih harus menerapkan kontrol jaringan. Organisasi mungkin memberlakukan pembatasan untuk melindungi dari eksfiltrasi data dan memastikan visibilitas untuk pusat operasi keamanan pusat (SOC) dan tim jaringan TI.
Dengan pendekatan ini, tim platform dapat mengoptimalkan pengeluaran organisasi secara keseluruhan dengan menggunakan layanan terpusat, daripada menyebarkan kontrol keamanan yang berlebihan untuk setiap beban kerja di seluruh organisasi. Dalam arsitektur ini, Azure Firewall adalah contoh layanan pusat. Ini tidak hemat biaya atau praktis bagi setiap tim beban kerja untuk mengelola instans firewall mereka sendiri. Kami merekomendasikan pendekatan terpusat untuk manajemen firewall.
Lalu lintas ingress
Arus lalu lintas ingress tetap sama dengan arsitektur garis besar.
Pemilik beban kerja bertanggung jawab atas sumber daya apa pun yang terkait dengan masuknya internet publik ke beban kerja Anda. Misalnya, dalam arsitektur ini, Application Gateway dan IP publiknya ditempatkan di jaringan spoke dan bukan jaringan hub. Beberapa organisasi mungkin menempatkan sumber daya dengan lalu lintas masuk dalam langganan konektivitas dengan menggunakan implementasi demiliterisasi terpusat (DMZ). Integrasi dengan topologi tertentu berada di luar cakupan untuk artikel ini.
Lalu lintas egress
Dalam arsitektur dasar, set skala komputer virtual beban kerja mengakses internet publik melalui Azure Load Balancer, tetapi lalu lintas tersebut tidak dibatasi.
Desain itu berbeda dalam arsitektur ini. Semua lalu lintas yang meninggalkan jaringan virtual spoke dirutekan melalui jaringan hub yang di-peering melalui firewall keluar. Rute dilampirkan ke semua subnet yang mungkin di jaringan spoke yang mengarahkan semua lalu lintas untuk IP yang tidak ditemukan di jaringan virtual lokal (0.0.0.0/0) ke Azure Firewall hub.
Unduh file Visio arsitektur ini.
Komunikasi beban kerja ke titik akhir privat untuk akses Key Vault tetap sama dengan arsitektur garis besar. Jalur itu dihilangkan dari diagram sebelumnya untuk brevity.
Tim beban kerja harus mengidentifikasi, mendokumen, dan mengomunikasikan semua arus lalu lintas keluar yang diperlukan untuk infrastruktur dan operasi beban kerja. Tim platform memungkinkan lalu lintas yang diperlukan, dan semua lalu lintas keluar yang tidak dikomunikasikan kemungkinan ditolak.
Mengontrol lalu lintas keluar lebih dari sekadar memastikan bahwa lalu lintas yang diharapkan diizinkan. Ini juga tentang memastikan hanya lalu lintas yang diharapkan yang diizinkan. Lalu lintas keluar yang tidak dikomunikasikan kemungkinan ditolak secara default, tetapi berada dalam kepentingan keamanan terbaik beban kerja untuk memastikan bahwa lalu lintas dirutekan dengan benar.
Tip
Dorong tim platform untuk menggunakan grup IP di Azure Firewall. Praktik ini memastikan bahwa kebutuhan lalu lintas keluar beban kerja Anda diwakili secara akurat dengan cakupan ketat hanya ke subnet sumber. Misalnya, aturan yang memungkinkan VM beban kerja menjangkau api.example.org tidak selalu menyiratkan bahwa sumber daya pendukung dalam jaringan virtual yang sama dapat mengakses titik akhir yang sama. Tingkat kontrol terperinci ini dapat meningkatkan postur keamanan jaringan Anda.
Komunikasikan persyaratan lalu lintas keluar yang unik kepada tim platform. Misalnya, jika beban kerja Anda membangun banyak koneksi bersamaan ke titik akhir jaringan eksternal, beri tahu tim platform. Kemudian tim platform dapat menyediakan implementasi Azure NAT Gateway yang sesuai atau menambahkan lebih banyak IP publik di firewall regional untuk mitigasi.
Organisasi Anda mungkin memiliki persyaratan yang mencegah penggunaan pola arsitektur, yang menggunakan IP publik milik beban kerja untuk keluar. Dalam hal ini, Anda dapat menggunakan Azure Policy untuk menolak IP publik pada kartu antarmuka jaringan (NIC) VM dan IP publik lainnya, selain titik masuk terkenal Anda.
Zona DNS Private
Arsitektur yang menggunakan titik akhir privat memerlukan zona DNS privat untuk bekerja dengan penyedia DNS. Tim beban kerja harus memiliki pemahaman yang jelas tentang persyaratan dan manajemen zona DNS privat dalam langganan yang disediakan tim platform. Zona DNS privat biasanya dikelola dalam skala besar dengan kebijakan DINE, yang memungkinkan Azure Firewall berfungsi sebagai proksi DNS yang andal dan mendukung aturan jaringan nama domain yang sepenuhnya memenuhi syarat (FQDN).
Dalam arsitektur ini, tim platform memastikan resolusi DNS privat yang andal untuk titik akhir tautan privat. Berkolaborasilah dengan tim platform Anda untuk memahami harapan mereka.
pengujian Koneksi ivity
Untuk arsitektur berbasis VM, ada beberapa alat pengujian yang dapat membantu menentukan garis pandang jaringan, perutean, dan masalah DNS. Anda dapat menggunakan alat pemecahan masalah tradisional, seperti netstat, , nslookupatau tcping. Selain itu, Anda dapat memeriksa pengaturan Dynamic Host Configuration Protocol (DHCP) dan DNS adaptor jaringan. Jika ada NIC, Anda memiliki lebih banyak kemampuan pemecahan masalah yang memungkinkan Anda melakukan pemeriksaan konektivitas dengan menggunakan Azure Network Watcher.
Akses operator
Seperti arsitektur garis besar, akses operasional melalui Azure Bastion didukung dalam arsitektur ini.
Namun, arsitektur garis besar menyebarkan Azure Bastion sebagai bagian dari beban kerja. Untuk organisasi khas yang mengadopsi zona pendaratan Azure, mereka menyebarkan Azure Bastion sebagai sumber daya pusat untuk setiap wilayah. Tim platform memiliki dan memelihara Azure Bastion, dan semua beban kerja dalam organisasi membagikannya. Untuk menunjukkan kasus penggunaan tersebut dalam arsitektur ini, Azure Bastion berada di jaringan hub dalam langganan konektivitas.
Identitas operator
Arsitektur ini menggunakan ekstensi autentikasi yang sama dengan arsitektur garis besar.
Catatan
Ketika operator masuk ke VM, mereka harus menggunakan identitas perusahaan mereka di penyewa ID Microsoft Entra mereka dan tidak berbagi perwakilan layanan di seluruh fungsi.
Selalu mulai dengan prinsip hak istimewa paling sedikit dan akses terperinci ke tugas alih-alih akses jangka panjang. Dalam konteks zona pendaratan, manfaatkan dukungan just-in-time (JIT) yang dikelola tim platform.
Kepatuhan patch dan peningkatan OS
Arsitektur garis besar menjelaskan pendekatan otonom untuk patching dan peningkatan. Ketika beban kerja terintegrasi dengan zona pendaratan, pendekatan tersebut mungkin berubah. Tim platform mungkin menentukan operasi patching sehingga semua beban kerja mematuhi persyaratan organisasi.
Pastikan bahwa proses patching mencakup semua komponen yang Anda tambahkan ke arsitektur. Misalnya, jika Anda memilih untuk menambahkan VM agen build untuk mengotomatiskan penyebaran, penskalaan, dan manajemen aplikasi, VM tersebut harus mematuhi persyaratan platform.
Pemantauan
Platform zona pendaratan Azure menyediakan sumber daya pengamatan bersama sebagai bagian dari langganan manajemen. Namun, kami sarankan Anda menyediakan sumber daya pemantauan Anda sendiri untuk memfasilitasi tanggung jawab kepemilikan beban kerja. Pendekatan ini konsisten dengan arsitektur garis besar.
Tim beban kerja menyediakan sumber daya pemantauan, yang meliputi:
Application Insights sebagai layanan pemantauan performa aplikasi (APM) untuk tim beban kerja.
Ruang kerja Analitik Log sebagai sink terpadu untuk semua log dan metrik yang dikumpulkan dari sumber daya Azure milik beban kerja dan kode aplikasi.
Unduh file Visio arsitektur ini.
Mirip dengan garis besar, semua sumber daya dikonfigurasi untuk mengirim log Diagnostik Azure ke ruang kerja Log Analytics yang disediakan tim beban kerja sebagai bagian dari penyebaran infrastruktur sebagai kode (IaC) sumber daya. Anda mungkin juga perlu mengirim log ke ruang kerja Analitik Log pusat. Di zona pendaratan Azure, ruang kerja tersebut berada dalam langganan manajemen.
Tim platform mungkin juga memiliki kebijakan DINE yang dapat mereka gunakan untuk mengonfigurasi Diagnostik untuk mengirim log ke langganan manajemen terpusat mereka. Penting untuk memastikan bahwa implementasi Anda tidak membatasi alur log tambahan.
Menghubungkan data dari beberapa sink
Log dan metrik beban kerja serta komponen infrastrukturnya disimpan di ruang kerja Log Analytics beban kerja. Namun, log dan metrik yang dipusatkan layanan, seperti Azure Firewall, ID Microsoft Entra, dan Azure Bastion, dibuat disimpan di ruang kerja Analitik Log pusat. Menghubungkan data dari beberapa sink bisa menjadi tugas yang kompleks.
Data berkorelasi sering digunakan selama respons insiden. Jika ada masalah dengan menghubungkan data dari beberapa sink, pastikan runbook triase untuk arsitektur ini mengatasinya dan menyertakan titik kontak organisasi jika masalah meluas di luar sumber daya beban kerja. Administrator beban kerja mungkin memerlukan bantuan dari administrator platform untuk menghubungkan entri log dari jaringan perusahaan, keamanan, atau layanan platform lainnya.
Penting
Untuk tim platform: Jika memungkinkan, berikan kontrol akses berbasis peran (RBAC) untuk mengkueri dan membaca sink log untuk sumber daya platform yang relevan. Aktifkan log firewall untuk evaluasi aturan jaringan dan aplikasi dan proksi DNS karena tim aplikasi dapat menggunakan informasi ini selama tugas pemecahan masalah.
Kebijakan Azure
Tim platform kemungkinan menerapkan kebijakan yang memengaruhi penyebaran beban kerja. Mereka sering menerapkan kebijakan DINE untuk menangani penyebaran otomatis ke dalam langganan zona pendaratan aplikasi. Kebijakan DINE dapat memodifikasi sumber daya beban kerja atau menambahkan sumber daya ke penyebaran Anda, yang dapat mengakibatkan perbedaan antara sumber daya yang secara deklaratif disebarkan melalui templat beban kerja dan sumber daya yang benar-benar digunakan permintaan pemrosesan. Solusi umumnya adalah memperbaiki perubahan tersebut dengan pendekatan imperatif, yang tidak ideal.
Untuk menghindari perbedaan tersebut, terlebih dahulu menggabungkan dan menguji perubahan yang dimulai platform ke dalam templat IaC Anda. Jika tim platform menggunakan kebijakan Azure yang bertentangan dengan persyaratan aplikasi, Anda dapat menegosiasikan resolusi dengan tim platform.
Penting
Zona pendaratan Azure menggunakan berbagai kebijakan DINE, misalnya kebijakan yang mengelola titik akhir privat dalam skala besar. Kebijakan ini memantau penyebaran titik akhir privat dan memperbarui Azure DNS di jaringan hub, yang merupakan bagian dari langganan yang dikelola platform. Tim beban kerja tidak memiliki izin untuk mengubah kebijakan di hub, dan tim platform tidak memantau penyebaran tim beban kerja untuk memperbarui DNS secara otomatis. Kebijakan DINE digunakan untuk menyediakan koneksi ini.
Kebijakan lain mungkin memengaruhi arsitektur ini, termasuk kebijakan yang:
- Memerlukan VM Windows untuk bergabung dengan domain Direktori Aktif. Kebijakan ini memastikan bahwa ekstensi VM diinstal dan dikonfigurasi
JoinADDomainExtension. Untuk informasi selengkapnya, lihat Menerapkan VM Windows untuk bergabung dengan domain Direktori Aktif. - Larang penerusan IP pada antarmuka jaringan.
Mengelola perubahan dari waktu ke waktu
Layanan dan operasi yang disediakan platform dianggap sebagai dependensi eksternal dalam arsitektur ini. Tim platform terus menerapkan perubahan, onboarding pengguna, dan menerapkan kontrol biaya. Tim platform, yang melayani organisasi, mungkin tidak memprioritaskan beban kerja individual. Perubahan pada dependensi tersebut, baik perubahan gambar emas, modifikasi firewall, patching otomatis, atau perubahan aturan, dapat memengaruhi beberapa beban kerja.
Oleh karena itu, tim beban kerja dan platform harus berkomunikasi secara efisien dan tepat waktu untuk mengelola semua dependensi eksternal. Penting untuk menguji perubahan, sehingga tidak berdampak negatif pada beban kerja.
Perubahan platform yang memengaruhi beban kerja
Dalam arsitektur ini, tim platform mengelola sumber daya berikut. Perubahan pada sumber daya ini berpotensi memengaruhi keandalan, keamanan, operasi, dan target performa beban kerja. Penting untuk mengevaluasi perubahan ini sebelum tim platform menerapkannya untuk menentukan bagaimana perubahan tersebut memengaruhi beban kerja.
Kebijakan Azure: Perubahan pada kebijakan Azure dapat memengaruhi sumber daya beban kerja dan dependensinya. Misalnya, mungkin ada perubahan kebijakan langsung atau pergerakan zona pendaratan ke dalam hierarki grup manajemen baru. Perubahan ini mungkin lugas sampai ada penyebaran baru, jadi penting untuk mengujinya secara menyeluruh.
Aturan firewall: Modifikasi pada aturan firewall dapat memengaruhi jaringan virtual beban kerja atau aturan yang berlaku secara luas di semua lalu lintas. Modifikasi ini dapat mengakibatkan lalu lintas yang diblokir dan bahkan kegagalan proses senyap, seperti aplikasi patch OS yang gagal. Potensi masalah ini berlaku untuk firewall Azure keluar dan aturan NSG yang diterapkan Azure Virtual Network Manager.
Sumber daya bersama: Perubahan pada SKU atau fitur pada sumber daya bersama dapat memengaruhi beban kerja.
Perutean di jaringan hub: Perubahan dalam sifat perutean transitif di hub berpotensi memengaruhi fungsionalitas beban kerja jika beban kerja bergantung pada perutean ke jaringan virtual lainnya.
Host Azure Bastion: Perubahan pada ketersediaan atau konfigurasi host Azure Bastion dapat memengaruhi operasi beban kerja. Pastikan bahwa perubahan pola akses jump box memiliki akses rutinitas, ad-hoc, dan darurat yang efektif.
Perubahan kepemilikan: Mengomunikasikan setiap perubahan kepemilikan dan titik kontak ke tim beban kerja karena dapat memengaruhi permintaan manajemen dan dukungan beban kerja.
Perubahan beban kerja yang memengaruhi platform
Contoh berikut adalah perubahan beban kerja dalam arsitektur ini yang harus Anda komunikasikan ke tim platform. Penting bagi tim platform untuk memvalidasi keandalan, keamanan, operasi, dan target performa layanan platform terhadap perubahan tim beban kerja baru sebelum diterapkan.
Keluarnya jaringan: Pantau peningkatan signifikan keluar jaringan untuk mencegah beban kerja menjadi tetangga yang bising pada perangkat jaringan. Masalah ini berpotensi memengaruhi target performa atau keandalan beban kerja lainnya.
Akses publik: Perubahan akses publik ke komponen beban kerja mungkin memerlukan pengujian lebih lanjut. Tim platform mungkin merelokasi beban kerja ke grup manajemen yang berbeda.
Peringkat kekritisan bisnis: Jika ada perubahan pada perjanjian tingkat layanan (SLA) beban kerja, Anda mungkin memerlukan pendekatan kolaborasi baru antara platform dan tim beban kerja.
Perubahan kepemilikan: Mengomunikasikan perubahan kepemilikan dan titik kontak ke tim platform.
Perubahan persyaratan bisnis beban kerja
Untuk mempertahankan tujuan tingkat layanan (SLO) beban kerja, tim platform mungkin perlu terlibat dalam perubahan arsitektur beban kerja. Perubahan ini mungkin memerlukan manajemen perubahan dari tim platform atau validasi bahwa tata kelola yang ada mendukung persyaratan yang diubah.
Misalnya, komunikasikan perubahan pada alur keluar yang sebelumnya tidak diizinkan sehingga tim platform dapat menambahkan alur tersebut di firewall, Virtual Network Manager, atau komponen lain untuk mendukung lalu lintas yang diperlukan. Sebaliknya, jika alur keluar yang diizinkan sebelumnya tidak lagi diperlukan, tim platform harus memblokir alur tersebut untuk menjaga keamanan beban kerja. Komunikasikan juga perubahan perutean ke jaringan virtual lain atau titik akhir lintas lokasi atau perubahan pada komponen arsitektur. Setiap sumber daya tunduk pada kebijakan dan kontrol firewall yang berpotensi keluar.
Keandalan
Arsitektur ini selaras dengan jaminan keandalan dalam arsitektur garis besar.
Target keandalan
SLO komposit maksimum yang mungkin lebih rendah dari SLO komposit garis besar karena komponen seperti kontrol jaringan keluar. Komponen-komponen ini, umum di lingkungan zona pendaratan, tidak unik untuk arsitektur ini. SLO juga berkurang jika tim beban kerja secara langsung mengontrol layanan Azure ini.
Meskipun SLO dengan kemungkinan maksimum yang lebih rendah, aspek keandalan utama adalah pembagian komponen beban kerja di seluruh tim fungsional. Dengan metode ini, tim beban kerja mendapat manfaat dari tim khusus yang berfokus pada pengoperasian infrastruktur penting yang digunakan beban kerja ini dan beban kerja lainnya.
Untuk informasi selengkapnya, lihat Rekomendasi untuk menentukan target keandalan.
Dependensi kritis
Lihat semua fungsionalitas yang dilakukan beban kerja di platform dan zona pendaratan aplikasi sebagai dependensi. Rencana respons insiden mengharuskan tim beban kerja mengetahui titik dan metode informasi kontak untuk dependensi ini. Sertakan juga dependensi ini dalam analisis mode kegagalan beban kerja (FMA).
Untuk arsitektur ini, pertimbangkan dependensi berikut:
Firewall keluar: Firewall keluar terpusat, dibagikan oleh beberapa beban kerja, mengalami perubahan yang tidak terkait dengan beban kerja.
Kelelahan port jaringan: Lonjakan penggunaan dari semua beban kerja yang berbagi perangkat jaringan dapat menyebabkan saturasi jaringan atau kelelahan port pada firewall keluar.
Kebijakan DINE: Kebijakan DINE untuk zona DNS privat Azure DNS (atau dependensi lain yang disediakan platform) adalah upaya terbaik, tanpa SLA pada eksekusi. Keterlambatan konfigurasi DNS dapat menyebabkan keterlambatan kesiapan aplikasi untuk menangani lalu lintas.
Kebijakan grup manajemen: Kebijakan yang konsisten di antara lingkungan adalah kunci untuk keandalan. Pastikan bahwa lingkungan praproduksi mirip dengan lingkungan produksi untuk memberikan pengujian yang akurat dan untuk mencegah penyimpangan khusus lingkungan yang dapat memblokir penyebaran atau skala. Untuk informasi selengkapnya, lihat Mengelola lingkungan pengembangan aplikasi di zona pendaratan Azure.
Banyak dari pertimbangan ini mungkin ada tanpa zona pendaratan Azure, tetapi beban kerja dan tim platform perlu secara kolaboratif mengatasi masalah ini untuk memastikan kebutuhan terpenuhi.
Untuk informasi selengkapnya, lihat Rekomendasi untuk melakukan analisis mode kegagalan.
Keamanan
Pertimbangan keamanan untuk arsitektur ini dibawa dari arsitektur garis besar. Rekomendasi di bagian berikut didasarkan pada daftar periksa tinjauan desain keamanan di Well-Architected Framework.
Kontrol jaringan
Konfigurasikan kontrol jaringan dengan benar untuk memastikan bahwa beban kerja Anda aman.
Lalu lintas ingress
Anda dapat mengisolasi beban kerja dari spoke beban kerja lain dalam organisasi Anda melalui NSG pada subnet Anda atau sifat atau kontrol nontransitif di hub regional. Buat NSG komprehensif yang hanya mengizinkan persyaratan jaringan masuk aplikasi Anda dan infrastrukturnya. Kami menyarankan agar Anda tidak hanya mengandalkan sifat nontransitif jaringan hub untuk keamanan.
Tim platform kemungkinan menerapkan kebijakan Azure untuk memastikan bahwa Application Gateway mengatur Web Application Firewall ke mode tolak, untuk membatasi jumlah IP publik yang tersedia untuk langganan Anda, dan pemeriksaan lainnya. Selain kebijakan tersebut, tim beban kerja harus memiliki tanggung jawab untuk menyebarkan kebijakan yang berpusat pada beban kerja yang memperkuat postur keamanan ingress.
Tabel berikut ini memperlihatkan contoh kontrol ingress dalam arsitektur ini.
| Sumber | Tujuan | Kontrol beban kerja | Kontrol platform |
|---|---|---|---|
| Internet | Arus lalu lintas pengguna | Corong semua permintaan melalui aturan NSG, Web Application Firewall, dan perutean sebelum memungkinkan lalu lintas publik beralih ke lalu lintas privat yang memasuki VM front-end | Tidak |
| Azure Bastion | Akses operator ke VM | NSG pada subnet VM yang memblokir semua lalu lintas ke port akses jarak jauh, kecuali bersumber dari subnet Azure Bastion platform yang ditunjuk | Tidak |
| Spoke lainnya | Tidak | Diblokir melalui aturan NSG | Perutean nontransitif atau aturan Azure Firewall dalam kasus hub aman Azure Virtual WAN |
Lalu lintas egress
Terapkan aturan NSG yang mengekspresikan persyaratan konektivitas keluar yang diperlukan dari solusi Anda dan tolak yang lainnya. Jangan hanya mengandalkan kontrol jaringan hub. Sebagai operator beban kerja, Anda memiliki tanggung jawab untuk menghentikan lalu lintas keluar yang tidak diinginkan sedekat sumber yang dapat dipraktekkan.
Ketahuilah bahwa saat Anda memiliki subnet dalam jaringan virtual, tim platform kemungkinan membuat aturan firewall untuk secara khusus mewakili persyaratan yang diambil sebagai bagian dari proses penjual langganan Anda. Pastikan bahwa perubahan subnet dan penempatan sumber daya selama masa pakai arsitektur Anda masih kompatibel dengan permintaan asli Anda. Atau Anda dapat bekerja dengan tim jaringan Anda untuk memastikan kelangsungan kontrol keluar akses paling sedikit.
Tabel berikut menunjukkan contoh egress dalam arsitektur ini.
| Titik akhir | Tujuan | Kontrol beban kerja (NSG) | Kontrol platform (hub) |
|---|---|---|---|
| ntp.ubuntu.com | Protokol Waktu Jaringan (NTP) untuk VM linux | UDP/123 ke internet pada subnet VM front-end (firewall keluar mempersempit pembukaan luas ini) | Jatah aturan jaringan firewall untuk yang sama dengan kontrol beban kerja |
| Titik akhir Windows Update | Fungsionalitas Windows Update dari server Microsoft | TCP/443 dan TCP/80 ke internet pada subnet VM back-end (firewall keluar mempersempit pembukaan luas ini) | Aturan tunjangan firewall dengan tag FQDN dari WindowsUpdate |
| Memantau titik akhir agen | Lalu lintas yang diperlukan untuk ekstensi Monitor pada VM | TCP/443 ke internet pada kedua subnet VM (firewall keluar mempersempit pembukaan luas ini) | Jatah aturan aplikasi firewall yang diperlukan untuk semua FQDN tertentu pada TCP/443 |
| nginx.org | Untuk menginstal Nginx (komponen aplikasi contoh) langsung dari vendor | TCP/443 ke internet pada subnet VM front-end (firewall keluar mempersempit pembukaan luas ini) | Jatah aturan aplikasi firewall yang diperlukan untuk nginx.org pada TCP/443 |
| Key Vault | Untuk mengimpor sertifikat TLS (Keamanan Lapisan Transportasi) di Application Gateway dan VM | - TCP/443 ke subnet titik akhir privat dari kedua subnet VM ke subnet titik akhir privat - TCP/443 ke subnet titik akhir privat dari subnet Application Gateway - TCP/443 dari VM yang ditandai dengan penetapan kelompok keamanan aplikasi (ASG) yang diperlukan dan subnet Application Gateway |
Tidak |
DDoS Protection
Tentukan siapa yang bertanggung jawab untuk menerapkan paket DDoS Protection yang mencakup semua IP publik solusi Anda. Tim platform mungkin menggunakan paket perlindungan IP atau bahkan mungkin menggunakan Azure Policy untuk memberlakukan rencana perlindungan jaringan virtual. Arsitektur ini harus memiliki cakupan karena melibatkan IP publik untuk masuk dari internet.
Untuk informasi selengkapnya, lihat Rekomendasi untuk jaringan dan konektivitas.
Manajemen rahasia
Untuk manajemen rahasia, arsitektur ini mengikuti arsitektur garis besar.
Sebagai tim beban kerja, lanjutkan menyimpan rahasia Anda di instans Key Vault Anda. Sebarkan lebih banyak instans sesuai kebutuhan untuk mendukung operasi aplikasi dan infrastruktur Anda.
Untuk informasi selengkapnya, lihat Rekomendasi untuk melindungi rahasia aplikasi.
Pengoptimalan biaya
Untuk sumber daya beban kerja, strategi pengoptimalan biaya dalam arsitektur garis besar juga berlaku untuk arsitektur ini.
Arsitektur ini sangat mendapat manfaat dari sumber daya platform zona pendaratan Azure. Bahkan jika Anda menggunakan sumber daya tersebut melalui model penagihan balik, keamanan tambahan dan konektivitas lintas lokasi lebih hemat biaya daripada mengelola sumber daya tersebut sendiri.
Tim platform mengelola sumber daya berikut dalam arsitektur ini. Sumber daya ini sering berbasis konsumsi (penagihan balik) atau berpotensi bebas ke tim beban kerja.
- Azure Firewall
- Informasi keamanan dan manajemen acara (SIEM)
- Host Azure Bastion
- Konektivitas lintas lokasi, seperti ExpressRoute
Manfaatkan penawaran terpusat lainnya dari tim platform Anda untuk memperluas manfaat tersebut ke beban kerja Anda tanpa mengorbankan SLO, tujuan waktu pemulihan (RTO), atau tujuan titik pemulihan (RPO).
Untuk informasi selengkapnya, lihat Rekomendasi untuk mengumpulkan dan meninjau data biaya.
Menyebarkan skenario ini
Penyebaran untuk arsitektur referensi ini tersedia di GitHub.
Langkah selanjutnya
Tinjau kolaborasi dan detail teknis yang dibagikan antara tim beban kerja dan tim platform.