Udostępnij za pośrednictwem


Zarządzanie tożsamościami i dostępem

W tym artykule opisano zagadnienia dotyczące projektowania i zalecenia dotyczące zarządzania tożsamościami i dostępem. Koncentruje się ona na wdrażaniu platformy analizy w skali chmury na platformie Microsoft Azure. Ponieważ analiza w skali chmury jest elementem o znaczeniu krytycznym, wskazówki dotyczące obszarów projektowych strefy docelowej platformy Azure powinny być również uwzględnione w projekcie.

W tym artykule omówiono zagadnienia i zalecenia dotyczące stref docelowych platformy Azure. Aby uzyskać więcej informacji, zobacz Zarządzanie tożsamościami i dostępem.

Projekt strefy docelowej danych

Analiza w skali chmury obsługuje model kontroli dostępu przy użyciu tożsamości firmy Microsoft Entra. Model używa zarówno kontroli dostępu na podstawie ról (RBAC) platformy Azure, jak i list kontroli dostępu (ACL).

Przejrzyj działania związane z administracją i zarządzaniem platformą Azure wykonywane przez zespoły. Rozważ analizę w skali chmury na platformie Azure. Określ najlepszą możliwą dystrybucję obowiązków w organizacji.

Przypisania ról

Aby tworzyć, dostarczać i obsługiwać produkty danych autonomicznie w obrębie platformy danych, zespoły aplikacji danych wymagają kilku praw dostępu w środowisku platformy Azure. Przed przejściem do odpowiednich wymagań kontroli dostępu opartej na rolach należy podkreślić, że w środowiskach deweloperskich i wyższych należy użyć różnych modeli dostępu. Ponadto grupy zabezpieczeń powinny być używane wszędzie tam, gdzie jest to możliwe, aby zmniejszyć liczbę przypisań ról i uprościć proces zarządzania i przeglądu praw RBAC. Ma to krytyczne znaczenie ze względu na ograniczoną liczbę przypisań ról, które można utworzyć na subskrypcję.

Środowisko deweloperskie powinno mieć dostęp do zespołu deweloperów i ich odpowiednich tożsamości użytkowników, aby umożliwić im szybsze iterowanie, dowiedz się więcej o niektórych możliwościach w usługach platformy Azure i skuteczniej rozwiąż problemy. Dostęp do środowiska deweloperskiego pomoże podczas opracowywania lub ulepszania infrastruktury jako kodu (IaC) i innych artefaktów kodu. Gdy implementacja w środowisku projektowym działa zgodnie z oczekiwaniami, można ją stale wdrażać w środowiskach wyższych. Wyższe środowiska, takie jak test i prod, powinny być zablokowane dla zespołu aplikacji danych. Tylko jednostka usługi powinna mieć dostęp do tych środowisk i dlatego wszystkie wdrożenia muszą być wykonywane za pośrednictwem tożsamości jednostki usługi przy użyciu potoków ciągłej integracji/ciągłego wdrażania. Podsumowując, w uprawnieniach dostępu do środowiska deweloperskiego należy podać tożsamości i tożsamości użytkowników jednostki usługi oraz w wyższych środowiskach prawa dostępu powinny być udostępniane tylko tożsamości jednostki usługi.

Aby można było tworzyć zasoby i przypisania ról między zasobami w grupach zasobów aplikacji danych i ContributorUser Access Administrator należy podać prawa. Umożliwi to zespołom tworzenie i kontrolowanie usług w ich środowisku w granicach usługi Azure Policy. Analiza w skali chmury zaleca użycie prywatnych punktów końcowych w celu przezwyciężenia ryzyka eksfiltracji danych i ponieważ inne opcje łączności powinny być blokowane przez zespół platformy Azure za pośrednictwem zasad, zespoły aplikacji danych będą wymagać praw dostępu do udostępnionej sieci wirtualnej strefy docelowej danych, aby móc pomyślnie skonfigurować wymaganą łączność sieciową dla usług, których planuje używać. Aby postępować zgodnie z zasadą najniższych uprawnień, należy przezwyciężyć konflikty między różnymi zespołami aplikacji danych i mieć wyraźną separację zespołów, analiza w skali chmury proponuje utworzenie dedykowanej podsieci dla zespołu aplikacji danych i utworzenie Network Contributor przypisania roli do tej podsieci (zakres zasobów podrzędnych). To przypisanie roli umożliwia zespołom dołączanie do podsieci przy użyciu prywatnych punktów końcowych.

Te dwa pierwsze przypisania ról umożliwią samoobsługowe wdrażanie usług danych w tych środowiskach. Aby rozwiązać problem z zarządzaniem kosztami, organizacje powinny dodać tag centrum kosztów do grup zasobów, aby umożliwić międzyładowanie i rozproszone własność kosztów. Zwiększa to świadomość w zespołach i wymusza podejmowanie odpowiednich decyzji w odniesieniu do wymaganych jednostek SKU i warstw usług.

Aby umożliwić również samoobsługowe korzystanie z innych zasobów udostępnionych w strefie docelowej danych, wymagane jest kilka dodatkowych przypisań ról. Jeśli wymagany jest dostęp do środowiska usługi Databricks, organizacje powinny używać narzędzia SCIM Synch from Microsoft Entra ID w celu zapewnienia dostępu. Jest to ważne, ponieważ ten mechanizm automatycznie synchronizuje użytkowników i grupy z identyfikatora Entra firmy Microsoft do płaszczyzny danych usługi Databricks, a także automatycznie usuwa prawa dostępu, gdy osoba opuszcza organizację lub firmę. Nie można tego zrobić, jeśli w usłudze Azure Databricks są używane oddzielne konta użytkowników. Zespoły aplikacji danych powinny zostać dodane do obszaru roboczego usługi Databricks w obszarze shared-product-rg i w obiekcie shared-integration-rg. W usłudze Azure Databricks zespoły aplikacji danych powinny mieć Can Restart prawa dostępu do wstępnie zdefiniowanego klastra, aby móc uruchamiać obciążenia w obszarze roboczym.

Poszczególne zespoły będą wymagać dostępu do centralnego konta usługi Purview w celu odnajdywania zasobów danych w odpowiednich strefach docelowych danych. W związku z tym zespoły będą musiały zostać dodane do Data Reader kolekcji najwyższego poziomu usługi Purview. Ponadto zespoły będą w większości przypadków wymagać opcji edytowania katalogowanych zasobów danych, które są ich właścicielami, aby udostępnić dodatkowe szczegóły, takie jak szczegóły kontaktowe właścicieli danych i ekspertów, a także bardziej szczegółowe informacje o tym, jakie kolumny w zestawie danych opisują i jakie informacje zawierają.

Podsumowanie wymagań dotyczących kontroli dostępu opartej na rolach

Do celów automatyzacji wdrażania stref docelowych danych potrzebne są następujące role:

Nazwa roli

opis

Scope

Wdróż wszystkie prywatne strefy DNS dla wszystkich usług danych w jednej subskrypcji i grupie zasobów. Jednostka usługi musi znajdować się Private DNS Zone Contributor w globalnej grupie zasobów DNS utworzonej podczas wdrażania strefy docelowej zarządzania danymi. Ta rola jest wymagana do wdrożenia rekordów A dla prywatnych punktów końcowych.

(Zakres grupy zasobów) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}

Aby skonfigurować komunikację równorzędną sieci wirtualnej między siecią docelową strefy danych i siecią strefy docelowej zarządzania danymi, jednostka usługi potrzebuje Network Contributor praw dostępu w grupie zasobów zdalnej sieci wirtualnej.

(Zakres grupy zasobów) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}

To uprawnienie jest wymagane do udostępniania własnego środowiska Integration Runtime, które zostanie wdrożone w integration-rg grupie zasobów z innymi fabrykami danych. Wymagane jest również przypisanie tożsamości zarządzanych usług Azure Data Factory i Azure Synapse Analytics w odpowiednich systemach plików kont magazynu.

(Zakres zasobów) /subscriptions/{{dataLandingZone}subscriptionId}

Uwaga

W scenariuszu produkcyjnym można zmniejszyć liczbę przypisań ról. Przypisanie Network Contributor roli jest wymagane tylko do skonfigurowania komunikacji równorzędnej sieci wirtualnej między strefą docelową zarządzania danymi a strefą docelową danych. Bez tego zagadnienia rozpoznawanie nazw DNS nie działa. Ruch przychodzący i wychodzący jest porzucony, ponieważ nie ma widoku do usługi Azure Firewall.

Nie Private DNS Zone Contributor jest to również wymagane, jeśli wdrożenie rekordów A DNS prywatnych punktów końcowych jest zautomatyzowane za pomocą zasad platformy Azure z zastosowaniem deployIfNotExists . To samo dotyczy User Access Administrator elementu , ponieważ wdrożenie można zautomatyzować przy użyciu deployIfNotExists zasad.

Przypisania ról dla produktów danych

Do wdrożenia produktu danych w strefie docelowej danych wymagane są następujące przypisania ról:

Nazwa roli

opis

Scope

Wdróż wszystkie prywatne strefy DNS dla wszystkich usług danych w jednej subskrypcji i grupie zasobów. Jednostka usługi musi znajdować się Private DNS Zone Contributor w globalnej grupie zasobów DNS utworzonej podczas wdrażania strefy docelowej zarządzania danymi. Ta rola jest wymagana do wdrożenia rekordów A dla odpowiednich prywatnych punktów końcowych.

(Zakres grupy zasobów) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

Wdróż wszystkie usługi przesyłania strumieniowego integracji danych w jednej grupie zasobów w ramach subskrypcji strefy docelowej danych. Jednostka usługi wymaga Contributor przypisania roli w tej grupie zasobów.

(Zakres grupy zasobów) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

Aby wdrożyć prywatne punkty końcowe w określonej podsieci usługi Private Link, która została utworzona podczas wdrażania strefy docelowej danych, jednostka usługi wymaga Network Contributor dostępu w tej podsieci.

(Zakres zasobów podrzędnych) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"

Dostęp do innych zasobów

Poza platformą Azure zespoły ds. produktów danych i Integracja danych będą również wymagać dostępu do repozytorium w celu przechowywania artefaktów kodu, efektywnej współpracy i wprowadzania aktualizacji oraz spójnego wprowadzania zmian za pośrednictwem ciągłej integracji/ciągłego wdrażania w wyższych środowiskach. Ponadto należy udostępnić tablicę projektu w celu umożliwienia elastycznego opracowywania, planowania przebiegu, śledzenia zadań oraz opinii użytkowników i żądań funkcji.

Na koniec automatyzacja ciągłej integracji/ciągłego wdrażania będzie wymagać skonfigurowania połączenia z platformą Azure, co odbywa się w większości usług za pośrednictwem zasad usługi. W związku z tym zespoły będą wymagać dostępu do jednostki usługi w celu osiągnięcia automatyzacji w ramach projektu.

Zarządzanie dostępem do danych

Zarządzanie dostępem do danych powinno odbywać się przy użyciu grup firmy Microsoft Entra. Dodaj nazwy główne lub nazwy główne usługi użytkownika do grup firmy Microsoft Entra. Dodaj grupy do usług i przyznaj grupie uprawnienia. Takie podejście umożliwia precyzyjną kontrolę dostępu.

W przypadku produktów danych w usłudze Azure Data Lake rozważ użycie list kontroli dostępu (ACL). Aby uzyskać więcej informacji, zobacz Model kontroli dostępu w usłudze Azure Data Lake Storage Gen2. Korzystanie z przekazywania microsoft Entra z listami kontroli dostępu jest obsługiwane przez większość natywnych usług platformy Azure, w tym Azure Machine Edukacja, Azure Synapse SQL Serverless, Apache Spark dla usług Azure Synapse i Azure Databricks.

Inne magazyny wielolotowe prawdopodobnie będą używane w analizie w skali chmury. Przykłady obejmują usługi Azure Database for PostgreSQL, Azure Database for MySQL, Azure SQL Database, SQL Managed Instance i Dedykowane pule usługi Azure Synapse SQL. Mogą być one używane przez zespoły aplikacji danych do przechowywania produktów danych.

Zalecamy używanie grup entra firmy Microsoft do zabezpieczania obiektów bazy danych zamiast pojedynczych kont użytkowników firmy Microsoft Entra. Te grupy entra firmy Microsoft są używane do uwierzytelniania użytkowników i pomagają chronić obiekty bazy danych. Podobnie jak w przypadku wzorca usługi Data Lake, możesz użyć dołączania do domeny lub produktów danych, aby utworzyć te grupy w ramach usługi Microsoft Entra.

Takie podejście zapewnia również jedną lokalizację zarządzania i umożliwia przeglądanie praw dostępu w usłudze Azure Graph.

Aby uzyskać więcej informacji na temat sposobu zwiększania zabezpieczeń stref docelowych zarządzania danymi i stref docelowych danych zarządzających infrastrukturą danych, zobacz Provision security for cloud-scale analytics in Azure (Aprowizuj zabezpieczenia na potrzeby analizy w skali chmury na platformie Azure).

Następne kroki