Ustawianie listy ACL kontenerów
Operacja Set Container ACL
ustawia uprawnienia dla określonego kontenera. Uprawnienia wskazują, czy obiekty blob w kontenerze mogą być dostępne publicznie.
Od wersji 2009-09-19 uprawnienia kontenera zapewniają następujące opcje zarządzania dostępem do kontenera:
pełny publiczny dostęp do odczytu: Kontener i dane obiektów blob można odczytywać za pośrednictwem żądania anonimowego. Klienci mogą wyliczać obiekty blob w kontenerze za pośrednictwem żądania anonimowego, ale nie mogą wyliczać kontenerów na koncie magazynu.
publiczny dostęp do odczytu tylko dla obiektów blob: dane obiektów blob w tym kontenerze mogą być odczytywane za pośrednictwem żądania anonimowego, ale dane kontenera nie są dostępne. Klienci nie mogą wyliczać obiektów blob w kontenerze za pośrednictwem żądania anonimowego.
Brak publicznego dostępu do odczytu: Kontener i dane obiektów blob mogą być odczytywane tylko przez właściciela konta.
Set Container ACL
również ustawia przechowywane zasady dostępu do użycia z sygnaturami dostępu współdzielonego. Aby uzyskać więcej informacji, zobacz Definiowanie przechowywanych zasad dostępu.
Cały publiczny dostęp do kontenera jest anonimowy, podobnie jak dostęp za pośrednictwem sygnatury dostępu współdzielonego.
Prosić
Żądanie Set Container ACL
można skonstruować w następujący sposób. Zalecamy używanie protokołu HTTPS. Zastąp myaccount nazwą konta magazynu:
Metoda | Identyfikator URI żądania | Wersja PROTOKOŁU HTTP |
---|---|---|
PUT |
https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl |
HTTP/1.1 |
Emulowane żądanie usługi magazynu
Podczas wykonywania żądania względem emulowanej usługi magazynu określ nazwę hosta emulatora i port usługi Blob Service jako 127.0.0.1:10000
, a następnie nazwę emulowanego konta magazynu:
Metoda | Identyfikator URI żądania | Wersja PROTOKOŁU HTTP |
---|---|---|
PUT |
http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl |
HTTP/1.1 |
Aby uzyskać więcej informacji, zobacz Use the Azurite emulator for local Azure Storage development.
Parametry identyfikatora URI
W identyfikatorze URI żądania można określić następujące dodatkowe parametry:
Parametr | Opis |
---|---|
timeout |
Fakultatywny. Parametr timeout jest wyrażony w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Blob Service. |
Nagłówki żądań
Wymagane i opcjonalne nagłówki żądań zostały opisane w poniższej tabeli:
Nagłówek żądania | Opis |
---|---|
Authorization |
Wymagane. Określa schemat autoryzacji, nazwę konta i podpis. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage. |
Date lub x-ms-date |
Wymagane. Określa uniwersalny czas koordynowany (UTC) dla żądania. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage. |
x-ms-version |
Fakultatywny. Określa wersję operacji do użycia dla tego żądania. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji dla usług Azure Storage. |
x-ms-blob-public-access |
Fakultatywny. Określa, czy dostęp do danych w kontenerze może być uzyskiwany publicznie i na poziomie dostępu. Możliwe wartości to: - container : określa pełny publiczny dostęp do odczytu dla danych kontenera i obiektów blob. Klienci mogą wyliczać obiekty blob w kontenerze za pośrednictwem żądania anonimowego, ale nie mogą wyliczać kontenerów na koncie magazynu.- blob: Określa publiczny dostęp do odczytu dla obiektów blob. Dane obiektów blob w tym kontenerze można odczytywać za pośrednictwem żądania anonimowego, ale dane kontenera nie są dostępne. Klienci nie mogą wyliczać obiektów blob w kontenerze za pośrednictwem żądania anonimowego.Jeśli ten nagłówek nie jest uwzględniony w żądaniu, dane kontenera są prywatne dla właściciela konta. Należy pamiętać, że ustawienie publicznego dostępu dla kontenera na koncie usługi Azure Premium Storage nie jest dozwolone. |
x-ms-lease-id: <ID> |
Opcjonalnie, wersja 2012-02-12 lub nowsza. Jeśli zostanie określony, Set Container ACL powiedzie się tylko wtedy, gdy dzierżawa kontenera jest aktywna i odpowiada temu identyfikatorowi. Jeśli nie ma aktywnej dzierżawy lub identyfikator nie jest zgodny, zwracany jest błąd 412 (Niepowodzenie warunku wstępnego). |
x-ms-client-request-id |
Fakultatywny. Zapewnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-kibibyte (KiB), który jest rejestrowany w dziennikach podczas konfigurowania rejestrowania. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer. Aby uzyskać więcej informacji, zobacz Monitor Azure Blob Storage. |
Ta operacja obsługuje również użycie nagłówków warunkowych do wykonania operacji tylko wtedy, gdy zostanie spełniony określony warunek. Aby uzyskać więcej informacji, zobacz Określanie nagłówków warunkowych dla operacji usługi Blob Service.
Treść żądania
Aby określić przechowywane zasady dostępu, podaj unikatowy identyfikator i zasady dostępu w treści żądania dla operacji Set Container ACL
.
Element SignedIdentifier
zawiera unikatowy identyfikator określony w elemecie Id
oraz szczegóły zasad dostępu, jak określono w elemecie AccessPolicy
. Maksymalna długość unikatowego identyfikatora wynosi 64 znaki.
Pola Start
i Expiry
muszą być wyrażone jako czas UTC i muszą być zgodne z prawidłowym formatem ISO 8061. Obsługiwane formaty ISO 8061 obejmują następujące elementy:
YYYY-MM-DD
YYYY-MM-DDThh:mmTZD
YYYY-MM-DDThh:mm:ssTZD
YYYY-MM-DDThh:mm:ss.fffffffTZD
W przypadku części dat tych formatów YYYY
jest czterocyfrową reprezentacją roku, MM
jest dwucyfrową reprezentacją miesiąca, a DD
jest dwucyfrową reprezentacją dnia. W przypadku części czasu hh
jest reprezentacją godziny w notacji 24-godzinnej, mm
jest reprezentacją dwucyfrową minuty, ss
jest dwucyfrową drugą reprezentacją, a fffffff
jest reprezentacją siedmiocyfrową milisekundową. Projektant czasu T
oddziela części daty i godziny ciągu, a projektant strefy czasowej TZD
określa strefę czasową.
<?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>
Przykładowe żądanie
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>
Odpowiedź
Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.
Kod stanu
Pomyślna operacja zwraca kod stanu 200 (OK).
Aby uzyskać więcej informacji na temat kodów stanu, zobacz Stan i kody błędów.
Nagłówki odpowiedzi
Odpowiedź dla tej operacji zawiera następujące nagłówki. Odpowiedź może również zawierać dodatkowe standardowe nagłówki HTTP. Wszystkie standardowe nagłówki są zgodne ze specyfikacją protokołu HTTP/1.1 .
Nagłówek odpowiedzi | Opis |
---|---|
ETag |
Element ETag dla kontenera. Jeśli wersja żądania to 2011-08-18 lub nowsza, wartość ETag jest ujęta w cudzysłów. |
Last-Modified |
Zwraca datę i godzinę ostatniej modyfikacji kontenera. Format daty jest zgodny z RFC 1123. Aby uzyskać więcej informacji, zobacz Reprezentowanie wartości daty/godziny w nagłówkach. Każda operacja modyfikującą kontener lub jego właściwości lub metadane aktualizuje czas ostatniej modyfikacji, w tym ustawienie uprawnień kontenera. Operacje na obiektach blob nie mają wpływu na czas ostatniej modyfikacji kontenera. |
x-ms-request-id |
Jednoznacznie identyfikuje żądanie, które zostało wykonane i może służyć do rozwiązywania problemów z żądaniem. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z operacjami interfejsu API |
x-ms-version |
Wskazuje wersję usługi Blob Service, która została użyta do wykonania żądania. Ten nagłówek jest zwracany dla żądań wysyłanych w wersji 2009-09-19 lub nowszej. |
Date |
Wartość daty/godziny UTC wygenerowana przez usługę, która wskazuje godzinę zainicjowania odpowiedzi. |
x-ms-client-request-id |
Może służyć do rozwiązywania problemów z żądaniami i odpowiadającymi odpowiedziami. Wartość tego nagłówka jest równa wartości nagłówka x-ms-client-request-id , jeśli znajduje się w żądaniu, a wartość nie zawiera więcej niż 1024 widocznych znaków ASCII. Jeśli nagłówek x-ms-client-request-id nie znajduje się w żądaniu, nie będzie on obecny w odpowiedzi. |
Przykładowa odpowiedź
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
Autoryzacja
Autoryzacja jest wymagana podczas wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. Możesz autoryzować operację Set Container ACL
zgodnie z poniższym opisem.
Ważny
Firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z tożsamościami zarządzanymi w celu autoryzowania żądań do usługi Azure Storage. Identyfikator Entra firmy Microsoft zapewnia lepsze zabezpieczenia i łatwość użycia w porównaniu z autoryzacją klucza współdzielonego.
Usługa Azure Storage obsługuje używanie identyfikatora Entra firmy Microsoft do autoryzowania żądań do danych obiektów blob. Za pomocą identyfikatora Entra firmy Microsoft możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień podmiotowi zabezpieczeń. Podmiot zabezpieczeń może być użytkownikiem, grupą, jednostką usługi aplikacji lub tożsamością zarządzaną platformy Azure. Podmiot zabezpieczeń jest uwierzytelniany przez identyfikator entra firmy Microsoft w celu zwrócenia tokenu OAuth 2.0. Token może następnie służyć do autoryzowania żądania względem usługi Blob Service.
Aby dowiedzieć się więcej o autoryzacji przy użyciu identyfikatora Entra firmy Microsoft, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu identyfikatora Entra firmy Microsoft.
Uprawnienia
Poniżej wymieniono akcję RBAC niezbędną dla użytkownika microsoft Entra, grupy, tożsamości zarządzanej lub jednostki usługi w celu wywołania operacji Set Container ACL
oraz najmniej uprzywilejowanej wbudowanej roli RBAC platformy Azure, która obejmuje tę akcję:
- akcję RBAC platformy Azure:Microsoft.Storage/storageAccounts/blobServices/containers/setAcl/action
- wbudowana rola Najmniej uprzywilejowana:właściciel danych obiektu blob usługi Storage
Aby dowiedzieć się więcej na temat przypisywania ról przy użyciu kontroli dostępu opartej na rolach platformy Azure, zobacz Assign an Azure role for access to blob data.
Uwagi
Po ustawieniu uprawnień dla kontenera istniejące uprawnienia zostaną zastąpione. Aby zaktualizować uprawnienia kontenera, wywołaj Pobierz listę ACL kontenera, aby pobrać wszystkie zasady dostępu skojarzone z kontenerem. Zmodyfikuj zasady dostępu, które chcesz zmienić, a następnie wywołaj Set Container ACL
z pełnym zestawem danych w celu przeprowadzenia aktualizacji.
Włączanie anonimowego dostępu publicznego na danych kontenera
Aby włączyć anonimowy publiczny dostęp do odczytu danych kontenera, wywołaj Set Container ACL
przy użyciu nagłówka x-ms-blob-public-access
ustawionego na container
lub blob
. Aby wyłączyć dostęp anonimowy, wywołaj Set Container ACL
bez określania nagłówka x-ms-blob-public-access
.
Jeśli ustawisz x-ms-blob-public-access
na blob
, klienci będą mogli anonimowo wywoływać następujące operacje:
pobierz obiektów blob
pobieranie metadanych obiektu blob
pobierz listę zablokowanych (tylko dla zatwierdzonej listy zablokowanych)
Jeśli ustawisz x-ms-blob-public-access
na container
, klienci będą mogli anonimowo wywoływać następujące operacje:
Operacje dostępu do obiektów blob wymienione w poprzedniej sekcji.
pobieranie metadanych kontenera
Ustanawianie zasad dostępu na poziomie kontenera
Przechowywane zasady dostępu mogą określać czas rozpoczęcia, czas wygaśnięcia i uprawnienia dla sygnatur dostępu współdzielonego, z którymi jest skojarzony. W zależności od tego, jak chcesz kontrolować dostęp do kontenera lub zasobu obiektu blob, możesz określić wszystkie te parametry w przechowywanych zasadach dostępu i pominąć je z adresu URL sygnatury dostępu współdzielonego. W tym celu można zmodyfikować zachowanie skojarzonego podpisu w dowolnym momencie lub odwołać go. Możesz też określić jeden lub więcej parametrów zasad dostępu w przechowywanych zasadach dostępu, a inne na adresie URL. Na koniec możesz określić wszystkie parametry w adresie URL. W takim przypadku można użyć przechowywanych zasad dostępu, aby odwołać podpis, ale nie zmodyfikować jego zachowania. Aby uzyskać więcej informacji, zobacz Definiowanie przechowywanych zasad dostępu.
Razem sygnatura dostępu współdzielonego i przechowywane zasady dostępu muszą zawierać wszystkie pola wymagane do autoryzowania podpisu. Jeśli brakuje jakichkolwiek wymaganych pól, żądanie zakończy się niepowodzeniem. Podobnie, jeśli pole jest określone zarówno w adresie URL sygnatury dostępu współdzielonego, jak i przechowywanych zasadach dostępu, żądanie kończy się niepowodzeniem z kodem stanu 400 (nieprawidłowe żądanie).
Co najwyżej pięć oddzielnych zasad dostępu można ustawić dla jednego kontenera w dowolnym momencie. Jeśli w treści żądania przekazano więcej niż pięć zasad dostępu, usługa zwraca kod stanu 400 (nieprawidłowe żądanie).
Sygnaturę dostępu współdzielonego można wydać w kontenerze lub obiekcie blob niezależnie od tego, czy dane kontenera są dostępne dla anonimowego dostępu do odczytu. Sygnatura dostępu współdzielonego zapewnia większą kontrolę nad tym, kiedy i kiedy zasób jest dostępny.
Nuta
Po ustanowieniu przechowywanych zasad dostępu w kontenerze zastosowanie zasad może potrwać do 30 sekund. W tym interwale, dopóki zasady nie staną się aktywne, sygnatura dostępu współdzielonego skojarzona z przechowywanymi zasadami dostępu kończy się niepowodzeniem z kodem stanu 403 (Zabronione).
Rozliczeń
Żądania cen mogą pochodzić od klientów korzystających z interfejsów API usługi Blob Storage bezpośrednio za pośrednictwem interfejsu API REST usługi Blob Storage lub z biblioteki klienta usługi Azure Storage. Te żądania naliczają opłaty za transakcję. Typ transakcji wpływa na sposób naliczania opłat za konto. Na przykład transakcje odczytu są naliczane do innej kategorii rozliczeniowej niż transakcje zapisu. W poniższej tabeli przedstawiono kategorię rozliczeń dla żądań Set Container ACL
na podstawie typu konta magazynu:
Operacja | Typ konta magazynu | Kategoria rozliczeń |
---|---|---|
Ustawianie listy ACL kontenerów | Blokowy obiekt blob w warstwie Premium Standardowa ogólnego przeznaczenia, wersja 2 |
Inne operacje |
Ustawianie listy ACL kontenerów | Standardowa ogólnego przeznaczenia, wersja 1 | Operacje zapisu |
Aby dowiedzieć się więcej o cenach dla określonej kategorii rozliczeń, zobacz Cennik usługi Azure Blob Storage.
Zobacz też
Ograniczanie dostępu do kontenerów i obiektów blob
Delegowanie dostępu za pomocą sygnatury dostępu współdzielonego
Tworzenie i używanie sygnatury dostępu współdzielonego
Definiowanie przechowywanych zasad dostępu
uzyskiwanie listy ACL kontenerów
autoryzowanie żądań do usługi Azure Storage
kody stanu i błędów
kody błędów usługi Blob Service