Az - Basic Information
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
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.
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
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.
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 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 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 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.
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”
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)
Onthou dat om Azure hulpbronne te evalueer, die gebruiker 'n eksplisiete toekenning van die toestemming benodig.
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
Alhoewel dit standaard beperk is, kan gebruikers (lede en gaste) met toegekennde toestemmings die vorige aksies uitvoer.
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.
'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.
'n App Registrasie is 'n konfigurasie wat 'n toepassing toelaat om met Entra ID te integreer en aksies uit te voer.
Toepassing ID (Kliënt ID): 'n Unieke identifiseerder vir jou app in Azure AD.
Herlei URIs: URL's waar Azure AD autentisering antwoorde stuur.
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).
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.
API Toestemmings: Spesifiseer watter hulpbronne of API's die app toegang kan verkry.
Autentisering Instellings: Definieer die app se ondersteunde autentisering vloei (bv., OAuth2, OpenID Connect).
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.
Die diens prinsipaal sal al die gevraagde toestemmings wat dit geconfigureer is, ontvang.
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 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.
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 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.
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
Die mees bevoorregte rol is Globale Administrateur
In die Beskrywing van die rol is dit moontlik om sy fynere toestemmings te sien
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.
Eienaar
Volledige toegang tot alle hulpbronne
Kan toegang vir ander gebruikers bestuur
Alle hulpbron tipes
Bydraer
Volledige toegang tot alle hulpbronne
Kan nie toegang bestuur nie
Alle hulpbron tipes
Leser
• Sien alle hulpbronne
Alle hulpbron tipes
Gebruiker Toegang Administrateur
Sien alle hulpbronne
Kan toegang vir ander gebruikers bestuur
Alle hulpbron tipes
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:
Bied toestemming aan om rugsteun kluise te gebruik om disk rugsteun te doen.
3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
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 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.
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:
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 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 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.
Beleid Definisie: 'n Reël, geskryf in JSON, wat spesifiseer wat toegelaat of vereis word.
Beleid Toewysing: Die toepassing van 'n beleid op 'n spesifieke omvang (bv. subskripsie, hulpbron groep).
Inisiatiewe: 'n Versameling van beleide wat saamgegroepeer is vir breër afdwinging.
Effek: Spesifiseer wat gebeur wanneer die beleid geaktiveer word (bv. "Weier," "Oudit," of "Voeg by").
Sommige voorbeelde:
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.
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.
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.
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.
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.
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:
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.
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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
