Autoryzowanie dostępu do obiektów blob przy użyciu identyfikatora Entra firmy Microsoft
Usługa Azure Storage obsługuje używanie identyfikatora Entra firmy Microsoft do autoryzowania żądań do danych obiektów blob. Za pomocą identyfikatora Entra firmy Microsoft możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień jednostce zabezpieczeń, która może być użytkownikiem, grupą lub jednostką usługi aplikacji. Podmiot zabezpieczeń jest uwierzytelniany przez identyfikator entra firmy Microsoft w celu zwrócenia tokenu OAuth 2.0. Token może następnie służyć do autoryzowania żądania względem usługi Blob Service.
Autoryzacja za pomocą identyfikatora Entra firmy Microsoft jest dostępna dla wszystkich kont ogólnego przeznaczenia i usługi Blob Storage we wszystkich regionach publicznych i chmurach krajowych. Tylko konta magazynu utworzone za pomocą modelu wdrażania usługi Azure Resource Manager obsługują autoryzację firmy Microsoft Entra.
Ważne
Aby uzyskać optymalne zabezpieczenia, firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z tożsamościami zarządzanymi w celu autoryzowania żądań względem danych obiektów blob, kolejek i tabel, jeśli 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 delegowania użytkowników. Sygnatura dostępu współdzielonego delegowania użytkownika jest zabezpieczona przy użyciu poświadczeń usługi Microsoft Entra zamiast klucza 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 identyfikatora Entra firmy Microsoft dla obiektów blob
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. W przypadku identyfikatora Entra firmy Microsoft dostęp do zasobu jest procesem dwuetapowym:
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.
Następnie token jest przekazywany jako część żądania do usługi Blob Service i używany przez usługę 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żywanie konta Microsoft Entra z portalem, programem PowerShell lub interfejsem wiersza polecenia platformy Azure
Aby dowiedzieć się, jak uzyskać dostęp do danych w witrynie Azure Portal przy użyciu konta Microsoft Entra, zobacz Dostęp do danych w witrynie Azure Portal. Aby dowiedzieć się, jak wywoływać polecenia programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure przy użyciu konta Microsoft Entra, zobacz Dostęp do danych za pomocą programu PowerShell lub interfejsu wiersza polecenia platformy Azure.
Używanie identyfikatora Entra firmy Microsoft do autoryzowania dostępu w kodzie aplikacji
Aby autoryzować dostęp do usługi Azure Storage przy użyciu identyfikatora Entra firmy Microsoft, możesz użyć 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.
- Biblioteka Microsoft Authentication Library (MSAL) może być odpowiednia dla niektórych zaawansowanych scenariuszy.
Biblioteka klienta tożsamości platformy Azure
Biblioteka klienta tożsamości platformy Azure upraszcza proces uzyskiwania tokenu dostępu OAuth 2.0 do autoryzacji przy użyciu identyfikatora Entra firmy Microsoft za pośrednictwem zestawu Azure SDK. Najnowsze wersje bibliotek klienckich usługi Azure Storage dla platformy .NET, Java, Python, JavaScript i Go są zintegrowane z bibliotekami tożsamości platformy Azure dla każdego z tych języków, aby zapewnić prosty i bezpieczny sposób uzyskiwania tokenu dostępu do autoryzacji żądań usługi 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 na platformie Azure, jednostka zabezpieczeń może być tożsamością zarządzaną dla zasobów platformy Azure, jednostki usługi lub użytkownika lub grupy. W środowisku projektowym biblioteka klienta udostępnia token dostępu dla użytkownika lub jednostki usługi na potrzeby testowania.
Token dostępu zwrócony przez bibliotekę klienta tożsamości platformy Azure jest hermetyzowany w poświadczeniach tokenu. Następnie możesz użyć poświadczeń tokenu, aby uzyskać obiekt klienta usługi do użycia w wykonywaniu autoryzowanych operacji w usłudze Azure Storage. Prostym sposobem uzyskania tokenu dostępu i poświadczeń tokenu jest użycie klasy DefaultAzureCredential udostępnianej przez bibliotekę klienta tożsamości platformy Azure. DomyślnieAzureCredential próbuje pobrać poświadczenia tokenu sekwencyjnie, próbując wykonać kilka różnych typów poświadczeń. Wartość domyślnaAzureCredential działa zarówno w środowisku projektowym, jak i na platformie Azure.
Poniższa tabela zawiera dodatkowe informacje dotyczące autoryzowania dostępu do danych w różnych scenariuszach:
Biblioteka uwierzytelniania firmy Microsoft (MSAL)
Chociaż firma Microsoft zaleca korzystanie z biblioteki klienta tożsamości platformy Azure, 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ę więcej na temat biblioteki MSAL.
Jeśli używasz biblioteki MSAL do uzyskania tokenu OAuth na potrzeby dostępu do usługi Azure Storage, musisz podać identyfikator zasobu Entra firmy Microsoft. 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 usługi Azure Storage identyfikator zasobu może być specyficzny dla pojedynczego konta magazynu lub może mieć zastosowanie do dowolnego konta magazynu.
Po podaniu identyfikatora zasobu specyficznego dla pojedynczego konta magazynu i usługi identyfikator zasobu jest używany do uzyskiwania tokenu na potrzeby autoryzowania żądań tylko do określonego 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 magazynu.
| Chmura | Identyfikator zasobu |
|---|---|
| Globalna platforma Azure | https://<account-name>.blob.core.windows.net |
| Azure Government | https://<account-name>.blob.core.usgovcloudapi.net |
| Azure w Chinach — 21Vianet | https://<account-name>.blob.core.chinacloudapi.cn |
Możesz również podać identyfikator zasobu, który ma zastosowanie do dowolnego konta magazynu, 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 w Chinach — 21Vianet |
https://storage.azure.com/ |
Przypisywanie ról platformy Azure na potrzeby praw dostępu
Firma Microsoft Entra autoryzuje prawa dostępu do zabezpieczonych zasobów za pośrednictwem kontroli dostępu opartej na rolach platformy Azure. Usługa Azure Storage definiuje zestaw wbudowanych ról RBAC obejmujących typowe zestawy uprawnień używanych do uzyskiwania dostępu do danych obiektów blob. Można również zdefiniować role niestandardowe na potrzeby dostępu do danych obiektów 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ę 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
W niektórych przypadkach może być konieczne włączenie szczegółowego dostępu do zasobów obiektów blob lub uproszczenie uprawnień w przypadku dużej liczby przypisań ról dla zasobu magazynu. Do konfigurowania warunków przypisań ról można użyć kontroli dostępu opartej na atrybutach platformy Azure (Azure ABAC). Możesz użyć warunków z rolą niestandardową lub wybrać wbudowane role. 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 danych obiektów blob, zobacz Akcje i atrybuty warunków przypisywania ról platformy Azure w usłudze Azure Storage (wersja zapoznawcza).
Uwaga
Podczas tworzenia konta usługi Azure Storage nie masz automatycznie przypisanych uprawnień dostępu do danych za pośrednictwem identyfikatora Entra firmy Microsoft. 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ń. Najlepsze rozwiązania określają, że zawsze najlepiej przyznać tylko najwęższy możliwy zakres. Role RBAC platformy Azure zdefiniowane w szerszym zakresie są dziedziczone przez pod nimi zasoby.
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 magazynu W tym zakresie przypisanie roli ma zastosowanie do wszystkich kontenerów i ich obiektów blob.
- 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 magazynu we wszystkich grupach zasobów w subskrypcji.
- Grupa zarządzania. W tym zakresie przypisanie roli ma zastosowanie do wszystkich kontenerów we wszystkich kontach magazynu we wszystkich grupach zasobów we wszystkich subskrypcjach w grupie zarządzania.
Aby uzyskać więcej informacji na temat zakresu przypisań ról RBAC platformy Azure, zobacz Omówienie zakresu kontroli dostępu opartej na rolach platformy Azure.
Wbudowane role platformy Azure dla obiektów blob
Kontrola dostępu oparta na rolach platformy Azure udostępnia kilka wbudowanych ról umożliwiających autoryzowanie dostępu do danych obiektów blob przy użyciu identyfikatora Entra firmy Microsoft i protokołu OAuth. Oto kilka przykładów ról, które zapewniają uprawnienia do zasobów danych w usłudze Azure Storage:
- Właściciel danych obiektu blob usługi Storage: Służy do określania własności i zarządzania kontrolą dostępu POSIX w usłudze Azure Data Lake Storage Gen2. Aby uzyskać więcej informacji, zobacz Kontrola dostępu w usłudze Azure Data Lake Storage Gen2.
- Współautor danych obiektu blob usługi Storage: Służy do przyznawania uprawnień do odczytu/zapisu/usuwania do zasobów usługi Blob Storage.
- Czytelnik danych obiektu blob usługi Storage: Służy do przyznawania uprawnień tylko do odczytu do zasobów usługi Blob Storage.
- Delegator obiektów blob magazynu: Pobierz klucz delegowania użytkownika, który będzie używany do utworzenia sygnatury dostępu współdzielonego podpisanej przy użyciu poświadczeń usługi Microsoft Entra dla kontenera lub obiektu blob.
Aby dowiedzieć się, jak przypisać wbudowaną rolę platformy Azure do podmiotu zabezpieczeń, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych obiektów 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ą podmiotowi zabezpieczeń na dostęp do danych obiektów 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 identyfikatora Microsoft Entra. Jeśli jednak rola zawiera wartość Microsoft.Storage/storageAccounts/listKeys/action, użytkownik, któremu przypisano tę rolę, może uzyskać dostęp do danych na koncie magazynu za pośrednictwem autoryzacji klucza współdzielonego z kluczami 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 dla usługi Azure Storage dla usług danych i usługi zarządzania, zobacz sekcję Storage w temacie Role wbudowane platformy Azure dla kontroli dostępu opartej na rolach platformy Azure. 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
Propagacja przypisań ról platformy 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.
Uzyskiwanie dostępu do danych przy użyciu konta Microsoft Entra
Dostęp do danych obiektów blob za pośrednictwem witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia platformy Azure można autoryzować przy użyciu konta Microsoft Entra użytkownika 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 parametry 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
Witryna Azure Portal może używać konta Microsoft Entra lub kluczy dostępu do konta w celu uzyskania dostępu do danych obiektów blob na koncie usługi Azure Storage. Który schemat autoryzacji używany w witrynie Azure Portal zależy od przypisanych ról platformy Azure.
Podczas próby uzyskania dostępu do danych obiektów blob witryna Azure Portal najpierw sprawdza, czy przypisano ci rolę platformy Azure za pomocą polecenia Microsoft.Storage/storageAccounts/listkeys/action. Jeśli przypisano ci rolę z tą akcją, witryna Azure Portal używa klucza konta do uzyskiwania dostępu do danych obiektów blob za pośrednictwem autoryzacji klucza współdzielonego. Jeśli nie przypisano ci roli z tą akcją, witryna Azure Portal próbuje uzyskać dostęp do danych przy użyciu konta Microsoft Entra.
Aby uzyskać dostęp do danych obiektów blob z witryny Azure Portal przy użyciu konta firmy Microsoft Entra, musisz mieć uprawnienia dostępu do danych obiektów blob, a także musisz mieć uprawnienia do nawigowania po zasobach konta magazynu w witrynie Azure Portal. 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 magazynu. Z tego powodu dostęp do portalu wymaga również przypisania roli usługi Azure Resource Manager, takiej jak rola czytelnika, z zakresem obejmującym poziom konta magazynu lub wyższym. Rola Czytelnik przyznaje najbardziej ograniczone uprawnienia, ale inna rola Azure Resource Manager, która przyznaje dostęp do zasobów zarządzania kontami magazynu, jest również akceptowalna. Aby dowiedzieć się więcej na temat przypisywania użytkownikom uprawnień dostępu do danych w witrynie Azure Portal przy użyciu konta usługi 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 witrynie, zobacz Wybieranie sposobu autoryzowania dostępu do danych obiektów blob w witrynie Azure Portal.
Dostęp do danych z poziomu programu PowerShell lub interfejsu wiersza polecenia platformy Azure
Interfejs wiersza polecenia platformy Azure i program PowerShell obsługują logowanie przy użyciu poświadczeń firmy Microsoft Entra. Po zalogowaniu sesja jest uruchamiana w ramach tych poświadczeń. Aby dowiedzieć się więcej, zobacz jeden z następujących artykułów:
- Wybieranie sposobu autoryzowania dostępu do danych obiektów blob za pomocą interfejsu wiersza polecenia platformy Azure
- Uruchamianie poleceń programu z poświadczeniami usługi Microsoft Entra w celu uzyskania dostępu do danych obiektów blob
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.