Container-ACL instellen

Met de Set Container ACL bewerking worden de machtigingen voor de opgegeven container ingesteld. De machtigingen geven aan of blobs in een container openbaar toegankelijk zijn.

Vanaf versie 2009-09-19 bieden de containermachtigingen de volgende opties voor het beheren van containertoegang:

• volledige openbare leestoegang: container- en blobgegevens kunnen worden gelezen via anonieme aanvraag. Clients kunnen blobs in de container opsommen via anonieme aanvragen, maar kunnen geen containers in het opslagaccount opsommen.

• alleen openbare leestoegang voor blobs: blobgegevens in deze container kunnen worden gelezen via anonieme aanvraag, maar containergegevens zijn niet beschikbaar. Clients kunnen geen blobs in de container opsommen via anonieme aanvraag.

• Geen openbare leestoegang: container- en blobgegevens kunnen alleen worden gelezen door de accounteigenaar.

Set Container ACL stelt ook een opgeslagen toegangsbeleid in voor gebruik met handtekeningen voor gedeelde toegang. Zie Een opgeslagen toegangsbeleid definiërenvoor meer informatie.

Alle openbare toegang tot de container is anoniem, net als toegang via een Shared Access Signature.

Verzoek

De Set Container ACL aanvraag kan als volgt worden samengesteld. U wordt aangeraden HTTPS te gebruiken. Vervang myaccount- door de naam van uw opslagaccount:

Methode	Aanvraag-URI	HTTP-versie
PUT	https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl	HTTP/1.1

Emulated storage-serviceaanvraag

Wanneer u een aanvraag indient op basis van de geëmuleerde opslagservice, geeft u de hostnaam van de emulator en de Blob-servicepoort op als 127.0.0.1:10000, gevolgd door de geëmuleerde naam van het opslagaccount:

Methode	Aanvraag-URI	HTTP-versie
PUT	http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl	HTTP/1.1

Zie De Azurite-emulator gebruiken voor lokale Azure Storage-ontwikkelingvoor meer informatie.

URI-parameters

U kunt de volgende aanvullende parameters opgeven in de aanvraag-URI:

Parameter	Beschrijving
timeout	Facultatief. De parameter timeout wordt uitgedrukt in seconden. Zie Time-outs instellen voor blobservicebewerkingenvoor meer informatie.

Aanvraagheaders

De vereiste en optionele aanvraagheaders worden beschreven in de volgende tabel:

Aanvraagheader	Beschrijving
Authorization	Vereist. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
Date of x-ms-date	Vereist. Hiermee geeft u de Coordinated Universal Time (UTC) voor de aanvraag. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
x-ms-version	Facultatief. Hiermee geeft u de versie van de bewerking die moet worden gebruikt voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-servicesvoor meer informatie.
x-ms-blob-public-access	Facultatief. Hiermee geeft u op of gegevens in de container openbaar en het toegangsniveau kunnen worden geopend. Mogelijke waarden zijn: - container: hiermee geeft u volledige openbare leestoegang voor container- en blobgegevens op. Clients kunnen blobs in de container opsommen via anonieme aanvragen, maar kunnen geen containers in het opslagaccount opsommen. - blob: Hiermee geeft u openbare leestoegang voor blobs op. Blobgegevens in deze container kunnen worden gelezen via anonieme aanvraag, maar containergegevens zijn niet beschikbaar. Clients kunnen geen blobs in de container opsommen via anonieme aanvraag. Als deze header niet is opgenomen in de aanvraag, zijn containergegevens privé voor de accounteigenaar. Houd er rekening mee dat het instellen van openbare toegang voor een container in een Azure Premium Storage-account niet is toegestaan.
x-ms-lease-id: <ID>	Optioneel, versie 2012-02-12 en hoger. Als deze is opgegeven, slaagt Set Container ACL alleen als de lease van de container actief is en overeenkomt met deze id. Als er geen actieve lease is of de id niet overeenkomt, wordt 412 (voorwaarde mislukt) geretourneerd.
x-ms-client-request-id	Facultatief. Biedt een door de client gegenereerde, ondoorzichtige waarde met een tekenlimiet van 1 kibibyte (KiB) die wordt vastgelegd in de logboeken wanneer logboekregistratie is geconfigureerd. We raden u ten zeerste aan deze header te gebruiken om activiteiten aan de clientzijde te correleren met aanvragen die de server ontvangt. Zie Azure Blob Storage-bewaken voor meer informatie.

Deze bewerking ondersteunt ook het gebruik van voorwaardelijke headers om de bewerking alleen uit te voeren als aan een opgegeven voorwaarde wordt voldaan. Zie Voorwaardelijke headers opgeven voor blobservicebewerkingenvoor meer informatie.

Aanvraagbody

Als u een opgeslagen toegangsbeleid wilt opgeven, geeft u een unieke id en toegangsbeleid op in de aanvraagbody voor de Set Container ACL bewerking.

Het element SignedIdentifier bevat de unieke id, zoals opgegeven in het Id-element en de details van het toegangsbeleid, zoals opgegeven in het AccessPolicy-element. De maximale lengte van de unieke id is 64 tekens.

De velden Start en Expiry moeten worden uitgedrukt als UTC-tijden en moeten voldoen aan een geldige ISO 8061-indeling. Ondersteunde ISO 8061-indelingen zijn onder andere:

• YYYY-MM-DD
• YYYY-MM-DDThh:mmTZD
• YYYY-MM-DDThh:mm:ssTZD
• YYYY-MM-DDThh:mm:ss.fffffffTZD

Voor het datumgedeelte van deze notaties is YYYY een jaarweergave van vier cijfers, MM een maandweergave van twee cijfers is en DD een dagweergave van twee cijfers is. Voor het tijdgedeelte is hh de uurweergave in de notatie van 24 uur, mm de weergave van twee cijfers is, ss de tweede weergave van twee cijfers is en fffffff de zevencijferige milliseconden vertegenwoordigt. Een tijdsontwerper T scheidt de datum- en tijdgedeelten van de tekenreeks en een tijdzone-ontwerper TZD een tijdzone opgeeft.

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>  
  

Voorbeeldaanvraag

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
x-ms-blob-public-access: container  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2009-09-28T08:49:37.0000000Z</Start>  
      <Expiry>2009-09-29T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>  
  

Antwoord

Het antwoord bevat een HTTP-statuscode en een set antwoordheaders.

Statuscode

Een geslaagde bewerking retourneert statuscode 200 (OK).

Zie Status en foutcodesvoor meer informatie over statuscodes.

Antwoordheaders

Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord kan ook aanvullende standaard HTTP-headers bevatten. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader	Beschrijving
ETag	De ETag voor de container. Als de aanvraagversie 2011-08-18 of hoger is, wordt de ETag-waarde tussen aanhalingstekens geplaatst.
Last-Modified	Retourneert de datum en tijd waarop de container voor het laatst is gewijzigd. De datumnotatie volgt RFC 1123. Zie Datum-/tijdwaarden weergeven in koptekstenvoor meer informatie. Elke bewerking die de container of de eigenschappen of metagegevens wijzigt, werkt de laatst gewijzigde tijd bij, inclusief het instellen van de machtigingen van de container. Bewerkingen op blobs hebben geen invloed op de tijd van de laatste wijziging van de container.
x-ms-request-id	Identificeer de aanvraag die is gemaakt en kan worden gebruikt om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossen voor meer informatie
x-ms-version	Geeft de Blob-serviceversie aan die is gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn gedaan op basis van versie 2009-09-19 en hoger.
Date	Een UTC-datum/tijdwaarde die wordt gegenereerd door de service, wat de tijd aangeeft waarop het antwoord is gestart.
x-ms-client-request-id	Kan worden gebruikt om problemen met aanvragen en bijbehorende antwoorden op te lossen. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id header als deze aanwezig is in de aanvraag en de waarde niet meer dan 1024 zichtbare ASCII-tekens bevat. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze niet aanwezig in het antwoord.

Voorbeeldantwoord

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
ETag: "0x8CB171613397EAB"  
Last-Modified: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  

Machtiging

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Set Container ACL bewerking autoriseren zoals hieronder wordt beschreven.

Belangrijk

Microsoft raadt aan om Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen voor Azure Storage te autoriseren. Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak in vergelijking met autorisatie van gedeelde sleutels.

Microsoft Entra ID (aanbevolen)

Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipaal. De beveiligingsprincipaal kan een door een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipaal wordt geverifieerd door de Microsoft Entra-id om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag te autoriseren voor de Blob-service.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra IDvoor meer informatie over autorisatie met Behulp van Microsoft Entra ID.

Machtigingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra-gebruiker, groep, beheerde identiteit of service-principal om de Set Container ACL-bewerking aan te roepen, en de minst bevoorrechte ingebouwde Azure RBAC-rol die deze actie omvat:

• Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/setAcl/action
• ingebouwde rol met minimale bevoegdheden:eigenaar van opslagblobgegevens

Zie Een Azure-rol toewijzen voor toegang tot blobgegevensvoor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

gedeelde sleutel

De Set Container ACL-bewerking ondersteunt autorisatie van gedeelde sleutels. Autoriseren met accountsleutels wordt niet aanbevolen voor de meeste scenario's, omdat het minder veilig is.

Microsoft raadt u aan de toewijzing van gedeelde sleutelautorisatie voor het opslagaccount indien mogelijk ongedaan te maken. Zie Autorisatie voorkomen met gedeelde sleutelvoor meer informatie.

Opmerkingen

Wanneer u machtigingen voor een container instelt, worden de bestaande machtigingen vervangen. Als u de machtigingen van de container wilt bijwerken, roept u Container-ACL ophalen aan om alle toegangsbeleidsregels op te halen die aan de container zijn gekoppeld. Wijzig het toegangsbeleid dat u wilt wijzigen en roep Set Container ACL aan met de volledige set gegevens om de update uit te voeren.

anonieme openbare toegang inschakelen voor containergegevens

Als u anonieme openbare leestoegang wilt inschakelen voor containergegevens, roept u Set Container ACL aan met de x-ms-blob-public-access header ingesteld op container of blob. Als u anonieme toegang wilt uitschakelen, roept u Set Container ACL aan zonder de x-ms-blob-public-access koptekst op te geven.

Als u x-ms-blob-public-access instelt op blob, kunnen clients de volgende bewerkingen anoniem aanroepen:

• Blob- ophalen

• Blob-eigenschappen ophalen

• blobmetagegevens ophalen

• Blokkeringslijst ophalen (alleen voor de vastgelegde bloklijst)

• Paginabereiken ophalen

Als u x-ms-blob-public-access instelt op container, kunnen clients de volgende bewerkingen anoniem aanroepen:

• De blob-toegangsbewerkingen die worden vermeld in de vorige sectie.

• Containereigenschappen ophalen

• containermetagegevens ophalen

• lijstblobs

toegangsbeleid op containerniveau tot stand brengen

Een opgeslagen toegangsbeleid kan de begintijd, verlooptijd en machtigingen opgeven voor de handtekeningen voor gedeelde toegang waaraan het is gekoppeld. Afhankelijk van hoe u de toegang tot uw container of blobresource wilt beheren, kunt u al deze parameters in het opgeslagen toegangsbeleid opgeven en weglaten uit de URL voor de shared access Signature. Als u dit doet, kunt u het gedrag van de bijbehorende handtekening op elk gewenst moment wijzigen of intrekken. U kunt ook een of meer toegangsbeleidsparameters opgeven in het opgeslagen toegangsbeleid en de andere parameters op de URL. Ten slotte kunt u alle parameters op de URL opgeven. In dit geval kunt u het opgeslagen toegangsbeleid gebruiken om de handtekening in te trekken, maar niet om het gedrag ervan te wijzigen. Zie Een opgeslagen toegangsbeleid definiërenvoor meer informatie.

Samen moeten de handtekening voor gedeelde toegang en het opgeslagen toegangsbeleid alle velden bevatten die nodig zijn om de handtekening te autoriseren. Als er vereiste velden ontbreken, mislukt de aanvraag. Als een veld is opgegeven in zowel de shared access signature URL als het opgeslagen toegangsbeleid, mislukt de aanvraag met statuscode 400 (Ongeldige aanvraag).

Maximaal vijf afzonderlijke toegangsbeleidsregels kunnen op elk gewenst moment worden ingesteld voor één container. Als er meer dan vijf toegangsbeleidsregels worden doorgegeven in de aanvraagbody, retourneert de service statuscode 400 (Ongeldige aanvraag).

Een handtekening voor gedeelde toegang kan worden uitgegeven in een container of een blob, ongeacht of containergegevens beschikbaar zijn voor anonieme leestoegang. Een handtekening voor gedeelde toegang biedt een grotere mate van controle over hoe, wanneer en voor wie een resource toegankelijk wordt gemaakt.

Notitie

Wanneer u een opgeslagen toegangsbeleid instelt voor een container, kan het tot 30 seconden duren voordat het beleid van kracht wordt. Gedurende dit interval, totdat het beleid actief wordt, mislukt een handtekening voor gedeelde toegang die is gekoppeld aan het opgeslagen toegangsbeleid, met statuscode 403 (Verboden).

Facturering

Prijsaanvragen kunnen afkomstig zijn van clients die Blob Storage-API's gebruiken, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Deze aanvragen maken kosten per transactie. Het type transactie is van invloed op de manier waarop het account in rekening wordt gebracht. Leestransacties worden bijvoorbeeld opgebouwd tot een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Set Container ACL aanvragen op basis van het type opslagaccount:

Operatie	Type opslagaccount	Factureringscategorie
Container-ACL instellen	Premium blok-blob Standaard algemeen gebruik v2	Andere bewerkingen
Container-ACL instellen	Standaard algemeen gebruik v1	Schrijfbewerkingen

Zie Prijzen voor Azure Blob Storagevoor meer informatie over prijzen voor de opgegeven factureringscategorie.

Zie ook

de toegang tot containers en blobs beperken
Toegang delegeren met een Shared Access Signature-
Een Shared Access Signature- maken en gebruiken
Een opgeslagen toegangsbeleid definiëren
container-ACL ophalen
aanvragen autoriseren voor Azure Storage
status en foutcodes
foutcodes voor Blob-service