RBAC vs PIM

Begriffe und Abgrenzung

• Azure RBAC: Rollen und Zuweisungen auf Azure-Ressourcenebene (Management Group / Subscription / Resource Group / Resource).
• PIM (Privileged Identity Management): Workflows, um privilegierte Rollen zeitlich begrenzt, nachvollziehbar und optional mit Genehmigung/Begründung zu aktivieren.

Wichtig: PIM ersetzt RBAC nicht. PIM steuert wie und wann ein Benutzer eine RBAC-Rolle bekommt (aktiviert), nicht welche Rechte die Rolle grundsätzlich enthält.

Entscheidungsheuristik

Nutze dauerhafte RBAC-Zuweisungen, wenn:

• es sich um nicht-privilegierte Rollen handelt (z. B. Reader, Monitoring Reader),
• der Zugriff automatisiert und dauerhaft erforderlich ist (z. B. Managed Identities/Service Principals für Deployments),
• die Rolle keine weitreichenden Änderungen erlaubt.

Nutze PIM (eligible assignments), wenn:

• die Rolle privilegiert ist (Owner, User Access Administrator, Contributor auf breitem Scope),
• der Zugriff nur sporadisch benötigt wird (Break/Fix, Notfall, Change-Fenster),
• du Begründung, Ticket-Referenz, Genehmigung oder MFA bei Aktivierung erzwingen willst.

Praxis: Rollenmodell auf Plattform-Ebene

Ein pragmatisches Modell trennt typischerweise:

• Plattformbetrieb: Contributor/Owner nur über PIM, Scope so hoch wie nötig (häufig Subscription oder definierte Plattform-RGs).
• Security/Governance: Policy Contributor / Resource Policy Contributor, ggf. Security Reader/Administrator – privilegierte Rollen ebenfalls über PIM.
• Workload-Teams: Contributor auf der Workload-RG oder Subscription, aber ohne Berechtigung, Rechte zu delegieren.

Ein häufig unterschätzter Sonderfall ist User Access Administrator: Diese Rolle erlaubt Rechtevergabe und ist in der Praxis oft kritischer als Owner auf einem kleineren Scope.

Welche Rollen sind “wirklich” privilegiert?

Als Faustregel sind Rollen privilegiert, wenn sie (a) Rechte delegieren können oder (b) breite Änderungen erlauben. Typische Kandidaten für PIM:

• Owner
• User Access Administrator
• Contributor auf Subscription/Management Group
• Security Admin / Privileged Role Admin (Entra)
• Rollen, die Sicherheitskontrollen ändern können (z. B. Policy-/RBAC-Administratoren je nach Setup)

Rollen wie Reader/Monitoring Reader sind meist dauerhaft vertretbar – aber auch hier gilt: Scope klein halten.

Ablauf in der Praxis: Change → Aktivierung → Nachweis

Ein praxistauglicher Workflow für privilegierte Änderungen:

1. Change/Ticket beschreibt Scope und Ziel.
2. Rolle wird via PIM aktiviert (Begründung = Ticket-ID).
3. Änderung wird durchgeführt (IaC bevorzugt).
4. Aktivierung endet automatisch; Logs bleiben als Nachweis.

Das klingt banal, verhindert aber die häufigsten Audit-Probleme (“Wer war wann Owner und warum?”).

Konfigurationsempfehlungen für PIM

• Maximale Aktivierungsdauer: kurz halten (z. B. 1–4 Stunden für Betriebsrollen).
• Begründungspflicht: aktivieren; idealerweise mit Change/Ticket-ID.
• Genehmigung: für besonders kritische Rollen (Owner/UAA auf Management Group) sinnvoll.
• Benachrichtigungen: an ein zentrales Security-Postfach/Channel.
• Access Reviews: regelmäßig für eligible und active Zuweisungen.

Zusätzlich sinnvoll (je nach Reifegrad):

• “Require MFA on activation” für privilegierte Rollen
• Aktivierungen nur von compliant Geräten für Admin-Rollen (über Conditional Access für Admin-Portale)
• Benachrichtigungen nicht nur an Security, sondern auch an Plattform-On-Call (damit Aktivierungen in Incidents nicht “unsichtbar” bleiben)

Break-Glass und Betriebsrealität

In realen Umgebungen brauchst du Notfallpfade. Übliche Bausteine:

• Break-Glass-Accounts (stark geschützt, überwacht, getrennt von normaler Nutzung) – nicht in täglicher Routine verwenden.
• Outage-Szenario: Wenn PIM/Entra eingeschränkt ist, muss klar sein, wie kritische Betriebsaufgaben trotzdem möglich sind.

Anti-Patterns

• Owner/Contributor auf Subscription dauerhaft für viele Personen.
• PIM ohne Monitoring: Aktivierungen passieren, aber niemand sieht es.
• Zu breite Scopes “für den Komfort” (Management Group Owner für alltägliche Tasks).

Troubleshooting: Wenn “es geht nicht”

• 403 trotz Rollenaktivierung: Token neu holen (Ab-/Anmelden), ggf. warten (Propagation). Prüfe Scope (richtige Subscription/RG?).
• Portal zeigt Rolle aktiv, CLI nicht: az account clear bzw. erneute Anmeldung; bei mehreren Tenants/Subscriptions auf Kontext achten.
• Vererbungen unerwartet: RBAC ist scope-basiert; eine Zuweisung auf Management Group wirkt in Subscriptions darunter.

Wenn 403 weiter besteht, prüfe auch den Data-Plane-Aspekt: z. B. Storage/Key Vault benötigen oft zusätzliche Data-Plane-Rollen, selbst wenn Management-Plane-Rechte vorhanden sind.