Udostępnij za pośrednictwem


Model kontroli dostępu w usłudze Azure Data Lake Storage Gen2

Usługa Data Lake Storage Gen2 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 udostępniony i autoryzacja sygnatury dostępu współdzielonego udziela dostępu użytkownikowi (lub aplikacji) bez konieczności posiadania tożsamości w identyfikatorze Entra firmy Microsoft. Dzięki tym dwóm formom uwierzytelniania kontrola dostępu oparta na rolach platformy Azure, usługa Azure ABAC i listy ACL nie mają wpływu.

Zarówno kontrola dostępu oparta na rolach platformy Azure, jak i lista ACL wymagają, aby użytkownik (lub aplikacja) miał tożsamość w identyfikatorze Entra firmy Microsoft. 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 obiektu blob usługi 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 Gen2.

Jak są oceniane uprawnienia

Podczas autoryzacji opartej na jednostkach zabezpieczeń uprawnienia są oceniane, jak pokazano na poniższym diagramie.

data lake storage permission flow

  1. 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.
  2. 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).
  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.
  4. 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.

data lake storage permission flow example

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
Odczytywanie pliku Data.txt Właściciel danych Storage Blob 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
None --X --X --X R--
Dołączanie do pliku Data.txt Właściciel danych Storage Blob 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-
None --X --X --X RW-
Usuń plik Data.txt Właściciel danych Storage Blob 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
None --X --X -WX Nie dotyczy
Tworzenie pliku Data.txt Właściciel danych Storage Blob 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
None --X --X -WX Nie dotyczy
Listy/ Właściciel danych Storage Blob 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
None R-X Brak NIE DOTYCZY Brak
Lista /Oregon/ Właściciel danych Storage Blob 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
None --X R-X Brak Brak
Lista /Oregon/Portland/ Właściciel danych Storage Blob 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
None --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. Opór możliwości bezpośredniego przypisywania poszczególnych użytkowników lub jednostek usługi. 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ę LogsWriter do listy ACL katalogu /LogData z uprawnieniami rwx .
  • Dodaj grupę LogsReader do listy ACL katalogu /LogData z uprawnieniami r-x .
  • Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej (MSI) dla usługi LogsWriters ADF.
  • Dodaj użytkowników w zespole inżynierów usług do LogsWriter grupy.
  • Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej LogsReader dla 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 Zakres 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 Gen2 obsługuje również metody klucza współdzielonego i sygnatury dostępu współdzielonego na potrzeby uwierzytelniania. Charakterystyczną cechą tych metod uwierzytelniania jest to, że żadna tożsamość nie jest skojarzona z obiektem wywołującym i dlatego nie można wykonać autoryzacji opartej na uprawnieniach podmiotu zabezpieczeń.

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.

Tokeny SAS obejmują dozwolone uprawnienia w ramach tokenu. Uprawnienia zawarte w tokenie SAS są skutecznie stosowane do wszystkich decyzji dotyczących autoryzacji, ale nie są wykonywane żadne dodatkowe kontrole listy ACL.

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