Toegangsbeheer en data lake-configuraties in Azure Data Lake Storage Gen2

Dit artikel helpt u bij het beoordelen en begrijpen van de mechanismen voor toegangsbeheer in Azure Data Lake Storage Gen2. Deze mechanismen omvatten op rollen gebaseerd toegangsbeheer van Azure (RBAC) en toegangsbeheerlijsten (ACL's). U leert hier hoe u de volgende handelingen kunt uitvoeren:

• Toegang evalueren tussen Azure RBAC en ACL's
• Toegangsbeheer configureren met behulp van een of beide mechanismen
• De mechanismen voor toegangsbeheer toepassen op data lake-implementatiepatronen

U hebt basiskennis nodig van opslagcontainers, beveiligingsgroepen, Azure RBAC en ACL's. Om de discussie te kaderen, verwijzen we naar een algemene data lake-structuur van onbewerkte, verrijkte en gecureerde zones.

U kunt dit document gebruiken met Gegevenstoegangsbeheer.

De ingebouwde Azure RBAC-rollen gebruiken

Azure Storage heeft twee toegangslagen: servicebeheer en gegevens. U hebt toegang tot abonnementen en opslagaccounts via de servicebeheerlaag. Toegang tot containers, blobs en andere gegevensbronnen via de gegevenslaag. Als u bijvoorbeeld een lijst met opslagaccounts van Azure wilt, verzendt u een aanvraag naar het beheereindpunt. Als u een lijst met bestandssystemen, mappen of bestanden in een opslagaccount wilt, verzendt u een aanvraag naar een service-eindpunt.

Rollen kunnen machtigingen bevatten voor toegang tot beheer- of gegevenslagen. De rol Lezer verleent alleen-lezentoegang tot beheerlaagbronnen, maar geen leestoegang tot gegevens.

Rollen zoals Eigenaar, Inzender, Lezer en Inzender voor opslagaccounts kunnen een beveiligingsprincipaal een opslagaccount beheren. Maar ze bieden geen toegang tot de gegevens in dat account. Alleen rollen die expliciet zijn gedefinieerd voor gegevenstoegang, geven een beveiligingsprincipaal toegang tot de gegevens. Deze rollen, met uitzondering van Lezer, krijgen toegang tot de opslagsleutels voor toegang tot gegevens.

Ingebouwde beheerrollen

Hieronder ziet u de ingebouwde beheerrollen.

• Eigenaar: Beheer alles, inclusief toegang tot resources. Deze rol biedt belangrijke toegang.
• Inzender: Beheer alles, behalve toegang tot resources. Deze rol biedt belangrijke toegang.
• Inzender voor opslagaccounts: volledig beheer van opslagaccounts. Deze rol biedt belangrijke toegang.
• Lezer: lees- en lijstbronnen. Deze rol biedt geen sleuteltoegang.

Ingebouwde gegevensrollen

Hieronder ziet u de ingebouwde gegevensrollen.

• Eigenaar van opslagblobgegevens: volledige toegang tot Azure Storage-blobcontainers en -gegevens, waaronder het instellen van eigendom en het beheren van POSIX-toegangsbeheer.
• Inzender voor opslagblobgegevens: Azure Storage-containers en -blobs lezen, schrijven en verwijderen.
• Opslagblobgegevenslezer: Azure Storage-containers en -blobs lezen en vermelden.

De eigenaar van de opslagblobgegevens is een supergebruikersrol die volledige toegang heeft tot alle mutatiebewerkingen. Deze bewerkingen omvatten het instellen van de eigenaar van een map of bestand en ACL's voor mappen en bestanden waarvoor ze niet de eigenaar zijn. Supergebruikerstoegang is de enige geautoriseerde manier om de eigenaar van een resource te wijzigen.

Notitie

Het kan vijf minuten duren voordat Azure RBAC-toewijzingen zijn doorgevoerd en van kracht worden.

Hoe toegang wordt geëvalueerd

Tijdens autorisatie op basis van een beveiligingsprincipaal evalueert het systeem machtigingen in de volgende volgorde. Zie het volgende diagram voor meer informatie.

• Azure RBAC wordt eerst geëvalueerd en heeft voorrang op ACL-toewijzingen.
• Als de bewerking volledig is geautoriseerd op basis van RBAC, worden ACL's helemaal niet geëvalueerd.
• Als de bewerking niet volledig is geautoriseerd, worden ACL's geëvalueerd.

Zie Hoe machtigingen worden geëvalueerd voor meer informatie.

Notitie

Dit machtigingsmodel is alleen van toepassing op Azure Data Lake Storage. Deze is niet van toepassing op algemeen gebruik of blobopslag zonder hiërarchische naamruimte ingeschakeld. Deze beschrijving sluit gedeelde sleutels en SAS-verificatiemethoden uit. Het sluit ook scenario's uit waarin de beveiligingsprincipaal de ingebouwde rol Eigenaar van opslagblobgegevens krijgt toegewezen, die supergebruikerstoegang biedt. Ingesteld allowSharedKeyAccess op onwaar, zodat de toegang wordt gecontroleerd op identiteit.

Zie Toegangsbeheerlijsten in Azure Data Lake Storage Gen2 voor meer informatie over welke machtigingen op basis van toegangsbeheer zijn vereist voor een bepaalde bewerking.

Notitie

• Toegangsbeheerlijsten zijn alleen van toepassing op beveiligingsprinciplen in dezelfde tenant, inclusief gastgebruikers.
• Elke gebruiker met machtigingen voor het koppelen aan een cluster kan Azure Databricks-koppelpunten maken. Configureer het koppelpunt met behulp van service-principalreferenties of de optie Microsoft Entra Passthrough. Op het moment van maken worden machtigingen niet geëvalueerd. Machtigingen worden geëvalueerd wanneer een bewerking gebruikmaakt van het koppelpunt. Elke gebruiker die aan een cluster kan koppelen, kan proberen het koppelpunt te gebruiken.
• Wanneer een gebruiker een tabeldefinitie maakt in Azure Databricks of Azure Synapse Analytics, moeten ze leestoegang hebben tot de onderliggende gegevens.

Toegang tot Azure Data Lake Storage configureren

Toegangsbeheer instellen in Azure Data Lake Storage met behulp van Azure RBAC, ACL's of een combinatie van beide.

Toegang configureren met alleen Azure RBAC

Als toegangsbeheer op containerniveau voldoende is, bieden Azure RBAC-toewijzingen een eenvoudige beheerbenadering voor het beveiligen van gegevens. Het is raadzaam om toegangsbeheerlijsten te gebruiken voor een groot aantal beperkte gegevensassets of waar u gedetailleerd toegangsbeheer nodig hebt.

Alleen toegang configureren met ACL's

Hieronder vindt u een overzicht van configuratieaanbeveling voor analyses op cloudschaal.

Toegangsbeheervermeldingen toewijzen aan een beveiligingsgroep in plaats van aan een afzonderlijke gebruiker of service-principal. Zie Beveiligingsgroepen gebruiken versus afzonderlijke gebruikers voor meer informatie.

Wanneer u gebruikers toevoegt aan of verwijdert uit de groep, hoeft u geen updates te maken voor Data Lake Storage. Bovendien vermindert het gebruik van groepen de kans dat de 32 vermeldingen voor toegangsbeheer per bestand of map-ACL worden overschreden. Na de vier standaardvermeldingen zijn er slechts 28 resterende vermeldingen voor machtigingstoewijzingen.

Zelfs wanneer u groepen gebruikt, kunt u veel vermeldingen voor toegangsbeheer hebben op het hoogste niveau van de mapstructuur. Deze situatie treedt op wanneer gedetailleerde machtigingen voor verschillende groepen vereist zijn.

Toegang configureren met zowel Azure RBAC- als toegangsbeheerlijsten

De machtigingen voor Inzender voor opslagblobgegevens en Opslagblobgegevenslezer bieden toegang tot de gegevens en niet tot het opslagaccount. U kunt toegang verlenen op het niveau van het opslagaccount of op containerniveau. Als inzender voor opslagblobgegevens is toegewezen, kunnen ACL's niet worden gebruikt om de toegang te beheren. Als opslagblobgegevenslezer is toegewezen, kunt u schrijfmachtigingen met verhoogde bevoegdheid verlenen met behulp van ACL's. Zie Hoe de toegang wordt geëvalueerd voor meer informatie.

Deze benadering is geschikt voor scenario's waarbij de meeste gebruikers leestoegang nodig hebben, maar slechts een paar gebruikers schrijftoegang nodig hebben. De data lake-zones kunnen verschillende opslagaccounts zijn en gegevensassets kunnen verschillende containers zijn. De data lake-zones kunnen worden vertegenwoordigd door containers en gegevensassets die worden vertegenwoordigd door mappen.

Methoden voor geneste toegangsbeheerlijsten

Er zijn twee benaderingen voor geneste ACL-groepen.

Optie 1: De bovenliggende uitvoergroep

Voordat u bestanden en mappen maakt, begint u met een bovenliggende groep. Wijs die groep uitvoeringsmachtigingen toe aan zowel standaard-ACL's als toegang tot ACL's op containerniveau. Voeg vervolgens de groepen toe waarvoor gegevenstoegang tot de bovenliggende groep is vereist.

Waarschuwing

We raden u aan dit patroon te gebruiken waarbij u recursieve verwijderingen hebt en in plaats daarvan Optie 2: De lijst met toegangsbeheer andere vermeldingen.

Deze techniek wordt geneste groepen genoemd. De lidgroep neemt de machtigingen over van de bovenliggende groep, die globale uitvoeringsmachtigingen biedt voor alle lidgroepen. De ledengroep heeft geen uitvoeringsmachtigingen nodig omdat deze machtigingen worden overgenomen. Meer nesting biedt mogelijk meer flexibiliteit en flexibiliteit. Voeg beveiligingsgroepen toe die teams of geautomatiseerde taken vertegenwoordigen aan de gegevenstoegangslezer en schrijfgroepen.

Optie 2: De andere vermelding voor toegangsbeheer

De aanbevolen methode is om de ACL te gebruiken die andere vermeldingen zijn ingesteld in de container of hoofdmap. Geef de standaardinstellingen en toegangs-ACL's op, zoals wordt weergegeven in het volgende scherm. Deze aanpak zorgt ervoor dat elk deel van het pad van het hoofd- naar het laagste niveau uitvoeringsmachtigingen heeft.

Deze uitvoeringsmachtiging wordt naar beneden doorgegeven aan alle toegevoegde onderliggende mappen. De machtiging wordt doorgegeven aan de diepte waar de beoogde toegangsgroep machtigingen nodig heeft om te lezen en uit te voeren. Het niveau bevindt zich in het laagste deel van de keten, zoals wordt weergegeven in het volgende scherm. Met deze methode verleent u groepstoegang om de gegevens te lezen. De methode werkt op dezelfde manier voor schrijftoegang.

Aanbevolen beveiliging van Data Lake-zones

De volgende gebruiksgegevens zijn de aanbevolen beveiligingspatronen voor elk van de Data Lake-zones:

• Raw mag alleen toegang tot gegevens toestaan met behulp van SPN's (Security Principal Names).
• Verrijkt mag alleen toegang tot gegevens toestaan met behulp van SPN's (Security Principal Names).
• Gecureerd moet toegang toestaan met zowel SPN's (Security Principal Names) als UPN's (User Principal Names).

Voorbeeldscenario voor het gebruik van Microsoft Entra-beveiligingsgroepen

Er zijn veel verschillende manieren om groepen in te stellen. Stel dat u een map hebt met de naam /LogData logboekgegevens die door uw server worden gegenereerd. Azure Data Factory neemt gegevens op in die map. Specifieke gebruikers van het technische team van de service uploaden logboeken en beheren andere gebruikers van deze map. De Azure Databricks-analyse- en data science-werkruimteclusters kunnen logboeken uit die map analyseren.

Als u deze activiteiten wilt inschakelen, maakt u een LogsWriter groep en een LogsReader groep. Wijs de volgende machtigingen toe:

• Voeg de LogsWriter groep toe aan de ACL van de /LogData map met rwx machtigingen.
• Voeg de LogsReader groep toe aan de ACL van de /LogData map met r-x machtigingen.
• Voeg het service-principal-object of de beheerde service-identiteit (MSI) voor Data Factory toe aan de LogsWriters groep.
• Voeg gebruikers toe aan het technische team van de service aan de LogsWriter groep.
• Azure Databricks is geconfigureerd voor Microsoft Entra passthrough naar azure Data Lake Store.

Als een gebruiker in het service-engineeringteam overdraagt naar een ander team, verwijdert u die gebruiker uit de LogsWriter groep.

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 uit de /LogData map verwijderen. U moet de vermelding ook verwijderen uit alle submappen en bestanden in de volledige maphiërarchie van de /LogData map.

Toegangsbeheer voor azure Synapse Analytics-gegevens

Voor het implementeren van een Azure Synapse-werkruimte is een Azure Data Lake Storage Gen2-account vereist. Azure Synapse Analytics maakt gebruik van het primaire opslagaccount voor verschillende integratiescenario's en slaat gegevens op in een container. De container bevat Apache Spark-tabellen en toepassingslogboeken onder een map met de naam /synapse/{workspaceName}. De werkruimte maakt ook gebruik van een container voor het beheren van bibliotheken die u installeert.

Geef tijdens de implementatie van de werkruimte via Azure Portal een bestaand opslagaccount op of maak een nieuw opslagaccount. Het opgegeven opslagaccount is het primaire opslagaccount voor de werkruimte. Het implementatieproces verleent de werkruimte-id toegang tot het opgegeven Data Lake Storage Gen2-account met behulp van de rol Inzender voor opslagblobgegevens.

Als u de werkruimte buiten Azure Portal implementeert, voegt u handmatig de Azure Synapse Analytics-werkruimte-identiteit toe aan de rol Inzender voor opslagblobgegevens. Het is raadzaam om de rol Inzender voor opslagblobgegevens toe te wijzen op containerniveau om het principe van minimale bevoegdheden te volgen.

Wanneer u pijplijnen, werkstromen en notebooks uitvoert via taken, gebruiken ze de machtigingscontext voor werkruimte-id's. Als een van de taken in de primaire opslag van de werkruimte leest of schrijft, gebruikt de werkruimte-id de lees-/schrijfmachtigingen die zijn verleend via de bijdrager voor opslagbloggegevens.

Wanneer gebruikers zich aanmelden bij de werkruimte om scripts uit te voeren of voor ontwikkeling, staan de contextmachtigingen van de gebruiker lees-/schrijftoegang toe op de primaire opslag.

Gedetailleerd toegangsbeheer voor gegevens in Azure Synapse Analytics met behulp van toegangsbeheerlijsten

Wanneer u data lake-toegangsbeheer instelt, hebben sommige organisaties gedetailleerde toegang nodig. Ze hebben mogelijk gevoelige gegevens die niet door sommige groepen in de organisatie kunnen worden gezien. Azure RBAC staat alleen lezen of schrijven toe op opslagaccount- en containerniveau. Met ACL's kunt u fijnmazig toegangsbeheer instellen op map- en bestandsniveau om lezen/schrijven toe te staan voor een subset van gegevens voor specifieke groepen.

Overwegingen bij het gebruik van Spark-tabellen

Wanneer u Apache Spark-tabellen in een Spark-pool gebruikt, wordt er een magazijnmap gemaakt. De map bevindt zich in de hoofdmap van de container in de primaire opslag van de werkruimte:

synapse/workspaces/{workspaceName}/warehouse

Als u van plan bent Om Apache Spark-tabellen te maken in Azure Synapse Spark-pool, verleent u schrijfmachtigingen voor de magazijnmap voor de groep met de opdracht waarmee de Spark-tabel wordt gemaakt. Als de opdracht wordt uitgevoerd via een geactiveerde taak in een pijplijn, verleent u schrijfmachtigingen aan de MSI van de werkruimte.

In dit voorbeeld wordt een Spark-tabel gemaakt:

df.write.saveAsTable("table01")

Zie Toegangsbeheer instellen voor uw Synapse-werkruimte voor meer informatie.

Overzicht van Toegang tot Azure Data Lake

Er is geen enkele benadering voor het beheren van data lake-toegang voor iedereen. Een belangrijk voordeel van een data lake is het bieden van wrijvingsvrije toegang tot gegevens. In de praktijk willen verschillende organisaties verschillende niveaus van governance en controle over hun gegevens. Sommige organisaties hebben een gecentraliseerd team voor het beheren van toegangs- en inrichtingsgroepen onder strenge interne controles. Andere organisaties zijn flexibeler en hebben gedecentraliseerde controle. Kies de benadering die voldoet aan uw governanceniveau. Uw keuze mag niet leiden tot onnodige vertragingen of wrijving bij het verkrijgen van toegang tot gegevens.

Volgende stappen

• Azure Databricks gebruiken in analyses op cloudschaal in Azure