Microsoft Entra ID und Azure RBAC bei STACKIT

Die Migration der Reihe nach

1. 01

   1. Prinzipale und Zuweisungen erfassen

   Listen Sie jede Rollenzuweisung mit Prinzipal, Rolle und Scope auf, zum Beispiel mit az role assignment list. Eine Azure-Rollenzuweisung besteht aus Sicherheitsprinzipal, Rollendefinition und Scope; die Inventarliste hat diese drei Spalten je Zeile.

2. 02

   2. Entra ID für Personen behalten, wenn gewünscht

   STACKIT unterstützt die Föderation mit Entra ID: Die Dokumentation verweist die meisten Entra-Kunden auf die STACKIT Enterprise App und beschreibt für die übrigen Fälle eine eigene OpenID-Connect-Föderation. Mitarbeitende melden sich dann mit ihrer Entra-Identität bei STACKIT an, und der Tenant bleibt der Ort, an dem Ein- und Austritte gepflegt werden.

3. 03

   3. Das Scope-Modell festlegen

   Azure-Scopes sind Management-Gruppe, Subscription, Ressourcengruppe und Ressource. STACKIT-Rollen werden auf Organisations-, Ordner- und Projektebene gebunden. Management-Gruppen entsprechen Ordnern; wie Subscriptions und Ressourcengruppen auf Projekte abgebildet werden, ist eine Designentscheidung, die der Lauf als offen führt.

4. 04

   4. Rollenbindungen neu aufbauen

   Jede Azure-Zuweisung wird eine STACKIT-Rollenbindung für Benutzer, Gruppe oder Service Account. Azure-Rollen werden nicht namentlich übernommen; jede wird auf die Rollen abgebildet, die STACKIT für das Produkt dokumentiert.

5. 05

   5. Workloads Service Accounts geben

   Managed Identities und die Service Principals hinter Automatisierung werden zu Service Accounts, mit Schlüssel oder mit Workload Identity Federation.

6. 06

   6. Code anpassen, der die Managed Identity nutzte

   Code, der Tokens über DefaultAzureCredential bezog, braucht STACKIT-Zugangsdaten oder Föderation. Das ist eine Änderung in jedem Verbraucher, die der Lauf je Identität markiert.

7. 07

   7. Je Rolle einen Prinzipal testen

   Melden Sie sich als Benutzer mit jeder Rolle und als jeder Service Account an und bestätigen Sie, was erlaubt und was verwehrt ist, bevor die Azure-Zuweisungen entfernt werden.

Entra-ID- und RBAC-Objekte und ihr Ziel

Klassen aus dem Demo-Lauf vom 4. November 2026. Die mittlere Spalte stammt aus der unter den Quellen genannten STACKIT-Dokumentation.

Eine Managed Identity wird zum Service Account

Eine kleine Umgebung, für diese Seite geschrieben. Links: die User-assigned Identity. Rechts: der Block des Entwurfs, ohne die Prüfkommentare, die in der Datei darüber stehen.

resource "azurerm_user_assigned_identity" "worker" {
  name                = "id-report-worker"
  location            = azurerm_resource_group.platform.location
  resource_group_name = azurerm_resource_group.platform.name
}

resource "stackit_service_account" "worker" {
  project_id = var.project_id
  name       = "worker"
}

• Der Name ändert sich

  Der Quellname id-report-worker wird nicht übernommen; der Entwurf benennt das Konto nach der Ressourcenadresse. Benennen Sie es um, wenn Clients oder Runbooks den alten Namen suchen.

• Es kommen keine Berechtigungen mit

  Ein neuer Service Account hat standardmäßig keinen Zugriff auf Ressourcen. Die Rollenbindungen, die der Azure-Identität Zugriff auf Storage gaben, sind der nächste Schritt und nicht im Entwurf.

• Vier Einstellungen bleiben offen

  Der Bericht führt Ressourcengruppen-Scope, Code ohne hinterlegte Zugangsdaten, Rollenzuweisungen und Standortresidenz als Punkte, die eine Person entscheidet. Ein Service Account hat keine eigene Region; die Residenz prüfen Sie gegen die Region des Projekts.

Gruppen und App-Registrierung, bewertet

Aus demselben Lauf. Links: zwei Sicherheitsgruppen und eine Anwendungsregistrierung. Rechts: die ersten sechs Zeilen der Wellentabelle, die der Lauf dafür geschrieben hat.

resource "azuread_group" "platform_admins" {
  display_name     = "platform-admins"
  security_enabled = true
}

resource "azuread_group" "report_readers" {
  display_name     = "report-readers"
  security_enabled = true
}

resource "azuread_application" "portal" {
  display_name = "customer-portal"
}

wave,wave_state,unit,type,module_call,presence,class,confidence,application,application_status,proposed_group
1,MEMBER,azuread_application.portal,azuread_application,,KNOWN_PRESENT,MANUAL_REVIEW,LOW,,UNASSIGNED,
1,MEMBER,azuread_group.platform_admins,azuread_group,,KNOWN_PRESENT,REDESIGN,MEDIUM,,UNASSIGNED,
1,MEMBER,azuread_group.report_readers,azuread_group,,KNOWN_PRESENT,REDESIGN,MEDIUM,,UNASSIGNED,
1,MEMBER,azurerm_storage_account.reports,azurerm_storage_account,,KNOWN_PRESENT,REPLATFORM,MEDIUM,,UNASSIGNED,
1,MEMBER,azurerm_user_assigned_identity.worker,azurerm_user_assigned_identity,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,,UNASSIGNED,

• Für Gruppen gibt es keine Zielressource

  Der Lauf stellt fest, dass die Rollenzuweisungs-Ressourcen des fest versionierten Providers je ein Subjekt nehmen und dass es keine Ressource gibt, die eine Prinzipalgruppe anlegt. Den Zugriff einer Gruppe nachzubilden heißt: eine Bindung je Mitglied, oder die Gruppe aus Ihrem Identitätsanbieter föderieren.

• Die Plattformdokumentation nennt Gruppen

  Die STACKIT-Seite zur Zugriffssteuerung führt Gruppen neben Benutzern und Service Accounts als Subjekte von Rollenbindungen, und die Entra-SCIM-Anleitung bildet Anzeigename und Mitglieder von Gruppen ab. Ob eine bereitgestellte Gruppe Ihre Rollenbindungen tragen kann, sollten Sie einmal testen, bevor Sie darauf aufbauen.

• Die App-Registrierung hängt von ihrer Verwendung ab

  Ein Workload, der Azure-APIs aufruft, wird zum Service Account mit Schlüssel oder föderierter Identität. Eine Anmelde-Anwendung bleibt in Entra ID mit neuen Redirect-URIs. Eine Pipeline-Identität zieht mit der Pipeline um. Welcher Fall zutrifft, zeigt die Konfiguration nicht; deshalb ist die Konfidenz LOW.

Rollenzuweisungen: gelistet, nicht übersetzt

Aus demselben Lauf. Links: die drei Rollenzuweisungen der Demo. Rechts: wie der Lauf sie zusammen mit Ressourcengruppe und benutzerdefinierter Rolle in der Terraform-README festhält, nämlich als Hilfsressourcen, die keine Einheit liest.

resource "azurerm_role_assignment" "admins_owner" {
  scope                = azurerm_resource_group.platform.id
  role_definition_name = "Contributor"
  principal_id         = azuread_group.platform_admins.object_id
}

resource "azurerm_role_assignment" "readers_blob" {
  scope                = azurerm_storage_account.reports.id
  role_definition_name = "Storage Blob Data Reader"
  principal_id         = azuread_group.report_readers.object_id
}

resource "azurerm_role_assignment" "worker_operator" {
  scope              = azurerm_resource_group.platform.id
  role_definition_id = azurerm_role_definition.report_operator.role_definition_resource_id
  principal_id       = azurerm_user_assigned_identity.worker.principal_id
}

| Source | Kind | Read by |
|---|---|---|
| `azurerm_resource_group.platform` | support resource | `azurerm_storage_account.reports`, `azurerm_user_assigned_identity.worker` |
| `azurerm_role_assignment.admins_owner` | support resource | no unit of the source reads it |
| `azurerm_role_assignment.readers_blob` | support resource | no unit of the source reads it |
| `azurerm_role_assignment.worker_operator` | support resource | no unit of the source reads it |
| `azurerm_role_definition.report_operator` | support resource | no unit of the source reads it |

• Ihre Einstellungen erreichen trotzdem die Prüfung

  Der Architektenbericht führt 16 kritische Einstellungen der fünf Hilfsressourcen auf: Prinzipal, Rolle und Scope jeder Zuweisung sowie Scopes, Name und Berechtigungen der benutzerdefinierten Rolle, jede als Prüfpunkt geschlossen. Der Lauf formuliert die Fragen, nicht die Antworten.

• Die Landing-Zone-Liste zählt eine Bindung

  migration/landing-zone-requirements.md zählt eine stackit_authorization_project_role_assignment, die einer Quelleinheit (der Managed Identity) zugeordnet ist, aber von keinem Block angelegt wird; für sie muss also noch nichts freigeschaltet oder auf Kontingente angerechnet werden. Der Provider ordnet diese Ressource einem zuschaltbaren Feature zu, das sich noch deutlich ändern kann; der Lauf lässt die Identitätseinheit deshalb von einer Person prüfen.

• Die Bindungen als Tabelle planen

  Ein Tabellenblatt aus Azure-Prinzipal, Azure-Rolle, Scope, STACKIT-Subjekt, STACKIT-Rolle und Ebene ist das Arbeitsergebnis. Prüfer zeichnen es ab, bevor jemand eine Bindung anwendet.

Personen: föderieren und bereitstellen

1. 01

   OIDC-Föderation

   Für eine eigene OIDC-Föderation registrieren Sie in Entra ID eine Anwendung mit der Redirect-URL des STACKIT-Identitätsanbieters und fügen ID-Token-Claims für E-Mail, Nachname, Vorname und bevorzugten Benutzernamen hinzu. Bei STACKIT eröffnen Sie ein Supportticket mit Föderationstyp, E-Mail-Domänen und Modus der Benutzeranlage und übermitteln Client-ID, Secret, Scopes und Tenant-ID.

2. 02

   Benutzer automatisch anlegen oder nicht

   Bei aktivierter automatischer Anlage entstehen Benutzer bei der ersten erfolgreichen Anmeldung. Ist sie deaktiviert, müssen sie vorher existieren, etwa durch SCIM-Bereitstellung.

3. 03

   SCIM für Benutzer und Gruppen

   Die Bereitstellung bildet bei Benutzern userName, mail, Namen und objectId ab, bei Gruppen Anzeigename, Mitglieder und objectId. STACKIT lehnt unerwartete Attribute mit HTTP 400 ab; bilden Sie also nur ab, was erwartet wird.

4. 04

   Die E-Mail-Adresse ist der Schlüssel

   Konten sind an E-Mail-Adressen gebunden. Ein späterer Wechsel des Föderationstyps ist nahtlos, solange die Adressen gleich bleiben.

Workloads: Service Accounts

1. 01

   Zwei Wege zur Authentifizierung

   Ein Service Account kann Workload Identity Federation nutzen, die einem externen OIDC-Aussteller vertraut und kurzlebige Tokens ausgibt, oder einen Schlüssel. Die Dokumentation nennt den privaten Schlüssel hochsensibel: Halten Sie ihn aus dem Quellcode heraus.

2. 02

   An Server angehängt

   Ein Service Account kann an einen Server gehängt werden, sodass Anwendungen kurzlebige Tokens vom Metadatendienst erhalten, ohne gespeicherte Zugangsdaten. Das Anhängen braucht die Act-as-Berechtigung auf das Konto und eine Server-Berechtigung.

3. 03

   Kein Standardzugriff

   Service Accounts starten ohne Zugriff. Vergeben Sie projektbezogene Rollen mit den Bindungen aus Ihrer Tabelle.

Entscheidungen Ihrer Architekten

• Entra als Identitätsanbieter oder nicht

  Behalten ist der kürzeste Weg für Personen; die Identitätsverwaltung selbst zu verlagern ist ein eigenes Projekt.

• Projektaufbau

  Was aus Subscription und Ressourcengruppe wird: ein Projekt je Umgebung ist ein üblicher Anfang.

• Gruppenstrategie

  Per SCIM bereitgestellte Gruppen, eine Bindung je Person oder eine Mischung.

• Schlüssel oder Föderation

  Je Workload ein Schlüssel mit Rotation oder Föderation mit einem externen Aussteller.

• Residenz der Identitäten

  Bestätigen Sie, dass die Projektregion Ihre Anforderung erfüllt; Service Accounts haben keine eigene.

Fragen zu Entra ID und RBAC

Quellen

• Was ist Azure RBAC? (Microsoft Learn)
• STACKIT-Dokumentation: Zugriffssteuerung
• STACKIT-Dokumentation: Service Accounts
• STACKIT-Dokumentation: Service Account an Server anhängen
• STACKIT-Dokumentation: Leitfaden zur Föderation mit Microsoft Entra ID
• STACKIT-Dokumentation: Identitätsbereitstellung mit Entra ID