Tworzenie sygnatury dostępu współdzielonego usługi
Ważne
W celu zapewnienia optymalnego bezpieczeństwa firma Microsoft zaleca używanie Tożsamość Microsoft Entra z tożsamościami zarządzanymi w celu autoryzowania żądań względem danych obiektów blob, kolejek i tabel, jeśli jest to możliwe. Autoryzacja przy użyciu Tożsamość Microsoft Entra 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 Autoryzowanie za pomocą Tożsamość Microsoft Entra. Aby dowiedzieć się więcej na temat tożsamości 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 działające 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 względem zasobów platformy Azure za pomocą serwerów z obsługą usługi Azure Arc.
W przypadku scenariuszy, w których są używane sygnatury dostępu współdzielonego (SAS), firma Microsoft zaleca używanie sygnatury dostępu współdzielonego delegowania użytkownika. Sygnatura dostępu współdzielonego delegowania użytkownika jest zabezpieczona przy użyciu poświadczeń Microsoft Entra zamiast klucza konta. Aby dowiedzieć się więcej o sygnaturach dostępu współdzielonego, zobacz Twórca sygnatury dostępu współdzielonego delegowania użytkownika.
Sygnatura dostępu współdzielonego (SAS) usługi deleguje dostęp do zasobu tylko w jednej z usług magazynu: Azure Blob Storage, Azure Queue Storage, Azure Table Storage lub Azure Files. Identyfikator URI sygnatury dostępu współdzielonego na poziomie usługi składa się z identyfikatora URI zasobu, dla którego sygnatura dostępu współdzielonego deleguje dostęp, a następnie token sygnatury dostępu współdzielonego.
Token sygnatury dostępu współdzielonego to ciąg zapytania zawierający wszystkie informacje wymagane do autoryzowania żądania. Token określa zasób, do którego klient może uzyskać dostęp, uprawnienia przyznane i okres, w którym podpis jest prawidłowy.
Sygnatura dostępu współdzielonego może również określać obsługiwany adres IP lub zakres adresów, z którego mogą pochodzić żądania, obsługiwany protokół, za pomocą którego można wysłać żądanie, lub opcjonalny identyfikator zasad dostępu skojarzony z żądaniem.
Na koniec każdy token SAS zawiera podpis.
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.
Autoryzowanie sygnatury dostępu współdzielonego usługi
Sygnatura dostępu współdzielonego konta jest zabezpieczana przy użyciu klucza konta magazynu. Podczas tworzenia sygnatury dostępu współdzielonego konta aplikacja kliencka musi mieć klucz konta.
Aby użyć Microsoft Entra poświadczeń w celu zabezpieczenia sygnatury dostępu współdzielonego dla kontenera lub obiektu blob, utwórz sygnaturę dostępu współdzielonego delegowania użytkownika.
Obsługa sygnatur dostępu współdzielonego w przypadku dostępu w zakresie katalogu
Sygnatura dostępu współdzielonego usługi obsługuje zakres katalogu (sr=d
), gdy wersja autoryzacji (sv
) to 2020-02-10 lub nowsza, a hierarchiczna przestrzeń nazw jest włączona. Semantyka zakresu katalogu (sr=d
) jest podobna do tych dla 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.
Konstruowanie sygnatury dostępu współdzielonego usługi
Na poniższej ilustracji przedstawiono części identyfikatora URI sygnatury dostępu współdzielonego. Wymagane części są wyświetlane w kolorze pomarańczowym. Pola tworzące token SAS są opisane w kolejnych sekcjach.
W poniższych sekcjach opisano sposób określania parametrów tworzących token SAS usługi.
signedVersion
Określanie pola
Pole signedVersion
(sv
) zawiera wersję usługi sygnatury dostępu współdzielonego. Ta wartość określa wersję autoryzacji klucza współdzielonego, która jest używana przez ten sygnatura dostępu współdzielonego signature
(w polu). Wartość określa również wersję usługi dla żądań wysyłanych za pomocą tego sygnatury dostępu współdzielonego.
Aby uzyskać informacje o wersji używanej podczas wykonywania żądań za pośrednictwem sygnatury dostępu współdzielonego, zobacz Przechowywanie wersji dla usług Azure Storage.
Aby uzyskać informacje na temat wpływu tego parametru na autoryzację żądań wysyłanych za pomocą sygnatury dostępu współdzielonego, zobacz Delegowanie dostępu za pomocą sygnatury dostępu współdzielonego.
Nazwa pola | Parametr zapytania | Opis |
---|---|---|
signedVersion |
sv |
Wymagane. Obsługiwane w wersji 2012-02-12 lub nowszej. Wersja usługi magazynu używana do autoryzacji i obsługi żądań wysyłanych za pomocą tego sygnatury dostępu współdzielonego. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji dla usług Azure Storage. |
Określanie wersji starszego żądania SYGNATURy dostępu współdzielonego
W starszych scenariuszach, w których signedVersion
nie jest używany, usługa Blob Storage stosuje reguły w celu określenia wersji. Aby uzyskać więcej informacji na temat tych reguł, zobacz Przechowywanie wersji dla usług Azure Storage.
Ważne
Oprogramowanie klienckie może wystąpić nieoczekiwane zachowanie protokołu w przypadku korzystania z identyfikatora URI sygnatury dostępu współdzielonego korzystającego z wersji usługi magazynu nowszej niż oprogramowanie klienckie. Kod tworzący identyfikatory URI sygnatury dostępu współdzielonego powinien polegać na wersjach zrozumiałych dla oprogramowania klienckiego wysyłającego żądania obsługi magazynu.
Określ podpisany zasób (tylko usługa Blob Storage)
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 zasobu obiektu blob lub kontenera w tokenie SAS.
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 zagnieżdżony w kontenerze. |
Określanie podpisanego zasobu (Azure Files)
Sygnatura dostępu współdzielonego jest obsługiwana w przypadku Azure Files w wersji 2015-02-21 lub nowszej.
Pole signedResource
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 pliku lub udziału w identyfikatorze URI.
Nazwa pola | Parametr zapytania | Opis |
---|---|---|
signedResource |
sr |
Wymagane. Określ f , czy zasób udostępniony jest plikiem. Daje to dostęp do zawartości i metadanych pliku.Określ s , czy zasób udostępniony jest udziałem. Daje to dostęp do zawartości i metadanych dowolnego pliku w udziale oraz do listy katalogów i plików w udziale. |
Określ parametry zapytania, aby zastąpić nagłówki odpowiedzi (tylko usługi Blob Storage i Azure Files)
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. Ta funkcja jest obsługiwana w wersji 2013-08-15 dla usługi Blob Storage i wersji 2015-02-21 dla Azure Files. Sygnatury dostępu współdzielonego korzystające z tej funkcji muszą zawierać parametr ustawiony na 2013-08-15
wartość lub nowszą sv
dla usługi Blob Storage albo do 2015-02-21
lub nowszego dla Azure Files.
Nagłówki odpowiedzi i odpowiednie parametry zapytania są wymienione w poniższej tabeli:
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 dla sygnatury dostępu współdzielonego utworzonej przy użyciu wersji 2013-08-15 lub nowszej, Content-Type
nagłówek odpowiedzi ma wartość binary
. Ta wartość zastępuje Content-Type
wartość nagłówka przechowywaną dla obiektu blob dla żądania, które używa tylko 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ć je do znaku ciąg-to-sign, który jest używany do konstruowania ciągu podpisu. Aby uzyskać więcej informacji, zobacz sekcję "Konstruowanie ciągu podpisu" w dalszej części tego artykułu. Aby uzyskać dodatkowe przykłady, zobacz Przykłady sygnatury dostępu współdzielonego usługi.
Określ nazwę tabeli (tylko usługa Table Storage)
Pole tableName
określa nazwę tabeli do udostępnienia.
Nazwa pola | Parametr zapytania | Opis |
---|---|---|
tableName |
tn |
Wymagane. Nazwa tabeli do udostępnienia. |
Określanie zasad dostępu
Część identyfikatora URI zasad dostępu wskazuje okres, w którym sygnatura dostępu współdzielonego jest prawidłowa, oraz uprawnienia, które mają zostać przyznane użytkownikowi. Części identyfikatora URI tworzące zasady dostępu zostały opisane w poniższej tabeli:
Nazwa pola | Parametr zapytania | Opis |
---|---|---|
signedStart |
st |
Opcjonalny. Czas, kiedy sygnatura dostępu współdzielonego stanie się prawidłowa, wyrażona w jednym z akceptowanych formatów ISO 8601 UTC. Jeśli ten parametr zostanie pominięty, bieżący czas UTC jest używany jako godzina rozpoczęcia. W wersjach starszych niż 2012-02-12 czas trwania między signedStart i signedExpiry nie może przekraczać jednej godziny, chyba że są używane zasady kontenera. Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Formatowanie wartości daty/godziny. |
signedExpiry |
se |
Wymagane. Czas, kiedy sygnatura dostępu współdzielonego staje się nieprawidłowa, wyrażona w jednym z akceptowanych formatów ISO 8601 UTC. Należy pominąć to pole, jeśli zostało określone w skojarzonych zasadach dostępu przechowywanych. Aby uzyskać więcej informacji na temat akceptowanych formatów UTC, zobacz Formatowanie wartości daty/godziny. |
signedPermissions
1 |
sp |
Wymagane. Uprawnienia skojarzone z sygnaturą dostępu współdzielonego. Użytkownik jest ograniczony do operacji, które są dozwolone przez uprawnienia. Należy pominąć to pole, jeśli zostało określone w skojarzonych zasadach dostępu przechowywanych. |
startPk
2startRk
2 |
spk srk |
Tylko usługa Table Storage. Opcjonalnie, ale startPk musi towarzyszyć .startRk Minimalna partycja i klucze wierszy, które są dostępne za pomocą tego sygnatury dostępu współdzielonego. Wartości klucza są inkluzywne. Jeśli zostaną pominięte, nie ma mniejszej granicy dla jednostek tabeli, do których można uzyskać dostęp. |
endPk
2endRk
2 |
epk erk |
Tylko usługa Table Storage. Opcjonalnie, ale endPk musi towarzyszyć .endRk Maksymalna liczba kluczy partycji i wierszy dostępnych za pomocą tego sygnatury dostępu współdzielonego. Wartości klucza są inkluzywne. Jeśli zostaną pominięte, nie ma górnej granicy dla jednostek tabeli, do których można uzyskać dostęp. |
1 Pole signedPermissions
jest wymagane w identyfikatorze URI, chyba że jest określone jako część przechowywanych zasad dostępu.
2 Pola startPk
, startRk
, endPk
i endRk
można określić tylko w zasobach usługi Table Storage.
Określanie uprawnień
Uprawnienia określone dla signedPermissions
pola (sp
) w tokenie sygnatury dostępu współdzielonego wskazują, które operacje może wykonywać klient w zasobie.
Możesz połączyć uprawnienia, 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 to rw
: , rd
, rl
, wd
, wl
i rl
. Przykłady nieprawidłowych ustawień to wr
: , dr
, lr
i dw
. Nie można określić oznaczenia uprawnień więcej niż raz.
Sygnatura dostępu współdzielonego usługi nie może udzielić dostępu do określonych operacji:
- Nie można tworzyć, usuwać ani wyświetlać kontenerów, kolejek i tabel.
- Nie można odczytać ani zapisać metadanych i właściwości kontenera.
- Nie można wyczyścić kolejek, a ich metadane nie mogą być zapisywane.
- 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 Twórca sygnaturę dostępu współdzielonego konta.
Ważne
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. Wykonaj operacje korzystające z sygnatur dostępu współdzielonego tylko za pośrednictwem połączenia HTTPS i rozpowszechniają identyfikatory URI sygnatury dostępu współdzielonego tylko w bezpiecznym połączeniu, takim jak HTTPS.
Uprawnienia obsługiwane dla każdego typu zasobu opisano w poniższych sekcjach.
Uprawnienia do katalogu, kontenera lub obiektu blob
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 | Przeczytaj 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 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 | Twórca lub napisz zawartość, właściwości, metadane lub listę 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. |
Usuwanie trwałe | 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. |
Znajdowanie | f | Kontener | 2019-12-12 i nowsze | Znajdź obiekty blob z tagami indeksu. |
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 daje możliwość ustawienia grupy, uprawnień POSIX i listy ACL poSIX obiektu blob. program nie zezwala obiektowi wywołującemu 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 wywołującym ustawienie właściciela lub grupy będącej właścicielem albo działanie jako właściciel podczas zmiany nazwy lub usunięcia katalogu lub obiektu 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 archiwizację ze względów prawnych dla obiektu blob. |
Uprawnienia do pliku
Uprawnienie | Symbol identyfikatora URI | Dozwolone operacje |
---|---|---|
Read | r | Odczytywanie zawartości, właściwości, metadanych. Użyj pliku jako źródła operacji kopiowania. |
Utwórz | c | Twórca nowy plik lub skopiuj plik do nowego pliku. |
Write | w | Twórca lub napisz zawartość, właściwości, metadane. Zmień rozmiar pliku. Użyj pliku jako miejsca docelowego operacji kopiowania. |
Usuń | d | Usuń plik. |
Uprawnienia do udziału
Uprawnienie | Symbol identyfikatora URI | Dozwolone operacje |
---|---|---|
Read | r | Odczytywanie zawartości, właściwości lub metadanych dowolnego pliku w udziale. Użyj dowolnego pliku w udziale jako źródła operacji kopiowania. |
Utwórz | c | Twórca nowy plik w udziale lub skopiuj plik do nowego pliku w udziale. |
Write | w | W przypadku dowolnego pliku w udziale utwórz lub napisz zawartość, właściwości lub metadane. Zmień rozmiar pliku. Użyj pliku jako miejsca docelowego operacji kopiowania. Uwaga: nie można udzielić uprawnień do odczytu lub zapisu właściwości udziału lub metadanych przy użyciu sygnatury dostępu współdzielonego usługi. Zamiast tego użyj sygnatury dostępu współdzielonego konta. |
Usuń | d | Usuń dowolny plik w udziale. Uwaga: nie można udzielić uprawnień do usuwania udziału przy użyciu sygnatury dostępu współdzielonego usługi. Zamiast tego użyj sygnatury dostępu współdzielonego konta. |
Lista | l | Wyświetlanie listy plików i katalogów w udziale. |
Uprawnienia do kolejki
Uprawnienie | Symbol identyfikatora URI | Dozwolone operacje |
---|---|---|
Read | r | Odczytywanie metadanych i właściwości, w tym liczby komunikatów. Podgląd w wiadomościach. |
Dodaj | a | Dodaj komunikaty do kolejki. |
Aktualizacja | u | Aktualizowanie komunikatów w kolejce. Uwaga: użyj uprawnienia Proces z aktualizacją, aby najpierw uzyskać komunikat, który chcesz zaktualizować. |
Proces | p | Pobieranie i usuwanie komunikatów z kolejki. |
Uprawnienia dla tabeli
Uprawnienie | Symbol identyfikatora URI | Dozwolone operacje |
---|---|---|
Zapytanie | r | Uzyskiwanie jednostek i wykonywanie zapytań o jednostki. |
Dodaj | a | Dodaj jednostki. Uwaga: w przypadku operacji upsert wymagane są uprawnienia dodawania i aktualizowania. |
Aktualizacja | u | Aktualizowanie jednostek. Uwaga: w przypadku operacji upsert wymagane są uprawnienia dodawania i aktualizowania. |
Usuń | d | Usuń jednostki. |
Określanie adresu IP lub zakresu adresów IP
Od wersji 2015-04-05 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.
Podczas określania zakresu adresów IP należy pamiętać, że zakres jest uwzględniany. Na przykład określenie sip=168.1.5.65
lub sip=168.1.5.60-168.1.5.70
na sygnaturze dostępu współdzielonego ogranicza żądanie do tych adresów IP.
W poniższej tabeli opisano, czy należy uwzględnić signedIp
pole w tokenie SAS dla określonego 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 dostarczana klientowi w tym scenariuszu signedIp nie powinna zawierać wychodzącego adresu IP dla pola. Żądania wysyłane z tego samego regionu, które używają sygnatury dostępu współdzielonego z określonym adresem IP ruchu wychodzącego, 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 niż klient | Sygnatura dostępu współdzielonego dostarczana klientowi w tym scenariuszu może zawierać publiczny adres IP lub zakres adresów dla signedIp pola. Żądanie z sygnaturą dostępu współdzielonego musi 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 dostarczana klientowi w tym scenariuszu może zawierać publiczny adres IP lub zakres adresów dla signedIp pola. Żądanie z sygnaturą dostępu współdzielonego musi 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
Począwszy od wersji 2015-04-05, opcjonalne signedProtocol
pole (spr
) określa protokół dozwolony dla żądania 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
. Należy pamiętać, że tylko protokół HTTP nie jest dozwoloną wartością.
Określanie zakresów dostępu do tabel
Pola startPk
, startRk
, endPk
i endRk
definiują zakres jednostek tabeli skojarzonych z sygnaturą dostępu współdzielonego. Zapytania tabeli zwracają tylko wyniki znajdujące się w zakresie, a próby użycia sygnatury dostępu współdzielonego w celu dodawania, aktualizowania lub usuwania jednostek poza tym zakresem zakończy się niepowodzeniem.
Jeśli startPk
jest endPk
równa , sygnatura dostępu współdzielonego autoryzuje dostęp do jednostek tylko w jednej partycji w tabeli.
Jeśli startPk
równa endPk
się i startRk
równa endRk
, sygnatura dostępu współdzielonego może uzyskać dostęp tylko do jednej jednostki w jednej partycji.
Aby dowiedzieć się, jak te pola ograniczają dostęp do jednostek w tabeli, zapoznaj się z następującą tabelą:
Pola obecne | Zakres ograniczenia |
---|---|
startPk |
partitionKey >= startPk |
endPk |
partitionKey <= endPk |
startPk , startRk |
(partitionKey >startPk ) || (partitionKey == startPk && rowKey >= startRk ) |
endPk , endRk |
(partitionKey <endPk ) || (partitionKey == endPk && rowKey <= endRk ) |
Określanie głębokości katalogu
Gdy hierarchiczna przestrzeń nazw jest włączona, a signedResource
pole określa katalog (sr=d
), należy również określić signedDirectoryDepth
pole (sdd
), aby wskazać liczbę podkatalogów w katalogu głównym. Wartość sdd
pola musi być nieujemną 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.
https://{account}.blob.core.windows.net/{container}/d1/d2
Katalog ma głębokość 2.
To pole jest obsługiwane w wersji 2020-02-10 lub nowszej.
Określanie podpisanego identyfikatora
Po określeniu signedIdentifier
pola w identyfikatorze URI należy powiązać określony sygnaturę dostępu współdzielonego z odpowiednimi zapisanymi zasadami dostępu. Przechowywane zasady dostępu zapewniają dodatkową miarę kontroli nad co najmniej jednym sygnaturą dostępu współdzielonego, w tym możliwość odwoływanie podpisu w razie potrzeby. Każdy kontener, kolejka, tabela lub udział może mieć maksymalnie pięć przechowywanych zasad dostępu.
W poniższej tabeli opisano sposób odwoływania się do podpisanego identyfikatora w identyfikatorze URI:
Nazwa pola | Parametr zapytania | Opis |
---|---|---|
signedIdentifier |
si |
Opcjonalny. Unikatowa wartość zawierająca maksymalnie 64 znaki, która jest skorelowana z zasadami dostępu określonymi dla kontenera, kolejki lub tabeli. |
Zapisane zasady dostępu zawierają podpisany identyfikator, czyli wartość maksymalnie 64 znaków, która jest unikatowa w obrębie zasobu. Możesz określić wartość tego podpisanego identyfikatora dla signedidentifier
pola w identyfikatorze URI sygnatury dostępu współdzielonego. Po określeniu podpisanego identyfikatora w identyfikatorze URI należy skojarzyć podpis z zapisanymi zasadami dostępu. Aby ustanowić zasady dostępu na poziomie kontenera przy użyciu interfejsu API REST, zobacz Delegowanie dostępu za pomocą sygnatury dostępu współdzielonego.
Określanie zakresu szyfrowania
Za pomocą signedEncryptionScope
pola w identyfikatorze URI można określić zakres szyfrowania, którego może używać aplikacja kliencka. Wymusza ona szyfrowanie po stronie serwera z określonym zakresem szyfrowania podczas przekazywania obiektów blob (PUT) przy użyciu tokenu SAS. Get i HEAD nie będą ograniczone i wykonywane tak jak wcześniej.
W poniższej tabeli opisano sposób odwoływania się do podpisanego zakresu szyfrowania w identyfikatorze URI:
Nazwa pola | Parametr zapytania | Opis |
---|---|---|
signedEncryptionScope |
ses |
Opcjonalny. Wskazuje zakres szyfrowania używany do szyfrowania zawartości żądania. |
To pole jest obsługiwane w wersji 2020-12-06 lub nowszej. Jeśli dodasz ses
element przed obsługiwaną wersją, usługa zwróci kod odpowiedzi błędu 403 (Zabronione).
Jeśli ustawisz domyślny zakres szyfrowania dla kontenera lub systemu plików, ses
parametr zapytania uwzględnia zasady szyfrowania kontenera. Jeśli występuje niezgodność między parametrem ses
zapytania i x-ms-default-encryption-scope
nagłówkiem, a x-ms-deny-encryption-scope-override
nagłówek jest ustawiony na true
wartość , usługa zwraca kod odpowiedzi błędu 403 (Zabronione).
Po podaniu nagłówka x-ms-encryption-scope
i parametru ses
zapytania w żądaniu PUT usługa zwraca kod odpowiedzi błędu 400 (nieprawidłowe żądanie), jeśli występuje niezgodność.
Określanie podpisu
Część identyfikatora URI jest używana do autoryzowania żądania utworzonego przy użyciu sygnatury dostępu współdzielonego. Usługa Azure Storage używa schematu autoryzacji klucza współdzielonego do autoryzacji sygnatury dostępu współdzielonego usługi.
W poniższej tabeli opisano sposób określania podpisu w identyfikatorze URI:
Nazwa pola | Parametr zapytania | Opis |
---|---|---|
signature |
sig |
Ciąg do znaku to unikatowy ciąg skonstruowany z pól i musi zostać zweryfikowany w celu autoryzowania żądania. Podpis to kod uwierzytelniania komunikatów oparty na skrótach (HMAC), który jest obliczany za pośrednictwem ciągu do podpisania i klucza przy użyciu algorytmu SHA256, a następnie kodowania przy użyciu kodowania Base64. |
Konstruowanie ciągu podpisu
Aby utworzyć ciąg podpisu sygnatury dostępu współdzielonego, najpierw skonstruuj 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.
Wersja 2020-12-06 lub nowsza
Wersja 2020-12-06 dodaje obsługę pola zakresu szyfrowania podpisanego. Aby skonstruować ciąg do podpisania dla zasobów usługi Blob Storage, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedIP + "\n" +
signedProtocol + "\n" +
signedVersion + "\n" +
signedResource + "\n" +
signedSnapshotTime + "\n" +
signedEncryptionScope + "\n" +
rscc + "\n" +
rscd + "\n" +
rsce + "\n" +
rscl + "\n" +
Wersja 2018-11-09 lub nowsza
Wersja 2018-11-09 dodaje obsługę podpisanych pól czasu migawek obiektów blob i podpisanych zasobów. Te pola muszą być uwzględnione w ciągu do podpisania. Aby skonstruować ciąg do podpisania dla zasobów usługi Blob Storage, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedIP + "\n" +
signedProtocol + "\n" +
signedVersion + "\n" +
signedResource + "\n"
signedSnapshotTime + "\n" +
rscc + "\n" +
rscd + "\n" +
rsce + "\n" +
rscl + "\n" +
rsct
Wersja 2015-04-05 lub nowsza
Wersja 2015-04-05 dodaje obsługę podpisanych pól protokołu IP i podpisanych. Te pola muszą być uwzględnione w ciągu do podpisania. Aby skonstruować ciąg do podpisania dla usługi Blob Storage lub Azure Files zasobów, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedIP + "\n" +
signedProtocol + "\n" +
signedVersion + "\n" +
rscc + "\n" +
rscd + "\n" +
rsce + "\n" +
rscl + "\n" +
rsct
Aby utworzyć znak ciągu dla zasobów usługi Table Storage, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedIP + "\n" +
signedProtocol + "\n" +
signedVersion + "\n" +
startingPartitionKey + "\n"
startingRowKey + "\n"
endingPartitionKey + "\n"
endingRowKey
Aby utworzyć ciąg do podpisania dla zasobów usługi Queue Storage, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedIP + "\n" +
signedProtocol + "\n" +
signedVersion
Wersja 2013-08-15 do 2015-02-21
Aby skonstruować ciąg do podpisania dla zasobów usługi Blob Storage lub Azure Files przy użyciu wersji 2013-08-15 do 2015-02-21, użyj następującego formatu. W przypadku Azure Files sygnatura dostępu współdzielonego jest obsługiwana w wersji 2015-02-21.
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedVersion + "\n" +
rscc + "\n" +
rscd + "\n" +
rsce + "\n" +
rscl + "\n" +
rsct
Aby skonstruować znak ciągu dla tabeli, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedVersion + "\n" +
startPk + "\n" +
startRk + "\n" +
endPk + "\n" +
endRk
Aby skonstruować znak ciągu dla kolejki, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedVersion
Wersja 2012-02-12
Aby skonstruować znak ciągu dla zasobów usługi Blob Storage w wersji 2012-02-12, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier + "\n" +
signedVersion
Wersje starsze niż 2012-02-12
Aby skonstruować ciąg do podpisania dla zasobów usługi Blob Storage dla wersji starszych niż 2012-02-12, użyj następującego formatu:
StringToSign = signedPermissions + "\n" +
signedStart + "\n" +
signedExpiry + "\n" +
canonicalizedResource + "\n" +
signedIdentifier
Podczas tworzenia ciągu do podpisania pamiętaj o następujących kwestiach:
Jeśli pole jest opcjonalne i nie podano go w ramach żądania, określ pusty ciąg dla tego pola. Pamiętaj, aby po pustym ciągu uwzględnić znak nowego wiersza (\n).
Ciąg-znak dla tabeli musi zawierać dodatkowe parametry, nawet jeśli są puste ciągi.
Część
signedpermission
ciągu musi zawierać oznaczenia uprawnień w stałej kolejności, która jest specyficzna dla każdego typu zasobu. Każda kombinacja tych uprawnień jest akceptowalna, ale kolejność liter uprawnień musi być zgodna z kolejnością w poniższej tabeli.Typ zasobu Kolejność uprawnień Obiekt blob racwd Kontener racwdl Kolejka raup File rcwd Udostępnij rcwdl Tabela raud Na przykład przykłady prawidłowych ustawień uprawnień dla kontenera obejmują
rw
, ,rd
rl
,wd
,wl
irl
. Przykłady nieprawidłowych ustawień towr
,dr
,lr
idw
. Określanie oznaczenia uprawnień więcej niż raz jest niedozwolone.Podaj wartość dla
signedIdentifier
części ciągu, jeśli kojarzysz żądanie z zapisanymi zasadami dostępu.Sygnatura dostępu współdzielonego określająca wersję usługi magazynu, która jest wcześniejsza niż 2012-02-12, może udostępniać tylko obiekt blob lub kontener i musi pominąć
signedVersion
i znak nowego wiersza przed nim.Część
canonicalizedResource
ciągu jest ścieżką kanoniczną do podpisanego zasobu. Musi ona zawierać nazwę usługi (Blob Storage, Table Storage, Queue Storage lub Azure Files) dla wersji 2015-02-21 lub nowszej, nazwę konta magazynu oraz nazwę zasobu i musi być zdekodowana pod adresem URL. Nazwy obiektów blob muszą zawierać kontener obiektu blob. Nazwy tabel muszą być małymi literami.
Kanoniczny ciąg zasobu dla kontenera, kolejki, tabeli lub udziału plików musi pominąć końcowy ukośnik (/) dla sygnatury dostępu współdzielonego, która zapewnia dostęp do tego obiektu.
W poniższych przykładach pokazano, jak utworzyć canonicalizedResource
część ciągu w zależności od typu zasobu.
Containers
W wersji 2015-02-21 lub nowszej:
URL = https://myaccount.blob.core.windows.net/music
canonicalizedResource = "/blob/myaccount/music"
W przypadku wersji starszych niż 2015-02-21:
URL = https://myaccount.blob.core.windows.net/music
canonicalizedResource = "/myaccount/music"
Obiekty blob
W wersji 2015-02-21 lub nowszej:
URL = https://myaccount.blob.core.windows.net/music/intro.mp3
canonicalizedResource = "/blob/myaccount/music/intro.mp3"
W przypadku wersji starszych niż 2015-02-21:
URL = https://myaccount.blob.core.windows.net/music/intro.mp3
canonicalizedResource = "/myaccount/music/intro.mp3"
Udziały plików
URL = https://myaccount.file.core.windows.net/music
canonicalizedResource = "/file/myaccount/music"
Pliki
URL = https://myaccount.file.core.windows.net/music/intro.mp3
canonicalizedResource = "/file/myaccount/music/intro.mp3"
Kolejki
W wersji 2015-02-21 lub nowszej:
URL = https://myaccount.queue.core.windows.net/thumbnails
canonicalizedResource = "/queue/myaccount/thumbnails"
W przypadku wersji starszych niż 2015-02-21:
URL = https://myaccount.queue.core.windows.net/thumbnails
canonicalizedResource = "/myaccount/thumbnails"
Tabele
Jeśli podpisany zasób jest tabelą, upewnij się, że nazwa tabeli ma małe litery w formacie kanonicznym.
W wersji 2015-02-21 lub nowszej:
URL = https://myaccount.table.core.windows.net/Employees(PartitionKey='Jeff',RowKey='Price')
canonicalizedResource = "/table/myaccount/employees"
W przypadku wersji starszych niż 2015-02-21:
URL = https://myaccount.table.core.windows.net/Employees(PartitionKey='Jeff',RowKey='Price')
canonicalizedResource = "/myaccount/employees"
Okres istnienia i odwołanie sygnatury dostępu współdzielonego
Sygnatury dostępu współdzielonego udzielają użytkownikom praw dostępu do zasobów konta magazynu. Podczas planowania używania sygnatury dostępu współdzielonego zastanów się nad okresem istnienia sygnatury dostępu współdzielonego i informacją, czy aplikacja może wymagać odwołania praw dostępu w określonych okolicznościach.
Sygnatura dostępu współdzielonego ad hoc a przechowywane zasady dostępu
Sygnatura dostępu współdzielonego usługi może mieć jedną z dwóch form:
Sygnatura dostępu współdzielonego ad hoc: podczas tworzenia sygnatury dostępu współdzielonego ad hoc czas rozpoczęcia, czas wygaśnięcia i uprawnienia sygnatury dostępu współdzielonego są określone w identyfikatorze URI sygnatury dostępu współdzielonego (lub domniemanym, jeśli zostanie pominięty czas rozpoczęcia). Dowolny typ sygnatury dostępu współdzielonego może być sygnaturą dostępu współdzielonego ad hoc.
Okres istnienia sygnatury dostępu współdzielonego ad hoc można zarządzać przy użyciu
signedExpiry
pola . Jeśli chcesz nadal udzielać klientowi dostępu do zasobu po upływie czasu wygaśnięcia, musisz wystawić nowy podpis. Zalecamy, aby okres istnienia sygnatury dostępu współdzielonego był krótki. Przed wersją 2012-02-12 sygnatura dostępu współdzielonego nie skojarzona z zapisanymi zasadami dostępu nie może mieć aktywnego okresu, który przekroczył jedną godzinę.Sygnatura dostępu współdzielonego z zapisanymi zasadami dostępu: przechowywane zasady dostępu są definiowane w kontenerze zasobów, który może być kontenerem obiektów blob, tabelą, kolejką lub udziałem plików. Zapisane zasady dostępu umożliwiają zarządzanie ograniczeniami dla co najmniej jednego sygnatury dostępu współdzielonego. Po skojarzeniu sygnatury dostępu współdzielonego z zapisanymi zasadami dostępu sygnatura dostępu współdzielonego dziedziczy ograniczenia (czyli czas rozpoczęcia, czas wygaśnięcia i uprawnienia) zdefiniowane dla przechowywanych zasad dostępu.
Przechowywane zasady dostępu są reprezentowane przez
signedIdentifier
pole w identyfikatorze URI. Przechowywane zasady dostępu zapewniają dodatkową miarę kontroli nad co najmniej jednym sygnaturą dostępu współdzielonego, w tym możliwość odwoływanie podpisu w razie potrzeby.
Odwoływanie sygnatury dostępu współdzielonego
Ponieważ identyfikator URI sygnatury dostępu współdzielonego jest adresem URL, każdy, kto uzyskuje sygnaturę dostępu współdzielonego, może go używać niezależnie od tego, kto pierwotnie go utworzył. Jeśli sygnatura dostępu współdzielonego jest publikowana publicznie, może być używana przez każdą osobę na świecie. Sygnatura dostępu współdzielonego udziela dostępu do zasobów każdemu, kto posiada go do momentu wystąpienia jednej z czterech rzeczy:
Osiągnięto czas wygaśnięcia określony w sygnaturze dostępu współdzielonego ad hoc.
Osiągnięto czas wygaśnięcia określony w przechowywanych zasadach dostępu, do których odwołuje się sygnatura dostępu współdzielonego, jeśli są przywoływały przechowywane zasady dostępu, a zasady dostępu określają czas wygaśnięcia.
Można osiągnąć czas wygaśnięcia, ponieważ interwał upłynie lub zmodyfikowano przechowywane zasady dostępu, aby mieć czas wygaśnięcia w przeszłości, co jest jednym ze sposobów odwołania sygnatury dostępu współdzielonego.
Przechowywane zasady dostępu, do których odwołuje się sygnatura dostępu współdzielonego, są usuwane, co powoduje odwołanie sygnatury dostępu współdzielonego. Jeśli usługa Azure Storage nie może zlokalizować przechowywanych zasad dostępu określonych w sygnaturze dostępu współdzielonego, klient nie może uzyskać dostępu do zasobu wskazanego przez identyfikator URI.
Jeśli ponownie utworzysz zapisane zasady dostępu o dokładnie takiej samej nazwie jak usunięte zasady, wszystkie istniejące tokeny SAS będą ponownie prawidłowe zgodnie z uprawnieniami skojarzonymi z tymi zapisanymi zasadami dostępu. Przyjęto założenie, że czas wygaśnięcia sygnatury dostępu współdzielonego nie minął. Jeśli zamierzasz odwołać sygnaturę dostępu współdzielonego, pamiętaj, aby użyć innej nazwy podczas ponownego tworzenia zasad dostępu z upływem czasu wygaśnięcia w przyszłości.
Klucz konta, który został użyty do utworzenia sygnatury dostępu współdzielonego, jest ponownie wygenerowany. Ponowne generowanie klucza konta powoduje, że wszystkie składniki aplikacji używające tego klucza nie mogą autoryzować, dopóki nie zostaną zaktualizowane tak, aby używały innego prawidłowego klucza konta lub nowo wygenerowanego klucza konta. Ponowne generowanie klucza konta jest jedynym sposobem natychmiastowego odwołania sygnatury dostępu współdzielonego ad hoc.
Ważne
Identyfikator URI sygnatury dostępu współdzielonego jest skojarzony z kluczem konta używanym do tworzenia podpisu i skojarzonych zapisanych zasad dostępu, jeśli ma to zastosowanie. Jeśli nie określono żadnych przechowywanych zasad dostępu, jedynym sposobem odwołania sygnatury dostępu współdzielonego jest zmiana klucza konta.
Najlepszym rozwiązaniem jest użycie przechowywanych zasad dostępu z sygnaturą dostępu współdzielonego usługi. Jeśli nie chcesz używać przechowywanych zasad dostępu, pamiętaj, aby zachować okres, w którym sygnatura dostępu współdzielonego ad hoc jest prawidłowa. Aby uzyskać więcej informacji na temat kojarzenia sygnatury dostępu współdzielonego usługi z zapisanymi zasadami dostępu, zobacz Definiowanie przechowywanych zasad dostępu.
Przykład sygnatury dostępu współdzielonego usługi
W poniższym przykładzie pokazano identyfikator URI obiektu blob z dołączonym do niego tokenem SAS usługi. Token SYGNATURy dostępu współdzielonego usługi zapewnia uprawnienia do 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&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 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. |
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 Azure Storage | sv=2023-05-24 |
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 autoryzacji dostępu do obiektu blob. Podpis jest kluczem HMAC obliczanym za pomocą ciągu do podpisania i klucza przy użyciu algorytmu SHA256, a następnie zakodowanego przy użyciu kodowania Base64. |