Share via

Toegangsbeheer in Azure Data Lake Storage Gen1

  • Artikel

Azure Data Lake Storage Gen1 implementeert een model voor toegangsbeheer dat is afgeleid van HDFS, dat op zijn beurt is afgeleid van het POSIX-model voor toegangsbeheer. Dit artikel bevat een overzicht van de basisbeginselen van het model voor toegangsbeheer 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 beheren de toegang tot een object. Bestanden en mappen hebben Toegangs-ACL's.

  • Standaard-ACL's: een 'sjabloon' van ACL's die zijn gekoppeld aan een map die de Toegangs-ACL's bepaalt voor alle onderliggende items die zijn gemaakt onder die map. Bestanden hebben geen Standaard-ACL's.

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

Notitie

Als u de Standaard-ACL voor een bovenliggend item wijzigt, heeft dit geen invloed op de Toegangs-ACL of de Standaard ACL van bestaande onderliggende items.

Machtigingen

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

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

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

Machtigingen worden niet overgenomen

In het POSIX-model dat door Data Lake Storage Gen1 wordt gebruikt, worden machtigingen voor een item opgeslagen voor het item zelf. Machtigingen voor een item kunnen dus niet worden overgenomen van de bovenliggende items.

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

Bewerking Object / 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 ---
Maken Data.txt --X --X -WX ---
Lijst / R-X --- --- ---
Lijst /Seattle/ --X R-X --- ---
Lijst /Seattle/Portland/ --X --X R-X ---

Notitie

Schrijfmachtigingen zijn niet vereist voor het verwijderen van het bestand als aan de eerder genoemde twee voorwaarden wordt voldaan.

Gebruikers en identiteiten

Alle bestanden en mappen beschikken over verschillende machtigingen voor de volgende identiteiten:

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

De identiteiten van gebruikers en groepen worden Microsoft Entra identiteiten. Tenzij anders vermeld, kan een 'gebruiker' in de context van Data Lake Storage Gen1 dus 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 LSU-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 Van eigenaar 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 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 van een bestand of map is 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'. De gebruiker 'alice' kan bijvoorbeeld tot de groep 'financiën' behoren. Els kan behoren tot meerdere groepen, maar één groep is altijd ingesteld als haar hoofdgroep. Wanneer Alice in POSIX een bestand maakt, wordt de groep die eigenaar is van dat bestand ingesteld op haar primaire groep, in dit geval 'financiën'. 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.

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

  • Voorbeeld 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 guid zonder nul. Deze waarde staat geen toegang toe. Het is een tijdelijke aanduiding totdat een groep wordt toegewezen.
  • Voorbeeld 2 (alle andere gevallen): wanneer een nieuw item wordt gemaakt, wordt de groep die eigenaar is, gekopieerd van 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.

Notitie

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

Voor accounts die op of vóór september 2018 zijn gemaakt, 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. Eén gebruikersaccount is niet geldig voor het verlenen van machtigingen via de groep die eigenaar is. Daarom worden er geen machtigingen verleend door deze standaardinstelling. 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 geïllustreerd in het algoritme voor toegangscontrole, beperkt het masker de toegang voor benoemde gebruikers, de groep die eigenaar is en benoemde groepen.

Notitie

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 vergrendelde bit is een geavanceerdere functie van een POSIX-bestandssysteem. In de context van Data Lake Storage Gen1 is het onwaarschijnlijk dat de plakbit nodig is. Kortom, als de plakbit is ingeschakeld voor een map, kan een onderliggend item alleen worden verwijderd of hernoemd door de gebruiker die eigenaar is van het onderliggende item.

De vergrendelde bit wordt niet weergegeven in Azure Portal.

Standaardmachtigingen voor nieuwe bestanden en mappen

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

  • De Standaard-ACL en Toegangs-ACL voor een onderliggende map.
  • De Toegangs-ACL van een onderliggend bestand (bestanden beschikken niet over een Standaard-ACL).

umask

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

De umask voor Azure Data Lake Storage Gen1 is 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 het bovenliggende item naar de toegangs-ACL van het kind
umask.owning_group 0 --- Voor de groep die eigenaar is, kopieert u de standaard-ACL van het bovenliggende item naar de toegangs-ACL van het onderliggende kind
umask.overig 7 RWX Verwijder voor andere alle machtigingen voor de toegangs-ACL van het kind

De umask-waarde die door Azure Data Lake Storage Gen1 wordt gebruikt, betekent in feite dat de waarde voor andere nooit standaard wordt verzonden op nieuwe onderliggende items, 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 voor het recursief verwijderen van een map en de inhoud ervan?

  • De bovenliggende map moet de machtigingen Schrijven + Uitvoeren hebben.
  • De map die wordt verwijderd en elke map daarin moeten de machtigingen Lezen + Schrijven + Uitvoeren hebben.

Notitie

U hebt geen schrijfmachtigingen nodig voor het verwijderen van bestanden in mappen. 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.

Welke groep wordt ingesteld als eigenaar van een bestand of map bij het maken ervan?

De groep 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 de LSU-machtigingen die ik nodig heb niet. 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 zie ik GUID's. Hoe kan dat?

Vermeldingen in de ACL's worden opgeslagen als GUID's die overeenkomen met gebruikers in Microsoft Entra ID. De API's geven de GUID's als zodanig weer. We proberen ACL's in Azure Portal eenvoudiger in gebruik te maken door de GUID's wanneer mogelijk om te zetten 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 bij het gebruik van de service-principal gebruiken om ACL's in te stellen?

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

Ondersteunt Data Lake Storage Gen1 overname van ACL's?

Nee, maar Standaard ACL's kunnen worden gebruikt voor het instellen van ACL's voor onderliggende bestanden en mappen die nieuw zijn gemaakt onder de bovenliggende map.

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

Per bestand en per map kunnen 32 ACL's worden ingesteld. Toegang en standaard-ACL's hebben elk hun invoerlimiet van 32 ACL's. 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