Toegangsbeheerlijsten (ACL's) in Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 implementeert een model voor toegangsbeheer dat ondersteuning biedt voor zowel Op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) als POSIX-achtige toegangsbeheerlijsten (ACL's). In dit artikel worden toegangsbeheerlijsten in Data Lake Storage Gen2. Zie Toegangsbeheermodel in Azure Data Lake Storage Gen2 voor meer informatie over het integreren van Azure RBAC met ACL's en hoe het systeem deze evalueert om autorisatiebeslissingen te Azure Data Lake Storage Gen2.

Over ACL's

U kunt een beveiligingsprincipaal koppelen aan een toegangsniveau voor bestanden en mappen. Deze verbanden worden vastgelegd in een toegangsbeheerlijst (ACL). Elk bestand en elke map in uw opslagaccount heeft een toegangsbeheerlijst. Wanneer een beveiligingsprincipaal een bewerking probeert uit te voeren op een bestand of map, bepaalt een ACL-controle of die beveiligingsprincipaal (gebruiker, groep, service-principal of beheerde identiteit) het juiste machtigingsniveau heeft om de bewerking uit te voeren.

Notitie

ACL's zijn alleen van toepassing op beveiligingsprincipalen in dezelfde tenant en zijn niet van toepassing op gebruikers die gebruikmaken van Gedeelde sleutel of SAS-tokenverificatie (Shared Access Signature). Dat komt doordat er geen identiteit is gekoppeld aan de aanroeper en daarom geen op machtigingen gebaseerde autorisatie op basis van een beveiligingsprincipaal kan worden uitgevoerd.

ACL's instellen

Zie een van de volgende artikelen als u machtigingen op bestands- en mapniveau wilt instellen:

Omgeving Artikel
Azure Storage Explorer Gebruik Azure Storage Explorer voor het beheren van ACL's in Azure Data Lake Storage Gen2
Azure Portal Gebruik de Azure Portal voor het beheren van ACL's in Azure Data Lake Storage Gen2
.NET .NET gebruiken voor het beheren van ACL's in Azure Data Lake Storage Gen2
Java Java gebruiken voor het beheren van ACL's in Azure Data Lake Storage Gen2
Python Python gebruiken voor het beheren van ACL's in Azure Data Lake Storage Gen2
JavaScript (node.js) De JavaScript-SDK in Node.js ACL's beheren in Azure Data Lake Storage Gen2
PowerShell PowerShell gebruiken voor het beheren van ACL's in Azure Data Lake Storage Gen2
Azure CLI Azure CLI gebruiken voor het beheren van ACL's in Azure Data Lake Storage Gen2
REST-API Pad - Bijwerken

Belangrijk

Als de beveiligingsprincipaal een service-principal is, is het belangrijk om de object-id van de service-principal te gebruiken en niet de object-id van de gerelateerde app-registratie. Als u de object-id van de service-principal wilt op halen, opent u de Azure CLI en gebruikt u deze opdracht: az ad sp show --id <Your App ID> --query objectId . Zorg ervoor dat u de tijdelijke <Your App ID> aanduiding vervangt door de app-id van uw app-registratie.

Typen ACL's

Er zijn twee soorten toegangsbeheerlijsten: toegangs-ACL's en standaard-ACL's.

Met toegangs-ACL's beheert u de toegang tot een object. Bestanden en mappen hebben beide Toegangs-ACL's.

Standaard-ACL's zijn sjablonen van ACL's die zijn gekoppeld aan een map die de toegangs-ACL's bepalen voor alle onderliggende items die onder die map worden gemaakt. Bestanden hebben geen Standaard-ACL's.

Toegangs-ACL's en standaard-ACL's hebben dezelfde structuur.

Notitie

Het wijzigen van de standaard-ACL op een bovenliggend heeft geen invloed op de toegangs-ACL of de standaard-ACL van onderliggende items die al bestaan.

Machtigingsniveaus

De machtigingen voor mappen en bestanden in een container zijn Lezen, Schrijven en Uitvoeren en kunnen worden gebruikt voor bestanden en mappen, zoals wordt weergegeven in de volgende tabel:

File Directory
Lezen (L) Kan de inhoud van een bestand lezen Lezen en Uitvoeren zijn vereist om de inhoud van de map weer te geven
Schrijven (S) Kan schrijven of toevoegen aan een bestand Vereist Schrijven en Uitvoeren om onderliggende items in een map te maken
Uitvoeren (U) Betekent niets in de context van Data Lake Storage Gen2 Vereist om de onderliggende items van een map te doorlopen

Notitie

Als u alleen machtigingen verleent met behulp van ACL's (geen Azure RBAC), moet u de beveiligingsprincipaal Machtigingen uitvoeren verlenen voor de hoofdmap van de container en voor elke map in de hiërarchie van mappen die naar het bestand leiden, om een beveiligingsprincipaal lees- of schrijftoegang te verlenen tot een bestand.

Korte formulieren voor machtigingen

LSU wordt gebruikt om Lezen + Schrijven + Uitvoeren aan te geven. Er bestaat een verkorte numerieke vorm. Hierbij is Lezen = 4, Schrijven = 2 en Uitvoeren = 1. De som van deze getallen vertegenwoordigt de machtigingen. Hier volgen enkele voorbeelden.

Numerieke vorm Verkorte vorm Wat het betekent
7 RWX Lezen + Schrijven + Uitvoeren
5 R-X Lezen + Uitvoeren
4 R-- Lezen
0 --- Geen machtigingen

Overname van machtigingen

In het POSIX-model dat wordt gebruikt door Data Lake Storage Gen2, worden machtigingen voor een item opgeslagen op het item zelf. Met andere woorden, machtigingen voor een item kunnen niet worden overgenomen van de bovenliggende items als de machtigingen zijn ingesteld nadat het onderliggende item al is gemaakt. Machtigingen worden alleen overgenomen als de standaardmachtigingen zijn ingesteld op de bovenliggende items voordat de onderliggende items zijn gemaakt.

In de volgende tabel ziet u de ACL-vermeldingen die nodig zijn om een beveiligingsprincipaal in staat te stellen de bewerkingen uit te voeren die worden vermeld in de kolom Bewerking.

Deze tabel bevat een kolom die elk niveau van een fictieve directoryhië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 \ naamData.txt.

Belangrijk

In deze tabel wordt ervan uitgenomen dat u alleen ACL's gebruikt zonder Azure-roltoewijzingen. Zie Permissions table: Combining Azure RBAC and ACL(Tabel Machtigingen: Azure RBAC en ACL combineren) voor een vergelijkbare tabel waarin Azure RBAC wordt gecombineerd met ACL's.

Bewerking / Oregon/ Portland/ Data.txt
Lees Data.txt --X --X --X R--
Aan Data.txt --X --X --X RW-
De Data.txt --X --X -WX ---
Een Data.txt --X --X -WX ---
Lijst / R-X --- --- ---
Lijst /Oregon/ --X R-X --- ---
Lijst /Oregon/Portland/ --X --X R-X ---

Notitie

Schrijfmachtigingen voor het bestand zijn niet vereist om het te verwijderen, zolang aan de vorige twee voorwaarden wordt voldaan.

Gebruikers en identiteiten

Elk bestand en elke map heeft afzonderlijke machtigingen voor deze identiteiten:

  • De gebruiker die eigenaar is
  • De groep die eigenaar is
  • Benoemde gebruikers
  • Benoemde groepen
  • Benoemde service-principals
  • Benoemde beheerde identiteiten
  • Alle andere gebruikers

De identiteiten van gebruikers en groepen zijn Azure Active Directory-identiteiten (Azure AD). Dus tenzij anders vermeld, kan een gebruiker, in de context van Data Lake Storage Gen2, verwijzen naar een Azure AD-gebruiker, service-principal, beheerde identiteit of beveiligingsgroep.

De gebruiker die eigenaar is

De gebruiker die het item heeft gemaakt, wordt automatisch de gebruiker die eigenaar is van het item. Een gebruiker die eigenaar is kan:

  • De machtigingen wijzigen van een bestand waarvan hij eigenaar is.
  • De groep die eigenaar van een bestand is wijzigen, zolang deze gebruiker ook lid is van de doelgroep.

Notitie

De gebruiker die eigenaar is, kan de gebruiker die eigenaar is van een bestand of map niet wijzigen. Alleen supergebruikers kunnen de gebruiker die eigenaar is van een bestand of map wijzigen.

De groep die eigenaar is

In de POSIX ACL's is elke gebruiker gekoppeld aan een primaire groep. De gebruiker 'Alice' kan bijvoorbeeld deel uitmaken van de groep 'Financiën'. Alice kan ook deel uitmaken van meerdere groepen, maar één groep wordt altijd aangewezen als de primaire groep. Wanneer Els in POSIX een bestand maakt, wordt de groep die eigenaar van het bestand is als haar hoofdgroep ingesteld. In dit geval is dit 'Financiën'. De groep die eigenaar is, gedraagt zich op dezelfde manier als toegewezen machtigingen voor andere gebruikers/groepen.

De groep die eigenaar is toewijzen voor een nieuw bestand of nieuwe map

  • Case 1: de hoofdmap '/'. Deze map wordt gemaakt wanneer een Data Lake Storage Gen2 container wordt gemaakt. In dit geval wordt de groep die eigenaar is ingesteld op de gebruiker die de container heeft gemaakt als deze is gedaan met behulp van OAuth. Als de container is gemaakt met behulp van gedeelde sleutel, een account-SAS of een service-SAS, worden de eigenaar en groep die eigenaar is ingesteld op $superuser.
  • Case 2 (elk ander geval): wanneer er een nieuw item wordt gemaakt, wordt de groep die eigenaar is uit de bovenliggende map gekopieerd.

De groep die eigenaar is wijzigen

De groep die eigenaar is kan worden gewijzigd door:

  • Alle supergebruikers.
  • De gebruiker die eigenaar is, als deze gebruiker ook lid is van de doelgroep.

Notitie

De groep die eigenaar is, kan de ACL's van een bestand of map niet wijzigen. Hoewel de groep die eigenaar is, is ingesteld op de gebruiker die het account heeft gemaakt in het geval van de hoofdmap, case 1 hierboven, is één gebruikersaccount niet geldig voor het verlenen van machtigingen via de groep die eigenaar is. U kunt deze machtiging toewijzen aan een geldige gebruikersgroep, indien van toepassing.

Algoritme voor toegangscontrole

De volgende pseudocode vertegenwoordigt het algoritme voor toegangscontrole voor opslagaccounts.

def access_check( user, desired_perms, path ) : 
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm
  
  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True 
        
  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

Het masker

Zoals geïllustreerd in het algoritme voor toegangscontrole beperkt het masker de toegang voor benoemde gebruikers, de groep die eigenaar is en benoemde groepen.

Voor een nieuwe Data Lake Storage Gen2-container wordt het masker voor de toegangs-ACL van de hoofdmap ('/') standaard ingesteld op 750 voor mappen en 640 voor bestanden. In de volgende tabel ziet u de symbolische notatie van deze machtigingsniveaus.

Entiteit Mappen Bestanden
Gebruiker die eigenaar is rwx r-w
Groep die eigenaar is r-x r--
Anders --- ---

Bestanden ontvangen de X-bit niet, omdat deze niet relevant zijn voor bestanden in een systeem dat alleen wordt opgeslagen.

Het masker kan per aanroep worden opgegeven. Hierdoor kunnen verschillende verbruikende systemen, zoals clusters, verschillende effectieve maskers hebben voor hun bestandsbewerkingen. Als een masker is opgegeven voor een bepaalde aanvraag, wordt het standaardmasker volledig overschreven.

De vergrendelde bit

De sticky bit is een geavanceerdere functie van een POSIX-container. In de context van Data Lake Storage Gen2 is het onwaarschijnlijk dat de sticky bit nodig is. Samengevat: als de sticky bit is ingeschakeld in een map, kan een onderliggend item alleen worden verwijderd of hernoemd door de gebruiker die eigenaar is van het onderliggende item.

De sticky bit wordt niet weergegeven in de Azure Portal.

Standaardmachtigingen voor nieuwe bestanden en mappen

Wanneer een nieuw bestand of nieuwe map wordt gemaakt onder een bestaande map, bepaalt de standaard-ACL in de bovenliggende map:

  • De standaard-ACL en toegangs-ACL van een onderliggende map.
  • De toegangs-ACL van een onderliggend bestand (bestanden hebben geen standaard-ACL).

umask

Wanneer u een bestand of map maakt, wordt umask gebruikt om te wijzigen hoe de standaard-ACL's worden ingesteld voor het onderliggende item. umask is een 9-bits waarde voor bovenliggende directories die een RWX-waarde bevat voor de gebruiker die eigenaar is, de groep die eigenaar is en andere.

De umask voor Azure Data Lake Storage Gen2 een constante waarde die is ingesteld op 007. Deze waarde wordt omgezet in:

umask-onderdeel Numerieke vorm Verkorte vorm Betekenis
umask.owning_user 0 --- Voor de gebruiker die eigenaar is, kopieert u de standaard-ACL van de bovenliggende gebruiker naar de toegangs-ACL van het onderliggende
umask.owning_group 0 --- Voor de groep die eigenaar is, kopieert u de standaard-ACL van de bovenliggende groep naar de toegangs-ACL van het onderliggende
umask.other 7 RWX Voor andere, verwijdert u alle machtigingen voor de toegangs-ACL van het onderliggende

De umask-waarde die wordt gebruikt door Azure Data Lake Storage Gen2 betekent dat de waarde voor andere nooit standaard wordt verzonden op nieuwe kinderen, tenzij er een standaard-ACL is gedefinieerd in de bovenliggende map. In dat geval wordt de umask genegeerd en worden de machtigingen die zijn gedefinieerd door de standaard-ACL toegepast op het onderliggende item.

De volgende pseudocode laat zien hoe de umask wordt toegepast bij het maken van de ACL's voor een onderliggend item.

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

Veelgestelde vragen

Moet ik ondersteuning voor ACL's inschakelen?

Nee. Toegangsbeheer via ACL's is ingeschakeld voor een opslagaccount zolang de functie Hiërarchische naamruimte (HNS) is ingeschakeld.

Als HNS is uitgeschakeld, zijn de Azure RBAC-autorisatieregels nog steeds van toepassing.

Wat is de beste manier om ACL's toe te passen?

Gebruik altijd Azure AD-beveiligings groepen als de toegewezen Principal in een ACL-vermelding. Houd de kans 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 de Acl's opnieuw hoeft toe te passen op een volledige mapstructuur. In plaats daarvan kunt u alleen gebruikers en service-principals toevoegen aan of verwijderen uit de juiste Azure AD-beveiligings groep.

Er zijn veel verschillende manieren om groepen in te stellen. Stel dat u een map hebt met de naam /LogData , die logboek gegevens bevat die door de server worden gegenereerd. Met Azure Data Factory (ADF) worden gegevens opgenomen in die map. Specifieke gebruikers van het team van de service techniek 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. Daarna kunt u machtigingen als volgt toewijzen:

  • 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 Managed Service Identity (MSI) voor ADF toe aan de LogsWriters groep.
  • Gebruikers in het team van de service techniek toevoegen aan de LogsWriter groep.
  • Voeg het Service-Principal-object of MSI voor Databricks toe aan de LogsReader groep.

Als een gebruiker in het service engineering-team 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 exclusieve ACL-vermelding voor die gebruiker hebt, moet u die ACL-vermelding verwijderen uit de map /LogData . U moet ook de vermelding verwijderen uit alle submappen en bestanden in de volledige Directory-hiërarchie van de /LogData -map.

Als u een groep wilt maken en leden wilt toevoegen, raadpleegt u een basis groep maken en leden toevoegen met behulp van Azure Active Directory.

Hoe worden azure RBAC- en ACL-machtigingen geëvalueerd?

Zie How permissions are evaluate(Hoe machtigingen worden geëvalueerd) voor meer informatie over hoe het systeem Azure RBAC en ACL's samen evalueert om autorisatiebeslissingen te nemen voor opslagaccountbronnen.

Wat zijn de limieten voor Azure-roltoewijzingen en ACL-vermeldingen?

De volgende tabel bevat een overzicht van de limieten die u moet overwegen bij het gebruik van Azure RBAC voor het beheren van 'coarse-grain'-machtigingen (machtigingen die van toepassing zijn op opslagaccounts of containers) en het gebruik van ACL's voor het beheren van 'fijnmadere' machtigingen (machtigingen die van toepassing zijn op bestanden en mappen). Gebruik beveiligingsgroepen voor ACL-toewijzingen. Door groepen te gebruiken, is het minder waarschijnlijk dat u het maximum aantal roltoewijzingen per abonnement en het maximum aantal ACL-vermeldingen per bestand of map overschrijdt.

Mechanisme Bereik Limieten Ondersteund machtigings niveau
Azure RBAC Opslag accounts, containers.
Azure-roltoewijzingen voor meerdere resources op het niveau van een abonnement of resource groep.
2000 Azure-roltoewijzingen in een abonnement Azure-rollen (ingebouwd of aangepast)
MIGREREN Map, bestand 32 ACL-vermeldingen (in feite 28 ACL-vermeldingen) per bestand en per map. De toegangs-en standaard-Acl's hebben elk een eigen 32 ACL-ingangs limiet. ACL-machtiging

Ondersteunt Data Lake Storage Gen2 overname van Azure RBAC?

Azure-roltoewijzingen nemen deze wel over. Toewijzingen stromen van abonnements-, resourcegroep- en opslagaccountresources naar de containerresource.

Ondersteunt Data Lake Storage Gen2 overname van ACL's?

Standaard-ACL's kunnen worden gebruikt om ACL's in te stellen voor nieuwe onderliggende subdirectory's en bestanden die zijn gemaakt onder de bovenliggende map. Als u ACL's voor bestaande onderliggende items wilt bijwerken, moet u ACL's recursief toevoegen, bijwerken of verwijderen voor de gewenste directoryhiërarchie. Zie de sectie ACL's instellen van dit artikel voor hulp.

Welke machtigingen zijn vereist om een map en de inhoud ervan recursief te verwijderen?

  • De aanroeper heeft machtigingen voor 'supergebruiker',

of

  • De bovenliggende map moet schrijf- en uitvoermachtigingen hebben.
  • Voor de map die moet worden verwijderd, en elke map in de map, zijn de machtigingen Lezen + Schrijven + Uitvoeren vereist.

Notitie

U hebt geen schrijfmachtigingen nodig om bestanden in mappen te verwijderen. Bovendien kan de hoofdmap '/' nooit worden verwijderd.

Wie is de eigenaar van een bestand of map?

De maker van een bestand of map wordt de eigenaar. In het geval van de hoofdmap is dit de identiteit van de gebruiker die de container heeft gemaakt.

Welke groep is ingesteld als de groep die eigenaar is van een bestand of map bij het maken?

De groep die eigenaar is, wordt gekopieerd uit de groep die eigenaar is van de bovenliggende map waaronder het nieuwe bestand of de nieuwe map wordt gemaakt.

Ik ben de gebruiker die eigenaar is van een bestand, maar ik heb niet de RWX-machtigingen die ik nodig heb. Wat moet ik doen?

De gebruiker die eigenaar is kan de machtigingen van het bestand wijzigen en zichzelf de vereiste LSU-machtigingen geven.

Waarom zie ik soms GUID's in ACL's?

Er wordt een GUID weergegeven als de vermelding een gebruiker vertegenwoordigt en die gebruiker niet meer in Azure AD bestaat. Dit gebeurt doorgaans wanneer gebruikers het bedrijf verlaten of hun accounts zijn verwijderd in Azure AD. Daarnaast hebben service-principals en beveiligingsgroepen geen USER Principal Name (UPN) om ze te identificeren en worden ze dus vertegenwoordigd door hun OID-kenmerk (een GUID).

Hoe kan ik ACL's correct instellen voor een service-principal?

Wanneer u ACL's voor service-principals definieert, is het belangrijk om de object-id (OID) van de service-principal te gebruiken voor de app-registratie die u hebt gemaakt. Het is belangrijk te weten dat geregistreerde apps een afzonderlijke service-principal hebben in de specifieke Azure AD-tenant. Geregistreerde apps hebben een OID die zichtbaar is in de Azure Portal, maar de service-principal heeft een andere (andere) OID.

U kunt de opdracht gebruiken om de OID op te halen voor de service-principal die overeenkomt met een az ad sp show app-registratie. Geef de toepassings-id op als parameter. Hier is een voorbeeld van het verkrijgen van de OID voor de service-principal die overeenkomt met een app-registratie met app-id = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Voer de volgende opdracht uit in de Azure CLI:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

OID wordt weergegeven.

Wanneer u de juiste OID voor de service-principal hebt, gaat u naar de pagina Storage Explorer Toegang beheren om de OID toe te voegen en de juiste machtigingen voor de OID toe te wijzen. Zorg ervoor dat u Opslaan selecteert.

Kan ik de ACL van een container instellen?

Nee. Een container heeft geen ACL. U kunt echter de ACL van de hoofdmap van de container instellen. Elke container heeft een hoofdmap en deelt dezelfde naam als de container. Als de container bijvoorbeeld de naam my-container heeft, heeft de hoofdmap de naam myContainer/ .

De Azure Storage REST API bevat een bewerking met de naam Container-ACLinstellen, maar die bewerking kan niet worden gebruikt om de ACL van een container of de hoofdmap van een container in te stellen. In plaats daarvan wordt deze bewerking gebruikt om aan te geven of blobs in een container openbaar toegankelijk zijn.

Waar kan ik meer informatie over het POSIX-model voor toegangsbeheer?

Zie ook