Rekomendasi praktik terbaik identitas terkelola
Identitas terkelola untuk sumber daya Azure adalah fitur ID Microsoft Entra. Setiap layanan Azure yang mendukung identitas terkelola untuk sumber daya Azure tunduk pada garis waktu mereka masing-masing. Pastikan Anda meninjau status ketersediaan identitas terkelola untuk sumber daya dan masalah yang diketahui sebelum Anda memulai.
Memilih identitas terkelola yang ditetapkan oleh sistem atau pengguna
Identitas terkelola yang ditetapkan pengguna lebih efisien dalam berbagai skenario yang lebih luas daripada identitas terkelola yang ditetapkan sistem. Lihat tabel di bawah ini untuk beberapa skenario dan rekomendasi identitas yang ditetapkan pengguna atau ditetapkan sistem.
Identitas yang ditetapkan pengguna dapat digunakan oleh beberapa sumber daya, dan siklus hidup mereka dipisahkan dari siklus hidup sumber daya yang terkait. Baca sumber daya mana yang mendukung identitas terkelola.
Siklus hidup ini memungkinkan Anda untuk memisahkan pembuatan sumber daya dan tanggung jawab administrasi identitas. Identitas yang ditetapkan pengguna beserta penetapan peran dapat dikonfigurasi terlebih dahulu dari sumber daya yang mengharuskannya. Pengguna yang membuat sumber daya hanya memerlukan akses untuk menetapkan identitas yang ditetapkan pengguna, tanpa perlu membuat identitas atau penetapan peran baru.
Karena identitas yang ditetapkan sistem dibuat dan dihapus bersama dengan sumber daya, penetapan peran tidak dapat dibuat terlebih dahulu. Urutan ini dapat menyebabkan kegagalan saat menyebarkan infrastruktur jika pengguna yang membuat sumber daya tidak juga memiliki akses untuk membuat penetapan peran.
Jika infrastruktur Anda mengharuskan beberapa sumber daya memerlukan akses ke sumber daya yang sama, satu identitas yang ditetapkan pengguna dapat ditetapkan kepada mereka. Overhead administrasi akan berkurang karena ada lebih sedikit identitas dan penetapan peran yang berbeda untuk dikelola.
Jika Anda mengharuskan setiap sumber daya memiliki identitasnya sendiri, atau memiliki sumber daya yang memerlukan sekumpulan izin unik dan ingin identitas dihapus saat sumber daya dihapus, maka Anda harus menggunakan identitas yang ditetapkan sistem.
| Skenario | Rekomendasi | Catatan |
|---|---|---|
| Pembuatan sumber daya yang cepat (misalnya, komputasi sementara) dengan identitas terkelola | Identitas yang ditetapkan pengguna | Jika Anda mencoba membuat beberapa identitas terkelola dalam waktu singkat - misalnya, menyebarkan beberapa komputer virtual masing-masing dengan identitas yang ditetapkan sistem mereka sendiri - Anda dapat melebihi batas tarif untuk pembuatan objek Microsoft Entra, dan permintaan akan gagal dengan kesalahan HTTP 429. Jika sumber daya dibuat atau dihapus dengan cepat, Anda juga dapat melebihi batas jumlah sumber daya di ID Microsoft Entra jika menggunakan identitas yang ditetapkan sistem. Meskipun identitas yang ditetapkan sistem yang dihapus tidak lagi dapat diakses oleh sumber daya apa pun, hal ini akan diperhitungkan dalam batas Anda hingga dihapus sepenuhnya setelah 30 hari. Menyebarkan sumber daya yang terkait dengan satu identitas yang ditetapkan pengguna hanya akan memerlukan pembuatan satu Perwakilan Layanan di ID Microsoft Entra, menghindari batas tarif. Menggunakan satu identitas yang dibuat sebelumnya juga akan mengurangi risiko penundaan replikasi yang dapat terjadi jika beberapa sumber daya dibuat dengan identitas masing-masing. Baca selengkapnya tentang batas layanan langganan Azure. |
| Sumber daya/aplikasi yang direplikasi | Identitas yang ditetapkan pengguna | Sumber daya yang melakukan tugas yang sama - misalnya, server web duplikat atau fungsionalitas identik yang berjalan dalam layanan aplikasi dan dalam aplikasi pada komputer virtual - biasanya memerlukan izin yang sama. Dengan menggunakan identitas yang ditetapkan pengguna yang sama, diperlukan lebih sedikit penetapan peran sehingga mengurangi overhead manajemen. Sumber daya tidak harus memiliki tipe yang sama. |
| Kepatuhan | Identitas yang ditetapkan pengguna | Jika organisasi Anda mengharuskan semua pembuatan identitas melalui proses persetujuan, menggunakan satu identitas yang ditetapkan pengguna di beberapa sumber daya akan memerlukan lebih sedikit persetujuan daripada Identitas yang ditetapkan sistem, yang dibuat berdasarkan pembuatan sumber daya baru. |
| Akses diperlukan sebelum sumber daya disebarkan | Identitas yang ditetapkan pengguna | Beberapa sumber daya mungkin memerlukan akses ke sumber daya Azure tertentu sebagai bagian dari penyebarannya. Dalam hal ini, identitas yang ditetapkan sistem mungkin tidak dibuat tepat waktu sehingga identitas yang ditetapkan pengguna yang sudah ada sebelumnya harus digunakan. |
| Pengelogan Audit | Identitas yang ditetapkan sistem | Jika Anda perlu mencatat sumber daya tertentu mana yang melakukan tindakan, bukan identitas mana, gunakan identitas yang ditetapkan sistem. |
| Manajemen Siklus Hidup Izin | Identitas yang ditetapkan sistem | Jika Anda mengharuskan izin untuk sumber daya dihapus bersama dengan sumber dayanya, gunakan identitas yang ditetapkan sistem. |
Menggunakan identitas yang ditetapkan pengguna untuk mengurangi administrasi
Diagram menunjukkan perbedaan antara identitas yang ditetapkan sistem dan yang ditetapkan pengguna saat digunakan untuk memungkinkan beberapa komputer virtual mengakses dua akun penyimpanan.
Diagram menunjukkan empat komputer virtual dengan identitas yang ditetapkan sistem. Setiap komputer virtual memiliki penetapan peran yang sama yang memberi mereka akses ke dua akun penyimpanan.
Ketika identitas yang ditetapkan pengguna dikaitkan dengan empat komputer virtual, hanya dua penetapan peran yang diperlukan, dibandingkan dengan identitas yang ditetapkan sistem yang memerlukan delapan. Jika identitas komputer virtual memerlukan lebih banyak penetapan peran, peran tersebut akan diberikan izin ke semua sumber daya yang terkait dengan identitas ini.
Grup keamanan juga dapat digunakan untuk mengurangi jumlah penetapan peran yang diperlukan. Diagram ini menunjukkan empat komputer virtual dengan identitas yang ditetapkan sistem, yang telah ditambahkan ke grup keamanan, dengan penetapan peran ditambahkan ke grup alih-alih identitas yang ditetapkan sistem. Meskipun hasilnya mirip, konfigurasi ini tidak menawarkan kemampuan templat Resource Manager yang sama dengan identitas yang ditetapkan pengguna.
Beberapa identitas terkelola
Sumber daya yang mendukung identitas terkelola dapat memiliki identitas yang ditetapkan sistem dan satu atau beberapa identitas yang ditetapkan pengguna.
Model ini memberikan fleksibilitas untuk menggunakan identitas bersama yang ditetapkan pengguna dan menerapkan izin terperinci saat diperlukan.
Dalam contoh berikut, "Komputer Virtual 3" dan "Komputer Virtual 4" dapat mengakses akun penyimpanan dan brankas kunci, tergantung pada identitas yang ditetapkan pengguna mana yang mereka gunakan saat mengautentikasi.
Dalam contoh berikut, "Komputer Virtual 4" memiliki identitas yang ditetapkan pengguna, memberinya akses ke akun penyimpanan dan brankas kunci, tergantung pada identitas mana yang digunakan saat mengautentikasi. Penetapan peran untuk identitas yang ditetapkan sistem spesifik untuk komputer virtual terkait.
Batas
Lihat batasan untuk identitas terkelola dan peran kustom dan penetapan peran.
Ikuti prinsip hak istimewa paling rendah saat memberikan akses
Saat memberikan identitas apa pun, termasuk identitas terkelola, izin untuk mengakses layanan, selalu berikan izin paling rendah yang diperlukan untuk melakukan tindakan yang diinginkan. Misalnya, jika identitas terkelola digunakan untuk membaca data dari akun penyimpanan, tidak perlu memberikan izin identitas tersebut untuk juga menulis data ke akun penyimpanan. Memberikan izin tambahan, misalnya, menjadikan identitas terkelola sebagai kontributor pada langganan Azure saat tidak diperlukan, meningkatkan radius gangguan keamanan yang terkait dengan identitas. Seseorang harus selalu meminimalkan radius gangguan keamanan sehingga mengorbankan identitas tersebut menyebabkan kerusakan minimum.
Pertimbangkan efek menetapkan identitas terkelola ke sumber daya Azure dan/atau memberikan izin yang ditetapkan kepada pengguna
Penting untuk dicatat bahwa ketika sumber daya Azure, seperti Azure Logic App, fungsi Azure, atau Mesin Virtual, dll ditugaskan identitas terkelola, semua izin yang diberikan kepada identitas terkelola sekarang tersedia untuk sumber daya Azure. Hal ini penting karena jika pengguna memiliki akses untuk menginstal atau mengeksekusi kode pada sumber daya ini, maka pengguna memiliki akses ke semua identitas yang ditugaskan/terkait dengan sumber daya Azure. Tujuan dari identitas terkelola adalah untuk memberikan kode yang berjalan pada akses sumber daya Azure ke sumber daya lain, tanpa pengembang perlu menangani atau menempatkan kredensial langsung ke kode untuk mendapatkan akses itu.
Misalnya, jika Identitas terkelola (ClientId = 1234) telah diberikan akses baca/tulis ke StorageAccount7755 dan telah ditetapkan ke LogicApp3388, maka Alice, yang tidak memiliki akses langsung ke akun penyimpanan tetapi memiliki izin untuk menjalankan kode dalam LogicApp3388 juga dapat membaca/menulis data ke/dari StorageAccount7755 dengan menjalankan kode yang menggunakan identitas terkelola.
Demikian pula, jika Alice memiliki izin untuk menetapkan identitas terkelola itu sendiri, dia dapat menetapkannya ke sumber daya Azure yang berbeda dan memiliki akses ke semua izin yang tersedia untuk identitas terkelola.
Secara umum, ketika memberikan akses administratif pengguna ke sumber daya yang dapat mengeksekusi kode (seperti Aplikasi Logika) dan memiliki identitas terkelola, pertimbangkan apakah peran yang ditugaskan kepada pengguna dapat menginstal atau menjalankan kode pada sumber daya, dan jika ya, tetapkan peran itu jika pengguna benar-benar membutuhkannya.
Pemeliharaan
Identitas yang ditetapkan sistem secara otomatis dihapus ketika sumber daya dihapus, sementara siklus hidup identitas yang ditetapkan pengguna tidak terpengaruh dengan sumber daya apa pun yang terkait dengannya.
Anda harus menghapus identitas yang ditetapkan pengguna secara manual saat tidak lagi diperlukan, meskipun tidak ada sumber daya yang terkait dengannya.
Penetapan peran tidak dihapus secara otomatis saat identitas terkelola yang ditetapkan sistem atau ditetapkan pengguna telah dihapus. Penetapan peran ini harus dihapus secara manual sehingga batas penetapan peran per langganan tidak terlampaui.
Penetapan peran yang terkait dengan identitas terkelola yang dihapus akan ditampilkan sebagai "Identitas tidak ditemukan" saat dilihat di portal. Baca selengkapnya.
Penetapan peran yang tidak lagi terkait dengan pengguna atau perwakilan layanan akan muncul dengan nilai ObjectTypeUnknown. Untuk menghapusnya, Anda dapat menyalurkan beberapa perintah Azure PowerShell bersama-sama untuk mendapatkan semua penetapan peran terlebih dahulu, memfilter hanya ke yang memiliki nilai ObjectTypeUnknown, lalu menghapus penetapan peran tersebut dari Azure.
Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment
Pembatasan penggunaan identitas terkelola untuk otorisasi
Menggunakan grup ID Microsoft Entra untuk memberikan akses ke layanan adalah cara yang bagus untuk menyederhanakan proses otorisasi. Idenya sederhana - berikan izin kepada grup dan tambahkan identitas ke grup sehingga mereka mewarisi izin yang sama. Ini adalah pola yang mapan dari berbagai sistem lokal dan berfungsi dengan baik ketika identitas mewakili pengguna. Opsi lain untuk mengontrol otorisasi di ID Microsoft Entra adalah dengan menggunakan Peran Aplikasi, yang memungkinkan Anda mendeklarasikan peran yang khusus untuk aplikasi (bukan grup, yang merupakan konsep global dalam direktori). Kemudian Anda dapat menetapkan peran aplikasi ke identitas yang dikelola (serta pengguna atau grup).
Dalam kedua kasus, untuk identitas non-manusia seperti Aplikasi Microsoft Entra dan Identitas terkelola, mekanisme yang tepat tentang bagaimana informasi otorisasi ini disajikan ke aplikasi tidak cocok saat ini. Implementasi hari ini dengan ID Microsoft Entra dan Azure Role Based Access Control (Azure RBAC) menggunakan token akses yang dikeluarkan oleh ID Microsoft Entra untuk autentikasi setiap identitas. Jika identitas ditambahkan ke grup atau peran, ini dinyatakan sebagai klaim dalam token akses yang dikeluarkan oleh ID Microsoft Entra. Azure RBAC menggunakan klaim ini untuk mengevaluasi lebih lanjut aturan otorisasi untuk mengizinkan atau menolak akses.
Mengingat bahwa kelompok dan peran identitas adalah klaim dalam token akses, setiap perubahan otorisasi tidak berlaku sampai token direfresh. Untuk pengguna manusia, biasanya tidak menjadi masalah, karena pengguna dapat memperoleh token akses baru dengan keluar dan masuk lagi (atau menunggu masa pakai token berakhir, yaitu 1 jam secara default). Token identitas terkelola di sisi lain di-cache oleh infrastruktur Azure yang mendasari untuk tujuan performa dan ketahanan: agar layanan ujung belakang identitas terkelola mempertahankan cache per sumber daya URI selama sekitar 24 jam. Hal ini berarti diperlukan waktu beberapa jam agar perubahan pada grup identitas terkelola atau keanggotaan peran diterapkan. Saat ini, tidak memungkinkan untuk memaksa token identitas yang dikelola untuk direfresh sebelum berakhir. Jika Anda mengubah grup identitas terkelola atau keanggotaan peran untuk menambah atau menghapus izin, Anda mungkin perlu menunggu beberapa jam agar sumber daya Azure menggunakan identitas tersebut sehingga memiliki akses yang benar.
Jika penundaan ini tidak dapat diterima untuk kebutuhan Anda, pertimbangkan alternatif untuk menggunakan grup atau peran dalam token. Untuk memastikan bahwa perubahan pada izin untuk identitas terkelola berlaku dengan cepat, kami sarankan Anda mengelompokkan sumber daya Azure menggunakan identitas terkelola yang ditetapkan pengguna dengan izin yang diterapkan langsung ke identitas, alih-alih menambahkan atau menghapus identitas terkelola dari grup Microsoft Entra yang memiliki izin. Identitas terkelola yang ditetapkan pengguna dapat digunakan seperti grup karena dapat ditugaskan ke satu atau lebih sumber daya Azure untuk menggunakannya. Operasi penugasan dapat dikontrol dengan menggunakan Kontributor identitas terkelola dan Peran operator identitas terkelola.