Tworzenie sygnatury dostępu współdzielonego do delegowania użytkowników

  • Artykuł

Token sygnatury dostępu współdzielonego (SAS) można zabezpieczyć w celu uzyskania dostępu do kontenera, katalogu lub obiektu blob przy użyciu poświadczeń Microsoft Entra lub klucza konta. Sygnatura dostępu współdzielonego zabezpieczona przy użyciu poświadczeń Microsoft Entra jest nazywana sygnaturą dostępu współdzielonego delegowania użytkownika. Najlepszym rozwiązaniem w zakresie zabezpieczeń jest użycie Microsoft Entra poświadczeń, jeśli jest to możliwe, a nie klucza konta, co może być łatwiejsze do naruszenia zabezpieczeń. Gdy projekt aplikacji wymaga sygnatur dostępu współdzielonego, użyj poświadczeń Microsoft Entra, aby utworzyć sygnaturę dostępu współdzielonego delegowania użytkownika, aby zapewnić lepsze zabezpieczenia.

Każda sygnatura dostępu współdzielonego jest podpisana przy użyciu klucza. Aby utworzyć sygnaturę dostępu współdzielonego delegowania użytkownika, należy najpierw zażądać klucza delegowania użytkownika, którego następnie użyjesz do podpisania sygnatury dostępu współdzielonego. Klucz delegowania użytkownika jest analogiczny do klucza konta używanego do podpisywania sygnatury dostępu współdzielonego usługi lub sygnatury dostępu współdzielonego konta, z tą różnicą, że opiera się na poświadczeniach Microsoft Entra. Aby zażądać klucza delegowania użytkownika, wywołaj operację Pobierz klucz delegowania użytkownika . Następnie możesz użyć klucza delegowania użytkownika do utworzenia sygnatury dostępu współdzielonego.

Sygnatura dostępu współdzielonego delegowania użytkownika jest obsługiwana w przypadku Azure Blob Storage i Azure Data Lake Storage Gen2. Przechowywane zasady dostępu nie są obsługiwane w przypadku sygnatury dostępu współdzielonego delegowania użytkownika.

Przestroga

Sygnatury dostępu współdzielonego to klucze, które udzielają uprawnień do zasobów magazynu, i należy je chronić tak samo jak klucz konta. Ważne jest, aby chronić sygnaturę dostępu współdzielonego przed złośliwym lub niezamierzonym użyciem. Użyj uznania w dystrybucji sygnatury dostępu współdzielonego i zaplanuj odwołanie naruszonej sygnatury dostępu współdzielonego. Operacje korzystające z sygnatur dostępu współdzielonego powinny być wykonywane tylko za pośrednictwem połączenia HTTPS, a identyfikatory URI sygnatur dostępu współdzielonego powinny być dystrybuowane tylko na bezpiecznym połączeniu, takim jak HTTPS.

Aby uzyskać informacje na temat zabezpieczania sygnatury dostępu współdzielonego przy użyciu klucza konta, zobacz Tworzenie sygnatury dostępu współdzielonego usługi i Tworzenie sygnatury dostępu współdzielonego konta.

Obsługa sygnatur dostępu współdzielonego delegowania użytkownika dla dostępu w zakresie katalogu

Sygnatura dostępu współdzielonego delegowania użytkownika obsługuje zakres katalogu (sr=d), jeśli wersja autoryzacji (sv) to 2020-02-10 lub nowsza, a hierarchiczna przestrzeń nazw (HNS) jest włączona. Semantyka zakresu katalogu (sr=d) jest podobna do zakresu kontenera (sr=c), z tą różnicą, że dostęp jest ograniczony do katalogu i wszystkich plików i podkatalogów w nim. Po sr=d określeniu sdd parametr zapytania jest również wymagany.

Format ciągu do podpisania dla autoryzacji w wersji 2020-02-10 jest niezmieniony.

Obsługa sygnatury dostępu współdzielonego delegowania użytkownika dla identyfikatora OID użytkownika

Sygnatura dostępu współdzielonego delegowania użytkownika obsługuje opcjonalny identyfikator obiektu użytkownika (OID), który jest przenoszony w parametrze saoid lub suoid , gdy wersja autoryzacji (sv) to 2020-02-10 lub nowsza. Ten opcjonalny parametr udostępnia rozszerzony model autoryzacji dla obciążeń klastra z wieloma użytkownikami, takich jak Hadoop i Spark.

Tokeny SAS można ograniczyć do określonej operacji systemu plików i użytkownika, co zapewnia mniej narażony token dostępu, który jest bezpieczniejszy do dystrybucji w klastrze wielu użytkowników. Jednym z przypadków użycia tych funkcji jest integracja sterownika Hadoop ABFS z platformą Apache Ranger.

Autoryzacja sygnatury dostępu współdzielonego delegowania użytkownika

Gdy klient uzyskuje dostęp do zasobu usługi Blob Storage przy użyciu sygnatury dostępu współdzielonego delegowania użytkownika, żądanie do usługi Azure Storage jest autoryzowane przy użyciu poświadczeń Microsoft Entra, które zostały użyte do utworzenia sygnatury dostępu współdzielonego. Uprawnienia kontroli dostępu opartej na rolach (RBAC) przyznane dla tego konta Microsoft Entra wraz z uprawnieniami jawnie przyznanymi dla sygnatury dostępu współdzielonego określają dostęp klienta do zasobu. Takie podejście zapewnia dodatkowy poziom zabezpieczeń i pomaga uniknąć konieczności przechowywania klucza dostępu do konta przy użyciu kodu aplikacji. Z tych powodów tworzenie sygnatury dostępu współdzielonego przy użyciu poświadczeń Microsoft Entra jest najlepszym rozwiązaniem w zakresie zabezpieczeń.

Uprawnienia przyznane klientowi, który posiada sygnaturę dostępu współdzielonego, są częścią wspólną uprawnień, które zostały przyznane podmiotowi zabezpieczeń, który zażądał klucza delegowania użytkownika i uprawnieniami, które zostały przyznane zasobowi w tokenie SAS przy użyciu signedPermissions pola (sp). Jeśli uprawnienie przyznane podmiotowi zabezpieczeń za pośrednictwem kontroli dostępu opartej na rolach nie zostanie również przyznane w tokenie SYGNATURy dostępu współdzielonego, to uprawnienie nie zostanie przyznane klientowi, który próbuje użyć sygnatury dostępu współdzielonego w celu uzyskania dostępu do zasobu. Podczas tworzenia sygnatury dostępu współdzielonego delegowania użytkownika upewnij się, że uprawnienia przyznane za pośrednictwem kontroli dostępu opartej na rolach i uprawnienia przyznane za pośrednictwem tokenu SAS są wyrównane do poziomu dostępu wymaganego przez klienta.

Aby utworzyć sygnaturę dostępu współdzielonego delegowania użytkownika, wykonaj następujące czynności:

  1. Użyj kontroli dostępu opartej na rolach, aby udzielić żądanych uprawnień podmiotowi zabezpieczeń, który zażąda klucza delegowania użytkownika.
  2. Uzyskaj token OAuth 2.0 z Tożsamość Microsoft Entra.
  3. Użyj tokenu, aby zażądać klucza delegowania użytkownika, wywołując operację Pobierz klucz delegowania użytkownika .
  4. Użyj klucza delegowania użytkownika, aby skonstruować token SAS z odpowiednimi polami.

Przypisywanie uprawnień przy użyciu kontroli dostępu opartej na rolach

Podmiot zabezpieczeń, który żąda klucza delegowania użytkownika, musi mieć odpowiednie uprawnienia. Jednostka zabezpieczeń Tożsamość Microsoft Entra może być użytkownikiem, grupą, jednostką usługi lub tożsamością zarządzaną.

Aby zażądać klucza delegowania użytkownika, należy przypisać do podmiotu zabezpieczeń akcję Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey . Następujące wbudowane role RBAC obejmują akcję Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey , jawnie lub w ramach definicji symboli wieloznacznych:

Ponieważ operacja Pobierz klucz delegowania użytkownika działa na poziomie konta magazynu, akcja Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey musi być ograniczona na poziomie konta magazynu, grupy zasobów lub subskrypcji. Jeśli podmiot zabezpieczeń ma przypisaną dowolną z wcześniej wymienionych, wbudowanych ról lub roli niestandardowej, która zawiera akcję Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey , na poziomie konta magazynu, grupy zasobów lub subskrypcji, podmiot zabezpieczeń może zażądać klucza delegowania użytkownika.

Jeśli podmiot zabezpieczeń ma przypisaną rolę, która zezwala na dostęp do danych, ale jest ograniczona do poziomu kontenera, możesz dodatkowo przypisać rolę delegatora obiektów blob usługi Storage do podmiotu zabezpieczeń na poziomie konta magazynu, grupy zasobów lub subskrypcji. Rola Delegator obiektów blob usługi Storage udziela uprawnień podmiotu zabezpieczeń w celu żądania klucza delegowania użytkownika.

Aby uzyskać więcej informacji na temat ról RBAC dla usługi Azure Storage, zobacz Autoryzowanie za pomocą usługi Azure Active Directory.

Uzyskiwanie tokenu OAuth 2.0

Aby uzyskać klucz delegowania użytkownika, najpierw zażądaj tokenu OAuth 2.0 z Tożsamość Microsoft Entra. Podaj token ze schematem elementu nośnego, aby autoryzować wywołanie operacji Pobierz klucz delegowania użytkownika . Aby uzyskać więcej informacji na temat żądania tokenu OAuth z Tożsamość Microsoft Entra, zobacz Przepływy uwierzytelniania i scenariusze aplikacji.

Żądanie klucza delegowania użytkownika

Wywołanie operacji Pobierz klucz delegowania użytkownika zwraca klucz jako zestaw wartości, które są używane jako parametry w tokenie SAS delegowania użytkownika. Te parametry są opisane w dokumentacji Uzyskiwanie klucza delegowania użytkownika i w następnej sekcji "Konstruowanie sygnatury dostępu współdzielonego delegowania użytkownika".

Gdy klient żąda klucza delegowania użytkownika przy użyciu tokenu OAuth 2.0, usługa Azure Storage zwraca klucz delegowania użytkownika w imieniu podmiotu zabezpieczeń. Sygnatura dostępu współdzielonego utworzona przy użyciu klucza delegowania użytkownika ma przyznane uprawnienia podmiotowi zabezpieczeń.

Po utworzeniu klucza delegowania użytkownika można go użyć do utworzenia dowolnej liczby sygnatur dostępu współdzielonego delegowania użytkownika w okresie istnienia klucza. Klucz delegowania użytkownika jest niezależny od tokenu OAuth 2.0 używanego do jego uzyskania, dlatego token nie musi być odnawiany tak długo, jak klucz jest nadal prawidłowy. Możesz określić, że klucz jest ważny przez maksymalnie siedem dni.

Konstruowanie sygnatury dostępu współdzielonego delegowania użytkownika

Poniższa tabela zawiera podsumowanie pól obsługiwanych dla tokenu SAS delegowania użytkownika. Kolejne sekcje zawierają dodatkowe szczegóły dotyczące sposobu określania tych parametrów.

Nazwa pola sygnatury dostępu współdzielonego Parametr tokenu sygnatury dostępu współdzielonego Wymagane lub opcjonalne Obsługa wersji Opis
signedVersion sv Wymagane 2018-11-09 i nowsze Wskazuje wersję usługi używanej do konstruowania pola podpisu. Określa również wersję usługi, która obsługuje żądania wykonywane za pomocą tej sygnatury dostępu współdzielonego.
signedResource sr Wymagane Wszystko Określa, które zasoby obiektów blob są dostępne za pośrednictwem sygnatury dostępu współdzielonego.
signedStart st Opcjonalne Wszystko Opcjonalny. Czas ważności sygnatury dostępu współdzielonego wyrażony w jednym z akceptowanych formatów ISO 8601 UTC. Jeśli ta wartość zostanie pominięta, bieżąca godzina UTC jest używana jako godzina rozpoczęcia. Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Formatowanie wartości datetime.
signedExpiry se Wymagane Wszystko Czas, gdy sygnatura dostępu współdzielonego stanie się nieprawidłowa, wyrażona w jednym z akceptowanych formatów ISO 8601 UTC. Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Formatowanie wartości datetime.
signedPermissions sp Wymagane Wszystko Wskazuje operacje, które klient posiadający sygnaturę dostępu współdzielonego może wykonywać na zasobie. Uprawnienia mogą być łączone.
signedIp sip Opcjonalne 2015-04-05 i nowsze Określa adres IP lub zakres obejmujący adresy IP, z których mają być akceptowane żądania. Podczas określania zakresu należy pamiętać, że zakres jest inkluzywny. Obsługiwane są tylko adresy IPv4.

Na przykład: sip=168.1.5.65 lub sip=168.1.5.60-168.1.5.70.
signedProtocol spr Opcjonalne 2015-04-05 i nowsze Określa protokół dozwolony dla żądania z sygnaturą dostępu współdzielonego. Dołącz to pole, aby wymagać, aby żądania wysyłane przy użyciu tokenu SAS używały protokołu HTTPS.
signedObjectId skoid Wymagane 2018-11-09 i nowsze Identyfikuje podmiot zabezpieczeń Microsoft Entra.
signedTenantId sktid Wymagane 2018-11-09 i nowsze Określa dzierżawę Microsoft Entra, w której zdefiniowano podmiot zabezpieczeń.
signedKeyStartTime skt Opcjonalny. 2018-11-09 i nowsze Wartość jest zwracana przez operację Pobierz klucz delegowania użytkownika . Wskazuje początek okresu istnienia klucza delegowania użytkownika wyrażony w jednym z akceptowanych formatów ISO 8601 UTC. Jeśli pominięto wartość, przyjmuje się bieżącą godzinę. Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Formatowanie wartości datetime.
signedKeyExpiryTime ske Wymagane 2018-11-09 i nowsze Wartość jest zwracana przez operację Pobierz klucz delegowania użytkownika . Wskazuje koniec okresu istnienia klucza delegowania użytkownika wyrażony w jednym z akceptowanych formatów ISO 8601 UTC. Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Formatowanie wartości datetime.
signedKeyVersion skv Wymagane 2018-11-09 i nowsze Wartość jest zwracana przez operację Pobierz klucz delegowania użytkownika . Określa wersję usługi magazynu, która została użyta do pobrania klucza delegowania użytkownika. To pole musi określać wersję 2018-11-09 lub nowszą.
signedKeyService sks Wymagane 2018-11-09 i nowsze Wskazuje usługę, dla której klucz delegowania użytkownika jest prawidłowy. Obecnie obsługiwana jest tylko usługa Blob Storage.
signedAuthorizedObjectId saoid Opcjonalne 2020-02-10 i nowsze Określa identyfikator obiektu dla podmiotu zabezpieczeń Microsoft Entra, który jest autoryzowany przez właściciela klucza delegowania użytkownika do wykonania akcji przyznanej przez token SAS. Nie jest przeprowadzane dodatkowe sprawdzanie uprawnień na listach kontroli dostępu (ACL) dla przenośnego interfejsu systemu operacyjnego (POSIX).
signedUnauthorizedObjectId suoid Opcjonalne 2020-02-10 i nowsze Określa identyfikator obiektu dla Microsoft Entra podmiotu zabezpieczeń, gdy włączono hierarchiczną przestrzeń nazw. Usługa Azure Storage przeprowadza sprawdzanie listy ACL POSIX względem identyfikatora obiektu, zanim autoryzuje operację.
signedCorrelationId scid Opcjonalne 2020-02-10 i nowsze Skoreluj dzienniki inspekcji magazynu z dziennikami inspekcji używanymi przez podmiot zabezpieczeń, który generuje i dystrybuuje sygnaturę dostępu współdzielonego.
signedDirectoryDepth sdd Wymagane, gdy sr=d 2020-02-10 i nowsze Wskazuje liczbę katalogów w folderze głównym katalogu określonego w canonicalizedResource polu ciągu do znaku.
signedEncryptionScope ses Opcjonalne 2020-12-06 i nowsze Wskazuje zakres szyfrowania używany do szyfrowania zawartości żądania.
signature sig Wymagane Wszystko Podpis to kod uwierzytelniania komunikatów oparty na skrótach (HMAC), który jest obliczany na podstawie ciągu do podpisania i klucza przy użyciu algorytmu SHA256, a następnie zakodowany przy użyciu kodowania Base64.
Cache-Control nagłówek odpowiedzi rscc Opcjonalne 2013-08-15 i nowsze Usługa Azure Storage ustawia Cache-Control nagłówek odpowiedzi na wartość określoną w tokenie SAS.
Content-Disposition nagłówek odpowiedzi rscd Opcjonalne 2013-08-15 i nowsze Usługa Azure Storage ustawia Content-Disposition nagłówek odpowiedzi na wartość określoną w tokenie SAS.
Content-Encoding nagłówek odpowiedzi rsce Opcjonalne 2013-08-15 i nowsze Usługa Azure Storage ustawia Content-Encoding nagłówek odpowiedzi na wartość określoną w tokenie SAS.
Content-Language nagłówek odpowiedzi rscl Opcjonalne 2013-08-15 i nowsze Usługa Azure Storage ustawia Content-Language nagłówek odpowiedzi na wartość określoną w tokenie SAS.
Content-Type nagłówek odpowiedzi rsct Opcjonalne 2013-08-15 i nowsze Usługa Azure Storage ustawia Content-Type nagłówek odpowiedzi na wartość określoną w tokenie SAS.

Określanie pola podpisanej wersji

signedVersion Wymagane pole (sv) określa wersję usługi dla sygnatury dostępu współdzielonego. Ta wartość wskazuje wersję usługi używanej do konstruowania signature pola i określa wersję usługi, która obsługuje żądanie wykonane za pomocą tego sygnatury dostępu współdzielonego. Wartość sv pola musi być w wersji 2018-11-09 lub nowszej.

Określanie pola podpisanego zasobu

Wymagane signedResource pole (sr) określa, które zasoby są dostępne za pośrednictwem sygnatury dostępu współdzielonego. W poniższej tabeli opisano sposób odwoływania się do obiektu blob, kontenera lub zasobu katalogu w tokenie SYGNATURy dostępu współdzielonego:

Zasób Wartość parametru Obsługiwane wersje Opis
Obiekt blob b Wszystko Przyznaje dostęp do zawartości i metadanych obiektu blob.
Wersja obiektu blob Bv 2018-11-09 i nowsze Udziela dostępu do zawartości i metadanych wersji obiektu blob, ale nie podstawowego obiektu blob.
Migawka obiektu blob B 2018-11-09 i nowsze Udziela dostępu do zawartości i metadanych migawki obiektu blob, ale nie podstawowego obiektu blob.
Kontener c Wszystko Udziela dostępu do zawartości i metadanych dowolnego obiektu blob w kontenerze oraz do listy obiektów blob w kontenerze.
Directory d 2020-02-10 i nowsze Przyznaje dostęp do zawartości i metadanych dowolnego obiektu blob w katalogu oraz do listy obiektów blob w katalogu na koncie magazynu z włączoną hierarchiczną przestrzenią nazw. Jeśli dla pola określono signedResource katalog, signedDirectoryDepth parametr (sdd) jest również wymagany. Katalog jest zawsze w kontenerze.

Określanie czasu trwania ważności podpisu

Pola signedStart (st) i signedExpiry (se) wskazują czas rozpoczęcia i wygaśnięcia sygnatury dostępu współdzielonego. Pole signedExpiry jest wymagane. Pole signedStart jest opcjonalne. Jeśli zostanie pominięty, bieżąca godzina UTC jest używana jako godzina rozpoczęcia.

W przypadku sygnatury dostępu współdzielonego delegowania użytkownika czas rozpoczęcia i wygaśnięcia sygnatury dostępu współdzielonego powinien mieścić się w przedziale czasu zdefiniowanym dla klucza delegowania użytkownika. Jeśli klient spróbuje użyć sygnatury dostępu współdzielonego po wygaśnięciu klucza delegowania użytkownika, sygnatura dostępu współdzielonego zakończy się niepowodzeniem z powodu błędu autoryzacji, niezależnie od tego, czy sama sygnatura dostępu współdzielonego jest nadal prawidłowa.

Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Formatowanie wartości datetime.

Określanie uprawnień

Uprawnienia określone dla signedPermissions pola (sp) w tokenie SYGNATURy dostępu współdzielonego wskazują operacje, które klient posiadający sygnaturę dostępu współdzielonego może wykonać na zasobie.

Uprawnienia można połączyć, aby umożliwić klientowi wykonywanie wielu operacji z tą samą sygnaturą dostępu współdzielonego. Podczas konstruowania sygnatury dostępu współdzielonego należy uwzględnić uprawnienia w następującej kolejności:

racwdxltmeop

Przykłady prawidłowych ustawień uprawnień dla kontenera to rw, , rd, wdrl, wli rl. Przykłady nieprawidłowych ustawień to wr, dr, lri dw. Określanie oznaczenia uprawnień więcej niż raz jest niedozwolone.

Sygnatura dostępu współdzielonego delegowania użytkownika nie może udzielić dostępu do niektórych operacji:

  • Kontenerów nie można tworzyć, usuwać ani wyświetlać.
  • Nie można odczytywać ani zapisywać metadanych i właściwości kontenera.
  • Nie można dzierżawić kontenerów.

Aby utworzyć sygnaturę dostępu współdzielonego, która udziela dostępu do tych operacji, użyj sygnatury dostępu współdzielonego konta. Aby uzyskać więcej informacji, zobacz Tworzenie sygnatury dostępu współdzielonego konta.

Uprawnienia obsługiwane dla każdego typu zasobu opisano w poniższej tabeli:

Uprawnienie Symbol identyfikatora URI Zasób Obsługa wersji Dozwolone operacje
Read r Kontener
Directory
Obiekt blob		 Wszystko Odczytywanie zawartości, listy bloków, właściwości i metadanych dowolnego obiektu blob w kontenerze lub katalogu. Użyj obiektu blob jako źródła operacji kopiowania.
Dodaj a Kontener
Directory
Obiekt blob		 Wszystko Dodaj blok do uzupełnialnych obiektów blob.
Utwórz c Kontener
Directory
Obiekt blob		 Wszystko Napisz nowy obiekt blob, utwórz migawkę obiektu blob lub skopiuj obiekt blob do nowego obiektu blob.
Write w Kontener
Directory
Obiekt blob		 Wszystko Tworzenie lub zapisywanie zawartości, właściwości, metadanych lub listy zablokowanych. Migawka lub dzierżawa obiektu blob. Zmień rozmiar obiektu blob (tylko stronicowy obiekt blob). Użyj obiektu blob jako miejsca docelowego operacji kopiowania.
Usuń d Kontener
Directory
Obiekt blob		 Wszystko Usuwanie obiektu blob. W przypadku wersji 2017-07-29 lub nowszej uprawnienie Usuwanie umożliwia również przerywanie dzierżawy obiektu blob. Aby uzyskać więcej informacji, zobacz operację dzierżawy obiektu blob .
Usuń wersję x Kontener
Obiekt blob		 2019-12-12 i nowsze Usuń wersję obiektu blob.
Trwałe usuwanie Y Obiekt blob 2020-02-10 i nowsze Trwałe usunięcie migawki lub wersji obiektu blob.
Lista l Kontener
Directory		 Wszystko Wyświetlanie listy obiektów blob niecyklicznie.
Tagi t Obiekt blob 2019-12-12 i nowsze Odczytywanie lub zapisywanie tagów w obiekcie blob.
Move m Kontener
Directory
Obiekt blob		 2020-02-10 i nowsze Przenieś obiekt blob lub katalog i jego zawartość do nowej lokalizacji. Ta operacja może być opcjonalnie ograniczona do właściciela podrzędnego obiektu blob, katalogu lub katalogu nadrzędnego, jeśli saoid parametr jest uwzględniony w tokenie sygnatury dostępu współdzielonego, a bit sticky jest ustawiony w katalogu nadrzędnym.
Wykonaj polecenie e Kontener
Directory
Obiekt blob		 2020-02-10 i nowsze Pobierz właściwości systemu i, jeśli hierarchiczna przestrzeń nazw jest włączona dla konta magazynu, pobierz listę ACL POSIX obiektu blob. Jeśli hierarchiczna przestrzeń nazw jest włączona, a obiekt wywołujący jest właścicielem obiektu blob, to uprawnienie przyznaje możliwość ustawiania grupy właścicieli, uprawnień POSIX i listy ACL obiektu blob POSIX. Nie zezwala obiekt wywołujący na odczytywanie metadanych zdefiniowanych przez użytkownika.
Własność o Kontener
Directory
Obiekt blob		 2020-02-10 i nowsze Gdy hierarchiczna przestrzeń nazw jest włączona, to uprawnienie umożliwia obiektowi wywołującego ustawienie właściciela lub grupy będącej właścicielem albo działanie jako właściciel, gdy obiekt wywołujący zmieni nazwę lub usunie katalog lub obiekt blob w katalogu, który ma ustawiony bit sticky.
Uprawnienia p Kontener
Directory
Obiekt blob		 2020-02-10 i nowsze Gdy hierarchiczna przestrzeń nazw jest włączona, to uprawnienie umożliwia wywołującym ustawianie uprawnień i list ACL POSIX w katalogach i obiektach blob.
Ustawianie zasad niezmienności mogę Kontener
Obiekt blob		 2020-06-12 i nowsze Ustaw lub usuń zasady niezmienności lub blokadę prawną obiektu blob.

Określanie adresu IP lub zakresu adresów IP

Opcjonalne signedIp pole (sip) określa publiczny adres IP lub zakres publicznych adresów IP, z których mają być akceptowane żądania. Jeśli adres IP, z którego pochodzi żądanie, nie jest zgodny z adresem IP lub zakresem adresów określonym w tokenie SAS, żądanie nie jest autoryzowane. Obsługiwane są tylko adresy IPv4.

Po określeniu zakresu adresów IP zakres jest włącznie. Na przykład określenie lub sip=168.1.5.60-168.1.5.70 na sygnaturze dostępu współdzielonego sip=168.1.5.65 ogranicza żądanie do tych adresów IP.

W poniższej tabeli opisano, czy należy uwzględnić signedIp pole w tokenie SAS dla danego scenariusza, na podstawie środowiska klienta i lokalizacji konta magazynu.

Środowisko klienta Lokalizacja konta magazynu Zalecenie
Klient uruchomiony na platformie Azure W tym samym regionie co klient Sygnatura dostępu współdzielonego udostępniona klientowi w tym scenariuszu nie powinna zawierać wychodzącego adresu IP dla signedIp pola. Żądania wysyłane z tego samego regionu przy użyciu sygnatury dostępu współdzielonego z określonym adresem IP wychodzącym zakończy się niepowodzeniem.

Zamiast tego użyj sieci wirtualnej platformy Azure do zarządzania ograniczeniami zabezpieczeń sieci. Żądania do usługi Azure Storage z tego samego regionu zawsze odbywają się za pośrednictwem prywatnego adresu IP. Aby uzyskać więcej informacji, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.
Klient uruchomiony na platformie Azure W innym regionie od klienta Sygnatura dostępu współdzielonego udostępniona klientowi w tym scenariuszu może zawierać publiczny adres IP lub zakres adresów dla signedIp pola. Żądania wysyłane za pomocą sygnatury dostępu współdzielonego muszą pochodzić z określonego adresu IP lub zakresu adresów.
Klient działający lokalnie lub w innym środowisku chmury W dowolnym regionie świadczenia usługi Azure Sygnatura dostępu współdzielonego udostępniona klientowi w tym scenariuszu może zawierać publiczny adres IP lub zakres adresów dla signedIp pola. Żądania wysyłane za pomocą sygnatury dostępu współdzielonego muszą pochodzić z określonego adresu IP lub zakresu adresów.

Jeśli żądanie przechodzi przez serwer proxy lub bramę, podaj publiczny wychodzący adres IP tego serwera proxy lub bramy dla signedIp pola.

Określanie protokołu HTTP

Pole opcjonalne signedProtocol (spr) określa protokół, który jest dozwolony dla żądań, które są wykonywane z sygnaturą dostępu współdzielonego. Możliwe wartości to tylko HTTPS i HTTP (https,http) lub HTTPS (https). Wartość domyślna to https,http.

Uwaga

Nie można określić protokołu HTTP dla spr pola.

Określanie podpisanego identyfikatora obiektu

Pole signedObjectId (skoid) jest wymagane dla sygnatury dostępu współdzielonego delegowania użytkownika. Operacja Pobierz klucz delegowania użytkownika zwraca tę wartość w ramach odpowiedzi. Podpisany identyfikator obiektu to wartość identyfikatora GUID, która obsługuje niezmienny identyfikator podmiotu zabezpieczeń w Platforma tożsamości Microsoft.

Określanie podpisanego identyfikatora dzierżawy

Pole signedTenantId (sktid) jest wymagane dla sygnatury dostępu współdzielonego delegowania użytkownika. Operacja Pobierz klucz delegowania użytkownika zwraca tę wartość w ramach odpowiedzi. Podpisany identyfikator dzierżawy to wartość identyfikatora GUID reprezentująca dzierżawę Microsoft Entra, w której zdefiniowano podmiot zabezpieczeń.

Określ czas rozpoczęcia podpisanego klucza

Opcjonalne signedKeyStartTime pole (skt) wskazuje początek okresu istnienia klucza delegowania użytkownika w formacie DATY ISO. Operacja Pobierz klucz delegowania użytkownika zwraca tę wartość w ramach odpowiedzi. Jeśli godzina rozpoczęcia zostanie pominięta, zakłada się, że czas rozpoczęcia klucza podpisanego jest bieżący.

Określanie czasu wygaśnięcia podpisanego klucza

Pole signedKeyExpiryTime (ske) jest wymagane dla sygnatury dostępu współdzielonego delegowania użytkownika w formacie DATY ISO. Operacja Pobierz klucz delegowania użytkownika zwraca tę wartość w ramach odpowiedzi. Czas wygaśnięcia podpisanego klucza wskazuje koniec okresu istnienia klucza delegowania użytkownika. Wartość czasu wygaśnięcia może wynosić maksymalnie siedem dni od momentu rozpoczęcia sygnatury dostępu współdzielonego.

Określanie podpisanej usługi klucza

Pole signedKeyService (sks) jest wymagane dla sygnatury dostępu współdzielonego delegowania użytkownika. Operacja Pobierz klucz delegowania użytkownika zwraca tę wartość w ramach odpowiedzi. Pole usługi podpisanego klucza wskazuje usługę, dla której klucz delegowania użytkownika jest prawidłowy. Wartość pola usługi podpisanego klucza dla usługi Blob Storage to b.

Określanie podpisanej wersji klucza

Pole signedkeyversion (skv) jest wymagane dla sygnatury dostępu współdzielonego delegowania użytkownika. Operacja Pobierz klucz delegowania użytkownika zwraca tę wartość w ramach odpowiedzi. Pole signedkeyversion określa wersję usługi magazynu używaną do pobierania klucza delegowania użytkownika. To pole musi określać wersję 2018-11-09 lub nowszą.

Określanie podpisanego identyfikatora obiektu dla podmiotu zabezpieczeń

Opcjonalne signedAuthorizedObjectId pola (saoid) i signedUnauthorizedObjectId (suoid) umożliwiają integrację z usługami Apache Hadoop i Apache Ranger na potrzeby obciążeń Azure Data Lake Storage Gen2. Użyj jednego z tych pól w tokenie sygnatury dostępu współdzielonego, aby określić identyfikator obiektu dla podmiotu zabezpieczeń:

  • Pole saoid określa identyfikator obiektu dla podmiotu zabezpieczeń Microsoft Entra autoryzowanego przez właściciela klucza delegowania użytkownika w celu wykonania akcji przyznanej przez token SAS. Usługa Azure Storage weryfikuje token sygnatury dostępu współdzielonego i zapewnia, że właściciel klucza delegowania użytkownika ma wymagane uprawnienia, zanim usługa Azure Storage udzieli dostępu. Nie jest wykonywane dodatkowe sprawdzanie uprawnień na listach ACL POSIX.
  • Pole suoid określa identyfikator obiektu dla podmiotu zabezpieczeń Microsoft Entra, gdy hierarchiczna przestrzeń nazw jest włączona dla konta magazynu. Pole suoid jest prawidłowe tylko dla kont, które mają hierarchiczną przestrzeń nazw. suoid Po dołączeniu pola do tokenu SYGNATURy dostępu współdzielonego usługa Azure Storage wykonuje sprawdzanie listy ACL POSIX względem identyfikatora obiektu, zanim autoryzuje operację. Jeśli to sprawdzanie listy ACL nie powiedzie się, operacja zakończy się niepowodzeniem. Hierarchiczna przestrzeń nazw musi być włączona dla konta magazynu, jeśli suoid pole jest uwzględnione w tokenie SYGNATURY dostępu współdzielonego. W przeciwnym razie sprawdzanie uprawnień zakończy się niepowodzeniem z powodu błędu autoryzacji.

Identyfikator obiektu podmiotu zabezpieczeń, który żąda klucza delegowania użytkownika, jest przechwytywany w wymaganym skoid polu. Aby określić identyfikator obiektu w tokenie sygnatury dostępu współdzielonego z saoid polem lub suoid , podmiot zabezpieczeń zidentyfikowany w skoid polu musi mieć przypisaną rolę RBAC obejmującą rolę Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action lub Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action. Aby uzyskać więcej informacji na temat tych akcji, zobacz Operacje dostawcy zasobów platformy Azure.

Określając identyfikator obiektu w saoid polu lub suoid , można również ograniczyć operacje związane z własnością katalogu lub obiektu blob w następujący sposób:

  • Jeśli operacja tworzy katalog lub obiekt blob, usługa Azure Storage ustawia właściciela katalogu lub obiektu blob na wartość określoną przez identyfikator obiektu. Jeśli identyfikator obiektu nie jest określony, usługa Azure Storage ustawia właściciela katalogu lub obiektu blob na wartość określoną przez skoid parametr .
  • Jeśli bit sticky jest ustawiony w katalogu nadrzędnym, a operacja usuwa lub zmienia nazwę katalogu lub obiektu blob, identyfikator obiektu właściciela katalogu nadrzędnego lub właściciela zasobu musi być zgodny z wartością określoną przez identyfikator obiektu.
  • Jeśli operacja ustawia właściciela katalogu lub obiektu blob, a x-ms-owner nagłówek jest określony, wartość określona przez identyfikator obiektu musi być zgodna z wartością określoną przez x-ms-owner nagłówek.
  • Jeśli operacja ustawia grupę dla katalogu lub obiektu blob, a x-ms-group nagłówek jest określony, wartość określona przez identyfikator obiektu musi być członkiem grupy określonej przez x-ms-group nagłówek.
  • Jeśli operacja ustawia uprawnienia lub listę ACL dla katalogu lub obiektu blob, należy spełnić jeden z następujących dwóch warunków:
    • Wartość określona dla identyfikatora obiektu musi być właścicielem katalogu lub obiektu blob.
    • Wartość signedPermissions pola (sp) musi zawierać Ownership uprawnienie (o) oprócz Permissions uprawnień (p).

Identyfikator obiektu określony w polu lub suoid jest uwzględniany w saoid dziennikach diagnostycznych podczas wysyłania żądań przy użyciu tokenu SAS.

Pole saoid or suoid jest obsługiwane tylko wtedy, gdy signedVersion pole (sv) jest ustawione na wersję 2020-02-10 lub nowszą. Token SAS może zawierać tylko jedno z tych pól.

Określanie identyfikatora korelacji

Pole signedCorrelationId (scid) określa identyfikator korelacji, który może służyć do korelowania dzienników inspekcji magazynu z dziennikami inspekcji używanymi przez podmiot zabezpieczeń, który generuje i dystrybuuje sygnaturę dostępu współdzielonego. Na przykład zaufana usługa autoryzacji zwykle ma tożsamość zarządzaną, która uwierzytelnia i autoryzuje użytkowników, generuje sygnaturę dostępu współdzielonego, dodaje wpis do lokalnego dziennika inspekcji i zwraca sygnaturę dostępu współdzielonego do użytkownika, który może następnie użyć sygnatury dostępu współdzielonego w celu uzyskania dostępu do zasobów usługi Azure Storage. Dołączając identyfikator korelacji zarówno w lokalnym dzienniku inspekcji, jak i w dzienniku inspekcji magazynu, można zezwolić na późniejsze skorelowanie tych zdarzeń. Wartość jest identyfikatorem GUID bez nawiasów klamrowych i małymi literami.

To pole jest obsługiwane w wersji 2020-02-10 lub nowszej.

Określanie głębokości katalogu

signedResource Jeśli pole określa katalog (), należy również określić pole (sr=dsdd), aby wskazać signedDirectoryDepth liczbę podkatalogów w katalogu głównym. Wartość sdd pola musi być nie ujemną liczbą całkowitą.

Na przykład katalog https://{account}.blob.core.windows.net/{container}/ główny ma głębokość 0. Każdy podkatalog w katalogu głównym dodaje głębokość o 1. Katalog https://{account}.blob.core.windows.net/{container}/d1/d2 ma głębokość 2.

To pole jest obsługiwane w wersji 2020-02-10 lub nowszej.

Określanie parametrów zapytania w celu zastąpienia nagłówków odpowiedzi

Aby zdefiniować wartości niektórych nagłówków odpowiedzi, które mają być zwracane, gdy sygnatura dostępu współdzielonego jest używana w żądaniu, można określić nagłówki odpowiedzi w parametrach zapytania. Nagłówki odpowiedzi i odpowiednie parametry zapytania są następujące:

Nazwa nagłówka odpowiedzi Odpowiadający parametr zapytania sygnatury dostępu współdzielonego
Cache-Control rscc
Content-Disposition rscd
Content-Encoding rsce
Content-Language rscl
Content-Type rsct

Jeśli na przykład określisz rsct=binary parametr zapytania w tokenie SYGNATURY dostępu współdzielonego, Content-Type nagłówek odpowiedzi ma wartość binary. Ta wartość zastępuje wartość nagłówka Content-Type przechowywaną dla obiektu blob dla żądania tylko przy użyciu tego sygnatury dostępu współdzielonego.

Jeśli tworzysz sygnaturę dostępu współdzielonego, która określa nagłówki odpowiedzi jako parametry zapytania, musisz uwzględnić te nagłówki odpowiedzi w znaku ciąg-to-sign, który jest używany do konstruowania ciągu podpisu. Aby uzyskać więcej informacji, zobacz sekcję "Określanie podpisu".

Określanie zakresu szyfrowania

Pole signed encryption scope (ses) określa zakres szyfrowania używany przez aplikację kliencka podczas przekazywania obiektów blob przy użyciu tokenu SAS za pośrednictwem operacji Put Blob . Pole signed encryption scope jest obsługiwane, gdy pole podpisanej wersji (sv) w tokenie sygnatury dostępu współdzielonego jest w wersji 2020-12-06 lub nowszej. Jeśli pole podpisanej wersji określa wersję starszą niż obsługiwana wersja, usługa zwraca kod odpowiedzi błędu 403 (Zabronione).

Jeśli domyślny zakres szyfrowania jest ustawiony dla kontenera lub systemu plików, ses pole uwzględnia zasady szyfrowania kontenerów. Jeśli istnieje niezgodność między ses parametrem zapytania a x-ms-default-encryption-scope nagłówkiem, a x-ms-deny-encryption-scope-override nagłówek ma wartość true, usługa zwraca kod odpowiedzi błędu 403 (Zabronione).

x-ms-encryption-scope Jeśli nagłówek i ses parametr zapytania są podane w żądaniu PUT i występuje niezgodność, usługa zwraca kod odpowiedzi błędu 400 (Nieprawidłowe żądanie).

Określanie podpisu

Pole signature (sig) służy do autoryzowania żądania złożonego przez klienta z sygnaturą dostępu współdzielonego. Znak-ciąg jest unikatowym ciągiem skonstruowanym z pól, które muszą zostać zweryfikowane, aby autoryzować żądanie. Podpis jest algorytmem HMAC obliczanym za pomocą ciągu do podpisania i klucza przy użyciu algorytmu SHA256, a następnie zakodowanego przy użyciu kodowania Base64.

Aby skonstruować ciąg podpisu sygnatury sygnatury dostępu współdzielonego delegowania użytkownika, utwórz ciąg do podpisania z pól tworzących żądanie, zakoduj ciąg jako UTF-8, a następnie oblicz podpis przy użyciu algorytmu HMAC-SHA256. Pola zawarte w znaku ciągu muszą być zdekodowane pod adresem URL.

Pola wymagane w ciągu do podpisania zależą od wersji usługi używanej do autoryzacji (sv pole). W poniższych sekcjach opisano konfigurację podpisywania ciągu dla wersji, które obsługują sygnaturę dostępu współdzielonego delegowania użytkownika.

Wersja 2020-12-06 lub nowsza

Znak ciągu do autoryzacji w wersji 2020-12-06 i nowszej ma następujący format:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                signedEncryptionScope + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Wersja 2020-02-10

Znak ciągu do autoryzacji w wersji 2020-02-10 ma następujący format:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Wersje starsze niż 2020-02-10

Znak do ciągu dla wersji autoryzacji starszych niż 2020-02-10 ma następujący format:

StringToSign =  signedPermissions + "\n" +  
                signedStart + "\n" +  
                signedExpiry + "\n" +  
                canonicalizedResource + "\n" +  
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +  
                signedProtocol + "\n" +  
                signedVersion + "\n" +  
                signedResource + "\n" +
                rscc + "\n" +
                rscd + "\n" +  
                rsce + "\n" +  
                rscl + "\n" +  
                rsct

Zasób kanoniczny

Część canonicalizedResource ciągu jest ścieżką kanoniczną do podpisanego zasobu. Musi zawierać punkt końcowy usługi Blob Storage i nazwę zasobu, a jego nazwa musi być zdekodowana pod adresem URL. Ścieżka obiektu blob musi zawierać jego kontener. Ścieżka katalogu musi zawierać liczbę podkatalogów odpowiadających parametrowi sdd .

Kanoniczny ciąg zasobu dla kontenera musi pominąć końcowy ukośnik (/) dla sygnatury dostępu współdzielonego, która zapewnia dostęp do tego kontenera.

W poniższych przykładach pokazano, jak utworzyć canonicalizedResource część ciągu w zależności od typu zasobu.

Przykład kontenera (Azure Blob Storage)
URL = https://myaccount.blob.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Przykład obiektu blob (Azure Blob Storage)
URL = https://myaccount.blob.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"
Przykład kontenera (Azure Data Lake Storage Gen2)
URL = https://myaccount.dfs.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Przykład katalogu (Azure Data Lake Storage Gen2)
URL = https://myaccount.dfs.core.windows.net/music/instruments/guitar/  
canonicalizedResource = "/blob/myaccount/music/instruments/guitar/"
Przykład obiektu blob (Azure Data Lake Storage Gen2)
URL = https://myaccount.dfs.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"

Pola opcjonalne

Jeśli pole jest opcjonalne i nie jest podane jako część tokenu SYGNATURY dostępu współdzielonego, określ pusty ciąg dla pola. Pamiętaj, aby po pustym ciągu uwzględnić znak nowego wiersza (\n).

Przykład sygnatury dostępu współdzielonego delegowania użytkowników

W poniższym przykładzie przedstawiono identyfikator URI obiektu blob z dołączonym do niego tokenem SAS delegowania użytkownika. Token sygnatury dostępu współdzielonego delegowania użytkownika zapewnia uprawnienia odczytu i zapisu do obiektu blob.

https://myaccount.blob.core.windows.net/sascontainer/blob1.txt?sp=rw&st=2023-05-24T01:13:55Z&se=2023-05-24T09:13:55Z&skoid=<object-id>&sktid=<tenant-id>&skt=2023-05-24T01:13:55Z&ske=2023-05-24T09:13:55Z&sks=b&skv=2022-11-02&sip=168.1.5.60-168.1.5.70&spr=https&sv=2022-11-02&sr=b&sig=<signature>

Każda część identyfikatora URI jest opisana w poniższej tabeli:

Nazwa Część sygnatury dostępu współdzielonego Opis
Identyfikator URI zasobu https://myaccount.blob.core.windows.net/sascontainer/blob1.txt Adres obiektu blob. Zdecydowanie zalecamy korzystanie z protokołu HTTPS.
Ogranicznik ? Ogranicznik poprzedzający ciąg zapytania. Ogranicznik nie jest częścią tokenu SAS.
Uprawnienia sp=rw Uprawnienia przyznane przez sygnaturę dostępu współdzielonego obejmują odczyt (r) i zapis (w).
Godzina rozpoczęcia st=2023-05-24T01:13:55Z Określony w czasie UTC. Jeśli chcesz, aby sygnatura dostępu współdzielonego jest prawidłowa natychmiast, pomiń godzinę rozpoczęcia.
Czas wygaśnięcia se=2023-05-24T09:13:55Z Określony w czasie UTC.
Identyfikator obiektu skoid=<object-id> Podmiot zabezpieczeń Microsoft Entra.
Identyfikator dzierżawy sktid=<tenant-id> Dzierżawa Microsoft Entra, w której zarejestrowano podmiot zabezpieczeń.
Czas rozpoczęcia klucza skt=2023-05-24T01:13:55Z Początek okresu istnienia klucza delegowania użytkownika.
Czas wygaśnięcia klucza ske=2023-05-24T09:13:55Z Koniec okresu istnienia klucza delegowania użytkownika.
Usługa kluczy sks=b Dla wartości usługi jest obsługiwana tylko usługa blob.
Wersja klucza skv=2022-11-02 Wersja usługi magazynu, która została użyta do pobrania klucza delegowania użytkownika.
Zakres adresów IP sip=168.1.5.60-168.1.5.70 Zakres adresów IP, z których zostanie zaakceptowane żądanie.
Protokół spr=https Dozwolone są tylko żądania używające protokołu HTTPS.
Wersja usługi Blob Service sv=2022-11-02 W przypadku usługi Azure Storage w wersji 2012-02-12 lub nowszej ten parametr wskazuje wersję do użycia.
Zasób sr=b Zasób jest obiektem blob.
Podpis sig=<signature> Służy do autoryzowania dostępu do obiektu blob. Podpis jest algorytmem HMAC obliczanym za pomocą ciągu do podpisania i klucza przy użyciu algorytmu SHA256, a następnie zakodowanego przy użyciu kodowania Base64.

Odwoływanie sygnatury dostępu współdzielonego delegowania użytkownika

Jeśli uważasz, że bezpieczeństwo sygnatury dostępu współdzielonego zostało naruszone, należy je odwołać. Sygnaturę dostępu współdzielonego delegowania użytkownika można odwołać, cofając klucz delegowania użytkownika lub zmieniając lub usuwając przypisania ról RBAC dla podmiotu zabezpieczeń używanego do tworzenia sygnatury dostępu współdzielonego.

Ważne

Zarówno klucz delegowania użytkownika, jak i przypisania ról RBAC są buforowane przez usługę Azure Storage, więc może wystąpić opóźnienie między zainicjowaniem procesu odwoływania, a gdy istniejąca sygnatura dostępu współdzielonego delegowania użytkownika stanie się nieprawidłowa.

Odwoływanie klucza delegowania użytkownika

Klucz delegowania użytkownika można odwołać, wywołując operację Odwoływanie kluczy delegowania użytkownika . Po odwołaniu klucza delegowania użytkownika wszelkie sygnatury dostępu współdzielonego, które opierają się na tym kluczu, stają się nieprawidłowe. Następnie możesz ponownie wywołać operację Pobierz klucz delegowania użytkownika i użyć klucza, aby utworzyć nowe sygnatury dostępu współdzielonego. Jest to najszybszy sposób odwoływanie sygnatury dostępu współdzielonego delegowania użytkownika.

Zmienianie lub usuwanie przypisań ról

Możesz zmienić lub usunąć przypisanie roli RBAC dla podmiotu zabezpieczeń używanego do utworzenia sygnatury dostępu współdzielonego. Gdy klient używa sygnatury dostępu współdzielonego do uzyskiwania dostępu do zasobu, usługa Azure Storage sprawdza, czy podmiot zabezpieczeń, którego poświadczenia były używane do zabezpieczenia sygnatury dostępu współdzielonego, ma wymagane uprawnienia do zasobu.

Zobacz też