Model kontroli dostępu w usłudze Azure Data Lake Storage
Usługa Data Lake Storage obsługuje następujące mechanizmy autoryzacji:
- Autoryzacja klucza współdzielonego
- Autoryzacja sygnatury dostępu współdzielonego (SAS)
- Kontrola dostępu oparta na rolach (Azure RBAC)
- Kontrola dostępu oparta na atrybutach (Azure ABAC)
- Listy kontroli dostępu (ACL)
Klucz współużytkowany, sygnatura dostępu współdzielonego konta i autoryzacja sygnatury dostępu współdzielonego usługi udziela dostępu użytkownikowi (lub aplikacji) bez konieczności posiadania tożsamości w identyfikatorze Entra firmy Microsoft. W przypadku tych form uwierzytelniania kontrola dostępu oparta na rolach platformy Azure, kontrola abac platformy Azure i listy ACL nie mają wpływu. Listy ACL można stosować do tokenów SAS delegowanych przez użytkownika, ponieważ te tokeny są zabezpieczone przy użyciu poświadczeń firmy Microsoft Entra. Zobacz Autoryzacja klucza współdzielonego i sygnatury dostępu współdzielonego.
Kontrola dostępu oparta na rolach platformy Azure i lista ACL wymagają, aby użytkownik (lub aplikacja) miał tożsamość w usłudze Microsoft Entra ID. Kontrola dostępu oparta na rolach platformy Azure umożliwia przyznanie dostępu „gruboziarnistego” do danych konta magazynu, takich jak dostęp do odczytu lub zapisu do wszystkich danych na koncie magazynu. Funkcja ABAC platformy Azure umożliwia uściślenie przypisań ról RBAC przez dodanie warunków. Na przykład można udzielić dostępu do odczytu lub zapisu do wszystkich obiektów danych na koncie magazynu, które mają określony tag. Listy ACL umożliwiają udzielanie dostępu „szczegółowego”, takiego jak dostęp do zapisu do określonego katalogu lub pliku.
Ten artykuł koncentruje się na kontroli dostępu opartej na rolach platformy Azure, kontroli dostępu opartej na rolach i listach ACL oraz o tym, jak system ocenia je razem w celu podejmowania decyzji dotyczących autoryzacji dla zasobów konta magazynu.
Kontrola dostępu oparta na rolach (Azure RBAC)
Kontrola dostępu oparta na rolach platformy Azure używa przypisań ról do stosowania zestawów uprawnień do podmiotów zabezpieczeń. Podmiot zabezpieczeń to obiekt reprezentujący użytkownika, grupę, jednostkę usługi lub tożsamość zarządzaną zdefiniowaną w identyfikatorze Entra firmy Microsoft. Zestaw uprawnień może nadać jednostce zabezpieczeń poziom dostępu "gruboziarnisty", taki jak dostęp do odczytu lub zapisu do wszystkich danych na koncie magazynu lub wszystkich danych w kontenerze.
Następujące role umożliwiają jednostce zabezpieczeń uzyskiwanie dostępu do danych na koncie magazynu.
| Rola | opis |
|---|---|
| Właściciel danych obiektu blob usługi Storage | Pełny dostęp do kontenerów i danych usługi Blob Storage. Ten dostęp pozwala podmiotowi zabezpieczeń ustawić właściciela elementu i zmodyfikować listy ACL wszystkich elementów. |
| Współautor danych w usłudze Blob Storage | Odczyt, zapis i usuwanie dostępu do kontenerów i obiektów blob usługi Blob Storage. Ten dostęp nie zezwala podmiotowi zabezpieczeń na ustawianie własności elementu, ale może zmodyfikować listę ACL elementów należących do podmiotu zabezpieczeń. |
| Czytelnik danych obiektu blob usługi Storage | Odczytywanie i wyświetlanie listy kontenerów i obiektów blob usługi Blob Storage. |
Role, takie jak Właściciel, Współautor, Czytelnik i Współautor konta magazynu, umożliwiają podmiotowi zabezpieczeń zarządzanie kontem magazynu, ale nie zapewniają dostępu do danych w ramach tego konta. Jednak te role (z wyłączeniem czytelnika) mogą uzyskać dostęp do kluczy magazynu, które mogą być używane w różnych narzędziach klienckich w celu uzyskania dostępu do danych.
Kontrola dostępu oparta na atrybutach (Azure ABAC)
Usługa Azure ABAC bazuje na kontroli dostępu opartej na rolach platformy Azure przez dodanie warunków przypisywania ról na podstawie atrybutów w kontekście określonych akcji. Warunek przypisania roli to dodatkowa kontrola, którą można opcjonalnie dodać do przypisania roli, aby zapewnić bardziej uściślioną kontrolę dostępu. Nie można jawnie odmówić dostępu do określonych zasobów przy użyciu warunków.
Aby uzyskać więcej informacji na temat kontrolowania dostępu do usługi Azure Storage przy użyciu usługi Azure ABAC, zobacz Autoryzowanie dostępu do usługi Azure Blob Storage przy użyciu warunków przypisywania ról platformy Azure.
Listy kontroli dostępu (ACL)
Listy ACL umożliwiają stosowanie "bardziej szczegółowego" poziomu dostępu do katalogów i plików. Lista ACL to konstrukcja uprawnień zawierająca serię wpisów listy ACL. Każdy wpis listy ACL kojarzy podmiot zabezpieczeń z poziomem dostępu. Aby dowiedzieć się więcej, zobacz Listy kontroli dostępu (ACL) w usłudze Azure Data Lake Storage.
Jak są oceniane uprawnienia
Podczas autoryzacji opartej na jednostkach zabezpieczeń uprawnienia są oceniane, jak pokazano na poniższym diagramie.
- Platforma Azure określa, czy dla podmiotu zabezpieczeń istnieje przypisanie roli.
- Jeśli przypisanie roli istnieje, warunki przypisania roli (2) są oceniane następnego.
- Jeśli nie, listy ACL (4) zostaną ocenione w następnej kolejności.
- Platforma Azure określa, czy istnieją jakiekolwiek warunki przypisywania ról ABAC.
- Jeśli nie istnieją żadne warunki, dostęp zostanie udzielony.
- Jeśli istnieją warunki, są oceniane, aby sprawdzić, czy są zgodne z żądaniem (3).
- Platforma Azure określa, czy wszystkie warunki przypisywania ról ABAC są zgodne z atrybutami żądania.
- Jeśli wszystkie z nich są zgodne, zostanie udzielony dostęp.
- Jeśli co najmniej jeden z nich nie jest zgodny, listy ACL (4) są oceniane następnego.
- Jeśli dostęp nie został jawnie udzielony po ocenie przypisań ról i warunków, listy ACL są oceniane.
- Jeśli listy ACL zezwalają na żądany poziom dostępu, zostanie udzielony dostęp.
- Jeśli nie, dostęp zostanie odrzucony.
Ważne
Ze względu na sposób, w jaki uprawnienia dostępu są oceniane przez system, nie można użyć listy ACL, aby ograniczyć dostęp, który został już przyznany przez przypisanie roli i jego warunki. Dzieje się tak, ponieważ system najpierw ocenia przypisania ról i warunki platformy Azure, a jeśli przypisanie przyznaje wystarczające uprawnienia dostępu, listy ACL są ignorowane.
Na poniższym diagramie przedstawiono przepływ uprawnień dla trzech typowych operacji: wyświetlanie zawartości katalogu, odczytywanie pliku i zapisywanie pliku.
Tabela uprawnień: łączenie kontroli dostępu opartej na rolach platformy Azure, kontroli dostępu opartej na rolach i list ACL
W poniższej tabeli pokazano, jak połączyć role, warunki i wpisy listy ACL platformy Azure, aby podmiot zabezpieczeń mógł wykonywać operacje wymienione w kolumnie Operacja . W tej tabeli przedstawiono kolumnę reprezentującą każdy poziom fikcyjnej hierarchii katalogów. Istnieje kolumna katalogu głównego kontenera (/), podkatalog o nazwie Oregon, podkatalog katalogu Oregon o nazwie Portland i plik tekstowy w katalogu Portland o nazwie Data.txt. Wyświetlane w tych kolumnach są krótkie reprezentacje formularza wpisu listy ACL wymagane do udzielenia uprawnień. N/A (Nie dotyczy) pojawia się w kolumnie, jeśli wpis listy ACL nie jest wymagany do wykonania operacji.
| Operacja | Przypisana rola platformy Azure (z warunkami lub bez niego) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Odczyt Data.txt | Właściciel danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak |
| Współautor danych w usłudze Blob Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Czytelnik danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Brak | --X |
--X |
--X |
R-- |
|
| Dołączanie do Data.txt | Właściciel danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak |
| Współautor danych w usłudze Blob Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Czytelnik danych obiektu BLOB usługi Storage | --X |
--X |
--X |
-W- |
|
| Brak | --X |
--X |
--X |
RW- |
|
| Usuwanie Data.txt | Właściciel danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak |
| Współautor danych w usłudze Blob Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Czytelnik danych obiektu BLOB usługi Storage | --X |
--X |
-WX |
Nie dotyczy | |
| Brak | --X |
--X |
-WX |
Nie dotyczy | |
| Tworzenie/aktualizowanie Data.txt | Właściciel danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak |
| Współautor danych w usłudze Blob Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Czytelnik danych obiektu BLOB usługi Storage | --X |
--X |
-WX |
Nie dotyczy | |
| Brak | --X |
--X |
-WX |
Nie dotyczy | |
| Lista/ | Właściciel danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak |
| Współautor danych w usłudze Blob Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Czytelnik danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Brak | R-X |
Brak | NIE DOTYCZY | Brak | |
| Lista /Oregon/ | Właściciel danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak |
| Współautor danych w usłudze Blob Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Czytelnik danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Brak | --X |
R-X |
Brak | Brak | |
| Lista /Oregon/Portland/ | Właściciel danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak |
| Współautor danych w usłudze Blob Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Czytelnik danych obiektu BLOB usługi Storage | Brak | NIE DOTYCZY | NIE DOTYCZY | Brak | |
| Brak | --X |
--X |
R-X |
Brak |
Uwaga
Aby wyświetlić zawartość kontenera w Eksplorator usługi Azure Storage, podmioty zabezpieczeń muszą zalogować się do Eksplorator usługi Storage przy użyciu identyfikatora Microsoft Entra i (co najmniej) mieć dostęp do odczytu (R--) do folderu głównego (\) kontenera. Ten poziom uprawnień daje im możliwość wyświetlania listy zawartości folderu głównego. Jeśli nie chcesz, aby zawartość folderu głównego mogła być widoczna, możesz przypisać im rolę Czytelnik . Dzięki tej roli będą mogli wyświetlić listę kontenerów na koncie, ale nie zawartość kontenera. Następnie można udzielić dostępu do określonych katalogów i plików przy użyciu list ACL.
Grupy zabezpieczeń
Zawsze używaj grup zabezpieczeń Entra firmy Microsoft jako przypisanego podmiotu zabezpieczeń we wpisie listy ACL. Unikaj bezpośredniego przypisywania poszczególnych użytkowników lub zleceniodawców usług. Użycie tej struktury umożliwia dodawanie i usuwanie użytkowników lub jednostek usługi bez konieczności ponownego stosowania list ACL do całej struktury katalogów. Zamiast tego możesz po prostu dodawać lub usuwać użytkowników i jednostki usługi z odpowiedniej grupy zabezpieczeń firmy Microsoft Entra.
Istnieje wiele różnych sposobów konfigurowania grup. Załóżmy na przykład, że masz katalog o nazwie /LogData , który przechowuje dane dziennika generowane przez serwer. Usługa Azure Data Factory (ADF) pozyskiwa dane do tego folderu. Konkretni użytkownicy z zespołu inżynierów usług będą przekazywać dzienniki i zarządzać innymi użytkownikami tego folderu, a różne klastry usługi Databricks będą analizować dzienniki z tego folderu.
Aby włączyć te działania, możesz utworzyć grupę LogsWriter i grupę LogsReader . Następnie można przypisać uprawnienia w następujący sposób:
- Dodaj grupę
LogsWriterdo listy ACL katalogu /LogData z uprawnieniamirwx. - Dodaj grupę
LogsReaderdo listy ACL katalogu /LogData z uprawnieniamir-x. - Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej (MSI) dla usługi
LogsWritersADF. - Dodaj użytkowników w zespole inżynierów usług do
LogsWritergrupy. - Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej
LogsReaderdla usługi Databricks.
Jeśli użytkownik w zespole inżynierów usług opuści firmę, możesz je usunąć z LogsWriter grupy. Jeśli nie dodano tego użytkownika do grupy, ale zamiast tego dodano dedykowany wpis listy ACL dla tego użytkownika, należy usunąć ten wpis listy ACL z katalogu /LogData . Należy również usunąć wpis ze wszystkich podkatalogów i plików w całej hierarchii katalogów katalogu /LogData .
Aby utworzyć grupę i dodać członków, zobacz Tworzenie podstawowej grupy i dodawanie członków przy użyciu identyfikatora Entra firmy Microsoft.
Ważne
Usługa Azure Data Lake Storage Gen2 zależy od identyfikatora entra firmy Microsoft do zarządzania grupami zabezpieczeń. Identyfikator Entra firmy Microsoft zaleca ograniczenie członkostwa w grupie dla danego podmiotu zabezpieczeń do mniej niż 200. To zalecenie jest spowodowane ograniczeniem tokenów sieci Web JSON (JWT), które zapewniają informacje o członkostwie podmiotu zabezpieczeń w aplikacjach firmy Microsoft Entra. Przekroczenie tego limitu może prowadzić do nieoczekiwanych problemów z wydajnością usługi Data Lake Storage Gen2. Aby dowiedzieć się więcej, zobacz Konfigurowanie oświadczeń grup dla aplikacji przy użyciu identyfikatora Entra firmy Microsoft.
Limity przypisań ról i wpisów listy ACL platformy Azure
Korzystając z grup, mniej prawdopodobne jest przekroczenie maksymalnej liczby przypisań ról na subskrypcję i maksymalnej liczby wpisów listy ACL na plik lub katalog. W poniższej tabeli opisano te limity.
| Mechanizm | Scope | Limity | Obsługiwany poziom uprawnień |
|---|---|---|---|
| Kontrola dostępu na podstawie ról platformy Azure | Konta magazynu, kontenery. Przypisania ról platformy Azure między zasobami na poziomie subskrypcji lub grupy zasobów. |
4000 przypisań ról platformy Azure w subskrypcji | Role platformy Azure (wbudowane lub niestandardowe) |
| ACL | Katalog, plik | 32 wpisy listy ACL (skutecznie 28 wpisów listy ACL) na plik i na katalog. Listy ACL dostępu i domyślne listy ACL mają własny limit wynoszący 32 wpisy ACL. | Uprawnienie listy ACL |
Autoryzacja klucza współdzielonego i sygnatury dostępu współdzielonego (SAS)
Usługa Azure Data Lake Storage obsługuje również metody klucza współdzielonego i sygnatury dostępu współdzielonego na potrzeby uwierzytelniania.
W przypadku klucza współużytkowanego obiekt wywołujący skutecznie uzyskuje dostęp "superużytkownika", co oznacza pełny dostęp do wszystkich operacji na wszystkich zasobach, w tym danych, ustawiania właściciela i zmieniania list ACL. Listy ACL nie mają zastosowania do użytkowników korzystających z autoryzacji klucza współużytkowanego, ponieważ żadna tożsamość nie jest skojarzona z obiektem wywołującym i dlatego nie można wykonać autoryzacji opartej na uprawnieniach podmiotu zabezpieczeń. To samo dotyczy tokenów sygnatury dostępu współdzielonego (SAS), z wyjątkiem sytuacji, gdy jest używany token SAS delegowany przez użytkownika. W takim przypadku usługa Azure Storage wykonuje sprawdzanie listy ACL POSIX względem identyfikatora obiektu, zanim autoryzuje operację, o ile opcjonalny parametr suoid jest używany. Aby dowiedzieć się więcej, zobacz Tworzenie sygnatury dostępu współdzielonego delegowania użytkownika.
Następne kroki
Aby dowiedzieć się więcej na temat list kontroli dostępu, zobacz Listy kontroli dostępu (ACL) w usłudze Azure Data Lake Storage.