Åtkomstkontrollistor (ACL: er) i Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 implementerar en åtkomstkontrollmodell som stöder både rollbaserad åtkomstkontroll i Azure (Azure RBAC) och POSIX-liknande åtkomstkontrollistor (ACL:er). I den här artikeln beskrivs åtkomstkontrolllistor i Data Lake Storage Gen2. Mer information om hur du införlivar Azure RBAC tillsammans med ACL:er och hur systemet utvärderar dem för att fatta auktoriseringsbeslut finns i Access Control Model in Azure Data Lake Storage Gen2 (Åtkomstkontrollmodell i Azure Data Lake Storage Gen2).

Om ACL:er

Du kan associera ett säkerhetsobjekt med en åtkomstnivå för filer och kataloger. Varje association avbildas som en post i en åtkomstkontrollista (ACL). Varje fil och katalog i ditt lagringskonto har en åtkomstkontrolllista. När ett säkerhetsobjekt försöker utföra en åtgärd på en fil eller katalog avgör en ACL-kontroll om säkerhetsobjekt (användare, grupp, tjänstens huvudnamn eller hanterad identitet) har rätt behörighetsnivå för att utföra åtgärden.

Så här anger du ACL:er

Information om hur du anger behörigheter på fil- och katalognivå finns i någon av följande artiklar:

Typer av ACL:er

Det finns två typer av åtkomstkontrollistor: åtkomst-ACL:er och standard-ACL:er.

Åtkomst-ACL:er kontrollerar åtkomst till ett objekt. Filer och kataloger har båda åtkomst-ACL:er.

Standard-ACL:er är mallar för ACL:er som är associerade med en katalog som bestämmer åtkomst-ACL:er för underordnade objekt som skapas under den katalogen. Filer har inte standard-ACL:er.

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

Behörighetsnivåer

Behörigheterna för kataloger och filer i en container är Läsa, Skriva och Köra, och de kan användas för filer och kataloger enligt följande tabell:

Kortformat för behörigheter

RWX anvä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.

Arv av behörigheter

I POSIX-modellen som används av Data Lake Storage Gen2 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 om behörigheterna anges efter att det underordnade objektet redan har skapats. Behörigheter ärvs endast om standardbehörigheter har angetts för de överordnade objekten innan de underordnade objekten har skapats.

Vanliga scenarier som rör ACL-behörigheter

I följande tabell visas de ACL-poster som krävs för att aktivera ett säkerhetsobjekt för att utföra de åtgärder som anges i kolumnen Åtgärd.

Den här tabellen visar en kolumn som representerar varje nivå i en fiktiv kataloghierarki. Det finns en kolumn för rotkatalogen för containern ( ), en underkatalog med namnet Oregon , en underkatalog i katalogen Oregon med namnet Portland och en textfil i katalogen Portland med / namnetData.txt.

Användare och identiteter

Varje fil och katalog har olika behörigheter för dessa identiteter:

• Ägande användare
• Ägande grupp
• Namngivna användare
• Namngivna grupper
• Namngivna tjänsthuvudnamn
• Namngivna hanterade identiteter
• Alla andra användare

Identiteten för användare och grupper är Azure Active Directory (Azure AD)-identiteter. Om inget annat anges kan en användare i samband med Data Lake Storage Gen2 referera till en Azure AD-användare, tjänstens huvudnamn, hanterad identitet eller säkerhetsgrupp.

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

Ägande grupp

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

Tilldela den äga gruppen för en ny fil eller katalog

• Fall 1: Rotkatalogen / . Den här katalogen skapas när en Data Lake Storage Gen2-container skapas. I det här fallet är den ägande gruppen inställd på den användare som skapade containern om den gjordes med hjälp av OAuth. Om containern skapas med hjälp av delad nyckel, en konto-SAS eller en tjänst-SAS ställs ägaren och den ägarande gruppen in på $superuser .
• Fall 2 (vart annat fall): När ett nytt objekt skapas kopieras den äga gruppen från den överordnade katalogen.

Ändra den äga gruppen

Den ägande gruppen kan ändras av:

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

Så här utvärderas behörigheter

Identiteter utvärderas i följande ordning:

1. Superanvändare
2. Ägande användare
3. Namngiven användare, tjänstens huvudnamn eller hanterad identitet
4. Äga grupp eller namngiven grupp
5. Alla andra användare

Om fler än en av dessa identiteter gäller för ett säkerhetsobjekt beviljas behörighetsnivån som är associerad med den första identiteten. Om ett säkerhetsobjekt till exempel är både den ägande användaren och en namngiven användare gäller behörighetsnivån som är associerad med den äger användaren.

Följande pseudokod representerar algoritmen för åtkomstkontroll för lagringskonton. Den här algoritmen visar i vilken ordning identiteter utvärderas.

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)

Masken

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

För en ny Data Lake Storage Gen2-container är masken för åtkomst-ACL för rotkatalogen ("/") standardvärdet 750 för kataloger och 640 för filer. I följande tabell visas den symboliska notationen för dessa behörighetsnivåer.

Filerna tar inte emot X-bitars eftersom det är irrelevant för filer i ett system med endast arkivet.

Masken kan anges per anrop. Detta gör att olika användningssystem, till exempel kluster, kan ha olika effektiva masker för sina filåtgärder. Om en mask anges för en viss begäran åsidosätter den helt standardmasken.

Sticky bit

Sticky bit är en mer avancerad funktion i en POSIX-container. När det gäller Data Lake Storage Gen2 är det osannolikt att sticky bit kommer att behövas. Sammanfattningsvis, om sticky bit är aktiverat på en katalog, kan ett underobjekt bara tas bort eller byta namn på det underordnade objektets äger användare.

Sticky bit visas inte i Azure Portal.

Standardbehörigheter för nya filer och kataloger

När en ny fil eller katalog skapas under en befintlig katalog avgör standard-ACL på den överordnade katalogen:

• En underordnad katalogs standard-ACL och åtkomst-ACL.
• En underordnad fils åtkomst-ACL (filerna har ingen standard-ACL).

umask

När du skapar en fil eller katalog 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 kataloger som innehåller ett RWX-värde för att äga användare, äga grupp och andra.

Umask för Azure Data Lake Storage Gen2 ett konstant värde som är inställt på 007. Det här värdet översätts till:

Umask-värdet som används av Azure Data Lake Storage Gen2 innebär i praktiken att värdet för andra aldrig överförs som standard på nya underordnade objekt, såvida inte en standard-ACL har definierats för den överordnade katalogen. I så fall ignoreras umask och de behörigheter som definieras av standard-ACL:en tillämpas på det underordnade objektet.

Följande pseudokod visar hur umask tillämpas när du skapar ACL:er för ett underobjekt.

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

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

Nej. Åtkomstkontroll via ACL:er har aktiverats för ett lagringskonto så länge funktionen HNS (Hierarkisk namnrymd) är aktiverad.

Om HNS är inaktiverat gäller fortfarande Azure Azure RBAC-auktoriseringsreglerna.

Vilket är det bästa sättet att tillämpa ACL:er?

Använd alltid Azure AD-säkerhetsgrupper som det tilldelade huvudobjektet i en ACL-post. Motstå möjligheten att direkt tilldela enskilda användare eller tjänst huvud namn. Med den här strukturen kan du lägga till och ta bort användare eller tjänstens huvud namn utan att behöva tillämpa ACL: er på en hel katalog struktur. I stället kan du bara lägga till eller ta bort användare och tjänstens huvud namn från rätt Azure AD-säkerhetsgrupp.

Det finns många olika sätt att konfigurera grupper. Anta till exempel att du har en katalog med namnet /LogData som innehåller loggdata som genereras av servern. Azure Data Factory (ADF) matar in data i den mappen. Vissa användare från service teknik teamet laddar upp loggar och hanterar andra användare av den här mappen och olika Databricks-kluster kommer att analysera loggar från den mappen.

Om du vill aktivera dessa aktiviteter kan du skapa en LogsWriter grupp och en LogsReader grupp. Sedan kan du tilldela behörigheter enligt följande:

• Lägg till LogsWriter gruppen i ACL: en för /LogData -katalogen med rwx behörigheter.
• Lägg till LogsReader gruppen i ACL: en för /LogData -katalogen med r-x behörigheter.
• Lägg till tjänstens huvud objekt eller Hanterad tjänstidentitet (MSI) för ADF i LogsWriters gruppen.
• Lägg till användare i service Engineering-teamet i LogsWriter gruppen.
• Lägg till tjänstens huvud objekt eller MSI för Databricks i LogsReader gruppen.

Om en användare i service Engineering-teamet lämnar företaget kan du bara ta bort dem från LogsWriter gruppen. Om du inte har lagt till användaren i en grupp, men i stället lade till en dedikerad ACL-post för användaren, skulle du behöva ta bort ACL-posten från /LogData -katalogen. Du måste också ta bort posten från alla under kataloger och filer i hela katalogens hierarki i /LogData -katalogen.

Information om hur du skapar en grupp och lägger till medlemmar finns i skapa en grundläggande grupp och lägga till medlemmar med hjälp av Azure Active Directory.

Hur utvärderas Azure RBAC- och ACL-behörigheter?

Information om hur systemet utvärderar Azure RBAC och ACL:er tillsammans för att fatta auktoriseringsbeslut för lagringskontoresurser finns i Så här utvärderas behörigheter.

Vilka är gränserna för Azure-rolltilldelningar och ACL-poster?

Följande tabell innehåller en sammanfattning av gränserna att tänka på när du använder Azure RBAC för att hantera "grovkorniga" behörigheter (behörigheter som gäller för lagringskonton eller containrar) och användning av ACL:er för att hantera "finkorniga" behörigheter (behörigheter som gäller för filer och kataloger). Använd säkerhetsgrupper för ACL-tilldelningar. Med hjälp av grupper är det mindre troligt att du överskrider det maximala antalet rolltilldelningar per prenumeration och det maximala antalet ACL-poster per fil eller katalog.

Stöder Data Lake Storage Gen2 arv av Azure RBAC?

Azure-rolltilldelningar ärver. Tilldelningar flödar från prenumerations-, resursgrupps- och lagringskontoresurser ned till containerresursen.

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

Standard-ACL:er kan användas för att ange ACL:er för nya underordnade underkataloger och filer som skapats under den överordnade katalogen. Om du vill uppdatera ACL:er för befintliga underordnade objekt måste du lägga till, uppdatera eller ta bort ACL:er rekursivt för den önskade kataloghierarkin. Mer information finns i avsnittet Så här ställer du in ACL:er i den här artikeln.

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

• Anroparen har superanvändarbehörigheter,

Eller

• Den överordnade katalogen måste ha skriv- och körningsbehörighet.
• Den katalog som ska tas bort, och varje katalog i den, kräver läs- och skrivbehörighet + kör-behörigheter.

Vem är ägare till en fil eller katalog?

Skaparen av en fil eller katalog blir ägare. När det gäller rotkatalogen är detta identiteten för den användare som skapade containern.

Vilken grupp anges som den äga gruppen för en fil eller katalog när den skapas?

Den äga gruppen kopieras från den egna gruppen i den överordnade katalogen som den nya filen eller katalogen skapas under.

Jag äger en fil, men jag har inte de RWX-behörigheter 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.

Varför ser jag ibland GUID i ACL:er?

Ett GUID visas om posten representerar en användare och användaren inte finns i Azure AD längre. Detta inträffar vanligtvis när användaren har lämnat företaget eller om kontot har tagits bort i Azure AD. Dessutom har tjänstens huvudnamn och säkerhetsgrupper inget UPN (User Principal Name) för att identifiera dem och representeras därför av deras OID-attribut (ett guid).

Hur gör jag för att ange ACL:er korrekt för tjänstens huvudnamn?

När du definierar ACL:er för tjänstens huvudnamn är det viktigt att du använder objekt-ID :t (OID) för tjänstens huvudnamn för den appregistrering som du skapade. Observera att registrerade appar har ett separat tjänsthuvudnamn i den specifika Azure AD-klientorganisationen. Registrerade appar har ett OID som är synligt i Azure Portal, men tjänstens huvudnamn har en annan (annan) OID.

Om du vill hämta OID för tjänstens huvudnamn som motsvarar en appregistrering kan du använda az ad sp show kommandot . Ange Program-ID som parameter. Här är ett exempel på hur du hämtar OID för tjänstens huvudnamn som motsvarar en appregistrering med App-ID = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Kör följande kommando i Azure CLI:

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

OID visas.

När du har rätt OID för tjänstens huvudnamn går du till sidan Storage Explorer Hantera åtkomst för att lägga till OID:en och tilldela lämpliga behörigheter för OID:t. Se till att du väljer Spara.

Kan jag ange ACL för en container?

Nej. En container har ingen ACL. Du kan dock ange ACL för containerns rotkatalog. Varje container har en rotkatalog och delar samma namn som containern. Om containern till exempel heter my-container heter rotkatalogen my-container/ .

Den Azure Storage REST API innehåller en åtgärd med namnet Set Container ACL, men den åtgärden kan inte användas för att ange ACL för en container eller rotkatalogen för en container. I stället används åtgärden för att ange om blobar i en container kan nås offentligt.

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

• POSIX-åtkomstkontrollistor på Linux
• Guide för HDFS-behörighet
• Vanliga frågor och svar om POSIX
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• POSIX ACL på Ubuntu
• ACL med åtkomstkontrollistor på Linux

Se även

• Modellen för åtkomstkontroll i Azure Data Lake Storage Gen2