Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage przy użyciu sygnatur dostępu współdzielonego (SAS)

Sygnatura dostępu współdzielonego (SAS) zapewnia bezpieczny delegowany dostęp do zasobów na koncie magazynu. Dzięki sygnaturze dostępu współdzielonego masz szczegółową kontrolę nad tym, jak klient może uzyskać dostęp do danych. Na przykład:

  • Do jakich zasobów klient może uzyskać dostęp.

  • Jakie uprawnienia mają do tych zasobów.

  • Czas ważności sygnatury dostępu współdzielonego.

Typy sygnatur dostępu współdzielonego

Usługa Azure Storage obsługuje trzy typy sygnatur dostępu współdzielonych:

  • Sygnatura dostępu współdzielonego delegowania użytkowników

  • Sygnatura dostępu współdzielonego usługi

  • Sygnatura dostępu współdzielonego konta

Sygnatura dostępu współdzielonego delegowania użytkowników

Sygnatura dostępu współdzielonego delegowania użytkownika jest Azure Active Directory (Azure AD), a także przez uprawnienia określone dla sygnatury dostępu współdzielonego. Sygnatura dostępu współdzielonego delegowania użytkownika dotyczy tylko usługi Blob Storage.

Aby uzyskać więcej informacji na temat sygnatury dostępu współdzielonego delegowania użytkownika, zobacz Tworzenie sygnatury dostępu współdzielonego delegowania użytkownika (interfejs API REST).

Sygnatura dostępu współdzielonego usługi

Sygnatura dostępu współdzielonego usługi jest zabezpieczona przy użyciu klucza konta magazynu. Sygnatura dostępu współdzielonego usługi deleguje dostęp do zasobu tylko w jednej z usług azure Storage: Blob Storage, Queue Storage, Table Storage lub Azure Files.

Aby uzyskać więcej informacji na temat sygnatury dostępu współdzielonego usługi, zobacz Tworzenie sygnatury dostępu współdzielonego usługi (interfejs API REST).

Sygnatura dostępu współdzielonego konta

Sygnatura dostępu współdzielonego konta jest zabezpieczona przy użyciu klucza konta magazynu. Sygnatura dostępu współdzielonego konta deleguje dostęp do zasobu w co najmniej jednej usłudze magazynu. Wszystkie operacje dostępne za pośrednictwem sygnatury dostępu współdzielonego delegowania usługi lub użytkownika są również dostępne za pośrednictwem sygnatury dostępu współdzielonego konta.

Można również delegować dostęp do następujących czynności:

  • Operacje na poziomie usługi (na przykład operacje Get/Set Service Properties i Get Service Stats).

  • Operacje odczytu, zapisu i usuwania, które nie są dozwolone w przypadku sygnatury dostępu współdzielonego usługi.

Aby uzyskać więcej informacji na temat sygnatury dostępu współdzielonego konta, utwórz sygnaturę dostępu współdzielonego konta (interfejs API REST).

Uwaga

Firma Microsoft zaleca używanie poświadczeń usługi Azure AD, gdy jest to możliwe, jako najlepszego rozwiązania w zakresie zabezpieczeń, a nie klucza konta, którego bezpieczeństwo może być łatwiej naruszone. Jeśli projekt aplikacji wymaga sygnatur dostępu współdzielonego w celu uzyskania dostępu do usługi Blob Storage, użyj poświadczeń usługi Azure AD, aby utworzyć sygnaturę dostępu współdzielonego delegowania użytkownika, jeśli jest to możliwe w celu uzyskania najwyższego bezpieczeństwa. Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu do danych w usłudze Azure Storage.

Sygnatura dostępu współdzielona może mieć jedną z następujących dwóch postaci:

  • 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 są określane w adresie URI sygnatury dostępu współdzielonego. Każdy typ sygnatury dostępu współdzielonego może być sygnaturą dostępu współdzielonego ad hoc.

  • Sygnatura dostępu współdzielonego usługi 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 mogą służyć do zarządzania ograniczeniami dotyczącymi co najmniej jednej sygnatury dostępu współdzielonych usługi. W przypadku skojarzenia sygnatury dostępu współdzielonego usługi z zapisanymi zasadami dostępu sygnatura dostępu współdzielonego dziedziczy ograniczenia dotyczące czasu rozpoczęcia, czasu wygaśnięcia i uprawnień zdefiniowanych dla — — przechowywanych zasad dostępu.

Uwaga

Sygnatura dostępu współdzielonego delegowania użytkownika lub sygnatura dostępu współdzielonego konta muszą być sygnaturą dostępu współdzielonego ad hoc. Przechowywane zasady dostępu nie są obsługiwane w przypadku sygnatury dostępu współdzielonego delegowania użytkowników ani sygnatury dostępu współdzielonego konta.

Jak działa sygnatura dostępu współdzielona

Sygnatura dostępu współdzielona to podpisany URI, który wskazuje jeden lub więcej zasobów magazynu. Ten URI zawiera token, który zawiera specjalny zestaw parametrów zapytania. Token wskazuje, w jaki sposób klient może uzyskiwać dostęp do zasobów. Jeden z parametrów zapytania, podpis, jest zbudowany z parametrów sygnatury dostępu współdzielonego i podpisany za pomocą klucza, który został użyty do utworzenia sygnatury dostępu współdzielonego. Ta sygnatura jest używana przez usługę Azure Storage do autoryzowania dostępu do zasobu magazynu.

Uwaga

Nie jest możliwe inspekcja generowania tokenów SAS. Każdy użytkownik, który ma uprawnienia do generowania tokenu SAS przy użyciu klucza konta lub za pośrednictwem przypisania roli platformy Azure, może to zrobić bez wiedzy właściciela konta magazynu. Należy zachować ostrożność, aby ograniczyć uprawnienia, które umożliwiają użytkownikom generowanie tokenów SAS. Aby uniemożliwić użytkownikom generowanie sygnatury dostępu współdzielonego podpisanego przy użyciu klucza konta dla obciążeń obiektów blob i kolejek, możesz uniemożliwić dostęp za pomocą klucza wspólnego do konta magazynu. Aby uzyskać więcej informacji, zobacz Zapobieganie autoryzacji za pomocą klucza wspólnego.

Sygnatura sas i autoryzacja

Token SAS można podpisać przy użyciu klucza delegowania użytkownika lub klucza konta magazynu (klucza wspólnego).

Podpisywanie tokenu SAS przy użyciu klucza delegowania użytkownika

Token SAS można podpisać przy użyciu klucza delegowania użytkownika, który został utworzony przy użyciu Azure Active Directory (Azure AD). Sygnatura dostępu współdzielonego delegowania użytkownika jest podpisyana przy użyciu klucza delegowania użytkownika.

Aby uzyskać klucz, a następnie utworzyć sygnaturę dostępu współdzielonego, podmiot zabezpieczeń usługi Azure AD musi mieć przypisaną rolę platformy Azure, która zawiera Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey akcję. Aby uzyskać więcej informacji, zobacz Tworzenie sygnatury dostępu współdzielonego delegowania użytkownika (interfejs API REST).

Podpisywanie tokenu SAS przy użyciu klucza konta

Zarówno sygnatura dostępu współdzielonego usługi, jak i sygnatura dostępu współdzielonego konta są podpisane przy użyciu klucza konta magazynu. Aby utworzyć sygnaturę dostępu współdzielonego podpisaną przy użyciu klucza konta, aplikacja musi mieć dostęp do klucza konta.

Gdy żądanie zawiera token SAS, jest ono autoryzowane na podstawie sposobu podpisania tego tokenu SAS. Klucz dostępu lub poświadczenia używane do tworzenia tokenu SAS są również używane przez usługę Azure Storage do udzielania dostępu klientowi, który posiada sygnaturę dostępu współdzielonego.

W poniższej tabeli przedstawiono sposób autoryzacji każdego typu tokenu SAS.

Typ sygnatury dostępu współdzielonego Typ autoryzacji
Sygnatura dostępu współdzielonego delegowania użytkownika (tylko usługa Blob Storage) Azure AD
Sygnatura dostępu współdzielonego usługi Klucz wspólny
Sygnatura dostępu współdzielonego konta Klucz wspólny

Firma Microsoft zaleca używanie sygnatury dostępu współdzielonego delegowania użytkownika, jeśli jest to możliwe, aby zapewnić najwyższe bezpieczeństwo.

Token SAS

Token SAS to ciąg generowany po stronie klienta, na przykład przy użyciu jednej z bibliotek klienta usługi Azure Storage klienta. Token SAS nie jest śledzony przez usługę Azure Storage w żaden sposób. Po stronie klienta można utworzyć nieograniczoną liczbę tokenów SAS. Po utworzeniu sygnatury dostępu współdzielonego można dystrybuować ją do aplikacji klienckich, które wymagają dostępu do zasobów na koncie magazynu.

Aplikacje klienckie zapewniają sygnaturę URI sygnatury dostępu współdzielonego Storage Azure jako część żądania. Następnie usługa sprawdza parametry sygnatury dostępu współdzielonego i podpis, aby sprawdzić, czy są prawidłowe. Jeśli usługa sprawdzi, czy podpis jest prawidłowy, żądanie jest autoryzowane. W przeciwnym razie żądanie zostanie odrzucone z kodem błędu 403 (Zabronione).

Oto przykładowy interfejs URI sygnatury dostępu współdzielonego usługi, który pokazuje URI zasobu i token sygnatury dostępu współdzielonego. Ponieważ token SYGNATURY dostępu współdzielonego składa się z ciągu zapytania URI, najpierw musi nasłuchić znak zapytania, a następnie token sygnatury dostępu współdzielonego:

Składniki interfejsu URI sygnatury dostępu współdzielonego usługi

Kiedy należy używać sygnatury dostępu współdzielonych

Użyj sygnatury dostępu współdzielonego, aby zapewnić bezpieczny dostęp do zasobów na koncie magazynu dowolneowi klientowi, który w przeciwnym razie nie ma uprawnień do tych zasobów.

Często spotykany scenariusz, w którym sygnatura dostępu współdzielonego jest przydatna, to usługa, w której użytkownicy odczytują i zapisują własne dane na koncie magazynu. W scenariuszu, w którym dane użytkowników są przechowywane na koncie magazynu, zwykle występują dwa wzorce projektowe:

  1. Klienci przekazują i pobierają dane za pośrednictwem usługi serwera proxy frontonu, która przeprowadza uwierzytelnianie. Ta usługa serwera proxy frontou umożliwia weryfikację reguł biznesowych. Jednak w przypadku dużych ilości danych lub transakcji o dużej ilości utworzenie usługi, która może być skalowana w celu dopasowania do zapotrzebowania, może być kosztowna lub trudna.

    Diagram scenariusza: Usługa serwera proxy frontony

  2. Uproszczona usługa uwierzytelnia klienta zgodnie z potrzebami, a następnie generuje sygnaturę dostępu współdzielonego. Po otrzymaniu sygnatury dostępu współdzielonego aplikacja kliency może bezpośrednio uzyskać dostęp do zasobów konta magazynu. Uprawnienia dostępu są definiowane przez sygnaturę dostępu współdzielonego i interwał dozwolony przez sygnaturę dostępu współdzielonego. Sygnatura dostępu współdzielonego zmniejsza konieczność kierowania wszystkich danych przez usługę serwera proxy frontonu.

    Diagram scenariusza: usługa dostawcy sygnatur dostępu współdzielonego

Wiele rzeczywistych usług może korzystać z hybrydowej z tych dwóch metod. Na przykład niektóre dane mogą być przetwarzane i weryfikowane za pośrednictwem serwera proxy frontou. Inne dane są zapisywane i/lub odczytywane bezpośrednio przy użyciu sygnatury dostępu współdzielonego.

Ponadto sygnatura dostępu współdzielonego jest wymagana do autoryzowania dostępu do obiektu źródłowego w operacji kopiowania w niektórych scenariuszach:

  • Podczas kopiowania obiektu blob do innego obiektu blob, który znajduje się na innym koncie magazynu.

    Opcjonalnie możesz użyć sygnatury dostępu współdzielonego, aby autoryzować dostęp do docelowego obiektu blob.

  • Podczas kopiowania pliku do innego pliku, który znajduje się na innym koncie magazynu.

    Opcjonalnie możesz użyć sygnatury dostępu współdzielonego, aby autoryzować dostęp do pliku docelowego.

  • Podczas kopiowania obiektu blob do pliku lub pliku do obiektu blob.

    Sygnatury dostępu współdzielonego należy używać nawet wtedy, gdy obiekty źródłowe i docelowe znajdują się w ramach tego samego konta magazynu.

Najlepsze rozwiązania dotyczące korzystania z sygnatury dostępu współdzielonego

W przypadku korzystania z sygnatur dostępu współdzielonych w aplikacjach należy pamiętać o dwóch potencjalnych zagrożeniach:

  • W przypadku wycieku sygnatury dostępu współdzielonego może z niego korzystać każda osoba, która ją uzyska, co może potencjalnie naruszyć bezpieczeństwo konta magazynu.

  • Jeśli sygnatura dostępu współdzielonego dostarczana do aplikacji klienckiej wygaśnie i aplikacja nie będzie mogła pobrać nowej sygnatury dostępu współdzielonego z usługi, funkcjonalność aplikacji może być utrudniona.

Poniższe zalecenia dotyczące używania sygnatur dostępu współdzielonych mogą pomóc w zminimalizowaniu tych zagrożeń:

  • Zawsze używaj protokołu HTTPS do tworzenia lub dystrybuowania sygnatury dostępu współdzielonego. Jeśli sygnatura dostępu współdzielonego zostanie przekazana przez protokół HTTP i przechwycona, osoba atakująca wykonująca atak typu man-in-the-middle będzie mogła odczytać sygnaturę dostępu współdzielonego. Następnie mogą używać tej sygnatury dostępu współdzielonego tak samo, jak może to mieć zamierzony użytkownik. Może to naruszyć bezpieczeństwo poufnych danych lub uszkodzenie danych przez złośliwego użytkownika.

  • Jeśli to możliwe, użyj sygnatury dostępu współdzielonego delegowania użytkownika. Sygnatura dostępu współdzielonego delegowania użytkownika zapewnia doskonałe zabezpieczenia sygnatury dostępu współdzielonego usługi lub sygnatury dostępu współdzielonego konta. Sygnatura dostępu współdzielonego delegowania użytkownika jest zabezpieczona przy użyciu poświadczeń usługi Azure AD, dzięki czemu nie trzeba przechowywać klucza konta przy użyciu kodu.

  • Mieć plan odwołania dla sygnatury dostępu współdzielonego. Upewnij się, że jesteś przygotowany do reagowania w przypadku naruszenia zabezpieczeń sygnatury dostępu współdzielonego.

  • Zdefiniuj przechowywane zasady dostępu dla sygnatury dostępu współdzielonego usługi. Zapisane zasady dostępu zapewniają możliwość odwołania uprawnień dla sygnatury dostępu współdzielonego usługi bez konieczności ponownego generowania kluczy konta magazynu. Ustaw datę wygaśnięcia tych bardzo daleko w przyszłości (lub nieskończoną) i upewnij się, że jest ona regularnie aktualizowana w celu przeniesienia jej w przyszłość.

  • Użyj najbliższych czasów wygaśnięcia dla sygnatury dostępu współdzielonego usługi ad hoc lub sygnatury dostępu współdzielonego konta. W ten sposób, nawet jeśli sygnatura dostępu współdzielonego zostanie naruszona, będzie ona ważna tylko przez krótki czas. To rozwiązanie jest szczególnie ważne, jeśli nie można odwołać się do zapisanych zasad dostępu. Krótkoterminowe czasy wygaśnięcia ograniczają również ilość danych, które można zapisywać w obiekcie blob, ograniczając czas dostępny do przekazania do niego.

  • W razie potrzeby klienci automatycznie odnawiają sygnaturę dostępu współdzielonego. Klienci powinni odnowić sygnaturę dostępu współdzielonego jeszcze przed jej wygaśnięciem, aby zapewnić czas na ponowne próby, jeśli usługa dostarczająca sygnaturę dostępu współdzielonego jest niedostępna. W niektórych przypadkach może to być niepotrzebne. Możesz na przykład chcieć użyć sygnatury dostępu współdzielonego do niewielkiej liczby natychmiastowych, krótkotrwałych operacji. Oczekuje się, że te operacje zostaną wykonane w okresie wygaśnięcia. W związku z tym nie oczekujesz odnowienia sygnatury dostępu współdzielonego. Jeśli jednak masz klienta, który rutynowo wysyła żądania za pośrednictwem sygnatury dostępu współdzielonego, możliwość wygaśnięcia ma swoje zastosowania.

  • Należy zachować ostrożność w przypadku czasu rozpoczęcia sygnatury dostępu współdzielonego. Jeśli ustawisz czas rozpoczęcia sygnatury dostępu współdzielonego na bieżący czas, awarie mogą występować sporadycznie przez kilka pierwszych minut. Jest to spowodowane tym, że różne maszyny mają nieco inne bieżące czasy (znane jako nieschypki zegara). Ogólnie rzecz biorąc, ustaw czas rozpoczęcia na co najmniej 15 minut w przeszłości. Nie należy też ustawiać jej w ogóle, co spowoduje, że będzie ona obowiązywać natychmiast we wszystkich przypadkach. To samo dotyczy również czasu wygaśnięcia — pamiętaj, że w dowolnym żądaniu można zaobserwować maksymalnie 15 minut niescytości zegara w dowolnym kierunku. W przypadku klientów korzystających z wersji REST wcześniejszej niż 2012-02-12 maksymalny czas trwania sygnatury dostępu współdzielonego, która nie odwołuje się do przechowywanych zasad dostępu, wynosi 1 godzinę. Wszystkie zasady, które określają czas dłuższy niż 1 godzina, nie będą mieć wartości.

  • Należy zachować ostrożność przy użyciu formatu daty/godziny sygnatury dostępu współdzielonego. W przypadku niektórych narzędzi (takich jak AzCopy) formaty daty/godziny muszą mieć formaty "+%Y-%m-%dT%H:%M:%SZ". Ten format obejmuje w szczególności sekundy.

  • Należy konkretną konkretną grupę zasobów, do której ma zostać uzyskany dostęp. Najlepszym rozwiązaniem w zakresie zabezpieczeń jest zapewnienie użytkownikowi minimalnych wymaganych uprawnień. Jeśli użytkownik potrzebuje tylko dostępu do odczytu do jednej jednostki, przyznaj jej dostęp do odczytu do tej pojedynczej jednostki, a nie dostęp do odczytu/zapisu/usuwania do wszystkich jednostek. Pomaga to również zmniejszyć szkody w przypadku naruszenia sygnatury dostępu współdzielonego, ponieważ ta sygnatura dostępu współdzielonego ma mniejszą moc w rękach osoby atakującej.

  • Należy pamiętać, że twoje konto będzie rozliczane za użycie, w tym za pośrednictwem sygnatury dostępu współdzielonego. Jeśli zapewnisz dostęp do zapisu do obiektu blob, użytkownik może przekazać obiekt blob o pojemności 200 GB. Jeśli udzielono im również dostępu do odczytu, mogą oni pobrać go 10 razy, co wiąże się z kosztami danych wychodzących o 2 TB. Ponownie podaj ograniczone uprawnienia, aby ułatwić ograniczenie potencjalnych akcji złośliwych użytkowników. Użyj krótkoterminowej sygnatury dostępu współdzielonego, aby zmniejszyć to zagrożenie (ale pamiętaj o niesyłaniach zegara w czasie zakończenia).

  • Weryfikowanie danych zapisywanych przy użyciu sygnatury dostępu współdzielonego. Gdy aplikacja kliency zapisuje dane na koncie magazynu, należy pamiętać, że mogą to być problemy. Jeśli planujesz walidować dane, przeanalikuj je po ich napisano i zanim będą używane przez aplikację. Ta praktyka chroni również przed uszkodzonymi lub złośliwymi danymi zapisywanych na Twoim koncie przez użytkownika, który prawidłowo uzyskał sygnaturę dostępu współdzielonego, lub przez użytkownika wykorzystującego ujawnioną sygnaturę dostępu współdzielonego.

  • Kiedy nie używać sygnatury dostępu współdzielonego. Czasami ryzyko związane z określonej operacji na koncie magazynu przeważa nad korzyściami związanymi z używaniem sygnatury dostępu współdzielonego. W przypadku takich operacji utwórz usługę warstwy środkowej, która zapisuje dane na koncie magazynu po wykonaniu walidacji reguły biznesowej, uwierzytelniania i inspekcji. Ponadto czasami łatwiej jest zarządzać dostępem w inny sposób. Jeśli na przykład chcesz, aby wszystkie obiekty blob w kontenerze było publicznie czytelne, możesz ustawić kontener jako publiczny, zamiast dostarczać sygnaturę dostępu współdzielonego każdemu klientowi w celu uzyskania dostępu.

  • Użyj Azure Monitor i dzienników usługi Azure Storage do monitorowania aplikacji. Błędy autoryzacji mogą wystąpić z powodu awarii w usłudze dostawcy sygnatur dostępu współdzielonego. Mogą one również wystąpić po niezamierzonym usunięciu zapisanych zasad dostępu. Możesz użyć rejestrowania Azure Monitor analityki magazynu, aby zaobserwować wzrost liczby błędów autoryzacji tego typu. Aby uzyskać więcej informacji, zobacz Metryki usługi Azure Storage w usłudze Azure Monitor i Rejestrowanie usługi Azure Storage Analytics.

Uwaga

Storage nie śledzi liczby sygnatur dostępu współdzielonych, które zostały wygenerowane dla konta magazynu, a żaden interfejs API nie może podać tych szczegółów. Jeśli musisz znać liczbę sygnatur dostępu współdzielonych, które zostały wygenerowane dla konta magazynu, musisz śledzić liczbę ręcznie.

Wprowadzenie do sygnatury dostępu współdzielonego

Aby rozpocząć pracę z sygnaturami dostępu współdzielonego, zobacz następujące artykuły dla każdego typu sygnatury dostępu współdzielonego.

Sygnatura dostępu współdzielonego delegowania użytkowników

Sygnatura dostępu współdzielonego usługi

Sygnatura dostępu współdzielonego konta

Następne kroki