Identitäts- und Zugriffsverwaltung für Landing-Zones
Nachdem Sie Ihre Identitätsarchitektur festgelegt haben, müssen Sie die Autorisierung und den Zugriff auf die Ressourcen in den Anwendungs- und Plattform-Landing-Zones verwalten. Überlegen Sie, auf welche Ressourcen jeder authentifizierte Prinzipal Zugriff hat und benötigt und wie Sie das Risiko eines unbefugten Zugriffs auf Ihre Ressourcen beheben können. Weitere Informationen finden Sie unter Entwurf einer Identitätsarchitektur.
Übersicht
Der Designbereich Identitäts- und Zugriffsverwaltung bietet Anleitungen, die Ihnen bei der Implementierung des Zugriffsmodells für Unternehmen in Azure und der Implementierung und Sicherung von Steuerungsebenen helfen. Wenn Sie das Designprinzip der Abonnement-Demokratisierung einbeziehen, kann Ihr Anwendungsteam seine eigenen Workloads innerhalb der Richtlinien verwalten, die das Plattformteam festlegt. Dieser Ansatz folgt auch dem Prinzip der richtlinienbasierten Governance.
Das Plattformteam ist für die Bereitstellung neuer Plattform-Landing-Zones oder Abonnements verantwortlich. Bei der Bereitstellung einer Landing-Zone für eine*n Anwendungsbesitzer*in sollte das Plattformteam diese mit den entsprechenden Zugriffssteuerungen konfigurieren, damit der/die Anwendungsbesitzer*in seine eigenen Ressourcen verwalten kann. Der/die Anwendungsbesitzer*in sollte in der Lage sein, innerhalb von Microsoft Entra ID Benutzende und Gruppen zu erstellen und zu verwalten und diesen Benutzenden und Gruppen Rollen zuzuweisen. Der/die Anwendungsbesitzer*in kann dann den Zugriff auf seine/ihre eigenen Ressourcen verwalten und den Zugriff auf andere Benutzende und Gruppen nach Bedarf delegieren. Die Landing-Zone sollte je nach den Anforderungen der Anwendung auch über eine optionale Netzwerkkonnektivität zu Active Directory Domain Services (AD DS) oder Microsoft Entra Domain Services im Abonnement der Microsoft Identitätsplattform verfügen.
Verwenden Sie die rollenbasierte Zugriffssteuerung (RBAC) von Azure, um den administrativen Zugriff auf Azure-Ressourcen zu verwalten. Überlegen Sie, ob Benutzer*innen Berechtigungen für einen engen Bereich benötigen, wie z. B. ein/e Administrator*in für eine einzelne Anwendung, oder einen breiten Bereich, wie z. B. ein/e Netzwerkadministrator*in für mehrere Anwendungs-Workloads. Befolgen Sie in jedem Fall das Prinzip des minimalen Zugriffs, und stellen Sie sicher, dass Benutzende nur die für ihre normalen Aktivitäten erforderlichen Rollen haben. Verwenden Sie bei Bedarf angepasste Rollen und Microsoft Entra Privileged Identity Management (PIM), um JIT-Zugriff (Just-in-Time) zu erzwingen. Obwohl das Plattformteam für die Grundlage der Identitäts- und Zugriffsverwaltung verantwortlich ist, sind sowohl die Teams-Plattform als auch die Anwendungsteams Nutzende des Dienstes und sollten die gleichen Grundsätze befolgen.
Identitäts- und Zugriffsverwaltung ist wichtig für die erfolgreiche Trennung einer Landing-Zone von einer anderen und die Isolierung von Workloads innerhalb einer Organisation. Sie ist ein kritischer Designbereich sowohl für Plattform-Landing-Zones als auch für Anwendungs-Landing-Zones.
Wenn Ihre Organisation ein Abonnement-Vending-Verfahren einsetzt, können Sie viele der Identitäts- und Zugriffskonfigurationen für Landing Zones von Anwendungen automatisieren. Implementieren Sie den Verkauf von Abonnements, um die Erstellung von Landing Zones 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
Wichtig
Klassische Ressourcen und klassische Administrator*innen werden am 31. August 2024 abgelöst. Entfernen Sie unnötige Co-Administrator*innen, und verwenden Sie Azure RBAC für eine detaillierte Zugriffssteuerung.
Verstehen Sie den Unterschied zwischen Microsoft Entra ID-Rollen und Azure RBAC-Rollen.
Microsoft Entra ID-Rollen kontrollieren die administrativen Berechtigungen für mandantenweite Dienste wie Microsoft Entra ID und andere Microsoft-Dienste wie Microsoft Teams, Microsoft Exchange Online und Microsoft Intune.
Azure RBAC-Rollen steuern die administrativen Rechte für Azure-Ressourcen wie virtuelle Maschinen, Abonnements und Ressourcengruppen.
Die Rollen Azure RBAC-Besitzer*in und Benutzerzugriffs-Administrator*in können die Rollenzuweisungen auf Azure-Ressourcen ändern. Standardmäßig hat die Microsoft Entra Globale*r-Administrator*in-Rolle 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.
Wichtig
Microsoft empfiehlt, Rollen mit den geringsten Berechtigungen zu verwenden. Dies trägt zur Verbesserung der Sicherheit Ihrer Organisation bei. „Globaler Administrator“ ist eine Rolle mit umfangreichen Berechtigungen, die auf Notfallszenarios beschränkt sein sollte, in denen Sie keine vorhandene Rolle verwenden können.
Das folgende Diagramm zeigt die Beziehung zwischen Microsoft Entra ID-Rollen und Azure RBAC-Rollen:
Sie können rollenzuweisbare Gruppen erstellen und den Gruppen Microsoft Entra Rollen zuweisen, wenn Sie die Eigenschaft
isAssignableToRoleauftruesetzen. Nur Gruppen, für die diese Eigenschaft eingestellt ist, sind geschützt. Die einzigen Rollen, die die Mitgliedschaft einer Gruppe ändern können, sind globale Administrator*innen, Administrator*innen mit privilegierten Rollen oder der/die Besitzer*in der Gruppe.Nur einige Rollen können das Kennwort oder die Multi-Faktor-Authentifizierung (MFA) für eine*n andere/n Administrator*in zurücksetzen. Diese Einschränkung verhindert, dass nicht autorisierte Administrator*innen die Anmeldeinformationen eines höher privilegierten Kontos 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 Benutzenden, Gruppen und Prinzipalen des Dienstes angepasste Rollen in den Bereichen Mandant, Verwaltungsgruppe, Abonnement und Ressourcengruppe zuweisen. Verwenden Sie nach Möglichkeit die in Azure integrierten Rollen, und erstellen Sie angepasste Rollen nur, wenn dies erforderlich ist.
Wenn Sie Ihre Strategie zur Zugriffssteuerung entwerfen, sollten Sie die Servicegrenzen für Rollen, Rollenzuweisungen und angepasste Rollen kennen.
Einige Azure RBAC-Rollen unterstützen Attribut-basierte Zugriffssteuerung (ABAC) oder Rollenzuweisungsbedingungen. Wenn Sie Bedingungen verwenden, können Administrator*innen Rollen dynamisch zuweisen, basierend auf den Attributen der Ressource. So können Sie 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.
Sie können integrierte und benutzerdefinierte RBAC-Rollen mit
Microsoft.Authorization/roleAssignments/writeoderMicrosoft.Authorization/roleAssignments/delete-Berechtigungen verwenden, um Rollenzuweisungen zu erstellen, zu löschen und zu aktualisieren. Jeder Benutzer mit dieser Rolle kann entscheiden, wer über Schreib-, Lese- und Löschberechtigungen für jede Ressource im Zuordnungsbereich verfügt. Mitglieder der Plattform- oder Anwendungszielzone sollten überlegen, wie sie privilegierte Rollen an andere Benutzer und Gruppen delegieren, um ihnen die erforderliche Autonomie zu gewähren. Um die Einhaltung der Prinzipien für den Zugriff mit den geringsten Rechten zu gewährleisten, können sie Bedingungen verwenden, um Benutzer zu delegieren.
Entwurfsempfehlungen
Allgemeine Empfehlungen
Erzwingen Sie die Microsoft Entra Multi-Faktor-Authentifizierung (MFA) für Benutzende, die Rechte für die Azure Umgebung haben, einschließlich des Plattform-Abonnements, des Anwendungs-Abonnements und des Microsoft Entra ID-Mandanten. Viele Compliance-Frameworks erfordern die Durchsetzung von MFA. 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, stellen Sie sicher, dass Sie Benutzende mit Leserrollen in MFA-Richtlinien aufnehmen.
Verwenden Sie Microsoft Entra-Richtlinien für bedingten Zugriff für Benutzende, die Rechte für die Azure-Umgebung haben. Bedingter Zugriff ist eine weitere Funktion, die dazu beiträgt, eine kontrollierte Azure-Umgebung vor unberechtigtem Zugriff zu schützen. Administrator*innen von Anwendungen und Plattformen sollten Richtlinien für bedingten Zugriff haben, die das Risikoprofil ihrer Rolle widerspiegeln. So könnten Sie beispielsweise verlangen, dass administrative Aktivitäten nur von bestimmten Standorten oder bestimmten Arbeitsplätzen aus durchgeführt werden. Oder die Risikotoleranz bei der Anmeldung für Benutzende mit administrativem Zugriff auf Azure-Ressourcen könnte niedriger sein als für normale Microsoft Entra ID-Benutzende.
Aktivieren Sie Microsoft Defender for Identity, um Identitäten von Benutzenden zu schützen und Anmeldeinformationen zu sichern. Defender for Identity ist Teil von Microsoft Defender XDR. Sie können Defender for Identity verwenden, um verdächtige Aktivitäten von Benutzenden zu identifizieren und Zeitpläne für Vorfälle zu erhalten. Sie können ihn auch mit bedingtem Zugriff verwenden, um Authentifizierungsversuche mit hohem Risiko zu verweigern. Stellen Sie die Sensoren von Defender for Identity auf lokalen Domänencontrollern und Domänencontrollern im Azure Identity Abonnement bereit.
Verwenden Sie Microsoft Sentinel, um Bedrohungsaufklärung und Funktionalitäten für Ermittlungen bereitzustellen. Sentinel verwendet Log-Dateien 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 z. B. Web-Browsing und E-Mail-Zugriff. Web und E-Mail sind allgemeine Angriffsvektoren. Wenn ein Benutzungskonto kompromittiert wird, ist es weniger wahrscheinlich, dass es zu einer Sicherheitsverletzung 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 Administration verwenden. Privilegierte Microsoft Entra ID- und Azure RBAC-Rollen sind im Azure-Portal und in der Dokumentation als PRIVILEGIERT gekennzeichnet.
Für nicht privilegierte Job-Funktionsrollen, die Azure-Anwendungsressourcen verwalten können, sollten Sie überlegen, ob Sie separate Administratorkonten benötigen oder Microsoft Entra PIM verwenden, um den administrativen Zugriff zu kontrollieren. PIM stellt sicher, dass das Konto nur dann über die erforderlichen Berechtigungen verfügt, wenn sie benötigt werden, und dass die Berechtigungen entfernt werden, wenn die Aufgabe abgeschlossen ist (auch bekannt als Just-in-Time Zugriff).
Um die Rollenzuweisungen überschaubarer zu machen, weisen Sie den Benutzenden keine Rollen direkt zu. Weisen Sie Rollen stattdessen Gruppen zu, um die Anzahl der Rollenzuweisungen zu minimieren. Für jedes Abonnement gibt es ein Limit.
Verwenden Sie Microsoft Entra PIM für Gruppen, um Just-in-Time administrative Zugriffssteuerungen auf privilegierte Benutzende anzuwenden. Ziehen Sie in Erwägung, die Gruppenmitgliedschaft mit der Verwaltung von Berechtigungen zu steuern. 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 Anmeldeinformationen für die Konten sicher auf, überwachen Sie ihre Verwendung, und testen Sie sie regelmäßig, um sicherzustellen, dass Sie sie im Notfall verwenden können.
Weitere Informationen finden Sie unter Sichere Zugriffspraktiken für Administrator*innen in Microsoft Entra ID.
Empfehlungen zu Microsoft Entra ID
Integrieren Sie Microsoft Entra ID mit Azure Monitor, damit Sie Ihre Anmeldeaktivitäten und den Prüfpfad von Änderungen innerhalb Ihres Mandanten analysieren können. Konfigurieren Sie eine Diagnose-Einstellung, um Anmeldeprotokolle und Audit-Protokolle an den zentralen Arbeitsbereich von Azure Monitor Logs im Abonnement zu senden.
Verwenden Sie die Funktion zur Verwaltung von Berechtigungen von Microsoft Entra ID-Governance, um Zugangspakete zu erstellen, die die Gruppenmitgliedschaft über 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 der Ebene des Mandanten zu verwalten:
Role 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 Kennwort-Hash-Synchronisierung, Microsoft Entra Seamless Single Sign-on (SSO) und Verbund-Einstellungen. Sicherheitsadministrator Liest Sicherheitsinformationen und Berichte und verwaltet Konfigurationen in Microsoft Entra ID und Microsoft 365. Anwendungsadministrator Erzeugt und verwaltet alle Aspekte von App-Registrierungen und Unternehmens-Apps. Sie können keine mandantenweite administrative Genehmigung erteilen. Weisen Sie einer höher privilegierten Rolle keine Aufgabe zu, die eine niedriger privilegierte Rolle erledigen kann. Weisen Sie beispielsweise die Rolle Benutzeradministrator*in zu, um Benutzende zu verwalten, und nicht die Rolle Globale*r Administrator*in. Weitere Informationen finden Sie unter Microsoft Entra integrierte Rollen Berechtigungen.
Verwenden Sie Administrative Einheiten, um eine Reihe von Administrator*innen einzuschränken, damit sie nur bestimmte Objekte in Ihrem Mandanten verwalten können. Sie können administrative Einheiten verwenden, um die Verwaltung einer Untermenge des Verzeichnisses zu delegieren. So können Sie beispielsweise die Verwaltung eines Service-Desks an eine einzelne Unternehmenseinheit innerhalb einer größeren Organisation delegieren.
Administrative Einheiten können auch dazu beitragen, die Notwendigkeit separater Microsoft Entra ID-Mandanten als Sicherheitsgrenze zu beseitigen, wenn separate Teams die Microsoft 365-Plattform und die Azure-Plattform in derselben Organisation verwalten. So können Sie beispielsweise administrative Einheiten verwenden, um die Verwaltung von Azure-Anwendungssicherheitsprinzipalen an das Anwendungsteam zu delegieren, ohne Rechte auf dem gesamten Microsoft Entra ID-Mandanten zu gewähren.
Verwenden Sie eingeschränkte administrative Einheiten zur Verwaltung, um weiteren Schutz zu bieten. Verhindern Sie, dass andere Personen als eine bestimmte Gruppe von Administrator*innen, die Sie bestimmen, bestimmte Objekte ändern. Beispielsweise könnten Ihre Richtlinien zur Aufgabentrennung erfordern, dass Sie diese Funktion verwenden, um zu verhindern, dass jemand ein bestimmtes Benutzungskonto ändert, selbst Benutzer*innen mit der Rolle Benutzeradministrator*in. Diese Einschränkung ist nützlich für Dienstkonten, die von Anwendungen verwendet werden und die nicht einmal Administrator*innen ändern sollten. Sie können auch eine Eskalation der Rechte verhindern, z. B. wenn jemand ein Benutzungskonto 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 einer Fehlkonfiguration zu verringern, standardisieren Sie Rollen und Rollenzuweisungen in allen Landing-Zones der Anwendung. Wenn Sie beispielsweise eine Rolle haben, die Benutzende mit der Verwaltung virtueller Maschinen betraut, verwenden Sie dieselbe Rolle in allen Landing-Zones für Anwendungen. Dieser Ansatz vereinfacht auch das Verschieben von Ressourcen zwischen Landing Zones.
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 Log-Dateien mit dem entsprechenden Berechtigungsmodell konfiguriert sind. Wenn Sie einen zentralisierten Azure Monitor Logs-Arbeitsbereich verwenden, stellen Sie mit Ressourcenberechtigungen sicher, dass Anwendungsteams Zugriff auf ihre eigenen Log-Dateien haben, nicht aber auf die Log-Dateien 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 Benutzenden den entsprechenden Zugriff zu gewähren. Manchmal können Sie jedoch keine integrierten Rollen verwenden und gleichzeitig den Zugriff mit den geringsten Rechten einhalten, da die Rollen möglicherweise Berechtigungen enthalten, die über das hinausgehen, was Ihre Benutzenden benötigen. Wenn Sie eine genauere Kontrolle wünschen, sollten Sie eine angepasste Rolle erstellen, die die spezifischen Berechtigungen widerspiegelt, die für die Ausführung einer bestimmten Funktion erforderlich sind. Weitere Informationen finden Sie unter Rollenbasierte Autorisierung bereitstellen.
Viele in Azure erstellte Rollen bieten vordefinierte Rollenzuweisungen auf der Plattform- und Ressourcenebene. Wenn Sie mehrere Rollenzuweisungen kombinieren, bedenken Sie die Gesamtwirkung.
Der Azure Landing-Zone-Accelerator enthält mehrere angepasste Rollen für allgemeine administrative Funktionen. Sie können diese Rollen neben den in Azure integrierten Rollen verwenden. Die folgende Tabelle beschreibt die angepassten administrativen Rollen oder Bereiche für den Azure Landing-Zone-Accelerator:
Administrative Rolle oder Bereich Beschreibung Aktionen NotActions Azure Platform-Besitzende (wie die integrierte Besitzerrolle) Verwaltet Verwaltungsgruppen und Lebenszyklen von Abonnements *Besitzer des Abonnements Delegierte Rolle für den/die Besitzer*in des Abonnements *Microsoft.Authorization/*/write,Microsoft.Network/vpnGateways/*,
Microsoft.Network/expressRouteCircuits/*,
Microsoft.Network/routeTables/write,
Microsoft.Network/vpnSites/*Anwendungsbesitzender (DevOps, App-Betrieb) Mitwirkende Rolle für das Anwendungs- oder Betriebsteam im Bereich des Abonnements *Microsoft.Authorization/*/write,Microsoft.Network/publicIPAddresses/write,Microsoft.Network/virtualNetworks/write,Microsoft.KeyVault/locations/deletedVaults/purge/actionNetzwerkverwaltung (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 Sicherheitsadministrator*in mit horizontaler Sicht auf den gesamten Azure-Bestand und die Key Vault-Bereinigungsrichtlinie */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 Landing-Zone für eine Anwendung bereitstellt, sollte es sicherstellen, dass alle erforderlichen Objekte der Identitäts- und Zugriffsverwaltung erstellt werden, z. B. Sicherheitsgruppen, Standardrollenzuweisungen und verwaltete Identitäten, die den Benutzenden zugewiesen werden.
Erstellen Sie Rollenzuweisungen für die Landing-Zone im Bereich des Abonnements oder der Ressourcengruppe. Die Zuweisung von Azure-Richtlinien erfolgt im Bereich der Verwaltungsgruppe, sodass Sie die Rollenzuweisung für die Landing-Zone in einem niedrigeren Bereich bereitstellen sollten. Verwenden Sie diesen Ansatz, um sicherzustellen, dass Administrator*innen der Landing-Zone volle Autonomie über ihre Ressourcen haben, aber die Zuweisungen der Azure-Richtlinien, die ihre Landing-Zone kontrollieren, nicht ändern können.
Jede Landing-Zone sollte ihre eigenen Gruppen und Rollenzuweisungen haben. Erstellen Sie keine allgemeinen Gruppen, und weisen Sie diese nicht mehreren Landing-Zones zu. Dieser Ansatz kann zu Fehlkonfigurationen und Sicherheitsverletzungen führen und ist im großen Maßstab nur schwer zu verwalten. Wenn ein/e Benutzende*r Zugriff auf mehrere Landing-Zones benötigt, weisen Sie ihn den entsprechenden Gruppen in jeder Landing-Zone zu. Verwenden Sie ID-Governance, um ihre Gruppenmitgliedschaft zu kontrollieren.
Weisen Sie die Rollen den Gruppen zu, nicht den Benutzenden. Auf diese Weise stellen Sie sicher, dass die Benutzenden über die richtigen Berechtigungen verfügen, wenn sie Ihrer Organisation beitreten oder sie verlassen. Außerdem können Sie so sicherstellen, dass die Benutzenden über die richtigen Berechtigungen verfügen, wenn sie zwischen Teams wechseln. Wenn ein Benutzender zum Beispiel vom Networking-Team zum Sicherheitsteam wechselt, sollten Sie ihn aus der Networking-Gruppe entfernen und der Sicherheitsgruppe hinzufügen. Wenn Sie Benutzenden direkt eine Rolle zuweisen, behalten diese die Rolle auch nach dem Wechsel in ein anderes Team bei. Verwenden Sie ID-Governance, um die Gruppenmitgliedschaft zu kontrollieren, anstatt Gruppenmitglieder manuell hinzuzufügen und zu entfernen.
Pflegen Sie getrennte Sicherheitskonfigurationen für verschiedene Umgebungen derselben Anwendung, z. B. Entwicklung/Test und Produktion. Erstellen Sie separate Gruppen und Rollenzuweisungen für jede Umgebung. Verwenden Sie verwaltete Identitäten oder Dienstprinzipale nicht in verschiedenen Umgebungen. Behandeln Sie jede Umgebung wie eine eigene Landing-Zone. Dieser Ansatz trägt dazu bei, die Isolierung zwischen Entwicklung/Test und Produktion zu gewährleisten und den Prozess des Verschiebens von Anwendungsbereitstellungen zwischen Umgebungen zu standardisieren. Wenn ein und dieselbe Person Zugriff auf mehrere Landing-Zones benötigt, sollten Sie sie den entsprechenden Gruppen in jeder Landing-Zone zuordnen.
Überlegen Sie, ob Plattform-Administrator*innen Berechtigungen für die Landing-Zones von Anwendungen benötigen. Wenn ja, verwenden Sie Microsoft Entra PIM, um den Zugriff auf diese Ressourcen zu kontrollieren, und weisen Sie die am wenigsten privilegierten Berechtigungen zu. Ein*e Administrator*in könnte zum Beispiel Zugriff auf eine bestimmte Plattform-Landing-Zone benötigen, um eine Fehlerbehebung durchzuführen, sollte aber keinen routinemäßigen Zugriff auf die Anwendungsdaten oder den Code haben. In diesem Fall kann der/die Administrator*in der Plattform den Zugriff auf die Anwendung beantragen. Ein*e Administrator*in mit privilegierter Rolle genehmigt die Anfrage, und der/die Plattformadministrator*in erhält die erforderlichen Berechtigungen für den angegebenen Zeitraum. Dieser Ansatz trägt dazu bei, die Aufgabentrennung durchzusetzen und die Landing-Zones der Anwendungen vor versehentlicher oder schädlicher Fehlkonfiguration zu schützen.
Wenn Sie die administrative Verantwortung an andere delegieren, z. B. an Anwendungsteams, sollten Sie überlegen, ob diese alle Berechtigungen oder nur eine Untermenge benötigen. Befolgen Sie das Prinzip der geringsten Rechte. So können Sie beispielsweise Benutzenden, die den Zugriff auf Azure-Ressourcen, nicht aber die Ressourcen selbst verwalten müssen, die Rollen „Benutzerzugriffsadministrator“ oder „RBAC-Administrator“ zuweisen. Um die Identitäten, Identitätstypen und Rollen einzuschränken, die die Benutzer delegieren und an Azure RBAC-Zuweisungen zuweisen können, verwenden Sie delegierte Rollenzuweisungen mit Bedingungen. Bedingungen ermöglichen es Anwendungsteams, ihre eigenen Sicherheitsprinzipale innerhalb der vom Plattformteam festgelegten Beschränkungen zu verwalten. Privilegiertere Rollenzuweisungen erfordern eine Eskalation an das Plattformteam. Berücksichtigen Sie die folgenden Faktoren, wenn Sie Bedingungen zum Delegieren von RBAC-Rollen verwenden:
Überprüfen Sie aktuelle Rollenzuweisungen für integrierte und benutzerdefinierte privilegierte Rollen, und bewerten Sie, ob Sie diesen vorhandenen Zuweisungen geeignete Bedingungen hinzufügen sollten. Sie können beispielsweise den benutzerdefinierten Rollen „Abonnementbesitzer“ und „Anwendungsbesitzer“ Bedingungen hinzufügen, die der Azure-Beschleuniger für die Zielzone bereitstellt. Diese Bedingungen können die wichtigsten Arten von Rollen, denen sie Rollen zuweisen können, einschränken oder bestimmte Rollen, die sie zuweisen können, begrenzen.
Folgen Sie dem PoLP, wenn Sie Rollenzuweisungen Bedingungen hinzufügen. Beschränken Sie beispielsweise die Delegierten darauf, nur Gruppen Rollen zuzuweisen, oder ermöglichen Sie den Delegierten, alle Rollen außer privilegierten Administratorrollen wie Eigentümer, Benutzerzugriffsadministrator und RBAC-Administrator zuzuweisen.
Erstellen Sie Ihre eigenen Bedingungen, wenn die verfügbaren Bedingungsvorlagen Ihre Anforderungen oder Richtlinien nicht erfüllen.
Überprüfen Sie die bekannten Einschränkungen des Delegierens der Azure-Zugriffsverwaltung an andere Benutzer.
Die folgende Tabelle zeigt eine beispielhafte Rollenzuweisungsstruktur für eine Azure Landing-Zone-Umgebung. Sie bietet ein Gleichgewicht zwischen Sicherheit und einfacher Verwaltung. Sie können die Struktur an die Anforderungen Ihrer Organisation anpassen. Sie können ein und dieselbe Person je nach ihrer Rolle innerhalb der Organisation mehreren Gruppen zuweisen. Aber Sie sollten die RBAC-Zuweisungen auf eine bestimmte Gruppe innerhalb einer bestimmten Landing-Zone anwenden.
Resource Benutzer Rollenzuweisung Zuweisungsziel Erläuterungen zum Bereich in Azure Policy Anwendung X Landing-Zone Anwendung X Besitzer*in Anwendungsbesitzende (angepasst, in Azure Landing Zone Accelerator enthalten) Application X Admins-SicherheitsgruppeAnwendung X Produktions- und Entwicklungs-/Test-Abonnements Anwendung X Landing-Zone Anwendung X Besitzer*in Administrator*in für den Anwendungszugriff (angepasst, mit Bedingungen für die Rollenzuweisung, um den Zugriff auf die eigene Anwendung zu verwalten) Application X Admins-SicherheitsgruppeAnwendung X Produktions- und Entwicklungs-/Test-Abonnements Anwendung X Landing-Zone Anwendung X Daten-Administrator*in Daten-Administrator*in (angepasst, mit Berechtigungen für erforderliche Datenressourcen) Application X Data Team-SicherheitsgruppeAnwendung X Produktions- und Entwicklungs-/Test-Abonnements Anwendung Y Landing-Zone Anwendung Y Besitzer*in Anwendungsbesitzende (angepasst, in Azure Landing Zone Accelerator enthalten) Application Y Admins-SicherheitsgruppeAnwendung Y Abonnements für Produktion und Entwicklung/Test Anwendung Y Landing-Zone Anwendung Y Test-Team Mitwirkende beim Test (angepasst, mit Berechtigungen, die für das Testen der Anwendung erforderlich sind) Application Y Test Team-SicherheitsgruppeAnwendung Y dev/test-Abonnement Sandbox Entwicklungsteam für die Anwendung Z Besitzer (integriert) Application Z developers-SicherheitsgruppeRessourcengruppen der Anwendung Z im Sandbox-Abonnement Plattform-Ressourcen Plattform-Verwaltungsteam Mitwirkender (integriert) Platform AdminsPIM-GruppePlatformVerwaltungsgruppePlattform-Landing-Zones Plattform-Verwaltungsteam Leser (integriert) Platform Team-SicherheitsgruppeOrganisatorische Verwaltungsgruppe auf höchster Ebene Mandantenweit Sicherheitsteam Sicherheitsbetrieb (angepasst, im Azure Landing-Zone-Accelerator enthalten) Security Ops-SicherheitsgruppeOrganisatorische Verwaltungsgruppe auf höchster Ebene Mandantenweit Sicherheitsteam Administrator*in für bedingten Zugriff (integriert, mit aktivierten geschützten Aktionen) Security administrators-SicherheitsgruppeMicrosoft Entra ID-Mandant Mandantenweit Netzwerkteam Netzwerk-Betrieb (angepasst, in Azure Landing-Zone-Accelerator enthalten) Network Ops-SicherheitsgruppeAlle Abonnements Mandantenweit FinOps-Team Billing Reader (integriert) FinOps Team-SicherheitsgruppeOrganisatorische Verwaltungsgruppe auf höchster Ebene Azure Policy-Zuweisungen mit dem
DeployIfNotExists-Effekt erfordern eine verwaltete Identität, um nicht-konforme Ressourcen zu korrigieren. Wenn Sie eine vom System zugewiesene verwaltete Identität als Teil des Zuweisungsprozesses von Azure Policy verwenden, gewährt Azure automatisch die erforderlichen Berechtigungen. Wenn Sie eine von Benutzenden zugewiesene verwaltete Identität verwenden, müssen die Berechtigungen manuell erteilt werden. Die Rollenzuweisungen für verwaltete Identitäten müssen dem Prinzip der geringsten Berechtigung folgen und nur die Berechtigungen zulassen, die für die Durchführung der Korrektur der Richtlinie im Zielbereich erforderlich sind. Verwaltete Identitäten für die Korrektur von Richtlinien bieten keinen Support für angepasste Rollendefinitionen. Wenden Sie Rollenzuweisungen direkt auf verwaltete Identitäten an, und nicht auf Gruppen.
Empfehlungen für Microsoft Entra PIM
Verwenden Sie Microsoft Entra PIM, um das Zero Trust-Modell und den Zugriff mit den geringsten Privilegien einzuhalten. Ordnen Sie die Rollen Ihrer Organisation den erforderlichen Mindestzugriffsebenen zu. In Microsoft Entra PIM können Sie Azure-eigene Tools verwenden, vorhandene Tools und Prozesse erweitern oder je nach Bedarf sowohl vorhandene als auch native Tools verwenden.
Verwenden Sie Microsoft Entra PIM-Zugriffsüberprüfungen, um die Berechtigungen für Ressourcen regelmäßig zu überprüfen. 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 Automation-Runbooks, die erhöhte Zugriffsberechtigungen erfordern, oder für privilegierte Pipelines zur Bereitstellung. Sie können die gleichen Tools und Richtlinien für die Kontrolle automatisierter Workflows verwenden, die auf kritische Sicherheitsgrenzen zugreifen, wie Sie sie für die Kontrolle von Benutzenden mit den gleichen Berechtigungen verwenden. Automatisierungs- und Bereitstellungspipelines für Anwendungsteams sollten über Rollenzuweisungen verfügen, die verhindern, dass Anwendungsbesitzende ihre eigenen Privilegien ausweiten können.
Kontrollieren Sie hochprivilegierte Azure RBAC-Rollen, wie z. B. Besitzende oder Benutzerzugriffsadministrator*innen, die Mitgliedern von Plattform- oder Anwendungs-Landing-Zone-Teams auf 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 Hochstufungsprozess benötigen wie Microsoft Entra ID-Rollen.
Zum Beispiel könnte ein*e Benutzer*in routinemäßig einen begrenzten administrativen Zugriff auf Ressourcen in einer Landing-Zone für Anwendungen benötigen. Gelegentlich könnte er/sie die Rolle Besitzer*in benötigen. Sie können zwei Sicherheitsgruppen erstellen: Anwendungsadministrator*innen und Anwendungsbesitzer*innen. Weisen Sie der Gruppe der Anwendungsadministrator*innen die Rollen mit den geringsten Rechten zu und der Gruppe der Anwendungsbesitzer*innen die Rolle des/der Besitzer*in. Verwenden Sie PIM-Gruppen, damit Benutzende bei Bedarf die Besitzer*in-Rolle anfordern können. Zu allen anderen Zeiten verfügen die Benutzenden nur über die Berechtigungen, die für die Ausführung ihrer typischen Aktivitäten erforderlich sind.
Verwenden Sie geschützte Aktionen mit Microsoft Entra PIM, um zusätzliche Schutzschichten hinzuzufügen. In Microsoft Entra ID sind geschützte Aktionen Berechtigungen, denen Richtlinien für bedingten Zugriff zugewiesen sind. Wenn Benutzende versuchen, eine geschützte Aktion durchzuführen, müssen sie zunächst die Richtlinien für bedingten Zugriff erfüllen, die den erforderlichen Berechtigungen zugewiesen sind. Um beispielsweise Administrator*innen die Möglichkeit zu bieten, mandantenübergreifende Zugriffseinstellungen zu aktualisieren, können Sie verlangen, dass sie zunächst die Phishing-resistente MFA-Richtlinie erfüllen.
Identitäts- und Zugriffsverwaltung im Accelerator für Azure-Zielzonen
Identitäts- und Zugriffsverwaltung sind zentrale Funktionen der Implementierung des Azure Landing-Zone-Accelerators. Die Bereitstellung umfasst ein Abonnement, das speziell auf die Identität ausgerichtet ist. Hier können Organisationen AD DS-Domänencontroller oder andere Identitätsdienste wie Microsoft Entra Connect Server bereitstellen, die für ihre Umgebung erforderlich sind. Nicht alle Organisationen benötigen die Dienste des Abonnements. Einige Organisationen verfügen beispielsweise über Anwendungen, die bereits vollständig mit Microsoft Entra ID integriert sind.
Das Identitäts-Abonnement verfügt über ein virtuelles Netzwerk, das mit dem virtuellen Hub-Netzwerk im Plattform-Abonnement verbunden ist (Peering). Mit dieser Konfiguration kann das Plattformteam das Identitätsabonnement verwalten, und die Anwendungsbesitzenden haben bei Bedarf Zugriff auf die Identitätsdienste. Sie müssen das Identitätsabonnement und das virtuelle Netzwerk sichern, um die Identitätsdienste vor unberechtigtem Zugriff zu schützen.
Die Implementierung des Azure Landing-Zone-Accelerators umfasst auch folgende Optionen:
- 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