# Az - Basiese Inligting

{{#include ../../../banners/hacktricks-training.md}}

## Organisasie Hiërargie

<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUcVrh1BpuQXN7RzGqoxrn-4Nm_sjdJU-dDTvshloB7UMQnN1mtH9N94zNiPCzOYAqE9EsJqlboZOj47tQsQktjxszpKvIDPZLs9rgyiObcZCvl7N0ZWztshR0ZddyBYZIAwPIkrEQ=s2048?key=l3Eei079oPmVJuh8lxQYxxrB" alt=""><figcaption><p><a href="https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png">https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png</a></p></figcaption></figure>

### 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 huur** vertrou.

<figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>

### 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 (of enige van sy ouers) toegepas word, word **geërf** na al die hulpbronne binne die subskripsie

### Hulpbron Groepe

[Van die dokumentasie:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) '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.

<figure><img src="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>

### 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 stoor. 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 teken-in (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 erflike protokolle soos LDAP, Kerberos, en NTLM, wat organisasies in staat stel om ouer 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 erflike 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 huur aan
- Dui Vertoonnaam aan
- Dui wagwoord aan
- Dui eienskappe aan (voornaam, posbeskrywing, kontak inligting…)
- Standaard gebruiker tipe is “**lid**”
- **Buitelandige 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](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) maar onder andere aksies sal 'n lid in staat wees om:

- Alle gebruikers, Groepe, Toepassings, Toestelle, Rolle, Subskripsies, en hul publieke eienskappe te lees
- Gaste uit te nooi (_kan afgeskakel word_)
- Sekuriteitsgroepe te skep
- Nie-verborgen Groep lidmaatskappe te lees
- Gaste by Besit groepe te voeg
- Nuwe toepassing te skep (_kan afgeskakel word_)
- Tot 50 toestelle aan Azure toe te voeg (_kan afgeskakel word_)

> [!NOTE]
> Onthou dat om Azure hulpbronne te enumerate, die gebruiker 'n eksplisiete toekenning van die toestemming benodig.

### Gebruikers Standaard Konfigureerbare Toestemmings

- **Lede (**[**dokumentasie**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
- Registreer Toepassings: Standaard **Ja**
- Beperk nie-admin gebruikers 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 nie (slegs web)
- Laat gebruikers toe om werk of skool rekening met LinkedIn te verbind: Standaard **Ja**
- Toon hou gebruiker ingelog: 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** opsies:
- **Gaste gebruikers het dieselfde toegang as lede**.
- **Gaste gebruikers het beperkte toegang tot eienskappe en lidmaatskappe van gids objekte (standaard)**. Dit beperk gaste toegang tot slegs hul eie gebruikersprofiel per 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** opsies:
- **Enige iemand in die organisasie kan gaste gebruikers uitnooi insluitend gaste en nie-admins (mees inklusief) - Standaard**
- **Lede gebruikers en gebruikers wat aan spesifieke admin rolle toegeken is kan gaste gebruikers uitnooi insluitend gaste met lid toestemmings**
- **Slegs gebruikers wat aan spesifieke admin rolle toegeken is kan gaste gebruikers uitnooi**
- **Niemand in die organisasie kan gaste gebruikers uitnooi insluitend admins (mees beperkend)**
- **Buitelandige gebruiker verlaat**: Standaard **Waar**
- Laat buitelandige gebruikers toe om die organisasie te verlaat

> [!TIP]
> Alhoewel dit per standaard beperk is, kan gebruikers (lede en gaste) met toegekenne toestemmings die vorige aksies uitvoer.

### **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 huur.

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 eienskappe verander.

### **Diens Prinsipale**

'n **Diens Prinsipaal** is 'n **identiteit** geskep vir **gebruik** met **toepassings**, gehoste dienste, en geoutomatiseerde 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 kan verkry** en op watter vlak. Om veiligheidsredes, word dit altyd aanbeveel om **diens prinsipale met geoutomatiseerde 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 (per standaard), **stoor die gegenereerde wagwoord** aangesien jy dit nie weer sal 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).
1. As 'n **sertifikaat** of **geheim** gegenereer word, is dit moontlik vir 'n persoon om **as die diens prinsipaal** met CLI gereedskap aan te meld deur die **toepassing ID**, die **geheim** of **sertifikaat** en die **huur** (domein of ID) te ken.
4. **API Toestemmings:** Spesifiseer watter hulpbronne of API's die app kan toegang.
5. **Autentisering Instellings:** Definieer die app se ondersteunde autentisering vloei (bv., OAuth2, OpenID Connect).
6. **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 huur geïnstalleer word.
1. 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, interne apps, en apps wat slegs geselekteerde toestemmings vra (Aanbeveel)**
- Alle gebruikers kan toestemming gee vir apps wat slegs toestemmings vra wat as "lae impak" geklassifiseer is, apps van geverifieerde uitgewers en apps geregistreer in die huur.
- **Standaard** lae impak toestemmings (alhoewel jy moet aanvaar om hulle 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
- profile - sien gebruiker se basiese profiel
- email - 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 om te **verbinde** 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 huur 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 geskep word in die EntraID 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 nie** (soos wagwoorde of sertifikate) om toegang te verkry as die diens prinsipaal wat aan dit geheg is.

### Enterprise Toepassings

Dit is net 'n **tabel 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 jou toe om **toestemmings van 'n rol oor 'n spesifieke gedeelte van 'n organisasie** te gee.

Voorbeeld:

- Scenario: 'n Maatskappy wil regionale IT admins 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 van 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 admins kan gebruikersrekeninge binne hul streek bestuur sonder om ander streke te beïnvloed.

### Entra ID Rolle & Toestemmings

- 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](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
- Rolle gemerk as **`PRIVILEGED`** deur EntraID moet met omsigtigheid toegeken word omdat Microsoft verduidelik [in die dokumentasie](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): Bevoorregte rol toekennings kan lei tot verhoogde voorregte as dit nie op 'n veilige en bedoelde manier gebruik word nie.
- Die mees bevoorregte rol is **Globale Administrateur**
- Rolle groepeer **fynere toestemmings** en hulle kan in hul beskrywings gevind word.
- Dit is moontlik om **aangepaste rolle** te skep met die gewenste toestemmings. Alhoewel om een of ander rede nie al die fynere toestemmings beskikbaar is vir admins om aangepaste rolle te skep nie.
- Rolle in Entra ID is heeltemal **onafhanklik** van rolle in Azure. Die enigste verband is dat prinsipale met die rol **Globale Administrateur** in Entra ID kan verhoog na die **Gebruiker Toegang Administrateur** rol in Azure.
- Dit is **nie moontlik om wildcard** in Entra ID rolle te gebruik nie.

## Azure Rolle & Toestemmings

- **Rolle** is **toegeken** aan **prinsipale** op 'n **skaal**: `principal -[HAS ROLE]->(scope)`
- **Rolle** toegeken aan **groepe** 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 en op **alle hulpbronne** binne die hulpbron groep hê.

### Ingeboude rolle

[Van die dokumentasie: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure rol-gebaseerde toegangbeheer (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) het verskeie Azure **ingeboude 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 ingeboude rolle nie aan die spesifieke behoeftes van jou organisasie voldoen nie, kan jy jou eie [**Azure aangepaste rolle**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) skep.

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

| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Bied toestemming aan om rugsteun kluis te laat disk rugsteun uitvoer.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
| [Virtuele Masjien Gebruiker Aanmelding](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Sien Virtuele Masjiene in die portaal en meld aan as 'n gewone gebruiker. | fb879df8-f326-4884-b1cf-06f3ad86be52 |

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

- Vind hier 'n lys met [**alle Azure ingeboude rolle**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
- Vind hier 'n lys met [**alle Entra ID ingeboude rolle**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).

### Aangepaste Rolle

- Dit is ook moontlik om [**aangepaste rolle**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) 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 aangepaste 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` verwys na toestemmings vir bestuursoperasies op hulpbronne, soos om hulpbron definisies en instellings te skep, op te dateer, of te verwyder.
- `dataActions` is toestemmings vir data operasies binne die hulpbron, wat jou toelaat om die werklike data wat in die hulpbron bevat is, te lees, te skryf, of te verwyder.
- `notActions` en `notDataActions` word gebruik om spesifieke toestemmings van die rol uit te sluit. Dit ontken egter **nie hulle nie**, as 'n ander rol hulle toeken, sal die prinsipaal hulle hê.
- `assignableScopes` is 'n reeks van skale waar die rol toegeken kan word (soos bestuursgroepe, subskripsies, of hulpbron groepe).

Voorbeeld van toestemmings JSON vir 'n aangepaste rol:
```json
{
"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": []
}
]
}
}
```
### Toestemmingsorde

- Ten einde vir 'n **hoofpersoon om toegang tot 'n hulpbron te hê** moet 'n eksplisiete rol aan hom toegeken word (op enige manier) **wat hom daardie toestemming gee**.
- 'n Eksplisiete **weieringstoewysing het voorrang** bo die rol wat die toestemming gee.

<figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>

### 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 Gebruikerstoegang Administrateur Azure rol in die Wortelbestuursgroep**. 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](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)

<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>

### Toewysingsvoorwaardes & MFA

Volgens **[die dokumentasie](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**: Tans kan voorwaardes by ingeboude of pasgemaakte roltoewysings gevoeg word wat **blob stoor data aksies of wagwoord stoor data aksies** het.

### Weieringstoewysings

Net soos roltoewysings, **weieringstoewysings** word gebruik om **toegang tot Azure-hulpbronne te beheer**. egter, **weieringstoewysings** word gebruik om **toegang tot 'n hulpbron eksplisiet te weier**, selfs al is 'n gebruiker toegang gegee deur 'n roltoewysing. **Weieringstoewysings** het voorrang bo **roltoewysings**, wat beteken dat as 'n gebruiker toegang gegee word deur 'n roltoewysing maar ook eksplisiet toegang geweier word deur 'n weieringstoewysing, die weieringstoewysing voorrang sal hê.

Net soos roltoewysings, **weieringstoewysings** word toegepas oor 'n sekere omvang wat die betrokke hoofpersone en die toestemmings wat geweier word aandui. Boonop, in die geval van weieringstoewysings, is dit moontlik om die weiering te **verhoed dat dit geërf word** deur kindhulpbronne.

### 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 verhoed of verseker dat alle hulpbronne spesifieke etikette het vir opsporing.

Azure Beleide is **proaktief**: hulle kan nie-nakomende hulpbronne verhoed 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," "Ou dit," 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 verhoed om koste te beheer.
4. **Afgedwonge Etikettering Beleide**: Etikette is sleutel-waarde pare wat met Azure-hulpbronne geassosieer word en wat vir hulpbronbestuur gebruik word. Beleide kan afdwing dat sekere etikette teenwoordig moet wees, of spesifieke waardes moet hê, vir alle hulpbronne. Dit is nuttig vir koste-opsporing, 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 wortelbestuursgroep** of in ander bestuursgroepe gebruik.

Azure beleid json voorbeeld:
```json
{
"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"
}
```
### Toestemmingsoorname

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 ingeslote **hulpbronne** van die entiteit waar hulle toegeken is.

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

<figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>

### Azure RBAC vs ABAC

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

Azure **ABAC** (attribuut-gebaseerde toegangbeheer) bou voort 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 kan byvoeg tot jou roltoekenning** 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** **met behulp van voorwaardes** nie.

## Verwysings

- [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](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://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://abouttmc.com/glossary/azure-subscription/)
- [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://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](https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration)

{{#include ../../../banners/hacktricks-training.md}}
