Toegangsbeheermodel in Azure Data Lake Storage

Data Lake Storage ondersteunt de volgende autorisatiemechanismen:

• Autorisatie van gedeelde sleutels
• Sas-autorisatie (Shared Access Signature)
• Op rollen gebaseerd toegangsbeheer (Azure RBAC)
• Op kenmerken gebaseerd toegangsbeheer (Azure ABAC)
• Toegangsbeheerlijsten (ACL)

Gedeelde sleutel en SAS-autorisatie verlenen toegang tot een gebruiker (of toepassing) zonder dat ze een identiteit in Microsoft Entra-id hoeven te hebben. Met deze twee vormen van verificatie hebben Azure RBAC, Azure ABAC en ACL's geen effect.

Azure RBAC en ACL vereisen beide dat de gebruiker (of toepassing) een identiteit heeft in Microsoft Entra ID. Met Azure RBAC kunt u 'grofmazige' toegang verlenen tot opslagaccountgegevens, zoals lees- of schrijftoegang tot alle gegevens in een opslagaccount. Met Azure ABAC kunt u RBAC-roltoewijzingen verfijnen door voorwaarden toe te voegen. U kunt bijvoorbeeld lees- of schrijftoegang verlenen aan alle gegevensobjecten in een opslagaccount met een specifieke tag. Met ACL's kunt u 'fijnmazige' toegang verlenen, zoals schrijftoegang tot een specifieke map of bestand.

Dit artikel is gericht op Azure RBAC, ABAC en ACL's en hoe het systeem deze samen evalueert om autorisatiebeslissingen te nemen voor opslagaccountbronnen.

Op rollen gebaseerd toegangsbeheer (Azure RBAC)

Azure RBAC maakt gebruik van roltoewijzingen om sets machtigingen toe te passen op beveiligingsprinciplen. Een beveiligingsprincipaal is een object dat een gebruiker, groep, service-principal of beheerde identiteit vertegenwoordigt die is gedefinieerd in Microsoft Entra-id. Een machtigingenset kan een beveiligingsprincipaal een 'grof' toegangsniveau geven, zoals lees- of schrijftoegang tot alle gegevens in een opslagaccount of alle gegevens in een container.

Met de volgende rollen kan een beveiligingsprincipaal toegang krijgen tot gegevens in een opslagaccount.

Rol	Beschrijving
Eigenaar van opslagblobgegevens	Volledige toegang tot Blob Storage-containers en -gegevens. Met deze toegang kan de beveiligingsprincipal de eigenaar van een item instellen en de ACL's van alle items wijzigen.
Inzender van opslag-blobgegevens	Lees-, schrijf- en verwijder toegang tot Blob Storage-containers en -blobs. Met deze toegang kan de beveiligingsprincipaal het eigendom van een item niet instellen, maar kan de ACL worden gewijzigd van items die eigendom zijn van de beveiligingsprincipaal.
Lezer voor opslagblobgegevens	Blob Storage-containers en -blobs lezen en vermelden.

Met rollen zoals Eigenaar, Inzender, Lezer en Inzender voor opslagaccounts kan een beveiligingsprincipaal een opslagaccount beheren, maar geen toegang bieden tot de gegevens binnen dat account. Deze rollen (met uitzondering van lezer) kunnen echter toegang krijgen tot de opslagsleutels, die kunnen worden gebruikt in verschillende clienthulpprogramma's voor toegang tot de gegevens.

Op kenmerken gebaseerd toegangsbeheer (Azure ABAC)

Azure ABAC bouwt voort op Azure RBAC door roltoewijzingsvoorwaarden toe te voegen op basis van kenmerken in de context van specifieke acties. Een voorwaarde voor roltoewijzing is een extra controle die u desgewenst kunt toevoegen aan uw roltoewijzing om meer verfijnd toegangsbeheer te bieden. U kunt de toegang tot specifieke resources niet expliciet weigeren met behulp van voorwaarden.

Zie Toegang tot Azure Blob Storage autoriseren met behulp van azure-roltoewijzingsvoorwaarden voor meer informatie over het gebruik van Azure ABAC om de toegang tot Azure Storage te beheren.

ACL’s (toegangsbeheerlijsten)

ACL's bieden u de mogelijkheid om een 'fijner' toegangsniveau toe te passen op mappen en bestanden. Een ACL is een machtigingsconstructie die een reeks ACL-vermeldingen bevat. Elke ACL-vermelding koppelt de beveiligingsprincipaal aan een toegangsniveau. Zie Toegangsbeheerlijsten (ACL's) in Azure Data Lake Storage voor meer informatie.

Evalueren van machtigingen

Tijdens autorisatie op basis van een beveiligingsprincipaal worden machtigingen geëvalueerd, zoals wordt weergegeven in het volgende diagram.

1. Azure bepaalt of er een roltoewijzing bestaat voor de principal.
   • Als er een roltoewijzing bestaat, worden de voorwaarden voor roltoewijzing (2) vervolgens geëvalueerd.
   • Zo niet, dan worden de ACL's (4) hierna geëvalueerd.
2. Azure bepaalt of er voorwaarden voor ABAC-roltoewijzing bestaan.
   • Als er geen voorwaarden bestaan, wordt toegang verleend.
   • Als er voorwaarden bestaan, worden ze geëvalueerd om te zien of ze overeenkomen met de aanvraag (3).
3. Azure bepaalt of alle voorwaarden van de ABAC-roltoewijzing overeenkomen met de kenmerken van de aanvraag.
   • Als ze allemaal overeenkomen, wordt toegang verleend.
   • Als ten minste één van deze niet overeenkomt, worden de ACL's (4) vervolgens geëvalueerd.
4. Als de toegang niet expliciet is verleend nadat de roltoewijzingen en voorwaarden zijn geëvalueerd, worden de ACL's geëvalueerd.
   • Als de ACL's het aangevraagde toegangsniveau toestaan, wordt toegang verleend.
   • Zo niet, dan wordt de toegang geweigerd.

Belangrijk

Vanwege de manier waarop toegangsmachtigingen door het systeem worden geëvalueerd, kunt u geen toegangsbeheerlijst gebruiken om de toegang te beperken die al is verleend door een roltoewijzing en de bijbehorende voorwaarden. Dat komt doordat het systeem eerst Azure-roltoewijzingen en -voorwaarden evalueert en als de toewijzing voldoende toegangsmachtigingen verleent, ACL's worden genegeerd.

In het volgende diagram ziet u de machtigingsstroom voor drie algemene bewerkingen: mapinhoud weergeven, een bestand lezen en een bestand schrijven.

Machtigingstabel: Azure RBAC, ABAC en ACL's combineren

In de volgende tabel ziet u hoe u Azure-rollen, -voorwaarden en ACL-vermeldingen kunt combineren, zodat een beveiligingsprincipaal de bewerkingen in de kolom Bewerking kan uitvoeren. In deze tabel ziet u een kolom die elk niveau van een fictieve maphiërarchie vertegenwoordigt. Er is een kolom voor de hoofdmap van de container (/), een submap met de naam Oregon, een submap van de map Oregon met de naam Portland en een tekstbestand in de map Portland met de naam Data.txt. In deze kolommen worden korte vormweergaven weergegeven van de ACL-vermelding die is vereist om machtigingen te verlenen. N.v.v. (niet van toepassing) wordt weergegeven in de kolom als een ACL-vermelding niet vereist is om de bewerking uit te voeren.

Operation	Toegewezen Azure-rol (met of zonder voorwaarden)	/	Oregon/	Portland/	Data.txt
Lees Data.txt	Opslag-blobgegevens eigenaar	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Inzender voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Lezer voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Geen	--X	--X	--X	R--
Toevoegen aan Data.txt	Opslag-blobgegevens eigenaar	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Inzender voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Lezer voor opslagblobgegevens	--X	--X	--X	-W-
	Geen	--X	--X	--X	RW-
Data.txt verwijderen	Opslag-blobgegevens eigenaar	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Inzender voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Lezer voor opslagblobgegevens	--X	--X	-WX	N.v.t.
	Geen	--X	--X	-WX	N.v.t.
Data.txt maken	Opslag-blobgegevens eigenaar	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Inzender voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Lezer voor opslagblobgegevens	--X	--X	-WX	N.v.t.
	Geen	--X	--X	-WX	N.v.t.
Lijst/	Opslag-blobgegevens eigenaar	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Inzender voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Lezer voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Geen	R-X	N.v.t.	N.v.t.	N.v.t.
Lijst /Oregon/	Opslag-blobgegevens eigenaar	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Inzender voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Lezer voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Geen	--X	R-X	N.v.t.	N.v.t.
Lijst /Oregon/Portland/	Opslag-blobgegevens eigenaar	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Inzender voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Lezer voor opslagblobgegevens	N.v.t.	N.v.t.	N.v.t.	N.v.t.
	Geen	--X	--X	R-X	N.v.t.

Notitie

Als u de inhoud van een container in Azure Storage Explorer wilt weergeven, moeten beveiligingsprinciplen zich aanmelden bij Storage Explorer met behulp van Microsoft Entra-id en (minimaal) leestoegang hebben (R--) tot de hoofdmap (\) van een container. Dit machtigingsniveau biedt hen de mogelijkheid om de inhoud van de hoofdmap weer te geven. Als u niet wilt dat de inhoud van de hoofdmap zichtbaar is, kunt u de rol Lezer toewijzen. Met deze rol kunnen ze de containers in het account weergeven, maar niet de inhoud van de container. Vervolgens kunt u toegang verlenen tot specifieke mappen en bestanden met behulp van ACL's.

Beveiligingsgroepen

Gebruik altijd Microsoft Entra-beveiligingsgroepen als de toegewezen principal in een ACL-vermelding. Weersta de mogelijkheid om afzonderlijke gebruikers of service-principals rechtstreeks toe te wijzen. Met deze structuur kunt u gebruikers of service-principals toevoegen en verwijderen zonder dat u ACL's opnieuw hoeft toe te voegen aan een hele mapstructuur. In plaats daarvan kunt u alleen gebruikers en service-principals toevoegen aan of verwijderen uit de juiste Microsoft Entra-beveiligingsgroep.

Er zijn veel verschillende manieren om groepen in te stellen. Stel dat u een map hebt met de naam /LogData die logboekgegevens bevat die door uw server worden gegenereerd. Azure Data Factory (ADF) neemt gegevens op in die map. Specifieke gebruikers van het service-engineeringteam uploaden logboeken en beheren andere gebruikers van deze map, en verschillende Databricks-clusters analyseren logboeken uit die map.

Als u deze activiteiten wilt inschakelen, kunt u een LogsWriter groep en een LogsReader groep maken. Vervolgens kunt u machtigingen als volgt toewijzen:

• Voeg de LogsWriter groep toe aan de ACL van de map /LogData met rwx machtigingen.
• Voeg de LogsReader groep toe aan de ACL van de map /LogData met r-x machtigingen.
• Voeg het service-principalobject of Managed Service Identity (MSI) voor ADF toe aan de LogsWriters groep.
• Voeg gebruikers toe aan het technische team van de service aan de LogsWriter groep.
• Voeg het service-principalobject of MSI voor Databricks toe aan de LogsReader groep.

Als een gebruiker in het service-engineeringteam het bedrijf verlaat, kunt u ze gewoon uit de LogsWriter groep verwijderen. Als u die gebruiker niet aan een groep hebt toegevoegd, maar in plaats daarvan een toegewezen ACL-vermelding voor die gebruiker hebt toegevoegd, moet u die ACL-vermelding verwijderen uit de map /LogData . U moet de vermelding ook verwijderen uit alle submappen en bestanden in de volledige maphiërarchie van de map /LogData-map .

Zie Een basisgroep maken en leden toevoegen met behulp van Microsoft Entra-id om een groep te maken en leden toe te voegen.

Belangrijk

Azure Data Lake Storage Gen2 is afhankelijk van de Microsoft Entra-id voor het beheren van beveiligingsgroepen. Microsoft Entra ID raadt u aan om het groepslidmaatschap voor een bepaalde beveiligingsprincipaal te beperken tot minder dan 200. Deze aanbeveling wordt veroorzaakt door een beperking van JSON-webtokens (JWT) die de groepslidmaatschapsgegevens van een beveiligingsprincipaal in Microsoft Entra-toepassingen bieden. Het overschrijden van deze limiet kan leiden tot onverwachte prestatieproblemen met Data Lake Storage Gen2. Zie Groepsclaims configureren voor toepassingen met behulp van Microsoft Entra-id voor meer informatie.

Limieten voor Azure-roltoewijzingen en ACL-vermeldingen

Door gebruik te maken van groepen, verkleint u het risico dat u het maximum aantal roltoewijzingen per abonnement en het maximum aantal ACL-vermeldingen per bestand of map overschrijdt. In de volgende tabel worden deze limieten beschreven.

Mechanisme	Bereik	Limieten	Ondersteund machtigingsniveau
Azure RBAC	Opslagaccounts, containers. Azure-roltoewijzingen voor meerdere resources op abonnements- of resourcegroepniveau.	4000 Azure-roltoewijzingen in een abonnement	Azure-rollen (ingebouwd of aangepast)
ACL	Map, bestand	32 ACL-vermeldingen (effectief 28 ACL-vermeldingen) per bestand en per map. Toegang en standaard-ACL's hebben elk hun invoerlimiet van 32 ACL's.	ACL-machtiging

Sas-autorisatie (Shared Key and Shared Access Signature)

Azure Data Lake Storage biedt ook ondersteuning voor gedeelde sleutel - en SAS-methoden voor verificatie. Een kenmerk van deze verificatiemethoden is dat er geen identiteit is gekoppeld aan de aanroeper en daarom kan geen autorisatie op basis van machtigingen op basis van een beveiligingsprincipaal worden uitgevoerd.

In het geval van gedeelde sleutel krijgt de aanroeper effectief 'supergebruiker' toegang, wat betekent dat alle bewerkingen op alle resources, inclusief gegevens, instellingseigenaar en wijzigen van ACL's, volledige toegang krijgen tot alle bewerkingen.

SAS-tokens bevatten toegestane machtigingen als onderdeel van het token. De machtigingen die zijn opgenomen in het SAS-token worden effectief toegepast op alle autorisatiebeslissingen, maar er worden geen aanvullende ACL-controles uitgevoerd.

Volgende stappen

Zie Toegangsbeheerlijsten (ACL's) in Azure Data Lake Storage voor meer informatie over toegangsbeheerlijsten.