System-Assigned vs. User-Assigned Azure Managed Identities: Mana yang Sebaiknya Anda Pilih?

By Mirko Peters · 2026-10-26

Bandingkan identitas terkelola Azure yang ditetapkan sistem dan yang ditetapkan pengguna. Pelajari jenis identitas mana yang harus dipilih untuk mengurangi beban administrasi dan meningkatkan skala dengan aman.

Automatically translated with AI from the original post. Read the English original

Memilih antara identitas terkelola yang ditetapkan sistem dan yang ditetapkan pengguna di Azure adalah salah satu keputusan arsitektur paling krusial untuk keamanan cloud dan beban administrasi. Identitas yang ditetapkan sistem terikat langsung dengan siklus hidup satu resource Azure. Sebaliknya, identitas yang ditetapkan pengguna berfungsi sebagai entitas mandiri yang dapat dibagikan ke beberapa resource. Cara ini secara signifikan mengurangi penetapan peran yang berulang dan mencegah hambatan batas token di lingkungan otomatis.

Poin Penting

• Identitas yang ditetapkan sistem dibuat, dikelola, dan dihapus secara otomatis bersama resource Azure induknya.
• Identitas yang ditetapkan pengguna ada secara independen sebagai resource Azure mandiri, sehingga dapat dibagikan ke beberapa VM, aplikasi, dan fungsi.
• Microsoft merekomendasikan identitas yang ditetapkan pengguna untuk sebagian besar skenario dengan banyak resource guna meminimalkan pencatatan dan penetapan peran yang rumit.
• Menggunakan identitas yang ditetapkan sistem di lingkungan uji coba yang skalanya cepat berubah atau berumur pendek dapat menyebabkan identitas menumpuk dan memicu batas laju (rate limit) Azure.
• Satu resource Azure dapat menjalankan identitas yang ditetapkan sistem untuk pencatatan yang terisolasi sekaligus satu atau beberapa identitas yang ditetapkan pengguna untuk beban kerja bersama.

Memahami Perbedaan Utama

Ketika Anda mulai merancang aplikasi cloud yang aman tanpa secret atau connection string yang ditulis langsung dalam kode, Anda harus memutuskan bagaimana beban kerja Anda akan melakukan autentikasi ke Microsoft Entra ID. Azure menawarkan dua jenis identitas terkelola: yang ditetapkan sistem dan yang ditetapkan pengguna. Memahami cara kerja keduanya di balik layar akan menghemat waktu tim engineering Anda dalam jumlah besar, baik untuk pemecahan masalah maupun pemeliharaan administratif.

Cara Kerja Identitas yang Ditetapkan Sistem

Identitas terkelola yang ditetapkan sistem diaktifkan langsung di dalam resource Azure tertentu, seperti Azure Virtual Machine, App Service, atau Function App. Anggap saja identitas ini lahir bersama resource dan ikut berakhir bersamanya. Ketika Anda mengaktifkan identitas yang ditetapkan sistem pada virtual machine, Azure membuat identitas di Microsoft Entra ID dengan nama yang persis sama dengan nama resource tersebut.

Manfaat utama pendekatan ini adalah kesederhanaan dan keterikatan siklus hidup. Karena identitas terikat pada resource, Anda tidak perlu khawatir identitas yatim tertinggal di direktori setelah virtual machine dinonaktifkan. Jika Anda menghapus resource, Azure secara otomatis menghapus identitasnya. Namun, keterikatan yang erat ini menimbulkan keterbatasan arsitektur jika Anda memiliki beberapa resource yang memerlukan izin akses yang sama.

Cara Kerja Identitas yang Ditetapkan Pengguna

Identitas terkelola yang ditetapkan pengguna, sebaliknya, dibuat terlebih dahulu sebagai resource Azure yang mandiri. Anda memberinya nama khusus, mengelolanya secara independen dalam resource group, lalu menghubungkannya secara eksplisit ke satu atau beberapa layanan Azure yang memerlukan akses. Karena tidak terikat pada siklus hidup virtual machine atau app service tertentu, identitas ini tetap ada meskipun semua resource yang terhubung dengannya dihapus.

Sifat mandiri ini mengubah cara arsitek cloud menangani manajemen akses dalam skala besar. Alih-alih memperlakukan autentikasi sebagai hubungan satu-ke-satu antara satu server dan satu database, identitas yang ditetapkan pengguna memungkinkan Anda membangun model autentikasi banyak-ke-satu, di mana kelompok microservice berbagi satu konteks keamanan yang terkelola dengan baik.

Beban Administrasi dan Penetapan Peran

Perbedaan praktis antara kedua jenis identitas ini menjadi sangat terasa ketika Anda mengelola kontrol akses berbasis peran (RBAC) di lingkungan berskala besar. Setiap kali Anda memberikan akses kepada identitas ke akun penyimpanan, Key Vault, atau database, Anda harus membuat penetapan peran Azure.

Bayangkan skenario perusahaan yang umum: Anda memiliki empat mesin virtual yang semuanya perlu membaca data dari dua akun penyimpanan Azure yang berbeda. Jika Anda hanya mengandalkan identitas yang ditetapkan sistem, setiap mesin virtual memerlukan identitasnya sendiri. Untuk memberikan akses, Anda harus mengonfigurasi delapan penetapan peran terpisah, yaitu satu untuk setiap mesin di setiap akun penyimpanan. Jika Anda menskalakan menjadi dua puluh mesin virtual, jumlah penetapan peran akan membengkak secara eksponensial dan menciptakan mimpi buruk administratif.

Sebaliknya, jika keempat mesin virtual tersebut berbagi satu identitas terkelola yang ditetapkan pengguna, Anda hanya perlu membuat dua penetapan peran secara total. Anda tetap mendapatkan kontrol akses yang sama granularnya dengan usaha pengelolaan yang jauh lebih kecil. Ketika anggota tim keluar atau infrastruktur dibangun ulang, menjaga direktori tetap bersih menjadi jauh lebih sederhana.

Jebakan Arsitektur dan Kasus Tepi

Meskipun identitas yang ditetapkan pengguna umumnya lebih efisien, memilih jenis yang salah dapat menimbulkan gesekan operasional yang tersembunyi. Salah satu bahaya utamanya melibatkan sumber daya komputasi berumur pendek atau lingkungan penskalaan otomatis.

Jika Anda menyediakan dan menghapus lingkungan pengembangan, pengujian, atau kontainer secara cepat sepanjang hari menggunakan identitas yang ditetapkan sistem, identitas-identitas tersebut akan menumpuk di Microsoft Entra ID sebelum rutinitas pembersihan dijalankan. Lama-kelamaan, organisasi dapat mencapai batas laju direktori Azure, sehingga platform menolak seluruh permintaan pembuatan sumber daya baru. Berbagi identitas yang ditetapkan pengguna di seluruh beban kerja sementara ini sepenuhnya menghindari jebakan tersebut.

Sebaliknya, identitas yang ditetapkan sistem unggul dalam dua skenario spesifik:

• Auditing dan Nirsangkal: Jika log keamanan Anda harus membuktikan secara pasti mesin virtual mana yang melakukan tindakan tertentu, identitas yang ditetapkan sistem memberikan atribusi mikro tersebut karena setiap sumber daya memiliki objek direktori unik sendiri.
• Pembersihan Siklus Hidup yang Ketat: Jika persyaratan kepatuhan mewajibkan agar seluruh izin akses hilang pada saat sumber daya dihentikan, identitas yang ditetapkan sistem menanganinya secara otomatis tanpa intervensi manusia.

Ingatlah bahwa Anda tidak harus memilih secara mutlak salah satu. Satu sumber daya Azure dapat memiliki identitas yang ditetapkan sistem untuk operasi pribadi yang sensitif, sekaligus satu atau beberapa identitas yang ditetapkan pengguna untuk alur kerja perusahaan yang dipakai bersama.

Kesimpulan

Mengelola identitas di cloud Microsoft menuntut keseimbangan antara efisiensi operasional dan batasan keamanan yang ketat. Dengan memahami perbedaan operasional yang jelas antara identitas yang ditetapkan sistem dan yang ditetapkan pengguna, Anda dapat merancang arsitektur yang tangguh dan dapat diskalakan yang menghilangkan rahasia yang di-hardcode tanpa menambah beban administratif yang berlebihan.

Untuk mendalami cara token diterbitkan, cara Azure Key Vault terintegrasi tanpa kata sandi, dan jebakan keamanan umum yang perlu dihindari, pastikan Anda Dengarkan episode lengkapnya dari podcast untuk wawasan dari para ahli dan strategi praktis.

Pertanyaan Umum

Dapatkah satu sumber daya Azure menggunakan identitas terkelola yang ditetapkan sistem sekaligus yang ditetapkan pengguna?

Ya. Sumber daya Azure seperti Virtual Machine atau App Service dapat memiliki satu identitas yang ditetapkan sistem dan satu atau beberapa identitas yang ditetapkan pengguna yang diaktifkan secara bersamaan, sehingga Anda dapat memadukan strategi autentikasi yang khusus dan yang dipakai bersama.

Apa yang terjadi pada identitas yang ditetapkan pengguna ketika sumber daya Azure yang terpasang padanya dihapus?

Berbeda dengan identitas yang ditetapkan sistem, yang otomatis dihapus ketika sumber daya induknya dihapus, identitas yang ditetapkan pengguna tetap ada sebagai objek mandiri di Azure hingga seorang administrator menghapusnya secara eksplisit.

Mengapa Microsoft merekomendasikan identitas yang ditetapkan pengguna untuk sebagian besar skenario multi-sumber daya?

Microsoft merekomendasikan identitas yang ditetapkan pengguna terutama untuk mengurangi beban administratif dan penyebaran penetapan peran yang tidak terkendali. Berbagi satu identitas di beberapa sumber daya komputasi secara signifikan mengurangi jumlah penetapan RBAC yang perlu Anda buat dan kelola.

Apakah identitas terkelola dikenakan biaya saat dijalankan di Azure?

Tidak, baik identitas terkelola yang ditetapkan sistem maupun yang ditetapkan pengguna adalah fitur gratis yang disertakan dengan Microsoft Entra ID untuk Azure resources, meskipun biaya standar mungkin berlaku untuk layanan komputasi atau penyimpanan dasar yang Anda akses.