Autoryzowanie dostępu do obiektów blob przy użyciu Microsoft Entra ID

Usługa Azure Storage obsługuje używanie Microsoft Entra ID do autoryzacji żądań do danych blob. Za pomocą Microsoft Entra ID można użyć Azure role-based access control (Azure RBAC), aby przyznać uprawnienia jednostce zabezpieczeń, którą może być użytkownik, grupa lub jednostka usługi aplikacji. Identyfikator Entra firmy Microsoft uwierzytelnia podmiot zabezpieczeń i zwraca token OAuth 2.0. Użyj tokenu, aby autoryzować żądanie względem usługi Blob Service.

Możesz użyć autoryzacji Microsoft Entra ID ze wszystkimi kontami ogólnego przeznaczenia i usługi Blob Storage we wszystkich regionach publicznych i chmurach krajowych. Tylko konta magazynu utworzone przy użyciu modelu wdrażania Azure Resource Manager obsługują autoryzację Microsoft Entra.

Ważne

Aby zapewnić optymalne zabezpieczenia, firma Microsoft zaleca używanie Microsoft Entra ID z tożsamościami zarządzanymi do autoryzowania dostępu do danych w obiektach blob, kolejkach i tabelach, kiedy to możliwe. Autoryzacja przy użyciu identyfikatora Entra firmy Microsoft i tożsamości zarządzanych zapewnia doskonałe zabezpieczenia i łatwość użycia w przypadku autoryzacji klucza współdzielonego. Aby dowiedzieć się więcej o tożsamościach zarządzanych, zobacz Co to są tożsamości zarządzane dla zasobów platformy Azure. Aby zapoznać się z przykładem włączania i używania tożsamości zarządzanej dla aplikacji platformy .NET, zobacz Authenticating Azure-hosted apps to Azure resources with .NET (Uwierzytelnianie aplikacji hostowanych na platformie Azure w zasobach platformy Azure przy użyciu platformy .NET).

W przypadku zasobów hostowanych poza platformą Azure, takich jak aplikacje lokalne, można używać tożsamości zarządzanych za pośrednictwem usługi Azure Arc. Na przykład aplikacje uruchomione na serwerach z obsługą usługi Azure Arc mogą używać tożsamości zarządzanych do łączenia się z usługami platformy Azure. Aby dowiedzieć się więcej, zobacz Uwierzytelnianie w odniesieniu do zasobów platformy Azure 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 z delegowaniem użytkownika. Sygnatura dostępu współdzielonego delegowania użytkownika jest zabezpieczona poświadczeniami Microsoft Entra, a nie kluczem konta. Aby dowiedzieć się więcej o sygnaturach dostępu współdzielonego, zobacz Udzielanie ograniczonego dostępu do danych za pomocą sygnatur dostępu współdzielonego. Aby zapoznać się z przykładem tworzenia i używania sygnatury dostępu współdzielonego delegowania użytkownika za pomocą platformy .NET, zobacz Tworzenie sygnatury dostępu współdzielonego delegowania użytkownika dla obiektu blob za pomocą platformy .NET.

Omówienie Microsoft Entra ID dla blobów

Gdy podmiot zabezpieczeń (użytkownik, grupa lub aplikacja) próbuje uzyskać dostęp do zasobu obiektu blob, żądanie musi być autoryzowane, chyba że jest to obiekt blob dostępny na potrzeby dostępu anonimowego. Przy użyciu Microsoft Entra ID dostęp do zasobu jest procesem dwuetapowym:

  1. Najpierw tożsamość podmiotu zabezpieczeń jest uwierzytelniana i zwracany jest token OAuth 2.0.

    Krok uwierzytelniania wymaga, aby aplikacja zażądała tokenu dostępu OAuth 2.0 w czasie wykonywania. Jeśli aplikacja działa z poziomu jednostki platformy Azure, takiej jak maszyna wirtualna platformy Azure, zestaw skalowania maszyn wirtualnych lub aplikacja usługi Azure Functions, może używać tożsamości zarządzanej do uzyskiwania dostępu do danych obiektów blob.

  2. Następnie token jest przekazywany jako część żądania do usługi Blob Service, a usługa używa go do autoryzowania dostępu do określonego zasobu.

    Krok autoryzacji wymaga przypisania co najmniej jednej roli RBAC platformy Azure do podmiotu zabezpieczeń wysyłającego żądanie. Aby uzyskać więcej informacji, zobacz Przypisywanie ról platformy Azure na potrzeby praw dostępu.

Użyj konta Microsoft Entra z portalem, programem PowerShell lub Azure CLI

Aby dowiedzieć się, jak uzyskać dostęp do danych w portalu Azure przy użyciu konta Microsoft Entra, zapoznaj się z dostępem do danych w portalu Azure. Aby dowiedzieć się, jak za pomocą konta Microsoft Entra wywołać polecenia Azure PowerShell lub Azure CLI, zajrzyj do Dostęp do danych z programu PowerShell lub Azure CLI.

Używanie identyfikatora Entra firmy Microsoft do autoryzowania dostępu w kodzie aplikacji

Aby autoryzować dostęp do Azure Storage przy użyciu Microsoft Entra ID, użyj jednej z następujących bibliotek klienckich do uzyskania tokenu OAuth 2.0:

  • Biblioteka klienta tożsamości platformy Azure jest zalecana w przypadku większości scenariuszy programowania.
  • Microsoft Authentication Library (MSAL) może być odpowiedni dla niektórych zaawansowanych scenariuszy.

Biblioteka klienta tożsamości platformy Azure

Biblioteka klienta Azure Identity upraszcza proces uzyskiwania tokenu dostępu OAuth 2.0 do autoryzacji przy użyciu Microsoft Entra ID za pośrednictwem Azure SDK. Najnowsze wersje bibliotek klienckich Azure Storage dla .NET, Java, Python, JavaScript i Go integrują się z bibliotekami Azure Identity dla każdego z tych języków, aby zapewnić prosty i bezpieczny sposób uzyskiwania tokenu dostępu do autoryzacji żądań Azure Storage.

Zaletą biblioteki klienta tożsamości platformy Azure jest możliwość użycia tego samego kodu w celu uzyskania tokenu dostępu niezależnie od tego, czy aplikacja działa w środowisku deweloperów, czy na platformie Azure. Biblioteka klienta usługi Azure Identity zwraca token dostępu dla podmiotu zabezpieczeń. Gdy kod jest uruchomiony w Azure, principal zabezpieczeń może być tożsamością zarządzaną dla zasobów Azure, podmiotem usługi, użytkownikiem lub grupą. W środowisku projektowym biblioteka klienta udostępnia token dostępu dla użytkownika lub jednostki usługi na potrzeby testowania.

Token dostępu zwracany przez bibliotekę klienta Azure Identity jest zawarty w poświadczeniu tokenu. Następnie możesz użyć poświadczenia tokenu, aby uzyskać obiekt klienta usługi do wykonywania autoryzowanych operacji w usłudze Azure Storage. Prostym sposobem uzyskania tokenu dostępu i poświadczeń tokenu jest użycie DefaultAzureCredential klasy udostępnianej przez bibliotekę klienta Azure Identity. DefaultAzureCredential próbuje uzyskać poświadczenie tokenu, sekwencyjnie wypróbowując różne typy poświadczeń. DefaultAzureCredential działa zarówno w środowisku deweloperskim, jak i na platformie Azure.

Poniższa tabela zawiera dodatkowe informacje dotyczące autoryzowania dostępu do danych w różnych scenariuszach:

Język .NET Java JavaScript Python Go
Omówienie uwierzytelniania za pomocą identyfikatora Entra firmy Microsoft Jak uwierzytelniać aplikacje platformy .NET za pomocą usług platformy Azure Uwierzytelnianie platformy Azure przy użyciu języka Java i tożsamości platformy Azure Uwierzytelnianie aplikacji JavaScript na platformie Azure przy użyciu zestawu Azure SDK Uwierzytelnianie aplikacji języka Python na platformie Azure przy użyciu zestawu Azure SDK
Uwierzytelnianie przy użyciu jednostek usługi dla deweloperów Uwierzytelnianie aplikacji .NET do usług Azure podczas lokalnego rozwoju przy użyciu pryncypałów usługi Uwierzytelnianie platformy Azure przy użyciu jednostki usługi Uwierzytelnianie aplikacji JS w usługach platformy Azure przy użyciu tożsamości usługi Uwierzytelnianie aplikacji Python do usług Azure podczas lokalnego tworzenia przy użyciu zasad serwisowych Uwierzytelnianie w Azure SDK dla Go przy użyciu jednostki usługi
Uwierzytelnianie przy użyciu kont deweloperów lub użytkowników Uwierzytelnianie aplikacji platformy .NET w usługach platformy Azure podczas programowania lokalnego przy użyciu kont deweloperów Uwierzytelnianie platformy Azure przy użyciu poświadczeń użytkownika Uwierzytelnianie aplikacji JS w usługach platformy Azure przy użyciu kont deweloperskich Uwierzytelnianie aplikacji języka Python w usługach platformy Azure podczas programowania lokalnego przy użyciu kont deweloperów Uwierzytelnianie platformy Azure za pomocą zestawu Azure SDK dla języka Go
Uwierzytelnianie z aplikacji hostowanych na platformie Azure Uwierzytelnianie aplikacji hostowanych na platformie Azure do zasobów platformy Azure przy użyciu zestawu Azure SDK dla platformy .NET Uwierzytelnianie aplikacji Java hostowanych na platformie Azure Uwierzytelnianie aplikacji JavaScript hostowanych na platformie Azure do zasobów platformy Azure przy użyciu zestawu Azure SDK dla języka JavaScript Uwierzytelnianie aplikacji hostowanych na platformie Azure do zasobów platformy Azure przy użyciu zestawu Azure SDK dla języka Python Uwierzytelnianie za pomocą zestawu Azure SDK dla języka Go przy użyciu tożsamości zarządzanej
Uwierzytelnianie z aplikacji lokalnych Uwierzytelnianie w zasobach platformy Azure z aplikacji platformy .NET hostowanych lokalnie Uwierzytelnianie lokalnych aplikacji JavaScript w zasobach platformy Azure Uwierzytelnianie w zasobach platformy Azure z aplikacji języka Python hostowanych lokalnie
Omówienie biblioteki tożsamości klienta Biblioteka klienta tożsamości platformy Azure dla platformy .NET Biblioteka klienta tożsamości platformy Azure dla języka Java Biblioteka klienta tożsamości platformy Azure dla języka JavaScript Biblioteka klienta tożsamości platformy Azure dla języka Python Biblioteka klienta tożsamości platformy Azure dla języka Go

Biblioteka uwierzytelniania firmy Microsoft (MSAL)

Chociaż Microsoft zaleca korzystanie z biblioteki klienta Azure Identity, jeśli to możliwe, biblioteka MSAL może być odpowiednia do użycia w niektórych zaawansowanych scenariuszach. Aby uzyskać więcej informacji, zobacz Dowiedz się o MSAL.

Jeśli używasz MSAL do uzyskania tokenu OAuth na potrzeby dostępu do usługi Azure Storage, musisz podać identyfikator zasobu Microsoft Entra. Identyfikator zasobu Entra firmy Microsoft wskazuje odbiorców, dla których można użyć tokenu wystawionego do zapewnienia dostępu do zasobu platformy Azure. W przypadku Azure Storage identyfikator zasobu może być specyficzny dla pojedynczego konta magazynu lub może mieć zastosowanie do dowolnego konta magazynu.

Gdy podasz identyfikator zasobu, który jest specyficzny dla jednego konta magazynowego i usługi, identyfikator ten jest używany do uzyskania tokenu potrzebnego do autoryzacji żądań wyłącznie do wskazanego konta i usługi. W poniższej tabeli wymieniono wartość używaną dla identyfikatora zasobu na podstawie chmury, z którą pracujesz. Zastąp wartość <account-name> nazwą konta magazynowego.

Chmura Identyfikator zasobu
Globalna platforma Azure https://<account-name>.blob.core.windows.net
Azure Government https://<account-name>.blob.core.usgovcloudapi.net
Azure (Chiny) — 21Vianet https://<account-name>.blob.core.chinacloudapi.cn

Możesz również podać identyfikator zasobu, który ma zastosowanie do dowolnego konta przechowywania, jak pokazano w poniższej tabeli. Ten identyfikator zasobu jest taki sam dla wszystkich chmur publicznych i suwerennych i służy do uzyskiwania tokenu do autoryzowania żądań do dowolnego konta magazynu.

Chmura Identyfikator zasobu
Globalna platforma Azure
Azure Government
Azure (Chiny) — 21Vianet
https://storage.azure.com/

Przypisywanie ról platformy Azure na potrzeby praw dostępu

Microsoft Entra autoryzuje prawa dostępu do zabezpieczonych zasobów za pośrednictwem Azure RBAC. Usługa Azure Storage zdefiniowała zestaw wbudowanych ról RBAC obejmujących typowe zestawy uprawnień używanych do uzyskiwania dostępu do danych blob. Można również zdefiniować role niestandardowe na potrzeby dostępu do danych blob. Aby dowiedzieć się więcej na temat przypisywania ról platformy Azure na potrzeby dostępu do obiektów blob, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych obiektów blob.

Podmiot zabezpieczeń firmy Microsoft Entra może być użytkownikiem, grupą, jednostką usługi aplikacji lub tożsamością zarządzaną dla zasobów platformy Azure. Role RBAC przypisane do podmiotu zabezpieczeń określają uprawnienia, które podmiot zabezpieczeń ma dla określonego zasobu.

Aby dowiedzieć się, jak przypisywać role Azure na potrzeby dostępu do obiektów blob, zobacz Przydziel rolę Azure w celu uzyskania dostępu do danych obiektów blob.

W niektórych przypadkach może być konieczne włączenie szczegółowego dostępu do zasobów obiektów blob lub uproszczenie uprawnień, gdy mamy do czynienia z dużą liczbą przypisań ról dla jednego zasobu magazynowego. Użyj Azure kontroli dostępu opartej na atrybutach (Azure ABAC), aby skonfigurować warunki przypisania ról. Możesz użyć warunków z rolą użytkownika lub wybrać role wbudowane. Aby uzyskać więcej informacji na temat konfigurowania warunków dla zasobów usługi Azure Storage przy użyciu funkcji ABAC, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu warunków przypisania ról platformy Azure (wersja zapoznawcza). Aby uzyskać szczegółowe informacje na temat obsługiwanych warunków operacji na danych blob, zobacz Akcje i atrybuty warunków przypisywania ról platformy Azure w usłudze Azure Storage (wersja zapoznawcza).

Uwaga

Podczas tworzenia konta Azure Storage nie masz automatycznie przypisanych uprawnień dostępu do danych za pośrednictwem Microsoft Entra ID. Aby uzyskać dostęp do usługi Blob Storage, musisz jawnie przypisać sobie rolę platformy Azure. Można ją przypisać na poziomie subskrypcji, grupy zasobów, konta magazynu lub kontenera.

Zakres zasobu

Przed przypisaniem roli RBAC platformy Azure do podmiotu zabezpieczeń określ zakres dostępu, który powinien mieć podmiot zabezpieczeń. Zawsze udzielaj tylko najwęższego możliwego zakresu. Role RBAC Azure zdefiniowane w szerszym zakresie są dziedziczone przez zasoby pod nimi.

Dostęp do zasobów obiektów blob platformy Azure można ograniczyć na następujących poziomach, począwszy od najwęższego zakresu:

  • Pojedynczy kontener. W tym zakresie przypisanie roli ma zastosowanie do wszystkich obiektów blob w kontenerze oraz do właściwości i metadanych kontenera.
  • konto magazynowe W tym zakresie przypisanie roli ma zastosowanie do wszystkich kontenerów i ich blobów.
  • grupa zasobów. W tym zakresie przypisanie roli ma zastosowanie do wszystkich kontenerów we wszystkich kontach magazynu w grupie zasobów.
  • Subskrypcja. W tym zakresie przypisanie roli ma zastosowanie do wszystkich kontenerów we wszystkich kontach we wszystkich grupach zasobów w subskrypcji.
  • Grupa zarządzania. W tym zakresie przypisanie roli ma zastosowanie do wszystkich kontenerów we wszystkich kontach przechowywania we wszystkich grupach zasobów we wszystkich subskrypcjach w grupie zarządczej.

Aby uzyskać więcej informacji na temat zakresu przypisań ról RBAC platformy Azure, zobacz Zrozumienie zakresu dla Azure RBAC.

Wbudowane role platformy Azure dla obiektów blob

Azure RBAC udostępnia kilka wbudowanych ról umożliwiających autoryzowanie dostępu do danych blob przy użyciu Microsoft Entra ID i protokołu OAuth. Oto kilka przykładów ról, które zapewniają uprawnienia do zasobów danych w usłudze Azure Storage:

Aby dowiedzieć się, jak przypisać wbudowaną rolę platformy Azure do podmiotu zabezpieczeń, zobacz Przypisywanie roli platformy Azure w celu dostępu do danych obiektu blob. Aby dowiedzieć się, jak wyświetlić listę ról RBAC platformy Azure i ich uprawnień, zobacz Wyświetlanie listy definicji ról platformy Azure.

Aby uzyskać więcej informacji na temat sposobu definiowania ról wbudowanych dla usługi Azure Storage, zobacz Omówienie definicji ról. Aby uzyskać informacje na temat tworzenia ról niestandardowych platformy Azure, zobacz Role niestandardowe platformy Azure.

Tylko role jawnie zdefiniowane dla dostępu do danych zezwalają jednostce zabezpieczeń na dostęp do danych blob. Wbudowane role, takie jak Właściciel, Współautor, i Współautor konta magazynu, umożliwiają podmiotowi zabezpieczeń zarządzanie kontem magazynu, ale nie zapewniają dostępu do danych obiektów blob w ramach tego konta za pośrednictwem tożsamości Microsoft Entra. Jeśli jednak rola zawiera Microsoft.Storage/storageAccounts/listKeys/action, następnie użytkownik, któremu przypisano tę rolę, może uzyskać dostęp do danych w koncie magazynowania za pomocą autoryzacji klucza współdzielonego poprzez użycie kluczy dostępu do konta. Aby uzyskać więcej informacji, zobacz Wybieranie sposobu autoryzowania dostępu do danych obiektów blob w witrynie Azure Portal.

Aby uzyskać szczegółowe informacje na temat wbudowanych ról platformy Azure dotyczących Azure Storage oraz aspektów usług danych i zarządzania, zobacz sekcję Storage w Role wbudowane platformy Azure dla Azure RBAC. Ponadto aby uzyskać informacje o różnych typach ról, które zapewniają uprawnienia na platformie Azure, zobacz Role platformy Azure, Role firmy Microsoft Entra i klasyczne role administratora subskrypcji.

Ważne

propagowanie przypisań ról Azure może potrwać do 30 minut.

Uprawnienia dostępu do operacji danych

Aby uzyskać szczegółowe informacje na temat uprawnień wymaganych do wywoływania określonych operacji usługi Blob Service, zobacz Uprawnienia do wywoływania operacji danych.

Opóźnienia propagacji przypisania ról dla dostępu do danych w obiektach blob

Po przypisaniu ról lub usunięciu przypisań ról może upłynąć do 10 minut, aby zmiany zaczęły obowiązywać. Jeśli przypiszesz role w zakresie poziomu grupy zarządzania, procedura może potrwać znacznie dłużej.

Role wbudowane można przypisywać za pomocą akcji danych w zakresie grupy zarządzania. Jednak w rzadkich scenariuszach może wystąpić znaczne opóźnienie (do 12 godzin), zanim uprawnienia akcji danych będą skuteczne w przypadku niektórych typów zasobów. Uprawnienia są w końcu stosowane. W przypadku wbudowanych ról z akcjami danych dodawanie lub usuwanie przypisań ról w zakresie grupy zarządzania nie jest zalecane w scenariuszach, w których wymagana jest aktywacja lub odwoływanie uprawnień w odpowiednim czasie, na przykład Microsoft Entra Privileged Identity Management (PIM).

Jeśli ustawisz odpowiednie uprawnienia zezwalające na dostęp do danych za pośrednictwem Microsoft Entra ID i nadal nie możesz uzyskać dostępu do danych, na przykład otrzymujesz błąd "AuthorizationPermissionMismatch", upewnij się, że dałeś wystarczająco dużo czasu na propagację zmian uprawnień wprowadzonych w Microsoft Entra ID. Upewnij się również, że nie masz żadnych uprawnień odmowy, które blokują dostęp. Aby uzyskać więcej informacji, zobacz Omówienie przypisań odmowy platformy Azure.

Uzyskiwanie dostępu do danych przy użyciu konta Microsoft Entra

Dostęp do danych obiektów blob można autoryzować za pośrednictwem portalu Azure, programu PowerShell lub Azure CLI przy użyciu konta Microsoft Entra lub przy użyciu kluczy dostępu do konta (autoryzacja klucza współdzielonego).

Uwaga

Autoryzacja z kluczem udostępnionym nie jest zalecana, ponieważ może być mniej bezpieczna. Aby uzyskać optymalne zabezpieczenia, wyłącz autoryzację za pośrednictwem klucza współdzielonego dla konta magazynu, zgodnie z opisem w temacie Zapobieganie autoryzacji klucza współdzielonego dla konta usługi Azure Storage.

Korzystanie z kluczy dostępu i ciągów połączenia powinno być ograniczone do początkowego sprawdzania koncepcji lub prototypów programistycznych, które nie uzyskują dostępu do danych produkcyjnych ani poufnych. W przeciwnym razie klasy uwierzytelniania oparte na tokenach dostępne w zestawie Azure SDK powinny być zawsze preferowane podczas uwierzytelniania w zasobach platformy Azure.

Firma Microsoft zaleca, aby klienci używali identyfikatora Entra firmy Microsoft lub sygnatury dostępu współdzielonego (SAS), aby autoryzować dostęp do danych w usłudze Azure Storage. Aby uzyskać więcej informacji, zobacz Autoryzacja operacji na potrzeby dostępu do danych.

Dostęp do danych z witryny Azure Portal

Portal Azure może korzystać z konta Microsoft Entra lub kluczy dostępu do konta, aby uzyskać dostęp do danych blob w koncie usługi Azure Storage. Schemat autoryzacji używany w portalu Azure zależy od przypisanych ról Azure.

Podczas próby uzyskania dostępu do danych obiektów blob portal Azure najpierw sprawdza, czy przyznano ci rolę w Azure z Microsoft.Storage/storageAccounts/listkeys/action. Jeśli przypisano Ci rolę do tej akcji, portal Azure używa klucza konta do uzyskiwania dostępu do danych blob za pośrednictwem autoryzacji klucza współdzielonego. Jeśli nie masz przypisanej roli z tą akcją, portal Azure próbuje uzyskać dostęp do danych przy użyciu konta Microsoft Entra.

Aby uzyskać dostęp do danych obiektów blob z portalu Azure za pomocą konta Microsoft Entra, musisz mieć uprawnienia do dostępu do danych obiektów blob oraz uprawnienia do nawigowania po zasobach konta przechowywania w portalu Azure. Wbudowane role udostępniane przez usługę Azure Storage zapewniają dostęp do zasobów obiektów blob, ale nie dają uprawnień do zasobów konta przechowywania. Z tego powodu dostęp do portalu wymaga również przypisania roli Azure Resource Manager, takiej jak rola Czytelnik, z zakresem obejmującym poziom konta magazynu lub wyższy. Rola Czytelnik przyznaje najbardziej ograniczone uprawnienia, ale inna rola Azure Resource Manager, która umożliwia dostęp do zasobów zarządzania kontem magazynu, jest również akceptowalna. Aby dowiedzieć się więcej na temat przypisywania użytkownikom uprawnień dostępu do danych w portalu Azure przy użyciu konta Microsoft Entra, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych obiektów blob.

Witryna Azure Portal wskazuje, który schemat autoryzacji jest w użyciu podczas przechodzenia do kontenera. Aby uzyskać więcej informacji na temat dostępu do danych w portalu, zobacz Wybieranie sposobu autoryzowania dostępu do danych blob w portalu Azure.

Dostęp do danych z poziomu programu PowerShell lub interfejsu wiersza polecenia platformy Azure

Azure CLI i PowerShell obsługują logowanie przy użyciu poświadczeń Microsoft Entra. Po zalogowaniu sesja będzie działać na podstawie tych poświadczeń. Aby dowiedzieć się więcej, zobacz jeden z następujących artykułów:

Obsługa funkcji

Może to mieć wpływ na obsługę tej funkcji przez włączenie protokołu Data Lake Storage Gen2, sieciowego systemu plików (NFS) 3.0 lub protokołu SSH File Transfer Protocol (SFTP). Jeśli włączono dowolną z tych funkcji, zobacz Obsługa funkcji usługi Blob Storage na kontach usługi Azure Storage, aby ocenić obsługę tej funkcji.

Autoryzowanie operacji danych obiektów blob przy użyciu identyfikatora Entra firmy Microsoft jest obsługiwane tylko w przypadku interfejsu API REST w wersji 2017-11-09 i nowszych. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji usług Azure Storage.

Następne kroki