Identitäts- und Zugangsmanagement in der Zielzone

Nachdem Sie Ihre Identitätsarchitektur festgelegt haben, müssen Sie die Autorisierung und den Zugriff auf Ressourcen in Anwendungs- und Plattformlandezonen verwalten. Überlegen Sie, auf welche Ressourcen jeder authentifizierte Principal Zugriff hat und benötigt, und wie Sie das Risiko eines unbefugten Zugriffs auf Ihre Ressourcen mindern können. Weitere Informationen finden Sie unter Identity architecture design.

Übersicht

Der Designbereich für die Identitäts- und Zugriffsverwaltung bietet Anleitungen für die Implementierung des Unternehmenszugriffsmodells in Azure sowie für die Implementierung und Sicherung von Steuerungsebenen. Wenn Sie das Designprinzip der subscription democratization einbeziehen, kann Ihr Anwendungsteam seine eigenen Workloads innerhalb der vom Plattformteam festgelegten Richtlinien verwalten. Auch dieser Ansatz folgt dem Prinzip der policy-driven governance.

Das Plattformteam ist für die Bereitstellung neuer Anwendungslandezonen oder Abonnements zuständig. Bei der Bereitstellung einer Zielzone für einen Anwendungsinhaber sollte das Plattformteam diese mit den entsprechenden Zugriffskontrollen konfigurieren, damit der Anwendungsinhaber seine eigenen Ressourcen verwalten kann. Der Inhaber der Anwendung sollte in der Lage sein, Benutzer und Gruppen innerhalb von Microsoft Entra ID zu erstellen und zu verwalten und diesen Benutzern und Gruppen Rollen zuzuweisen. Der Inhaber der Anwendung kann dann den Zugriff auf seine eigenen Ressourcen verwalten und den Zugriff nach Bedarf an andere Benutzer und Gruppen delegieren. Die Zielzone sollte auch über eine optionale Netzwerkkonnektivität zu Active Directory Domain Services (AD DS) oder Microsoft Entra Domain Services im Rahmen des Microsoft Identity Platform-Abonnements verfügen, je nach den Anforderungen der Anwendung.

Verwenden Sie die rollenbasierte Zugriffskontrolle (RBAC) von Azure, um den administrativen Zugriff auf Azure-Ressourcen zu verwalten. Überlegen Sie, ob die Benutzer Berechtigungen für einen engen Bereich benötigen, wie z. B. einen Administrator für eine einzelne Anwendung, oder für einen breiten Bereich, wie z. B. einen Netzwerkadministrator für mehrere Anwendungs-Workloads. In jedem Fall sollten Sie den Grundsatz des „just enough access“ befolgen und sicherstellen, dass der Benutzer nur die für seine normalen Aktivitäten erforderlichen Rollen hat. Verwenden Sie bei Bedarf benutzerdefinierte Rollen und Microsoft Entra Privileged Identity Management (PIM), um Just-in-Time-Zugriff (JIT) zu erzwingen. Obwohl das Plattformteam für die Grundlage des Identitäts- und Zugriffsmanagements verantwortlich ist, sind sowohl die Plattform- als auch die Anwendungsteams Nutzer des Dienstes und sollten die gleichen Grundsätze befolgen.

Identitäts- und Zugriffsmanagement ist wichtig für die erfolgreiche Trennung einer Zielzone von einer anderen und die Isolierung von Workloads innerhalb einer Organisation. Dies ist ein kritischer Designbereich für die Zielzonen von Plattformen und Anwendungen.

Wenn Ihr Unternehmen einen Abonnement-Verkaufsprozess verwendet, können Sie viele der Identitäts- und Zugriffskonfigurationen für Anwendungslandezonen automatisieren. Implementieren Sie den Verkauf von Abonnements, um die Erstellung von Zielzonen zu standardisieren und damit Anwendungsteams ihre eigenen Ressourcen verwalten können.

Überlegungen zum Entwurf

In einigen Unternehmen werden Dienste von mehreren Anwendungen gemeinsam genutzt. Zum Beispiel könnte es einen zentralen Integrationsdienst geben, der von mehreren unabhängigen Anwendungen genutzt wird. In diesem Szenario sollten Sie überlegen, welche Dienste zentral verwaltet werden und welche an die Anwendungsteams delegiert werden, und sich darüber im Klaren sein, wo die Sicherheitsgrenzen durchgesetzt werden müssen. Den Anwendungsteams administrativen Zugriff auf den gemeinsamen Dienst zu gewähren, könnte für die Produktivität der Entwickler hilfreich sein, könnte aber auch mehr Zugriff als nötig bieten.

Die Verwaltung von Anwendungsressourcen, die keine Sicherheitsgrenzen überschreiten, kann an Anwendungsteams delegiert werden. Erwägen Sie, auch andere Aspekte zu delegieren, die zur Aufrechterhaltung von Sicherheit und Compliance erforderlich sind. Durch die Möglichkeit für Benutzer*innen, Ressourcen innerhalb einer sicher verwalteten Umgebung bereitzustellen, können Unternehmen die Agilitätsvorteile der Cloud nutzen und gleichzeitig die Verletzung kritischer Sicherheits- oder Governancegrenzen verhindern.

RBAC

Den Unterschied zwischen Microsoft Entra ID Rollen und Azure RBAC Rollen verstehen.

• Microsoft Entra ID-Rollen steuern die administrativen Berechtigungen für mandantenübergreifende Dienste wie Microsoft Entra ID und andere Microsoft-Dienste wie Microsoft Teams, Microsoft Exchange Online und Microsoft Intune.

• Azure RBAC Rollen steuern die administrativen Berechtigungen für Azure-Ressourcen wie virtuelle Maschinen, Abonnements und Ressourcengruppen.

• Die Rollen Azure RBAC Owner und User Access Administrator können die Rollenzuweisungen auf Azure-Ressourcen ändern. Standardmäßig hat die Rolle Microsoft Entra Global Administrator keine Berechtigung, den Zugriff auf Azure-Ressourcen zu verwalten. Es muss explizit aktiviert werden. Weitere Informationen finden Sie unter Erhöhen der Zugriffsrechte zum Verwalten aller Azure-Abonnements und Verwaltungsgruppen.

Das folgende Diagramm zeigt die Beziehung zwischen Microsoft Entra ID-Rollen und Azure RBAC-Rollen:

• Sie können rollenzuweisbare Gruppen erstellen und Microsoft Entra-Rollen zu den Gruppen zuweisen, wenn Sie die Eigenschaft isAssignableToRole auf true setzen. Nur Gruppen, die diese Eigenschaft haben, sind geschützt. Die einzigen Rollen, die die Mitgliedschaft einer Gruppe ändern können, sind globale Administratoren, Administratoren mit privilegierten Rollen oder der Inhaber der Gruppe.

• Nur einige Rollen können das Kennwort oder die Einstellungen für die Multifaktor-Authentifizierung (MFA) für einen anderen Administrator zurücksetzen. Diese Einschränkung verhindert, dass unbefugte Administratoren die Anmeldedaten eines Kontos mit höheren Rechten zurücksetzen, um mehr Berechtigungen zu erhalten.

• Wenn die integrierten Azure-Rollen die Anforderungen Ihrer Organisation nicht erfüllen, können Sie Ihre eigenen benutzerdefinierten Rollen erstellen. Genau wie bei den integrierten Rollen können Sie Benutzern, Gruppen und Dienstprinzipalen benutzerdefinierte Rollen auf der Ebene von Mandanten, Verwaltungsgruppen, Abonnements und Ressourcengruppen zuweisen. Verwenden Sie nach Möglichkeit die in Azure integrierten Rollen und erstellen Sie nur bei Bedarf eigene Rollen.

• Wenn Sie Ihre Zugriffskontrollstrategie entwerfen, sollten Sie die Servicegrenzen für Rollen, Rollenzuweisungen und benutzerdefinierte Rollen kennen.

• Einige Azure RBAC-Rollen unterstützen attributbasierte Zugriffskontrolle (ABAC) oder Rollenzuweisungsbedingungen. Wenn Sie Bedingungen verwenden, können Administratoren Rollen dynamisch auf der Grundlage der Attribute der Ressource zuweisen. Sie können z. B. die Rolle Storage Blob Data Contributor zuweisen, aber nur für Blobs, die ein bestimmtes Index-Tag haben, und nicht für alle Blobs in einem Container.

Entwurfsempfehlungen

Allgemeine Empfehlungen

• Erzwingen Sie Microsoft Entra-Multifaktor-Authentifizierung (MFA) für Benutzer, die Rechte für die Azure-Umgebung haben, einschließlich des Plattform-Abonnements, des Anwendungs-Abonnements und des Microsoft Entra ID-Mandanten. In vielen Regelwerken ist die Durchsetzung der MFA vorgeschrieben. MFA trägt dazu bei, das Risiko des Diebstahls von Anmeldeinformationen und des unbefugten Zugriffs zu verringern. Um unbefugten Zugriff auf sensible Informationen zu verhindern, sollten Sie sicherstellen, dass Sie Benutzer mit Leserrollen in MFA-Richtlinien aufnehmen.

• Verwenden Sie Microsoft Entra Conditional Access-Richtlinien für Benutzer, die Rechte in der Azure-Umgebung haben. Conditional Access ist eine weitere Funktion, die dazu beiträgt, eine kontrollierte Azure-Umgebung vor unberechtigtem Zugriff zu schützen. Anwendungs- und Plattformadministratoren sollten über Richtlinien für den bedingten Zugriff verfügen, die das Risikoprofil ihrer Rolle widerspiegeln. So kann es beispielsweise erforderlich sein, dass Sie administrative Tätigkeiten nur von bestimmten Standorten oder Arbeitsplätzen aus durchführen können. Oder die Risikotoleranz bei der Anmeldung für Benutzer mit administrativem Zugriff auf Azure-Ressourcen könnte niedriger sein als bei normalen Microsoft Entra ID-Benutzern.

• Aktivieren Sie Microsoft Defender for Identity, um Benutzeridentitäten zu schützen und Benutzeranmeldeinformationen zu sichern. Defender for Identity ist Teil von Microsoft Defender XDR. Sie können Defender for Identity verwenden, um verdächtige Benutzeraktivitäten zu identifizieren und Zeitpläne für Vorfälle zu erstellen. Sie können es auch mit Conditional Access verwenden, um Authentifizierungsversuche mit hohem Risiko zu verweigern. Stellen Sie Defender für Identitätssensoren auf lokalen Domänencontrollern und Domänencontrollern im Azure-Identitätsabonnement bereit.

• Verwenden Sie Microsoft Sentinel, um Threat Intelligence und Ermittlungsfunktionen bereitzustellen. Sentinel verwendet Protokolle von Azure Monitor Logs, Microsoft Entra ID, Microsoft 365 und anderen Diensten, um proaktiv Bedrohungen zu erkennen, zu untersuchen und darauf zu reagieren.

• Trennen Sie den administrativen Zugriff von nicht-administrativen, alltäglichen Zugriffen wie Web-Browsing und E-Mail-Zugriff. Web und E-Mail sind häufige Angriffsvektoren. Wenn ein Benutzerkonto kompromittiert wird, ist es weniger wahrscheinlich, dass es zu einem Sicherheitsverstoß kommt, wenn das Konto nicht für den administrativen Zugriff verwendet wird.

  • Verwenden Sie separate, nur in der Cloud verfügbare Konten für privilegierte Rollen. Verwenden Sie für den täglichen Gebrauch nicht dasselbe Konto, das Sie für die privilegierte Verwaltung verwenden. Privilegierte Microsoft Entra ID und Azure RBAC-Rollen sind im Azure-Portal und in der Dokumentation als PRIVILEGED gekennzeichnet.

  • Für nicht privilegierte Job-Funktionsrollen, die Azure-Anwendungsressourcen verwalten können, sollten Sie überlegen, ob Sie separate administrative Konten benötigen oder Microsoft Entra PIM verwenden, um den administrativen Zugriff zu steuern. PIM stellt sicher, dass das Konto nur dann über die erforderlichen Berechtigungen verfügt, wenn diese benötigt werden, und dass die Berechtigungen entfernt werden, wenn die Aufgabe abgeschlossen ist (auch bekannt als just-in-time access).

• Um die Rollenzuweisung überschaubarer zu gestalten, sollten Sie den Benutzern keine Rollen direkt zuweisen. Weisen Sie stattdessen Gruppen Rollen zu, um die Anzahl der Rollenzuweisungen zu minimieren, die für jedes Abonnement auf begrenzt ist.

  • Verwenden Sie Microsoft Entra PIM für Gruppen, um just-in-time administrative Zugriffskontrollen auf privilegierte Benutzer anzuwenden. Erwägen Sie die Kontrolle der Gruppenmitgliedschaft mit entitlement management. Sie können die Funktion zur Verwaltung von Berechtigungen verwenden, um Genehmigungs- und Audit-Workflows zu Gruppenmitgliedschaftsvorgängen hinzuzufügen und sicherzustellen, dass administrative Gruppenmitglieder nicht unnötig hinzugefügt oder entfernt werden.
  • Wenn Sie Zugriff auf Ressourcen gewähren, verwenden Sie für Azure Control-Plane-Ressourcen ausschließlich Microsoft Entra-Gruppen. Sowohl reine Entra-Benutzer und -Gruppen als auch solche, die mit Microsoft Entra Connect aus dem Unternehmen synchronisiert wurden, können zu einer reinen Entra-Gruppe hinzugefügt werden. Fügen Sie lokale Gruppen der reinen Microsoft Entra-Gruppe hinzu, wenn bereits ein Gruppenverwaltungssystem vorhanden ist. Die Verwendung von Entra-only-Gruppen hilft, die Cloud-Kontrollebene vor unbefugten Änderungen der lokalen Verzeichnisdienste zu schützen. Beachten Sie, dass nur Microsoft Entra auch als nur Cloud bezeichnet wird.

• Erstellen Sie Notfallzugriffskonten oder Break-Glass-Konten, um zu verhindern, dass Sie versehentlich aus Ihrer Microsoft Entra ID Organisation ausgesperrt werden. Notfallzugriffskonten sind hoch privilegiert und werden nur bestimmten Personen zugewiesen. Bewahren Sie die Anmeldedaten für die Konten sicher auf, überwachen Sie ihre Verwendung und testen Sie sie regelmäßig, um sicherzustellen, dass Sie sie im Katastrophenfall verwenden können.

  Weitere Informationen finden Sie unter Sichere Zugriffspraktiken für Administratoren in Microsoft Entra ID.

Microsoft Entra ID Empfehlungen

• Integrieren Sie Microsoft Entra ID mit Azure Monitor, damit Sie Ihre Anmeldeaktivitäten und den Prüfpfad von Änderungen innerhalb Ihres Tenants analysieren können. Konfigurieren Sie eine Diagnoseeinstellung, um Anmeldeprotokolle und Audit-Protokolle an den zentralen Azure Monitor Logs-Arbeitsbereich der Plattform im Verwaltungsabonnement zu senden.

• Nutzen Sie die Berechtigungsmanagement-Funktion von Microsoft Entra ID Governance, um Zugriffspakete zu erstellen, die die Gruppenmitgliedschaft durch automatische Genehmigungsprozesse und regelmäßige Zugriffsüberprüfungen für privilegierte Gruppenmitglieder kontrollieren.

• Verwenden Sie Microsoft Entra integrierte Rollen, um die folgenden Identitätseinstellungen auf Mandantenebene zu verwalten:

  Rolle	Beschreibung	Hinweis
  Globaler Administrator	Verwaltet alle Aspekte von Microsoft Entra ID und Microsoft-Diensten, die Microsoft Entra Identitäten verwenden.	Weisen Sie dieser Rolle nicht mehr als fünf Personen zu.
  Hybrididentitätsadministrator	Verwaltet die Cloud-Bereitstellung von Active Directory zu Microsoft Entra ID und verwaltet außerdem Microsoft Entra Connect, Microsoft Entra Pass-Through-Authentifizierung, Microsoft Entra Passwort-Hash-Synchronisierung, Microsoft Entra Seamless Single Sign-On (SSO) und Federation-Einstellungen.
  Sicherheitsadministrator	Liest Sicherheitsinformationen und Berichte und verwaltet Konfigurationen in Microsoft Entra ID und Microsoft 365.
  Anwendungsadministrator	Erstellt und verwaltet alle Aspekte von App-Registrierungen und Unternehmensanwendungen.	Sie können keine mandantenübergreifende administrative Zustimmung erteilen.

• Weisen Sie einer höher privilegierten Rolle keine Aufgabe zu, die eine niedriger privilegierte Rolle erledigen kann. Weisen Sie zum Beispiel die Rolle Benutzeradministrator zu, um Benutzer zu verwalten, nicht die Rolle Globaler Administrator. Weitere Informationen finden Sie unter Microsoft Entra built-in roles permissions.

• Verwenden Sie administrative Einheiten, um eine Gruppe von Administratoren einzuschränken, damit sie nur bestimmte Objekte in Ihrem Mandanten verwalten können. Sie können Verwaltungseinheiten verwenden, um die Verwaltung einer Teilmenge des Verzeichnisses zu delegieren. Sie können zum Beispiel die Verwaltung eines Service Desks an eine einzelne Geschäftseinheit innerhalb eines größeren Unternehmens delegieren.

  Verwaltungseinheiten können auch dazu beitragen, die Notwendigkeit separater Microsoft Entra ID-Tenants als Sicherheitsgrenze zu beseitigen, wenn separate Teams die Microsoft 365-Plattform und die Azure-Plattform in derselben Organisation verwalten. Sie können zum Beispiel administrative Einheiten verwenden, um die Verwaltung von Azure-Anwendungssicherheitsprinzipien an das Anwendungsteam zu delegieren, ohne Rechte für den gesamten Microsoft Entra ID-Tenant zu gewähren.

• Verwenden Sie Verwaltungseinheiten mit eingeschränktem Zugang, um weiteren Schutz zu bieten. Verhindern Sie, dass andere Personen als eine bestimmte Gruppe von Administratoren, die Sie festlegen, bestimmte Objekte ändern. Beispielsweise könnten Ihre Richtlinien zur Funktionstrennung erfordern, dass Sie diese Funktion verwenden, um zu verhindern, dass jemand ein bestimmtes Benutzerkonto ändern kann, selbst Benutzer mit der Rolle Benutzeradministrator. Diese Einschränkung ist nützlich für Dienstkonten, die von Anwendungen verwendet werden und die selbst von Administratoren nicht geändert werden sollten. Sie können auch eine Eskalation der Rechte verhindern, z. B. wenn jemand ein Benutzerkonto oder eine Gruppe ändert, die über Plattform- oder Landing-Zone-Administrationsrechte verfügt.

Empfehlungen für Azure RBAC

• Um die Verwaltung zu vereinfachen und das Risiko von Fehlkonfigurationen zu verringern, sollten Sie die Rollen und Rollenzuweisungen in allen Zielzonen der Anwendungen standardisieren. Wenn Sie beispielsweise eine Rolle haben, die Benutzer mit der Verwaltung virtueller Maschinen beauftragt, verwenden Sie dieselbe Rolle in allen Anwendungslandezonen. Dieser Ansatz vereinfacht auch die Verlagerung von Ressourcen zwischen Zielzonen.

• Verwenden Sie nach Möglichkeit Azure RBAC, um den Zugriff auf Ressourcen auf Datenebene zu verwalten. Beispiele für Endpunkte der Datenebene sind Azure Key Vault, ein Speicherkonto oder eine SQL-Datenbank.

• Stellen Sie sicher, dass die Arbeitsbereiche von Azure Monitor Logs mit dem entsprechenden Berechtigungsmodell konfiguriert sind. Wenn Sie einen zentralisierten Azure Monitor Logs-Arbeitsbereich verwenden, verwenden Sie Ressourcenberechtigungen, um sicherzustellen, dass Anwendungsteams Zugriff auf ihre eigenen Protokolle haben, aber nicht auf Protokolle anderer Teams.

Integrierte Rollen

• Überlegen Sie, ob integrierte Rollen für Ihre Anforderungen geeignet sind. In vielen Fällen können Sie einer Sicherheitsgruppe mehrere integrierte Rollen zuweisen, um einem Benutzer den entsprechenden Zugriff zu gewähren. Manchmal ist es jedoch nicht möglich, integrierte Rollen zu verwenden und gleichzeitig den Zugriff mit den geringsten Rechten zu gewährleisten, da die Rollen möglicherweise Berechtigungen enthalten, die die Anforderungen Ihrer Benutzer übersteigen. Wenn Sie eine genauere Kontrolle wünschen, können Sie eine benutzerdefinierte Rolle erstellen, die die für eine bestimmte Funktion erforderlichen Berechtigungen enthält. Weitere Informationen finden Sie unter Rollenbasierte Autorisierung bereitstellen.

• Viele in Azure integrierte Rollen bieten vordefinierte Rollenzuweisungen auf Plattform- und Ressourcenebene. Wenn Sie mehrere Rollenzuweisungen kombinieren, bedenken Sie die Gesamtwirkung.

• Der Zielzonenbeschleuniger von Azure (Landing Zone Accelerator) umfasst mehrere benutzerdefinierte Rollen für allgemeine Verwaltungsfunktionen. Sie können diese Rollen neben den in Azure integrierten Rollen verwenden. In der folgenden Tabelle werden die benutzerdefinierten administrativen Rollen oder Bereiche für den Azure Landing Zone Accelerator beschrieben:

  Administrative Rolle oder Bereich	Beschreibung	Aktionen	NotActions
  Azure Platform Owner (z. B. die integrierte Owner-Rolle)	Verwaltet Verwaltungsgruppen und Abonnement-Lebenszyklen	*
  Besitzer des Abonnements	Delegierte Rolle für den Abonnementbesitzer	*	Microsoft.Authorization/*/write, Microsoft.Network/vpnGateways/*, Microsoft.Network/expressRouteCircuits/*, Microsoft.Network/routeTables/write, Microsoft.Network/vpnSites/*
  Anwendungsinhaber (DevOps, Anwendungsbetrieb)	Mitwirkende Rolle für das Anwendungs- oder Betriebsteam im Rahmen des Abonnements	*	Microsoft.Authorization/*/write, Microsoft.Network/publicIPAddresses/write, Microsoft.Network/virtualNetworks/write, Microsoft.KeyVault/locations/deletedVaults/purge/action
  Netzwerkverwaltung (NetOps)	Verwaltet plattformweite globale Konnektivität, wie virtuelle Netzwerke, UDRs, NSGs, NVAs, VPNs, Azure ExpressRoute und andere	*/read, Microsoft.Network/*, Microsoft.Resources/deployments/*, Microsoft.Support/*
  SecOps	Rolle des Sicherheitsadministrators mit einer horizontalen Übersicht über den gesamten Azure-Bestand und die Bereinigungsrichtlinie für den Key Vault	*/read, */register/action, Microsoft.KeyVault/locations/deletedVaults/purge/action, Microsoft.PolicyInsights/*, Microsoft.Authorization/policyAssignments/*, Microsoft.Authorization/policyDefinitions/*, Microsoft.Authorization/policyExemptions/*, Microsoft.Authorization/policySetDefinitions/*, Microsoft.Insights/alertRules/*, Microsoft.Resources/deployments/*, Microsoft.Security/*, Microsoft.Support/*

  Diese Rollen benötigen je nach Verantwortungsmodell möglicherweise weitere Rechte. In einigen Organisationen muss eine NetOps-Rolle z. B. nur die globale Konnektivität verwalten und konfigurieren. In Unternehmen, die einen stärker zentralisierten Ansatz benötigen, können Sie die NetOps-Rolle um mehr zulässige Aktionen erweitern, z. B. um die Einrichtung von Peering zwischen Hubs und ihren Speichen.

Rollenzuweisungen und Gruppen

• Wenn das Plattformteam eine Anwendungslandezone einrichtet, sollte es sicherstellen, dass alle erforderlichen Identitäts- und Zugriffsverwaltungsobjekte erstellt werden, wie z. B. Sicherheitsgruppen, Standardrollenzuweisungen und vom Benutzer zugewiesene verwaltete Identitäten.

• Erstellen Sie Landing-Zone-Rollenzuweisungen auf der Ebene des Abonnements oder der Ressourcengruppe. Azure-Richtlinienzuweisungen erfolgen auf der Ebene der Verwaltungsgruppe, daher sollten Sie Zielzonen-Rollenzuweisungen auf einer niedrigeren Ebene bereitstellen. Verwenden Sie diesen Ansatz, um sicherzustellen, dass Zielzonen-Administratoren volle Autonomie über ihre Ressourcen haben, aber die Azure-Richtlinienzuweisungen, die ihre Zielzone regeln, nicht ändern können.

• Jede Anwendungslandezone sollte ihre eigenen Gruppen und Rollenzuweisungen haben. Erstellen Sie keine allgemeinen Gruppen und ordnen Sie sie nicht mehreren Zielzonen zu. Dieser Ansatz kann zu Fehlkonfigurationen und Sicherheitsverletzungen führen und ist in großem Umfang schwer zu verwalten. Wenn ein Benutzer Zugang zu mehreren Zielzonen benötigt, ordnen Sie ihn den entsprechenden Gruppen in jeder Zielzone zu. Verwenden Sie ID Governance, um ihre Gruppenmitgliedschaft zu verwalten.

• Weisen Sie die Rollen den Gruppen zu, nicht den Benutzern. Auf diese Weise können Sie sicherstellen, dass die Benutzer die richtigen Berechtigungen haben, wenn sie Ihrem Unternehmen beitreten oder es verlassen. Es hilft auch sicherzustellen, dass die Benutzer die richtigen Berechtigungen haben, wenn sie zwischen Teams wechseln. Wenn beispielsweise ein Benutzer vom Netzwerkteam zum Sicherheitsteam wechselt, sollten Sie ihn aus der Netzwerkgruppe entfernen und der Sicherheitsgruppe hinzufügen. Wenn Sie einem Benutzer eine Rolle direkt zuweisen, behält er diese Rolle auch nach einem Wechsel in ein anderes Team. Verwenden Sie ID Governance zur Verwaltung der Gruppenmitgliedschaft, anstatt Gruppenmitglieder manuell hinzuzufügen oder zu entfernen.

• Behalten Sie getrennte Sicherheitskonfigurationen für verschiedene Umgebungen der gleichen Anwendung bei, z. B. für Entwicklung/Test und Produktion. Erstellen Sie für jede Umgebung separate Gruppen und Rollenzuweisungen. Verwaltete Identitäten oder Dienstprinzipien dürfen nicht in verschiedenen Umgebungen gemeinsam genutzt werden. Behandeln Sie jede Umgebung als eine separate Zielzone. Dieser Ansatz trägt dazu bei, die Isolierung zwischen Entwicklung/Test und Produktion zu gewährleisten und den Prozess der Anwendungsbereitstellung zwischen Umgebungen zu standardisieren. Wenn dieselbe Person Zugang zu mehreren Zielzonen benötigt, sollten Sie sie den entsprechenden Gruppen in jeder Zielzone zuordnen.

• Überlegen Sie, ob Plattformadministratoren Berechtigungen für Anwendungslandezonen benötigen. Wenn dies der Fall ist, verwenden Sie Microsoft Entra PIM, um den Zugriff auf diese Ressourcen zu kontrollieren, und vergeben Sie die am wenigsten privilegierten Berechtigungen, die erforderlich sind. Ein Plattformadministrator könnte zum Beispiel Zugang zu einer bestimmten Anwendungslandezone benötigen, um ein Problem zu beheben, sollte aber keinen routinemäßigen Zugriff auf die Anwendungsdaten oder den Code haben. In diesem Fall kann der Plattformadministrator den Zugriff auf die Anwendung beantragen. Ein Administrator mit privilegierter Rolle genehmigt den Antrag, und der Plattformadministrator erhält die erforderlichen Berechtigungen für den angegebenen Zeitraum. Dieser Ansatz hilft, die Aufgabentrennung durchzusetzen und schützt die Zielzonen von Anwendungen vor versehentlicher oder böswilliger Fehlkonfiguration.

• Wenn Sie administrative Verantwortung an andere delegieren, z. B. an Anwendungsteams, sollten Sie überlegen, ob diese alle oder nur eine Teilmenge der Berechtigungen benötigen. Befolgen Sie das Prinzip der geringsten Rechte. So können Sie beispielsweise einem Benutzer, der den Zugriff auf Azure-Ressourcen, nicht aber die Ressourcen selbst verwalten muss, die Rollen User Access Administrator oder RBAC Administrator zuweisen. Um die Identitäten, Identitätstypen und Rollen einzuschränken, an die sie Azure RBAC-Zuweisungen delegieren und zuweisen können, verwenden Sie delegierte Rollenzuweisungen mit Bedingungen. Bedingungen ermöglichen es den Anwendungsteams, ihre eigenen Sicherheitsprinzipien innerhalb der vom Plattformteam festgelegten Grenzen zu verwalten. Privilegiertere Rollenzuweisungen erfordern eine Eskalation an das Plattformteam.

• Die folgende Tabelle zeigt eine beispielhafte Rollenzuweisungsstruktur für eine Azure-Landing-Zone-Umgebung. Es bietet ein ausgewogenes Verhältnis zwischen Sicherheit und einfacher Verwaltung. Sie können die Struktur an die Anforderungen Ihres Unternehmens anpassen. Sie können ein und dieselbe Person je nach ihrer Rolle innerhalb des Unternehmens mehreren Gruppen zuordnen. Sie sollten die RBAC-Zuweisungen jedoch auf eine bestimmte Gruppe innerhalb einer bestimmten Landingzone anwenden.

  Resource	Benutzer	Rollenzuweisung	Ziel der Zuweisung	Erläuterungen zum Bereich in Azure Policy
  Application X Zielzone	Application X Inhaber	Application Owner (benutzerdefiniert, in Azure Zielzone Accelerator enthalten)	Application X Admins Sicherheitsgruppe	Application X Produktions- und Entwicklungs-/Test-Abonnements
  Application X Zielzone	Application X Inhaber	Application Access Administrator (benutzerdefiniert, mit Rollenzuweisungsbedingungen zur Verwaltung des Zugriffs auf die eigene Anwendung)	Application X Admins Sicherheitsgruppe	Application X Produktions- und Entwicklungs-/Test-Abonnements
  Application X Zielzone	Application X Datenverwalter	Data Administrator (benutzerdefiniert, mit Berechtigungen für die erforderlichen Datenressourcen)	Application X Data Team Sicherheitsgruppe	Application X Produktions- und Entwicklungs-/Test-Abonnements
  Application Y Zielzone	Application Y Inhaber	Application Owner (benutzerdefiniert, in Azure Zielzone Accelerator enthalten)	Application Y Admins Sicherheitsgruppe	Application Y Produktions- und Entwicklungs-/Test-Abonnements
  Application Y Zielzone	Application Y Testteam	Test Contributor (benutzerdefiniert, mit den für Anwendungstests erforderlichen Berechtigungen)	Application Y Test Team Sicherheitsgruppe	Application Y dev/test Abonnement
  Sandbox	Application Z Entwicklungsteam	Besitzer (integriert)	Application Z developers Sicherheitsgruppe	Application Z-Ressourcengruppen im Sandbox-Abonnement
  Ressourcen der Plattform	Managementteam der Plattform	Mitwirkender (integriert)	Platform AdminsPIM-Gruppe	Platform Managementgruppe
  Plattform-Landing-Zone	Managementteam der Plattform	Leser (integriert)	Platform Team Sicherheitsgruppe	Organisatorische Führungsgruppe auf höchster Ebene
  Mandantenübergreifend	Sicherheitsteam	Sicherheitsoperationen (benutzerdefiniert, enthalten in Azure Zielzone Accelerator)	Security Ops Sicherheitsgruppe	Organisatorische Führungsgruppe auf höchster Ebene
  Mandantenübergreifend	Sicherheitsteam	Administrator für bedingten Zugriff (integriert, mit aktivierten geschützten Aktionen)	Security administrators Sicherheitsgruppe	Microsoft Entra ID-Mandant
  Mandantenübergreifend	Netzwerkteam	Netzwerkbetrieb (benutzerdefiniert, enthalten in Azure Zielzone Accelerator)	Network Ops Sicherheitsgruppe	Alle Abonnements
  Mandantenübergreifend	FinOps-Team	Rechnungsleser (eingebaut)	FinOps Team Sicherheitsgruppe	Organisatorische Führungsgruppe auf höchster Ebene

• Azure Policy-Zuweisungen mit der Wirkung DeployIfNotExistserfordern eine verwaltete Identität, um nicht konforme Ressourcen zu beheben. Wenn Sie eine vom System zugewiesene verwaltete Identität als Teil des Azure-Richtlinienzuweisungsprozesses verwenden, gewährt Azure automatisch die erforderlichen Berechtigungen. Wenn Sie eine dem Benutzer zugewiesene verwaltete Identität verwenden, müssen die Berechtigungen manuell erteilt werden. Die Zuweisung der verwalteten Identitätsrollen muss dem Prinzip der geringsten Berechtigung folgen und nur die Berechtigungen zulassen, die zur Durchführung der Richtlinienanpassung im Zielbereich erforderlich sind. Verwaltete Identitäten zur Richtlinienwiederherstellung unterstützen keine benutzerdefinierten Rollendefinitionen. Rollenzuweisungen direkt auf verwaltete Identitäten anwenden, nicht auf Gruppen.

Microsoft Entra PIM Empfehlungen

• Verwenden Sie Microsoft Entra PIM, um das Zero-Trust-Modell und den Zugriff mit geringsten Rechten einzuhalten. Ordnen Sie die Rollen in Ihrem Unternehmen den erforderlichen Mindestzugriffsebenen zu. In Microsoft Entra PIM können Sie Azure-eigene Tools verwenden, bestehende Tools und Prozesse erweitern oder bei Bedarf sowohl bestehende als auch native Tools verwenden.

• Verwenden Sie Microsoft Entra PIM Zugriffsüberprüfungen zur regelmäßigen Überprüfung von Ressourcenberechtigungen. Zugriffsüberprüfungen sind Teil vieler Complianceframeworks, weshalb viele Organisationen bereits über ein Verfahren zur Zugriffsüberprüfung verfügen.

• Verwenden Sie privilegierte Identitäten für Automatisierungs-Runbooks, die erhöhte Zugriffsberechtigungen erfordern, oder für privilegierte Bereitstellungspipelines. Sie können für automatisierte Workflows, die auf kritische Sicherheitsgrenzen zugreifen, dieselben Tools und Richtlinien verwenden, die Sie auch für Benutzer mit denselben Berechtigungen einsetzen. Automatisierungs- und Bereitstellungspipelines für Anwendungsteams sollten über Rollenzuweisungen verfügen, die verhindern, dass ein Anwendungsinhaber seine eigenen Berechtigungen ausweiten kann.

• Kontrollieren Sie hochprivilegierte Azure RBAC-Rollen, wie z. B. Inhaber oder Benutzerzugriffsadministratoren, die Mitgliedern von Plattform- oder Anwendungslandezonen-Teams in einer Abonnement- oder Verwaltungsgruppe zugewiesen sind. Verwenden Sie Microsoft Entra PIM für Gruppen, um Azure RBAC-Rollen so zu konfigurieren, dass sie den gleichen Erhöhungsprozess wie Microsoft Entra ID-Rollen erfordern.

  So kann ein Benutzer beispielsweise routinemäßig einen begrenzten administrativen Zugriff auf Ressourcen in einer Anwendungslandezone benötigen. Gelegentlich können sie die Rolle des Inhabers erfordern. Sie können zwei Sicherheitsgruppen erstellen: Anwendungsadministratoren und Anwendungsinhaber. Weisen Sie die Rollen mit den geringsten Rechten der Gruppe der Anwendungsadministratoren zu, und weisen Sie die Inhaberrolle der Rolle der Anwendungsinhaber zu. Verwenden Sie PIM-Gruppen, damit der Benutzer bei Bedarf die Rolle des Inhabers anfordern kann. Zu allen anderen Zeiten hat der Benutzer nur die Berechtigungen, die er für seine typischen Aktivitäten benötigt.

• Verwenden Sie geschützte Aktionen mit Microsoft Entra PIM, um zusätzlichen Schutz zu bieten. In Microsoft Entra ID sind geschützte Aktionen Berechtigungen, die Richtlinien für bedingten Zugriff zugewiesen werden. Wenn ein Benutzer versucht, eine geschützte Aktion durchzuführen, muss er zunächst die Richtlinien für den bedingten Zugriff erfüllen, die den erforderlichen Berechtigungen zugewiesen sind. Um beispielsweise Administratoren die Aktualisierung von mandantenübergreifenden Zugriffseinstellungen zu ermöglichen, können Sie verlangen, dass sie zuerst die phishing-resistente MFA-Richtlinie erfüllen.

Identitäts- und Zugriffsverwaltung im Accelerator für Azure-Zielzonen

Identitäts- und Zugriffsmanagement sind Kernfunktionen der Azure Zielzone Accelerator-Implementierung. Die Bereitstellung umfasst ein Abonnement für Identitätsdienste, in dem Unternehmen AD DS-Domänencontroller oder andere Identitätsdienste, wie Microsoft Entra Connect-Server, die für ihre Umgebung erforderlich sind, bereitstellen können. Nicht alle Organisationen benötigen Dienstleistungen im Rahmen eines Abonnements. Einige Unternehmen verfügen beispielsweise über Anwendungen, die bereits vollständig mit Microsoft Entra ID integriert sind.

Das Identitätsabonnement verfügt über ein virtuelles Netzwerk, das mit dem virtuellen Hub-Netzwerk im Plattformabonnement verbunden ist. Mit dieser Konfiguration kann das Plattformteam das Identitätsabonnement verwalten, und die Anwendungsinhaber haben bei Bedarf Zugriff auf Identitätsdienste. Sie müssen das Identitätsabonnement und das virtuelle Netzwerk sichern, um Identitätsdienste vor unbefugtem Zugriff zu schützen.

Die Azure Zielzone Accelerator-Implementierung umfasst auch Optionen zur:

• Zuweisen empfohlener Richtlinien zum Verwalten von Identitäten und Domänencontrollern
• Erstellen eines virtuellen Netzwerks und Herstellen einer Verbindung mit dem Hub über ein Peering virtueller Netzwerke

Nächste Schritte