Toegangsbeheerlijsten (ACL's) in Azure Data Lake Storage Gen2

  • Artikel

Azure Data Lake Storage Gen2 implementeert een toegangsbeheermodel dat zowel op rollen gebaseerd toegangsbeheer (Azure RBAC) als POSIX-achtige toegangsbeheerlijsten (ACL's) van Azure ondersteunt. In dit artikel worden toegangsbeheerlijsten in Data Lake Storage Gen2 beschreven. Zie Het Access Control-model in Azure Data Lake Storage Gen2 voor meer informatie over het opnemen van Azure RBAC in combinatie met ACL's en hoe het systeem deze evalueert om autorisatiebeslissingen te nemen.

Over ACL's

U kunt een beveiligingsprincipaal koppelen aan een toegangsniveau voor bestanden en mappen. Elke koppeling wordt vastgelegd als een vermelding in een ACL (Access Control List). Elk bestand en elke map in uw opslagaccount heeft een toegangsbeheerlijst. Wanneer een beveiligingsprincipaal een bewerking probeert uit te voeren in een bestand of map, bepaalt een ACL-controle of die beveiligingsprincipaal (gebruiker, groep, service-principal of beheerde identiteit) het juiste machtigingsniveau heeft om de bewerking uit te voeren.

Notitie

ACL's zijn alleen van toepassing op beveiligingsprincipals in dezelfde tenant en zijn niet van toepassing op gebruikers die sas-tokenverificatie (Shared Key of Shared Access Signature) gebruiken. Dat komt doordat er geen identiteit is gekoppeld aan de aanroeper en daarom kan geen autorisatie op basis van machtigingen op basis van een beveiligingsprincipaal worden uitgevoerd.

ACL's instellen

Zie een van de volgende artikelen om machtigingen op bestands- en mapniveau in te stellen:

Omgeving Artikel
Azure Storage Explorer Azure Storage Explorer gebruiken om ACL's te beheren in Azure Data Lake Storage Gen2
Azure Portal Azure Portal gebruiken om ACL's te beheren in Azure Data Lake Storage Gen2
.NET .NET gebruiken om ACL's te beheren in Azure Data Lake Storage Gen2
Java Java gebruiken om ACL's te beheren in Azure Data Lake Storage Gen2
Python Python gebruiken om ACL's te beheren in Azure Data Lake Storage Gen2
JavaScript (node.js) De JavaScript SDK in Node.js gebruiken om ACL's te beheren in Azure Data Lake Storage Gen2
PowerShell PowerShell gebruiken om ACL's te beheren in Azure Data Lake Storage Gen2
Azure-CLI Azure CLI gebruiken om ACL's te beheren in Azure Data Lake Storage Gen2
REST-API Pad - Bijwerken

Belangrijk

Als de beveiligings-principal een service-principal is, is het belangrijk dat u de object-id van de service-principal gebruikt en niet de object-id van de gerelateerde app-registratie. Als u de object-id van de service-principal wilt ophalen, opent u de Azure CLI en gebruikt u deze opdracht: az ad sp show --id <Your App ID> --query objectId Zorg ervoor dat u de <Your App ID> tijdelijke aanduiding vervangt door de app-id van uw app-registratie. De service-principal wordt behandeld als een benoemde gebruiker. U voegt deze id toe aan de ACL, net zoals elke benoemde gebruiker. Benoemde gebruikers worden verderop in dit artikel beschreven.

Typen ACL's

Er zijn twee soorten toegangsbeheerlijsten: toegangs-ACL's en standaard-ACL's.

Met toegangs-ACL's beheert u de toegang tot een object. Bestanden en mappen hebben beide Toegangs-ACL's.

Standaard-ACL's zijn sjablonen van ACL's die zijn gekoppeld aan een map die de toegangs-ACL's bepalen voor onderliggende items die onder die map worden gemaakt. Bestanden hebben geen Standaard-ACL's.

Zowel toegangs-ACL's als 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.

Machtigingsniveaus

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

Bestand Directory
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 en uitvoeren vereist om onderliggende items in een map te maken
Uitvoeren (U) Betekent niets in de context van Data Lake Storage Gen2 Vereist om de onderliggende items van een map te doorlopen

Notitie

Als u machtigingen verleent met behulp van alleen ACL's (geen Azure RBAC), moet u de beveiligingsprincipal machtigingen verlenen voor het uitvoeren van machtigingen voor de hoofdmap van de container en aan elke map in de hiërarchie van mappen die naar het bestand leiden.

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-- Read
0 --- Geen machtigingen

Overname van machtigingen

In het POSIX-model dat wordt gebruikt door Data Lake Storage Gen2 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 als de machtigingen zijn ingesteld nadat het onderliggende item al is gemaakt. Machtigingen worden alleen overgenomen als standaardmachtigingen zijn ingesteld voor de bovenliggende items voordat de onderliggende items zijn gemaakt.

In de volgende tabel ziet u de ACL-vermeldingen die nodig zijn om een beveiligingsprincipaal in te schakelen voor het uitvoeren van de bewerkingen die worden vermeld in de kolom Bewerking .

In deze tabel ziet u een kolom die elk niveau van een fictieve maphiërarchie vertegenwoordigt. Er is een kolom voor de hoofdmap van de container (/), een submap met de naam Oregon, een submap van de map Oregon met de naam Portland en een tekstbestand in de map Portland met de naam Data.txt.

Belangrijk

In deze tabel wordt ervan uitgegaan dat u alleen ACL's zonder Azure-roltoewijzingen gebruikt. Als u een vergelijkbare tabel wilt zien waarin Azure RBAC samen met ACL's wordt gecombineerd, raadpleegt u de tabel Machtigingen: Azure RBAC, ABAC en ACL's combineren.

Operation / Oregon/ Portland/ Data.txt
Data.txt lezen --X --X --X R--
Toevoegen aan Data.txt --X --X --X RW-
Data.txt verwijderen --X --X -WX ---
Data.txt maken --X --X -WX ---
Lijst/ R-X --- --- ---
Lijst /Oregon/ --X R-X --- ---
Lijst /Oregon/Portland/ --X --X R-X ---

Notitie

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 gebruiker die eigenaar is
  • De groep die eigenaar is
  • Benoemde gebruikers
  • Benoemde groepen
  • Benoemde service-principals
  • Benoemde beheerde identiteiten
  • 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 Gen2 verwijzen naar een Microsoft Entra-gebruiker, service-principal, beheerde identiteit of beveiligingsgroep.

De supergebruiker

Een supergebruiker heeft de meeste rechten van alle gebruikers. 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.

Als een container, bestand of map wordt gemaakt met gedeelde sleutel, een account-SAS of een service-SAS, worden de eigenaar en eigenaar van de groep ingesteld op $superuser.

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 is 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

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 wordt altijd aangewezen als de 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.

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

  • Case 1: De hoofdmap /. Deze map wordt gemaakt wanneer een Data Lake Storage Gen2-container wordt gemaakt. In dit geval wordt de groep die eigenaar is ingesteld op de gebruiker die de container heeft gemaakt als deze is uitgevoerd met OAuth. Als de container wordt gemaakt met behulp van een gedeelde sleutel, een account-SAS of een service-SAS, wordt de eigenaar en eigenaar van de groep ingesteld op $superuser.
  • Case 2 (elk ander geval): 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:

  • 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. Hoewel de groep die eigenaar is, is ingesteld op de gebruiker die het account heeft gemaakt in het geval van de hoofdmap, is Case 1 hierboven niet geldig voor het opgeven van machtigingen via de groep die eigenaar is. U kunt deze machtiging toewijzen aan een geldige gebruikersgroep, indien van toepassing.

Evalueren van machtigingen

Identiteiten worden in de volgende volgorde geëvalueerd:

  1. Superuser
  2. Gebruiker die eigenaar is
  3. Benoemde gebruiker, service-principal of beheerde identiteit
  4. Groep die eigenaar is of benoemde groep
  5. Alle andere gebruikers

Als meer dan een van deze identiteiten van toepassing is op een beveiligingsprincipaal, wordt het machtigingsniveau dat is gekoppeld aan de eerste identiteit verleend. Als een beveiligingsprincipaal bijvoorbeeld zowel de gebruiker die eigenaar is als een benoemde gebruiker, is het machtigingsniveau dat is gekoppeld aan de eigenaar van de gebruiker van toepassing.

Benoemde groepen worden allemaal samen beschouwd. Als een beveiligingsprincipaal lid is van meer dan één benoemde groep, evalueert het systeem elke groep totdat de gewenste machtiging is verleend. Als geen van de benoemde groepen de gewenste machtiging biedt, wordt het systeem verplaatst om een aanvraag te evalueren op basis van de machtiging die aan alle andere gebruikers is gekoppeld.

De volgende pseudocode vertegenwoordigt het algoritme voor toegangscontrole voor opslagaccounts. Dit algoritme toont de volgorde waarin identiteiten worden geëvalueerd.

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)

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.

Voor een nieuwe Data Lake Storage Gen2-container is het masker voor de toegangs-ACL van de hoofdmap (/) standaard ingesteld op 750 voor mappen en 640 voor bestanden. In de volgende tabel ziet u de symbolische notatie van deze machtigingsniveaus.

Entity Directories Files
Gebruiker die eigenaar is rwx rw-
Groep die eigenaar is r-x r--
Overige --- ---

Bestanden ontvangen de X-bit niet omdat het niet relevant is voor bestanden in een alleen-archiefsysteem.

Het masker kan per aanroep worden opgegeven. Hierdoor kunnen verschillende systemen, zoals clusters, verschillende effectieve maskers hebben voor hun bestandsbewerkingen. Als een masker is opgegeven voor een bepaalde aanvraag, wordt het standaardmasker volledig overschreven.

De vergrendelde bit

De plak-bit is een geavanceerdere functie van een POSIX-container. In de context van Data Lake Storage Gen2 is het onwaarschijnlijk dat de plak-bit nodig is. Kortom, als de plak-bit is ingeschakeld voor een map, kan een onderliggend item alleen worden verwijderd of hernoemd door de eigenaar van het onderliggende item, de eigenaar van de map of de Superuser ($superuser).

De plak-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 op 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 standaard-ACL wordt de umask toegepast op de toegangs-ACL om de initiële machtigingen van een standaard-ACL te bepalen. Als er een standaard-ACL is gedefinieerd in de bovenliggende map, wordt de umask effectief genegeerd en wordt de standaard-ACL van de bovenliggende map gebruikt om deze initiële waarden te definiëren.

De umask is een 9-bits waarde voor bovenliggende mappen die een RWX-waarde bevatten voor het bezit van de gebruiker, de groep die eigenaar is en andere.

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

Veelgestelde vragen

Moet ik ondersteuning voor ACL's inschakelen?

Nee Toegangsbeheer via ACL's is ingeschakeld voor een opslagaccount zolang de HNS-functie (Hierarchical Namespace) is ingeschakeld.

Als HNS is uitgeschakeld, zijn de Azure RBAC-autorisatieregels nog steeds van toepassing.

Wat is de beste manier om ACL's toe te passen?

Gebruik altijd Microsoft Entra-beveiligingsgroepen als de toegewezen principal in een ACL-vermelding. Weersta de mogelijkheid om afzonderlijke gebruikers of service-principals rechtstreeks toe te wijzen. Met deze structuur kunt u gebruikers of service-principals toevoegen en verwijderen zonder dat u ACL's opnieuw hoeft toe te voegen aan een hele mapstructuur. In plaats daarvan kunt u alleen gebruikers en service-principals toevoegen aan of verwijderen uit de juiste Microsoft Entra-beveiligingsgroep.

Er zijn veel verschillende manieren om groepen in te stellen. Stel dat u een map hebt met de naam /LogData die logboekgegevens bevat die door uw server worden gegenereerd. Azure Data Factory (ADF) neemt gegevens op in die map. Specifieke gebruikers van het service-engineeringteam uploaden logboeken en beheren andere gebruikers van deze map, en verschillende Databricks-clusters analyseren logboeken uit die map.

Als u deze activiteiten wilt inschakelen, kunt u een LogsWriter groep en een LogsReader groep maken. Vervolgens kunt u machtigingen als volgt toewijzen:

  • Voeg de LogsWriter groep toe aan de ACL van de map /LogData met rwx machtigingen.
  • Voeg de LogsReader groep toe aan de ACL van de map /LogData met r-x machtigingen.
  • Voeg het service-principalobject of Managed Service Identity (MSI) voor ADF toe aan de LogsWriters groep.
  • Voeg gebruikers toe aan het technische team van de service aan de LogsWriter groep.
  • Voeg het service-principalobject of MSI voor Databricks toe aan de LogsReader groep.

Als een gebruiker in het service-engineeringteam het bedrijf verlaat, kunt u ze gewoon uit de LogsWriter groep verwijderen. Als u die gebruiker niet aan een groep hebt toegevoegd, maar in plaats daarvan een toegewezen ACL-vermelding voor die gebruiker hebt toegevoegd, moet u die ACL-vermelding verwijderen uit de map /LogData . U moet de vermelding ook verwijderen uit alle submappen en bestanden in de volledige maphiërarchie van de map /LogData-map .

Zie Een basisgroep maken en leden toevoegen met behulp van Microsoft Entra-id om een groep te maken en leden toe te voegen.

Belangrijk

Azure Data Lake Storage Gen2 is afhankelijk van de Microsoft Entra-id voor het beheren van beveiligingsgroepen. Microsoft Entra ID raadt u aan om het groepslidmaatschap voor een bepaalde beveiligingsprincipaal te beperken tot minder dan 200. Deze aanbeveling wordt veroorzaakt door een beperking van JSON-webtokens (JWT) die de groepslidmaatschapsgegevens van een beveiligingsprincipaal in Microsoft Entra-toepassingen bieden. Het overschrijden van deze limiet kan leiden tot onverwachte prestatieproblemen met Data Lake Storage Gen2. Zie Groepsclaims configureren voor toepassingen met behulp van Microsoft Entra-id voor meer informatie.

Hoe worden Azure RBAC- en ACL-machtigingen geëvalueerd?

Als u wilt weten hoe het systeem Azure RBAC en ACL's evalueert om autorisatiebeslissingen te nemen voor opslagaccountbronnen, raadpleegt u Hoe machtigingen worden geëvalueerd.

Wat zijn de limieten voor Azure-roltoewijzingen en ACL-vermeldingen?

De volgende tabel bevat een overzicht van de limieten waarmee u rekening moet houden bij het gebruik van Azure RBAC voor het beheren van 'grofkorrelige' machtigingen (machtigingen die van toepassing zijn op opslagaccounts of containers) en het gebruik van ACL's voor het beheren van 'fijnmazige' machtigingen (machtigingen die van toepassing zijn op bestanden en mappen). Gebruik beveiligingsgroepen voor ACL-toewijzingen. Door gebruik te maken van groepen, verkleint u het risico dat u het maximum aantal roltoewijzingen per abonnement en het maximum aantal ACL-vermeldingen per bestand of map overschrijdt.

Mechanisme Bereik Limieten Ondersteund machtigingsniveau
Azure RBAC Opslagaccounts, containers.
Azure-roltoewijzingen voor meerdere resources op abonnements- of resourcegroepniveau.		 4000 Azure-roltoewijzingen in een abonnement Azure-rollen (ingebouwd of aangepast)
ACL Map, bestand 32 ACL-vermeldingen (effectief 28 ACL-vermeldingen) per bestand en per map. Toegang en standaard-ACL's hebben elk hun invoerlimiet van 32 ACL's. ACL-machtiging

Biedt Data Lake Storage Gen2 ondersteuning voor overname van Azure RBAC?

Azure-roltoewijzingen nemen wel over. Toewijzingen stromen van abonnements-, resourcegroep- en opslagaccountresources tot aan de containerresource.

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

Standaard-ACL's kunnen worden gebruikt om ACL's in te stellen voor nieuwe onderliggende submappen en bestanden die zijn gemaakt onder de bovenliggende map. Als u ACL's voor bestaande onderliggende items wilt bijwerken, moet u ACL's recursief toevoegen, bijwerken of verwijderen voor de gewenste adreslijsthiërarchie. Zie de sectie ACL's instellen van dit artikel voor hulp.

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

  • De beller heeft 'supergebruiker'-machtigingen,

Of

  • De bovenliggende map moet schrijf- en uitvoermachtigingen hebben.
  • Voor de map die moet worden verwijderd en elke map erin, zijn lees- en schrijfmachtigingen vereist.

Notitie

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. In het geval van de hoofdmap is dit de identiteit van de gebruiker die de container heeft gemaakt.

Welke groep wordt ingesteld als de groep die eigenaar is van een bestand of map bij het maken?

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.

Waarom zie ik soms GUID's in ACL's?

Er wordt een GUID weergegeven als de vermelding een gebruiker vertegenwoordigt en die gebruiker niet meer bestaat in Microsoft Entra. Dit gebeurt meestal wanneer de gebruiker het bedrijf heeft verlaten of als het account is verwijderd in Microsoft Entra-id. Daarnaast hebben service-principals en beveiligingsgroepen geen UPN (User Principal Name) om ze te identificeren, zodat ze worden vertegenwoordigd door hun OID-kenmerk (een GUID). Als u de ACL's wilt opschonen, verwijdert u deze GUID-vermeldingen handmatig.

Hoe kan ik ACL's correct instellen voor een service-principal?

Wanneer u ACL's definieert voor service-principals, is het belangrijk dat u de object-id (OID) van de service-principal gebruikt voor de app-registratie die u hebt gemaakt. Het is belangrijk te weten dat geregistreerde apps een afzonderlijke service-principal hebben in de specifieke Microsoft Entra-tenant. Geregistreerde apps hebben een OID die zichtbaar is in Azure Portal, maar de service-principal heeft een andere (andere) OID. Artikel Om de OID op te halen voor de service-principal die overeenkomt met een app-registratie, kunt u de az ad sp show opdracht gebruiken. Geef de toepassings-id op als de parameter. Hier volgt een voorbeeld van het verkrijgen van de OID voor de service-principal die overeenkomt met een app-registratie met App-id = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Voer de volgende opdracht uit in de Azure CLI:

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

OID wordt weergegeven.

Wanneer u de juiste OID voor de service-principal hebt, gaat u naar de pagina Toegang beheren van Storage Explorer om de OID toe te voegen en de juiste machtigingen voor de OID toe te wijzen. Zorg ervoor dat u Opslaan selecteert

Kan ik de ACL van een container instellen?

Nee Een container heeft geen ACL. U kunt echter de ACL van de hoofdmap van de container instellen. Elke container heeft een hoofdmap en deelt dezelfde naam als de container. Als de container bijvoorbeeld een naam my-containerheeft, heeft de hoofdmap de naam my-container/.

De Azure Storage REST API bevat een bewerking met de naam Set Container ACL, maar deze bewerking kan niet worden gebruikt om de ACL van een container of de hoofdmap van een container in te stellen. In plaats daarvan wordt die bewerking gebruikt om aan te geven of blobs in een container toegankelijk zijn met een anonieme aanvraag. We raden u aan om autorisatie te vereisen voor alle aanvragen voor blobgegevens. Zie Overzicht: Anonieme leestoegang voor blobgegevens herstellen voor meer informatie.

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

Zie ook