Udostępnij za pośrednictwem

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

  • Artykuł

Ważne

Aby uzyskać optymalne zabezpieczenia, firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z tożsamościami zarządzanymi w celu autoryzowania żądań względem danych obiektów blob, kolejek i tabel, jeśli to możliwe. Autoryzacja przy użyciu identyfikatora Entra firmy Microsoft i tożsamości zarządzanych zapewnia doskonałe zabezpieczenia i łatwość użycia w przypadku autoryzacji klucza współdzielonego. Aby dowiedzieć się więcej, zobacz Authorize with Microsoft Entra ID (Autoryzowanie za pomocą identyfikatora Entra ID firmy Microsoft). Aby dowiedzieć się więcej o tożsamościach zarządzanych, zobacz Co to są tożsamości zarządzane dla zasobów platformy Azure.

W przypadku zasobów hostowanych poza platformą Azure, takich jak aplikacje lokalne, można używać tożsamości zarządzanych za pośrednictwem usługi Azure Arc. Na przykład aplikacje uruchomione na serwerach z obsługą usługi Azure Arc mogą używać tożsamości zarządzanych do łączenia się z usługami platformy Azure. Aby dowiedzieć się więcej, zobacz Uwierzytelnianie w odniesieniu do zasobów platformy Azure przy użyciu serwerów z obsługą usługi Azure Arc.

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ń usługi Microsoft Entra lub klucza konta. Sygnatura dostępu współdzielonego zabezpieczona przy użyciu poświadczeń usługi Microsoft Entra jest nazywana delegowaniem użytkownika SAS. Najlepszym rozwiązaniem w zakresie zabezpieczeń jest użycie poświadczeń firmy Microsoft Entra, jeśli jest to możliwe, a nie klucza konta, co może być łatwiejsze w przypadku naruszenia zabezpieczeń. Gdy projekt aplikacji wymaga sygnatur dostępu współdzielonego, użyj poświadczeń firmy 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żywasz do podpisywania 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 firmy 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, aby utworzyć sygnaturę dostępu współdzielonego.

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

Przestroga

Sygnatury dostępu współdzielonego to klucze, które udzielają uprawnień do zasobów magazynu, i należy je chronić tak samo, jak w przypadku ochrony klucza 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 sygnatury dostępu współdzielonego powinny być dystrybuowane tylko w 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 Tworzeniesygnatury dostępu współdzielonego konta.

Obsługa sygnatury dostępu współdzielonego delegowania użytkowników na potrzeby dostępu w zakresie katalogu

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

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. Parametry saoid i suoid odpowiadają jednostce zabezpieczeń dla użytkownika końcowego korzystającego z sygnatury dostępu współdzielonego i zapewniają rozszerzony model autoryzacji dla obciążeń klastra wieloużywcowego, takich jak Hadoop i Spark.

Tokeny SYGNATURy dostępu współdzielonego mogą być ograniczone do określonej operacji systemu plików i użytkownika, która zapewnia mniej narażony token dostępu, który jest bezpieczniejszy do dystrybucji w klastrze z wieloma użytkownikami. Jednym z przypadków użycia tych funkcji jest integracja sterownika Hadoop ABFS z platformą Apache Ranger.

Aby dowiedzieć się więcej na temat opcjonalnych parametrów saoid i suoid, zobacz Określanie podpisanego identyfikatora obiektu użytkownika.

Autoryzowanie 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ń usługi Microsoft Entra, które zostały użyte do utworzenia sygnatury dostępu współdzielonego. Dostęp klienta do zasobu jest określany przez następujące uprawnienia:

  • Uprawnienia kontroli dostępu opartej na rolach (RBAC) przyznane podmiotowi zabezpieczeń firmy Microsoft, który zażądał klucza delegowania użytkownika.
  • Uprawnienia listy kontroli dostępu (ACL) POSIX, które są przyznawane podmiotowi zabezpieczeń, który zażądał klucza delegowania użytkownika. Ta dodatkowa kontrola odbywa się tylko wtedy, gdy uprawnienia RBAC nie mogą udzielić dostępu i tylko wtedy, gdy hierarchiczna przestrzeń nazw jest włączona na koncie magazynu.
  • Uprawnienia, które są jawnie przyznawane na tokenie SYGNATURY dostępu współdzielonego.

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 utworzenie sygnatury dostępu współdzielonego przy użyciu poświadczeń firmy Microsoft Entra jest najlepszym rozwiązaniem w zakresie zabezpieczeń.

Uprawnienia przyznane klientowi, który posiada sygnaturę dostępu współdzielonego, są skrzyżowaniem uprawnień, które zostały przyznane podmiotowi zabezpieczeń, który zażądał klucza delegowania użytkownika i uprawnieniami przyznanymi zasobowi w tokenie SAS przy użyciu pola signedPermissions (sp). Jeśli uprawnienie udzielone podmiotowi zabezpieczeń za pośrednictwem kontroli dostępu opartej na rolach lub list ACL POSIX nie zostanie również przyznane na token SAS, 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 list ACL RBAC i POSIX oraz uprawnienia przyznane za pośrednictwem tokenu SAS są zgodne z poziomem dostępu wymaganym przez klienta.

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

  1. Użyj list ACL RBAC lub POSIX, aby udzielić żądanych uprawnień podmiotowi zabezpieczeń, który zażąda klucza delegowania użytkownika.
  2. Uzyskaj token OAuth 2.0 z identyfikatora Entra firmy Microsoft.
  3. Użyj tokenu, aby zażądać klucza delegowania użytkownika, wywołując operację uzyskiwania klucza 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. Podmiot zabezpieczeń Microsoft Entra ID może być użytkownikiem, grupą, jednostką usługi lub tożsamością zarządzaną.

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

Ponieważ operacja pobierania klucza delegowania użytkownika działa na poziomie konta magazynu, Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey akcja 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 Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey akcji, na poziomie konta magazynu, grupy zasobów lub subskrypcji, podmiot zabezpieczeń może następnie 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ę Storage Blob Delegator do podmiotu zabezpieczeń na poziomie konta magazynu, grupy zasobów lub subskrypcji. Rola delegowania obiektów blob usługi Storage przyznaje uprawnienia podmiotu zabezpieczeń do żądania klucza delegowania użytkownika.

Aby uzyskać więcej informacji na temat ról RBAC dla usługi Azure Storage, zobacz Authorize with Microsoft Entra(Autoryzowanie za pomocą usługi Microsoft Entra).

Uzyskiwanie tokenu OAuth 2.0

Aby uzyskać klucz delegowania użytkownika, najpierw zażądaj tokenu OAuth 2.0 z identyfikatora Entra firmy Microsoft. 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 identyfikatora Entra firmy Microsoft, 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 tokenu SAS delegowania użytkownika. Te parametry opisano w Uzyskiwanie klucza delegowania użytkownika odwołania 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żna określić, że klucz jest ważny przez okres do siedmiu 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 wysyłane za pomocą tej sygnatury dostępu współdzielonego.
signedResource sr Wymagane wszystkie Określa, które zasoby obiektów blob są dostępne za pośrednictwem sygnatury dostępu współdzielonego.
signedStart st Opcjonalnie wszystkie 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 Format DateTime values.
signedExpiry se Wymagane wszystkie 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 Format DateTime values.
signedPermissions sp Wymagane wszystkie Wskazuje operacje wykonywane przez klienta, który posiada sygnaturę dostępu współdzielonego na zasobie. Uprawnienia mogą być łączone.
signedIp sip Opcjonalnie 2015-04-05 i nowsze Określa adres IP lub inkluzywny zakres adresów IP, z którego 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=198.51.100.0 lub sip=198.51.100.10-198.51.100.20.
signedProtocol spr Opcjonalnie 2015-04-05 i nowsze Określa protokół dozwolony dla żądania złożonego 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 Określa identyfikator obiektu podmiotu zabezpieczeń firmy Microsoft Entra. Ten identyfikator obiektu odpowiada jednostce zabezpieczeń, która zażądała klucza delegowania użytkownika.

Przed autoryzowaniem operacji usługa Azure Storage sprawdza uprawnienia RBAC względem identyfikatora obiektu. Jeśli uprawnienia RBAC nie mogą udzielić dostępu, usługa Azure Storage sprawdza uprawnienia listy ACL poSIX względem identyfikatora obiektu.
signedTenantId sktid Wymagane 2018-11-09 i nowsze Określa dzierżawę firmy Microsoft Entra, w której zdefiniowano podmiot zabezpieczeń.
signedKeyStartTime skt Wymagane. 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. Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Format DateTime values.
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 Format DateTime values.
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 Opcjonalnie 2020-02-10 i nowsze Określa identyfikator obiektu podmiotu zabezpieczeń firmy Microsoft entra autoryzowanego przez właściciela klucza delegowania użytkownika w celu wykonania akcji przyznanej przez token SAS. Ten identyfikator obiektu odpowiada podmiotowi zabezpieczeń użytkownikowi końcowemu sygnatury dostępu współdzielonego. Nie jest przeprowadzane żadne dodatkowe sprawdzanie uprawnień na listach kontroli dostępu (ACL) POSIX.
signedUnauthorizedObjectId suoid Opcjonalnie 2020-02-10 i nowsze Określa identyfikator obiektu dla podmiotu zabezpieczeń firmy Microsoft Entra, gdy włączono hierarchiczną przestrzeń nazw. Ten identyfikator obiektu odpowiada podmiotowi zabezpieczeń użytkownikowi końcowemu sygnatury dostępu współdzielonego. Usługa Azure Storage wykonuje sprawdzanie listy ACL POSIX względem identyfikatora obiektu, zanim autoryzuje operację.
signedCorrelationId scid Opcjonalnie 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 w przypadku sr=d 2020-02-10 i nowsze Wskazuje liczbę katalogów w folderze głównym katalogu określonym w polu canonicalizedResource ciągu do znaku.
signedEncryptionScope ses Opcjonalnie 2020-12-06 i nowsze Wskazuje zakres szyfrowania używany do szyfrowania zawartości żądania.
signature sig Wymagane wszystkie 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.
nagłówek odpowiedzi Cache-Control rscc Opcjonalnie 2013-08-15 i nowsze Usługa Azure Storage ustawia nagłówek odpowiedzi Cache-Control na wartość określoną w tokenie SAS.
nagłówek odpowiedzi Content-Disposition rscd Opcjonalnie 2013-08-15 i nowsze Usługa Azure Storage ustawia nagłówek odpowiedzi Content-Disposition na wartość określoną w tokenie SAS.
nagłówek odpowiedzi Content-Encoding rsce Opcjonalnie 2013-08-15 i nowsze Usługa Azure Storage ustawia nagłówek odpowiedzi Content-Encoding na wartość określoną w tokenie SAS.
nagłówek odpowiedzi Content-Language rscl Opcjonalnie 2013-08-15 i nowsze Usługa Azure Storage ustawia nagłówek odpowiedzi Content-Language na wartość określoną w tokenie SAS.
nagłówek odpowiedzi Content-Type rsct Opcjonalnie 2013-08-15 i nowsze Usługa Azure Storage ustawia nagłówek odpowiedzi Content-Type na wartość określoną w tokenie SAS.

Określanie pola podpisanej wersji

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

Określanie pola podpisanego zasobu

Wymagane pole signedResource (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 zasobu obiektu blob, kontenera lub katalogu w tokenie SAS:

Zasób Wartość parametru Obsługiwane wersje Opis
Obiekt blob b wszystkie Przyznaje dostęp do zawartości i metadanych obiektu blob.
Wersja obiektu blob Bv 2018-11-09 i nowsze Przyznaje dostęp 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 wszystkie Przyznaje dostęp do zawartości i metadanych dowolnego obiektu blob w kontenerze oraz do listy obiektów blob w kontenerze.
Katalog 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 signedResource określono katalog, wymagany jest również parametr signedDirectoryDepth (sdd). 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 sam sygnatura dostępu współdzielonego jest nadal prawidłowa.

Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Format DateTime values.

Określanie uprawnień

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

Uprawnienia można połączyć, aby umożliwić klientowi wykonywanie wielu operacji przy użyciu tej samej sygnatury 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 obejmują rw, rd, rl, wd, wli rl. Przykłady nieprawidłowych ustawień obejmują wr, dr, lri dw. Określanie oznaczenia uprawnień więcej niż raz nie jest dozwolone.

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

  • Nie można tworzyć, usuwać ani wyświetlać kontenerów.
  • Nie można odczytać ani zapisać 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 konta sygnatury dostępu współdzielonego.

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
Katalog
Obiekt blob		 wszystkie Odczytaj zawartość, listę bloków, właściwości i metadane dowolnego obiektu blob w kontenerze lub katalogu. Użyj obiektu blob jako źródła operacji kopiowania.
Dodaj a Kontener
Katalog
Obiekt blob		 wszystkie Dodaj blok do uzupełnialnych obiektów blob.
Utwórz c Kontener
Katalog
Obiekt blob		 wszystkie Napisz nowy obiekt blob, utwórz migawkę obiektu blob lub skopiuj obiekt blob do nowego obiektu blob.
Write w Kontener
Katalog
Obiekt blob		 wszystkie 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
Katalog
Obiekt blob		 wszystkie Usuwanie obiektu blob. W przypadku wersji 2017-07-29 lub nowszej uprawnienie Usuwanie umożliwia również przerwanie 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 t Obiekt blob 2020-02-10 i nowsze Trwałe usuwanie migawki lub wersji obiektu blob.
List l Kontener
Katalog		 wszystkie Wyświetlanie listy obiektów blob niecyklicznie.
Tagi t Obiekt blob 2019-12-12 i nowsze Odczytywanie lub zapisywanie tagów w obiekcie blob.
Przesuń m Kontener
Katalog
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 parametr saoid jest dołączony do tokenu SYGNATURy dostępu współdzielonego, a bit sticky jest ustawiony w katalogu nadrzędnym.
Wykonywanie e Kontener
Katalog
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ściciela, uprawnień POSIX i listy ACL POSIX obiektu blob. Obiekt wywołujący nie zezwala na odczytywanie metadanych zdefiniowanych przez użytkownika.
Własność o Kontener
Katalog
Obiekt blob		 2020-02-10 i nowsze Gdy hierarchiczna przestrzeń nazw jest włączona, to uprawnienie umożliwia obiektowi wywołującym 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
Katalog
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 i Kontener
Obiekt blob		 2020-06-12 i nowsze Ustaw lub usuń zasady niezmienności lub archiwizację ze względów prawnych dla obiektu blob.

Określanie adresu IP lub zakresu adresów IP

Opcjonalne pole signedIp (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 sip=198.51.100.0 lub sip=198.51.100.10-198.51.100.20 sygnatury dostępu współdzielonego ogranicza żądanie do tych adresów IP.

W poniższej tabeli opisano, czy należy uwzględnić pole signedIp 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 pola signedIp. Żądania wysyłane z tego samego regionu przy użyciu sygnatury dostępu współdzielonego z określonym wychodzącym adresem IP kończą 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 pola signedIp. Żą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 pola signedIp. Żą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 pola signedIp.

Określanie protokołu HTTP

Opcjonalne pole signedProtocol (spr) określa protokół dozwolony dla żądań wysyłanych za pomocą sygnatury dostępu współdzielonego. Możliwe wartości to zarówno HTTPS, jak i HTTP (https,http) lub TYLKO HTTPS (https). Domyślna wartość to https,http.

Uwaga

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

Określanie identyfikatora podpisanego 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ń na platformie tożsamości firmy 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ę firmy Microsoft Entra, w której zdefiniowano podmiot zabezpieczeń.

Określanie czasu rozpoczęcia klucza podpisanego

Wymagane pole signedKeyStartTime (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.

Określ czas 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 klucza podpisanego 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 użytkownika dla podmiotu zabezpieczeń

Opcjonalne pola signedAuthorizedObjectId (saoid) i signedUnauthorizedObjectId (suoid) umożliwiają integrację z obciążeniami usług Apache Hadoop i Apache Ranger dla usługi Azure Data Lake Storage. Użyj jednego z tych pól w tokenie SAS, aby określić identyfikator obiektu dla podmiotu zabezpieczeń:

  • Pole saoid określa identyfikator obiektu podmiotu zabezpieczeń firmy Microsoft Entra, który jest autoryzowany przez właściciela klucza delegowania użytkownika w celu wykonania akcji przyznanej przez token SAS. Usługa Azure Storage weryfikuje token SAS 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ń dla list ACL POSIX.
  • Pole suoid określa identyfikator obiektu podmiotu zabezpieczeń firmy 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. Gdy pole suoid jest uwzględnione w tokenie SAS, usługa Azure Storage wykonuje sprawdzanie listy ACL POSIX względem identyfikatora obiektu, zanim autoryzuje operację. Jeśli sprawdzanie listy ACL nie powiedzie się, operacja zakończy się niepowodzeniem. Hierarchiczna przestrzeń nazw musi być włączona dla konta magazynu, jeśli pole suoid jest uwzględnione w tokenie SAS. 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 polu skoid. Aby określić identyfikator obiektu w tokenie SAS z polem saoid lub suoid, podmiot zabezpieczeń zidentyfikowany w polu skoid musi mieć przypisaną rolę RBAC obejmującą 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 polu saoid lub suoid, można również ograniczyć operacje powią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 parametr skoid.
  • Jeśli bit sticky jest ustawiony w katalogu nadrzędnym i operacja usuwa lub zmienia nazwę katalogu lub obiektu blob, identyfikator obiektu właściciela katalogu nadrzędnego lub właściciel zasobu musi być zgodny z wartością określoną przez identyfikator obiektu.
  • Jeśli operacja ustawia właściciela katalogu lub obiektu blob, a nagłówek x-ms-owner jest określony, wartość określona przez identyfikator obiektu musi być zgodna z wartością określoną przez nagłówek x-ms-owner.
  • Jeśli operacja ustawia grupę dla katalogu lub obiektu blob, a nagłówek x-ms-group jest określony, wartość określona przez identyfikator obiektu musi być członkiem grupy określonej przez nagłówek x-ms-group.
  • Jeśli operacja ustawia uprawnienia lub listę ACL dla katalogu lub obiektu blob, należy również 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ść pola signedPermissions (sp) musi zawierać uprawnienie Ownership (o) oprócz uprawnienia Permissions (p).

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

Pole saoid lub suoid jest obsługiwane tylko wtedy, gdy pole signedVersion (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żywać sygnatury dostępu współdzielonego do uzyskiwania dostępu do zasobów usługi Azure Storage. Po uwzględnieniu identyfikatora korelacji w lokalnym dzienniku inspekcji i dzienniku inspekcji magazynu można je skorelować później. 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

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

Na przykład katalog główny https://{account}.blob.core.windows.net/{container}/ ma głębokość 0. Każdy podkatalog w katalogu głównym dodaje do głębokości o 1. https://{account}.blob.core.windows.net/{container}/d1/d2 katalogu 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 dla 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 parametr zapytania rsct=binary w tokenie SAS, nagłówek odpowiedzi Content-Type zostanie ustawiony na 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 dołączyć te nagłówki odpowiedzi do znaku ciągu używanego do konstruowania ciągu podpisu. Aby uzyskać więcej informacji, zobacz sekcję "Określaniepodpisu".

Określanie zakresu szyfrowania

Pole signed encryption scope (ses) określa zakres szyfrowania używany przez aplikację kliencą 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) na tokenie SAS 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, pole ses uwzględnia zasady szyfrowania kontenera. Jeśli między parametrem zapytania ses a nagłówkiem x-ms-default-encryption-scope występuje niezgodność, a nagłówek x-ms-deny-encryption-scope-override ma wartość true, usługa zwraca kod odpowiedzi błędu 403 (Zabronione).

Jeśli nagłówek x-ms-encryption-scope i parametr zapytania ses 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. Ciąg-znak to unikatowy ciąg skonstruowany z pól, które należy zweryfikować, aby autoryzować żądanie. Podpis jest algorytmem 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.

Aby utworzyć ciąg podpisu 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 (polesv). W poniższych sekcjach opisano konfigurację typu ciąg-znak dla wersji, które obsługują sygnaturę dostępu współdzielonego delegowania użytkownika.

Wersja 2020-12-06 lub nowsza

Ciąg do podpisania dla 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

Ciąg do podpisania dla wersji autoryzacji, które są starsze 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 i musi być zdekodowany pod adresem URL. Ścieżka obiektu blob musi zawierać 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 skonstruować część canonicalizedResource 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)
URL = https://myaccount.dfs.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Przykład katalogu (Azure Data Lake Storage)
URL = https://myaccount.dfs.core.windows.net/music/instruments/guitar/  
canonicalizedResource = "/blob/myaccount/music/instruments/guitar/"
Przykład obiektu blob (Azure Data Lake Storage)
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 podano go jako części tokenu SAS, 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żytkownika

W poniższym przykładzie pokazano identyfikator URI obiektu blob z dołączonym tokenem SAS delegowania użytkownika. Token SAS 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=198.51.100.10-198.51.100.20&spr=https&sv=2022-11-02&sr=b&sig=<signature>

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

Nazwisko Część sygnatury dostępu współdzielonego Opis
Adres 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 sygnatura dostępu współdzielonego ma być 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ń firmy Microsoft Entra.
Identyfikator dzierżawy sktid=<tenant-id> Dzierżawa firmy 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 Wartość usługi jest obsługiwana tylko przez usługę Blob Service.
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=198.51.100.10-198.51.100.20 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 naruszenie zabezpieczeń 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ć, odwołując klucz delegowania użytkownika lub zmieniając lub usuwając przypisania ról RBAC i listy ACL POSIX 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, dlatego może wystąpić opóźnienie między zainicjowaniem procesu odwołania i nieprawidłową sygnaturą dostępu współdzielonego delegowania użytkownika.

Odwoływanie klucza delegowania użytkownika

Klucz delegowania użytkownika można odwołać, wywołując operację Odwołaj klucze delegowania użytkownika. Po odwołaniu klucza delegowania użytkownika wszelkie sygnatury dostępu współdzielonego korzystające z tego klucza stają się nieprawidłowe. Następnie możesz ponownie wywołać operację Pobierz klucz delegowania użytkownika i użyć klucza do utworzenia nowych sygnatur dostępu współdzielonego. Jest to najszybszy sposób odwołania sygnatury dostępu współdzielonego delegowania użytkownika.

Zmienianie lub usuwanie przypisań ról lub list ACL

Możesz zmienić lub usunąć przypisanie roli RBAC i listy ACL POSIX dla podmiotu zabezpieczeń używanego do tworzenia 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 zostały użyte do zabezpieczenia sygnatury dostępu współdzielonego, ma wymagane uprawnienia do zasobu.

Zobacz też