Mengotomatiskan zona pendaratan Azure di beberapa penyewa
Jika organisasi Anda memiliki beberapa penyewa Microsoft Entra dengan zona pendaratan Azure (ALZ) di masing-masing, satu atau beberapa kali, otomatisasi adalah kuncinya. Automation membantu berhasil mengoperasikan dan memelihara penyebaran ALZ dalam skala besar di semua penyewa. Ada banyak pendekatan untuk mengotomatiskan penyebaran ALZ di beberapa penyewa. Pendekatan yang Anda ambil bergantung pada alasan organisasi Anda memiliki beberapa penyewa Microsoft Entra.
Misalnya, Anda mungkin memiliki beberapa penyewa Microsoft Entra jika Anda adalah vendor perangkat lunak independen. Kemungkinan Anda ingin memisahkan penyewa Microsoft Entra solusi perusahaan dan SaaS Anda. Risiko operasi atau penyebaran yang memengaruhi penyewa lain, baik yang dimaksudkan atau tidak sengaja, berkurang.
Bagian berikut ini menyediakan diagram dan panduan tentang pendekatan yang dapat Anda ambil. Pilih pendekatan mana yang terbaik untuk Anda berdasarkan kebutuhan, pertimbangan, dan rekomendasi untuk mengotomatiskan penyebaran zona pendaratan Azure Anda saat menangani beberapa penyewa Microsoft Entra.
Catatan
Tinjau artikel berikut ini terlebih dahulu untuk mendapatkan gambaran umum penyewa Microsoft Entra:
Pendekatan
Ada dua pendekatan untuk mengotomatiskan penyebaran zona pendaratan Azure di beberapa penyewa Microsoft Entra.
Pendekatan 1 - Isolasi lengkap adalah pendekatan paling umum dalam skenario multi-penyewa. Pendekatan ini menjaga pemisahan dan isolasi yang diperlukan antara penyewa Microsoft Entra, yang merupakan persyaratan paling umum saat menggunakan pendekatan multi-penyewa.
Pendekatan 2 - Pendaftaran aplikasi bersama (multi-penyewa) dengan beberapa perwakilan layanan umumnya digunakan dalam skenario Penyedia Layanan Terkelola (MSP). Dalam pendekatan ini, pola stempel penyebaran dapat digunakan untuk mengotomatiskan penyebaran arsitektur yang hampir identik di beberapa penyewa dalam skala besar.
Kedua pendekatan ini disediakan sebagai contoh dan inspirasi. Anda dapat mencampur dan mencocokkan pendekatan dalam penyebaran Anda berdasarkan kebutuhan organisasi Anda.
Penting
Artikel ini membahas cara mengotomatiskan penyebaran dan pengoperasian zona pendaratan Azure sebagai platform di setiap penyewa Microsoft Entra yang dimiliki organisasi Anda. Pendekatan, rekomendasi, dan pertimbangan dalam artikel ini tidak dimaksudkan untuk digunakan oleh tim aplikasi yang menyebarkan dan mengoperasikan layanan dan aplikasi mereka ke zona pendaratan (langganan). Untuk informasi selengkapnya tentang berbagai jenis zona pendaratan, lihat Zona pendaratan platform vs. aplikasi.
Pendekatan 1 - Isolasi lengkap
Dalam pendekatan ini, tujuan utamanya adalah untuk menjaga setiap penyewa Microsoft Entra terisolasi satu sama lain di semua komponen otomatisasi, seperti:
- Repositori Git.
- GitHub Actions atau Azure Pipelines (termasuk pelari yang dihost sendiri, jika digunakan).
- Identitas yang digunakan untuk melakukan tugas dari otomatisasi, seperti identitas terkelola yang ditetapkan untuk pelari yang dihost sendiri, nama perwakilan layanan (SPN), pengguna, atau administrator.
Dalam pendekatan ini, ada lebih banyak komponen untuk dikelola yang diduplikasi per penyewa Microsoft Entra. Beberapa organisasi mungkin memiliki kontrol kepatuhan terhadap peraturan yang diberlakukan pada mereka yang mengamanatkan jenis pemisahan dan isolasi ini.
Catatan
Jika organisasi Anda hanya mengizinkan penggunaan identitas terkelola untuk otomatisasi platform, Anda harus menggunakan pendekatan ini atau pendekatan yang masuk ke setiap penyewa satu per satu. Identitas terkelola tidak mendukung skenario lintas penyewa. Untuk informasi selengkapnya, lihat Tanya Jawab Umum ini.
Identitas untuk administrator dan pengembang platform - Pendekatan 1
Dalam pendekatan ini, identitas juga harus diisolasi di setiap penyewa Microsoft Entra, yang berarti setiap administrator atau pengembang platform memerlukan akun pengguna terpisah dalam setiap penyewa untuk melakukan operasi dalam penyewa tersebut. Akun-akun ini juga digunakan untuk mengakses alat pengembang, seperti GitHub atau Azure DevOps, untuk setiap penyewa. Pertimbangkan dengan cermat efek produktivitas administrator dan pengembang setelah pendekatan ini.
Microsoft Entra B2B dan/atau Azure Lighthouse dapat digunakan, tetapi opsi ini mempertanyakan alasan untuk memiliki penyewa Microsoft Entra terpisah.
Pendekatan 2 - Pendaftaran aplikasi bersama (multi-penyewa) dengan beberapa perwakilan layanan
Dalam pendekatan ini, pendaftaran aplikasi dibuat dalam mengelola penyewa Microsoft Entra. Di setiap penyewa Microsoft Entra yang ingin Anda kelola, nama perwakilan layanan (SPN) dibuat di penyewa tersebut, berdasarkan pendaftaran aplikasi. Tindakan ini memungkinkan pekerja menjalankan tugas alur dan langkah-langkah untuk masuk ke salah satu penyewa Microsoft Entra dengan satu set kredensial.
Tip
Untuk informasi tentang hubungan antara pendaftaran aplikasi dan aplikasi perusahaan (prinsip layanan), lihat Objek aplikasi dan perwakilan layanan di ID Microsoft Entra.
Penting
Dalam pendekatan ini, pendaftaran aplikasi tunggal dan aplikasi perusahaan terkait (perwakilan layanan) harus dipantau untuk setiap aktivitas abnormal dalam alat informasi keamanan dan manajemen peristiwa (SIEM) Anda karena ini adalah akun yang sangat istimewa. Ini harus mengirim pemberitahuan dan berpotensi secara otomatis mengambil tindakan, tergantung pada tingkat keparahan pemberitahuan.
Dalam contoh sebelumnya, satu pendaftaran aplikasi ada di contoso.onmicrosoft.com penyewa Microsoft Entra, dan aplikasi perusahaan berada di setiap penyewa Microsoft Entra yang ditautkan ke pendaftaran aplikasi. Penyiapan ini memungkinkan alur untuk mengautentikasi dan mengotorisasi ke semua penyewa Microsoft Entra dengan menggunakan pendaftaran aplikasi tunggal. Untuk informasi selengkapnya, lihat Membuat multi-penyewa aplikasi Anda.
Saat Anda menggunakan alur terpusat, Anda mungkin perlu membuat tabel pemetaan kecil yang berisi data yang berkorelasi dengan penyewa Microsoft Entra dan metadata lainnya, seperti lingkungan, langganan terkait, nama organisasi, dan ID objek identitas yang digunakan untuk autentikasi dan otorisasi. Data ini dapat dipanggil selama eksekusi alur dalam langkah yang menggunakan beberapa logika dan kondisi untuk mengontrol penyewa Microsoft Entra mana yang disebarkan ke dan dengan identitas mana. Data dapat disimpan dalam layanan, seperti Azure Cosmos DB atau penyimpanan Azure Table.
Saat Anda menangani beberapa lingkungan, seperti pengembangan, pengujian, atau produksi, lingkungan dapat dikontrol dengan cara yang sama dengan menggunakan pendaftaran aplikasi dan aplikasi perusahaan yang sama, atau terpisah dengan alur.
Anda mungkin memutuskan untuk memiliki alur terpisah untuk setiap penyewa Microsoft Entra atau menggunakan satu alur. Pilihannya adalah pilihan Anda berdasarkan kebutuhan Anda.
Catatan
Azure Lighthouse berfungsi mirip dengan pendekatan ini, tetapi Azure Lighthouse tidak mengizinkan penugasan pemilik RBAC, administrator akses pengguna, dan peran dengan izin DataActions. Untuk informasi selengkapnya, lihat Dukungan peran untuk Azure Lighthouse.
Peran akses pemilik dan pengguna biasanya diperlukan dalam semua skenario penyebaran zona pendaratan Azure. Persyaratan ini menghapus Azure Lighthouse sebagai opsi untuk seluruh aspek penyebaran otomatisasi platform dari zona pendaratan Azure, tetapi masih berguna dalam beberapa skenario. Untuk informasi selengkapnya, lihat Penggunaan Azure Lighthouse di multi-penyewa ALZ.
Identitas untuk administrator dan pengembang platform - Pendekatan 2
Dalam pendekatan ini, administrator platform dan pengembang biasanya hanya memerlukan akses ke penyewa Microsoft Entra pengelola. Akses ini memberi mereka akses ke alat pengembang, seperti GitHub atau Azure DevOps, yang disebarkan dan dioperasikan oleh semua penyewa.
Mereka mungkin memiliki akses ke penyewa Microsoft Entra lainnya melalui Microsoft Entra B2B atau Azure Lighthouse. Mereka menggunakan akun yang sama dari penyewa pengelola, atau mereka mungkin memiliki akun terpisah, seperti contoh dalam pendekatan pertama.