Az - Basic Information
Organisasie Hiërargie
Bestuursgroepe
As jou organisasie baie Azure intekeninge het, mag jy 'n manier nodig hê om effektief toegang, beleid en nakoming vir daardie intekeninge te bestuur. Bestuursgroepe bied 'n regeringsskoop bo intekeninge.
Let daarop dat 10,000 bestuursgroepe in 'n enkele gids ondersteun kan word en 'n bestuursgroepboom kan tot ses vlakke diep ondersteun.
Van die dokumentasie: Elke gids kry 'n enkele topvlak bestuursgroep genaamd die wortel bestuursgroep. Die wortel bestuursgroep is ingebou in die hiërargie om alle bestuursgroepe en intekeninge na hom toe te vou. Hierdie wortel bestuursgroep maak dit moontlik vir globale beleide en Azure roltoewysings om op die gidssvlak toegepas te word. Die Azure AD Globale Administrateur moet hulself verhoog na die Gebruikerstoegangsadministrateur rol van hierdie wortelgroep aanvanklik. Na die verhoging van toegang kan die administrateur enige Azure rol toewys aan ander gidsgbruikers of groepe om die hiërargie te bestuur. As administrateur kan jy jou eie rekening as eienaar van die wortel bestuursgroep toewys.
Die wortel bestuursgroep kan nie geskuif of verwyder word nie, in teenstelling met ander bestuursgroepe.
Bestuursgroepe bied jou bestuur op ondernemingsvlak op skaal, maak nie saak watter tipe intekeninge jy mag hê nie. Nietemin moet alle intekeninge binne 'n enkele bestuursgroep die selfde Azure Active Directory (Azure AD) huurder vertrou.
Azure Intekeninge
In Azure dien 'n intekening as 'n logiese houer vir die doel van voorsiening van sake- of tegniese hulpbronne. Hierdie houer behou die besonderhede van hulpbronne soos virtuele masjiene (VM's), databasisse, onder andere. Met die skep van 'n Azure-hulpbron, soos 'n VM, word die intekening wat daarmee geassosieer is, gespesifiseer. Hierdie struktuur fasiliteer die delegasie van toegang deur gebruik te maak van rolgebaseerde toegangsbeheermeganismes.
Hulpbrongroepe
Van die dokumentasie: 'n Hulpbrongroep is 'n houer wat verwante hulpbronne vir 'n Azure-oplossing bevat. Die hulpbrongroep kan al die hulpbronne vir die oplossing insluit, of net daardie hulpbronne wat jy as 'n groep wil bestuur. Voeg gewoonlik hulpbronne wat die selfde lewensiklus deel by dieselfde hulpbrongroep sodat jy hulle maklik as 'n groep kan ontplooi, opdateer en verwyder.
Alle hulpbronne moet binne 'n hulpbrongroep wees en kan slegs aan 'n groep behoort en as 'n hulpbrongroep verwyder word, word al die hulpbronne daarin ook verwyder.
Administratiewe Eenhede
Van die dokumentasie: Administratiewe eenhede laat jou toe om jou organisasie in enige eenheid wat jy wil, te onderverdeel, en dan spesifieke administrateurs toe te wys wat slegs die lede van daardie eenheid kan bestuur. Byvoorbeeld, jy kan administratiewe eenhede gebruik om toestemmings aan administrateurs van elke skool by 'n groot universiteit te delegeer, sodat hulle slegs toegang kan beheer, gebruikers kan bestuur en beleide kan instel in die Skool van Ingenieurswese.
Slegs gebruikers, groepe en toestelle kan lede van 'n administratiewe eenheid wees.
Daarom sal 'n Administratiewe eenheid 'n paar lede bevat en ander prinsipale sal toestemmings oor daardie administratiewe eenheid toegewys word wat hulle kan gebruik om die lede van die administratiewe eenheid te bestuur.
Azure vs Azure AD vs Azure AD-domeindienste
Dit is belangrik om te let dat Azure AD 'n diens binne Azure is. Azure is Microsoft se wolkplatform terwyl Azure AD 'n ondernemings-identiteitsdiens in Azure is. Verder is Azure AD nie soos Windows Active Directory nie, dit is 'n identiteitsdiens wat op 'n heel ander manier werk. As jy 'n Domeinbeheerder in Azure wil hardloop vir jou Windows Active Directory-omgewing, moet jy Azure AD-domeindienste gebruik.
Prinsipale
Azure ondersteun verskillende tipes prinsipale:
Gebruiker: 'n gewone persoon met geloofsbriewe om toegang te verkry.
Groep: 'n groep van prinsipale wat saam bestuur word. Toestemmings wat aan groepe verleen word, word deur sy lede geërf.
Diensprinsipaall/Ondernemingstoepassings: Dit is 'n identiteit wat geskep is 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 diensprinsipaal toegewys is, wat jou beheer gee oor watter hulpbronne toeganklik is en op watter vlak. Vir veiligheidsredes word dit altyd aanbeveel om diensprinsipale met geoutomatiseerde gereedskap te gebruik eerder as om hulle toe te laat om met 'n gebruikersidentiteit in te teken.
By die skep van 'n diensprinsipaal kan jy kies tussen wagwoordverifikasie of sertifikaatverifikasie.
As jy wagwoord verif (standaard) kies, stoor die gegenereerde wagwoord aangesien jy dit nie weer kan ophaal nie.
As jy sertifikaatverifikasie kies, maak seker dat die toepassing toegang tot die privaatsleutel sal hê.
Bestuurde Identiteit (Metadatabewys): Bestuurde identiteite in Azure Active Directory bied 'n oplossing vir die outomatiese bestuur van die identiteit van toepassings. Hierdie identiteite word deur toepassings gebruik vir die doel van koppel aan hulpbronne wat verenigbaar is met Azure Active Directory (Azure AD)-verifikasie. Deur bestuurde identiteite te gebruik, kan toepassings Azure AD-tokens beveilig terwyl die behoefte om geloofsbriewe direk te hanteer, geëlimineer word. Daar is twee tipes bestuurde identiteite:
Stelseltoegewys. Sommige Azure-diens toelaat jou om 'n bestuurde identiteit direk op 'n diensinstansie te aktiveer. Wanneer jy 'n stelseltoegewys bestuurde identiteit aktiveer, word 'n identiteit in Azure AD geskep. Die identiteit is aan die lewensiklus van daardie diensbron gekoppel. Wanneer die hulpbron verwyder word, verwyder Azure outomaties die identiteit vir jou. Volgens die ontwerp kan slegs daardie Azure-hulpbron hierdie identiteit gebruik om tokens van Azure AD aan te vra.
Gebruikerstoegewys. Jy kan ook 'n bestuurde identiteit as 'n afsonderlike Azure-hulpbron skep. Jy kan 'n gebruikerstoegewys bestuurde identiteit skep en dit toewys aan een of meer instansies van 'n Azure-diens (veelvuldige hulpbronne). Vir gebruikerstoegewysde bestuurde identiteite word die identiteit afsonderlik van die hulpbronne wat dit gebruik, bestuur.
Rolle & Toestemmings
Rolle word toegewys aan principals op 'n omvang: principal -[HAS ROLE]->(scope)
Rolle wat aan groepe toegewys word, word geërf deur al die lede van die groep.
Afhanklik van die omvang waarop die rol toegewys is, kan die rol geërf word na ander hulpbronne binne die omvanghouer. Byvoorbeeld, as 'n gebruiker A 'n rol op die intekening het, sal hy daardie rol op al die hulpbrongroepe binne die intekening en op alle hulpbronne binne die hulpbrongroep hê.
Klassieke Rolle
Eienaar |
| Alle tipes hulpbronne |
Bydraer |
| Alle tipes hulpbronne |
Leser | • Sien alle hulpbronne | Alle tipes hulpbronne |
Gebruikerstoegangsadministrateur |
| Alle tipes hulpbronne |
Ingeboude rolle
Van die dokumente: Azure rolgebaseerde toegangsbeheer (Azure RBAC) het verskeie Azure ingeboude rolle wat jy kan toewys aan gebruikers, groepe, diensprinsipale en bestuurde identiteite. Roltoewysings 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** skep**.
Ingeboude rolle geld slegs vir die hulpbronne waarvoor hulle bedoel is, byvoorbeeld kyk na hierdie 2 voorbeelde van Ingeboude rolle oor Rekenaar hulpbronne:
Verskaf toestemming om rugsteunskuil te maak vir skyfback-up. | 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 toegewys word aan logika-houers (soos bestuursgroepe, intekeninge en hulpbrongroepe) en die betrokke principals sal hulle hê oor die hulpbronne binne daardie houers.
Vind hier 'n lys met alle Azure ingeboude rolle.
Vind hier 'n lys met alle Azure AD ingeboude rolle.
Aangepaste Rolle
Azure laat ook toe om aangepaste rolle te skep met die toestemmings wat die gebruiker benodig.
Toestemming Geweier
Om 'n prinsipaal toegang tot 'n hulpbron te gee moet 'n eksplisiete rol aan hom toegeken word (hoe dan ook) wat hom daardie toestemming gee.
'n eksplisiete ontkenroltoewysing het voorrang bo die rol wat die toestemming gee.
Globale Administrateur
Gebruikers met die Globale Administrateur rol het die vermoë om 'op te hef' na die Gebruikerstoegangsadministrateur Azure rol na die hoofbestuursgroep. Dit beteken dat 'n Globale Administrateur in staat sal wees om toegang te bestuur tot alle Azure intekeninge en bestuursgroepe. Hierdie opheffing kan gedoen word aan die einde van die bladsy: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure Beleide
Azure beleide is 'n stel reëls en regulasies in Microsoft Azure, 'n wolkrekenaardiens, wat help om organisatoriese standaarde te bestuur en af te dwing en om nakoming op skaal te assesseer. Hierdie beleide dwing verskillende reëls af oor jou Azure-hulpbronne, wat verseker dat daardie hulpbronne voldoen aan korporatiewe standaarde en diensvlak-ooreenkomste.
Azure beleide is noodsaaklik vir wolkbestuur en -sekuriteit, wat help om te verseker dat hulpbronne behoorlik en doeltreffend gebruik word, en dat hulle voldoen aan eksterne regulasies en interne beleide. Sommige voorbeelde:
Verseker Nakoming met Spesifieke Azure Streke: Hierdie beleid verseker dat alle hulpbronne in spesifieke Azure streke geïmplementeer word. Byvoorbeeld, 'n maatskappy wil dalk verseker dat al sy data in Europa gestoor word vir GDPR-nakoming.
Afdwinging van 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 Tipes Hulpbronne: Hierdie beleid kan die skepping van sekere tipes hulpbronne beperk. Byvoorbeeld, 'n beleid kan ingestel word om die skepping van duur hulpbrontipes, soos sekere VM-groottes, te voorkom om koste te beheer.
Afdwinging van Etiketteringsbeleide: Etikette is sleutel-waardepare wat met Azure-hulpbronne geassosieer word vir hulpbronbestuur. 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.
Beperking van Openbare Toegang tot Hulpbronne: Beleide kan afdwing dat sekere hulpbronne, soos bergingsrekeninge of databasisse, nie openbare eindpunte het nie, wat verseker dat hulle slegs binne die organisasie se netwerk toeganklik is.
Outomatiese Toepassing van Sekuriteitsinstellings: Beleide kan gebruik word om outomatiese sekuriteitsinstellings op hulpbronne toe te pas, soos die toepassing van 'n spesifieke netwerksekuriteitsgroep op alle VM's of die versekering dat alle bergingsrekeninge kriptering gebruik.
Let daarop dat Azure Beleide aan enige vlak van die Azure-hierargie geheg kan word, maar hulle word gewoonlik gebruik in die hoofbestuursgroep of in ander bestuursgroepe.
Toestemmingsomvang
In Azure word toestemmings toegewys aan enige deel van die hiërargie. Dit sluit bestuursgroepe, intekeninge, hulpbrongroepe en individuele hulpbronne in. Toestemmings word geërf deur die ingeslote hulpbronne van die entiteit waar hulle toegewys is.
Hierdie hiërargiese struktuur maak doeltreffende en skaalbare bestuur van toegangstoestemmings moontlik.
Azure RBAC vs ABAC
RBAC (rolgebaseerde toegangsbeheer) is wat ons reeds gesien het in die vorige afdelings: Die toewysing van 'n rol aan 'n prinsipaal om hom toegang te verleen oor 'n hulpbron. Tog, in sommige gevalle wil jy dalk fynkorrelige toegangsbestuur bied of die bestuur van honderde roltoewysings vereenvoudig.
Azure ABAC (attribuutgebaseerde toegangsbeheer) bou voort op Azure RBAC deur roltoewysingsvoorwaardes toe te voeg gebaseer op eienskappe in die konteks van spesifieke aksies. 'n Roltoewysingsvoorwaarde is 'n bykomende kontrole wat jy opsioneel by jou roltoewysing kan voeg om meer fynkorrelige toegangsbeheer te bied. 'n Voorwaarde filter af die toestemmings wat verleen word as deel van die roldefinisie en roltoewysing. Byvoorbeeld, jy kan 'n voorwaarde byvoeg wat vereis dat 'n voorwerp 'n spesifieke etiket moet hê om die voorwerp te lees. Jy kan nie uitdruklik toegang tot spesifieke hulpbronne ontken deur voorwaardes te gebruik.
Standaard Gebruikerspermissies
'n Basiese gebruiker sal sommige standaard permissies hê om sekere dele van AzureAD op te som:
Lees alle gebruikers, Groepe, Toepassings, Toestelle, Rolle, Inschrywings, en hul openbare eienskappe
Nooi Gaste uit (kan afgeskakel word)
Skep Sekuriteitsgroepe
Lees nie-versteekte Groepslidmaatskappe
Voeg gaste by Eie groepe
Skep nuwe toepassing (kan afgeskakel word)
Voeg tot 50 toestelle by Azure by (kan afgeskakel word)
Jy kan die volledige lys van standaard permissies van gebruikers in die dokumentasie sien. Verder, let daarop dat in daardie lys kan jy ook die gaste se standaard permissieslys sien.
Onthou dat om Azure-bronne op te som, moet die gebruiker 'n uitdruklike toestemming hê.
Bevoorregte Identiteitsbestuur (PIM)
Bevoorregte Identiteitsbestuur (PIM) in Azure is 'n instrument wat bevoorregte toegang bestuur, beheer, en monitor in Azure Active Directory en Azure. Dit verbeter sekuriteit deur net-op-tyd en tydbeperkte bevoorregte toegang te voorsien, goedkeuringsprosesse af te dwing, en addisionele verifikasie te vereis. Hierdie benadering verminder die risiko van ongemagtigde toegang deur te verseker dat verhoogde permissies slegs toegeken word wanneer dit nodig is en vir 'n spesifieke tydsduur.
Verifikasie Tokens
Daar is drie tipes tokens wat in OIDC gebruik word:
Toegangstokens: Die klient bied hierdie token aan die hulpbronbediener aan om hulpbronne te benader. Dit kan slegs gebruik word vir 'n spesifieke kombinasie van gebruiker, klient, en hulpbron en kan nie herroep word tot verval - dit is standaard 1 uur. Op hierdie manier is die opsporing laag.
ID-tokens: Die klient ontvang hierdie token van die magtigingbediener. Dit bevat basiese inligting oor die gebruiker. Dit is gebind aan 'n spesifieke kombinasie van gebruiker en klient.
Verfris Tokens: Verskaf aan die klient saam met toegangstoken. Gebruik om nuwe toegangs- en ID-tokens te kry. Dit is gebind aan 'n spesifieke kombinasie van gebruiker en klient en kan herroep word. Standaard vervaltyd is 90 dae vir onaktiewe verfris-tokens en geen verval vir aktiewe tokens.
Inligting vir voorwaardelike toegang word gestoor binne die JWT. Dus, as jy die token vanaf 'n toegelate IP-adres aanvra, sal daardie IP in die token gestoor word en dan kan jy daardie token vanaf 'n nie-toegelate IP gebruik om die hulpbronne te benader.
Kyk na die volgende bladsy om verskillende maniere te leer om toegangstokens aan te vra en mee in te teken:
pageAz - AzureAD (AAD)Die mees algemene API-eindpunte is:
Azure-hulpbronbestuurder (ARM): management.azure.com
Microsoft Grafiek: graph.microsoft.com (Azure AD Grafiek wat verouderd is, is graph.windows.net)
Verwysings
Last updated
