Az - Osnovne informacije

Reading time: 20 minutes

Hijerarhija organizacije

Grupa za upravljanje

• Može sadržati druge grupe za upravljanje ili pretplate.
• Ovo omogućava primenu kontrola upravljanja kao što su RBAC i Azure Policy jednom na nivou grupe za upravljanje i da se one naslede od svih pretplata u grupi.
• 10.000 grupa za upravljanje može biti podržano u jednoj direktoriji.
• Drvo grupa za upravljanje može podržati do šest nivoa dubine. Ova granica ne uključuje nivo korena ili nivo pretplate.
• Svaka grupa za upravljanje i pretplata mogu podržavati samo jednog roditelja.
• Čak i ako se može kreirati nekoliko grupa za upravljanje, postoji samo 1 grupa za upravljanje korenom.
• Grupa za upravljanje korenom sadrži sve druge grupe za upravljanje i pretplate i ne može se premestiti ili obrisati.
• Sve pretplate unutar jedne grupe za upravljanje moraju verovati istom Entra ID tenant-u.

Azure pretplate

• To je još jedan logički kontejner u kojem se mogu pokretati resursi (VM-ovi, DB-ovi…) i za koji će se naplaćivati.
• Njegov roditelj je uvek grupa za upravljanje (i može biti grupa za upravljanje korenom) jer pretplate ne mogu sadržati druge pretplate.
• Veruje samo jednoj Entra ID direktoriji
• Dozvole primenjene na nivou pretplate (ili bilo kojem od njenih roditelja) se nasleđuju svim resursima unutar pretplate

Grupe resursa

Iz dokumenata: Grupa resursa je kontejner koji sadrži povezane resurse za Azure rešenje. Grupa resursa može uključivati sve resurse za rešenje, ili samo one resurse koje želite da upravljate kao grupu. Generalno, dodajte resurse koji dele isti životni ciklus u istu grupu resursa kako biste ih lako implementirali, ažurirali i obrisali kao grupu.

Svi resursi moraju biti unutar grupe resursa i mogu pripadati samo jednoj grupi, a ako se grupa resursa obriše, svi resursi unutar nje se takođe brišu.

Azure Resource IDs

Svaki resurs u Azure-u ima Azure Resource ID koji ga identifikuje.

Format Azure Resource ID-a je sledeći:

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

Za virtuelnu mašinu nazvanu myVM u grupi resursa myResourceGroup pod ID-jem pretplate 12345678-1234-1234-1234-123456789012, Azure Resource ID izgleda ovako:

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

Azure vs Entra ID vs Azure AD Domain Services

Azure

Azure je Microsoftova sveobuhvatna platforma za cloud računarstvo, koja nudi širok spektar usluga, uključujući virtuelne mašine, baze podataka, veštačku inteligenciju i skladištenje. Ona služi kao osnova za hostovanje i upravljanje aplikacijama, izgradnju skalabilnih infrastruktura i pokretanje modernih radnih opterećenja u oblaku. Azure pruža alate za programere i IT profesionalce da kreiraju, implementiraju i upravljaju aplikacijama i uslugama bez problema, zadovoljavajući razne potrebe od startapa do velikih preduzeća.

Entra ID (ranije Azure Active Directory)

Entra ID je cloud-bazirana usluga upravljanja identitetom i pristupom dizajnirana da se bavi autentifikacijom, autorizacijom i kontrolom pristupa korisnika. Ona omogućava siguran pristup Microsoftovim uslugama kao što su Office 365, Azure i mnoge aplikacije trećih strana. Sa funkcijama kao što su jedinstveno prijavljivanje (SSO), višefaktorska autentifikacija (MFA) i politike uslovnog pristupa, između ostalog.

Entra Domain Services (ranije Azure AD DS)

Entra Domain Services proširuje mogućnosti Entra ID nudeći upravljane usluge domena kompatibilne sa tradicionalnim Windows Active Directory okruženjima. Podržava nasleđene protokole kao što su LDAP, Kerberos i NTLM, omogućavajući organizacijama da migriraju ili pokreću starije aplikacije u oblaku bez implementacije lokalnih kontrolera domena. Ova usluga takođe podržava grupne politike za centralizovano upravljanje, što je čini pogodnom za scenarije u kojima nasleđena ili AD-bazirana radna opterećenja treba da koegzistiraju sa modernim cloud okruženjima.

Entra ID Principali

Korisnici

• Novi korisnici
• Naznačite ime i domen e-pošte iz odabranog tenant-a
• Naznačite prikazano ime
• Naznačite lozinku
• Naznačite svojstva (ime, radno mesto, kontakt informacije…)
• Podrazumevani tip korisnika je “član”
• Spoljni korisnici
• Naznačite e-poštu za poziv i prikazano ime (može biti e-pošta koja nije od Microsoft-a)
• Naznačite svojstva
• Podrazumevani tip korisnika je “Gost”

Podrazumevane dozvole članova i gostiju

Možete ih proveriti na https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions ali među ostalim radnjama član će moći da:

• Čita sve korisnike, grupe, aplikacije, uređaje, uloge, pretplate i njihove javne osobine
• Poziva goste (može se isključiti)
• Kreira sigurnosne grupe
• Čita ne-skrivene članstva grupa
• Dodaje goste u vlasničke grupe
• Kreira nove aplikacije (može se isključiti)
• Dodaje do 50 uređaja u Azure (može se isključiti)

Podrazumevane konfigurabilne dozvole korisnika

• Članovi (docs)
• Registracija aplikacija: Podrazumevano Da
• Ograničavanje ne-administrativnih korisnika od kreiranja tenant-a: Podrazumevano Ne
• Kreiranje sigurnosnih grupa: Podrazumevano Da
• Ograničavanje pristupa Microsoft Entra administrativnom portalu: Podrazumevano Ne
• Ovo ne ograničava API pristup portalu (samo web)
• Dozvolite korisnicima da povežu radni ili školski nalog sa LinkedIn-om: Podrazumevano Da
• Prikazivanje zadržavanja korisnika prijavljenim: Podrazumevano Da
• Ograničavanje korisnika od oporavka BitLocker ključeva za njihove vlasničke uređaje: Podrazumevano Ne (proverite u podešavanjima uređaja)
• Čitanje drugih korisnika: Podrazumevano Da (putem Microsoft Graph)
• Gosti
• Ograničenja pristupa gostujućih korisnika opcije:
• Gosti imaju isti pristup kao članovi.
• Gosti imaju ograničen pristup svojstvima i članstvima objekata direktorijuma (podrazumevano). Ovo ograničava pristup gostiju samo na njihov profil korisnika po default-u. Pristup informacijama o drugim korisnicima i grupama više nije dozvoljen.
• Pristup gostujućih korisnika je ograničen na svojstva i članstva njihovih vlastitih objekata direktorijuma je najrestriktivniji.
• Gosti mogu pozivati opcije:
• Svako u organizaciji može pozvati gostujuće korisnike uključujući goste i ne-admine (najinkluzivnije) - Podrazumevano
• Članovi korisnici i korisnici dodeljeni specifičnim administrativnim ulogama mogu pozvati gostujuće korisnike uključujući goste sa članovskim dozvolama
• Samo korisnici dodeljeni specifičnim administrativnim ulogama mogu pozvati gostujuće korisnike
• Niko u organizaciji ne može pozvati gostujuće korisnike uključujući administratore (najrestriktivnije)
• Spoljni korisnici mogu napustiti: Podrazumevano Tačno
• Dozvolite spoljnim korisnicima da napuste organizaciju

Grupe

Postoje 2 tipa grupa:

• Sigurnosne: Ova vrsta grupe se koristi za davanje članovima pristupa aplikacijama, resursima i dodeljivanje licenci. Korisnici, uređaji, servisni principi i druge grupe mogu biti članovi.
• Microsoft 365: Ova vrsta grupe se koristi za saradnju, dajući članovima pristup zajedničkoj pošti, kalendaru, datotekama, SharePoint lokaciji, itd. Članovi grupe mogu biti samo korisnici.
• Ovo će imati adresu e-pošte sa domenom EntraID tenant-a.

Postoje 2 tipa članstva:

• Dodeljeno: Omogućava ručno dodavanje specifičnih članova u grupu.
• Dinamičko članstvo: Automatski upravlja članstvom koristeći pravila, ažurirajući uključivanje grupe kada se atributi članova promene.

Servisni principi

Servisni princip je identitet kreiran za upotrebu sa aplikacijama, hostovanim uslugama i automatizovanim alatima za pristup Azure resursima. Ovaj pristup je ograničen ulogama dodeljenim servisnom principu, dajući vam kontrolu nad koji resursi mogu biti pristupljeni i na kojem nivou. Iz bezbednosnih razloga, uvek se preporučuje da koristite servisne principe sa automatizovanim alatima umesto da im dozvolite prijavu sa korisničkim identitetom.

Moguće je direktno se prijaviti kao servisni princip generišući mu tajnu (lozinku), sertifikat, ili dodeljujući federisani pristup platformama trećih strana (npr. Github Actions) preko njega.

• Ako izaberete lozinku za autentifikaciju (podrazumevano), sačuvajte generisanu lozinku jer je nećete moći ponovo pristupiti.
• Ako izaberete autentifikaciju sertifikatom, uverite se da će aplikacija imati pristup privatnom ključu.

Registracije aplikacija

Registracija aplikacije je konfiguracija koja omogućava aplikaciji da se integriše sa Entra ID i da izvršava radnje.

Ključne komponente:

1. ID aplikacije (Client ID): Jedinstveni identifikator za vašu aplikaciju u Azure AD.
2. Redirect URIs: URL-ovi na koje Azure AD šalje odgovore na autentifikaciju.
3. Sertifikati, tajne i federisani kredencijali: Moguće je generisati tajnu ili sertifikat za prijavu kao servisni princip aplikacije, ili dodeliti federisani pristup (npr. Github Actions).
4. Ako je sertifikat ili tajna generisana, moguće je da osoba prijavi kao servisni princip koristeći CLI alate znajući ID aplikacije, tajnu ili sertifikat i tenant (domen ili ID).
5. API dozvole: Specifikuje koje resurse ili API-je aplikacija može pristupiti.
6. Podešavanja autentifikacije: Definiše podržane tokove autentifikacije aplikacije (npr., OAuth2, OpenID Connect).
7. Servisni princip: Servisni princip se kreira kada se aplikacija kreira (ako se to uradi iz web konzole) ili kada se instalira u novom tenant-u.
8. Servisni princip će dobiti sve tražene dozvole sa kojima je konfigurisan.

Podrazumevane dozvole pristanka

Korisnički pristanak za aplikacije

• Ne dozvoliti korisnički pristanak
• Administrator će biti potreban za sve aplikacije.
• Dozvoliti korisnički pristanak za aplikacije od verifikovanih izdavača, interne aplikacije i aplikacije koje traže samo odabrane dozvole (preporučeno)
• Svi korisnici mogu pristati na aplikacije koje traže samo dozvole klasifikovane kao "niskog uticaja", aplikacije od verifikovanih izdavača i aplikacije registrovane u tenant-u.
• Podrazumevane dozvole niskog uticaja (iako ih treba prihvatiti da bi se dodale kao niske):
• User.Read - prijava i čitanje korisničkog profila
• offline_access - održavanje pristupa podacima kojima su korisnici dali pristup
• openid - prijava korisnika
• profile - pregled osnovnog profila korisnika
• email - pregled adrese e-pošte korisnika
• Dozvoliti korisnički pristanak za aplikacije (podrazumevano)
• Svi korisnici mogu pristati na bilo koju aplikaciju da pristupi podacima organizacije.

Zahtevi za pristanak administratora: Podrazumevano Ne

• Korisnici mogu zatražiti pristanak administratora za aplikacije na koje ne mogu pristati
• Ako je Da: Moguće je naznačiti korisnike, grupe i uloge koje mogu pristati na zahteve
• Takođe konfigurišite da li će korisnici primati obaveštenja putem e-pošte i podsetnike o isteku

Upravljani identitet (metapodaci)

Upravljani identiteti u Azure Active Directory nude rešenje za automatsko upravljanje identitetom aplikacija. Ovi identiteti se koriste od strane aplikacija u svrhu povezivanja sa resursima kompatibilnim sa autentifikacijom Azure Active Directory (Azure AD). Ovo omogućava uklanjanje potrebe za hardkodiranjem cloud kredencijala u kodu jer će aplikacija moći da kontaktira metapodatkovnu uslugu kako bi dobila važeći token za izvršavanje radnji kao naznačeni upravljani identitet u Azure-u.

Postoje dva tipa upravljanih identiteta:

• Sistemom dodeljeni. Neke Azure usluge omogućavaju da omogućite upravljani identitet direktno na instanci usluge. Kada omogućite sistemom dodeljeni upravljeni identitet, servisni princip se kreira u Entra ID tenant-u kojem veruje pretplata u kojoj se resurs nalazi. Kada se resurs obriše, Azure automatski briše identitet za vas.
• Korisnikom dodeljeni. Takođe je moguće da korisnici generišu upravljane identitete. Ovi se kreiraju unutar grupe resursa unutar pretplate i servisni princip će biti kreiran u EntraID kojem veruje pretplata. Zatim, možete dodeliti upravljeni identitet jednoj ili više instanci Azure usluge (više resursa). Za korisnikom dodeljene upravljane identitete, identitet se upravlja odvojeno od resursa koji ga koriste.

Upravljani identiteti ne generišu večne kredencijale (kao što su lozinke ili sertifikati) za pristup kao servisni princip koji je povezan sa njima.

Preduzeća aplikacije

To je samo tabela u Azure-u za filtriranje servisnih principa i proveru aplikacija koje su dodeljene.

To nije još jedan tip "aplikacije", ne postoji nijedan objekat u Azure-u koji je "Preduzeće aplikacija", to je samo apstrakcija za proveru servisnih principa, registracija aplikacija i upravljanih identiteta.

Administrativne jedinice

Administrativne jedinice omogućavaju davanje dozvola iz uloge nad specifičnim delom organizacije.

Primer:

• Scenario: Kompanija želi da regionalni IT administratori upravljaju samo korisnicima u svojoj regiji.
• Implementacija:
• Kreirajte administrativne jedinice za svaku regiju (npr., "Severna Amerika AU", "Evropa AU").
• Popunite AU sa korisnicima iz njihovih odgovarajućih regija.
• AU mogu sadržati korisnike, grupe ili uređaje
• AU podržavaju dinamička članstva
• AU ne mogu sadržati AU
• Dodelite administrativne uloge:
• Dodelite ulogu "Administrator korisnika" regionalnom IT osoblju, ograničenu na AU njihove regije.
• Ishod: Regionalni IT administratori mogu upravljati korisničkim nalozima unutar svoje regije bez uticaja na druge regije.

Entra ID Uloge i Dozvole

• Da bi upravljali Entra ID, postoje neke ugrađene uloge koje se mogu dodeliti Entra ID principima za upravljanje Entra ID
• Proverite uloge na https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
• Uloge označene kao PRIVILEGOVANE od strane EntraID treba dodeliti sa oprezom jer, kako Microsoft objašnjava u dokumentima: Dodeljivanje privilegovanih uloga može dovesti do povećanja privilegija ako se ne koristi na siguran i nameran način.
• Najprivilegovanija uloga je Globalni administrator
• Uloge grupišu granularne dozvole i mogu se naći u njihovim opisima.
• Moguće je kreirati prilagođene uloge sa željenim dozvolama. Iako iz nekog razloga nisu sve granularne dozvole dostupne za administratore da kreiraju prilagođene uloge.
• Uloge u Entra ID su potpuno nezavisne od uloga u Azure-u. Jedina veza je da principi sa ulogom Globalni administrator u Entra ID mogu povećati na ulogu Administrator pristupa korisnicima u Azure-u.
• Nije moguće koristiti džoker znakove u Entra ID ulogama.

Azure Uloge i Dozvole

• Uloge se dodeljuju principima na opsegu: princip -[IMA ULOGU]->(opseg)
• Uloge dodeljene grupama se nasleđuju od svih članova grupe.
• U zavisnosti od opsega na koji je uloga dodeljena, uloga se može naslediti na druge resurse unutar kontejnera opsega. Na primer, ako korisnik A ima ulogu na pretplati, on će imati tu ulogu na svim grupama resursa unutar pretplate i na svim resursima unutar grupe resursa.

Ugrađene uloge

Iz dokumenata: Azure role-based access control (Azure RBAC) ima nekoliko Azure ugrađenih uloga koje možete dodeliti korisnicima, grupama, servisnim principima i upravljanim identitetima. Dodeljivanje uloga je način na koji kontrolišete pristup Azure resursima. Ako ugrađene uloge ne zadovoljavaju specifične potrebe vaše organizacije, možete kreirati svoje Azure prilagođene uloge.

Ugrađene uloge se primenjuju samo na resurse za koje su namenjene, na primer, proverite ova 2 primera ugrađenih uloga nad Compute resursima:

Ove uloge se takođe mogu dodeliti nad logičkim kontejnerima (kao što su grupe za upravljanje, pretplate i grupe resursa) i principi koji su pogođeni će ih imati nad resursima unutar tih kontejnera.

• Pronađite ovde listu sa svim Azure ugrađenim ulogama.
• Pronađite ovde listu sa svim Entra ID ugrađenim ulogama.

Prilagođene uloge

• Takođe je moguće kreirati prilagođene uloge
• One se kreiraju unutar opsega, iako uloga može biti u više opsega (grupe za upravljanje, pretplate i grupe resursa)
• Moguće je konfigurisati sve granularne dozvole koje će prilagođena uloga imati
• Moguće je isključiti dozvole
• Princip sa isključenom dozvolom neće moći da je koristi čak i ako se dozvola dodeljuje negde drugde
• Moguće je koristiti džoker znakove
• Korišćeni format je JSON
• actions se odnosi na dozvole za upravljačke operacije nad resursima, kao što su kreiranje, ažuriranje ili brisanje definicija i podešavanja resursa.
• dataActions su dozvole za operacije sa podacima unutar resursa, omogućavajući vam da čitate, pišete ili brišete stvarne podatke sadržane u resursu.
• notActions i notDataActions se koriste za isključivanje specifičnih dozvola iz uloge. Međutim, ne negiraju ih, ako druga uloga dodeljuje te dozvole, princip će ih imati.
• assignableScopes je niz opsega u kojima se uloga može dodeliti (kao što su grupe za upravljanje, pretplate ili grupe resursa).

Primer dozvola JSON za prilagođenu ulogu:

{
"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": []
}
]
}
}

Permissions order

• Da bi principal imao pristup resursu, potrebno je da mu bude dodeljena eksplicitna uloga (na bilo koji način) koja mu daje tu dozvolu.
• Eksplicitna dodela odbijanja ima prioritet nad ulogom koja dodeljuje dozvolu.

Global Administrator

Global Administrator je uloga iz Entra ID koja dodeljuje potpunu kontrolu nad Entra ID tenant-om. Međutim, po defaultu ne dodeljuje nikakve dozvole nad Azure resursima.

Korisnici sa ulogom Global Administrator imaju mogućnost da 'povećaju' na User Access Administrator Azure ulogu u Root Management Group. Tako Global Administratori mogu upravljati pristupom u svim Azure pretplatama i upravljačkim grupama.
Ovo povećanje može se izvršiti na kraju stranice: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Assignments Conditions & MFA

Prema dokumentaciji: Trenutno, uslovi se mogu dodati ugrađenim ili prilagođenim dodelama uloga koje imaju blob storage data actions ili queue storage data actions.

Deny Assignments

Baš kao i dodele uloga, dodele odbijanja se koriste za kontrolu pristupa Azure resursima. Međutim, dodele odbijanja se koriste za eksplicitno odbijanje pristupa resursu, čak i ako je korisniku dodeljen pristup putem dodele uloge. Dodele odbijanja imaju prioritet nad dodelama uloga, što znači da ako je korisniku dodeljen pristup putem dodele uloge, ali mu je takođe eksplicitno odbijen pristup putem dodele odbijanja, dodela odbijanja će imati prioritet.

Baš kao i dodele uloga, dodele odbijanja se primenjuju na određeni opseg koji označava pogođene principe i dozvole koje se odbijaju. Štaviše, u slučaju dodela odbijanja, moguće je sprečiti da se odbijanje nasledi od resursa dece.

Azure Policies

Azure Policies su pravila koja pomažu organizacijama da osiguraju da njihovi resursi ispunjavaju specifične standarde i zahteve usklađenosti. Omogućavaju vam da sprovodite ili proveravate podešavanja na resursima u Azure-u. Na primer, možete sprečiti kreiranje virtuelnih mašina u neovlašćenoj regiji ili osigurati da svi resursi imaju specifične oznake za praćenje.

Azure Policies su proaktivne: mogu sprečiti kreiranje ili promenu neusklađenih resursa. Takođe su reaktivne, omogućavajući vam da pronađete i ispravite postojeće neusklađene resurse.

Key Concepts

1. Policy Definition: Pravilo, napisano u JSON-u, koje specificira šta je dozvoljeno ili zahtevano.
2. Policy Assignment: Primena politike na određeni opseg (npr. pretplata, grupa resursa).
3. Initiatives: Skup politika grupisanih zajedno za širu primenu.
4. Effect: Specificira šta se dešava kada se politika aktivira (npr. "Deny," "Audit," ili "Append").

Neki primeri:

1. Osiguranje usklađenosti sa specifičnim Azure regionima: Ova politika osigurava da se svi resursi postavljaju u specifične Azure regione. Na primer, kompanija može želeti da osigura da su svi njeni podaci pohranjeni u Evropi radi usklađenosti sa GDPR-om.
2. Sprovođenje standarda imenovanja: Politike mogu sprovoditi konvencije imenovanja za Azure resurse. Ovo pomaže u organizaciji i lakom identifikovanju resursa na osnovu njihovih imena, što je korisno u velikim okruženjima.
3. Ograničavanje određenih tipova resursa: Ova politika može ograničiti kreiranje određenih tipova resursa. Na primer, politika može biti postavljena da spreči kreiranje skupih tipova resursa, poput određenih veličina VM-a, kako bi se kontrolisali troškovi.
4. Sprovođenje politika označavanja: Oznake su parovi ključ-vrednost povezani sa Azure resursima koji se koriste za upravljanje resursima. Politike mogu sprovoditi da određene oznake moraju biti prisutne, ili imati specifične vrednosti, za sve resurse. Ovo je korisno za praćenje troškova, vlasništvo ili kategorizaciju resursa.
5. Ograničavanje javnog pristupa resursima: Politike mogu sprovoditi da određeni resursi, poput skladišnih naloga ili baza podataka, nemaju javne krajnje tačke, osiguravajući da su dostupni samo unutar mreže organizacije.
6. Automatsko primenjivanje bezbednosnih podešavanja: Politike se mogu koristiti za automatsko primenjivanje bezbednosnih podešavanja na resurse, kao što je primena specifične grupe bezbednosti mreže na sve VM-ove ili osiguranje da svi skladišni nalozi koriste enkripciju.

Napomena da se Azure Policies mogu prikačiti na bilo koji nivo Azure hijerarhije, ali se najčešće koriste u root management group ili u drugim upravljačkim grupama.

Azure policy json example:

{
"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"
}

Nasleđivanje dozvola

U Azure dozvole se mogu dodeliti bilo kojem delu hijerarhije. To uključuje upravljačke grupe, pretplate, grupe resursa i pojedinačne resurse. Dozvole se nasleđuju od sadržanih resursa entiteta gde su dodeljene.

Ova hijerarhijska struktura omogućava efikasno i skalabilno upravljanje dozvolama pristupa.

Azure RBAC vs ABAC

RBAC (kontrola pristupa zasnovana na rolama) je ono što smo već videli u prethodnim sekcijama: Dodeljivanje uloge principalu kako bi mu se omogućio pristup resursu.
Međutim, u nekim slučajevima možda ćete želeti da obezbedite fino podešeno upravljanje pristupom ili pojednostavite upravljanje stotinama dodela uloga.

Azure ABAC (kontrola pristupa zasnovana na atributima) se oslanja na Azure RBAC dodavanjem uslova dodele uloga zasnovanih na atributima u kontekstu specifičnih akcija. Uslov dodele uloge je dodatna provera koju možete opcionalno dodati svojoj dodeli uloge kako biste obezbedili fino podešenu kontrolu pristupa. Uslov filtrira dozvole dodeljene kao deo definicije uloge i dodele uloge. Na primer, možete dodati uslov koji zahteva da objekat ima specifičnu oznaku da bi se pročitao objekat.
Ne možete eksplicitno odbiti pristup specifičnim resursima korišćenjem uslova.

Reference

• 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