Udostępnij za pośrednictwem

Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage za pomocą sygnatur dostępu współdzielonego (SAS)

  • Artykuł

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. Na 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

Ważne

W przypadku scenariuszy, w których są używane sygnatury dostępu współdzielonego, firma Microsoft zaleca używanie sygnatury dostępu współdzielonego delegowania użytkowników. Sygnatura dostępu współdzielonego delegowania użytkownika jest zabezpieczona przy użyciu poświadczeń firmy Microsoft zamiast klucza konta, co zapewnia lepsze zabezpieczenia. Aby uzyskać więcej informacji na temat autoryzacji dostępu do danych, zobacz Autoryzowanie dostępu do danych w usłudze Azure Storage.

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 Microsoft Entra, 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 użytkownika lub usługi 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).

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 jednego sygnatur 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 dla 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 token dołączany do identyfikatora URI zasobu usługi Azure Storage. Token zawierający specjalny zestaw parametrów zapytania, który wskazuje, jak zasoby mogą być dostępne przez klienta. Jeden z parametrów zapytania, podpis, jest skonstruowany z 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 z uprawnieniami do generowania tokenu SAS przy użyciu klucza konta lub 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ółużytkowanego.

Sygnatura sygnatury dostępu współdzielonego i autoryzacja

Token SYGNATURy dostępu współdzielonego 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 sygnatury dostępu współdzielonego można podpisać przy użyciu klucza delegowania użytkownika, który został utworzony przy użyciu poświadczeń firmy Microsoft Entra. 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, podmiot zabezpieczeń firmy Microsoft musi mieć przypisaną rolę platformy Azure obejmującą 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

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 SAS, to żądanie jest autoryzowane na podstawie sposobu podpisywania 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 posiada sygnaturę dostępu współdzielonego.

Poniższa tabela zawiera podsumowanie sposobu 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) Microsoft Entra ID
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 w celu uzyskania lepszych zabezpieczeń.

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. 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, znakiem ogranicznika ('?') i tokenem SYGNATURy dostępu współdzielonego.

Diagram przedstawiający składniki identyfikatora URI zasobu z tokenem SAS.

Uwaga

Znak ogranicznika ('?') dla ciągu zapytania nie jest częścią tokenu SAS. Jeśli wygenerujesz token SAS z portalu, programu PowerShell, interfejsu wiersza polecenia platformy Azure lub jednego z zestawów SDK usługi Azure Storage, może być konieczne dołączenie znaku ogranicznika do adresu URL zasobu.

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 każdemu klientowi, który w inny sposób nie ma 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 tworzenie 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 odbierze sygnaturę dostępu współdzielonego, będzie mogła uzyskiwać bezpośredni 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 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żesz użyć sygnatury dostępu współdzielonego, aby autoryzować również 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 podana dla 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.

Poniższe zalecenia dotyczące używania sygnatur dostępu współdzielonego mogą pomóc w ograniczeniu 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 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 spowodować 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 Microsoft Entra, dzięki czemu nie trzeba przechowywać klucza konta przy użyciu kodu.

  • Mają 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 dotyczą 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 zostanie zapisany 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 on regularnie aktualizowany, aby przenieść go dalej do przyszłości. Istnieje limit pięciu przechowywanych zasad dostępu na kontener.

  • Użyj czasu wygaśnięcia w czasie zbliżonym do czasu 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 w przypadku naruszenia zabezpieczeń sygnatury dostępu współdzielonego jest ona ważna 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 zapisywać w obiekcie blob, ograniczając czas dostępny do przekazania do niego.

  • W razie potrzeby klienci mają 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ć czas ponawiania prób, 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. Te operacje powinny zostać 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 jest 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 czas 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 zaobserwować do 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 data/godzina sygnatury dostępu współdzielonego. W przypadku niektórych narzędzi (takich jak Narzędzie AzCopy) wartości daty/godziny muszą być sformatowane jako "+%Y-%m-%dT%H:%M:%SZ". Ten format obejmuje w szczególności sekundy.

  • Przyznaj najmniejsze możliwe uprawnienia sygnaturze dostępu współdzielonego. Najlepszym rozwiązaniem w zakresie zabezpieczeń jest zapewnienie użytkownikowi minimalnych wymaganych uprawnień do najmniejszych możliwych zasobów. Jeśli to możliwe, użyj sygnatury dostępu współdzielonego tylko do odczytu. Jeśli użytkownik potrzebuje tylko dostępu do odczytu do pojedynczego obiektu, przyznaj im dostęp do odczytu do tego pojedynczego obiektu, a nie do odczytu/zapisu/usuwania do wszystkich obiektów. Pomaga to również zmniejszyć szkody w przypadku naruszenia zabezpieczeń sygnatury dostępu współdzielonego, ponieważ sygnatura dostępu współdzielonego ma mniejszą moc w rękach osoby atakującej.

    Nie ma bezpośredniego sposobu identyfikowania klientów, którzy uzyskiwali dostęp do zasobu. Można jednak użyć unikatowych pól w sygnaturze dostępu współdzielonego, podpisanego adresu IP (sip), podpisanego początku (st) i podpisanych pól wygaśnięcia (se), aby śledzić dostęp. Można na przykład 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ż nadano im dostęp do odczytu, mogą zdecydować się na pobranie go 10 razy, poniesienie 2 TB kosztów ruchu wychodzącego za Ciebie. 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, należy pamiętać, że mogą występować problemy z danymi. Jeśli planujesz zweryfikować dane, wykonaj tę walidację po zapisaniu danych i przed ich użyciem przez aplikację. Ta praktyka chroni również przed złośliwymi lub uszkodzonymi danymi zapisanymi na Twoim koncie przez użytkownika, który prawidłowo nabył sygnaturę dostępu współdzielonego lub przez użytkownika wykorzystującego wyciek sygnatury 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 dla każdego klienta w celu uzyskania dostępu.

  • Monitorowanie aplikacji przy użyciu dzienników usług Azure Monitor i 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 niezamierzonego 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 zaleca ograniczenie interwału sygnatury dostępu współdzielonego w przypadku naruszenia zabezpieczeń. Ustawiając zasady wygasania sygnatur dostępu współdzielonego dla kont magazynu, możesz podać zalecany górny limit wygaśnięcia, gdy użytkownik utworzy 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, i żaden interfejs API nie może podać tych szczegółów. Jeśli musisz znać liczbę sygnatur dostępu współdzielonego, które zostały wygenerowane 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 dla każdego typu sygnatury 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

Następne kroki