Pendekatan pengujian untuk zona pendaratan Azure

Catatan

Artikel ini hanya berlaku untuk Microsoft Azure dan bukan untuk penawaran Microsoft Cloud lainnya seperti Microsoft 365 atau Microsoft Dynamics 365.

Beberapa organisasi mungkin ingin menguji definisi dan penetapan Azure Policy pada platform zona pendaratan Azure, peran dan penetapan kustom kontrol akses berbasis peran (RBAC), dan sebagainya. Pengujian dapat diselesaikan melalui otomatisasi dengan menggunakan templat Azure Resource Manager (templat ARM), Terraform, Bicep, atau secara manual melalui portal Microsoft Azure. Panduan ini menyediakan pendekatan yang dapat digunakan untuk menguji perubahan dan dampaknya pada penyebaran platform zona pendaratan Azure.

Artikel ini juga dapat digunakan dengan panduan otomatisasi Platform dan area desain penting DevOps yang berkaitan dengan tim dan tugas fungsi PlatformOps dan Central. Selain itu, panduan dalam Mengadopsi pagar pembatas berbasis kebijakan dapat dikombinasikan untuk teknik yang digunakan dalam meluncurkan perubahan kebijakan pada penerapan zona pendaratan Azure.

Panduan ini paling cocok untuk organisasi dengan proses manajemen perubahan yang kuat yang mengatur perubahan pada hierarki grup manajemen produksi. Hierarki grup pengelolaan kenari dapat digunakan secara independen untuk menulis dan menguji penyebaran sebelum Anda menyebarkannya ke lingkungan produksi.

Catatan

Istilah kenari digunakan untuk menghindari kebingungan dengan lingkungan pengembangan atau lingkungan pengujian. Nama ini hanya digunakan sebagai ilustrasi. Anda dapat menentukan nama apa pun yang Anda anggap sesuai untuk lingkungan zona pendaratan Azure kenari Anda.

Demikian pula, istilah lingkungan/hierarki produksi digunakan di seluruh panduan ini untuk merujuk ke hierarki grup manajemen zona pendaratan Azure yang mungkin dimiliki organisasi Anda yang berisi langganan dan sumber daya Azure untuk beban kerja Anda.

Definisi platform

Penting

Panduan ini bukan untuk lingkungan pengembangan atau lingkungan pengujian yang akan digunakan oleh pemilik aplikasi atau layanan yang dikenal sebagai zona pendaratan, beban kerja, aplikasi, atau layanan. Ini ditempatkan dan ditangani di dalam hierarki grup manajemen zona pendaratan Azure pada lingkungan produksi dan tata kelola yang terkait (RBAC dan Azure Policy).

Untuk panduan tentang pengembangan, pengujian, pengujian penerimaan pengguna (UAT), dan lingkungan produksi untuk beban kerja aplikasi dan tim, lihat Mengelola lingkungan pengembangan aplikasi di zona pendaratan Azure.

Panduan ini hanya untuk pengujian tingkat platform dan perubahan dalam konteks zona pendaratan Azure.

Zona pendaratan Azure membantu Anda merancang dan menyebarkan komponen platform Azure yang diperlukan untuk memungkinkan Anda membangun dan mengoprasionalkan zona pendaratan dalam skala besar.

Sumber daya platform dalam lingkup untuk artikel ini dan pendekatan pengujian ini adalah:

Produk atau Layanan	Penyedia dan jenis sumber daya
Grup pengelolaan	Microsoft.Management/managementGroups
Asosiasi langganan kelompok manajemen	Microsoft.Management/managementGroups/subscriptions
Definisi kebijakan	Microsoft.Authorization/policyDefinitions
Definisi inisiatif kebijakan atau definisi yang ditetapkan kebijakan	Microsoft.Authorization/policySetDefinitions
Penugasan kebijakan	Microsoft.Authorization/policyAssignments
Definisi peran RBAC	Microsoft.Authorization/roleDefinitions
Penetapan peran RBAC	Microsoft.Authorization/roleAssignments
Langganan	Microsoft.Subscription/aliases

Contoh skenario dan hasil

Contoh skenario ini adalah organisasi yang ingin menguji dampak dan hasil Azure Policy baru untuk mengatur sumber daya dan pengaturan di semua zona pendaratan, sesuai dengan Prinsip desain tata kelola berbasis kebijakan. Mereka tidak ingin membuat perubahan ini secara langsung ke lingkungan produksi karena berkaitan dengan dampak yang mungkin terjadi.

Menggunakan lingkungan kenari untuk menguji perubahan platform ini memungkinkan organisasi mengimplementasikan dan meninjau dampak dan hasil perubahan Azure Policy. Proses ini akan memastikannya memenuhi persyaratan organisasi sebelum mereka menerapkan Azure Policy ke lingkungan produksi.

Skenario serupa mungkin merupakan perubahan pada penetapan peran Azure RBAC dan keanggotaan grup Microsoft Entra. Ini mungkin memerlukan bentuk pengujian sebelum perubahan dibuat dalam lingkungan produksi.

Penting

Ini bukan pendekatan atau pola penyebaran umum untuk sebagian besar pelanggan. Ini bukan merupakan kewajiban untuk penerapan zona pendaratan Azure.

Gambar 1: Hierarki grup pengelolaan Kenari.

Seperti yang ditunjukkan oleh diagram, seluruh hierarki grup manajemen produksi dari zona penempatan Azure diduplikasi di bawah Tenant Root Group. Nama kenari ditambahkan ke nama dan ID tampilan grup pengelolaan. ID harus unik dalam satu tenant Microsoft Entra.

Catatan

Nama tampilan grup manajemen canary dapat sama dengan nama tampilan grup manajemen produksi. Hal ini dapat menyebabkan pengguna bingung. Karena itu, sebaiknya tambahkan nama "kenari" ke nama tampilan dan id mereka.

Hierarki grup manajemen kenari kemudian digunakan untuk menyederhanakan pengujian jenis sumber daya berikut:

• Grup manajemen
  • Penempatan langganan
• RBAC
  • Peran (bawaan dan khusus)
  • Penetapan
• Azure Policy
  • Definisi (bawaan dan khusus)
  • Inisiatif, juga dikenal sebagai definisi yang ditetapkan
  • Penetapan

Bagaimana jika Anda tidak ingin menerapkan hierarki grup manajemen canary?

Jika Anda tidak ingin menyebarkan hierarki grup manajemen kenari, Anda dapat menguji sumber daya platform dalam hierarki lingkungan produksi dengan menggunakan langganan kotak pasir seperti yang ditunjukkan dalam diagram.

Gambar 2: Hierarki grup manajemen landing zone Azure yang menyoroti sandbox.

Untuk menguji Azure Policy dan RBAC dalam skenario ini, Anda memerlukan satu langganan Azure dengan peran RBAC Pemilik yang ditetapkan ke identitas yang ingin Anda gunakan untuk menyelesaikan pengujian, misalnya, Akun Pengguna, Perwakilan Layanan, atau Identitas Layanan Terkelola. Konfigurasi ini memungkinkan Anda menulis, menetapkan, dan memulihkan definisi dan penugasan Azure Policy dalam cakupan langganan kotak pasir saja.

Pendekatan kotak pasir ini juga dapat digunakan untuk pengujian RBAC dalam langganan, misalnya, jika Anda mengembangkan peran RBAC kustom baru untuk memberikan izin untuk kasus penggunaan tertentu. Semua pengujian ini dapat dilakukan di dalam langganan sandbox untuk diuji terlebih dahulu sebelum Anda membuat dan menetapkan peran yang lebih tinggi dalam hierarki.

Manfaat dari pendekatan ini adalah langganan kotak pasir dapat digunakan selama waktu yang diperlukan, dan kemudian dihapus dari lingkungan.

Namun, pendekatan ini tidak memungkinkan Anda menguji dengan pewarisan kebijakan RBAC dan Azure dari hierarki grup pengelolaan.

Panduan implementasi

Di bawah ini adalah panduan tentang cara menerapkan dan menggunakan hierarki grup manajemen canary untuk Azure landing zones, bersama dengan hierarki grup manajemen zona pendaratan Azure di lingkungan produksi.

Peringatan

Jika Anda menggunakan portal untuk menyebarkan dan mengelola lingkungan zona pendaratan Azure Anda saat ini, mungkin sulit untuk mengadopsi dan menggunakan pendekatan kenari secara efisien karena risiko tinggi lingkungan produksi dan kenari sering tidak sinkron dan karenanya tidak menyediakan hierarki dan lingkungan produksi seperti replika.

Pertimbangkan untuk pindah ke pendekatan penyebaran Infrastruktur sebagai Kode (IaC) untuk zona pendaratan Azure, seperti yang tercantum di atas, jika Anda berada dalam skenario ini. Atau waspadai potensi risiko penyimpangan konfigurasi antara kenari dan produksi dan lanjutkan dengan hati-hati. Untuk informasi selengkapnya, lihat Menggunakan IaC untuk memperbarui zona pendaratan Azure.

1. Gunakan perwakilan layanan Microsoft Entra yang terpisah (SPN) atau Identitas Terkelola (MI) yang diberi izin untuk mengakses lingkungan produksi yang relevan atau lingkungan pengujian awal dalam hierarki grup manajemen zona pendaratan Azure.
   • Panduan ini mengikuti prinsip hak akses seminimal mungkin (PoLP)
2. Gunakan folder terpisah dalam repositori git, cabang, atau repositori untuk menahan IaC untuk lingkungan produksi dan lingkungan kenari penyebaran zona pendaratan Azure.
   • Menggunakan prinsipal layanan Microsoft Entra (SPN) atau Identitas Dikelola (MI) yang relevan sebagai bagian dari alur CI/CD, tergantung pada hierarki mana yang diterapkan.
3. Terapkan kebijakan atau keamanan pada cabang git untuk lingkungan canary seperti yang sudah Anda terapkan pada lingkungan produksi.
   • Pertimbangkan untuk mengurangi jumlah pemberi izin dan memeriksa lingkungan kenari agar gagal dengan cepat.
4. Gunakan tindakan Azure Pipelines atau GitHub yang sama yang menggunakan variabel lingkungan untuk mengubah hierarki yang sedang disebarkan. Opsi lain adalah mengklon pipeline dan mengubah pengaturan yang tertanam untuk menentukan hierarki yang akan diimplementasikan.
   • Menggunakan templat Azure Pipelines DevOps atau Templat Alur Kerja Tindakan GitHub akan membantu Anda mematuhi prinsip Jangan Ulangi Diri (DRY).
5. Miliki sekumpulan langganan kenari di bawah akun penagihan terpisah, misalnya bagian faktur Akun Perjanjian Enterprise (EA) atau Perjanjian Pelanggan Microsoft (MCA), yang dapat dipindahkan dalam hierarki grup manajemen kenari sesuai kebutuhan.
   • Mungkin bermanfaat untuk memiliki sekumpulan sumber daya yang selalu disebarkan ke dalam langganan lingkungan kenari untuk mempercepat pengujian dan validasi perubahan pada lingkungan kenari.
6. Anda memiliki sekumpulan contoh arsitektur beban kerja aplikasi yang dapat Anda sebarkan ke langganan canary di lingkungan canary untuk menguji perubahan Azure Policy dan RBAC. Ini membantu Anda memvalidasi perubahan sebelum Menyebarkan dan mempromosikan perubahan ke dalam produksi.
   • Contoh beban kerja ini dapat disebarkan menggunakan templat IaC yang sama yang digunakan untuk menyebarkan beban kerja aplikasi produksi. Ini akan membantu Anda memastikan bahwa lingkungan kanari sinkron dengan lingkungan produksi dan bahwa perubahan yang Anda uji valid dan berlaku untuk lingkungan produksi.
   • Anda harus terus meninjau dan memperbarui contoh beban kerja untuk memastikan bahwa beban kerja tersebut relevan dan terbaru dengan arsitektur terbaru dan pola desain di organisasi Anda.
   • Jika Anda memberikan arsitektur referensi kepada tim aplikasi Anda, pertimbangkan untuk menerapkannya ke lingkungan canary juga. Ini membantu Anda memvalidasi perubahan terhadap arsitektur referensi dan memastikan bahwa perubahan tersebut berlaku untuk lingkungan produksi.
7. Kirim semua log aktivitas Azure untuk semua langganan Azure, termasuk langganan lingkungan kenari apa pun, ke ruang kerja Azure Log Analytics lingkungan produksi sesuai rekomendasi desain zona pendaratan Azure.
   • Ini membantu tim keamanan dan operasi Anda untuk memantau lingkungan percobaan guna mengidentifikasi setiap perubahan atau masalah yang mungkin timbul dari pengujian kebijakan Azure dan perubahan RBAC pada lingkungan produksi.

Tips

Jika Anda sudah memiliki zona pendaratan Azure yang disebarkan dalam produksi dan sekarang ingin menambahkan lingkungan kenari. Pertimbangkan untuk mengkloning penyebaran hierarki lingkungan produksi Anda saat ini dan mengubah nama sumber daya untuk menambahkan prefiks sesuai skema penamaan canary Anda.

Ini untuk memastikan apa yang Anda sebarkan untuk mengaktifkan lingkungan kenari sinkron dengan produksi sejak awal. Ini mudah dicapai saat menggunakan alat IaC bersama repositori git.

Menggunakan satu tenant Microsoft Entra

Pertimbangan yang perlu diperhitungkan saat Anda menggunakan satu tenant Microsoft Entra meliputi:

• Menggunakan satu penyewa mengikuti rekomendasi desain landing zone Azure untuk penyewa Microsoft Entra.
  • Dalam satu penyewa Microsoft Entra, Anda dapat menggunakan grup Microsoft Entra yang berbeda untuk lingkungan zona pendaratan Azure produksi dan kenari dengan pengguna yang sama yang ditetapkan ke hierarki grup manajemen yang relevan.
• Peningkatan atau penggandaan biaya lisensi Microsoft Entra ID karena beberapa identitas di berbagai penyewa Microsoft Entra. Ini sangat relevan bagi pelanggan yang menggunakan fitur Microsoft Entra ID P1 atau P2.
• Perubahan RBAC lebih kompleks di lingkungan canary dan produksi, karena kemungkinan pengguna dan grup tidak identik di kedua tenant Microsoft Entra.
  • Pertimbangkan bahwa ID pengguna dan grup tidak akan sama di seluruh penyewa Microsoft Entra karena mereka unik secara global.
• Mengurangi kompleksitas dan overhead manajemen yang disebabkan oleh pengelolaan beberapa penyewa Microsoft Entra.
  • Pengguna yang memiliki hak istimewa yang harus mempertahankan akses dan masuk ke akun penyewa yang berbeda untuk melakukan pengujian mungkin membuat perubahan yang tidak disengaja pada lingkungan produksi alih-alih lingkungan percobaan, sebagai contoh.
• Mengurangi kemungkinan penyimpangan konfigurasi dan kegagalan penyebaran.
• Tidak perlu membuat langkah keamanan tambahan atau proses akses darurat.
• Mengurangi gesekan dan waktu yang diperlukan untuk menerapkan perubahan pada penyebaran zona pendaratan Azure.

Langkah berikutnya

Setelah Anda memiliki lingkungan canary, Anda dapat mulai menguji perubahan Azure Policy dan RBAC sebelum menyebarkannya ke hierarki grup manajemen zona pendaratan produksi Azure Anda.

Ketika Anda telah menguji perubahan pada Kebijakan Azure di lingkungan canary, Anda kemudian dapat memindahkannya ke lingkungan produksi mengikuti pendekatan yang sama seperti yang didokumentasikan dalam panduan Mengadopsi pagar pembatas berbasis kebijakan. Ini dilakukan dengan menggunakan fitur mode penegakan penugasan kebijakan. Menggunakan pendekatan yang didokumentasikan dalam panduan ini memungkinkan Anda untuk melanjutkan melalui fase pengujian tambahan sebelum Anda menerapkan Azure Policy di lingkungan produksi dalam efek yang diinginkan yang akan membantu Anda membangun keyakinan pada perubahan Azure Policy yang Anda buat.

Anda juga dapat meninjau lingkungan kotak pasir untuk digunakan tim aplikasi Anda untuk pengembangan dan pengujian beban kerja mereka. Ini adalah konsep terpisah untuk lingkungan kenari dan digunakan untuk menyediakan lingkungan yang aman bagi tim aplikasi untuk mengembangkan dan menguji beban kerja mereka sebelum disebarkan ke dalam produksi.

Menerapkan lingkungan kotak pasir zona pendaratan