Kontrola dostępu i konfiguracje magazynu data lake w usłudze Azure Data Lake Storage Gen2

Ten artykuł pomaga ocenić i zrozumieć mechanizmy kontroli dostępu w usłudze Azure Data Lake Storage Gen2. Te mechanizmy obejmują kontrolę dostępu opartą na rolach (RBAC) platformy Azure i listy kontroli dostępu (ACL). Dowiesz się:

  • Jak ocenić dostęp między kontrolą dostępu opartą na rolach platformy Azure i listami ACL
  • Jak skonfigurować kontrolę dostępu przy użyciu jednego lub obu tych mechanizmów
  • Jak zastosować mechanizmy kontroli dostępu do wzorców implementacji usługi Data Lake

Potrzebujesz podstawowej wiedzy na temat kontenerów magazynu, grup zabezpieczeń, kontroli dostępu opartej na rolach platformy Azure i list ACL. Aby oprawić dyskusję, odwołujemy się do ogólnej struktury typu data lake nieprzetworzonych, wzbogaconych i wyselekcjonowanych stref.

Tego dokumentu można używać z zarządzaniem dostępem do danych.

Korzystanie z wbudowanych ról kontroli dostępu opartej na rolach platformy Azure

Usługa Azure Storage ma dwie warstwy dostępu: zarządzanie usługami i dane. Dostęp do subskrypcji i kont magazynu można uzyskać za pośrednictwem warstwy zarządzania usługami. Uzyskiwanie dostępu do kontenerów, obiektów blob i innych zasobów danych za pośrednictwem warstwy danych. Jeśli na przykład chcesz wyświetlić listę kont magazynu z platformy Azure, wyślij żądanie do punktu końcowego zarządzania. Jeśli chcesz uzyskać listę systemów plików, folderów lub plików na koncie magazynu, wyślij żądanie do punktu końcowego usługi.

Role mogą zawierać uprawnienia do zarządzania lub dostępu do warstwy danych. Rola Czytelnik udziela dostępu tylko do odczytu do zasobów warstwy zarządzania, ale nie do odczytu do danych.

Role, takie jak Właściciel, Współautor, Czytelnik i Współautor konta magazynu, umożliwiają podmiotowi zabezpieczeń zarządzanie kontem magazynu. Nie zapewniają jednak dostępu do danych na tym koncie. Tylko role jawnie zdefiniowane dla dostępu do danych zezwalają podmiotowi zabezpieczeń na dostęp do danych. Te role, z wyjątkiem czytelnika, uzyskują dostęp do kluczy magazynu w celu uzyskania dostępu do danych.

Wbudowane role zarządzania

Poniżej przedstawiono wbudowane role zarządzania.

  • Właściciel: Zarządzaj wszystkimi elementami, w tym dostępem do zasobów. Ta rola zapewnia dostęp do klucza.
  • Współautor: Zarządzaj wszystkim, z wyjątkiem dostępu do zasobów. Ta rola zapewnia dostęp do klucza.
  • Współautor konta magazynu: pełne zarządzanie kontami magazynu. Ta rola zapewnia dostęp do klucza.
  • Czytelnik: odczytywanie i wyświetlanie listy zasobów. Ta rola nie zapewnia dostępu do klucza.

Wbudowane role danych

Poniżej przedstawiono wbudowane role danych.

  • Właściciel danych obiektu blob usługi Storage: pełny dostęp do kontenerów obiektów blob i danych usługi Azure Storage, w tym ustawiania własności i zarządzania kontrolą dostępu w systemie POSIX.
  • Współautor danych obiektu blob usługi Storage: odczyt, zapis i usuwanie kontenerów i obiektów blob usługi Azure Storage.
  • Czytelnik danych obiektów blob usługi Storage: odczyt i wyświetlanie listy kontenerów i obiektów blob usługi Azure Storage.

Właściciel danych obiektu blob usługi Storage jest rolą administratora, która ma pełny dostęp do wszystkich operacjimutowania. Te operacje obejmują ustawienie właściciela katalogu lub pliku i list ACL dla katalogów i plików, dla których nie są właścicielami. Dostęp administratora jest jedynym autoryzowanym sposobem zmiany właściciela zasobu.

Uwaga

Propagacja przypisań RBAC platformy Azure może potrwać do pięciu minut.

Sposób oceniania dostępu

Podczas autoryzacji opartej na jednostkach zabezpieczeń system ocenia uprawnienia w następującej kolejności. Aby uzyskać więcej informacji, zobacz poniższy diagram.

  • Kontrola dostępu oparta na rolach platformy Azure jest oceniana jako pierwsza i ma priorytet nad wszystkimi przypisaniami listy ACL.
  • Jeśli operacja jest w pełni autoryzowana na podstawie kontroli dostępu opartej na rolach, listy ACL nie są w ogóle oceniane.
  • Jeśli operacja nie jest w pełni autoryzowana, zostaną ocenione listy ACL.

Aby uzyskać więcej informacji, zobacz Jak są oceniane uprawnienia.

Uwaga

Ten model uprawnień dotyczy tylko usługi Azure Data Lake Storage. Nie ma zastosowania do magazynu ogólnego przeznaczenia ani obiektów blob bez włączonej hierarchicznej przestrzeni nazw. Ten opis wyklucza metody uwierzytelniania współużytkowanego klucza i sygnatury dostępu współdzielonego. Wyklucza również scenariusze, w których podmiot zabezpieczeń ma przypisaną wbudowaną rolę Właściciela danych obiektu blob usługi Storage, która zapewnia dostęp administratora. Ustaw allowSharedKeyAccess wartość false, aby dostęp był poddawane inspekcji według tożsamości.

Diagram of a flow chart that shows how access is evaluated.

Aby uzyskać więcej informacji o tym, jakie uprawnienia oparte na listach ACL są wymagane dla danej operacji, zobacz Listy kontroli dostępu w usłudze Azure Data Lake Storage Gen2.

Uwaga

  • Listy kontroli dostępu dotyczą tylko podmiotów zabezpieczeń w tej samej dzierżawie, w tym użytkowników-gości.
  • Każdy użytkownik z uprawnieniami do dołączania do klastra może tworzyć punkty instalacji usługi Azure Databricks. Skonfiguruj punkt instalacji przy użyciu poświadczeń jednostki usługi lub opcji przekazywania entra firmy Microsoft. W momencie tworzenia uprawnienia nie są oceniane. Uprawnienia są oceniane, gdy operacja używa punktu instalacji. Każdy użytkownik, który może dołączyć do klastra, może podjąć próbę użycia punktu instalacji.
  • Gdy użytkownik tworzy definicję tabeli w usłudze Azure Databricks lub Azure Synapse Analytics, musi mieć dostęp do odczytu do danych bazowych.

Konfigurowanie dostępu do usługi Azure Data Lake Storage

Skonfiguruj kontrolę dostępu w usłudze Azure Data Lake Storage przy użyciu kontroli dostępu opartej na rolach platformy Azure, list ACL lub kombinacji obu tych funkcji.

Konfigurowanie dostępu tylko przy użyciu kontroli dostępu opartej na rolach platformy Azure

Jeśli wystarczy kontrola dostępu na poziomie kontenera, przypisania kontroli dostępu opartej na rolach platformy Azure oferują proste podejście do zarządzania zabezpieczaniem danych. Zaleca się używanie list kontroli dostępu dla dużej liczby ograniczonych zasobów danych lub w przypadku, gdy wymagana jest szczegółowa kontrola dostępu.

Konfigurowanie dostępu tylko przy użyciu list ACL

Poniżej przedstawiono zalecenia dotyczące konfiguracji dotyczące analizy w skali chmury.

Przypisz wpisy kontroli dostępu do grupy zabezpieczeń, a nie do pojedynczego użytkownika lub jednostki usługi. Aby uzyskać więcej informacji, zobacz Używanie grup zabezpieczeń i poszczególnych użytkowników.

Po dodaniu lub usunięciu użytkowników z grupy nie musisz wprowadzać aktualizacji do usługi Data Lake Storage. Ponadto użycie grup zmniejsza prawdopodobieństwo przekroczenia 32 wpisów kontroli dostępu na listę ACL plików lub folderów. Po czterech domyślnych wpisach istnieją tylko 28 pozostałych wpisów dla przypisań uprawnień.

Nawet w przypadku korzystania z grup można mieć wiele wpisów kontroli dostępu na najwyższych poziomach drzewa katalogów. Taka sytuacja występuje, gdy wymagane są szczegółowe uprawnienia dla różnych grup.

Diagram that shows several security groups requiring access to three data products.

Konfigurowanie dostępu przy użyciu kontroli dostępu opartej na rolach platformy Azure i list kontroli dostępu

Uprawnienia Współautor danych obiektu blob usługi Storage i Czytelnik danych obiektu blob usługi Storage zapewniają dostęp do danych, a nie do konta magazynu. Dostęp można udzielić na poziomie konta magazynu lub na poziomie kontenera. Jeśli przypisano współautora danych obiektu blob usługi Storage, listy ACL nie mogą być używane do zarządzania dostępem. Po przypisaniu czytnika danych obiektu blob usługi Storage można przyznać podwyższone uprawnienia do zapisu przy użyciu list ACL. Aby uzyskać więcej informacji, zobacz Jak jest oceniany dostęp.

Takie podejście faworyzuje scenariusze, w których większość użytkowników potrzebuje dostępu do odczytu, ale tylko kilku użytkowników potrzebuje dostępu do zapisu. Strefy data lake mogą być różnymi kontami magazynu, a zasoby danych mogą być różnymi kontenerami. Strefy data lake mogą być reprezentowane przez kontenery i zasoby danych reprezentowane przez foldery.

Podejścia grupy zagnieżdżonej listy kontroli dostępu

Istnieją dwa podejścia do zagnieżdżonych grup listy ACL.

Opcja 1. Nadrzędna grupa wykonywania

Przed utworzeniem plików i folderów rozpocznij od grupy nadrzędnej. Przypisz uprawnienia uruchamiania tej grupy do domyślnych list ACL i dostępu na poziomie kontenera. Następnie dodaj grupy, które wymagają dostępu do danych do grupy nadrzędnej.

Ostrzeżenie

Zalecamy użycie tego wzorca, w którym istnieją rekursywne usunięcia, a zamiast tego użyj opcji 2: lista kontroli dostępu innego wpisu.

Ta technika jest nazywana grupami zagnieżdżania. Grupa członków dziedziczy uprawnienia grupy nadrzędnej, która zapewnia globalne uprawnienia uruchamiania do wszystkich grup członkowskich. Grupa członków nie potrzebuje uprawnień do uruchamiania, ponieważ te uprawnienia są dziedziczone. Większe zagnieżdżanie może zapewnić większą elastyczność i elastyczność. Dodaj grupy zabezpieczeń reprezentujące zespoły lub zadania automatyczne do grup czytelników i modułów zapisywania dostępu do danych.

Diagram that shows nested groups where global run includes data assets for readers and writers and includes analysis team and engineering jobs.

Opcja 2. Lista kontroli dostępu innego wpisu

Zalecaną metodą jest użycie listy ACL innego wpisu ustawionego w kontenerze lub katalogu głównym. Określ wartości domyślne i listy ACL dostępu, jak pokazano na poniższym ekranie. Takie podejście zapewnia, że każda część ścieżki z katalogu głównego do najniższego poziomu ma uprawnienia do uruchamiania.

Screen capture that shows the manage access dialog box with other highlighted and access and default selected.

To uprawnienie przebiegu propaguje w dół do wszystkich dodanych folderów podrzędnych. Uprawnienie jest propagowane do głębokości, w której docelowa grupa dostępu potrzebuje uprawnień do odczytu i uruchamiania. Poziom znajduje się w najniższej części łańcucha, jak pokazano na poniższym ekranie. Takie podejście umożliwia grupie dostęp do odczytu danych. Podejście działa podobnie w przypadku dostępu do zapisu.

Screen capture that shows the manage access dialog box with businessgrp 1 highlighted and access and default selected.

Następujące zastosowania są zalecanymi wzorcami zabezpieczeń dla każdej ze stref typu data lake:

  • Nieprzetworzone powinny zezwalać na dostęp do danych tylko przy użyciu głównych nazw zabezpieczeń (SPN).
  • Wzbogacony powinien zezwalać na dostęp do danych tylko przy użyciu głównych nazw zabezpieczeń (SPN).
  • Wyselekcjonowane powinno zezwalać na dostęp z nazwami głównymi zabezpieczeń (SPN) i głównymi nazwami użytkowników (UPN).

Przykładowy scenariusz użycia grup zabezpieczeń firmy Microsoft Entra

Istnieje wiele różnych sposobów konfigurowania grup. Załóżmy na przykład, że masz katalog o nazwie /LogData zawierający dane dziennika generowane przez serwer. Usługa Azure Data Factory pozyskuje dane do tego folderu. Konkretni użytkownicy z zespołu inżynierów usług przekazują dzienniki i zarządzają innymi użytkownikami tego folderu. Klastry obszarów roboczych analizy i nauki o danych usługi Azure Databricks mogą analizować dzienniki z tego folderu.

Aby włączyć te działania, utwórz grupę LogsWriter i grupę LogsReader . Przypisz następujące uprawnienia:

  • Dodaj grupę LogsWriter do listy ACL /LogData katalogu z uprawnieniami rwx .
  • Dodaj grupę LogsReader do listy ACL /LogData katalogu z uprawnieniami r-x .
  • Dodaj do grupy obiekt jednostki usługi lub tożsamość usługi zarządzanej LogsWriters (MSI) dla usługi Data Factory.
  • Dodaj użytkowników w zespole inżynierów usług do LogsWriter grupy.
  • Usługa Azure Databricks jest skonfigurowana dla usługi Microsoft Entra passthrough do usługi Azure Data Lake Store.

Jeśli użytkownik w zespole inżynierów usług przenosi się do innego zespołu, po prostu usuń tego użytkownika z LogsWriter grupy.

Jeśli nie dodano tego użytkownika do grupy, ale zamiast tego dodano dedykowany wpis listy ACL dla tego użytkownika, musisz usunąć ten wpis listy ACL z /LogData katalogu. Należy również usunąć wpis ze wszystkich podkatalogów i plików w całej hierarchii katalogów katalogu /LogData .

Kontrola dostępu do danych usługi Azure Synapse Analytics

Aby wdrożyć obszar roboczy usługi Azure Synapse, wymagane jest konto usługi Azure Data Lake Storage Gen2. Usługa Azure Synapse Analytics używa podstawowego konta magazynu w kilku scenariuszach integracji i przechowuje dane w kontenerze. Kontener zawiera tabele platformy Apache Spark i dzienniki aplikacji w folderze o nazwie /synapse/{workspaceName}. Obszar roboczy używa również kontenera do zarządzania zainstalowanymi bibliotekami.

Podczas wdrażania obszaru roboczego za pośrednictwem witryny Azure Portal podaj istniejące konto magazynu lub utwórz nowe. Podane konto magazynu jest podstawowym kontem magazynu dla obszaru roboczego. Proces wdrażania udziela tożsamości obszaru roboczego dostępu do określonego konta usługi Data Lake Storage Gen2 przy użyciu roli Współautor danych obiektu blob usługi Storage.

Jeśli wdrożysz obszar roboczy poza witryną Azure Portal, ręcznie dodaj tożsamość obszaru roboczego usługi Azure Synapse Analytics do roli Współautor danych obiektu blob usługi Storage. Zaleca się przypisanie roli Współautor danych obiektu blob usługi Storage na poziomie kontenera, aby postępować zgodnie z zasadą najniższych uprawnień.

Po uruchomieniu potoków, przepływów pracy i notesów za pośrednictwem zadań używają kontekstu uprawnień tożsamości obszaru roboczego. Jeśli którekolwiek z zadań odczytuje lub zapisuje w magazynie podstawowym obszaru roboczego, tożsamość obszaru roboczego używa uprawnień odczytu/zapisu przyznanych za pośrednictwem współautora danych bloga magazynu.

Gdy użytkownicy loguje się do obszaru roboczego w celu uruchamiania skryptów lub programowania, uprawnienia kontekstu użytkownika zezwalają na dostęp do odczytu/zapisu w magazynie podstawowym.

Szczegółowa kontrola dostępu do danych w usłudze Azure Synapse Analytics przy użyciu list kontroli dostępu

Podczas konfigurowania kontroli dostępu do usługi Data Lake niektóre organizacje wymagają dostępu na poziomie szczegółowym. Mogą mieć poufne dane, które nie mogą być widoczne przez niektóre grupy w organizacji. Kontrola dostępu oparta na rolach platformy Azure umożliwia tylko odczyt lub zapis na koncie magazynu i na poziomie kontenera. Za pomocą list ACL można skonfigurować szczegółową kontrolę dostępu na poziomie folderu i pliku, aby umożliwić odczyt/zapis w podzestawie danych dla określonych grup.

Zagadnienia dotyczące korzystania z tabel platformy Spark

Gdy używasz tabel platformy Apache Spark w puli Platformy Spark, tworzy folder magazynu. Folder znajduje się w katalogu głównym kontenera w magazynie podstawowym obszaru roboczego:

synapse/workspaces/{workspaceName}/warehouse

Jeśli planujesz utworzyć tabele platformy Apache Spark w puli platformy Azure Synapse Spark, przyznaj uprawnienie do zapisu w folderze magazynu dla grupy, w której uruchomiono polecenie, które tworzy tabelę Spark. Jeśli polecenie jest uruchamiane przez wyzwolone zadanie w potoku, przyznaj uprawnienia do zapisu w pliku MSI obszaru roboczego.

W tym przykładzie zostanie utworzona tabela Platformy Spark:

df.write.saveAsTable("table01")

Aby uzyskać więcej informacji, zobacz Jak skonfigurować kontrolę dostępu dla obszaru roboczego usługi Synapse.

Podsumowanie dostępu do usługi Azure Data Lake

Żadne podejście do zarządzania dostępem do usługi Data Lake nie odpowiada wszystkim. Główną zaletą usługi Data Lake jest zapewnienie bezproblemowego dostępu do danych. W praktyce różne organizacje chcą różnych poziomów ładu i kontroli nad danymi. Niektóre organizacje mają scentralizowany zespół do zarządzania grupami dostępu i aprowizacji w ramach rygorystycznych mechanizmów kontroli wewnętrznych. Inne organizacje są bardziej zwinne i mają zdecentralizowaną kontrolę. Wybierz podejście spełniające poziom ładu. Wybór nie powinien skutkować nadmiernymi opóźnieniami lub tarciem w uzyskiwaniu dostępu do danych.

Następne kroki