Menyesuaikan arsitektur zona pendaratan Azure untuk memenuhi persyaratan

Sebagai bagian dari panduan zona pendaratan Azure, beberapa opsi implementasi referensi tersedia:

• Zona pendaratan Azure dengan Azure Virtual WAN
• Zona pendaratan Azure dengan hub dan spoke tradisional
• Fondasi zona pendaratan Azure
• Zona pendaratan Azure untuk perusahaan kecil

Opsi ini dapat membantu organisasi Anda memulai dengan cepat dengan menggunakan konfigurasi yang memberikan arsitektur konseptual zona pendaratan Azure dan praktik terbaik di area desain.

Implementasi referensi didasarkan pada praktik terbaik dan pembelajaran tim Microsoft dari keterlibatan dengan pelanggan dan mitra. Pengetahuan ini mewakili sisi "80" dari aturan 80/20. Berbagai implementasi mengambil posisi pada keputusan teknis yang merupakan bagian dari proses desain arsitektur.

Karena tidak semua kasus penggunaan sama, tidak semua organisasi dapat menggunakan pendekatan implementasi dengan cara yang tepat. Anda perlu memahami pertimbangan ketika persyaratan untuk penjahitan diidentifikasi.

Apa itu arketipe zona pendaratan di zona pendaratan Azure?

Arketipe zona pendaratan menjelaskan apa yang perlu benar untuk memastikan zona pendaratan (langganan Azure) memenuhi persyaratan lingkungan dan kepatuhan yang diharapkan pada cakupan tertentu. Contohnya meliputi:

• Penetapan Azure Policy.
• Penetapan kontrol akses berbasis peran (RBAC).
• Sumber daya yang dikelola secara terpusat seperti jaringan.

Pertimbangkan setiap grup manajemen dalam hierarki sumber daya sebagai berkontribusi pada output arketipe zona pendaratan akhir karena cara kerja pewarisan kebijakan di Azure. Pikirkan tentang apa yang diterapkan pada tingkat atas dalam hierarki sumber daya saat Anda merancang tingkat yang lebih rendah.

Ada hubungan dekat antara grup manajemen dan arketipe zona pendaratan, tetapi grup manajemen saja bukan arketipe zona pendaratan. Sebaliknya, ini merupakan bagian dari kerangka kerja yang digunakan untuk mengimplementasikan masing-masing arketipe zona pendaratan di lingkungan Anda.

Anda dapat melihat hubungan ini dalam arsitektur konseptual zona pendaratan Azure. Penetapan kebijakan dibuat di grup manajemen akar menengah, misalnya Contoso, untuk pengaturan yang harus berlaku untuk semua beban kerja. Lebih banyak penetapan kebijakan dibuat pada tingkat hierarki yang lebih rendah untuk persyaratan yang lebih spesifik.

Penempatan langganan dalam hierarki grup manajemen menentukan kumpulan penetapan Azure Policy dan kontrol akses (IAM) yang dihasilkan yang diwariskan, diterapkan, dan diberlakukan ke zona arahan tertentu (langganan Azure).

Proses dan alat lainnya mungkin diperlukan untuk memastikan zona pendaratan memiliki sumber daya yang dikelola secara terpusat yang diperlukan. Beberapa contohnya termasuk:

• Pengaturan diagnostik untuk mengirim data log aktivitas ke ruang kerja Analitik Log.
• Pengaturan ekspor berkelanjutan untuk Microsoft Defender untuk Cloud.
• Jaringan virtual dengan ruang alamat IP terkelola untuk beban kerja aplikasi.
• Penautan jaringan virtual ke Perlindungan Jaringan penolakan layanan terdistribusi (DDoS).

Catatan

Dalam implementasi referensi zona pendaratan Azure, kebijakan Azure dengan DeployIfNotExists efek dan Modifydigunakan untuk mencapai penyebaran beberapa sumber daya sebelumnya. Mereka mengikuti prinsip desain tata kelola yang didorong kebijakan.

Untuk informasi selengkapnya, lihat Mengadopsi pagar pembatas berbasis kebijakan.

Arketipe bawaan untuk arsitektur konseptual zona pendaratan Azure

Arsitektur konseptual mencakup contoh arketipe zona pendaratan untuk beban kerja aplikasi seperti corp dan online. Arketipe ini mungkin berlaku untuk organisasi Anda dan memenuhi kebutuhan Anda. Anda mungkin ingin membuat perubahan pada arketipe ini atau membuat yang baru. Keputusan Anda bergantung pada kebutuhan dan persyaratan organisasi Anda.

Tip

Untuk meninjau arketipe zona pendaratan di akselerator zona pendaratan Azure, lihat Grup manajemen di akselerator zona pendaratan Azure.

Anda mungkin juga ingin membuat perubahan di tempat lain dalam hierarki sumber daya. Saat Anda merencanakan hierarki untuk implementasi zona pendaratan Azure untuk organisasi Anda, ikuti panduan di area desain.

Contoh arketipe zona pendaratan berikut dari arsitektur konseptual membantu Anda memahami tujuan dan tujuan penggunaannya:

Arketipe zona pendaratan (grup manajemen)	Tujuan atau penggunaan
Corp	Grup manajemen khusus untuk zona arahan perusahaan. Grup ini adalah untuk beban kerja yang memerlukan konektivitas atau konektivitas hibrid dengan jaringan perusahaan melalui hub dalam langganan konektivitas.
Online	Grup manajemen khusus untuk zona arahan online. Grup ini adalah untuk beban kerja yang mungkin memerlukan konektivitas masuk/keluar internet langsung atau untuk beban kerja yang mungkin tidak memerlukan jaringan virtual.
Kotak Pasir	Grup manajemen khusus untuk langganan yang hanya akan digunakan untuk pengujian dan eksplorasi oleh organisasi. Langganan ini akan terputus dengan aman dari zona arahan perusahaan dan online. Sandbox juga memiliki serangkaian kebijakan yang kurang ketat yang ditetapkan untuk mengaktifkan pengujian, eksplorasi, dan konfigurasi layanan Azure.

Skenario di mana penjahitan mungkin diperlukan

Seperti disebutkan, kami menyediakan arketipe zona pendaratan umum di arsitektur konseptual zona pendaratan Azure. Mereka adalah corp dan online. Arketipe ini tidak diperbaiki dan bukan satu-satunya arketipe zona pendaratan yang diizinkan untuk beban kerja aplikasi. Anda mungkin perlu menyesuaikan arketipe zona pendaratan agar sesuai dengan kebutuhan dan kebutuhan Anda.

Sebelum Anda menyesuaikan arketipe zona pendaratan, penting untuk memahami konsep dan juga memvisualisasikan area hierarki yang kami sarankan Anda sesuaikan. Diagram berikut menunjukkan hierarki default arsitektur konseptual zona pendaratan Azure.

Dua area hierarki disorot. Satu berada di bawah Zona Pendaratan, dan yang lainnya berada di bawah Platform.

Menyesuaikan arketipe zona pendaratan aplikasi

Perhatikan area yang disorot dengan warna biru di bawah grup manajemen Zona Pendaratan. Ini adalah tempat paling umum dan paling aman dalam hierarki untuk menambahkan lebih banyak arketipe untuk memenuhi persyaratan baru atau lebih yang tidak dapat ditambahkan sebagai lebih banyak penetapan kebijakan ke arketipe yang ada dengan menggunakan hierarki yang ada.

Misalnya, Anda mungkin memiliki persyaratan baru untuk menghosting serangkaian beban kerja aplikasi yang perlu memenuhi persyaratan kepatuhan industri kartu pembayaran (PCI). Tetapi persyaratan baru ini tidak perlu berlaku untuk semua beban kerja di seluruh estat Anda.

Ada cara sederhana dan aman untuk memenuhi persyaratan baru ini. Buat grup manajemen baru yang disebut PCI di bawah grup manajemen Zona Pendaratan dalam hierarki. Anda dapat menetapkan lebih banyak kebijakan seperti inisiatif kebijakan kepatuhan peraturan Microsoft Defender untuk Cloud untuk PCI v3.2.1:2018 ke grup manajemen PCI baru. Tindakan ini membentuk arketipe baru.

Sekarang Anda dapat menempatkan langganan Azure baru atau memindahkan langganan Azure yang sudah ada ke dalam grup manajemen PCI baru untuk membuatnya mewarisi kebijakan yang diperlukan dan membentuk arketipe baru.

Contoh lain adalah Microsoft Cloud for Sovereignty, yang menambahkan grup manajemen untuk komputasi rahasia dan selaras untuk digunakan dalam industri yang diatur. Microsoft Cloud for Sovereignty menyediakan alat, panduan, dan pagar pembatas untuk adopsi cloud publik dengan kontrol kedaulatan yang sesuai.

Tip

Anda perlu mengetahui apa yang harus dipertimbangkan dan apa yang terjadi saat Anda memindahkan langganan Azure antara grup manajemen sehubungan dengan RBAC dan Azure Policy. Untuk informasi selengkapnya, lihat Transisi lingkungan Azure yang ada ke arsitektur konseptual zona pendaratan Azure.

Menyesuaikan arketipe zona pendaratan platform

Anda mungkin juga ingin menyesuaikan area yang disorot dengan warna oranye di bawah grup manajemen Platform . Zona di area ini dikenal sebagai zona pendaratan platform.

Misalnya, Anda mungkin memiliki tim SOC khusus yang memerlukan arketipenya sendiri untuk menghosting beban kerjanya. Beban kerja ini perlu memenuhi persyaratan penugasan Azure Policy dan RBAC yang berbeda dari grup manajemen Manajemen .

Buat grup manajemen Keamanan baru di bawah grup manajemen Platform dalam hierarki. Anda dapat menetapkan penetapan Azure Policy dan RBAC yang diperlukan untuk itu.

Sekarang Anda dapat menempatkan langganan Azure baru atau memindahkan langganan Azure yang sudah ada ke dalam grup manajemen Keamanan baru untuk membuatnya mewarisi kebijakan yang diperlukan dan membentuk arketipe baru.

Contoh hierarki zona pendaratan Azure yang disesuaikan

Diagram berikut menunjukkan hierarki zona pendaratan Azure yang disesuaikan. Ini menggunakan contoh dari diagram sebelumnya.

Poin yang perlu dipertimbangkan

Pertimbangkan poin-poin berikut saat Anda berpikir untuk menyesuaikan implementasi arketipe zona pendaratan Azure Anda dalam hierarki:

• Menyesuaikan hierarki tidak wajib. Arketipe dan hierarki default yang kami sediakan cocok untuk sebagian besar skenario.

• Jangan membuat ulang hierarki, tim, atau departemen organisasi Anda di arketipe.

• Selalu coba bangun pada arketipe dan hierarki yang ada untuk memenuhi persyaratan baru.

• Hanya buat arketipe baru saat benar-benar diperlukan.

  Misalnya, persyaratan kepatuhan baru seperti PCI hanya diperlukan untuk subset beban kerja aplikasi dan tidak perlu berlaku untuk semua beban kerja.

• Hanya buat arketipe baru di area yang disorot yang diperlihatkan dalam diagram sebelumnya.

• Hindari melampaui kedalaman hierarki empat lapisan untuk menghindari kompleksitas dan pengecualian yang tidak perlu. Perluas arketipe secara horizontal alih-alih secara vertikal dalam hierarki.

• Jangan membuat arketipe untuk lingkungan seperti pengembangan, pengujian, dan produksi.

  Untuk informasi selengkapnya, lihat Bagaimana cara menangani zona pendaratan beban kerja dev/test/production di arsitektur konseptual zona pendaratan Azure?

• Jika berasal dari lingkungan brownfield atau mencari pendekatan untuk menghosting langganan di Grup Manajemen Zona Pendaratan dengan kebijakan dalam mode penegakan "hanya audit", tinjau Skenario: Transisi lingkungan dengan menduplikasi grup manajemen zona pendaratan