RBAC und PIM für spokes¶

Ein spoke bekommt vier Entra-ID-Gruppen (Owners, Contributors, Readers, Support) und einen Service Principal. Diese Seite erklärt, wie diese Gruppen ihre Azure-Rechte erhalten, welche Rechte dauerhaft sind und welche über Privileged Identity Management (PIM) aktiviert werden, und wie du das änderst. Die Sicht der Nutzer steht unter Zugriff, Gruppen und PIM.

Zwei Ebenen des Zugriffs¶

Ebene	Scope	Gesteuert durch
Subscription-Rollen	Die gesamte subscription	Vom spoke canvas festgelegt: Owners = Owner, Contributors = Contributor, Readers = Reader. Der Service Principal des spokes ist dauerhaftes Mitglied von Owners.
Role map	Die gesamte subscription, für bestimmte Rollen	Eine eingebaute role map, die du überschreiben kannst. Wird für Rollen wie die Data-plane-Rollen von Key Vault und Storage verwendet.

Die Mitgliedschaft des Teams in jeder Gruppe kommt aus ProductTeamGroupNames, das PIM-Profil aus PIMGroupConfig (Spoke-JSON-Referenz).

PIM-Profile¶

Ein Profil bestimmt, wie die Team-Gruppe Mitglied einer spoke-Gruppe wird. Profile sind in pim_configurations definiert (Gemeinsame Spoke-Einstellungen) und werden über ihren Namen referenziert.

Profil	Mitgliedschaft der Team-Gruppe	Genehmigung
`nopim`	Dauerhaft (aktive Zuweisung). Keine Anfrage nötig.	Keine
`self-approve`	Eligible. Der Benutzer aktiviert sie in PIM.	Keine
`approval`	Eligible. Der Benutzer aktiviert sie in PIM.	Erforderlich

PIMGroupConfig legt je ein Profil für Readers, Contributors und Owners fest. Die Support-Gruppe ist nicht konfigurierbar: Die Deployment-Logik setzt sie.

Ein typisches Muster, wie es in einer Implementierung verwendet wird (ein Beispiel, keine Regel):

Gruppe	Dev und Test	Abnahme und Produktion
Owners	Eligible, mit Genehmigung	Eligible, mit Genehmigung
Contributors	Eligible, automatische Genehmigung	Eligible, mit Genehmigung
Readers	Dauerhaft	Dauerhaft

Support-Gruppe¶

Die Support-Gruppe hat keine eigenen Rechte. Während der Support-Zeiten (außerhalb der Bürozeiten) wird sie Mitglied der Owners-Gruppe. Personen in der Support-Gruppe können dann über PIM Owner aktivieren, aber nur außerhalb der Bürozeiten.

Die role map¶

Die role map vergibt Azure-Rollen über eine dauerhafte oder PIM-eligible Zuweisung auf subscription-Ebene. Eine Zuweisung deckt jede passende Ressource in der subscription ab, egal ob die Ressource schon existiert. Sie hängt nicht von den obigen Subscription-Rollen ab. Jede eingebaute Azure-Rolle kann verwendet werden, nicht nur Data-plane-Rollen.

Standardmäßig gilt:

Gruppe	Data plane von Key Vault und Storage Account
Readers, Contributors, Owners	Dauerhafter Lesezugriff (`Key Vault Reader`, `Storage Blob Data Reader`)
Contributors	PIM-eligible Lese-/Schreibrollen (Key Vault Secrets, Certificate und Crypto User-Rollen sowie `Storage Blob Data Contributor`), Profil self-approve
Owners	PIM-eligible Rollen mit voller Kontrolle (Key Vault Secrets, Certificates und Crypto Officer-Rollen sowie `Storage Blob Data Owner`), Profil approval

Der Service Principal des spokes erhält außerdem Key Vault Administrator auf dem Key Vault und Blob-Owner-Rechte auf dem Storage Account, wenn diese deployt sind.

Subscription-Scope, nicht pro Ressource

Die Zuweisung gilt auf der subscription. Ein Contributor, der Storage Blob Data Contributor aktiviert, kann Blobs in jedem Storage Account dieser subscription lesen und schreiben, auch in solchen, die das Team später erstellt hat. Denke daran, wenn du entscheidest, welches Profil eine Rolle bekommt.

Die role map überschreiben¶

Du kannst die Map für alle spokes oder für einen spoke ändern. Eine spoke-Einstellung hat Vorrang vor der gemeinsamen Einstellung.

Wo	Einstellung	Gilt für
Gemeinsame Einstellungen	`override_defaults.pim_assignments`	Alle spokes
Spoke-Datei	`adInfo.PIMAssignments`	Ein spoke

Beides sind Maps mit dem exakten Azure-Rollennamen als Key, zum Beispiel Storage Blob Data Contributor. Jeder Eintrag hat zwei Felder:

Feld	Bedeutung
`levels`	Die Ebenen der spoke-Gruppen, die die Rolle erhalten, zum Beispiel `["Owner"]`.
`pim_profile`	Der Name eines Profils aus `pim_configurations`, das bestimmt, wie die Rolle vergeben wird.

Regeln:

Setze ein Feld, um nur dieses Feld zu ändern. Ein Feld, das du weglässt, behält seinen eingebauten Wert.
levels: [] entfernt die Rolle komplett (für diesen spoke, oder für alle spokes, wenn es in den gemeinsamen Einstellungen steht).
Eine Rolle, die nicht in der eingebauten Map steht, muss beide Felder setzen.
Um eine Rolle hinzuzufügen, etwa eine SQL- oder Cosmos-DB-Data-Rolle, ist keine Änderung an den Terraform-Modulen nötig.

Beispiel in einer spoke-Datei: Storage Blob Data Owner nur für diesen spoke genehmigungspflichtig machen.

"adInfo": {
  "PIMAssignments": {
    "Storage Blob Data Owner": { "pim_profile": "approval" }
  }
}

Beispiel, das eine Rolle hinzufügt, die nicht eingebaut ist. Beide Felder sind erforderlich:

"PIMAssignments": {
  "<exact role name>": { "levels": ["Contributor"], "pim_profile": "self-approve" }
}

Zugriff sicher ändern¶

Ich möchte	Mach das
Einem weiteren Team Zugriff geben	Füge die Gruppe zu `ProductTeamGroupNames` hinzu (Spoke ändern)
Den Zugriff einer Gruppe genehmigungspflichtig machen	Ändere das Profil in `PIMGroupConfig`
Dauerhaften Data-plane-Zugriff für einen spoke entfernen	`"<role>": { "levels": [] }` in `adInfo.PIMAssignments`
Einen Default für jeden spoke ändern	`override_defaults.pim_assignments` in den gemeinsamen Einstellungen. Behandle es als Plattformänderung mit Review.

Lies nach jeder Änderung den Plan. Das Entfernen einer dauerhaften Zuweisung entzieht den Personen den Zugriff, die heute damit arbeiten.