Åtkomstkontroll i Azure Data Lake Storage Gen1

Artikel
03/26/2018

Azure Data Lake Storage Gen1 implementerar en åtkomstkontrollmodell som härleds från HDFS, som i sin tur härleds från POSIX-åtkomstkontrollmodellen. Den här artikeln sammanfattar grunderna i åtkomstkontrollmodellen för Data Lake Storage Gen1.

Åtkomstkontrollistor för filer och mappar

Det finns två sorters åtkomstkontrollistor (ACL:er), Åtkomst-ACL:er och Standard-ACL:er.

Åtkomst-ACL:er: De här kontrollerar åtkomst till ett objekt. Både filer och mappar har åtkomst-ACL:er.
Standard-ACL: En "mall" av ACL:er som är associerad med en mapp som bestämmer åtkomst-ACL:er för underordnade objekt som skapats under mappen. Filer har inte standard-ACL:er.

Både åtkomst-ACL:er och standard-ACL:er har samma struktur.

Anteckning

Att ändra standard-ACL på ett överordnat objekt påverkar inte åtkomst-ACL eller standard-ACL för underordnade objekt som redan finns.

Behörigheter

Behörigheter för ett objekt i filsystemet är Läsa, Skriva och Köra och de kan användas för filer och mappar som visas i tabellen nedan:

	Fil	Mapp
Läsa (R)	Kan läsa innehållet i en fil	Kräver Läsa och Köra för att visa innehållet i mappen
Skriva (W)	Kan skriva eller lägg till i en fil	Kräver Skriva och Köra för att skapa underordnade objekt i en mapp
Köra (X)	Betyder ingenting i samband med Data Lake Storage Gen1	Krävs för att bläddra bland de underordnade objekten i en mapp

Kortformat för behörigheter

RWXanvänds för att ange läsa + skriva + köra. Ett numeriskt mer komprimerat format finns där Läsa = 4, skriva = 2 och Köra = 1 och deras summa representerar behörigheterna. Här följer några exempel.

Numeriskt format	Kortformat	Vad det innebär
7	`RWX`	Läsa + skriva + köra
5	`R-X`	Läsa + köra
4	`R--`	Läsa
0	`---`	Inga behörigheter

Behörigheter ärvs inte

I POSIX-modellen som används av Data Lake Storage Gen1 lagras behörigheter för ett objekt på själva objektet. Behörigheter för ett objekt kan med andra ord inte ärvas från de överordnade objekten.

Nedan följer några vanliga scenarier som hjälper dig att förstå vilka behörigheter som krävs för att utföra vissa åtgärder på ett Data Lake Storage Gen1 konto.

Åtgärd	Objekt	/	Seattle/	Portland/	Data.txt
Läsa	Data.txt	`--X`	`--X`	`--X`	`R--`
Lägg till i	Data.txt	`--X`	`--X`	`--X`	`-W-`
Ta bort	Data.txt	`--X`	`--X`	`-WX`	`---`
Skapa	Data.txt	`--X`	`--X`	`-WX`	`---`
Lista	/	`R-X`	`---`	`---`	`---`
Lista	/Seattle/	`--X`	`R-X`	`---`	`---`
Lista	/Seattle/Portland/	`--X`	`--X`	`R-X`	`---`

Anteckning

Skrivbehörigheterna för filen behövs inte att ta bort filen så länge de två villkoren ovan är sanna.

Användare och identiteter

Alla filer och mappar har olika behörigheter för dessa identiteter:

Ägande användare
Ägande grupp
Namngivna användare
Namngivna grupper
Alla andra användare

Identiteterna för användare och grupper är Microsoft Entra identiteter. Så om inget annat anges kan en "användare" i kontexten för Data Lake Storage Gen1 antingen betyda en Microsoft Entra användare eller en Microsoft Entra säkerhetsgrupp.

Superanvändaren

En superanvändare har flest rättigheter för alla användare i Data Lake Storage Gen1-kontot. En superanvändare:

Har RWX-behörigheter till alla filer och mappar.
Kan ändra behörigheterna för alla filer och mappar.
Kan ändra ägande användare eller ägande grupp för alla filer och mappar.

Alla användare som ingår i rollen Ägare för ett Data Lake Storage Gen1-konto är automatiskt superanvändare.

Ägande användare

Användaren som skapade objektet är automatiskt ägande användare för objektet. En ägande användare kan:

Ändra behörigheterna för en fil som ägs.
Ändra ägande grupp för en fil som ägs, så länge den ägande användaren också är medlem i målgruppen.

Anteckning

Den ägande användaren kan inte ändra ägande användare för en fil eller mapp. Endast superanvändare kan ändra ägande användare av en fil eller mapp.

Ägande grupp

Bakgrund

I POSIX-ACL:er är varje användare associerad med en "primär grupp". Användaren "alice" kan till exempel tillhöra gruppen "finance". Alice kan också tillhöra flera grupper, men en grupp anges alltid som hennes primära grupp. När Alice skapar en fil i POSIX ställs den ägande gruppen för filen in på hennes primära grupp, som i det här fallet är "ekonomi". Den ägande gruppen fungerar annars på liknande sätt som tilldelade behörigheter för andra användare/grupper.

Eftersom det inte finns någon "primär grupp" som är associerad med användare i Data Lake Storage Gen1 tilldelas den ägande gruppen enligt nedan.

Tilldela ägande grupp för en ny fil eller mapp

Fall 1: Rotmappen "/". Den här mappen skapas när ett Data Lake Storage Gen1 konto skapas. I det här fallet är ägandegruppen inställd på ett helt noll-GUID. Det här värdet tillåter inte åtkomst. Det är en platshållare tills en grupp tilldelas.
Fall 2 (alla andra fall): När ett nytt objekt skapas, kopieras den ägande gruppen från den överordnade mappen.

Ändra ägande grupp

Den ägande gruppen kan ändras av:

Alla superanvändare.
Den ägande användaren, om den ägande användaren också är medlem i målgruppen.

Anteckning

Den ägande gruppen kan inte ändra ACL:er för en fil eller mapp.

För konton som skapades den 1 september 2018 eller före september 2018 angavs ägandegruppen till den användare som skapade kontot i fallet med rotmappen för ärende 1 ovan. Ett enskilt användarkonto är inte giltigt för att ge behörigheter via den ägande gruppen, vilket innebär att inga behörigheter beviljas med den här standardinställningen. Du kan tilldela den här behörigheten till en giltig användargrupp.

Algoritm för åtkomstkontroll

Följande pseudokod representerar algoritmen för åtkomstkontroll för Data Lake Storage Gen1 konton.

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)

Masken

Som du ser i algoritmen för åtkomstkontroll begränsar masken åtkomsten för namngivna användare, ägande grupp och namngivna grupper.

Anteckning

För ett nytt Data Lake Storage Gen1 konto är masken för åtkomst-ACL för rotmappen ("/") standard för RWX.

Sticky bit

Sticky bit är en mer avancerad funktion i ett POSIX-filsystem. När det gäller Data Lake Storage Gen1 är det osannolikt att den klibbiga biten kommer att behövas. Sammanfattningsvis kan ett underordnat objekt bara tas bort eller byta namn på det underordnade objektets ägande användare om den fästiga biten är aktiverad i en mapp.

Sticky bit visas inte i Azure-portalen.

Standardbehörigheter för nya filer och mappar

När en ny fil eller mapp skapas under en befintlig mapp, anger standard-ACL:en på den överordnade mappen:

En underordnad mapps standard-ACL och åtkomst-ACL.
En underordnad fils åtkomst-ACL (filer har inte en standard-ACL).

umask

När du skapar en fil eller mapp används umask för att ändra hur standard-ACL:er anges för det underordnade objektet. umask är ett 9-bitars värde på överordnade mappar som innehåller ett RWX-värde för ägande användare, ägande grupp och annat.

Umask för Azure Data Lake Storage Gen1 är ett konstant värde som anges till 007. Det här värdet översätts till

umask-komponent	Numeriskt format	Kortformat	Innebörd
umask.owning_user	0	`---`	För ägande användare kopierar du den överordnades standard-ACL till den underordnade åtkomst-ACL:en
umask.owning_group	0	`---`	För ägande grupp kopierar du den överordnades standard-ACL till den underordnade åtkomst-ACL:en
umask.other	7	`RWX`	För andra tar du bort alla behörigheter för barnets åtkomst-ACL

Umask-värdet som används av Azure Data Lake Storage Gen1 innebär effektivt att värdet för andra aldrig överförs som standard på nya underordnade – oavsett vad standard-ACL anger.

Följande pseudokod visar hur umask används när du skapar ACL:er för ett underordnat objekt.

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 )

Vanliga frågor om ACL:er i Data Lake Storage Gen1

Måste jag aktivera stöd för ACL:er?

Nej. Åtkomstkontroll via ACL:er är alltid aktiverat för ett Data Lake Storage Gen1 konto.

Vilka behörigheter krävs för att rekursivt ta bort en mapp och dess innehåll?

Den överordnade mappen måste ha behörigheterna skriva + köra.
Mappen som ska tas bort och alla mappar inom den, behöver behörigheterna läsa + skriva + köra.

Anteckning

Du behöver inte Skriv-behörigheter för att ta bort filer i mappar. Dessutom kan rotmappen "/" aldrig tas bort.

Vem äger en fil eller mapp?

Skaparen av en fil eller mapp blir ägaren.

Vilken grupp anges som den ägande gruppen för en fil eller mapp vid skapandet?

Det kopieras från den ägande gruppen för den överordnade mappen under vilken den nya filen eller mappen skapas.

Jag är ägande användare av en fil, men jag har inte den RWX-behörighet jag behöver. Vad gör jag nu?

Den ägande användaren kan lätt ändra behörigheterna för filen för att ge sig själva de RWX-behörigheter de behöver.

När jag tittar på ACL:er i Azure-portalen, visas användarnamn men via API:er visas GUID:er. Varför?

Poster i ACL:erna lagras som GUID:er som motsvarar användare i Microsoft Entra ID. API:erna returnerar GUID:erna i befintligt skick. Azure-portalen försöker göra det enklare att använda ACL:er genom att översätta GUID:er till bekanta namn när det är möjligt.

Varför visas ibland GUID:er i ACL:er när jag använder Azure-portalen?

Ett GUID visas när användaren inte längre finns i Microsoft Entra. Detta inträffar vanligtvis när användaren har lämnat företaget eller om deras konto har tagits bort i Microsoft Entra ID. Kontrollera också att du använder rätt ID för att ange ACL:er (information i fråga nedan).

Vilket ID ska jag använda för att ange ACL:er när jag använder tjänstens huvudnamn?

På Azure-portalen går du till Microsoft Entra ID –> Företagsprogram och väljer ditt program. Fliken Översikt bör visa ett objekt-ID och detta är vad som ska användas när du lägger till ACL:er för dataåtkomst (och inte program-ID).

Stöder Data Lake Storage Gen1 arv av ACL:er?

Nej, men standard-ACL:er kan användas för att ange ACL:er för underordnade filer och mappar som nyligen skapats under den överordnade mappen.

Vilka är gränserna för ACL-poster för filer och mappar?

32 ACL:er kan anges per fil och per katalog. Åtkomst- och standard-ACL:er har varsin gräns på 32 ACL. Använd säkerhetsgrupper för ACL-tilldelningar om det är möjligt. Med hjälp av grupper är det mindre troligt att du överskrider det maximala antalet ACL-poster per fil eller katalog.

Var hittar jag mer information om POSIX-modellen för åtkomstkontroll?

Se även

Översikt över Azure Data Lake Storage Gen1

Dela via

Åtkomstkontroll i Azure Data Lake Storage Gen1

Åtkomstkontrollistor för filer och mappar

Behörigheter

Kortformat för behörigheter

Behörigheter ärvs inte

Användare och identiteter

Superanvändaren

Ägande användare

Ägande grupp

Algoritm för åtkomstkontroll

Masken

Sticky bit

Standardbehörigheter för nya filer och mappar

umask

Vanliga frågor om ACL:er i Data Lake Storage Gen1

Måste jag aktivera stöd för ACL:er?

Vilka behörigheter krävs för att rekursivt ta bort en mapp och dess innehåll?

Vem äger en fil eller mapp?

Vilken grupp anges som den ägande gruppen för en fil eller mapp vid skapandet?

Jag är ägande användare av en fil, men jag har inte den RWX-behörighet jag behöver. Vad gör jag nu?

När jag tittar på ACL:er i Azure-portalen, visas användarnamn men via API:er visas GUID:er. Varför?

Varför visas ibland GUID:er i ACL:er när jag använder Azure-portalen?

Vilket ID ska jag använda för att ange ACL:er när jag använder tjänstens huvudnamn?

Stöder Data Lake Storage Gen1 arv av ACL:er?

Vilka är gränserna för ACL-poster för filer och mappar?

Var hittar jag mer information om POSIX-modellen för åtkomstkontroll?

Se även

Ytterligare resurser

Dela via

Åtkomstkontroll i Azure Data Lake Storage Gen1

Åtkomstkontrollistor för filer och mappar

Behörigheter

Kortformat för behörigheter

Behörigheter ärvs inte

Vanliga scenarier som rör behörigheter

Användare och identiteter

Superanvändaren

Ägande användare

Ägande grupp

Algoritm för åtkomstkontroll

Masken

Sticky bit

Standardbehörigheter för nya filer och mappar

umask

Vanliga frågor om ACL:er i Data Lake Storage Gen1

Måste jag aktivera stöd för ACL:er?

Vilka behörigheter krävs för att rekursivt ta bort en mapp och dess innehåll?

Vem äger en fil eller mapp?

Vilken grupp anges som den ägande gruppen för en fil eller mapp vid skapandet?

Jag är ägande användare av en fil, men jag har inte den RWX-behörighet jag behöver. Vad gör jag nu?

När jag tittar på ACL:er i Azure-portalen, visas användarnamn men via API:er visas GUID:er. Varför?

Varför visas ibland GUID:er i ACL:er när jag använder Azure-portalen?

Vilket ID ska jag använda för att ange ACL:er när jag använder tjänstens huvudnamn?

Stöder Data Lake Storage Gen1 arv av ACL:er?

Vilka är gränserna för ACL-poster för filer och mappar?

Var hittar jag mer information om POSIX-modellen för åtkomstkontroll?

Se även

Ytterligare resurser