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 penyebaran platform zona pendaratan Azure mereka untuk definisi dan penugasan Azure Policy, peran dan penetapan kustom kontrol akses berbasis peran (RBAC), dan sebagainya. Pengujian dapat diselesaikan melalui otomatisasi dengan menggunakan templat Azure Resource Manager (templat ARM), AzOps, Terraform, Bicep, atau secara manual melalui portal Azure. Panduan ini menyediakan pendekatan yang dapat digunakan untuk menguji perubahan dan dampaknya dalam 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.

Panduan ini paling cocok untuk organisasi dengan proses pengelolaan perubahan yang ketat yang mengatur perubahan pada hierarki grup pengelolaan lingkungan 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.

Sama halnya, istilah lingkungan produksi digunakan di seluruh panduan ini untuk merujuk ke hierarki grup pengelolaan 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 dalam hierarki grup pengelolaan lingkungan produksi dan tata kelola terkait (RBAC dan Azure Policy).

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

Skala perusahaan membantu Anda merancang dan menyebarkan komponen platform Azure yang diperlukan agar Anda dapat membangun dan mengoperasionalkan 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 grup pengelolaan	Microsoft.Management/managementGroups/subscriptions
Definisi kebijakan	Microsoft.Authorization/policyDefinitions
Definisi inisiatif kebijakan atau definisi yang ditetapkan kebijakan	Microsoft.Authorization/policySetDefinitions
Penetapan 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 bagi sebagian besar pelanggan. Ini tidak wajib untuk penyebaran zona pendaratan Azure.

Gambar 1: Hierarki grup pengelolaan Kenari.

Seperti yang ditunjukkan diagram, seluruh hierarki grup manajemen lingkungan produksi zona pendaratan Azure diduplikasi di Tenant Root Groupbawah . Nama kenari ditambahkan ke nama dan ID tampilan grup pengelolaan. ID harus unik dalam satu penyewa Microsoft Entra.

Catatan

Nama tampilan grup pengelolaan lingkungan kenari bisa sama dengan nama tampilan grup pengelolaan lingkungan produksi. Hal ini dapat menyebabkan pengguna bingung. Karena itu, sebaiknya tambahkan nama "kenari" ke nama tampilan, serta ID-nya.

Hierarki grup pengelolaan lingkungan kenari kemudian digunakan untuk memudahkan pengujian jenis sumber daya berikut:

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

Bagaimana jika Anda tidak ingin menyebarkan seluruh hierarki grup pengelolaan lingkungan kenari?

Jika Anda tidak ingin menyebarkan seluruh hierarki grup manajemen lingkungan 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 pengelolaan skala perusahaan yang menyoroti kotak pasir.

Untuk menguji Azure Policy dan RBAC dalam skenario ini, Anda memerlukan satu langganan Azure dengan peran RBAC Pemilik yang ditetapkan ke identitas yang Anda inginkan untuk menyelesaikan pengujian sebagai, misalnya, Akun Pengguna, Perwakilan Layanan, atau Identitas Layanan Terkelola. Konfigurasi ini memungkinkan Anda menulis, menetapkan, dan meremediasi definisi dan penetapan Azure Policy dalam lingkup 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. Pengujian ini semua dapat dilakukan dalam langganan kotak pasir dan diuji 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.

Menggunakan satu penyewa Microsoft Entra

Pertimbangan yang perlu diperhitungkan saat Anda menggunakan satu penyewa Microsoft Entra adalah:

• Mengikuti rekomendasi desain skala perusahaan untuk penyewa Microsoft Entra.
• Sesuai praktik terbaik Cloud Adoption Framework Azure, standarisasi pada satu direktori dan panduan identitas , penyewa Microsoft Entra tunggal adalah praktik terbaik untuk sebagian besar.
  • Dalam satu penyewa Microsoft Entra, Anda dapat menggunakan grup Microsoft Entra yang berbeda untuk lingkungan produksi dan lingkungan zona pendaratan Azure kenari, dengan pengguna yang sama, yang ditetapkan ke hierarki grup manajemen yang relevan dalam penyewa Microsoft Entra yang sama.
• Peningkatan atau duplikat biaya lisensi ID Microsoft Entra karena beberapa identitas di berbagai penyewa Microsoft Entra.
  • Poin ini sangat relevan bagi pelanggan yang menggunakan fitur Microsoft Entra ID P1 atau P2.
• Perubahan RBAC akan lebih kompleks di lingkungan kenari dan lingkungan produksi, karena kemungkinan pengguna dan grup tidak identik di kedua penyewa Microsoft Entra.
  • Selain itu, ID pengguna dan grup tidak akan sama di seluruh penyewa Microsoft Entra karena id tersebut unik secara global.
• Mengurangi kompleksitas dan overhead manajemen yang disebabkan oleh pengelolaan beberapa penyewa Microsoft Entra.
  • Pengguna istimewa yang harus mempertahankan akses dan masuk ke penyewa terpisah untuk melakukan pengujian mungkin membuat perubahan pada lingkungan produksi secara tidak sengaja, bukan membuat perubahan pada lingkungan kenari dan sebaliknya.
• Mengurangi kemungkinan penyimpangan konfigurasi dan kegagalan penyebaran.
• Keamanan ekstra dan proses akses mendesak atau darurat tidak perlu dibuat.
• Mengurangi gesekan dan waktu yang diperlukan untuk menerapkan perubahan pada penyebaran zona pendaratan Azure.

Panduan implementasi

Di bawah ini adalah panduan tentang cara menerapkan dan menggunakan hierarki grup manajemen kenari untuk zona pendaratan Azure bersama hierarki grup manajemen 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 oleh karena itu tidak menyediakan hierarki dan lingkungan produksi seperti replika.

Pertimbangkan untuk pindah ke pendekatan penyebaran Infrastructure-as-Code 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.

1. Gunakan perwakilan layanan (SPN) Microsoft Entra terpisah atau Identitas Layanan Terkelola (MSI) yang diberikan izin melalui lingkungan produksi yang relevan atau hierarki grup manajemen lingkungan kenari.
   • Panduan ini mengikuti prinsip hak istimewa paling sedikit (PoLP)
2. Gunakan folder terpisah dalam repositori git, cabang, atau repositori untuk menyimpan Infrastruktur sebagai Kode untuk lingkungan produksi dan lingkungan kenari penyebaran zona pendaratan Azure.
   • Menggunakan perwakilan layanan Microsoft Entra (SPN) atau Identitas Layanan Terkelola (MSI) yang relevan sebagai bagian dari alur CI/CD tergantung pada hierarki mana yang sedang disebarkan.
3. Terapkan kebijakan atau keamanan cabang git untuk lingkungan kenari seperti yang Anda miliki untuk 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 alur dan mengubah pengaturan yang dikodekan secara permanen untuk menentukan hierarki yang sedang disebarkan.
   • Menggunakan templat Azure Pipelines DevOps atau Templat Alur Kerja Tindakan GitHub akan membantu Anda mematuhi prinsip jangan mengulang sendiri (DRY).
5. Siapkan serangkaian langganan kenari dalam departemen EA terpisah dan akun yang dapat dipindahkan di sekitar hierarki grup pengelolaan kenari sesuai kebutuhan.
   • Mungkin bermanfaat untuk memiliki serangkaian sumber daya yang selalu disebarkan ke langganan lingkungan kenari.
   • Mungkin akan sangat membantu jika memiliki templat Infrastructure-as-Code seperti templat ARM, Bicep, atau Terraform, yang membuat serangkaian sumber daya yang memungkinkan validasi perubahan dalam lingkungan kenari.
6. 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.

Tip

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 mengawalinya dengan skema penamaan kenari Anda.

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

Langkah berikutnya

Pelajari cara menerapkan lingkungan kotak pasir zona pendaratan.

Menerapkan lingkungan kotak pasir zona pendaratan