Panduan Akses Manajemen Azure RBAC: Memahami Role, Scope, dan Role Assignment

Oktober 19, 2026 • 0 • menit membaca

Daftar Isi

Siapa boleh melakukan apa, dan di mana? Pertanyaan itu dijawab oleh Azure RBAC. Dalam Azure RBAC tutorial ini, Anda akan memahami tiga elemen kuncinya (security principal, role, dan scope), cara menghubungkannya lewat role assignment Azure, serta perbedaannya dengan peran di Microsoft Entra ID dan akses data plane.

Artikel ini membahas role based access control Azure secara hands-on dengan contoh Portal, Azure CLI, PowerShell, dan custom role JSON. Pembahasan Azure scope RBAC dan pewarisannya juga menjadi materi inti AZ-104 dan bersinggungan dengan SC-300.

1. Pengenalan Azure RBAC sebagai Mekanisme Authorization di Azure

Azure Role-Based Access Control (RBAC) adalah sistem otorisasi (authorization) yang dibangun di atas Azure Resource Manager (ARM). Ia menentukan apa yang boleh dilakukan sebuah identitas terhadap resource Azure.

Authentication vs Authorization:

Authentication: membuktikan siapa Anda. Dilakukan oleh Microsoft Entra ID (kata sandi, MFA, dan seterusnya).
Authorization: menentukan apa yang boleh Anda lakukan. Dilakukan oleh Azure RBAC.

Alurnya sederhana:

Karakteristik penting Azure RBAC:

Aditif: izin dari beberapa role assignment digabungkan.
Diwariskan ke bawah melalui hirarki scope.
Gratis, tersedia di semua subscription Azure.
Selain role assignment, ada deny assignment yang menolak aksi tertentu. Deny assignment dibuat oleh layanan tertentu (misalnya Deployment Stacks atau managed applications), bukan dibuat langsung oleh pengguna biasa.

2. Memahami 3 Elemen Kunci Azure RBAC

Setiap pemberian akses terdiri dari tiga elemen: siapa, apa, dan di mana.

Security Principal (Siapa)

Security principal adalah identitas yang meminta akses ke resource Azure.

Tipe	Penjelasan	Contoh
User	Individu dengan akun di Entra ID	budi@contoso.com
Group	Kumpulan user (dan identitas lain)	grp-azure-ops
Service Principal	Identitas untuk aplikasi atau alat otomasi	Aplikasi pipeline CI/CD
Managed Identity	Identitas yang dikelola Azure untuk resource, tanpa mengelola secret	VM atau App Service yang mengakses Key Vault

Managed identity terdiri dari system-assigned (terikat pada siklus hidup satu resource) dan user-assigned (dibuat terpisah dan dapat dipakai banyak resource).

Praktik terbaik: berikan akses ke group, bukan user individual, dan pakai managed identity alih-alih service principal dengan secret bila memungkinkan.

Role Definition (Apa yang Bisa Dilakukan)

Role definition adalah kumpulan izin yang berisi daftar operasi yang diizinkan (dan tidak diizinkan). Azure menyediakan built-in roles dalam jumlah ratusan, dan Anda dapat membuat custom roles.

Built-in Roles Fundamental

Role	Hak Akses	Dapat Mengelola Akses?
Owner	Akses penuh ke semua resource	Ya
Contributor	Membuat dan mengelola semua jenis resource	Tidak
Reader	Hanya melihat resource	Tidak
User Access Administrator	Hanya mengelola akses pengguna ke resource Azure	Ya (akses saja)

Selain empat role dasar di atas, ada banyak role spesifik layanan, misalnya:

Virtual Machine Contributor: mengelola VM, tetapi tidak jaringan atau storage yang terkait.
Network Contributor: mengelola resource jaringan.
Storage Blob Data Reader dan Storage Blob Data Contributor: akses ke data blob (data plane).
Key Vault Secrets User: membaca secret di Key Vault (data plane).
Security Reader dan Monitoring Reader: melihat data keamanan dan monitoring.
Role Based Access Control Administrator: menetapkan role, dengan kemungkinan dibatasi memakai kondisi, sebagai alternatif yang lebih sempit dari Owner atau User Access Administrator.

Owner, Contributor, User Access Administrator, dan RBAC Administrator termasuk privileged administrator roles, jadi gunakan dengan sangat hati-hati.

Kapan Membuat Custom Roles

Buat custom role bila:

Tidak ada built-in role yang cocok dengan kebutuhan least privilege Anda.
Built-in role terlalu luas, dan Anda hanya butuh beberapa operasi.
Anda perlu menggabungkan izin lintas layanan untuk satu fungsi pekerjaan.

Sebelum membuatnya, periksa dulu apakah kombinasi beberapa built-in role sudah memadai. Custom role menambah beban pemeliharaan, jadi dokumentasikan dan tinjau secara berkala.

Struktur custom role (JSON):

Actions: operasi control plane yang diizinkan.
NotActions: operasi yang dikurangkan dari Actions. Ini bukan deny rule. Bila pengguna mendapat izin yang sama dari role lain, izin itu tetap berlaku.
DataActions dan NotDataActions: operasi data plane.
AssignableScopes: scope tempat role boleh ditetapkan.

Contoh custom role untuk operator VM (file vm-operator.json):

{
  "Name": "Virtual Machine Operator",
  "IsCustom": true,
  "Description": "Dapat melihat, menjalankan, dan me-restart VM.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Resources/subscriptions/resourceGroups/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>"
  ]
}

Perintah CLI terkait custom role:

# Membuat custom role dari file JSON
az role definition create --role-definition vm-operator.json

# Melihat daftar role dan detail sebuah role
az role definition list --name 'Virtual Machine Operator'

Daftar operasi yang tersedia dapat dilihat lewat az provider operation list atau di dokumentasi resource provider operations.

Scope (Di Mana Izin Berlaku)

Scope adalah batas (scope boundary) tempat akses berlaku. Azure RBAC memiliki empat tingkat scope:

Management Group
   +-- Subscription
          +-- Resource Group
                 +-- Resource (VM, Storage Account, VNet, SQL Database)

Contoh format scope:

Tingkat	Contoh Scope
Management Group	`/providers/Microsoft.Management/managementGroups/mg-prod`
Subscription	`/subscriptions/<subscription-id>`
Resource Group	`/subscriptions/<subscription-id>/resourceGroups/rg-app1`
Resource	`/subscriptions/<subscription-id>/resourceGroups/rg-app1/providers/Microsoft.Compute/virtualMachines/vm-web01`

Inheritance (pewarisan): role assignment di scope induk berlaku ke semua scope di bawahnya. Misalnya Reader di subscription berarti Reader untuk semua resource group dan resource di dalamnya.

Prinsip penting:

Pewarisan bersifat aditif. Anda tidak bisa mencabut izin warisan dengan role assignment lain di scope yang lebih rendah.
Tetapkan akses pada scope paling sempit yang masih memenuhi kebutuhan.
Hindari assignment di management group atau subscription kecuali memang diperlukan lintas banyak resource.

3. Konsep Role Assignment dan Prinsip Least Privilege

Role assignment adalah proses menghubungkan security principal, role definition, dan scope untuk memberi akses. Tanpa role assignment, identitas yang sudah login pun tidak dapat melakukan operasi pada resource.

Cara Membuat Role Assignment di Azure Portal

Buka scope yang dituju (misalnya resource group) di Azure Portal.
Pilih Access control (IAM).
Klik Add > Add role assignment.
Pada tab Role, pilih role (misalnya Reader).
Pada tab Members, pilih User, group, or service principal (atau Managed identity), lalu pilih identitasnya.
Opsional: atur Conditions (misalnya untuk akses storage berbasis atribut).
Klik Review + assign.

Anda juga dapat memakai tab Check access untuk melihat akses efektif seseorang, dan tab Role assignments untuk melihat siapa saja yang memiliki akses di scope itu.

Izin yang diperlukan: untuk menetapkan role, Anda butuh izin Microsoft.Authorization/roleAssignments/write, yang dimiliki antara lain oleh Owner, User Access Administrator, dan RBAC Administrator.

Azure CLI

# Memberi peran Reader ke sebuah group pada resource group
az role assignment create \
  --assignee-object-id <group-object-id> \
  --assignee-principal-type Group \
  --role Reader \
  --scope /subscriptions/<subscription-id>/resourceGroups/rg-app1

# Melihat role assignment pada sebuah scope
az role assignment list \
  --scope /subscriptions/<subscription-id>/resourceGroups/rg-app1 \
  --output table

# Melihat semua assignment milik sebuah identitas, termasuk yang diwariskan
az role assignment list --assignee <object-id-atau-upn> --all --output table

# Menghapus role assignment
az role assignment delete \
  --assignee <object-id> \
  --role Reader \
  --scope /subscriptions/<subscription-id>/resourceGroups/rg-app1

Azure PowerShell

# Memberi peran Reader ke sebuah group pada resource group
New-AzRoleAssignment `
  -ObjectId <group-object-id> `
  -RoleDefinitionName 'Reader' `
  -ResourceGroupName 'rg-app1'

# Melihat role assignment
Get-AzRoleAssignment -ResourceGroupName 'rg-app1'

Perubahan role assignment dapat membutuhkan beberapa menit untuk berlaku sepenuhnya.

Menerapkan Prinsip Least Privilege

Least Privilege Principle berarti memberi izin sekecil mungkin, pada scope sesempit mungkin, selama waktu sesingkat mungkin.

Pilih role paling spesifik: gunakan Virtual Machine Contributor, bukan Contributor, untuk operator VM.
Pilih scope paling sempit: satu resource group, bukan seluruh subscription.
Batasi durasi: gunakan Privileged Identity Management (PIM) untuk akses just-in-time pada role istimewa (membutuhkan lisensi yang sesuai).
Tinjau berkala: lakukan access reviews untuk membersihkan akses yang tidak lagi dibutuhkan.

4. Perbedaan Akses Kontrol: Azure RBAC, Entra ID Roles, dan Data Plane

Azure RBAC vs Microsoft Entra ID Roles

Keduanya sama-sama memakai konsep role, tetapi mengatur objek yang berbeda.

Aspek	Azure RBAC	Microsoft Entra ID Roles
Mengatur akses ke	Resource Azure (VM, storage, VNet, dan lain-lain)	Objek direktori (user, group, aplikasi, pengaturan tenant)
Scope	Management group, subscription, resource group, resource	Tenant, atau administrative unit
Contoh role	Owner, Contributor, Reader	Global Administrator, User Administrator
Dikelola lewat	Access control (IAM) di Azure Portal	Microsoft Entra admin center, Roles and administrators
API	Azure Resource Manager	Microsoft Graph

Keduanya terpisah secara default. Seorang Global Administrator tidak otomatis punya akses ke resource Azure. Namun Global Administrator dapat melakukan elevate access untuk mendapatkan peran User Access Administrator di root scope, sehingga fitur ini perlu dipantau dan dibatasi.

Control Plane vs Data Plane

Azure RBAC mengatur dua jenis operasi:

Control plane (management plane): operasi yang mengelola resource lewat ARM, misalnya membuat, mengubah, atau menghapus storage account. Diatur oleh Actions.
Data plane: operasi terhadap data di dalam resource, misalnya membaca blob, mengambil secret dari Key Vault, atau mengirim pesan ke queue. Diatur oleh DataActions.

Aspek	Control Plane	Data Plane
Fokus	Mengelola resource	Mengakses data dalam resource
Contoh operasi	Membuat VM, mengubah konfigurasi storage account	Membaca blob, membaca secret Key Vault
Atribut di role	Actions, NotActions	DataActions, NotDataActions
Contoh role	Contributor, Virtual Machine Contributor	Storage Blob Data Contributor, Key Vault Secrets User

Poin penting:

Role Owner dan Contributor umumnya tidak memberi akses data plane. Pengguna Contributor tidak otomatis bisa membaca isi blob lewat Entra ID, dan perlu role data seperti Storage Blob Data Reader.
Namun Contributor dapat mengambil access key storage account (aksi control plane), lalu memakainya untuk mengakses data. Karena itu, pertimbangkan menonaktifkan akses shared key dan memakai autentikasi Entra ID dengan RBAC.
Key Vault mendukung model Azure RBAC dan model access policy lama. Microsoft menyarankan model RBAC untuk pengelolaan yang konsisten.
Beberapa layanan memiliki sistem data plane sendiri, misalnya permission di dalam database SQL atau RBAC data plane Cosmos DB, jadi pahami model akses tiap layanan.

Referensi sertifikasi: AZ-104 menguji pemberian akses lewat Azure RBAC, pembuatan custom role, dan interpretasi role assignment. SC-300 mendalami peran Entra ID, PIM, dan access reviews.

5. Tabel Matriks Ringkas Elemen Azure RBAC

Komponen	Definisi	Contoh Nyata	Praktik Terbaik
Security Principal	Identitas yang meminta akses (user, group, service principal, managed identity)	Group grp-azure-ops, managed identity milik App Service	Gunakan group untuk manusia, managed identity untuk workload, hindari secret yang berumur panjang
Role Definition	Kumpulan izin (Actions dan DataActions)	Reader, Contributor, Owner, custom role Virtual Machine Operator	Pilih role paling spesifik, buat custom role hanya bila built-in tidak cukup
Scope	Batas tempat akses berlaku: management group, subscription, resource group, resource	Resource group rg-app1	Tetapkan di scope paling sempit yang memenuhi kebutuhan
Role Assignment	Ikatan principal, role, dan scope	Group grp-azure-ops mendapat Reader di rg-app1	Dokumentasikan, tinjau berkala, dan hapus yang sudah tidak diperlukan
Inheritance	Pewarisan assignment dari scope induk ke bawah	Reader di subscription berlaku ke seluruh resource group	Hati-hati menetapkan di scope tinggi karena dampaknya luas
Control vs Data plane	Operasi manajemen resource vs akses ke data	Contributor (control plane), Storage Blob Data Reader (data plane)	Berikan role data plane secara terpisah, dan pertimbangkan menonaktifkan akses key
PIM (just-in-time)	Akses istimewa yang bersifat sementara dan perlu aktivasi	Owner yang diaktifkan 2 jam saat deployment	Gunakan untuk role istimewa, wajibkan MFA dan alasan aktivasi

Kesimpulan

Role based access control Azure bekerja dengan menggabungkan siapa (security principal), apa (role definition), dan di mana (scope) melalui role assignment. Memahami pewarisan scope, perbedaan control plane vs data plane, serta batas antara Azure RBAC dan Entra ID roles akan membuat Anda mampu memberi akses yang tepat, tidak lebih dan tidak kurang. Itulah inti dari setiap azure rbac tutorial yang baik, dan fondasi untuk lulus AZ-104.

Tips Keamanan agar Tidak Over-Privileged

Terapkan least privilege secara konsisten: role paling spesifik, scope paling sempit, durasi paling singkat.
Hindari Owner dan Contributor sebagai jawaban default. Banyak kebutuhan cukup dengan Reader atau role spesifik layanan.
Batasi jumlah Owner di setiap subscription (praktik umum adalah beberapa saja), dan kelola akses istimewa lewat PIM.
Berikan akses ke group, bukan individu, agar mudah diaudit dan diubah saat orang berpindah peran.
Gunakan managed identity untuk aplikasi dan otomasi, bukan akun pengguna atau secret statis.
Pisahkan akses control plane dan data plane. Berikan role data hanya pada yang membutuhkan, dan pertimbangkan menonaktifkan shared key pada storage.
Buat custom role seperlunya, dokumentasikan alasannya, dan tinjau berkala agar tidak menumpuk.
Lakukan access review secara berkala dan hapus assignment yang tidak lagi dipakai, termasuk identitas yang sudah dihapus.
Audit dan pantau: tinjau Activity Log untuk perubahan role assignment, dan buat alert untuk penetapan role istimewa.
Batasi dan pantau elevate access Global Administrator, serta gunakan akun admin terpisah dengan MFA.
Kombinasikan dengan Azure Policy dan Resource Locks sebagai lapisan pengaman tambahan, karena RBAC mengatur siapa, bukan konfigurasi apa yang diizinkan.
Uji di lingkungan non-produksi sebelum mengubah akses pada scope tinggi.

Dengan disiplin pada least privilege dan peninjauan berkala, Anda mengurangi risiko penyalahgunaan akses sekaligus menjaga operasional tetap lancar.

PintarAzure - Belajar Microsoft Azure