Az - Basic Information

Organisasie Hiërargie

Bestuursgroepe

• Dit kan ander bestuursgroepe of subskripsies bevat.

• Dit maak dit moontlik om governance beheer soos RBAC en Azure-beleid een keer op die bestuursgroepvlak toe te pas en dit geërf te laat word deur al die subskripsies in die groep.

• 10,000 bestuurs groepe kan in 'n enkele gids ondersteun word.

• 'n Bestuursgroepboom kan tot ses vlakke diepte ondersteun. Hierdie limiet sluit nie die wortelvlak of die subskripsievlak in nie.

• Elke bestuursgroep en subskripsie kan slegs een ouer ondersteun.

• Alhoewel verskeie bestuursgroepe geskep kan word, is daar slegs 1 wortel bestuursgroep.

• Die wortel bestuursgroep bevat al die ander bestuursgroepe en subskripsies en kan nie verskuif of verwyder word nie.

• Alle subskripsies binne 'n enkele bestuursgroep moet die dieselfde Entra ID huurder vertrou.

Azure Subskripsies

• Dit is 'n ander logiese houer waar hulpbronne (VM's, DB's…) gedra kan word en gefaktureer sal word.

• Sy ouer is altyd 'n bestuursgroep (en dit kan die wortel bestuursgroep wees) aangesien subskripsies nie ander subskripsies kan bevat nie.

• Dit vertrou slegs een Entra ID gids

• Toestemmings wat op die subskripsievlak toegepas word (of enige van sy ouers) word geërf na al die hulpbronne binne die subskripsie

Hulpbron Groepe

Uit die dokumentasie: 'n Hulpbron groep is 'n houer wat verwante hulpbronne vir 'n Azure oplossing bevat. Die hulpbron groep kan al die hulpbronne vir die oplossing insluit, of slegs daardie hulpbronne wat jy as 'n groep wil bestuur. Oor die algemeen, voeg hulpbronne wat die selfde lewensiklus deel by die selfde hulpbron groep sodat jy dit maklik kan ontplooi, opdateer, en verwyder as 'n groep.

Alle hulpbronne moet binne 'n hulpbron groep wees en kan slegs aan een groep behoort, en as 'n hulpbron groep verwyder word, word al die hulpbronne daarin ook verwyder.

Azure Hulpbron ID's

Elke hulpbron in Azure het 'n Azure Hulpbron ID wat dit identifiseer.

Die formaat van 'n Azure Hulpbron ID is soos volg:

• /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

Vir 'n virtuele masjien genaamd myVM in 'n hulpbron groep myResourceGroup onder subskripsie ID 12345678-1234-1234-1234-123456789012, lyk die Azure Hulpbron ID soos volg:

• /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

Azure vs Entra ID vs Azure AD Domein Dienste

Azure

Azure is Microsoft se omvattende cloud computing platform, wat 'n wye reeks dienste bied, insluitend virtuele masjiene, databasisse, kunsmatige intelligensie, en berging. Dit dien as die grondslag vir die gasheer en bestuur van toepassings, die bou van skaalbare infrastruktuur, en die uitvoering van moderne werklas in die wolk. Azure bied gereedskap vir ontwikkelaars en IT-professionals om toepassings en dienste naatloos te skep, te ontplooi, en te bestuur, wat voorsien in 'n verskeidenheid behoeftes van startups tot groot ondernemings.

Entra ID (voorheen Azure Active Directory)

Entra ID is 'n wolk-gebaseerde identiteit en toegang bestuur diens wat ontwerp is om autentisering, autorisasie, en gebruikers toegang beheer te hanteer. Dit bied veilige toegang tot Microsoft dienste soos Office 365, Azure, en baie derdeparty SaaS toepassings. Met funksies soos enkel aanmelding (SSO), multi-faktor autentisering (MFA), en voorwaardelike toegang beleid onder andere.

Entra Domein Dienste (voorheen Azure AD DS)

Entra Domein Dienste brei die vermoëns van Entra ID uit deur bestuurde domein dienste aan te bied wat versoenbaar is met tradisionele Windows Active Directory omgewings. Dit ondersteun ou protokolle soos LDAP, Kerberos, en NTLM, wat organisasies in staat stel om ou toepassings in die wolk te migreer of te laat loop sonder om plaaslike domein kontrollers te ontplooi. Hierdie diens ondersteun ook Groep Beleid vir gesentraliseerde bestuur, wat dit geskik maak vir scenario's waar ou of AD-gebaseerde werklas saam met moderne wolkomgewings moet bestaan.

Entra ID Principals

Gebruikers

• Nuwe gebruikers

• Dui e-pos naam en domein van die geselekteerde huurder aan

• Dui Vertoonnaam aan

• Dui wagwoord aan

• Dui eienskappe aan (voornaam, posbeskrywing, kontakbesonderhede…)

• Standaard gebruiker tipe is “lid”

• Buitelandse gebruikers

• Dui e-pos aan om uit te nooi en vertoonnaam (kan 'n nie-Microsoft e-pos wees)

• Dui eienskappe aan

• Standaard gebruiker tipe is “Gaste”

Lede & Gaste Standaard Toestemmings

Jy kan dit nagaan in https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions maar onder andere aksies sal 'n lid in staat wees om:

• Lees alle gebruikers, Groepe, Toepassings, Toestelle, Rolle, Subskripsies, en hul openbare eienskappe

• Nooi Gaste (kan afgeskakel word)

• Skep Sekuriteitsgroepe

• Lees nie-verborgene Groep lidmaatskappe

• Voeg gaste by Besit groepe

• Skep nuwe toepassing (kan afgeskakel word)

• Voeg tot 50 toestelle by Azure (kan afgeskakel word)

Gebruikers Standaard Konfigureerbare Toestemmings

• Lede (dokumentasie)

• Registreer Toepassings: Standaard Ja

• Beperk nie-administrateurs van die skep van huurders: Standaard Nee

• Skep sekuriteitsgroepe: Standaard Ja

• Beperk toegang tot Microsoft Entra administrasie portaal: Standaard Nee

• Dit beperk nie API toegang tot die portaal (slegs web)

• Laat gebruikers toe om werk of skool rekening met LinkedIn te verbind: Standaard Ja

• Toon hou gebruiker aangemeld: Standaard Ja

• Beperk gebruikers van die herstel van die BitLocker sleutel(s) vir hul besit toestelle: Standaard Nee (kyk in Toestel Instellings)

• Lees ander gebruikers: Standaard Ja (deur Microsoft Graph)

• Gaste

• Gaste gebruiker toegang beperkings

• Gaste gebruikers het dieselfde toegang as lede gee alle lid gebruiker toestemmings aan gaste gebruikers standaard.

• Gaste gebruikers het beperkte toegang tot eienskappe en lidmaatskappe van gids objekte (standaard) beperk gaste toegang tot slegs hul eie gebruikersprofiel standaard. Toegang tot ander gebruikers en groep inligting is nie meer toegelaat nie.

• Gaste gebruiker toegang is beperk tot eienskappe en lidmaatskappe van hul eie gids objekte is die mees beperkende een.

• Gaste kan uitnooi

• Enige iemand in die organisasie kan gaste gebruikers uitnooi insluitend gaste en nie-administrateurs (mees inklusief) - Standaard

• Lid gebruikers en gebruikers wat aan spesifieke administrateur rolle toegeken is kan gaste gebruikers uitnooi insluitend gaste met lid toestemmings

• Slegs gebruikers wat aan spesifieke administrateur rolle toegeken is kan gaste gebruikers uitnooi

• Niemand in die organisasie kan gaste gebruikers uitnooi insluitend administrateurs (mees beperkend)

• Buitelandse gebruiker verlaat: Standaard Waar

• Laat buitelandse gebruikers toe om die organisasie te verlaat

Groepe

Daar is 2 tipes groepe:

• Sekuriteit: Hierdie tipe groep word gebruik om lede toegang te gee tot toepassings, hulpbronne en om lisensies toe te ken. Gebruikers, toestelle, diens prinsipale en ander groepe kan lede wees.

• Microsoft 365: Hierdie tipe groep word gebruik vir samewerking, wat lede toegang gee tot 'n gedeelde posbus, kalender, lêers, SharePoint webwerf, ensovoorts. Groep lede kan slegs gebruikers wees.

• Dit sal 'n e-pos adres hê met die domein van die EntraID huurder.

Daar is 2 tipes lidmaatskappe:

• Toegewyse: Laat toe om spesifieke lede handmatig aan 'n groep toe te voeg.

• Dinamiese lidmaatskap: Bestuur lidmaatskap outomaties met behulp van reëls, wat groep insluiting opdateer wanneer lede se eienskappe verander.

Diens Prinsipale

'n Diens Prinsipaal is 'n identiteit geskep vir gebruik met toepassings, gehoste dienste, en outomatiese gereedskap om toegang tot Azure hulpbronne te verkry. Hierdie toegang is beperk deur die rolle wat aan die diens prinsipaal toegeken is, wat jou beheer gee oor watter hulpbronne toegang verkry en op watter vlak. Om veiligheidsredes, word dit altyd aanbeveel om diens prinsipale met outomatiese gereedskap te gebruik eerder as om hulle toe te laat om met 'n gebruikersidentiteit aan te meld.

Dit is moontlik om direk as 'n diens prinsipaal aan te meld deur dit 'n geheim (wagwoord), 'n sertifikaat, of federale toegang aan derdeparty platforms (bv. Github Actions) oor dit te verleen.

• As jy wagwoord autentisering kies (standaard), stoor die gegenereerde wagwoord aangesien jy dit nie weer kan toegang nie.

• As jy sertifikaat autentisering kies, maak seker dat die toepassing toegang sal hê oor die private sleutel.

App Registrasies

'n App Registrasie is 'n konfigurasie wat 'n toepassing toelaat om met Entra ID te integreer en aksies uit te voer.

Sleuteldelers:

1. Toepassing ID (Kliënt ID): 'n Unieke identifiseerder vir jou app in Azure AD.

2. Herlei URIs: URL's waar Azure AD autentisering antwoorde stuur.

3. Sertifikate, Geheimen & Federale Krediete: Dit is moontlik om 'n geheim of 'n sertifikaat te genereer om as die diens prinsipaal van die toepassing aan te meld, of om federale toegang aan dit te verleen (bv. Github Actions).

4. As 'n sertifikaat of geheim gegenereer word, is dit moontlik vir 'n persoon om as die diens prinsipaal aan te meld met CLI gereedskap deur die toepassing ID, die geheim of sertifikaat en die huurder (domein of ID) te ken.

5. API Toestemmings: Spesifiseer watter hulpbronne of API's die app toegang kan verkry.

6. Autentisering Instellings: Definieer die app se ondersteunde autentisering vloei (bv., OAuth2, OpenID Connect).

7. Diens Prinsipaal: 'n diens prinsipaal word geskep wanneer 'n App geskep word (as dit vanaf die webkonsol gedoen word) of wanneer dit in 'n nuwe huurder geïnstalleer word.

8. Die diens prinsipaal sal al die gevraagde toestemmings wat dit geconfigureer is, ontvang.

Standaard Toestemming Toestemmings

Gebruiker toestemming vir toepassings

• Moet nie gebruiker toestemming toelaat nie

• 'n Administrateur sal vir alle apps benodig word.

• Laat gebruiker toestemming toe vir apps van geverifieerde uitgewers, vir geselekteerde toestemmings (Aanbeveel)

• Alle gebruikers kan toestemming gee vir toestemmings wat as "lae impak" geklassifiseer is, vir apps van geverifieerde uitgewers of apps wat in hierdie organisasie geregistreer is.

• Standaard lae impak toestemmings (alhoewel jy moet aanvaar om dit as laag by te voeg):

• User.Read - teken in en lees gebruikersprofiel

• offline_access - hou toegang tot data wat gebruikers toegang gegee het

• openid - teken gebruikers in

• profiel - sien gebruiker se basiese profiel

• e-pos - sien gebruiker se e-pos adres

• Laat gebruiker toestemming toe vir apps (Standaard)

• Alle gebruikers kan toestemming gee vir enige app om toegang tot die organisasie se data te verkry.

Admin toestemming versoeke: Standaard Nee

• Gebruikers kan admin toestemming versoek vir apps waartoe hulle nie toestemming kan gee nie

• As Ja: Dit is moontlik om Gebruikers, Groepe en Rolle aan te dui wat toestemming versoeke kan gee

• Konfigureer ook of gebruikers e-pos kennisgewings en vervaldatums herinneringe sal ontvang

Bestuurde Identiteit (Metadata)

Bestuurde identiteite in Azure Active Directory bied 'n oplossing vir outomatiese bestuur van die identiteit van toepassings. Hierdie identiteite word deur toepassings gebruik met die doel om verbinding te maak met hulpbronne wat versoenbaar is met Azure Active Directory (Azure AD) autentisering. Dit maak dit moontlik om die behoefte aan hardkoding van wolk akrediteer in die kode te verwyder aangesien die toepassing in staat sal wees om die metadata diens te kontak om 'n geldige token te verkry om aksies uit te voer as die aangeduide bestuurde identiteit in Azure.

Daar is twee tipes bestuurde identiteite:

• Stelsel-toegewyse. Sommige Azure dienste laat jou toe om 'n bestuurde identiteit direk op 'n diens instansie in te skakel. Wanneer jy 'n stelsel-toegewyse bestuurde identiteit inskakel, word 'n diens prinsipaal geskep in die Entra ID huurder wat deur die subskripsie vertrou word waar die hulpbron geleë is. Wanneer die hulpbron verwyder word, verwyder Azure outomaties die identiteit vir jou.

• Gebruiker-toegewyse. Dit is ook moontlik vir gebruikers om bestuurde identiteite te genereer. Hierdie word binne 'n hulpbron groep binne 'n subskripsie geskep en 'n diens prinsipaal sal in die EntraID geskep word wat deur die subskripsie vertrou word. Dan kan jy die bestuurde identiteit aan een of meer instansies van 'n Azure diens toewys (meerdere hulpbronne). Vir gebruiker-toegewyse bestuurde identiteite, word die identiteit apart van die hulpbronne wat dit gebruik, bestuur.

Bestuurde Identiteite genereer nie ewige akrediteer (soos wagwoorde of sertifikate) om toegang te verkry as die diens prinsipaal wat aan dit geheg is.

Enterprise Toepassings

Dit is net 'n tafel in Azure om diens prinsipale te filter en die toepassings wat aan hulle toegeken is, te kontroleer.

Dit is nie 'n ander tipe "toepassing" nie, daar is geen objek in Azure wat 'n "Enterprise Toepassing" is nie, dit is net 'n abstraksie om die Diens prinsipale, App registrasies en bestuurde identiteite te kontroleer.

Administratiewe Eenhede

Administratiewe eenhede laat toe om toestemmings van 'n rol oor 'n spesifieke gedeelte van 'n organisasie te gee.

Voorbeeld:

• Scenario: 'n maatskappy wil regionale IT administrateurs toelaat om slegs die gebruikers in hul eie streek te bestuur.

• Implementering:

• Skep Administratiewe Eenhede vir elke streek (bv., "Noord-Amerika AU", "Europa AU").

• Vul AU's met gebruikers uit hul onderskeie streke.

• AU's kan gebruikers, groepe, of toestelle bevat

• AU's ondersteun dinamiese lidmaatskappe

• AU's kan nie AU's bevat nie

• Ken Admin Rolle toe:

• Gee die "Gebruiker Administrateur" rol aan regionale IT personeel, geskaal na hul streek se AU.

• Uitkoms: Regionale IT administrateurs kan gebruikersrekeninge binne hul streek bestuur sonder om ander streke te beïnvloed.

Entra ID Rolle

• Ten einde Entra ID te bestuur, is daar 'n paar ingeboude rolle wat aan Entra ID prinsipale toegeken kan word om Entra ID te bestuur

• Kyk na die rolle in https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference

• Die mees bevoorregte rol is Globale Administrateur

• In die Beskrywing van die rol is dit moontlik om sy fynere toestemmings te sien

Rolle & Toestemmings

Rolle word toegeken aan prinsipale op 'n skaal: principal -[HAS ROLE]->(scope)

Rolle wat aan groepe toegeken word, word geërf deur al die lede van die groep.

Afhangende van die skaal waaraan die rol toegeken is, kan die rol geërf word na ander hulpbronne binne die skaal houer. Byvoorbeeld, as 'n gebruiker A 'n rol op die subskripsie het, sal hy daardie rol op al die hulpbron groepe binne die subskripsie hê en op alle hulpbronne binne die hulpbron groep.

Klassieke Rolle

Gebou-in rolle

Uit die dokumentasie: Azure rol-gebaseerde toegangbeheer (Azure RBAC) het verskeie Azure gebou-in rolle wat jy kan toekenn aan gebruikers, groepe, diens prinsipale, en bestuurde identiteite. Rol toekennings is die manier waarop jy toegang tot Azure hulpbronne beheer. As die gebou-in rolle nie aan die spesifieke behoeftes van jou organisasie voldoen nie, kan jy jou eie Azure pasgemaakte rolle.

Gebou-in rolle geld slegs vir die hulpbronne waarvoor hulle bedoel is, byvoorbeeld kyk na hierdie 2 voorbeelde van Gebou-in rolle oor Compute hulpbronne:

Hierdie rolle kan ook toegeken word oor logiese houers (soos bestuursgroepe, subskripsies en hulpbron groepe) en die prinsipale wat geraak word, sal dit oor die hulpbronne binne daardie houers hê.

• Vind hier 'n lys met alle Azure gebou-in rolle.

• Vind hier 'n lys met alle Entra ID gebou-in rolle.

Pasgemaakte Rolle

• Dit is ook moontlik om pasgemaakte rolle te skep

• Hulle word binne 'n skaal geskep, alhoewel 'n rol in verskeie skale kan wees (bestuursgroepe, subskripsie en hulpbron groepe)

• Dit is moontlik om al die fynere toestemmings wat die pasgemaakte rol sal hê, te konfigureer

• Dit is moontlik om toestemmings uit te sluit

• 'n prinsipaal met 'n uitgeslote toestemming sal dit nie kan gebruik nie, selfs al word die toestemming elders toegeken

• Dit is moontlik om wildcard te gebruik

• Die gebruikte formaat is 'n JSON

• actions is vir die beheer van aksies oor die hulpbron

• dataActions is toestemmings oor die data binne die objek

Voorbeeld van toestemmings JSON vir 'n pasgemaakte rol:

{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": [
"/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"
],
"permissions": [
{
"actions": [
"Microsoft.DigitalTwins/register/action",
"Microsoft.DigitalTwins/unregister/action",
"Microsoft.DigitalTwins/operations/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/write",
"Microsoft.CostManagement/exports/*"
],
"notActions": [
"Astronomer.Astro/register/action",
"Astronomer.Astro/unregister/action",
"Astronomer.Astro/operations/read",
"Astronomer.Astro/organizations/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}

Permissies volgorde

• Om 'n hoofpersoon toegang tot 'n hulpbron te hê, moet daar 'n eksplisiete rol aan hom toegeken word (op enige manier) wat hom daardie toestemming gee.

• 'n Eksplisiete weier roltoewysing het voorrang bo die rol wat die toestemming gee.

Globale Administrateur

Globale Administrateur is 'n rol van Entra ID wat volledige beheer oor die Entra ID huurder gee. Dit gee egter nie standaard enige toestemmings oor Azure hulpbronne nie.

Gebruikers met die Globale Administrateur rol het die vermoë om 'te verhoog' na die Gebruikers Toegang Administrateur Azure rol in die Wortel Bestuur Groep. So kan Globale Administrateurs toegang in alle Azure subskripsies en bestuursgroepe bestuur. Hierdie verhoging kan aan die einde van die bladsy gedoen word: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Azure Beleide

Azure Beleide is reëls wat organisasies help om te verseker dat hul hulpbronne aan spesifieke standaarde en nakomingsvereistes voldoen. Hulle stel jou in staat om instellings op hulpbronne in Azure af te dwing of te oudit. Byvoorbeeld, jy kan die skepping van virtuele masjiene in 'n nie-geautoriseerde streek voorkom of verseker dat alle hulpbronne spesifieke etikette het vir opsporing.

Azure Beleide is proaktief: hulle kan nie-nakomende hulpbronne stop om geskep of verander te word. Hulle is ook reaktief, wat jou toelaat om bestaande nie-nakomende hulpbronne te vind en reg te stel.

Belangrike Konsepte

1. Beleid Definisie: 'n Reël, geskryf in JSON, wat spesifiseer wat toegelaat of vereis word.

2. Beleid Toewysing: Die toepassing van 'n beleid op 'n spesifieke omvang (bv. subskripsie, hulpbron groep).

3. Inisiatiewe: 'n Versameling van beleide wat saamgegroepeer is vir breër afdwinging.

4. Effek: Spesifiseer wat gebeur wanneer die beleid geaktiveer word (bv. "Weier," "Oudit," of "Voeg by").

Sommige voorbeelde:

1. Verseker Nakoming met Spesifieke Azure Streke: Hierdie beleid verseker dat alle hulpbronne in spesifieke Azure streke ontplooi word. Byvoorbeeld, 'n maatskappy mag wil verseker dat al sy data in Europa gestoor word vir GDPR-nakoming.

2. Afgedwonge Naamstandaarde: Beleide kan naamkonvensies vir Azure hulpbronne afdwing. Dit help om hulpbronne te organiseer en maklik te identifiseer op grond van hul name, wat nuttig is in groot omgewings.

3. Beperking van Sekere Hulpbron Tipes: Hierdie beleid kan die skepping van sekere tipes hulpbronne beperk. Byvoorbeeld, 'n beleid kan ingestel word om die skepping van duur hulpbron tipes, soos sekere VM-groottes, te voorkom om koste te beheer.

4. Afgedwonge Etikettering Beleide: Etikette is sleutel-waarde pare wat met Azure hulpbronne geassosieer word en gebruik word vir hulpbronbestuur. Beleide kan afdwing dat sekere etikette teenwoordig moet wees, of spesifieke waardes moet hê, vir alle hulpbronne. Dit is nuttig vir kostebestuur, eienaarskap, of kategorisering van hulpbronne.

5. Beperking van Publieke Toegang tot Hulpbronne: Beleide kan afdwing dat sekere hulpbronne, soos stoor rekeninge of databasisse, nie publieke eindpunte het nie, wat verseker dat hulle slegs binne die organisasie se netwerk toeganklik is.

6. Outomatiese Toepassing van Sekuriteitsinstellings: Beleide kan gebruik word om outomaties sekuriteitsinstellings op hulpbronne toe te pas, soos om 'n spesifieke netwerk sekuriteitsgroep op alle VM's toe te pas of om te verseker dat alle stoor rekeninge versleuteling gebruik.

Let daarop dat Azure Beleide aan enige vlak van die Azure hiërargie geheg kan word, maar hulle word gewoonlik in die wortel bestuursgroep of in ander bestuursgroepe gebruik.

Azure beleid json voorbeeld:

{
"policyRule": {
"if": {
"field": "location",
"notIn": [
"eastus",
"westus"
]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}

Toestemmings Erf

In Azure kan toestemmings aan enige deel van die hiërargie toegeken word. Dit sluit bestuursgroepe, subskripsies, hulpbron groepe, en individuele hulpbronne in. Toestemmings word geërf deur die hulpbronne van die entiteit waar hulle toegeken is.

Hierdie hiërargiese struktuur stel in staat vir doeltreffende en skaalbare bestuur van toegangstoestemmings.

Azure RBAC vs ABAC

RBAC (rol-gebaseerde toegangbeheer) is wat ons reeds in die vorige afdelings gesien het: 'n rol aan 'n prinsiep toe te ken om hom toegang te gee oor 'n hulpbron. E however, in sommige gevalle wil jy dalk meer fyn-granulêre toegangsbewaking bied of die bestuur van honderde rol toekennings vereenvoudig.

Azure ABAC (attribuut-gebaseerde toegangbeheer) bou op Azure RBAC deur roltoekenningsvoorwaardes gebaseer op attribuute in die konteks van spesifieke aksies by te voeg. 'n roltoekenningsvoorwaarde is 'n addisionele kontrole wat jy opsioneel aan jou roltoekenning kan voeg om meer fyn-granulêre toegangbeheer te bied. 'n Voorwaarde filter die toestemmings wat as deel van die roldefinisie en roltoekenning toegeken word. Byvoorbeeld, jy kan 'n voorwaarde byvoeg wat vereis dat 'n objek 'n spesifieke etiket moet hê om die objek te lees. Jy kan nie eksplisiet toegang tot spesifieke hulpbronne weier nie met behulp van voorwaardes.

Verwysings

• https://learn.microsoft.com/en-us/azure/governance/management-groups/overview

• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions

• https://abouttmc.com/glossary/azure-subscription/#:~:text=An%20Azure%20subscription%20is%20a,the%20subscription%20it%20belongs%20to.

• https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource

• https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration