Was ist Azure Entra ID? — Identitäten, Rollen und das mentale Modell das du wirklich brauchst

Warum Identity mehr ist als ein Login

Stell dir vor, du hast 50 Azure Functions in Produktion. Alle verbinden sich mit demselben Storage Account — über einen Connection String, den jemand vor zwei Jahren in die App Settings geklebt hat. Jetzt rotiert das Security-Team die Storage Keys. Was passiert?

Alle 50 Functions brechen zusammen. Gleichzeitig. In Produktion.

Das ist kein Extrembeispiel. Das passiert. Und es passiert, weil viele Entwickler Identity in Azure immer noch so denken wie vor zehn Jahren: Username, Passwort, fertig. In der Cloud ist das nicht nur falsch — es ist gefährlich.

Azure Entra ID ist das Fundament, das verhindert, dass solche Szenarien überhaupt entstehen. Aber nur, wenn man versteht, wie es wirklich funktioniert — nicht nur, wo man im Portal klickt.

Dieser Post ist kein Walkthrough. Es gibt keine Screenshots. Was du hier bekommst, ist das mentale Modell, das du brauchst, um sichere Architekturen zu bauen, Fehler zu diagnostizieren und sofort echten Wert in deiner Organisation zu liefern.

Was ist Azure Entra ID? — Kompakt erklärt

Seit 2023 heißt Azure Active Directory offiziell Microsoft Entra ID. Das ist mehr als ein Rebranding. Es signalisiert, dass Microsoft Identity als eigenständige, cloud-native Disziplin positioniert — unabhängig von der klassischen Active Directory-Welt.

Entra ID ist der Identity-Backbone für alles was Microsoft Cloud heißt: Microsoft 365, Azure-Ressourcen, externe SaaS-Apps, und zunehmend auch für nicht-menschliche Identitäten wie Agents, Pipelines und Dienste.

Die wichtigste Abgrenzung zuerst: Entra ID ist kein Ersatz für on-premise Active Directory. Es ist eine andere Technologie. On-premise AD arbeitet mit Kerberos, LDAP und Group Policy. Entra ID arbeitet mit OAuth 2.0, OpenID Connect und REST-APIs. Die Protokolle sind grundlegend verschieden. Wer das verwechselt, baut Hybrid-Architekturen, die nicht das machen, was er denkt.

Die Entra-Produktfamilie besteht aus mehreren Teilen:

Entra ID ist der Kern — Authentifizierung, Autorisierung, SSO und MFA für deine Organisation. Alles andere baut darauf auf.

Entra Workload ID ist die Erweiterung für nicht-menschliche Identitäten — Apps, Services, Agents. Genau das, was in Post 3 dieser Serie im Mittelpunkt steht.

Entra ID Governance automatisiert Access Lifecycle Management — wer bekommt wann welche Rechte, und wer überprüft das regelmäßig.

Entra External ID ist für externe Szenarien — Kunden, Partner, B2B-Kollaboration.

Für diesen Post konzentrieren wir uns auf Entra ID als Kern und die Konzepte, die du täglich brauchst.

Das Tenant-Konzept — das Fundament für alles andere

Bevor Identitäten, Rollen und Tokens Sinn ergeben, muss ein Konzept sitzen: der Tenant.

Ein Tenant ist eine dedizierte, vollständig isolierte Instanz von Entra ID für deine Organisation. Wenn du dich bei Azure anmeldest, hat Microsoft automatisch einen Tenant für dich erstellt. Alles, was du in Azure tust — jede Ressource, jede Identität, jeder Zugriff — existiert innerhalb dieses Tenants.

Die wichtigste Eigenschaft eines Tenants ist die Isolation. Identitäten aus Tenant A können nicht auf Ressourcen in Tenant B zugreifen, ohne explizite Konfiguration. Das ist kein Bug, das ist das Sicherheitsmodell.

Die Beziehung zwischen Tenants und Subscriptions verwirrt viele am Anfang, also klar und direkt: ein Tenant kann mehrere Azure Subscriptions verwalten. Eine Subscription gehört immer zu genau einem Tenant. Subscription und Tenant sind nicht dasselbe.

Eine gute Metapher: Der Tenant ist das Firmengebäude. Die Subscriptions sind die Etagen. Die Resource Groups sind die Abteilungen auf jeder Etage. Die einzelnen Ressourcen sind die Zimmer. Der Sicherheitsdienst am Eingang — das ist Entra ID.

Wann brauchst du mehrere Tenants? In der Praxis seltener als man denkt. Typische Szenarien: vollständig getrennte Konzerngesellschaften, strikte regulatorische Anforderungen die Datentrennung vorschreiben, oder Partner-Szenarien mit B2B-Kollaboration. Für Prod/Dev-Trennung reichen Subscriptions — kein eigener Tenant nötig.

Identitätstypen: Wer — oder was — hat Zugriff?

In Entra ID gibt es nicht nur Benutzer. Es gibt eine Taxonomie von Identitäten, und das Verständnis dieser Taxonomie ist der Unterschied zwischen einer sicheren und einer unsicheren Architektur.

RBAC — Das Rechtesystem von Azure

Role-Based Access Control ist das Autorisierungsmodell von Azure. Jeder Zugriff auf jede Azure-Ressource läuft über RBAC. Das Modell ist elegant einfach: es besteht aus genau drei Elementen.

Security Principal — Wer fragt an? Das kann ein User, eine Group, ein Service Principal oder eine Managed Identity sein.

Role Definition — Was darf der Principal tun? Eine Role Definition ist eine Sammlung von Berechtigungen, ausgedrückt als Actions (Management-Operationen) und DataActions (Daten-Operationen). Die Unterscheidung ist wichtig:

Scope — Auf welcher Ebene gilt die Zuweisung? Azure hat vier Scope-Ebenen, vom Allgemeinen zum Spezifischen: Management Group → Subscription → Resource Group → einzelne Ressource. Berechtigungen werden entlang der Hierarchie nach unten weitergegeben. Eine Rolle auf Subscription-Ebene gilt automatisch für alle Resource Groups und Ressourcen darunter.

Das Zusammenführen dieser drei Elemente nennt sich Role Assignment. Ein Role Assignment sagt: „Dieser Principal (Managed Identity der Function App) darf diese Aktionen (Storage Blob Data Reader) auf diesem Scope (Storage Account rg-prod/sa-data) ausführen."

Eine wichtige Empfehlung: Scope immer so spezifisch wie möglich wählen. Eine Managed Identity, die nur einen bestimmten Blob Container lesen muss, bekommt die Rolle auf Container-Ebene — nicht auf Subscription-Ebene. Das klingt nach Mehraufwand, ist aber der Unterschied zwischen einer sicheren und einer kompromittierbaren Architektur.

Das RBAC-Modell ist additiv. Wenn ein Principal mehrere Rollen hat, ist die effektive Berechtigung die Summe aller Rollen. Es gibt keine implizite Deny-Logik außer durch explizite Deny Assignments, die selten genutzt werden.

Eine letzte wichtige Abgrenzung: Azure RBAC ≠ Entra ID Roles. Azure RBAC steuert den Zugriff auf Azure-Ressourcen (Storage, VMs, Key Vault usw.). Entra ID Roles steuern den Zugriff auf das Verzeichnis selbst (User verwalten, Rollen zuweisen, Apps registrieren). Beide Systeme existieren parallel. Ein Global Administrator in Entra ID kann nicht automatisch Daten aus einem Storage Account lesen — dafür braucht er eine Azure RBAC-Rolle.

{
  "Name": "Storage Blob Reader (Custom)",
  "Description": "Liest Blobs aus definierten Containern. Kein Schreiben, kein Management.",
  "Actions": [],
  "NotActions": [],
  "DataActions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{deine-subscription-id}"
  ]
}

# Custom Role erstellen
az role definition create --role-definition role-storage-reader.json

# Role auf eine Managed Identity zuweisen
az role assignment create \
  --assignee <object-id-der-managed-identity> \
  --role "Storage Blob Reader (Custom)" \
  --scope /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{sa}

Wie Authentifizierung wirklich funktioniert — Token und Flows

Entra ID gibt keine Sessions aus. Es gibt Tokens aus — genauer gesagt JSON Web Tokens (JWTs). Alles läuft über Tokens. Wer das Prinzip dahinter versteht, kann Authentifizierungsprobleme deutlich schneller einordnen und gezielt an der richtigen Stelle suchen.

OAuth 2.0 Flows — welcher wann?

OAuth 2.0 ist kein einzelnes Protokoll — es ist eine Familie von Flows. Die drei wichtigsten:

Authorization Code Flow — für menschliche Benutzer. Der User wird zum Entra ID Login weitergeleitet, meldet sich an, und die App erhält einen Authorization Code, den sie gegen ein Token tauscht. MFA, Conditional Access — alles greift hier.

Client Credentials Flow — für Apps ohne User-Kontext. Die App authentifiziert sich direkt mit ihrer eigenen Identität (Client ID + Secret, Zertifikat oder Managed Identity). Kein User involviert. Das ist der Flow für Background-Services, Agents und automatisierte Prozesse.

On-Behalf-Of Flow — für Delegation. Service A hat ein User-Token und möchte damit Service B aufrufen. Service A tauscht das User-Token gegen ein neues Token für Service B — der User-Kontext bleibt erhalten.

Für alles was automatisiert läuft — und das ist der Großteil moderner Cloud-Architekturen — ist Client Credentials der richtige Flow.

Token Refresh — proaktiv vs. reaktiv

Proaktiver Refresh — Die App prüft vor jedem API-Call, ob das Token bald abläuft (z.B. weniger als 5 Minuten übrig), und holt sich vorher still ein neues. Der User sieht nie einen 401 und kein Request schlägt fehl. Die Microsoft Authentication Library (MSAL), die bei Azure-Apps typischerweise zum Einsatz kommt, macht genau das automatisch.

Reaktiver Refresh — Die App schickt das Token einfach mit, und erst wenn ein 401 zurückkommt, wird refresht und der Request wiederholt. Einfacher zu implementieren, aber der erste Request schlägt fehl und muss wiederholt werden.
* Das Diagramm oben zeigt den reaktiven Weg, da er den Ablauf Schritt für Schritt nachvollziehbar macht.

MSAL kombiniert beide Strategien: Es cached Tokens, prüft den exp-Claim, refresht proaktiv und fällt im Fehlerfall auf den reaktiven Weg zurück. Als Entwickler reicht ein Aufruf von AcquireTokenSilent() — MSAL entscheidet selbst, ob das gecachte Token noch gültig ist oder ein Refresh nötig ist.

Wichtig: Das Refresh Token selbst hat ebenfalls eine Lebensdauer. Bei Entra ID beträgt sie standardmäßig 90 Tage und verlängert sich bei regelmäßiger Nutzung (Sliding Window). Läuft auch das Refresh Token ab, muss sich der User komplett neu anmelden.

Managed Identity: Credentials ohne Credentials

Managed Identity ist die Antwort auf eine Frage, die sich jedes Entwicklungsteam stellen sollte: Warum müssen wir überhaupt Credentials verwalten?

Die Antwort lautet: müssen wir nicht. Nicht wenn die App auf einer Azure-Ressource läuft.

Managed Identity funktioniert über den Azure Instance Metadata Service (IMDS). Das ist ein interner HTTP-Endpunkt unter http://169.254.169.254/metadata/identity/oauth2/token, der nur von innerhalb der Azure-Ressource erreichbar ist. Die App fragt dort ein Token an — IMDS liefert es, Entra ID stellt es aus, kein Secret wird jemals exponiert.

Das SDK abstrahiert das vollständig. DefaultAzureCredential aus dem Azure Identity SDK probiert automatisch verschiedene Authentifizierungsmethoden in Reihenfolge: zuerst Umgebungsvariablen (für lokale Entwicklung), dann Managed Identity (für Produktion), dann Azure CLI Credentials. Derselbe Code funktioniert lokal und in Produktion — ohne Anpassung.

# Connection String aus App Settings — ein rotierter Key bricht alles
import os
from azure.storage.blob import BlobServiceClient

connection_string = os.environ["STORAGE_CONNECTION_STRING"]
client = BlobServiceClient.from_connection_string(connection_string)

# Managed Identity — kein Secret, kein Rotation-Problem, kein Ausfall
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
client = BlobServiceClient(
    account_url="https://{storageaccount}.blob.core.windows.net",
    credential=credential
)

# System-assigned Managed Identity aktivieren
az webapp identity assign \
  --name meine-function-app \
  --resource-group rg-prod

# Object ID der Managed Identity holen
PRINCIPAL_ID=$(az webapp identity show \
  --name meine-function-app \
  --resource-group rg-prod \
  --query principalId -o tsv)

# Storage Blob Data Reader Rolle zuweisen
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/{sub-id}/resourceGroups/rg-prod/providers/Microsoft.Storage/storageAccounts/meinstorage

Praxis: Was du mit drei Skripten sofort herausfindest

Kein Portal-Klick. Kein Screenshot. Drei Skripte die du morgen früh ausführen kannst — und die dir ein klares Bild deiner Umgebung liefern.

# Alle Service Principals mit Owner oder Contributor auf Subscription-Ebene
az role assignment list \
  --scope /subscriptions/{subscription-id} \
  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='Contributor'] | [?principalType=='ServicePrincipal']" \
  --output table

# Alle Function Apps in einer Subscription finden
az functionapp list --query "[].{Name:name, RG:resourceGroup, Identity:identity.type}" --output table

# Nur die ohne Identity
az functionapp list \
  --query "[?identity==null].{Name:name, ResourceGroup:resourceGroup}" \
  --output table

# Alle Role Assignments in einer Subscription als CSV exportieren
Get-AzRoleAssignment | Select-Object `
  DisplayName, `
  ObjectType, `
  RoleDefinitionName, `
  Scope | Export-Csv -Path "rbac-audit-$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation

Write-Host "Export abgeschlossen."

Die 5 häufigsten Fehler — und wie du sie vermeidest

Fazit

Drei Sätze die bleiben sollen:

Managed Identity ist besser als Service Principal ist besser als Connection String. Immer. Ohne Ausnahme.

RBAC ist ein Modell, kein Portal-Feature. Wer das Modell versteht — Principal, Role, Scope — trifft bessere Entscheidungen in Sekunden, nicht nach stundenlangem Suchen im Portal.

Tokens sind das Herzstück. Wer weiß was aud, oid und roles bedeuten, weiß wo er bei einem Problem anfangen muss zu suchen.