Bruke roller til å kontrollere ressurstilgang
Innebygde roller for Azure Resources (bruker PowerShell)
Azure har flere innebygde roller for å dekke de vanligste sikkerhetsscenarioene. Hvis du vil forstå hvordan rollene fungerer, kan vi undersøke tre roller som gjelder for alle ressurstyper:
- eier: Har full tilgang til alle ressurser, inkludert retten til å delegere tilgang til andre.
- bidragsyter: Kan opprette og administrere alle typer Azure-ressurser, men kan ikke gi tilgang til andre.
- Reader: Kan vise eksisterende Azure-ressurser.
Rolledefinisjoner
Hver rolle er et sett med egenskaper som er definert i en JSON-fil (JavaScript Object Notation). Denne rolledefinisjonen inkluderer en Name, IDog Description. Den inneholder også tillatelser som kan tillates (Handlinger), nektede tillatelser (NotActions) og omfang (for eksempel lesetilgang) for rollen.
For eierrollen betyr det alle handlinger, angitt med en stjerne (*); ingen avslåtte handlinger; og alle omfang, angitt av en skråstrek (/).
Du kan få denne informasjonen ved hjelp av PowerShell Get-AzRoleDefinition Owner
cmdlet.
Get-AzRoleDefinition Owner
Denne koden skal produsere følgende utdata:
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to resources.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
Prøv det samme for rollene bidragsyter og Leser for å se handlingene som er tillatt og avslått.
Innebygde roller
Hvis du vil ha en grundig undersøkelse av RBAC- og brukerrollene i Microsoft Entra ID, kan du se Undersøke RBAC og brukerroller i Microsoft Entra ID.
Hva er en rolledefinisjon?
En rolledefinisjon er en samling tillatelser. En rolledefinisjon viser operasjonene rollen kan utføre, for eksempel lese, skrive og slette. Den kan også vise operasjoner som ikke kan utføres eller operasjoner relatert til underliggende data.
Som tidligere beskrevet har en rolledefinisjon følgende struktur:
Navn | Beskrivelse |
---|---|
Id |
Unik identifikator for rollen, tilordnet av Azure |
IsCustom |
Sann hvis en egendefinert rolle, Usann hvis en innebygd rolle |
Description |
En lesbar beskrivelse av rollen |
Actions [] |
Tillatte tillatelser; * angir alle |
NotActions [] |
Nektet tillatelser |
DataActions [] |
Bestemte tillatte tillatelser som brukes på data, for eksempel Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read |
NotDataActions [] |
Bestemte nektede tillatelser som brukes på data. |
AssignableScopes [] |
Omfang der denne rollen gjelder, / indikerer global, men kan nå inn i et hierarkisk tre |
Denne strukturen representeres som JSON når den brukes i rollebasert tilgangskontroll (RBAC) eller fra den underliggende API-en. Her er for eksempel bidragsyter i JSON-format.
{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Lets you manage everything except access to resources.",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}
Handlinger og NotActions
Du kan skreddersy Actions
og NotActions
egenskaper for å gi og nekte de nøyaktige tillatelsene du trenger. Disse egenskapene er alltid i formatet: {Company}.{ProviderName}/{resourceType}/{action}
.
Her er for eksempel handlingene for de tre rollene vi har sett på tidligere:
Innebygd rolle | Handlinger | NotActions |
---|---|---|
Eier (tillat alle handlinger) | * |
- |
Bidragsyter (tillat alle handlinger unntatt skriving eller sletting av rolletilordninger) | * |
Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action |
Leser (tillat alle lesehandlinger) | */read |
- |
Jokertegnoperasjonen (*
) under Actions
angir at hovedstolen som er tilordnet denne rollen, kan utføre alle handlinger. eller med andre ord kan denne rollen administrere alt, inkludert handlinger definert i fremtiden etter hvert som nye ressurstyper legges til Azure. Med Reader-rollen er bare read
handlingen tillatt.
Operasjonene under NotActions
trekkes fra Actions
. Med rollen bidragsyter fjerner NotActions
denne rollens mulighet til å administrere tilgang til ressurser, og fjerner også tildeling av tilgang til ressurser.
DataActions og NotDataActions
Dataoperasjoner angis i egenskapene DataActions
og NotDataActions
. Du kan angi dataoperasjoner separat fra administrasjonsoperasjonene. Dette hindrer at gjeldende rolletilordninger med jokertegn (*
) plutselig har tilgang til data. Her er noen dataoperasjoner du kan angi i DataActions
og NotDataActions
:
- Lese en liste over blober i en beholder
- Skrive en lagringsblob i en beholder
- Slette en melding i en kø
Du kan bare legge til dataoperasjoner i DataActions
og NotDataActions
egenskaper. Ressursleverandører identifiserer hvilke operasjoner som er dataoperasjoner ved å angi egenskapen isDataAction
til true
. Roller som ikke har dataoperasjoner, kan utelate disse egenskapene fra rolledefinisjonen.
Disse handlingene fungerer akkurat som deres ledelse fettere. Du kan angi handlingene du vil tillate (eller *
for alle), og deretter angi en liste over bestemte handlinger som skal fjernes i NotDataActions
-samlingen. Her er noen eksempler. du finner den fullstendige listen over handlinger og datahandlinger i dokumentasjonen for ressursleverandøren:
Dataoperasjon | Beskrivelse |
---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete |
Slette blob-data |
Microsoft.Compute/virtualMachines/login/action |
Logge på en maskin som en vanlig bruker |
Microsoft.EventHub/namespaces/messages/send/action |
Sende meldinger på en hendelseshub |
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read |
Returnere en fil/mappe eller liste over filer/mapper |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
Lese en melding fra en kø |
Omfang som kan tilordnes
Definering av Handlinger og NotActions egenskaper er ikke nok til å implementere en rolle fullt ut. Du må også begrense rollen din på riktig måte.
Egenskapen AssignableScopes for rollen angir omfanget (abonnementer, ressursgrupper eller ressurser) der rollen er tilgjengelig for tildeling. Du kan gjøre den egendefinerte rollen tilgjengelig for tildeling bare i abonnementene eller ressursgruppene som trenger den, og dermed unngå å rote opp brukeropplevelsen for resten av abonnementene eller ressursgruppene.
Her er noen eksempler:
Til | Bruk omfang |
---|---|
Begrense til et abonnement | "/subscriptions/{sub-id}" |
Begrense til en bestemt ressursgruppe for et bestemt abonnement | "/subscriptions/{sub-id}/resourceGroups/{rg-name}" |
Begrense til en bestemt ressurs | "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}" |
Gjøre en rolle tilgjengelig for tildeling i to abonnementer | "/subscriptions/{sub-id}", "/subscriptions/{sub-id}" |
Opprett roller
Microsoft Entra ID leveres med innebygde roller som sannsynligvis vil dekke 99% av det du noensinne vil ønske å gjøre. Det er å foretrekke å bruke en innebygd rolle hvis mulig. Du kan imidlertid opprette egendefinerte roller hvis du synes det er nødvendig.
Notat
Oppretting av egendefinert rolle krever Microsoft Entra ID P1 eller P2. du kan ikke opprette egendefinerte roller i det kostnadsfrie nivået.
Du kan opprette en ny rolle gjennom flere mekanismer:
administrasjonssenteret for Microsoft Entra: Du kan bruke administrasjonssenteret for Microsoft Entra til å opprette en egendefinert rolle ved å velge roller & administratorer under Roller & administratorer i menyen til venstre, og deretter velge Ny egendefinert rolle.
Azure-portalen: Du kan bruke Azure-portalen til å opprette en egendefinert rolle ved å velge Microsoft Entra ID>Roller og administratorer>Ny egendefinert rolle.
Azure PowerShell: Du kan bruke
New-AzRoleDefinition
cmdlet til å definere en ny rolle.Azure Graph API-: Du kan bruke et REST-kall til Graph API for å opprette en ny rolle programmatisk.
Sammendragsdelen for denne modulen inneholder en kobling til dokumentasjonen for disse tilnærmingene.