Freigeben über

Festlegen der Container-ACL

  • Artikel

Der Set Container ACL-Vorgang legt die Berechtigungen für den angegebenen Container fest. Die Berechtigungen geben an, ob auf Blobs in einem Container öffentlich zugegriffen werden kann.

Ab Version 2009-09-19 bieten die Containerberechtigungen die folgenden Optionen für die Verwaltung des Containerzugriffs:

  • Vollständiger öffentlicher Lesezugriff: Container- und BLOB-Daten können über anonyme Anforderung gelesen werden. Clients können Blobs innerhalb des Containers über anonyme Anforderung aufzählen, container jedoch nicht im Speicherkonto aufzählen.

  • Nur öffentlichen Lesezugriff für Blobs: Blob-Daten in diesem Container können über anonyme Anforderung gelesen werden, Containerdaten sind jedoch nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über anonyme Anforderung aufzählen.

  • Kein öffentlicher Lesezugriff: Container- und BLOB-Daten können nur vom Kontobesitzer gelesen werden.

Set Container ACL legt auch eine gespeicherte Zugriffsrichtlinie für die Verwendung mit freigegebenen Zugriffssignaturen fest. Weitere Informationen finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.

Der gesamte öffentliche Zugriff auf den Container ist anonym, wie der Zugriff über eine Freigegebene Zugriffssignatur.

Bitten

Die Set Container ACL Anforderung kann wie folgt erstellt werden. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos:

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

Emulierte Speicherdienstanforderung

Wenn Sie eine Anforderung für den emulierten Speicherdienst durchführen, geben Sie den Hostnamen des Emulators und den Blob-Dienstport als 127.0.0.1:10000an, gefolgt vom emulierten Namen des Speicherkontos:

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

Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für die lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können die folgenden zusätzlichen Parameter im Anforderungs-URI angeben:

Parameter Beschreibung
timeout Wahlfrei. Der parameter timeout wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob-Dienstvorgänge.

Anforderungsheader

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle beschrieben:

Anforderungsheader Beschreibung
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date oder x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Wahlfrei. Gibt die Version des Vorgangs an, der für diese Anforderung verwendet werden soll. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage-Dienste.
x-ms-blob-public-access Wahlfrei. Gibt an, ob auf Daten im Container öffentlich und zugriffsebene zugegriffen werden kann. Mögliche Werte sind:

- container: Gibt den vollständigen öffentlichen Lesezugriff für Container- und BLOB-Daten an. Clients können Blobs innerhalb des Containers über anonyme Anforderung aufzählen, container jedoch nicht im Speicherkonto aufzählen.
- blob: Gibt den öffentlichen Lesezugriff für Blobs an. Blob-Daten in diesem Container können über anonyme Anforderung gelesen werden, containerdaten sind jedoch nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über anonyme Anforderung aufzählen.

Wenn dieser Header nicht in der Anforderung enthalten ist, sind Containerdaten für den Kontobesitzer privat.

Beachten Sie, dass das Festlegen des öffentlichen Zugriffs für einen Container in einem Azure Premium Storage-Konto nicht zulässig ist.
x-ms-lease-id: <ID> Optional, Version 2012-02-12 und höher. Wenn sie angegeben ist, ist Set Container ACL nur erfolgreich, wenn die Lease des Containers aktiv ist und dieser ID entspricht. Wenn keine aktive Lease vorhanden ist oder die ID nicht übereinstimmt, wird 412 (Vorbedingung fehlgeschlagen) zurückgegeben.
x-ms-client-request-id Wahlfrei. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem 1-Kibibyte-Zeichenlimit (KiB) bereit, der in den Protokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert ist. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen von Azure Blob Storage.

Dieser Vorgang unterstützt auch die Verwendung von bedingten Headern, um den Vorgang nur auszuführen, wenn eine angegebene Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob-Dienstvorgänge.

Anforderungstext

Um eine gespeicherte Zugriffsrichtlinie anzugeben, stellen Sie eine eindeutige ID und Zugriffsrichtlinie im Anforderungstext für den Set Container ACL-Vorgang bereit.

Das SignedIdentifier-Element enthält den eindeutigen Bezeichner, wie im Id-Element angegeben, und die Details der Zugriffsrichtlinie, wie im AccessPolicy-Element angegeben. Die maximale Länge des eindeutigen Bezeichners beträgt 64 Zeichen.

Die Felder Start und Expiry müssen als UTC-Zeiten ausgedrückt werden und müssen einem gültigen ISO 8061-Format entsprechen. Unterstützte ISO 8061-Formate umfassen Folgendes:

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

Für den Datumsteil dieser Formate ist YYYY eine vierstellige Jahresdarstellung, MM eine zweistellige Monatsdarstellung und DD eine zweistellige Tagesdarstellung ist. Für den Zeitteil ist hh die Stundendarstellung in 24-Stunden-Notation, mm ist die zweistellige Minutendarstellung, ss die zweistellige Zweite Darstellung und fffffff die siebenstellige Millisekundendarstellung ist. Ein Zeitsenzeichner T trennt die Datums- und Uhrzeitabschnitte der Zeichenfolge, und ein Zeitzonen-Kennzeichner TZD gibt eine Zeitzone an.

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

Beispielanforderung

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>

Antwort

Die Antwort enthält einen HTTP-Statuscode und eine Reihe von Antwortheadern.

Statuscode

Ein erfolgreicher Vorgang gibt den Statuscode 200 (OK) zurück.

Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang enthält die folgenden Header. Die Antwort kann auch zusätzliche Standard-HTTP-Header enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwortheader Beschreibung
ETag Das ETag für den Container. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen.
Last-Modified Gibt das Datum und die Uhrzeit der letzten Änderung des Containers zurück. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Kopfzeilen.

Jeder Vorgang, der den Container oder seine Eigenschaften oder Metadaten ändert, aktualisiert den Zeitpunkt der letzten Änderung, einschließlich des Festlegens der Berechtigungen des Containers. Vorgänge für Blobs wirken sich nicht auf die Uhrzeit der letzten Änderung des Containers aus.
x-ms-request-id Identifiziert eindeutig die Anforderung, die durchgeführt wurde, und kann zur Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge
x-ms-version Gibt die Blob-Dienstversion an, die zum Ausführen der Anforderung verwendet wurde. Dieser Header wird für Anforderungen zurückgegeben, die mit Version 2009-09-19 und höher vorgenommen wurden.
Date Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der die Uhrzeit angibt, zu der die Antwort initiiert wurde.
x-ms-client-request-id Kann verwendet werden, um Anfragen und entsprechende Antworten zu behandeln. Der Wert dieses Headers ist gleich dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1.024 sichtbare ASCII-Zeichen enthält. Wenn der x-ms-client-request-id-Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Beispielantwort

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

Ermächtigung

Die Autorisierung ist beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage erforderlich. Sie können den Set Container ACL Vorgang wie unten beschrieben autorisieren.

Wichtig

Microsoft empfiehlt die Verwendung der Microsoft Entra-ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Die Microsoft Entra-ID bietet eine bessere Sicherheit und Benutzerfreundlichkeit im Vergleich zur Shared Key-Autorisierung.

Azure Storage unterstützt die Verwendung der Microsoft Entra-ID zum Autorisieren von Anforderungen an BLOB-Daten. Mit Der Microsoft Entra-ID können Sie azure role-based access control (Azure RBAC) verwenden, um Berechtigungen für einen Sicherheitsprinzipal zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine von Azure verwaltete Identität sein. Der Sicherheitsprinzipal wird von der Microsoft Entra-ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann dann verwendet werden, um eine Anforderung für den Blob-Dienst zu autorisieren.

Weitere Informationen zur Autorisierung mithilfe der Microsoft Entra-ID finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID.

Erlaubnisse

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder einen Dienstprinzipal erforderlich ist, um den Set Container ACL Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf BLOB-Daten.

Bemerkungen

Wenn Sie Berechtigungen für einen Container festlegen, werden die vorhandenen Berechtigungen ersetzt. Um die Berechtigungen des Containers zu aktualisieren, rufen Sie Container-ACL- auf, um alle Zugriffsrichtlinien abzurufen, die dem Container zugeordnet sind. Ändern Sie die Zugriffsrichtlinie, die Sie ändern möchten, und rufen Sie dann Set Container ACL mit dem vollständigen Satz von Daten auf, um die Aktualisierung durchzuführen.

Anonymen öffentlichen Zugriff auf Containerdaten

Um den anonymen öffentlichen Lesezugriff auf Containerdaten zu aktivieren, rufen Sie Set Container ACL auf, wobei der x-ms-blob-public-access Header auf container oder blobfestgelegt ist. Um den anonymen Zugriff zu deaktivieren, rufen Sie Set Container ACL auf, ohne den x-ms-blob-public-access Header anzugeben.

Wenn Sie x-ms-blob-public-access auf blobfestlegen, können Clients die folgenden Vorgänge anonym aufrufen:

Wenn Sie x-ms-blob-public-access auf containerfestlegen, können Clients die folgenden Vorgänge anonym aufrufen:

Einrichten von Zugriffsrichtlinien auf Containerebene

Eine gespeicherte Zugriffsrichtlinie kann die Startzeit, die Ablaufzeit und die Berechtigungen für die freigegebenen Zugriffssignaturen angeben, denen sie zugeordnet ist. Je nachdem, wie Sie den Zugriff auf Ihre Container- oder Blobressource steuern möchten, können Sie alle diese Parameter innerhalb der gespeicherten Zugriffsrichtlinie angeben und von der URL für die Signatur für den freigegebenen Zugriff weglassen. Auf diese Weise können Sie entweder das Verhalten der zugehörigen Signatur jederzeit ändern oder widerrufen. Sie können auch einen oder mehrere Zugriffsrichtlinienparameter innerhalb der gespeicherten Zugriffsrichtlinie und die anderen Auf der URL angeben. Schließlich können Sie alle Parameter für die URL angeben. In diesem Fall können Sie die gespeicherte Zugriffsrichtlinie verwenden, um die Signatur zu widerrufen, aber nicht, um das Verhalten zu ändern. Weitere Informationen finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.

Zusammen müssen die Signatur für den freigegebenen Zugriff und die Richtlinie für den gespeicherten Zugriff alle Felder enthalten, die zum Autorisieren der Signatur erforderlich sind. Wenn erforderliche Felder fehlen, schlägt die Anforderung fehl. Ebenso schlägt die Anforderung mit dem Statuscode 400 (ungültige Anforderung) fehl, wenn ein Feld sowohl in der URL der freigegebenen Zugriffssignatur als auch in der gespeicherten Zugriffsrichtlinie angegeben wird.

Höchstens können fünf separate Zugriffsrichtlinien für einen einzelnen Container jederzeit festgelegt werden. Wenn mehr als fünf Zugriffsrichtlinien im Anforderungstext übergeben werden, gibt der Dienst den Statuscode 400 (Ungültige Anforderung) zurück.

Eine Signatur für gemeinsam genutzten Zugriff kann auf einem Container oder einem Blob ausgegeben werden, unabhängig davon, ob Containerdaten für anonymen Lesezugriff verfügbar sind. Eine gemeinsame Zugriffssignatur bietet ein größeres Maß an Kontrolle darüber, wie, wann und für wen eine Ressource zugänglich gemacht wird.

Anmerkung

Wenn Sie eine gespeicherte Zugriffsrichtlinie für einen Container einrichten, kann die Richtlinie bis zu 30 Sekunden in Kraft treten. Während dieses Intervalls schlägt eine freigegebene Zugriffssignatur, die der gespeicherten Zugriffsrichtlinie zugeordnet ist, mit dem Statuscode 403 (Verboten) fehl.

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die BLOB Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Diese Anforderungen anfallen Gebühren pro Transaktion. Der Transaktionstyp wirkt sich auf die Belastung des Kontos aus. Lesen Sie z. B. Transaktionen, die einer anderen Abrechnungskategorie als dem Schreiben von Transaktionen zugerechnet werden. Die folgende Tabelle zeigt die Abrechnungskategorie für Set Container ACL Anforderungen basierend auf dem Speicherkontotyp:

Operation Speicherkontotyp Abrechnungskategorie
Festlegen der Container-ACL Premium-Block-BLOB
Standard general-purpose v2		 Andere Vorgänge
Festlegen der Container-ACL Standard general-purpose v1 Schreibvorgänge

Informationen zu den Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Pricing.

Siehe auch

Einschränken des Zugriffs auf Container und Blobs
Stellvertretungszugriff mit einer freigegebenen Zugriffssignatur
Erstellen und Verwenden einer freigegebenen Zugriffssignatur
Definieren einer gespeicherten Zugriffsrichtlinie
Container-ACL- abrufen
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob-Dienstfehlercodes