Identitäts- und Zugriffsmodell¶
Diese Seite beschreibt die Überlegungen hinter der Zugriffssteuerung auf der Plattform. Wie du als Nutzer Zugriff beantragst und aktivierst, steht unter Zugriff, Gruppen und PIM. Die genauen Gruppen eines Spokes stehen in der Spoke-JSON-Referenz.
Prinzipien¶
- Mache die tägliche Arbeit autonom: Ein Team soll für gewöhnliche Aufgaben kein Ticket brauchen.
- Hochprivilegierte Rollen auf Tenant- oder Plattformebene sind immer durch PIM geschützt und werden von Personen der Kundenorganisation autorisiert, nicht vom Managed-Service-Anbieter.
- Halte das Modell einfach, um Komplexität in der Umsetzung zu vermeiden.
- Plattformrollen werden auf management groups zugewiesen und an die darunterliegenden Subscriptions vererbt. Workload-Rollen werden auf der Subscription zugewiesen und an ihre Ressourcen vererbt.
- Rollen und PIM-Zuweisungen gehen an Gruppen, nie an einzelne Benutzerkonten, die sich interaktiv anmelden.
Ebenen und Arten von Rollen¶
Rollen liegen auf drei Ebenen.
| Ebene | Was sie beschreibt | Verantwortlich |
|---|---|---|
| Business | Die Rollen, die an eine Person gebunden sind: Jobtitel, Funktion, Abteilung, Standort | Die Organisation (zum Beispiel provisioniert und verwaltet HR die Business-Benutzer) |
| Workload | Die Rollen auf Ebene eines Workloads, also einer Business-Lösung, die mehrere eng verwandte Anwendungen enthalten kann | Die Plattform stellt für jeden Workload einen Standardsatz technischer Rollen bereit. Zusätzliche Rollen sind möglich, aber das Workload-Team deployt und konfiguriert sie. |
| Application | Rollen innerhalb einer Anwendung, meist nativ in ihr | Das Workload-Team |
Rollen sind außerdem entweder technisch oder funktional, weil sie unterschiedliche Expertise erfordern:
| Typ | Fokus | Beispiele |
|---|---|---|
| Technisch | Das Innere des Workloads oder der Anwendung: Entwicklung, Deployment, Wartung. Hohe Rechte auf der Infrastruktur. | Ressourcen deployen, Konfiguration ändern |
| Funktional | Das Äußere: fachliche Verwaltung in der Anwendung, etwa Business-Benutzer oder Workflows verwalten. Keine Infrastrukturrechte. Wird öfter an Personen in anderen Teams delegiert. | Anwendungsbenutzer verwalten |
Workload-Rollen¶
Ein typischer Workload hat vier technische Rollen. Jede wird durch eine Entra ID Security-Gruppe getragen, die die Berechtigungen im Azure-Portal, in Azure DevOps und in anderen Services besitzt.
| Rolle | Bedeutung |
|---|---|
| Owner | Besitzt den Workload und ist am Ende für alles darin verantwortlich |
| Approver | Genehmigt Änderungen und erhöhten Zugriff auf Produktion, zum Beispiel PIM-Anfragen |
| Engineer | Verantwortlich für die Umsetzung des Workloads und beaufsichtigt ihn |
| Reader | Lesezugriff, für Gäste sowie unterstützende Engineers oder Architekten |
Die MCP-Spoke-Baseline erstellt pro Spoke vier Gruppen: Owners, Contributors, Readers und Support, und legt fest,
ob jede Rolle dauerhaft ist oder in PIM mit oder ohne Genehmigung aktiviert werden muss (siehe
Zugriff, Gruppen und PIM). Wer genehmigt, wird in den PIM-Einstellungen der
Spoke-Gruppen festgelegt. Eine Plattform kann zusätzliche Gruppen für Rollen auf Anwendungsebene hinzufügen.
Note
Wenn du auf den Spoke-Gruppen einen eigenen Rollensatz entwirfst, halte den Owner jeder Gruppe klar: Der Owner der Workload-Gruppe besitzt die Approver-, Engineer- und Reader-Gruppen.
Spoke-Gruppen und der Service Principal des Spokes¶
Die vier Gruppen eines Spokes haben auf der subscription eine feste Bedeutung:
| Gruppe | Rolle auf der subscription | Hinweise |
|---|---|---|
Owners |
Owner | Umfasst die Zugriffsverwaltung. Der Service Principal des Spokes ist ständiges Mitglied |
Contributors |
Contributor | Alles außer dem Setzen von Berechtigungen |
Readers |
Reader | Nur Ansicht |
Support |
Keine | Hat selbst keine Berechtigungen. Sie existiert, damit Support-Mitarbeiter des Plattform-Teams über PIM die Owners-Gruppe erreichen können |
Für Key Vault und Storage hat jede Gruppe standing Lesezugriff auf die Data Plane, und Contributors und Owners können zusätzlich erhöhte Rollen über PIM aktivieren. Der Service Principal des Spokes ist Owner auf der subscription, Key Vault Administrator auf dem Key Vault und Storage Blob Data Owner auf dem Storage Account und bekommt kein Secret, wenn Federated Credentials verwendet werden. Details und wie du die Rollenzuordnung überschreibst: Spoke canvas.
Das Deployment, das all das erstellt, ist durch eine Administrative Unit begrenzt: Es kann nur Gruppen in dieser Unit verwalten. So behält die Deployment-Identität geringe Berechtigungen. Siehe Was die Deployment-Identität braucht.
Zugriff auf einen Workload bekommen¶
| Weg | Wann | Warum |
|---|---|---|
| Der Antragsteller fragt den Workload-Owner, der die Person zur Teamgruppe hinzufügt | Normal | Der Zugriff ist auf einen Workload begrenzt und wird von dessen Owner autorisiert |
| Ein Plattform-Engineer aktiviert eine Reader-, Contributor- oder Owner-Rolle auf einer management group | Nur in Notfällen | Gibt Zugriff auf alle Ressourcen unterhalb dieser management group. Weniger bevorzugt. Immer über PIM und mit Begründung. |
Plattformrollen¶
Plattformrollen folgen denselben Prinzipien mit einem größeren Scope.
| Prinzip | Detail |
|---|---|
| Auf management groups zugewiesen | Die Kernrollen der Plattform werden auf management groups gesetzt und vererbt |
| Immer über PIM | Contributor und Owner auf Plattform-Scope sind nie dauerhaft |
| Ein externes Plattform-Team arbeitet als Gast | Die Engineers des Managed-Service-Anbieters sind meist Gäste im Tenant des Kunden. Einige eingebaute Policies markieren Gastkonten mit Schreib- oder Owner-Rechten; siehe Governance. |
Microsoft Defender for Cloud¶
Die Autorisierung in Defender for Cloud folgt den Azure-Rollen auf der Subscription:
| Aktion | Security Reader | Security Admin | Contributor | Owner |
|---|---|---|---|---|
| Alerts und Empfehlungen ansehen | Ja | Ja | Ja | Ja |
| Security Policy bearbeiten und Initiativen zuweisen | Nein | Ja | Nein | Ja |
| Defender-Pläne aktivieren oder deaktivieren | Nein | Ja | Ja | Ja |
| Eine Empfehlung anwenden (Fix) | Nein | Nein | Ja | Ja |
Das entspricht der Microsoft-Dokumentation. Prüfe es, bevor du dich darauf verlässt.
Break-glass-Konten¶
Du kannst dich aus dem Tenant aussperren, wenn die Anmeldung oder die Aktivierung privilegierter Rollen fehlschlägt. Verringere dieses Risiko mit Notfallzugriffskonten:
- Lege mindestens zwei an. Sie sind keiner Person zugeordnet.
- Verwende sie nur für Notfälle, in denen normale Administratorkonten nicht genutzt werden können.
- Bewahre die Zugangsdaten sicher auf (zum Beispiel in einem Vault und einem physischen Safe). Lege fest, wer Zugriff hat.
- Behandle jede Anmeldung mit diesen Konten als hohes Risiko: Löse einen Alert aus und überwache sie.
- Folge der aktuellen Microsoft-Anleitung für Notfallzugriffskonten, einschließlich des Umgangs mit Conditional Access.
Alle Rollen und Konten mit Rechten auf Tenant-Ebene sind standardmäßig hochriskant und sollten bei Nutzung überwacht werden.
Service Principals¶
Spoke-Deployments verwenden pro Spoke einen Service Principal. Siehe Was du bekommst und Service Principal und Zugangsdaten. Bevorzuge Federated Credentials gegenüber Secrets und rotiere Secrets, bevor sie ablaufen (Betriebsverantwortlichkeiten).