Microsoft Entra Workload Identities: Nicht-menschliche Identitäten für kleine Unternehmen in Berlin
Microsoft Entra Workload Identities bietet Identitäts- und Zugriffsverwaltung für nicht-menschliche Identitäten: Anwendungen, Dienste, Skripte und Automatisierungsprozesse, die auf Azure-Ressourcen, Microsoft 365-APIs oder andere geschützte Dienste zugreifen müssen. Für kleine Unternehmen in Berlin ist die Herausforderung dieselbe wie für große Unternehmen, aber oft weniger sichtbar: Jeder Dienstprinzipal, jede App-Registrierung und jede verwaltete Identität, die auf Ihren Mandanten zugreift, stellt eine Sicherheitsgrenze dar, die mit derselben Sorgfalt verwaltet werden muss wie menschliche Identitäten.
Das Problem nicht-menschlicher Identitäten
Wenn ein Entwickler ein Skript erstellt, das Daten aus SharePoint abruft, eine Drittanbieter-SaaS-Integration, die Kalenderdaten liest, oder eine Azure-Funktion, die in Azure Storage schreibt, benötigt dieser Code eine Anmeldeinformation zur Authentifizierung. Ohne ordnungsgemäßes Workload-Identitätsmanagement fallen Organisationen typischerweise in eines von zwei Anti-Mustern: die Verwendung eines gemeinsamen Dienstkontos (ein menschliches Benutzerkonto mit einem Passwort, das von der Automatisierung genutzt wird) oder das Einbetten von App-Secrets als Klartext in Code oder Umgebungsvariablen. Beide Muster schaffen ernsthafte Sicherheitsrisiken.
Gemeinsame Dienstkonten binden Automatisierung an ein menschliches Konto, das ein nicht ablaufendes Passwort haben muss, das sich jemand merken muss und das menschliche Berechtigungen gewährt anstatt der minimalen Berechtigungen für die spezifische Aufgabe. In Secrets eingebetteter Code landet regelmäßig in Versionsverwaltungsrepositorys, Deployment-Artefakten und Log-Dateien, wo er von Angreifern entdeckt wird, die öffentliche Repositories nach exponierten Anmeldeinformationen durchsuchen.
App-Registrierungen und Dienstprinzipale
Eine Entra ID-App-Registrierung erstellt eine Identität für eine Anwendung in Ihrem Mandanten. Die App-Registrierung definiert, was die Anwendung ist, welche Berechtigungen sie hat und wie sie sich authentifizieren kann. Der entsprechende Dienstprinzipal ist die Instanziierung dieser App-Registrierung in Ihrem Mandanten. Dienstprinzipale authentifizieren sich entweder mit Client-Secrets (zeitlich begrenzte Passwörter) oder Zertifikaten. Zertifikate sind deutlich sicherer als Client-Secrets, weil sie den Besitz des privaten Schlüssels erfordern, nicht nur das Wissen eines Strings, und weil sie mit kontrolliertem Zugriff in Azure Key Vault gespeichert werden können.
Die Berechtigungsbereiche für Dienstprinzipale folgen dem Prinzip der minimalen Berechtigungen: Statt einem Dienstprinzipal globale Administrator- oder weitreichende Graph-API-Berechtigungen zu gewähren, werden nur die spezifischen Microsoft Graph-Berechtigungsbereiche gewährt, die für die spezifische Operation erforderlich sind. Entra ID Workload Identities bietet Tools zur Überprüfung und Prüfung von Berechtigungsbereichen, die Dienstprinzipalen im gesamten Mandanten zugewiesen sind, und identifiziert übermäßig privilegierte App-Identitäten.
Verwaltete Identitäten: Credential-Management eliminieren
Verwaltete Identitäten sind der sicherste Ansatz zur Authentifizierung von Azure-Workloads an Azure-Ressourcen, weil sie das Credential-Management vollständig eliminieren. Wenn Sie eine verwaltete Identität auf einer Azure-Ressource aktivieren (eine VM, App Service, Azure-Funktion, Logik-App usw.), erstellt Azure automatisch einen Dienstprinzipal für diese Ressource und verwaltet die Credential-Rotation transparent. Der Anwendungscode authentifiziert sich mit der verwalteten Identität — er ruft den Azure Instance Metadata Service (IMDS) auf, um ein Token zu erhalten, das für die Authentifizierung an der Zielressource verwendet wird.
Systemseitig zugewiesene verwaltete Identitäten sind an den Lebenszyklus der spezifischen Azure-Ressource gebunden — wenn die Ressource gelöscht wird, wird die Identität automatisch gelöscht. Benutzerseitig zugewiesene verwaltete Identitäten sind eigenständige Identitätsressourcen, die mehreren Azure-Ressourcen zugewiesen werden können. Für ein kleines Berliner Unternehmen, das Azure App Services oder Azure-Funktionen betreibt, die auf Key Vault, Azure Storage oder Azure SQL zugreifen müssen, ist die Aktivierung der verwalteten Identität auf der Compute-Ressource und die Gewährung dieser Identität der minimal erforderlichen Rolle das empfohlene Muster, das das Verwalten von Anwendungsanmeldeinformationen vollständig eliminiert.
Workload Identity Federation
Workload Identity Federation erweitert das Konzept der verwalteten Identität auf Nicht-Azure-Umgebungen: GitHub Actions-Pipelines, GitLab CI/CD, Kubernetes-Cluster und andere Identity Provider, die OIDC-Token unterstützen. Anstatt ein Client-Secret für einen Dienstprinzipal zu erstellen und es als GitHub Actions-Secret zu speichern, konfigurieren Sie eine Federated-Identity-Credential, die Token vertraut, die von GitHubs OIDC-Provider für Ihr spezifisches Repository und Ihren Workflow ausgestellt werden.
Für ein Berliner Entwicklungsteam, das GitHub Actions für die Bereitstellung von Azure-Infrastruktur verwendet, bedeutet Workload Identity Federation, dass die CI/CD-Pipeline sich mit einem kurzlebigen OIDC-Token bei Azure authentifiziert anstatt mit einem langlebigen Client-Secret in GitHub Secrets. Es gibt kein Secret mehr, das rotiert werden muss, kein Secret, das versehentlich in Logs exponiert wird, und kein Secret, das in der Repository-Historie entdeckt werden kann. Dieser Ansatz reduziert das Risiko von Credential-Kompromittierung in DevOps-Workflows erheblich, die ein primäres Ziel für Supply-Chain-Angriffe geworden sind.
Governance: App-Registrierungs-Lebenszyklusmanagement
App-Registrierungen akkumulieren sich im Laufe der Zeit in Entra ID-Mandanten: Entwickler erstellen Registrierungen für Tests, Integrationen werden eingerichtet und aufgegeben, und Drittanbieter-Apps werden durch OAuth-Einwilligungen von Benutzern autorisiert. Jede aufgegebene Registrierung mit aktiven Anmeldeinformationen oder Berechtigungen stellt eine verbleibende Angriffsfläche dar. Regelmäßige Governance-Überprüfungen — Identifizierung von App-Registrierungen ohne aktuelle Anmeldeaktivität, bald ablaufenden Anmeldeinformationen oder übermäßig breiten Berechtigungen — sind eine Wartungsanforderung für die Workload-Identitätssicherheit.
Microsofts Anwendungsverwaltungsrichtlinien ermöglichen es Administratoren, einzuschränken, welche Benutzer App-Registrierungen erstellen können, Admin-Einwilligung für Anwendungsberechtigungsbereiche zu verlangen und Ablaufrichtlinien für Anmeldeinformationen anzuwenden, um sicherzustellen, dass Client-Secrets regelmäßig rotiert werden. Für Berliner Unternehmen mit Microsoft 365 E3 oder E5-Lizenzierung sind diese Governance-Kontrollen nativ in Entra ID verfügbar.
Weiterführende Artikel
- Microsoft Entra Conditional Access: Workload Identities Premium erweitert Conditional-Access-Richtlinien auf Dienstprinzipale — die Einschränkung, aus welchen Netzwerken sich ein Dienstprinzipal authentifizieren darf, und die Warnung bei anomalen Authentifizierungsmustern bietet denselben standortbasierten und risikobasierten Zugriffschutz für nicht-menschliche Identitäten, den Conditional Access für menschliche Benutzerkonten bietet
- Microsoft Azure Key Vault: Verwaltete Identitäten und Key Vault bilden das empfohlene Credential-Eliminierungsmuster für Azure-Workloads — anstatt Verbindungszeichenfolgen oder Client-Secrets in der Anwendungskonfiguration zu speichern, authentifizieren sich Anwendungen mit ihrer verwalteten Identität und rufen Secrets zur Laufzeit aus Key Vault ab, wodurch Klartext-Anmeldeinformationen aus Code, Konfigurationsdateien und Deployment-Artefakten vollständig eliminiert werden
