Dasar-dasar manajemen sumber daya Azure
Penting untuk memahami struktur dan istilah yang khusus untuk sumber daya Azure. Gambar berikut menunjukkan contoh empat tingkat cakupan yang disediakan oleh Azure:
Terminologi
Berikut adalah beberapa istilah yang harus Anda kenal:
Sumber daya - Item yang dapat dikelola yang tersedia melalui Azure. Komputer virtual, akun penyimpanan, aplikasi web, database, dan jaringan virtual adalah contoh sumber daya.
Grup sumber daya - Kontainer yang menyimpan sumber daya terkait untuk solusi Azure seperti kumpulan mesin virtual, VNet terkait, dan penyeimbang beban yang memerlukan manajemen oleh tim tertentu. Grup sumber daya menyertakan sumber daya yang ingin Anda kelola sebagai sebuah grup. Anda memutuskan sumber daya mana yang termasuk dalam grup sumber daya berdasarkan apa yang paling masuk akal bagi organisasi Anda. Grup sumber daya juga dapat digunakan untuk membantu manajemen siklus hidup dengan menghapus semua sumber daya yang memiliki masa pakai yang sama pada satu waktu. Pendekatan ini juga memberikan manfaat keamanan dengan tidak meninggalkan fragmen yang mungkin dieksploitasi.
Langganan - Dari perspektif hierarki organisasi, langganan adalah kontainer penagihan dan manajemen sumber daya serta grup sumber daya. Langganan Azure memiliki hubungan kepercayaan dengan ID Microsoft Entra. Langganan mempercayai ID Microsoft Entra untuk mengautentikasi pengguna, layanan, dan perangkat.
Catatan
Langganan hanya dapat mempercayai satu penyewa Microsoft Entra. Namun, setiap penyewa dapat mempercayai beberapa langganan dan langganan dapat dipindahkan antar penyewa.
Grup manajemen - Grup manajemen Azure menyediakan metode hierarkis untuk menerapkan kebijakan dan kepatuhan pada cakupan yang berbeda di atas langganan. Cakupan ini bisa berada di grup manajemen akar penyewa (cakupan tertinggi) atau pada tingkat yang lebih rendah dalam hierarki. Anda mengatur langganan ke dalam kontainer yang disebut "grup manajemen" dan menerapkan syarat tata kelola ke grup manajemen. Semua langganan dalam grup manajemen secara otomatis mewarisi kondisi yang diterapkan ke grup manajemen. Perhatikan, definisi kebijakan dapat diterapkan ke grup manajemen atau langganan.
Penyedia sumber - Layanan yang menyediakan sumber daya Azure. Misalnya, Microsoft adalah penyedia sumber yang umum. Komputasi, yang memasok sumber daya mesin virtual. Microsoft. Storage adalah penyedia sumber umum lainnya.
Templat Resource Manager - File JavaScript Object Notation (JSON) yang menentukan satu atau beberapa sumber daya untuk disebarkan ke grup sumber daya, langganan, penyewa, atau grup manajemen. Templat dapat digunakan untuk menyebarkan sumber daya secara konsisten dan berulang kali. Lihat Gambaran umum penyebaran templat. Selain itu, bahasa Bicep dapat digunakan alih-alih JSON.
Model Manajemen Sumber Daya Azure
Setiap langganan Azure dikaitkan dengan kontrol yang digunakan oleh Azure Resource Manager. Resource Manager adalah layanan penyebaran dan manajemen untuk Azure, ia memiliki hubungan kepercayaan dengan ID Microsoft Entra untuk manajemen identitas untuk organisasi, dan Akun Microsoft (MSA) untuk individu. Resource Manager menyediakan lapisan manajemen yang memungkinkan Anda untuk membuat, memperbarui, dan menghapus sumber daya di langganan Azure. Anda menggunakan fitur manajemen, seperti kontrol akses, kunci, dan tag untuk mengamankan serta mengatur sumber daya setelah penyebaran.
Catatan
Sebelum ARM, ada model penyebaran lain bernama Azure Service Manager (ASM) atau "klasik". Untuk mempelajari selengkapnya, lihat Penyebaran Azure Resource Manager vs. klasik. Mengelola lingkungan dengan model ASM berada di luar cakupan konten ini.
Azure Resource Manager adalah layanan front-end, yang menghosting REST API yang digunakan oleh PowerShell, portal Azure, atau klien lain untuk mengelola sumber daya. Saat klien membuat permintaan untuk mengelola sumber daya tertentu, Resource Manager meneruskan permintaan ke penyedia sumber guna menyelesaikan permintaan. Misalnya, jika klien membuat permintaan untuk mengelola sumber daya mesin virtual, Resource Manager akan meneruskan permintaan ke Microsoft. Penyedia sumber komputasi. Resource Manager mengharuskan klien menentukan pengidentifikasi untuk langganan dan grup sumber daya guna mengelola sumber daya mesin virtual.
Sebelum permintaan manajemen sumber daya dapat dijalankan oleh Resource Manager, serangkaian kontrol akan diperiksa.
Pemeriksaan pengguna yang valid - Pengguna yang meminta untuk mengelola sumber daya harus memiliki akun di penyewa Microsoft Entra yang terkait dengan langganan sumber daya terkelola.
Pemeriksaan izin pengguna - Izin ditetapkan kepada pengguna menggunakan kontrol akses berbasis peran (RBAC). Peran RBAC menentukan sekumpulan izin yang dapat diambil pengguna pada sumber daya tertentu. RBAC membantu Anda mengelola siapa yang memiliki akses ke sumber daya Azure, apa yang dapat mereka lakukan dengan sumber daya tersebut, dan area mana saja yang dapat mereka akses.
Pemeriksaan kebijakan Azure - Kebijakan Azure menentukan operasi yang diizinkan atau ditolak secara eksplisit untuk sumber daya tertentu. Misalnya, sebuah kebijakan dapat menentukan bahwa pengguna hanya diizinkan (atau tidak diizinkan) menyebarkan jenis mesin virtual tertentu.
Diagram berikut ini meringkas model sumber daya yang baru saja kami jelaskan.
Azure Lighthouse - Azure Lighthouse memungkinkan manajemen sumber daya di seluruh penyewa. Organisasi dapat mendelegasikan peran di tingkat langganan atau grup sumber daya ke identitas di penyewa lain.
Langganan yang memungkinkan manajemen sumber daya yang didelegasikan dengan Azure Lighthouse memiliki atribut yang menunjukkan ID penyewa yang dapat mengelola langganan atau grup sumber daya dan pemetaan antara peran RBAC bawaan dalam penyewa sumber daya hingga identitas di penyewa penyedia layanan. Pada runtime, Azure Resource Manager akan menggunakan atribut ini untuk mengotorisasi token yang berasal dari penyewa penyedia layanan.
Perlu dicatat bahwa Azure Lighthouse itu sendiri dimodelkan sebagai penyedia sumber daya Azure, yang berarti bahwa aspek delegasi di seluruh penyewa dapat ditargetkan melalui Kebijakan Azure.
Microsoft 365 Lighthouse - Microsoft 365 Lighthouse adalah portal admin yang membantu Penyedia Layanan Terkelola (MSP) mengamankan dan mengelola perangkat, data, dan pengguna dalam skala besar untuk pelanggan bisnis kecil dan menengah (SMB) yang menggunakan Microsoft 365 Business Premium, Microsoft 365 E3, atau Windows 365 Business.
Manajemen sumber daya Azure dengan ID Microsoft Entra
Sekarang setelah Anda memiliki pemahaman yang lebih baik tentang model manajemen sumber daya di Azure, mari kita periksa secara singkat beberapa kemampuan ID Microsoft Entra yang dapat menyediakan manajemen identitas dan akses untuk sumber daya Azure.
Billing
Penagihan penting untuk manajemen sumber daya karena beberapa peran penagihan berinteraksi dengan atau dapat mengelola sumber daya. Penagihan bekerja secara berbeda bergantung pada jenis perjanjian yang Anda miliki dengan Microsoft.
Perjanjian Enterprise Azure
Pelanggan Perjanjian Enterprise Azure (Azure EA) di-onboarding ke Portal Azure EA setelah eksekusi kontrak komersial mereka dengan Microsoft. Setelah onboarding, identitas dikaitkan dengan peran penagihan Administrator Enterprise "root". Portal menyediakan hierarki fungsi manajemen:
Departemen membantu membagi biaya menjadi pengelompokan yang logis dan memungkinkan Anda untuk menetapkan anggaran atau kuota di tingkat departemen.
Akun digunakan untuk departemen segmen lebih lanjut. Anda dapat menggunakan akun untuk mengelola langganan dan mengakses laporan. Portal EA dapat mengotorisasi Akun Microsoft (MSA) atau akun Microsoft Entra (diidentifikasi di portal sebagai "Akun Kerja atau Sekolah"). Identitas dengan peran "Pemilik Akun" di portal EA dapat membuat langganan Azure.
Penagihan perusahaan dan penyewa Microsoft Entra
Saat Pemilik Akun membuat langganan Azure dalam perjanjian perusahaan, manajemen identitas dan akses langganan dikonfigurasi sebagai berikut:
Langganan Azure dikaitkan dengan penyewa Microsoft Entra yang sama dari Pemilik Akun.
Pemilik akun yang membuat langganan akan diberi peran Administrator Layanan dan Administrator Akun. (Portal Azure EA menetapkan peran Azure Service Manager (ASM) atau "klasik" untuk mengelola langganan. Untuk mempelajari selengkapnya, lihat Azure Resource Manager vs. penyebaran klasik.)
Perjanjian perusahaan dapat dikonfigurasi untuk mendukung beberapa penyewa dengan mengatur jenis autentikasi "Akun kerja atau sekolah lintas penyewa" di Portal Azure EA. Mengingat hal di atas, organisasi dapat mengatur beberapa akun untuk setiap penyewa dan beberapa langganan untuk setiap akun, seperti yang ditunjukkan pada diagram berikut ini.
Penting untuk dicatat bahwa konfigurasi default yang dijelaskan di atas memberikan hak istimewa Pemilik Akun Azure EA untuk mengelola sumber daya dalam langganan apa pun yang mereka buat. Untuk langganan yang memiliki beban kerja produksi, pertimbangkan untuk memisahkan manajemen sumber daya dan penagihan dengan mengubah administrator layanan langganan tepat setelah pembuatan.
Untuk memisahkan lebih lanjut dan mencegah pemilik akun mendapatkan kembali akses administrator layanan ke langganan, penyewa langganan dapat diubah setelah pembuatan. Jika pemilik akun tidak memiliki objek pengguna di penyewa Microsoft Entra tempat langganan dipindahkan, mereka tidak dapat mendapatkan kembali peran pemilik layanan.
Untuk mempelajari lebih lanjut, kunjungi peran Azure, peran Microsoft Entra, dan peran administrator langganan klasik.
Perjanjian Pelanggan Microsoft
Pelanggan yang terdaftar dengan Perjanjian Pelanggan Microsoft (MCA) memiliki sistem manajemen penagihan yang berbeda dengan peran yang dimilikinya.
Akun penagihan untuk Perjanjian Pelanggan Microsoft berisi satu atau beberapa profil penagihan yang memungkinkan Anda mengelola faktur dan metode pembayaran. Setiap profil penagihan berisi satu atau beberapa bagian faktur guna mengatur biaya pada faktur profil penagihan.
Dalam Perjanjian Pelanggan Microsoft, peran penagihan berasal dari satu penyewa Microsoft Entra. Untuk menyediakan langganan untuk beberapa penyewa, langganan awalnya harus dibuat di penyewa Microsoft Entra yang sama dengan MCA, lalu diubah. Dalam diagram di bawah ini, langganan untuk lingkungan pra-produksi TI Perusahaan dipindahkan ke penyewa ContosoSandbox setelah pembuatan.
RBAC dan penetapan peran di Azure
Di bagian Dasar-Dasar Microsoft Entra, Anda mempelajari Azure RBAC adalah sistem otorisasi yang menyediakan manajemen akses terperinci ke sumber daya Azure, dan mencakup banyak peran bawaan. Anda dapat membuat peran kustom dan menetapkan peran pada cakupan yang berbeda. Izin diberlakukan dengan menetapkan peran RBAC ke objek yang meminta akses ke sumber daya Azure.
Peran Microsoft Entra beroperasi pada konsep seperti kontrol akses berbasis peran Azure. Perbedaan antara kedua sistem kontrol akses berbasis peran ini adalah bahwa Azure RBAC menggunakan Azure Resource Management untuk mengontrol akses ke sumber daya Azure seperti komputer virtual atau penyimpanan, dan peran Microsoft Entra mengontrol akses ke ID Microsoft Entra, aplikasi, dan layanan Microsoft seperti Office 365.
Peran Microsoft Entra dan peran Azure RBAC terintegrasi dengan Microsoft Entra Privileged Identity Management untuk mengaktifkan kebijakan aktivasi just-in-time seperti alur kerja persetujuan dan MFA.
ABAC dan penetapan peran di Azure
Kontrol akses berbasis atribut (ABAC) adalah sistem otorisasi yang mendefinisikan akses berdasarkan atribut yang terkait dengan prinsip keamanan, sumber daya, dan lingkungan. Dengan ABAC, Anda dapat memberikan akses prinsip keamanan ke sumber daya berdasarkan atribut. Azure ABAC mengacu pada implementasi ABAC untuk Azure.
Azure ABAC dibangun pada Azure RBAC dengan menambahkan kondisi penetapan peran berdasarkan atribut dalam konteks tindakan tertentu. Kondisi penetapan peran adalah pemeriksaan tambahan yang dapat Anda tambahkan secara opsional ke penetapan peran Anda untuk memberikan kontrol akses yang lebih terperinci. Kondisi memfilter izin yang diberikan sebagai bagian dari definisi peran dan penetapan peran. Misalnya, Anda dapat menambahkan kondisi yang mengharuskan objek memiliki tag tertentu untuk membaca objek. Anda tidak dapat secara eksplisit menolak akses ke sumber daya tertentu menggunakan ketentuan.
Akses Bersyarat
Microsoft Entra Conditional Access dapat digunakan untuk mengelola akses ke titik akhir manajemen Azure. Kebijakan Akses Bersyar dapat diterapkan ke aplikasi cloud API Windows Azure Service Management untuk melindungi titik akhir manajemen sumber daya Azure seperti:
Penyedia Azure Resource Manager (layanan)
API Azure Resource Manager
Azure PowerShell
Azure CLI
Portal Azure
Misalnya, administrator dapat mengonfigurasi kebijakan Akses Bersyarat, yang memungkinkan pengguna untuk masuk ke portal Azure hanya dari lokasi yang disetujui, dan juga memerlukan autentikasi multifaktor (MFA) atau perangkat gabungan domain Microsoft Entra hibrid.
Identitas Terkelola Azure
Tantangan umum saat membangun aplikasi cloud adalah cara mengelola kredensial dalam kode Anda untuk mengautentikasi ke layanan cloud. Menjaga kredensial tetap aman adalah tugas penting. Idealnya, kredensial tidak pernah muncul di stasiun kerja pengembang dan tidak dicentang ke kontrol sumber. Identitas terkelola untuk sumber daya Azure menyediakan layanan Azure dengan identitas yang dikelola secara otomatis di ID Microsoft Entra. Anda dapat menggunakan identitas untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi Microsoft Entra tanpa kredensial apa pun dalam kode Anda.
Ada dua jenis identitas terkelola:
Identitas terkelola yang ditetapkan sistem diaktifkan secara langsung pada sumber daya Azure. Saat sumber daya diaktifkan, Azure membuat identitas untuk sumber daya di penyewa Microsoft Entra tepercaya langganan terkait. Setelah identitas dibuat, info masuk disediakan ke sumber daya. Siklus hidup identitas yang ditetapkan sistem secara langsung terikat pada sumber daya Azure. Jika sumber daya dihapus, Azure secara otomatis membersihkan kredensial dan identitas di ID Microsoft Entra.
Identitas terkelola yang ditetapkan pengguna dibuat sebagai sumber daya Azure mandiri. Azure membuat identitas di penyewa Microsoft Entra yang dipercaya oleh langganan tempat sumber daya dikaitkan. Setelah identitas dibuat, identitas dapat ditetapkan ke satu atau beberapa sumber daya Azure. Siklus hidup identitas yang ditetapkan pengguna dikelola secara terpisah dari siklus hidup sumber daya Azure yang ditetapkannya.
Secara internal, identitas terkelola adalah perwakilan layanan dari jenis khusus, yang hanya dapat digunakan oleh sumber daya Azure tertentu. Ketika identitas terkelola dihapus, perwakilan layanan yang sesuai secara otomatis dihapus. Perhatikan bahwa otorisasi izin API Graph hanya dapat dilakukan oleh PowerShell, sehingga tidak semua fitur Identitas Terkelola dapat diakses melalui UI Portal.
Microsoft Entra Domain Services
Microsoft Entra Domain Services menyediakan domain terkelola untuk memfasilitasi autentikasi untuk beban kerja Azure menggunakan protokol warisan. Server yang didukung dipindahkan dari forest AD DS lokal dan bergabung ke domain terkelola Microsoft Entra Domain Services dan terus menggunakan protokol warisan untuk autentikasi (misalnya, autentikasi Kerberos).
Direktori Azure AD B2C dan Azure
Penyewa Azure AD B2C ditautkan ke langganan Azure untuk tujuan penagihan dan komunikasi. Penyewa Azure AD B2C memiliki struktur peran mandiri dalam direktori, yang independen dari peran istimewa RBAC Azure dari langganan Azure.
Saat penyewa Azure AD B2C awalnya disediakan, pengguna yang membuat penyewa B2C harus memiliki izin kontributor atau pemilik di dalam langganan. Mereka nantinya dapat membuat akun lain dan menetapkannya ke peran direktori. Untuk informasi selengkapnya, lihat Gambaran umum kontrol akses berbasis peran di ID Microsoft Entra.
Penting untuk dicatat bahwa pemilik dan kontributor langganan Microsoft Entra yang ditautkan dapat menghapus tautan antara langganan dan direktori, yang akan memengaruhi penagihan penggunaan Azure AD B2C yang sedang berlangsung.
Pertimbangan identitas untuk solusi IaaS di Azure
Skenario ini mencakup persyaratan isolasi identitas yang dimiliki organisasi untuk beban kerja Infrastructure-as-a-Service (IaaS).
Terdapat tiga opsi utama terkait manajemen isolasi beban kerja IaaS:
Mesin virtual yang bergabung ke Active Directory Domain Services (AD DS) mandiri
Microsoft Entra Domain Services bergabung dengan komputer virtual
Masuk ke komputer virtual di Azure menggunakan autentikasi Microsoft Entra
Konsep utama untuk mengatasi dengan dua opsi pertama adalah terdapat dua realm identitas yang terlibat dalam skenario ini.
Saat Anda masuk ke VM Azure Windows Server melalui protokol desktop jarak jauh (RDP), Anda umumnya masuk ke server menggunakan kredensial domain Anda, yang melakukan autentikasi Kerberos terhadap pengendali domain AD DS lokal atau Microsoft Entra Domain Services. Atau, jika server tidak bergabung dengan domain maka akun lokal dapat digunakan untuk masuk ke mesin virtual.
Saat Anda masuk ke portal Azure untuk membuat atau mengelola VM, Anda mengautentikasi terhadap ID Microsoft Entra (berpotensi menggunakan kredensial yang sama jika Anda telah menyinkronkan akun yang benar), dan ini dapat mengakibatkan autentikasi terhadap pengontrol domain Anda jika Anda menggunakan Layanan Federasi Direktori Aktif (AD FS) atau Autentikasi PassThrough.
Mesin virtual yang bergabung ke Active Directory Domain Services mandiri
AD DS adalah layanan direktori berbasis Windows Server yang diadopsi oleh sebagian besar organisasi untuk layanan identitas lokal. AD DS dapat disebarkan ketika ada persyaratan untuk menyebarkan beban kerja IaaS ke Azure yang memerlukan isolasi identitas dari administrator AD DS dan pengguna di forest lain.
Pertimbangan berikut perlu dibuat dalam skenario ini:
Pengendali domain AD DS: minimal dua pengendali domain AD DS harus disebarkan untuk memastikan bahwa layanan autentikasi sangat tersedia dan berkinerja. Untuk informasi selengkapnya, lihat Desain dan Perencanaan AD DS.
Desain dan Perencanaan AD DS - Forest AD DS baru harus dibuat dengan layanan berikut yang dikonfigurasi dengan benar:
Sistem Nama Domain (DNS) AD DS - DNS AD DS harus dikonfigurasi untuk zona yang relevan dalam AD DS guna memastikan bahwa resolusi nama beroperasi dengan benar untuk server dan aplikasi.
Situs dan Layanan AD DS - Layanan ini harus dikonfigurasi untuk memastikan bahwa aplikasi memiliki latensi rendah dan akses kinerja ke pengendali domain. Jaringan virtual, subnet, dan lokasi pusat data yang relevan tempat server berada harus dikonfigurasi di situs dan layanan.
FSMO AD DS - Peran Flexible Single Master Operation (FSMO) yang diperlukan harus ditinjau dan ditetapkan ke pengendali domain AD DS yang sesuai.
Gabungan Domain AD DS - Semua server (tidak termasuk "jumpbox") yang memerlukan AD DS untuk autentikasi, konfigurasi, dan manajemen perlu digabungkan ke forest yang terisolasi.
Kebijakan Grup (GPO) AD DS - GPO AD DS harus dikonfigurasi untuk memastikan bahwa konfigurasi memenuhi persyaratan keamanan dan bahwa konfigurasi distandarkan di seluruh forest juga komputer yang bergabung dengan domain.
Unit Organisasi (OU) AD DS - OU AD DS harus didefinisikan guna memastikan pengelompokan sumber daya AD DS ke dalam silo manajemen dan konfigurasi logis untuk tujuan administrasi dan penerapan konfigurasi.
Kontrol akses berbasis peran - RBAC harus didefinisikan untuk administrasi dan akses ke sumber daya yang bergabung ke forest ini. Drive ini termasuk:
Grup AD DS - Grup harus dibuat untuk menerapkan izin yang sesuai bagi pengguna ke sumber daya AD DS.
Akun administrasi - Seperti yang disebutkan di awal bagian ini bahwa terdapat dua akun administrasi yang diperlukan untuk mengelola solusi ini.
Akun administrasi AD DS dengan akses hak istimewa paling sedikit yang dibutuhkan untuk melakukan administrasi yang diperlukan di AD DS dan server yang bergabung dengan domain.
Akun administrasi Microsoft Entra untuk akses portal Azure untuk menyambungkan, mengelola, dan mengonfigurasi komputer virtual, VNet, grup keamanan jaringan, dan sumber daya Azure lain yang diperlukan.
Akun pengguna AD DS - Akun pengguna yang relevan perlu disediakan dan ditambahkan ke grup yang benar untuk memungkinkan akses pengguna ke aplikasi yang dihosting oleh solusi ini.
Jaringan virtual (VNet) - Panduan konfigurasi
Alamat IP pengendali domain AD DS - Pengendali domain tidak boleh dikonfigurasi dengan alamat IP statis dalam sistem operasi. Alamat IP harus dicadangkan di Azure VNET guna memastikan mereka selalu tetap sama dan DC harus dikonfigurasi untuk menggunakan DHCP.
Server DNS VNet - Server DNS harus dikonfigurasi pada VNet yang merupakan bagian dari solusi terisolasi ini untuk menunjuk ke pengendali domain. Langkah ini diperlukan untuk memastikan bahwa aplikasi dan server dapat menyelesaikan layanan AD DS yang diperlukan atau layanan lain yang bergabung ke forest AD DS.
Kelompok keamanan jaringan (NSG) - Pengendali domain harus berada di VNet atau subnet mereka sendiri dengan NSG yang ditentukan untuk hanya mengizinkan akses ke pengendali domain dari server yang diperlukan (misalnya, mesin atau jumpbox yang bergabung dengan domain). Jumpbox harus ditambahkan ke kelompok keamanan aplikasi (ASG) guna menyederhanakan pembuatan dan administrasi NSG.
Tantangan: Daftar di bawah ini menyoroti tantangan utama terkait menggunakan opsi ini untuk isolasi identitas:
Forest AD DS tambahan untuk mengatur, mengelola, dan memantau menghasilkan lebih banyak pekerjaan yang harus dilakukan tim IT.
Infrastruktur lebih lanjut mungkin diperlukan untuk manajemen patching dan penyebaran perangkat lunak. Organisasi harus mempertimbangkan untuk menyebarkan Manajemen Pembaruan Azure, Kebijakan Grup (GPO) atau System Center Configuration Manager (SCCM) untuk mengelola server ini.
Info masuk tambahan bagi pengguna untuk diingat dan digunakan untuk mengakses sumber daya.
Penting
Untuk model terisolasi ini, diasumsikan bahwa tidak ada konektivitas ke atau dari pengendali domain dari jaringan perusahaan pelanggan dan bahwa tidak ada kepercayaan yang dikonfigurasi dengan forest lain. Jumpbox atau server manajemen harus dibuat untuk memungkinkan titik tempat pengontrol domain AD DS dapat dikelola dan diatur.
Microsoft Entra Domain Services bergabung dengan komputer virtual
Ketika ada persyaratan untuk menyebarkan beban kerja IaaS ke Azure yang memerlukan isolasi identitas dari administrator AD DS dan pengguna di forest lain, domain terkelola Microsoft Entra Domain Services dapat disebarkan. Microsoft Entra Domain Services adalah layanan yang menyediakan domain terkelola untuk memfasilitasi autentikasi untuk beban kerja Azure menggunakan protokol warisan. Hal ini menyediakan domain terisolasi tanpa kompleksitas teknis dalam membangun dan mengelola AD DS Anda sendiri. Pertimbangan berikut perlu dibuat.
Domain terkelola Microsoft Entra Domain Services - Hanya satu domain terkelola Microsoft Entra Domain Services yang dapat disebarkan per penyewa Microsoft Entra dan ini terikat ke satu VNet. Disarankan agar VNet ini membentuk "hub" untuk autentikasi Microsoft Entra Domain Services. Dari hub ini, "spoke" dapat dibuat dan ditautkan guna memungkinkan autentikasi lama untuk server dan aplikasi. Spoke adalah VNet tambahan tempat server yang bergabung dengan Microsoft Entra Domain Services berada dan ditautkan ke hub menggunakan gateway jaringan Azure atau peering VNet.
Lokasi domain terkelola - Lokasi harus diatur saat menyebarkan domain terkelola Microsoft Entra Domain Services. Lokasi adalah wilayah fisik (pusat data) tempat domain terkelola disebarkan. Anda disarankan untuk:
Pertimbangkan lokasi yang tertutup secara geografis ke server dan aplikasi yang memerlukan layanan Microsoft Entra Domain Services.
Mempertimbangkan wilayah yang menyediakan kemampuan Zona Ketersediaan untuk persyaratan ketersediaan tinggi. Untuk informasi selengkapnya, lihat Zona Wilayah dan Ketersediaan di Azure.
Provisi objek - Microsoft Entra Domain Services menyinkronkan identitas dari ID Microsoft Entra yang terkait dengan langganan tempat Microsoft Entra Domain Services disebarkan. Perlu juga dicatat bahwa jika ID Microsoft Entra terkait memiliki sinkronisasi yang disiapkan dengan Microsoft Entra Connect (skenario forest pengguna) maka siklus hidup identitas ini juga dapat tercermin dalam Microsoft Entra Domain Services. Layanan ini memiliki dua mode yang dapat digunakan untuk menyediakan objek pengguna dan grup dari ID Microsoft Entra.
Semua: Semua pengguna dan grup disinkronkan dari ID Microsoft Entra ke Microsoft Entra Domain Services.
Tercakup: Hanya pengguna dalam cakupan grup yang disinkronkan dari ID Microsoft Entra ke Microsoft Entra Domain Services.
Saat Pertama kali Anda menyebarkan Microsoft Entra Domain Services, sinkronisasi satu arah otomatis dikonfigurasi untuk mereplikasi objek dari ID Microsoft Entra. Sinkronisasi satu arah ini terus berjalan di latar belakang untuk menjaga domain terkelola Microsoft Entra Domain Services tetap diperbarui dengan perubahan apa pun dari ID Microsoft Entra. Tidak ada sinkronisasi yang terjadi dari Microsoft Entra Domain Services kembali ke Microsoft Entra ID. Untuk informasi selengkapnya, lihat Bagaimana objek dan kredensial disinkronkan di domain terkelola Microsoft Entra Domain Services.
Perlu dicatat bahwa jika Anda perlu mengubah jenis sinkronisasi dari Semua ke Cakupan (atau sebaliknya), maka domain terkelola Microsoft Entra Domain Services harus dihapus, dibuat ulang, dan dikonfigurasi. Selain itu, organisasi harus mempertimbangkan penggunaan provisi "terlingkup" untuk mengurangi identitas hanya untuk mereka yang membutuhkan akses ke sumber daya Microsoft Entra Domain Services sebagai praktik yang baik.
Objek Kebijakan Grup (GPO) - Untuk mengonfigurasi GPO di domain terkelola Microsoft Entra Domain Services, Anda harus menggunakan alat Manajemen Kebijakan Grup di server yang telah bergabung dengan domain ke domain terkelola Microsoft Entra Domain Services. Untuk informasi selengkapnya, lihat Mengelola Kebijakan Grup di domain terkelola Microsoft Entra Domain Services.
Secure LDAP - Microsoft Entra Domain Services menyediakan layanan LDAP aman yang dapat digunakan oleh aplikasi yang memerlukannya. Pengaturan ini dinonaktifkan secara default dan untuk mengaktifkan LDAP aman, sertifikat perlu diunggah, selain itu, NSG yang mengamankan VNet tempat Microsoft Entra Domain Services disebarkan untuk harus mengizinkan konektivitas port 636 ke domain terkelola Microsoft Entra Domain Services. Untuk informasi selengkapnya, lihat Mengonfigurasi LDAP aman untuk domain terkelola Microsoft Entra Domain Services.
Administrasi - Untuk melakukan tugas administrasi pada Microsoft Entra Domain Services (misalnya, komputer gabungan domain atau edit GPO), akun yang digunakan untuk tugas ini harus menjadi bagian dari grup Administrator Microsoft Entra DC. Akun yang merupakan anggota grup ini tidak dapat langsung masuk ke pengendali domain untuk melakukan tugas manajemen. Sebagai gantinya, Anda membuat VM manajemen yang bergabung ke domain terkelola Microsoft Entra Domain Services, lalu menginstal alat manajemen AD DS reguler Anda. Untuk informasi selengkapnya, lihat Konsep manajemen untuk akun pengguna, kata sandi, dan administrasi di Microsoft Entra Domain Services.
Hash kata sandi - Agar autentikasi dengan Microsoft Entra Domain Services berfungsi, hash kata sandi untuk semua pengguna harus dalam format yang cocok untuk autentikasi NT LAN Manager (NTLM) dan Kerberos. Untuk memastikan autentikasi dengan Microsoft Entra Domain Services berfungsi seperti yang diharapkan, prasyarat berikut perlu dilakukan.
Pengguna yang disinkronkan dengan Microsoft Entra Connect (dari AD DS) - Hash kata sandi warisan perlu disinkronkan dari AD DS lokal ke ID Microsoft Entra.
Pengguna yang dibuat di MICROSOFT Entra ID - Perlu mengatur ulang kata sandi mereka agar hash yang benar dibuat untuk penggunaan dengan Microsoft Entra Domain Services. Untuk informasi selengkapnya, lihat Mengaktifkan sinkronisasi hash kata sandi.
Jaringan - Microsoft Entra Domain Services disebarkan ke Azure VNet sehingga pertimbangan perlu dilakukan untuk memastikan bahwa server dan aplikasi diamankan dan dapat mengakses domain terkelola dengan benar. Untuk informasi selengkapnya, lihat Pertimbangan desain jaringan virtual dan opsi konfigurasi untuk Microsoft Entra Domain Services.
Microsoft Entra Domain Services harus disebarkan di subnetnya sendiri: Jangan gunakan subnet atau subnet gateway yang ada.
Grup keamanan jaringan (NSG) - dibuat selama penyebaran domain terkelola Microsoft Entra Domain Services. Kelompok keamanan jaringan ini berisi aturan yang diperlukan untuk komunikasi layanan yang benar. Jangan buat atau gunakan kelompok keamanan jaringan yang sudah ada dengan aturan kustom Anda sendiri.
Microsoft Entra Domain Services memerlukan 3-5 alamat IP - Pastikan rentang alamat IP subnet Anda dapat menyediakan jumlah alamat ini. Membatasi alamat IP yang tersedia dapat mencegah Microsoft Entra Domain Services mempertahankan dua pengendali domain.
Server DNS VNet - Seperti yang dibahas sebelumnya tentang model "hub dan spoke", penting untuk mengonfigurasi DNS dengan benar di VNet untuk memastikan bahwa server yang bergabung ke domain terkelola Microsoft Entra Domain Services memiliki pengaturan DNS yang benar untuk menyelesaikan domain terkelola Microsoft Entra Domain Services. Setiap VNet memiliki entri server DNS yang diteruskan ke server saat mereka mendapatkan alamat IP dan entri DNS ini harus menjadi alamat IP domain terkelola Microsoft Entra Domain Services. Untuk informasi selengkapnya, lihat Memperbarui pengaturan DNS untuk jaringan virtual Azure.
Tantangan: Daftar di bawah ini menyoroti tantangan utama terkait menggunakan opsi ini untuk Isolasi Identitas.
Beberapa konfigurasi Microsoft Entra Domain Services hanya dapat dikelola dari server yang bergabung dengan Microsoft Entra Domain Services.
Hanya satu domain terkelola Microsoft Entra Domain Services yang dapat disebarkan per penyewa Microsoft Entra. Seperti yang kami jelaskan di bagian ini, model hub dan spoke disarankan untuk menyediakan autentikasi Microsoft Entra Domain Services ke layanan di VNet lain.
Infrastruktur lebih lanjut mungkin diperlukan untuk manajemen patching dan penyebaran perangkat lunak. Organisasi harus mempertimbangkan untuk menyebarkan Manajemen Pembaruan Azure, Kebijakan Grup (GPO) atau System Center Configuration Manager (SCCM) untuk mengelola server ini.
Untuk model terisolasi ini, diasumsikan bahwa tidak ada konektivitas ke VNet yang menghosting domain terkelola Microsoft Entra Domain Services dari jaringan perusahaan pelanggan dan tidak ada kepercayaan yang dikonfigurasi dengan forest lain. Jumpbox atau server manajemen harus dibuat untuk memungkinkan titik tempat Microsoft Entra Domain Services dapat dikelola dan dikelola.
Masuk ke komputer virtual di Azure menggunakan autentikasi Microsoft Entra
Ketika ada persyaratan untuk menyebarkan beban kerja IaaS ke Azure yang memerlukan isolasi identitas, maka opsi terakhir adalah menggunakan ID Microsoft Entra untuk masuk ke server dalam skenario ini. Ini memberikan kemampuan untuk menjadikan Microsoft Entra ID sebagai realm identitas untuk tujuan autentikasi dan isolasi identitas dapat dicapai dengan menyediakan server ke dalam langganan yang relevan, yang ditautkan ke penyewa Microsoft Entra yang diperlukan. Pertimbangan berikut perlu dibuat.
Sistem operasi yang didukung: Masuk ke komputer virtual di Azure menggunakan autentikasi Microsoft Entra saat ini didukung di Windows dan Linux. Untuk informasi lebih spesifik tentang sistem operasi yang didukung, lihat dokumentasi untuk Windows dan Linux.
Kredensial: Salah satu manfaat utama masuk ke komputer virtual di Azure menggunakan autentikasi Microsoft Entra adalah kemampuan untuk menggunakan kredensial Microsoft Entra federasi atau terkelola yang sama yang biasanya Anda gunakan untuk akses ke layanan Microsoft Entra untuk masuk ke komputer virtual.
Catatan
Penyewa Microsoft Entra yang digunakan untuk masuk dalam skenario ini adalah penyewa Microsoft Entra yang terkait dengan langganan tempat komputer virtual telah disediakan. Penyewa Microsoft Entra ini bisa menjadi penyewa yang memiliki identitas yang disinkronkan dari AD DS lokal. Organisasi harus membuat pilihan berdasarkan informasi yang selaras dengan prinsipal isolasi mereka saat memilih langganan dan penyewa Microsoft Entra mana yang ingin mereka gunakan untuk masuk ke server ini.
Persyaratan Jaringan: Komputer virtual ini perlu mengakses ID Microsoft Entra untuk autentikasi sehingga Anda harus memastikan bahwa konfigurasi jaringan komputer virtual mengizinkan akses keluar ke titik akhir Microsoft Entra pada 443. Lihat dokumentasi untuk Windows dan Linux untuk informasi selengkapnya.
Kontrol Akses berbasis peran (RBAC): Dua peran RBAC tersedia untuk memberikan tingkat akses yang sesuai ke mesin virtual ini. Peran RBAC ini dapat dikonfigurasi melalui portal Azure atau melalui Pengalaman Azure Cloud Shell. Untuk informasi selengkapnya, lihat Mengonfigurasi penetapan peran untuk mesin virtual.
Log masuk administrator mesin virtual: Pengguna yang diberi peran ini dapat masuk ke mesin virtual Azure dengan hak istimewa administrator.
Log masuk pengguna mesin virtual: Pengguna yang diberi peran ini dapat masuk ke mesin virtual Azure dengan hak istimewa pengguna.
Akses Bersyarat: Manfaat utama menggunakan ID Microsoft Entra untuk masuk ke komputer virtual Azure adalah kemampuan untuk menerapkan Akses Bersyarat sebagai bagian dari proses masuk. Hal ini memberikan kemampuan bagi organisasi untuk mengharuskan kondisi terpenuhi sebelum mengizinkan akses ke mesin virtual dan menggunakan autentikasi multifaktor untuk memberikan autentikasi yang kuat. Untuk informasi selengkapnya, lihat Menggunakan Akses Bersyarat.
Catatan
Koneksi jarak jauh ke komputer virtual yang bergabung ke MICROSOFT Entra ID hanya diizinkan dari PC Windows 10, Windows 11, dan Cloud PC yang bergabung dengan Microsoft Entra atau Microsoft Entra hybrid yang bergabung ke direktori yang sama dengan komputer virtual.
Tantangan: Daftar di bawah ini menyoroti tantangan utama terkait menggunakan opsi ini untuk isolasi identitas.
Tidak ada manajemen pusat atau konfigurasi server. Misalnya, tidak ada Kebijakan Grup yang dapat diterapkan ke sekelompok server. Organisasi harus mempertimbangkan untuk menyebarkan Manajemen Pembaruan di Azure guna mengelola patching dan pembaruan server ini.
Tidak cocok untuk aplikasi multi-tingkat yang memiliki persyaratan untuk mengautentikasi dengan mekanisme lokal seperti Autentikasi Terintegrasi Windows di seluruh server atau layanan ini. Jika ini adalah persyaratan untuk organisasi, disarankan agar Anda menjelajahi Layanan Domain Direktori Aktif Mandiri, atau skenario Microsoft Entra Domain Services yang dijelaskan di bagian ini.
Untuk model terisolasi ini, diasumsikan bahwa tidak ada konektivitas ke VNet yang menghosting komputer virtual dari jaringan perusahaan pelanggan. Jumpbox atau server manajemen harus dibuat untuk memungkinkan titik tempat server ini dapat dikelola dan diatur.