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 beschreven. Zie Access control model in Azure Data Lake Storage Gen2 (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 nemen.

Over ACL's

U kunt een beveiligingsprincipaal koppelen aan een toegangsniveau voor bestanden en mappen. Elke associatie wordt vastgelegd als een vermelding 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.

ACL's instellen

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

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.

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:

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.

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 er standaardmachtigingen zijn ingesteld op de bovenliggende items voordat de onderliggende items zijn gemaakt.

Algemene scenario's met betrekking tot ACL-machtigingen

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.

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.

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 hun 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 voor een nieuw bestand of nieuwe map toewijzen

• 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 een gedeelde sleutel, een account-SAS of een service-SAS, worden de eigenaar en groep die eigenaar zijn ingesteld op $superuser .
• Case 2 (elk ander geval): Wanneer een nieuw item wordt gemaakt, wordt de groep die eigenaar is, gekopieerd uit de bovenliggende map.

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.

Hoe machtigingen worden geëvalueerd

Identiteiten worden in de volgende volgorde geëvalueerd:

1. Superuser
2. Gebruiker die eigenaar is
3. Benoemde gebruiker, service-principal of beheerde identiteit
4. Groep of benoemde groep die eigenaar is
5. Alle andere gebruikers

Als meer dan een van deze identiteiten van toepassing is op een beveiligingsprincipaal, wordt het machtigingsniveau verleend dat is gekoppeld aan de eerste identiteit. Als een beveiligingsprincipaal bijvoorbeeld zowel de gebruiker die eigenaar is als een benoemde gebruiker is, is het machtigingsniveau van toepassing dat is gekoppeld aan de gebruiker die eigenaar is.

De volgende pseudocode vertegenwoordigt het algoritme voor toegangscontrole voor opslagaccounts. Dit algoritme toont de volgorde waarin identiteiten worden geëvalueerd.

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.

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:

De umask-waarde die wordt gebruikt door Azure Data Lake Storage Gen2 betekent dat de waarde voor andere nooit standaard wordt verzonden voor 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 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 kunt 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 'fijnmade' 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.

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 voor het recursief verwijderen van een map en de inhoud ervan?

• 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 en Uitvoeren vereist.

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 bestaat in Azure AD. 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 my-container/ .

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?

• POSIX met behulp van toegangsbeheerlijsten op Linux
• Handleiding voor HDFS-machtigingen
• Veelgestelde vragen over POSIX
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• POSIX ACL in Ubuntu
• ACL met behulp van toegangsbeheerlijsten in Linux

Zie ook

• Model voor toegangsbeheer in Azure Data Lake Storage Gen2