Delen via

Toegangsbeheer in Azure Data Lake Storage Gen1

Azure Data Lake Storage Gen1 implementeert een toegangsbeheermodel dat is afgeleid van HDFS, dat op zijn beurt is afgeleid van het POSIX-toegangsbeheermodel. In dit artikel vindt u een overzicht van de basisbeginselen van het toegangsbeheermodel voor Data Lake Storage Gen1.

Toegangsbeheerlijsten voor bestanden en mappen

Er zijn twee soorten toegangsbeheerlijsten ( ACL's), toegangs-ACL's en standaard-ACL's.

  • Toegangs-ACL's: deze beheertoegang tot een object. Bestanden en mappen hebben beide Toegangs-ACL's.

  • Standaard-ACL's: een "sjabloon" van ACL's die zijn gekoppeld aan een map die de toegangs-ACL's bepaalt voor items die in die map worden gemaakt. Bestanden hebben geen standaard-ACL's.

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

Opmerking

Het veranderen van de standaard-ACL op een ouder heeft geen effect op de toegangs-ACL of de standaard-ACL van kinderen die al bestaan.

Machtigingen

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

Bestand Map
Lezen (L) Kan de inhoud van een bestand lezen Vereist lezen en uitvoeren om de inhoud van de map weer te geven
Schrijven (S) Kan schrijven of toevoegen aan een bestand Schrijven enuitvoeren vereist om onderliggende items in een map te maken
Uitvoeren (X) Betekent niets in de context van Data Lake Storage Gen1 Vereist om de subitems van een map te doorzoeken

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. Hieronder volgen enkele voorbeelden.

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

Machtigingen nemen niet over

In het POSIX-model dat wordt gebruikt door Data Lake Storage Gen1, 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.

Hier volgen enkele veelvoorkomende scenario's om te begrijpen welke machtigingen nodig zijn om bepaalde bewerkingen uit te voeren op een Data Lake Storage Gen1-account.

Operatie Voorwerp / Seattle/ Portland/ Data.txt
Lezen Data.txt --X --X --X R--
Toevoegen aan Data.txt --X --X --X -W-
Verwijderen Data.txt --X --X -WX ---
Aanmaken Data.txt --X --X -WX ---
Lijst / R-X --- --- ---
Lijst /Seattle/ --X R-X --- ---
Lijst /Seattle/Portland/ --X --X R-X ---

Opmerking

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

Gebruikers en identiteiten

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

  • De eigenaar-gebruiker
  • De groep die eigenaar is
  • Benoemde gebruikers
  • Benoemde groepen
  • Alle andere gebruikers

De identiteiten van gebruikers en groepen zijn Microsoft Entra-identiteiten. Tenzij anders vermeld, kan een gebruiker in de context van Data Lake Storage Gen1 ofwel een Microsoft Entra-gebruiker of een Microsoft Entra-beveiligingsgroep betekenen.

De supergebruiker

Een supergebruiker heeft de meeste rechten van alle gebruikers in het Data Lake Storage Gen1-account. Een supergebruiker:

  • Heeft RWX-machtigingen voor alle bestanden en mappen.
  • kan de machtigingen voor elk bestand en elke map wijzigen,
  • kan de eigenaar of groep die eigenaar is van een bestand of map wijzigen.

Alle gebruikers die deel uitmaken van de rol Eigenaren voor een Data Lake Storage Gen1-account, zijn automatisch een supergebruiker.

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 men de eigenaar is.
  • De groep die eigenaar van een bestand is wijzigen, zolang deze gebruiker ook lid is van de doelgroep.

Opmerking

De gebruiker die eigenaar is kan de eigenaar 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

Achtergrond

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

Omdat er geen 'primaire groep' is gekoppeld aan gebruikers in Data Lake Storage Gen1, wordt de groep die eigenaar is, toegewezen zoals hieronder.

Eigenaarsgroep toewijzen voor een nieuw bestand of een nieuwe map

  • Case 1: De hoofdmap '/'. Deze map wordt gemaakt wanneer een Data Lake Storage Gen1-account wordt gemaakt. In dit geval wordt de groep die eigenaar is ingesteld op een all-zero GUID. Deze waarde staat geen toegang toe. Het is een tijdelijke aanduiding totdat een groep wordt toegewezen.
  • Case 2 (alle andere gevallen): 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:

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

Opmerking

De groep die eigenaar is , kan de ACL's van een bestand of map niet wijzigen.

Voor accounts die zijn gemaakt op of vóór september 2018, is de groep die eigenaar is, ingesteld op de gebruiker die het account heeft gemaakt in het geval van de hoofdmap voor Case 1 hierboven. Een gebruikersaccount kan geen machtigingen verlenen via de eigende groep, waardoor deze standaardinstelling geen machtigingen verleent. U kunt deze machtiging toewijzen aan een geldige gebruikersgroep.

Algoritme voor toegangscontrole

De volgende pseudocode vertegenwoordigt het algoritme voor toegangscontrole voor Data Lake Storage Gen1-accounts.

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 folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT 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.permmissions & mask) == desired_perms)

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

Het masker

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

Opmerking

Voor een nieuw Data Lake Storage Gen1-account wordt het masker voor de Toegangs-ACL van de hoofdmap (/) standaard ingesteld op RWX.

De vergrendelde bit

De sticky bit is een geavanceerde functie van een POSIX-bestandssysteem. In de context van Data Lake Storage Gen1 is het onwaarschijnlijk dat de 'sticky bit' nodig zal zijn. Kortom, als de sticky bit is ingeschakeld voor een map, kan een bestand of map daarin alleen worden verwijderd of hernoemd door de gebruiker die eigenaar is van dat bestand of die map.

De plak-bit wordt niet weergegeven in 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 op de bovenliggende map:

  • De standaard-ACL en toegang-ACL van een submap.
  • De Toegangs-ACL van een kindbestand (bestanden hebben geen standaard-ACL).

umask

Bij het maken van een bestand of map wordt umask gebruikt om te wijzigen hoe de standaard-ACL's voor het onderliggende item worden ingesteld. umask is een 9-bits waarde op bovenliggende mappen die een RWX-waarde bevat voor de eigenaar, de eigenaarsgroep en anderen.

De umask voor Azure Data Lake Storage Gen1 is een constante waarde en deze 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 het bovenliggende item naar de toegangs-ACL van het kind
umask.eigenaar_groep 0 --- Voor de eigendomsgroep kopieert u de standaard-ACL van het bovenliggende object naar de toegangs-ACL van het kind.
umask.other 7 RWX Voor andere, verwijdert u alle machtigingen voor de toegangs-ACL van het kind

De umask-waarde die door Azure Data Lake Storage Gen1 wordt gebruikt, betekent effectief dat de waarde voor anderen nooit standaard wordt doorgegeven bij nieuwe subitems, ongeacht wat de standaard-ACL aangeeft.

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 over ACL's in Data Lake Storage Gen1

Moet ik ondersteuning voor ACL's inschakelen?

Nee. Toegangsbeheer via ACL's is altijd ingeschakeld voor een Data Lake Storage Gen1-account.

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

  • De moedermap moet schrijven en uitvoeren machtigingen hebben.
  • Voor de map die moet worden verwijderd en voor elke map erin zijn lees- en schrijfmachtigingen vereist.

Opmerking

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

Wie is de eigenaar van een bestand of map?

De maker van een bestand of map wordt de eigenaar.

Welke groep wordt toegewezen als de groep die eigenaar is van een bestand of map bij aanmaak?

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 eigenaar 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.

Wanneer ik ACL's bekijk in Azure Portal, zie ik gebruikersnamen, maar via API's, ik zie GUID's, waarom is dat?

Vermeldingen in de ACL's worden opgeslagen als GUID's die overeenkomen met gebruikers in Microsoft Entra-id. De API's retourneren de GUID's zoals ze zijn. Azure Portal probeert ACL's gemakkelijker te gebruiken door de GUID's indien mogelijk te vertalen in beschrijvende namen.

Waarom zie ik soms GUID's in de ACL's wanneer ik Azure Portal gebruik?

Er wordt een GUID weergegeven wanneer de gebruiker niet meer in Microsoft Entra bestaat. Dit gebeurt meestal wanneer de gebruiker het bedrijf heeft verlaten of als het account is verwijderd in Microsoft Entra-id. Zorg er ook voor dat u de juiste id gebruikt voor het instellen van ACL's (details hieronder).

Welke id moet ik gebruiken om ACL's in te stellen wanneer ik service-principal gebruik?

Ga in Azure Portal naar Microsoft Entra ID -> Bedrijfstoepassingen en selecteer uw toepassing. Op het tabblad Overzicht moet een object-id worden weergegeven. Dit moet worden gebruikt bij het toevoegen van ACL's voor gegevenstoegang (en niet toepassings-id).

Biedt Data Lake Storage Gen1 ondersteuning voor overname van ACL's?

Nee, maar standaard-ACL's kunnen worden gebruikt om ACL's in te stellen voor kindbestanden en mappen die nieuw worden aangemaakt onder de bovenliggende map.

Wat zijn de limieten voor ACL-vermeldingen in bestanden en mappen?

32 ACL's kunnen per bestand en per map worden ingesteld. Toegang en standaard-ACL's hebben elk hun eigen limiet van 32 ACL-invoerregels. Gebruik indien mogelijk beveiligingsgroepen voor ACL-toewijzingen. Door groepen te gebruiken, is de kans kleiner dat u het maximum aantal ACL-vermeldingen per bestand of map overschrijdt.

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

Zie ook