Åtkomst kontrol listor (ACL: er) i Azure Data Lake Storage Gen2Access control lists (ACLs) in Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 implementerar en modell för åtkomst kontroll som stöder både Azure-rollbaserad åtkomst kontroll (Azure RBAC) och POSIX-liknande åtkomst kontrol listor (ACL: er).Azure Data Lake Storage Gen2 implements an access control model that supports both Azure role-based access control (Azure RBAC) and POSIX-like access control lists (ACLs). I den här artikeln beskrivs åtkomst kontrol listor i Data Lake Storage Gen2.This article describes access control lists in 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 åtkomst kontroll modell i Azure Data Lake Storage Gen2.To learn about how to incorporate Azure RBAC together with ACLs, and how system evaluates them to make authorization decisions, see Access control model in Azure Data Lake Storage Gen2.

Om ACL: erAbout ACLs

Du kan associera ett säkerhets objekt med en åtkomst nivå för filer och kataloger.You can associate a security principal with an access level for files and directories. Dessa associationer samlas in i en åtkomst kontrol lista (ACL).These associations are captured in an access control list (ACL). Varje fil och katalog i ditt lagrings konto har en åtkomst kontrol lista.Each file and directory in your storage account has an access control list. När ett säkerhets objekt försöker utföra en åtgärd på en fil eller katalog, avgör en ACL-kontroll om säkerhets objekt (användare, grupp, tjänstens huvud namn eller hanterad identitet) har rätt behörighets nivå för att utföra åtgärden.When a security principal attempts an operation on a file or directory, An ACL check determines whether that security principal (user, group, service principal, or managed identity) has the correct permission level to perform the operation.

Anteckning

ACL: er gäller endast för säkerhets objekt i samma klient organisation, och de gäller inte för användare som använder delad nyckel eller autentisering med signatur för delad åtkomst (SAS).ACLs apply only to security principals in the same tenant, and they don't apply to users who use Shared Key or shared access signature (SAS) token authentication. Det beror på att ingen identitet är kopplad till anroparen och därför inte behörigheten för säkerhets objekts behörighet kan inte utföras.That's because no identity is associated with the caller and therefore security principal permission-based authorization cannot be performed.

Ange ACL: erHow to set ACLs

Om du vill ange behörigheter för fil-och katalog nivå kan du läsa följande artiklar:To set file and directory level permissions, see any of the following articles:

MiljöEnvironment ArtikelArticle
Azure LagringsutforskarenAzure Storage Explorer Använda Azure Storage Explorer till att hantera kataloger, filer och åtkomstkontrollistor i Azure Data Lake Storage Gen2Use Azure Storage Explorer to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
.NET.NET Använd .NET för att hantera kataloger, filer och ACL: er i Azure Data Lake Storage Gen2Use .NET to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
JavaJava Använd Java för att hantera kataloger, filer och ACL: er i Azure Data Lake Storage Gen2Use Java to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
PythonPython Använd python för att hantera kataloger, filer och ACL: er i Azure Data Lake Storage Gen2Use Python to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
PowerShellPowerShell Använd PowerShell för att hantera kataloger, filer och ACL: er i Azure Data Lake Storage Gen2Use PowerShell to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
Azure CLIAzure CLI Använd Azure CLI för att hantera kataloger, filer och ACL: er i Azure Data Lake Storage Gen2Use Azure CLI to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
REST-APIREST API Sökväg – uppdateraPath - Update

Viktigt

Om säkerhetsobjektet är ett huvud namn för tjänsten är det viktigt att använda objekt-ID: t för tjänstens huvud namn och inte objekt-ID: t för den relaterade appens registrering.If the security principal is a service principal, it's important to use the object ID of the service principal and not the object ID of the related app registration. För att hämta objekt-ID: t för tjänstens huvud namn öppnar du Azure CLI och använder sedan det här kommandot: az ad sp show --id <Your App ID> --query objectId .To get the object ID of the service principal open the Azure CLI, and then use this command: az ad sp show --id <Your App ID> --query objectId. Se till att ersätta <Your App ID> plats hållaren med app-ID: t för din app Registration.make sure to replace the <Your App ID> placeholder with the App ID of your app registration.

Typer av ACL: erTypes of ACLs

Det finns två typer av åtkomst kontrol listor: åtkomst-ACL : er och standard-ACL: er.There are two kinds of access control lists: access ACLs and default ACLs.

Åtkomst-ACL:er kontrollerar åtkomst till ett objekt.Access ACLs control access to an object. Filer och kataloger har båda åtkomst-ACL:er.Files and directories both have access ACLs.

Standard-ACL: er är mallar för ACL: er som är kopplade till en katalog som fastställer åtkomst-ACL: er för underordnade objekt som skapas under den katalogen.Default ACLs are templates of ACLs associated with a directory that determine the access ACLs for any child items that are created under that directory. Filer har inte standard-ACL:er.Files do not have default ACLs.

Både åtkomst-ACL: er och standard-ACL: er har samma struktur.Both access ACLs and default ACLs have the same structure.

Anteckning

Att ändra standard-ACL: en på en överordnad påverkar inte åtkomst-ACL: en eller standard-ACL för underordnade objekt som redan finns.Changing the default ACL on a parent does not affect the access ACL or default ACL of child items that already exist.

Behörighets nivåerLevels of permission

Behörigheterna för ett behållar objekt är läsa, skriva och köra och de kan användas på filer och kataloger som visas i följande tabell:The permissions on a container object are Read, Write, and Execute, and they can be used on files and directories as shown in the following table:

FilFile KatalogDirectory
Läsa (R)Read (R) Kan läsa innehållet i en filCan read the contents of a file Kräver läsa och köra för att visa innehållet i katalogenRequires Read and Execute to list the contents of the directory
Skriva (W)Write (W) Kan skriva eller lägg till i en filCan write or append to a file Kräver skriva och köra för att skapa underordnade objekt i en katalogRequires Write and Execute to create child items in a directory
Köra (X)Execute (X) Betyder inte något i samband med Data Lake Storage Gen2Does not mean anything in the context of Data Lake Storage Gen2 Krävs för att bläddra bland de underordnade objekten i en katalogRequired to traverse the child items of a directory

Anteckning

Om du beviljar behörigheter genom att endast använda ACL: er (ingen Azure RBAC), så måste du ge säkerhets objektets Kör -behörigheter till behållaren och till varje mapp i hierarkin för mappar som leder till filen.If you are granting permissions by using only ACLs (no Azure RBAC), then to grant a security principal read or write access to a file, you'll need to give the security principal Execute permissions to the container, and to each folder in the hierarchy of folders that lead to the file.

Kortformat för behörigheterShort forms for permissions

RWX används för att ange läsa + skriva + köra.RWX is used to indicate Read + Write + Execute. Ett numeriskt mer komprimerat format finns där Läsa = 4, skriva = 2 och Köra = 1 och deras summa representerar behörigheterna.A more condensed numeric form exists in which Read=4, Write=2, and Execute=1, the sum of which represents the permissions. Här följer några exempel.Following are some examples.

Numeriskt formatNumeric form KortformatShort form Vad det innebärWhat it means
77 RWX Läsa + skriva + köraRead + Write + Execute
55 R-X Läsa + köraRead + Execute
44 R-- LäsRead
00 --- Inga behörigheterNo permissions

Arv av behörigheterPermissions inheritance

I POSIX-format modellen som används av Data Lake Storage Gen2 lagras behörigheter för ett objekt i själva objektet.In the POSIX-style model that's used by Data Lake Storage Gen2, permissions for an item are stored on the item itself. Med andra ord kan inte behörigheter för ett objekt ärvas från de överordnade objekten om behörigheterna anges efter att det underordnade objektet redan har skapats.In other words, permissions for an item cannot be inherited from the parent items if the permissions are set after the child item has already been created. Behörigheter ärvs bara om standard behörigheter har angetts för de överordnade objekten innan de underordnade objekten har skapats.Permissions are only inherited if default permissions have been set on the parent items before the child items have been created.

I följande tabell visas de ACL-poster som krävs för att aktivera ett säkerhets objekt för att utföra de åtgärder som anges i kolumnen operation .The following table shows you the ACL entries required to enable a security principal to perform the operations listed in the Operation column.

I den här tabellen visas en kolumn som representerar varje nivå i en fiktiv katalog-hierarki.This table shows a column that represents each level of a fictitious directory hierarchy. Det finns en kolumn för behållarens rot Katalog ( \ ), en under katalog med namnet " Oregon Göteborg", en under katalog till katalogen Göteborg, som heter Göteborg och en textfil i katalogen Göteborg med namnet Data.txt.There's a column for the root directory of the container (\), a subdirectory named Oregon, a subdirectory of the Oregon directory named Portland, and a text file in the Portland directory named Data.txt.

Viktigt

Den här tabellen förutsätter att du bara använder ACL: er utan några Azure Role-tilldelningar.This table assumes that you are using only ACLs without any Azure role assignments. Om du vill se en liknande tabell som kombinerar Azure RBAC tillsammans med ACL: er, se behörighets tabell: kombinera Azure RBAC och ACL.To see a similar table that combines Azure RBAC together with ACLs, see Permissions table: Combining Azure RBAC and ACL.

ÅtgärdOperation / OregonOregon/ PortlandPortland/ Data.txtData.txt
Läs Data.txtRead Data.txt --X --X --X R--
Lägg till i Data.txtAppend to Data.txt --X --X --X RW-
Ta bort Data.txtDelete Data.txt --X --X -WX ---
Skapa Data.txtCreate Data.txt --X --X -WX ---
ListaList / R-X --- --- ---
Visa lista/Oregon/List /Oregon/ --X R-X --- ---
Visa lista/Oregon/Portland/List /Oregon/Portland/ --X --X R-X ---

Anteckning

Skriv behörighet för filen krävs inte för att ta bort den, så länge som de föregående två villkoren är sanna.Write permissions on the file are not required to delete it, so long as the previous two conditions are true.

Användare och identiteterUsers and identities

Varje fil och katalog har distinkta behörigheter för dessa identiteter:Every file and directory has distinct permissions for these identities:

  • Ägande användareThe owning user
  • Ägande gruppThe owning group
  • Namngivna användareNamed users
  • Namngivna grupperNamed groups
  • Namngivna tjänstens huvud namnNamed service principals
  • Namngivna hanterade identiteterNamed managed identities
  • Alla andra användareAll other users

Identiteten för användare och grupper är Azure Active Directory (Azure AD)-identiteter.The identities of users and groups are Azure Active Directory (Azure AD) identities. Så om inget annat anges kan en användare, i kontexten för data Lake Storage Gen2, referera till en Azure AD-användare, tjänstens huvud namn, en hanterad identitet eller säkerhets grupp.So unless otherwise noted, a user, in the context of Data Lake Storage Gen2, can refer to an Azure AD user, service principal, managed identity, or security group.

Ägande användareThe owning user

Användaren som skapade objektet är automatiskt ägande användare för objektet.The user who created the item is automatically the owning user of the item. En ägande användare kan:An owning user can:

  • Ändra behörigheterna för en fil som ägs.Change the permissions of a file that is owned.
  • Ändra ägande grupp för en fil som ägs, så länge den ägande användaren också är medlem i målgruppen.Change the owning group of a file that is owned, as long as the owning user is also a member of the target group.

Anteckning

Den ägande användaren kan inte ändra ägande användare av en fil eller katalog.The owning user cannot change the owning user of a file or directory. Endast Super-användare kan ändra ägande användare av en fil eller katalog.Only super-users can change the owning user of a file or directory.

Ägande gruppThe owning group

I POSIX-ACL: erna är alla användare kopplade till en primär grupp.In the POSIX ACLs, every user is associated with a primary group. Användaren "Alice" kan t. ex. tillhöra gruppen "ekonomi".For example, user "Alice" might belong to the "finance" group. Alice kan också tillhöra flera grupper, men en grupp anges alltid som sin primära grupp.Alice might also belong to multiple groups, but one group is always designated as their primary group. 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".In POSIX, when Alice creates a file, the owning group of that file is set to her primary group, which in this case is "finance." Den ägande gruppen fungerar annars ungefär som tilldelade behörigheter för andra användare/grupper.The owning group otherwise behaves similarly to assigned permissions for other users/groups.

Tilldela ägande grupp för en ny fil eller katalogAssigning the owning group for a new file or directory

  • Fall 1: rot katalogen "/".Case 1: The root directory "/". Den här katalogen skapas när en Data Lake Storage Gen2-behållare skapas.This directory is created when a Data Lake Storage Gen2 container is created. I det här fallet anges den ägande gruppen till den användare som skapade behållaren om den gjordes med OAuth.In this case, the owning group is set to the user who created the container if it was done using OAuth. Om behållaren har skapats med hjälp av delad nyckel, en konto säkerhets Association eller en tjänst-SAS, är ägaren och ägande gruppen inställt på $superuser.If the container is created using Shared Key, an Account SAS, or a Service SAS, then the owner and owning group are set to $superuser.
  • Fall 2 (alla andra fall): när ett nytt objekt skapas, kopieras den ägande gruppen från den överordnade katalogen.Case 2 (Every other case): When a new item is created, the owning group is copied from the parent directory.

Ändra den ägande gruppenChanging the owning group

Den ägande gruppen kan ändras av:The owning group can be changed by:

  • Alla superanvändare.Any super-users.
  • Den ägande användaren, om den ägande användaren också är medlem i målgruppen.The owning user, if the owning user is also a member of the target group.

Anteckning

Den ägande gruppen kan inte ändra ACL: er för en fil eller katalog.The owning group cannot change the ACLs of a file or directory. Även om den ägande gruppen har angetts till den användare som skapade kontot i fallet för rot katalogen, fall 1 ovan, är ett enskilt användar konto inte giltigt för att ge behörighet via den ägande gruppen.While the owning group is set to the user who created the account in the case of the root directory, Case 1 above, a single user account isn't valid for providing permissions via the owning group. Du kan tilldela den här behörigheten till en giltig användargrupp, om det är lämpligt.You can assign this permission to a valid user group if applicable.

Algoritm för åtkomstkontrollAccess check algorithm

Följande pseudocode representerar algoritmen för åtkomst kontroll för lagrings konton.The following pseudocode represents the access check algorithm for storage 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 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)

MaskenThe mask

Som illustreras i algoritmen för åtkomst kontroll begränsar masken åtkomsten för namngivna användare, ägande grupp och namngivna grupper.As illustrated in the Access Check Algorithm, the mask limits access for named users, the owning group, and named groups.

För en ny Data Lake Storage Gen2-behållare är masken för åtkomst-ACL: en för rot katalogen ("/") standardvärdet 750 för kataloger och 640 för filer.For a new Data Lake Storage Gen2 container, the mask for the access ACL of the root directory ("/") defaults to 750 for directories and 640 for files. I följande tabell visas den symboliska notationen för dessa behörighets nivåer.The following table shows the symbolic notation of these permission levels.

EntitetEntity KatalogerDirectories FilesFiles
Ägande användareOwning user rwx r-w
Ägande gruppOwning group r-x r--
AnnatOther --- ---

Filerna tar inte emot X-biten eftersom det är irrelevant för filer i ett system för endast lagring.Files do not receive the X bit as it is irrelevant to files in a store-only system.

Masken kan anges per anrop.The mask may be specified on a per-call basis. Detta gör att olika användnings system, till exempel kluster, har olika effektiva masker för deras fil åtgärder.This allows different consuming systems, such as clusters, to have different effective masks for their file operations. Om en mask anges för en viss begäran, åsidosätter den fullständigt standard masken.If a mask is specified on a given request, it completely overrides the default mask.

Sticky bitThe sticky bit

Trögheten bit är en mer avancerad funktion i en POSIX-behållare.The sticky bit is a more advanced feature of a POSIX container. I samband med Data Lake Storage Gen2 är det osannolikt att det behövs.In the context of Data Lake Storage Gen2, it is unlikely that the sticky bit will be needed. I sammanfattning, om trögheten är aktive rad i en katalog, kan ett underordnat objekt bara tas bort eller byta namn av det underordnade objektets ägande användare.In summary, if the sticky bit is enabled on a directory, a child item can only be deleted or renamed by the child item's owning user.

Trögheten bit visas inte i Azure Portal.The sticky bit isn't shown in the Azure portal.

Standard behörigheter för nya filer och katalogerDefault permissions on new files and directories

När en ny fil eller katalog skapas under en befintlig katalog, fastställer standard-ACL: en för den överordnade katalogen:When a new file or directory is created under an existing directory, the default ACL on the parent directory determines:

  • En underordnad katalogs standard-ACL och åtkomst-ACL.A child directory's default ACL and access ACL.
  • En underordnad fils åtkomst-ACL (filer har inte en standard-ACL).A child file's access ACL (files do not have a default ACL).

umaskumask

När du skapar en fil eller katalog, används umask för att ändra hur standard-ACL: erna anges för det underordnade objektet.When creating a file or directory, umask is used to modify how the default ACLs are set on the child item. umask är ett 9-bitars värde i överordnade kataloger som innehåller ett RWX-värde för ägande användare, ägande grupp och annat.umask is a 9-bit value on parent directories that contains an RWX value for owning user, owning group, and other.

Umask för Azure Data Lake Storage Gen2 ett konstant värde som är inställt på 007.The umask for Azure Data Lake Storage Gen2 a constant value that is set to 007. Det här värdet översätts till:This value translates to:

umask-komponentumask component Numeriskt formatNumeric form KortformatShort form InnebördMeaning
umask.owning_userumask.owning_user 00 --- För ägande användare kopierar du den överordnade standard-ACL: en till barnets åtkomst-ACLFor owning user, copy the parent's default ACL to the child's access ACL
umask.owning_groupumask.owning_group 00 --- För ägande grupp kopierar du den överordnade standard-ACL: en till barnets åtkomst-ACLFor owning group, copy the parent's default ACL to the child's access ACL
umask. otherumask.other 77 RWX För övrigt tar du bort alla behörigheter för barnets åtkomst-ACLFor other, remove all permissions on the child's access ACL

Umask-värdet som används av Azure Data Lake Storage Gen2 effektivt innebär att värdet för annat aldrig överförs som standard vid nya underordnade, om inte en standard-ACL definieras i den överordnade katalogen.The umask value used by Azure Data Lake Storage Gen2 effectively means that the value for other is never transmitted by default on new children, unless a default ACL is defined on the parent directory. I så fall ignoreras umask och behörigheterna som definieras av standard-ACL: en tillämpas på det underordnade objektet.In that case, the umask is effectively ignored and the permissions defined by the default ACL are applied to the child item.

Följande pseudocode visar hur umask används när du skapar ACL: er för ett underordnat objekt.The following pseudocode shows how the umask is applied when creating the ACLs for a child 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 )

VANLIGA FRÅGOR OCH SVARFAQ

Måste jag aktivera stöd för ACL:er?Do I have to enable support for ACLs?

Nej.No. Åtkomst kontroll via ACL: er aktive ras för ett lagrings konto så länge funktionen för hierarkiskt namn område (HNS) är aktive rad.Access control via ACLs is enabled for a storage account as long as the Hierarchical Namespace (HNS) feature is turned ON.

Om HNS är inaktiverat används fortfarande Azure Azure RBAC-auktoriseringsregler.If HNS is turned OFF, the Azure Azure RBAC authorization rules still apply.

Vad är det bästa sättet att tillämpa ACL: er?What is the best way to apply ACLs?

Använd alltid Azure AD-säkerhetsgrupper som det tilldelade huvudobjektet i en ACL-post.Always use Azure AD security groups as the assigned principal in an ACL entry. Motstå möjligheten att direkt tilldela enskilda användare eller tjänst huvud namn.Resist the opportunity to directly assign individual users or service principals. 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.Using this structure will allow you to add and remove users or service principals without the need to reapply ACLs to an entire directory structure. 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.Instead, you can just add or remove users and service principals from the appropriate Azure AD security group.

Det finns många olika sätt att konfigurera grupper.There are many different ways to set up groups. Anta till exempel att du har en katalog med namnet /LogData som innehåller loggdata som genereras av servern.For example, imagine that you have a directory named /LogData which holds log data that is generated by your server. Azure Data Factory (ADF) matar in data i den mappen.Azure Data Factory (ADF) ingests data into that folder. 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.Specific users from the service engineering team will upload logs and manage other users of this folder, and various Databricks clusters will analyze logs from that folder.

Om du vill aktivera dessa aktiviteter kan du skapa en LogsWriter grupp och en LogsReader grupp.To enable these activities, you could create a LogsWriter group and a LogsReader group. Sedan kan du tilldela behörigheter enligt följande:Then, you could assign permissions as follows:

  • Lägg till LogsWriter gruppen i ACL: en för /LogData -katalogen med rwx behörigheter.Add the LogsWriter group to the ACL of the /LogData directory with rwx permissions.
  • Lägg till LogsReader gruppen i ACL: en för /LogData -katalogen med r-x behörigheter.Add the LogsReader group to the ACL of the /LogData directory with r-x permissions.
  • Lägg till tjänstens huvud objekt eller Hanterad tjänstidentitet (MSI) för ADF i LogsWriters gruppen.Add the service principal object or Managed Service Identity (MSI) for ADF to the LogsWriters group.
  • Lägg till användare i service Engineering-teamet i LogsWriter gruppen.Add users in the service engineering team to the LogsWriter group.
  • Lägg till tjänstens huvud objekt eller MSI för Databricks i LogsReader gruppen.Add the service principal object or MSI for Databricks to the LogsReader group.

Om en användare i service Engineering-teamet lämnar företaget kan du bara ta bort dem från LogsWriter gruppen.If a user in the service engineering team leaves the company, you could just remove them from the LogsWriter group. 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.If you did not add that user to a group, but instead, you added a dedicated ACL entry for that user, you would have to remove that ACL entry from the /LogData directory. Du måste också ta bort posten från alla under kataloger och filer i hela katalogens hierarki i /LogData -katalogen.You would also have to remove the entry from all subdirectories and files in the entire directory hierarchy of the /LogData directory.

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.To create a group and add members, see Create a basic group and add members using Azure Active Directory.

Hur utvärderas Azure RBAC-och ACL-behörigheter?How are Azure RBAC and ACL permissions evaluated?

Om du vill veta hur systemet utvärderar Azure RBAC och ACL: er tillsammans för att fatta auktoriseringsbeslut för lagrings konto resurser, se hur behörigheter utvärderas.To learn how the system evaluates Azure RBAC and ACLs together to make authorization decisions for storage account resources, see How permissions are evaluated.

Vilka är gränserna för roll tilldelningar i Azure och ACL-poster?What are the limits for Azure role assignments and ACL entries?

Följande tabell innehåller en sammanfattning av gränserna för att överväga när du använder Azure RBAC för att hantera "avkorniga" behörigheter (behörigheter som gäller för lagrings konton eller behållare) och använder ACL: er för att hantera "detaljerade" behörigheter (behörigheter som gäller för filer och kataloger).The following table provides a summary view of the limits to consider while using Azure RBAC to manage "coarse-grained" permissions (permissions that apply to storage accounts or containers) and using ACLs to manage "fine-grained" permissions (permissions that apply to files and directories). Använd säkerhets grupper för ACL-tilldelningar.Use security groups for ACL assignments. Genom att använda grupper kan du minska det högsta antalet roll tilldelningar per prenumeration och maximalt antal ACl-poster per fil eller katalog.By using groups, you're less likely to exceed the maximum number of role assignments per subscription and the maximum number of ACl entries per file or directory.

MekanismMechanism OmfångScope GränserLimits Behörighets nivå som stödsSupported level of permission
Azure RBACAzure RBAC Lagrings konton, behållare.Storage accounts, containers.
Kors resursens Azure Role-tilldelningar på prenumerations-eller resurs grupps nivå.Cross resource Azure role assignments at subscription or resource group level.
2000 Azure-roll tilldelningar i en prenumeration2000 Azure role assignments in a subscription Azure-roller (inbyggt eller anpassat)Azure roles (built-in or custom)
ACLACL Katalog, filDirectory, file 32 ACL-poster (effektivt 28 ACL-poster) per fil och per katalog.32 ACL entries (effectively 28 ACL entries) per file and per directory. Åtkomst-och standard-ACL: er har sin egen begränsning för 32 ACL-poster.Access and default ACLs each have their own 32 ACL entry limit. ACL-behörighetACL permission

Stöder Data Lake Storage Gen2 arv av Azure RBAC?Does Data Lake Storage Gen2 support inheritance of Azure RBAC?

Roll tilldelningar i Azure ärver.Azure role assignments do inherit. Tilldelnings flödet från prenumerations-, resurs grupps-och lagrings konto resurser till behållar resursen.Assignments flow from subscription, resource group, and storage account resources down to the container resource.

Stöder Data Lake Storage Gen2 arv av ACL: er?Does Data Lake Storage Gen2 support inheritance of ACLs?

Standard-ACL: er kan användas för att ange ACL: er för nya underordnade under kataloger och filer som skapas under den överordnade katalogen.Default ACLs can be used to set ACLs for new child subdirectories and files created under the parent directory. 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 katalogpartitionen.To update ACLs for existing child items, you will need to add, update, or remove ACLs recursively for the desired directory hierarchy. Mer information finns i ange åtkomst kontrol listor (ACL) rekursivt för Azure Data Lake Storage Gen2.For more information, see Set access control lists (ACLs) recursively for Azure Data Lake Storage Gen2.

Vilka behörigheter krävs för att rekursivt ta bort en katalog och dess innehåll?Which permissions are required to recursively delete a directory and its contents?

  • Anroparen har behörigheten "Super-User",The caller has 'super-user' permissions,

EllerOr

  • Den överordnade katalogen måste ha Skriv-och körnings behörighet.The parent directory must have Write + Execute permissions.
  • Katalogen som ska tas bort och alla kataloger i den, kräver Läs-och skriv + kör-behörigheter.The directory to be deleted, and every directory within it, requires Read + Write + Execute permissions.

Anteckning

Du behöver inte Skriv behörighet för att ta bort filer i kataloger.You do not need Write permissions to delete files in directories. Dessutom kan rot katalogen "/" aldrig tas bort.Also, the root directory "/" can never be deleted.

Vem är ägaren till en fil eller katalog?Who is the owner of a file or directory?

Skaparen av en fil eller katalog blir ägare.The creator of a file or directory becomes the owner. Om det gäller rot katalogen är detta identiteten för den användare som skapade behållaren.In the case of the root directory, this is the identity of the user who created the container.

Vilken grupp anges som den ägande gruppen för en fil eller katalog när den skapas?Which group is set as the owning group of a file or directory at creation?

Den ägande gruppen kopieras från den ägande gruppen i den överordnade katalogen under vilken den nya filen eller katalogen skapas.The owning group is copied from the owning group of the parent directory under which the new file or directory is created.

Jag är ägande användare av en fil men jag har inte de RWX-behörigheter jag behöver.I am the owning user of a file but I don't have the RWX permissions I need. Vad gör jag nu?What do I do?

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.The owning user can change the permissions of the file to give themselves any RWX permissions they need.

Varför visas ibland GUID i ACL: er?Why do I sometimes see GUIDs in ACLs?

Ett GUID visas om posten representerar en användare och den användaren inte finns längre i Azure AD.A GUID is shown if the entry represents a user and that user doesn't exist in Azure AD anymore. Detta inträffar vanligtvis när användaren har lämnat företaget eller om kontot har tagits bort i Azure AD.Usually this happens when the user has left the company or if their account has been deleted in Azure AD. Dessutom har tjänstens huvud namn och säkerhets grupper inget UPN (User Principal Name) för att identifiera dem och så de representeras av deras OID-attribut (en GUID).Additionally, service principals and security groups do not have a User Principal Name (UPN) to identify them and so they are represented by their OID attribute (a guid).

Hur gör jag för att ange ACL: er korrekt för ett huvud namn för tjänsten?How do I set ACLs correctly for a service principal?

När du definierar ACL: er för tjänstens huvud namn är det viktigt att använda objekt-ID: t (OID) för tjänstens huvud namn för den app-registrering som du skapade.When you define ACLs for service principals, it's important to use the Object ID (OID) of the service principal for the app registration that you created. Det är viktigt att notera att registrerade appar har ett separat tjänst objekt i den aktuella Azure AD-klienten.It's important to note that registered apps have a separate service principal in the specific Azure AD tenant. Registrerade appar har ett OID som är synligt i Azure Portal, men tjänstens huvud namn har en annan (annan) OID.Registered apps have an OID that's visible in the Azure portal, but the service principal has another (different) OID.

Om du vill hämta OID för det tjänst huvud namn som motsvarar en registrerad app kan du använda az ad sp show kommandot.To get the OID for the service principal that corresponds to an app registration, you can use the az ad sp show command. Ange program-ID som parameter.Specify the Application ID as the parameter. Här är ett exempel på hur du hämtar OID för tjänstens huvud namn som motsvarar en app-registrering med app-ID = 18218b12-1895-43e9-ad80-6e8fc1ea88ce.Here's an example on obtaining the OID for the service principal that corresponds to an app registration with App ID = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Kör följande kommando i Azure CLI:Run the following command in the Azure CLI:

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

OID kommer att visas.OID will be displayed.

När du har rätt OID för tjänstens huvud namn går du till sidan Storage Explorer Hantera åtkomst för att lägga till OID och tilldela lämpliga behörigheter för OID.When you have the correct OID for the service principal, go to the Storage Explorer Manage Access page to add the OID and assign appropriate permissions for the OID. Se till att du väljer Spara.Make sure you select Save.

Kan jag ange ACL för en behållare?Can I set the ACL of a container?

Nej.No. En behållare har ingen ACL.A container does not have an ACL. Du kan dock ange ACL: en för behållarens rot Katalog.However, you can set the ACL of the container’s root directory. Varje behållare har en rot Katalog och den delar samma namn som behållaren.Every container has a root directory, and it shares the same name as the container. Om behållaren till exempel heter my-container , namnges rot katalogen myContainer/ .For example, if the container is named my-container, then the root directory is named myContainer/.

Azure Storage REST API innehåller en åtgärd med namnet set behållar-ACL, men åtgärden kan inte användas för att ange ACL för en behållare eller rot katalogen för en behållare.The Azure Storage REST API does contain an operation named Set Container ACL, but that operation cannot be used to set the ACL of a container or the root directory of a container. I stället används den åtgärden för att indikera om blobbar i en behållare kan nås offentligt.Instead, that operation is used to indicate whether blobs in a container may be accessed publicly.

Var hittar jag mer information om POSIX-modellen för åtkomstkontroll?Where can I learn more about POSIX access control model?

Se ävenSee also