Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage za pomocą 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 sposobem uzyskiwania dostępu do danych przez klienta. Przykład:

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

  • Jakie uprawnienia mają do tych zasobów.

  • Jak długo sygnatura dostępu współdzielonego jest prawidłowa.

Typy sygnatur dostępu współdzielonego

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

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

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

  • Sygnatura dostępu współdzielonego konta

Sygnatura dostępu współdzielonego delegowania użytkownika

Sygnatura dostępu współdzielonego delegowania użytkownika jest zabezpieczona przy użyciu poświadczeń usługi 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 za pomocą 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żesz również delegować dostęp do następujących elementów:

  • 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 przy użyciu 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 Azure AD poświadczeń, jeśli jest to możliwe, jako najlepsze rozwiązanie w zakresie zabezpieczeń, zamiast używania klucza konta, co może być łatwiejsze do naruszenia zabezpieczeń. Gdy projekt aplikacji wymaga sygnatur dostępu współdzielonego w celu uzyskania dostępu do usługi Blob Storage, użyj poświadczeń Azure AD, aby utworzyć sygnaturę dostępu współdzielonego delegowania użytkownika, jeśli jest to możliwe w celu uzyskania najwyższej jakości zabezpieczeń. Aby uzyskać więcej informacji, zobacz Autoryzowanie dostępu do danych w usłudze Azure Storage.

Sygnatura dostępu współdzielonego może mieć jedną z następujących 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 są określone w identyfikatorze URI sygnatury dostępu współdzielonego. Dowolny 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. Przechowywane zasady dostępu mogą służyć do zarządzania ograniczeniami dla co najmniej jednej sygnatury dostępu współdzielonego usługi. Po skojarzeniu sygnatury dostępu współdzielonego usługi z zapisanymi zasadami dostępu sygnatura dostępu współdzielonego dziedziczy ograniczenia — czas rozpoczęcia, czas wygaśnięcia i uprawnienia — zdefiniowane dla przechowywanych zasad dostępu.

Uwaga

Sygnatura dostępu współdzielonego delegowania użytkownika lub sygnatura dostępu współdzielonego konta musi 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żytkownika ani sygnatury dostępu współdzielonego konta.

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

Sygnatura dostępu współdzielonego to podpisany identyfikator URI wskazujący co najmniej jeden zasób magazynu. Identyfikator URI zawiera token zawierający specjalny zestaw parametrów zapytania. Token wskazuje sposób uzyskiwania dostępu do zasobów przez klienta. Jeden z parametrów zapytania, podpis, jest tworzony na podstawie parametrów sygnatury dostępu współdzielonego i podpisany przy użyciu klucza, który został użyty do utworzenia sygnatury dostępu współdzielonego. Ten podpis jest używany przez usługę Azure Storage do autoryzowania dostępu do zasobu magazynu.

Uwaga

Nie można przeprowadzić inspekcji 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 znajomości 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 podpisanej przy użyciu klucza konta dla obciążeń obiektów blob i kolejek, możesz uniemożliwić dostęp klucza współdzielonego do konta magazynu. Aby uzyskać więcej informacji, zobacz Zapobieganie autoryzacji za pomocą klucza wspólnego.

Sygnatura sygnatury dostępu współdzielonego i autoryzacja

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

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 poświadczeń usługi Azure Active Directory (Azure AD). Sygnatura dostępu współdzielonego delegowania użytkownika jest podpisana przy użyciu klucza delegowania użytkownika.

Aby uzyskać klucz, a następnie utworzyć sygnaturę dostępu współdzielonego, należy przypisać rolę platformy Azure, która zawiera Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey akcję, Azure AD podmiot zabezpieczeń. 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

Sygnatura dostępu współdzielonego usługi 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 SYGNATURy dostępu współdzielonego, to żądanie jest autoryzowane na podstawie sposobu podpisywania 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 do klienta, który ma sygnaturę dostępu współdzielonego.

Poniższa tabela zawiera podsumowanie sposobu autoryzacji poszczególnych typów tokenów 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 korzystanie z sygnatury dostępu współdzielonego delegowania użytkownika, jeśli jest to możliwe w celu zapewnienia najwyższej jakości zabezpieczeń.

Token SAS

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

Aplikacje klienckie udostępniają identyfikator URI sygnatury dostępu współdzielonego do usługi Azure Storage w ramach żądania. Następnie usługa sprawdza parametry sygnatury dostępu współdzielonego i podpis, aby sprawdzić, czy jest ona prawidłowa. Jeśli usługa sprawdza, czy podpis jest prawidłowy, żądanie jest autoryzowane. W przeciwnym razie żądanie zostanie odrzucone z kodem błędu 403 (Zabronione).

Oto przykład identyfikatora URI sygnatury dostępu współdzielonego usługi z identyfikatorem URI zasobu i tokenem SYGNATURy dostępu współdzielonego. Ponieważ token SYGNATURy dostępu współdzielonego składa się z ciągu zapytania identyfikatora URI, identyfikator URI zasobu musi być najpierw poprzedzony znakiem zapytania, a następnie przez token SYGNATURy dostępu współdzielonego:

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

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

Użyj sygnatury dostępu współdzielonego, aby zapewnić bezpieczny dostęp do zasobów na koncie magazynu wszystkim klientom, którzy w inny sposób nie mają uprawnień do tych zasobów.

Typowy 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 frontonu umożliwia walidację reguł biznesowych. Jednak w przypadku dużych ilości danych lub transakcji o dużej ilości danych 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 frontonu

  2. Uproszczona usługa uwierzytelnia klienta zgodnie z potrzebami, a następnie generuje sygnaturę dostępu współdzielonego. Gdy aplikacja kliencka otrzyma sygnaturę dostępu współdzielonego, będzie mogła bezpośrednio uzyskać dostęp do zasobów konta magazynu. Uprawnienia dostępu są definiowane przez sygnaturę dostępu współdzielonego i dla interwału dozwolonego 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 sygnatury dostępu współdzielonego

Wiele rzeczywistych usług może używać hybrydowego tych dwóch podejść. Na przykład niektóre dane mogą być przetwarzane i weryfikowane za pośrednictwem serwera proxy frontonu. 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 ramach operacji kopiowania w niektórych scenariuszach:

  • Podczas kopiowania obiektu blob do innego obiektu blob znajdującego się na innym koncie magazynu.

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

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

    Opcjonalnie można również 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.

    Należy użyć sygnatury dostępu współdzielonego, nawet jeśli obiekty źródłowe i docelowe znajdują się na tym samym koncie magazynu.

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

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

  • W przypadku wycieku sygnatury dostępu współdzielonego można go użyć przez każdego, kto go uzyska, co może potencjalnie naruszyć bezpieczeństwo konta magazynu.

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

Następujące zalecenia dotyczące używania sygnatur dostępu współdzielonego mogą pomóc w ograniczeniu tego ryzyka:

  • Zawsze używaj protokołu HTTPS do tworzenia lub dystrybuowania sygnatury dostępu współdzielonego. Jeśli sygnatura dostępu współdzielonego jest przekazywana przez protokół HTTP i przechwycona, osoba atakująca wykonująca atak typu man-in-the-middle może odczytać sygnaturę dostępu współdzielonego. Następnie mogą używać tej sygnatury dostępu współdzielonego tak samo jak zamierzony użytkownik. Może to potencjalnie naruszyć bezpieczeństwo poufnych danych lub umożliwić 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 Azure AD poświadczeń, dzięki czemu nie trzeba przechowywać klucza konta przy użyciu kodu.

  • Należy mieć plan odwołania dla sygnatury dostępu współdzielonego. Upewnij się, że masz gotowość do reagowania w przypadku naruszenia zabezpieczeń sygnatury dostępu współdzielonego.

  • Skonfiguruj zasady wygasania sygnatury dostępu współdzielonego dla konta magazynu. Zasady wygasania sygnatury dostępu współdzielonego określają zalecany interwał, w którym sygnatura dostępu współdzielonego jest prawidłowa. Zasady wygasania sygnatur dostępu współdzielonego mają zastosowanie do sygnatury dostępu współdzielonego usługi lub sygnatury dostępu współdzielonego konta. Gdy użytkownik generuje sygnaturę dostępu współdzielonego usługi lub sygnaturę dostępu współdzielonego konta z interwałem ważności większym niż zalecany interwał, zostanie wyświetlone ostrzeżenie. Jeśli rejestrowanie usługi Azure Storage za pomocą usługi Azure Monitor jest włączone, wpis jest zapisywany w dziennikach usługi Azure Storage. Aby dowiedzieć się więcej, zobacz Tworzenie zasad wygasania dla sygnatur dostępu współdzielonego.

  • Utwórz przechowywane zasady dostępu dla sygnatury dostępu współdzielonego usługi. Zapisane zasady dostępu umożliwiają odwoływanie uprawnień dla sygnatury dostępu współdzielonego usługi bez konieczności ponownego generowania kluczy konta magazynu. Ustaw wygaśnięcie na te bardzo daleko w przyszłości (lub nieskończone) i upewnij się, że jest regularnie aktualizowany, aby przenieść go dalej w przyszłość. Istnieje limit pięciu przechowywanych zasad dostępu na kontener.

  • Użyj niemalterminowych czasów wygaśnięcia dla sygnatury dostępu współdzielonego usługi ad hoc sas lub sygnatury dostępu współdzielonego konta. W ten sposób, nawet jeśli naruszenie sygnatury dostępu współdzielonego jest prawidłowe tylko przez krótki czas. Ta praktyka jest szczególnie ważna, jeśli nie można odwoływać się do przechowywanych zasad dostępu. Niemalterminowe czasy wygaśnięcia ograniczają również ilość danych, które można zapisać w obiekcie blob, ograniczając czas dostępny do przekazania do niego.

  • W razie potrzeby klienci mogą automatycznie odnawiać sygnaturę dostępu współdzielonego. Klienci powinni odnowić sygnaturę dostępu współdzielonego na długo przed wygaśnięciem, aby umożliwić ponowne próby, jeśli usługa dostarczająca sygnaturę dostępu współdzielonego jest niedostępna. Może to być niepotrzebne w niektórych przypadkach. Na przykład można zastosować sygnaturę dostępu współdzielonego dla niewielkiej liczby natychmiastowych, krótkotrwałych operacji. Oczekuje się, że te operacje zostaną ukończone w okresie wygaśnięcia. W związku z tym nie oczekujesz, że sygnatura dostępu współdzielonego zostanie odnowiona. Jeśli jednak masz klienta, który rutynowo wysyła żądania za pośrednictwem sygnatury dostępu współdzielonego, możliwość wygaśnięcia wchodzi w grę.

  • Zachowaj ostrożność przy użyciu czasu rozpoczęcia sygnatury dostępu współdzielonego. Jeśli ustawisz czas rozpoczęcia sygnatury dostępu współdzielonego na bieżący czas, błędy mogą wystąpić sporadycznie przez pierwsze kilka minut. Jest to spowodowane tym, że różne maszyny mają nieco inne bieżące czasy (nazywane niesymetrycznością zegara). Ogólnie rzecz biorąc, ustaw godzinę rozpoczęcia na co najmniej 15 minut w przeszłości. Lub, nie ustawiaj go w ogóle, co sprawi, że będzie ono prawidłowe natychmiast we wszystkich przypadkach. To samo zwykle dotyczy czasu wygaśnięcia, jak również pamiętać, że można obserwować maksymalnie 15 minut niesymetryczności zegara w dowolnym kierunku w dowolnym żądaniu. W przypadku klientów korzystających z wersji REST wcześniejszej niż 2012-02-12 maksymalny czas trwania sygnatury dostępu współdzielonego, który nie odwołuje się do przechowywanych zasad dostępu wynosi 1 godzinę. Wszystkie zasady, które określają dłuższy okres niż 1 godzinę, zakończy się niepowodzeniem.

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

  • Aby uzyskać dostęp do zasobu, należy być specyficzny dla zasobu. Najlepszym rozwiązaniem w zakresie zabezpieczeń jest zapewnienie użytkownikowi minimalnych wymaganych uprawnień. Jeśli użytkownik potrzebuje tylko dostępu do odczytu do pojedynczej jednostki, przyznaj im dostęp do odczytu do tej pojedynczej jednostki, a nie do odczytu/zapisu/usuwania do wszystkich jednostek. Pomaga to również zmniejszyć szkody w przypadku naruszenia zabezpieczeń sygnatury dostępu współdzielonego, ponieważ sygnatura dostępu współdzielonego ma mniejsze uprawnienia w rękach osoby atakującej.

    Nie ma bezpośredniego sposobu identyfikowania klientów, którzy uzyskiwali dostęp do zasobu. W celu śledzenia dostępu można jednak użyć unikatowych pól w sygnaturze dostępu współdzielonego, podpisanym adresie IP (sip), podpisanym początku (st) i podpisanym wygaśnięciu (se). Na przykład możesz wygenerować token SAS z unikatowym czasem wygaśnięcia, który następnie można skorelować z klientem, do którego został wystawiony.

  • Dowiedz się, że twoje konto będzie rozliczane za dowolne 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 zdecydować się na przekazanie obiektu blob o pojemności 200 GB. Jeśli również udzielono im dostępu do odczytu, mogą zdecydować się na pobranie go 10 razy, ponoszenia 2 TB kosztów ruchu przychodzącego. Ponownie podaj ograniczone uprawnienia, aby pomóc w ograniczeniu potencjalnych działań złośliwych użytkowników. Użyj krótkotrwałej sygnatury dostępu współdzielonego, aby zmniejszyć to zagrożenie (ale należy pamiętać o niesymetryczności zegara w czasie zakończenia).

  • Weryfikowanie danych zapisanych przy użyciu sygnatury dostępu współdzielonego. Gdy aplikacja kliencka zapisuje dane na koncie magazynu, pamiętaj, że mogą występować problemy z danymi. Jeśli planujesz zweryfikować dane, przeprowadź tę walidację po zapisaniu danych i przed ich użyciem przez aplikację. Ta praktyka chroni również przed uszkodzeniem lub złośliwymi danymi zapisywanymi na twoim koncie przez użytkownika, który prawidłowo nabył sygnaturę dostępu współdzielonego lub przez użytkownika wykorzystującego wyciekły sygnaturę dostępu współdzielonego.

  • Dowiedz się, kiedy nie używać sygnatury dostępu współdzielonego. Czasami ryzyko związane z określoną operacją na koncie magazynu przewyższa korzyści wynikające z używania sygnatury dostępu współdzielonego. W przypadku takich operacji utwórz usługę warstwy środkowej, która zapisuje na koncie magazynu po przeprowadzeniu weryfikacji, uwierzytelniania i inspekcji reguł biznesowych. Ponadto czasami łatwiej jest zarządzać dostępem na inne sposoby. Jeśli na przykład chcesz, aby wszystkie obiekty blob w kontenerze mogły być publicznie czytelne, możesz ustawić kontener jako publiczny, zamiast dostarczać sygnaturę dostępu współdzielonego każdemu klientowi w celu uzyskania dostępu.

  • Monitorowanie aplikacji za pomocą usługi Azure Monitor i dzienników usługi Azure Storage. Błędy autoryzacji mogą wystąpić z powodu awarii w usłudze dostawcy sygnatury dostępu współdzielonego. Mogą one również wystąpić z nieumyślnego usunięcia przechowywanych zasad dostępu. Możesz użyć rejestrowania usługi Azure Monitor i analizy magazynu, aby zaobserwować wzrost liczby błędów autoryzacji tego typu. Aby uzyskać więcej informacji, zobacz Metryki usługi Azure Storage w usługach Azure Monitor i Azure analityka magazynu rejestrowania.

  • Skonfiguruj zasady wygasania sygnatury dostępu współdzielonego dla konta magazynu. Najlepsze rozwiązania zalecają ograniczenie interwału sygnatury dostępu współdzielonego w przypadku naruszenia zabezpieczeń. Ustawiając zasady wygasania sygnatury dostępu współdzielonego dla kont magazynu, możesz podać zalecany górny limit wygaśnięcia, gdy użytkownik tworzy sygnaturę dostępu współdzielonego usługi lub sygnaturę dostępu współdzielonego konta. Aby uzyskać więcej informacji, zobacz Tworzenie zasad wygasania dla sygnatur dostępu współdzielonego.

Uwaga

Usługa Storage nie śledzi liczby sygnatur dostępu współdzielonego, 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ółdzielonego wygenerowanych dla konta magazynu, musisz ręcznie śledzić liczbę.

Wprowadzenie do sygnatury dostępu współdzielonego

Aby rozpocząć pracę z sygnaturami dostępu współdzielonego, zobacz następujące artykuły dotyczące 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