Seminar Entra ID Cloud Exit – Workload-Identitäten entkoppeln

Viele Cloud-Abhängigkeiten liegen außerhalb interaktiver Benutzeranmeldungen. Hintergrunddienste, Sicherungsjobs und Pipelines können nach einer scheinbar erfolgreichen SSO-Migration weiterhin Entra-Token benötigen. Das Seminar erfasst diese Verbindungen und trennt die Identität des aufrufenden Prozesses von den Anforderungen der Zielressource.

Im Labor wird ein nicht interaktiver Zugriff auf eine eigene API auf ein unabhängiges Vertrauensmodell umgestellt. Azure Managed Identities lassen sich nicht als fertige Identitäten in einen anderen Identity Provider exportieren. Auch eine externe Workload-Föderation zu Entra bleibt für die damit erreichten Azure-Dienste Teil einer Entra-abhängigen Zugriffskette.

Inhaltsübersicht

1. Inventar technischer Identitäten
2. Zielressourcen und Restabhängigkeiten
3. Unabhängige Maschinenidentität
4. Pipelines und Automatisierung
5. Rotation und Störungsfälle
6. Abnahme und Stilllegungsplan

Lernziele

• Nicht interaktive Zugriffe samt Zielressourcen und Berechtigungen inventarisieren.
• Portable Authentifizierungswege von verbleibenden Azure-Abhängigkeiten unterscheiden.
• Einen Dienstzugriff auf einen unabhängigen Tokenaussteller umstellen.
• Rotation, Sperrung und Fehlerverhalten einer Maschinenidentität praktisch nachweisen.

Seminarinhalte

Inventar technischer Identitäten

• App-Registrierungen, Service Principals, Managed Identities und Hintergrundjobs erfassen.
• Eigentümer, Zielressource, Ausführungsort und benötigte Rechte einer Zugriffskette zuordnen.
• Zertifikatslaufzeiten, Geheimnisverwaltung und schwer erkennbare periodische Prozesse dokumentieren.

Zielressourcen und Restabhängigkeiten

• Eigene APIs von Azure-Diensten und Microsoft-Graph-Zugriffen unterscheiden.
• Föderierte Identitätsnachweise als Anmeldeverfahren betrachten und die Bindung der Zielressource separat bewerten.
• Ersatz eines Dienstes, Anpassung eines Clients und begrenzten Restbetrieb gegeneinander abwägen.

Unabhängige Maschinenidentität

• Client-Credentials-Zugriff auf eine vorbereitete API über den Ziel-IdP einrichten.
• Audience, Rollen, Scopes und Laufzeiten auf den tatsächlichen Prozessbedarf begrenzen.
• Verfahren mit Geheimnis oder Schlüsselmaterial nach Unterstützung der beteiligten Komponenten auswählen.

Pipelines und Automatisierung

• Dienstzugang in einen vorbereiteten Job oder eine Pipeline integrieren.
• OIDC-Vertrauensbeziehungen nach Issuer, Subject und Audience bewerten und zu weit gefasste Regeln erkennen.
• Konfiguration, Berechtigungsfreigabe und geheime Werte getrennt verwalten; Protokollausgaben auf sensible Inhalte prüfen.

Rotation und Störungsfälle

• Schlüssel oder Zugangsdaten kontrolliert wechseln und den Übergangszeitraum testen.
• Abgelaufene Tokens, falsche Audience und entzogene Berechtigungen als Fehlerfälle ausführen.
• Wiederholversuche und Alarmierung so gestalten, dass ein Identitätsfehler nachvollziehbar bleibt.

Abnahme und Stilllegungsplan

• Den neuen Job ohne den bisherigen Entra-Tokenpfad ausführen und die Ziel-API prüfen.
• Alte Zugangsdaten zunächst kontrolliert sperren und auf verbleibende Zugriffe beobachten.
• Restressourcen und die Voraussetzungen für das Entfernen der bisherigen Identität dokumentieren.

Praxisprojekt

Ein vorbereiteter Dienst beziehungsweise Pipeline-Job wird für den Zugriff auf eine eigene API auf das neue Identitätsmodell umgestellt.

1. Bisherige Zugriffskette samt Zielressource und effektiven Berechtigungen dokumentieren.
2. Eine neue Maschinenidentität mit eng begrenzten Rechten einrichten.
3. Den Testjob umstellen und erlaubte sowie verweigerte API-Aufrufe prüfen.
4. Eine Rotation durchführen und einen ungültigen Anmeldenachweis als Fehlerfall testen.
5. Den alten Zugang im Pilotfall sperren und den weiter funktionierenden Zielzugriff nachweisen.

Arbeitsumgebung

Der Kunde stellt einen vorbereiteten Keycloak-Ziel-IdP, eine eigene Test-API und einen lokalen Runner oder eine Testpipeline bereit. Für die Ausgangsanalyse werden ein Übungstenant und gegebenenfalls eine begrenzte Azure-Testumgebung beziehungsweise Exporte benötigt. Ausführungsumgebung und unterstütztes Authentifizierungsverfahren werden vorab festgelegt.