Zum Inhalt

Zugriff, Gruppen und PIM

Die Spoke-Gruppen

Jeder Spoke bekommt vier Entra ID Security-Gruppen, deren Namen sich aus Workload und Umgebung ergeben. Die bestehende Gruppe deines Teams (der Anzeigename in ProductTeamGroupNames) wird Mitglied dieser Gruppen, entweder direkt oder just-in-time über PIM.

Gruppe Azure-Rolle Typische Mitglieder
…_Readers Reader Alle im Team, die nur lesen müssen
…_Contributors Contributor Engineers, die Ressourcen ändern
…_Owners Owner Wenige Personen; meist die Deployment-Identität
…_Support Support-Zugriff; immer eligible mit Genehmigung Support-Mitarbeitende des Plattform-Teams

Die genauen Gruppennamen folgen dem Namenstemplate deiner Plattform (ein typisches Muster ist SG_SPOKE_<workload>_<env>_<role>).

Wofür die Rollen gedacht sind

Rolle Verwende sie, um …
Reader Ressourcen und Logs anzusehen. Geringes Risiko, daher oft dauerhaft vergeben.
Contributor Ressourcen zu erstellen und zu ändern. In acc und prd ist das normalerweise für Notfälle und kurzes Troubleshooting gedacht, weil Änderungen dort über Pipelines laufen.
Owner Zugriff und alles andere zu verwalten. Nur wenige Personen brauchen sie, und meist erledigt die Deployment-Identität (der Spoke Service Principal) die Arbeit.

Rollen werden an Gruppen vergeben, nicht an einzelne Benutzer. Erhöhte Rollen für Personen sind der letzte Ausweg. Alltägliche Änderungen laufen über die Deployment-Identität und deine Pipelines.

Wähle, wie jede Rolle vergeben wird

Pro Rolle (Readers, Contributors, Owners) legt das Plattform-Team beim Erstellen des Spokes einen von drei Modi fest:

Modus (PIMGroupConfig) So bekommst du die Rolle Einsatz
nopim Dauerhaft über die Gruppenmitgliedschaft Entwicklung und Test; Rollen mit geringem Risiko
self-approve Wenn du sie in PIM aktivierst; ohne Genehmigung Erhöhte Rollen, bei denen ein Audit-Trail genügt
approval Wenn du sie in PIM aktivierst und ein Genehmiger zustimmt Produktions-Owner und -Contributors

Üblich ist nopim in dev und tst sowie approval für Contributors und Owners in prd. Eine Änderung des Modus beantragst du über So änderst du.

Ein Beispiel pro Umgebung

Eine Kundenplattform nutzte dieses Setup. Bei dir kann es anders sein, denn der Modus wird pro Spoke festgelegt.

Rolle dev tst acc prd
Readers nopim nopim nopim nopim
Contributors nopim self-approve approval approval
Owners nopim approval approval approval

Reader hat ein geringes Risiko und ist daher immer direkt vergeben. dev setzt auf schnelles Feedback. Ab tst hinterlassen erhöhte Rollen einen Audit-Trail, und ab acc braucht es eine zweite Person.

Was im Hintergrund passiert

Die Spoke-Baseline nutzt PIM for Groups. Die Gruppe deines Teams wird Mitglied jeder Spoke-Gruppe. Im Modus nopim ist die Mitgliedschaft aktiv und dauerhaft. In den Modi self-approve und approval ist die Mitgliedschaft eligible: Deine Leute haben keine Rolle, bis sie sie aktivieren, und sie endet von selbst. Die Rolle selbst ist immer der Spoke-Gruppe auf der Subscription zugewiesen. Die Aktivierung der Gruppenmitgliedschaft verleiht also die Rolle. Mehr Hintergrund: PIM for Groups.

Eine Rolle in PIM aktivieren

  1. Öffne das Azure-Portal und gehe zu Privileged Identity Management.
  2. Wähle My roles und dann Groups.
  3. Suche die Spoke-Gruppe und wähle Activate.
  4. Wähle eine Dauer (bis zum erlaubten Maximum), gib eine klare Begründung an und bestätige.
  5. Bei approval geht die Anfrage an die Genehmiger. Verfolge sie unter My requests: Pending, Approved, Denied oder Expired.

Rollenaktivierungen sind immer temporär und laufen von selbst ab. Bevor du Zugriff beantragst, suche die Gruppe in der PIM-Liste Groups anhand des Kurznamens deines Workloads. Gib eine klare Begründung an (zum Beispiel die Änderungs- oder Incident-Nummer), denn jede Aktivierung und Genehmigung wird protokolliert und kann auditiert werden.

Genehmiger

Wenn du Genehmiger bist: Du bekommst eine E-Mail. Öffne PIM, wähle Approve requests und dann Groups, prüfe die Anfrage sorgfältig (Owner-Rechte sind sensibel) und wähle Approve oder Deny mit einem Kommentar. Halte die Genehmigergruppe klein. Erhöhte Rechte sollten selten nötig sein, da normale Änderungen über Pipelines laufen.

Wer genehmigen darf, hängt von der Plattform ab. Üblich sind die Mitglieder der Teamgruppe des Workloads plus einige Personen des Plattform-Teams. Auf vielen Plattformen kann niemand seine eigene Anfrage genehmigen. Nach deiner Genehmigung erhält der Antragsteller eine E-Mail, dass die Anfrage genehmigt wurde, und eine weitere, wenn der Zugriff aktiv ist.

Wer verwaltet die Gruppenmitglieder?

Gruppe Verwaltet von
Die eigene Gruppe deines Teams (in ProductTeamGroupNames) Dir oder deinem Identity-Team: Hier fügst du Kolleginnen und Kollegen hinzu oder entfernst sie. So gibst du einer Person Zugriff.
Die vier Spoke-Gruppen Die Plattform. Bearbeite weder Mitglieder noch Owner.

Ein Product Owner kann die Mitgliedschaft der Gruppen, die er besitzt, im Microsoft-Self-Service-Portal für Gruppen (myaccount.microsoft.com/groups) verwalten, sofern deine Organisation das aktiviert hat.

Anwendungsgruppen und Access Reviews

Manche Organisationen erlauben Workload-Teams, zusätzliche Entra ID Gruppen für die Autorisierung auf Anwendungsebene anzufordern, optional mit PIM (und einer automatisch erstellten Genehmigergruppe) und regelmäßigen Access Reviews (Entra ID Governance) der Mitglieder. Wenn deine Plattform das anbietet, fordere es beim Plattform-Team an, mit: Gruppenname, Beschreibung, optionalem PIM-Gruppennamen und optionaler Review-Frequenz. Die MCP-Spoke-Baseline selbst erstellt nur die vier oben genannten Gruppen.

Bei einer Gruppe mit PIM nennt eine Anfrage meist auch die Eligible-Gruppe (die Personen, die aktivieren dürfen) und die Aktivierungseinstellungen. Das sind die Entra-PIM-Einstellungen, die Plattformen typischerweise zur Auswahl anbieten:

Einstellung Bedeutung
Maximale Dauer Wie lange eine Aktivierung höchstens dauern darf, zum Beispiel 8 Stunden
Begründung Ob der Benutzer eine Begründung eingeben muss
Genehmigung Ob ein Genehmiger die Aktivierung akzeptieren muss
Multifaktor-Authentifizierung Ob der Benutzer bei der Aktivierung MFA durchführen muss
Ticket-Informationen Ob der Benutzer eine Ticketnummer angeben muss
Benachrichtigungen Wer über Aktivierungen und Genehmigungen benachrichtigt wird

Eine Kundenplattform kann diese Einstellungen als Code in einem separaten Repository halten, mit einer Policy-Datei, die mehrere Zuweisungen wiederverwenden. Frag dein Plattform-Team, wie Anwendungsgruppen in deiner Organisation angefordert werden.

Mitglieder mit Terraform hinzufügen

Wenn du die Gruppenmitgliedschaft als Code verwaltest, nutze azuread_group_member und übergib sowohl group_object_id als auch member_object_id explizit. Abfragen wie data "azuread_group" oder data "azuread_user" benötigen verzeichnisweite Leseberechtigungen, die der Spoke Service Principal normalerweise nicht hat. Ermittle die Object-IDs zuerst (Portal oder CLI) und trage sie in deinen Code ein.