Identitäts- und Zugriffsverwaltung
In diesem Artikel werden Entwurfspakete und -empfehlungen für die Identitäts- und Zugriffsverwaltung untersucht. Der Schwerpunkt liegt auf der Bereitstellung einer Analyseplattform auf Cloudebene in Microsoft Azure. Da es sich bei den Analysen auf Cloudebene um ein unternehmenskritisches Element handelt, sollten die Anleitungen zu den Entwurfsbereichen für Azure-Zielzonen auch in Ihren Entwurf einbezogen werden.
Dieser Artikel baut auf Überlegungen und Empfehlungen zu Azure-Zielzonen auf. Weitere Informationen finden Sie unter Identitäts- und Zugriffsverwaltung.
Entwurf der Datenzielzone
Cloud-Skalierungsanalysen unterstützen ein Zugriffssteuerungsmodell mit Microsoft Entra-Identitäten. Das Modell nutzt sowohl rollenbasierte Zugriffssteuerung (Azure RBAC) als auch Zugriffssteuerungslisten (ACLs).
Bewerten Sie die Administrations- und Verwaltungsaktivitäten in Azure, die Ihre Teams ausführen. Erwägen Sie Analysen auf Cloudebene in Azure. Ermitteln Sie die bestmögliche Verteilung der Zuständigkeiten innerhalb Ihres Unternehmens.
Rollenzuweisungen
Um Datenprodukte innerhalb der Datenplattform eigenständig zu entwickeln, bereitzustellen und zu nutzen, benötigen Datenanwendungsteams nur wenige Zugriffsrechte innerhalb der Azure-Umgebung. Beachten Sie, bevor Sie die jeweiligen RBAC-Anforderungen durchgehen, dass für die Entwicklung und für höhere Umgebungen verschiedene Zugriffsmodelle verwendet werden sollten. Außerdem sollten nach Möglichkeit Sicherheitsgruppen verwendet werden, um die Anzahl der Rollenzuweisungen zu verringern und die Verwaltung und Überprüfung der RBAC-Rechte zu vereinfachen. Dies ist aufgrund der begrenzten Anzahl von Rollenzuweisungen, die pro Abonnement erstellt werden können, wichtig.
Das Entwicklungsteam und deren jeweiligen Benutzeridentitäten sollten auf die Entwicklungsumgebung zugreifen dürfen, damit sie diese schneller durchlaufen können, bessere Einsicht in bestimmte Funktionen der Azure-Dienste erhalten und Probleme effektiver behandeln können. Durch den Zugriff auf eine Entwicklungsumgebung wird die Entwicklung oder Verbesserung der Infrastruktur als Code (IaC) und anderer Codeartefakte unterstützt. Sobald eine Implementierung in der Entwicklungsumgebung erwartungsgemäß funktioniert, kann sie kontinuierlich in die höheren Umgebungen eingeführt werden. Höhere Umgebungen, z. B. Test und Prod, sollten für das Datenanwendungsteam gesperrt werden. Nur ein Dienstprinzipal darf Zugriff auf diese Umgebungen haben und daher müssen alle Bereitstellungen über die Dienstprinzipalidentität mithilfe von CI/CD-Pipelines ausgeführt werden. Zusammenfassend sollten in der Entwicklungsumgebung Zugriffsrechte für einen Dienstprinzipal UND Benutzeridentitäten bereitgestellt werden, und in höheren Umgebungen sollten Zugriffsberechtigungen nur für eine Dienstprinzipalidentität bereitgestellt werden.
Damit Ressourcen und Rollenzuweisungen zwischen Ressourcen innerhalb der Ressourcengruppen der Datenanwendung erstellt werden können, müssen Contributor- und User Access Administrator-Rechte bereitgestellt werden. Dies ermöglicht es den Teams, innerhalb ihrer Umgebung und innerhalb der Grenzen von Azure Policy Dienste zu erstellen und zu steuern. Für Analysen auf Cloudebene wird die Verwendung privater Endpunkte empfohlen, um das Datenexfiltrationsrisiko zu überwinden. Da außerdem andere Konnektivitätsoptionen vom Azure-Plattformteam über Richtlinien blockiert werden sollten, benötigen Datenanwendungsteams Zugriffsberechtigungen für das freigegebene virtuelle Netzwerk einer Datenzielzone, um die erforderliche Netzwerkkonnektivität für die Dienste, die sie verwenden möchten, erfolgreich einrichten zu können. Da Analysen auf Cloudebene dem geringsten Berechtigungsprinzip folgen will, Konflikte zwischen verschiedenen Datenanwendungsteams vermeiden will und eine klare Trennung von Teams will, wird ein dediziertes Subnetz pro Datenanwendungsteam erstellt und eine Network Contributor-Rollenzuweisung zu diesem Subnetz (untergeordneter Ressourcenbereich) erstellt. Diese Rollenzuweisung ermöglicht es den Teams, sich über private Endpunkte mit dem Subnetz zu verknüpfen.
Diese beiden ersten Rollenzuweisungen ermöglichen die Self-Service-Bereitstellung von Datendiensten in diesen Umgebungen. Hinsichtlich der Kostenverwaltung sollten Organisationen den Ressourcengruppen ein Kostenstellen-Tag hinzufügen, um Weiterbelastungen und verteilte Kostenverantwortung zu ermöglichen. Dies erhöht das Bewusstsein innerhalb der Teams und erzwingt sie, die richtigen Entscheidungen hinsichtlich der erforderlichen SKUs und Dienstebenen zu treffen.
Um auch die Self-Service-Nutzung anderer freigegebener Ressourcen innerhalb der Datenzielzone zu ermöglichen, sind nur wenige zusätzliche Rollenzuweisungen erforderlich. Wenn der Zugriff auf eine Databricks-Umgebung erforderlich ist, sollten Organisationen die SCIM-Synchronisierung von Microsoft Entra ID verwenden, um Zugriff zu gewähren. Dies ist wichtig, da dieser Mechanismus Benutzer*innen und Gruppen automatisch von Microsoft Entra ID mit der Databricks-Datenebene synchronisiert und auch automatisch Zugriffsrechte entfernt, wenn eine Person die Organisation oder das Unternehmen verlässt. Dies könnte nicht der Fall sein, wenn separate Benutzerkonten in Azure Databricks verwendet werden. Datenanwendungsteams sollten dem Arbeitsbereich „Databricks“ in shared-product-rg und in shared-integration-rg hinzugefügt werden. In Azure Databricks sollten die Datenanwendungsteams Can Restart-Zugriffsberechtigungen für einen vordefinierten Cluster erhalten, um Workloads innerhalb des Arbeitsbereichs ausführen zu können.
Einzelne Teams benötigen Zugriff auf das zentrale Purview-Konto, um Datenressourcen innerhalb der jeweiligen Datenzielzonen zu ermitteln. Daher müssen die Teams als Data Reader zur Purview-Sammlung auf oberster Ebene hinzugefügt werden. Darüber hinaus erfordern die Teams in den meisten Fällen die Möglichkeit, katalogisierte Datenressourcen zu bearbeiten, für die sie verantwortlich sind, um zusätzliche Details wie Kontaktdetails von Datenbesitzern und Experten bereitzustellen, sowie genauere Details zu den Spalten in einem Dataset, welche eine Beschreibung und welche Informationen sie einschließen.
Zusammenfassung der rollenbasierten Zugriffssteuerungsanforderungen
Für die Automatisierung der Bereitstellung von Datenzielzonen benötigen Sie die folgenden Rollen:
Rollenname
BESCHREIBUNG
`Scope`
Stellen Sie alle privaten DNS-Zonen für alle Datendienste in einem einzigen Abonnement und einer Ressourcengruppe bereit. Der Dienstprinzipal muss Private DNS Zone Contributor in der globalen DNS-Ressourcengruppe sein, die während der Bereitstellung der Datenverwaltungszielzone erstellt wurde. Diese Rolle ist erforderlich, um A-Einträgen für die privaten Endpunkte bereitzustellen.
(Ressourcengruppenbereich) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Zum Einrichten des Peerings virtueller Netzwerke zwischen dem Datenzielzonennetzwerk und dem Zielzonennetzwerk der Datenverwaltung benötigt der Dienstprinzipal Network Contributor-Zugriffsrechte für die Ressourcengruppe des virtuellen Remotenetzwerks.
(Ressourcengruppenbereich) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Diese Berechtigung ist erforderlich, um die selbstgehostete Integration Runtime, die in der Ressourcengruppe integration-rg bereitgestellt wird, mit anderen Data Factorys zu teilen. Außerdem ist es erforderlich, den verwalteten Identitäten von Azure Data Factory und Azure Synapse Analytics Zugriff auf die jeweiligen Dateisysteme des Speicherkontos zuzuweisen.
(Ressourcenbereich) /subscriptions/{{dataLandingZone}subscriptionId}
Hinweis
Die Anzahl der Rollenzuweisungen kann in einem Produktionsszenario reduziert werden. Die Rollenzuweisung Network Contributor ist nur erforderlich, um das Peering virtueller Netzwerke zwischen der Datenverwaltungszielzone und der Datenzielzone einzurichten. Ohne diese Berücksichtigung funktioniert die DNS-Auflösung nicht. Der eingehende und ausgehende Datenverkehr wird getrennt, da keine Sichtverbindung zur Azure Firewall besteht.
Ein Private DNS Zone Contributor ist auch nicht erforderlich, wenn die Bereitstellung von DNS-A-Einträgen der privaten Endpunkte durch Azure-Richtlinien mit dem deployIfNotExists-Effekt automatisiert wird. Dasselbe gilt für den User Access Administrator, da die Bereitstellung mithilfe von deployIfNotExists-Richtlinien automatisiert werden kann.
Rollenzuweisungen für Datenprodukte
Die folgenden Rollenzuweisungen sind für die Bereitstellung eines Datenprodukts innerhalb einer Datenzielzone erforderlich:
Rollenname
BESCHREIBUNG
`Scope`
Stellen Sie alle privaten DNS-Zonen für alle Datendienste in einem einzigen Abonnement und einer Ressourcengruppe bereit. Der Dienstprinzipal muss Private DNS Zone Contributor in der globalen DNS-Ressourcengruppe sein, die während der Bereitstellung der Datenverwaltungszielzone erstellt wurde. Diese Rolle ist erforderlich, um A-Einträge für die jeweiligen privaten Endpunkte bereitzustellen.
(Ressourcengruppenbereich) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Stellen Sie alle Datenintegrationsstreamingdienste in einer einzelnen Ressourcengruppe innerhalb des Datenzielzonenabonnements bereit. Der Dienstprinzipal erfordert eine Contributor-Rollenzuweisung für diese Ressourcengruppe.
(Ressourcengruppenbereich) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Um private Endpunkte im angegebenen Private Link-Subnetz bereitzustellen, das während der Bereitstellung der Datenzielzone erstellt wurde, benötigt der Dienstprinzipal auf dieses Subnetz Zugriff als Network Contributor.
(Untergeordneter Ressourcenbereich) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Zugriff auf andere Ressourcen
Außerhalb von Azure erfordern Datenprodukt- und Datenintegrationsteams auch Zugriff auf ein Repository, um Codeartefakte zu speichern, effektiv zusammenzuarbeiten und Updates und Änderungen konsistent über CI/CD in höhere Umgebungen bereitzustellen. Darüber hinaus sollte ein Projekt-Board bereitgestellt werden, um agile Entwicklung, Sprintplanung, Nachverfolgung von Aufgaben sowie Benutzerfeedback- und Featureanfragen zu ermöglichen.
Schließlich erfordert die CI/CD-Automatisierung die Einrichtung einer Verbindung mit Azure, die in den meisten Diensten über Dienstprinzipien durchgeführt wird. Daher benötigen Teams Zugriff auf ein Dienstprinzip, um die Automatisierung innerhalb ihres Projekts zu erreichen.
Verwalten des Zugriffs auf Daten
Das Verwalten des Zugriffs auf Daten sollte mithilfe von Microsoft Entra-Gruppen erfolgen. Fügen Sie die Benutzerprinzipalnamen oder Dienstprinzipalnamen zu Microsoft Entra-Gruppen hinzu. Fügen Sie die Gruppen den Diensten hinzu, und erteilen Sie der Gruppe Berechtigungen. Dieser Ansatz ermöglicht eine feinkörnige Zugriffssteuerung.
Erwägen Sie für Dataprodukte in Azure Data Lakes die Verwendung von Zugriffssteuerungslisten (ACLs). Weitere Informationen finden Sie unter Zugriffssteuerungsmodell in Azure Data Lake Storage Gen2. Das Nutzen von Microsoft Entra-Passthrough mit Zugriffssteuerungslisten wird von den meisten nativen Azure-Diensten unterstützt, einschließlich von Azure Machine Learning, Azure Synapse SQL Serverless, Apache Spark für Azure Synapse und Azure Databricks.
Andere polyglotte Speicher werden wahrscheinlich für Analysen auf Cloudebene verwendet. Zu den Beispielen zählen Azure Database for PostgreSQL, Azure Database for MySQL, Azure SQL-Datenbank, SQL Managed Instance und dedizierte Pools unter Azure Synapse SQL. Sie können von Datenanwendungsteams verwendet werden, um Datenprodukte zu speichern.
- Verwenden von Microsoft Entra ID für die Authentifizierung mit Azure Database for PostgreSQL
- Verwenden der Microsoft Entra-Authentifizierung mit Azure SQL-Datenbank, SQL Managed Instance und Azure Synapse Analytics
- Verwenden von Microsoft Entra ID für die Authentifizierung mit Azure Database for MySQL
Es wird empfohlen, Microsoft Entra-Gruppen anstelle einzelner Microsoft Entra-Benutzerkonten zum Sichern von Datenbankobjekten zu verwenden. Diese Microsoft Entra-Gruppen werden zum Authentifizieren von Benutzer*innen verwendet und um Datenbankobjekte zu sichern. Ähnlich wie beim Data Lake-Muster können Sie das Onboarding Ihrer Domäne oder ihrer Datenprodukte verwenden, um diese Gruppen in Ihrem Microsoft Entra-Dienst zu erstellen.
Dieser Ansatz bietet auch einen einzigen Verwaltungsort und ermöglicht die Bewertung von Zugriffsrechten innerhalb der Azure Graph.
Weitere Informationen zum Erhöhen der Sicherheit für Datenverwaltungszielzonen und Datenzielzonen zur Verwaltung Ihres Datenbestands finden Sie unter Bereitstellen von Sicherheit für die Analyse auf Cloudebene in Azure.