Warum Ihre „svc-“-Konten eine tickende Zeitbombe sind

Von Mirko Peters · 2026-08-11

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

Willkommen zurück zum Podcast und zu unserer laufenden Tiefenanalyse der Sicherheitsarchitektur im Unternehmen. Wenn Ihre Organisation dem Durchschnitt entspricht, zeigt ein kurzer Blick in Ihr Active Directory oder Ihr Microsoft Entra ID-Verzeichnis einen wuchernden Friedhof an Konten, die mit „svc-“, „app-“ oder „admin-bot“ beginnen. Diese Konten halten den Betrieb am Laufen, sorgen für den Datenfluss und führen die Automatisierungen aus. Gleichzeitig sind sie aber der mit Abstand größte blinde Fleck in Ihrer modernen Sicherheitslage. In diesem Blogbeitrag vertiefen wir unser jüngstes Gespräch und zeigen, warum klassische Dienstkonten Ihre Zero-Trust-Architektur vollständig untergraben und warum die Migration zu Microsoft Entra Workload Identities der einzige Weg nach vorn ist.

Eine vollständige Audio-Aufschlüsselung dieses Themas finden Sie in unserer begleitenden Podcast-Folge Replace Service Accounts with Entra Workload Identities. Schauen wir uns nun die Mechanik des nicht-menschlichen Risikos an und wie Sie es dauerhaft beseitigen können.

TL;DR

Dienstkonten mit statischen Geheimnissen und weitreichenden Rechten sind Ihre größte Identitätslücke. Workload Identities (in Microsoft Entra ID) geben jedem nicht-menschlichen Akteur eine gesteuerte Identität mit geringsten Rechten, Lebenszyklus, CA-Richtlinien, Rotation und lückenlosen Audit-Protokollen, ohne Ihre Automatisierungen zu unterbrechen.

Warum Dienstkonten versagen (und Zero Trust untergraben)

Das klassische Dienstkonto-Modell wurde für eine Ära von Netzwerkgrenzen entwickelt, die es so nicht mehr gibt. Damals wurde Vertrauen dadurch definiert, ob ein Gerät im Unternehmensnetzwerk angeschlossen war. Ein statisches Kennwort in einer Konfigurationsdatei galt da als vertretbar. Heute ist diese Designphilosophie ein Risiko.

Statische Geheimnisse und keine MFA -> leicht zu stehlen, schwer sicher zu rotieren
Standardmäßig überprivilegiert -> „Hauptsache es läuft“-Berechtigungen werden dauerhaft
Kein Lebenszyklus -> verwaiste oder vergessene Konten überdauern Migrationen und Umstrukturierungen
Geringe Nachvollziehbarkeit -> „Wer hat das wofür genutzt?“ bleibt Raterei und Screenshots
Ausnahmekultur -> CA-/MFA-Ausnahmen für Bots erweitern still Ihre Angriffsfläche

Managed Identities: Ein guter Schritt, aber an Azure gebunden

Wenn Organisationen erkennen, dass statische Dienstkonten gefährlich sind, wenden sie sich oft zunächst den Azure Managed Identities zu. Managed Identities sind ein enormer Fortschritt, weil sie Geheimnisse für Azure-gehostete Ressourcen vollständig eliminieren. Sie haben jedoch klare Grenzen.

✅ Geheimnisfreier Zugriff auf Azure-native Ressourcen (Functions, VMs, Logic Apps)
❌ Lücken bei Hybrid- und Drittanbieter-Zielen, schwache Zuordnung von Verantwortlichkeiten, eingeschränkte Governance-Ansichten
❌ CA- und Berechtigungsabdeckung nicht einheitlich bei Nicht-Azure-Oberflächen

Workload Identities: Was Sie tatsächlich erhalten

Hier kommen die Microsoft Entra Workload Identities ins Spiel. Statt nicht-menschliche Akteure als Bürger zweiter Klasse zu behandeln oder Sie auf Azure-Einschränkungen festzulegen, erheben Workload Identities Anwendungen, Skripte und automatisierte Dienste zu vollwertigen Sicherheitsprinzipalen.

Vollwertige nicht-menschliche Identitäten (Apps, Skripte, Konnektoren, RPA, Integrationen)
Eingegrenzte Berechtigungen (Graph-/Ressourcenrollen, reine App-Authentifizierung) mit geringsten Rechten
Lebenszyklus (Verantwortlicher, Überprüfungsrhythmus, Außerbetriebnahme), verknüpft mit dem Geschäftsprozess
Conditional Access für Workloads (risiko- und kontextabhängige Kontrollen, Sitzungssteuerung, sofern unterstützt)
Credential-Hygiene (kurzlebige Geheimnisse, Zertifikate, Richtlinie zur Schlüsselrotation)
Einheitliche Transparenz (Anmeldungen, Token, Ressourcenzugriff, Änderungsverlauf) -> prüfungsbereit

Vergleichsmatrix (auf einen Blick)

Merkmal	Service Account	Managed Identity	Workload Identity
Geheimnisse	Statische Kennwörter	Ohne Geheimnisse (Azure)	Ohne Geheimnisse/kurzlebig + Rotation
Umfang	Breit / benutzerähnlich	Azure-zentriert	Beliebige Workloads (Apps/Skripte/Konnektoren)
CA / Risiko	Selten angewendet	Eingeschränkt	Richtliniengesteuert, sofern unterstützt
Lebenszyklus	Ad hoc	Einfach	Verantwortlicher + Überprüfungen + Außerbetriebnahme
Audit	Lückenhaft	Azure-Protokolle	Zentrale Anmelde- und Berechtigungshistorie

Architekturmuster (gängige Anwendungsfälle)

Die Umsetzung von Workload-Identitäten erfordert eine korrekte Zuordnung zu Ihren Architekturmustern. Hier sehen Sie, wie sie auf die häufigsten Unternehmens-Workloads angewendet werden:

Power Platform-Konnektoren / Cloud-Flows -> Weisen Sie jeder Integration eine Workload-Identität zu und gewähren Sie nur die benötigten Graph- und Dataverse-Bereiche.
Line-of-Business-Apps (Web-APIs, Daemons) -> App-Registrierung + Zertifikat; verwenden Sie App-Rollen und App-only-Graph-Zugriff; erzwingen Sie Bedingten Zugriff, wo möglich.
Automatisierungsskripte (Azure Automation, GitHub Actions, DevOps) -> Verwenden Sie föderierte Anmeldeinformationen (OIDC) und speichern Sie keine Geheimnisse.
Mandantenübergreifende / B2B-Jobs -> Eine eigene Workload-Identität pro Mandantengrenze; Rechte und Protokollierung isolieren.

Migrations-Playbook (90 Tage, ohne Hektik)

Hunderte alte Dienstkonten zu bearbeiten, kann überwältigend wirken. Deshalb brauchen Sie ein strukturiertes Migrations-Playbook über 90 Tage, das auf die Reduzierung von Risiken ausgerichtet ist.

Phase 1 – Erfassen & Priorisieren (Wochen 0–3)

Erfassen Sie nicht-menschliche Anmeldungen und Objekte: svc-*, app-*, freigegebene Postfächer, App-Registrierungen, Geheimnisse, die in weniger als 90 Tagen ablaufen.
Ordnen Sie jedes Objekt einem Besitzer, einem geschäftlichen Zweck, den Zielen, den Berechtigungen und einer Abhängigkeit vom Notfallzugang zu.
Risikobewertung: statische Kennwörter, globale Rollen, kein Besitzer, keine aktuelle Rotation.

Phase 2 – Zuerst Hochrisiko-Objekte umstellen (Wochen 4–8)

Richten Sie für jede Integration eine eigene Workload-Identität ein (nicht wiederverwenden).
Ersetzen Sie die Kennwortauthentifizierung durch Zertifikate oder föderierte Anmeldeinformationen und legen Sie eine Rotation fest.
Wechseln Sie zu App-only-Berechtigungen und entfernen Sie benutzerdelegierte Berechtigungen, wo sie nicht erforderlich sind.
Wenden Sie Richtlinien für Bedingten Zugriff auf Workload-Anmeldungen an (sofern unterstützt).
Implementieren Sie Zugriffsüberprüfungen (vierteljährlich) sowie die Zuständigkeit im CMDB/ITSM.

Phase 3 – Außerbetriebnahme & Governance (Wochen 9–12)

Deaktivieren Sie alte Dienstkonten, überwachen Sie diese 14 Tage lang und löschen Sie sie anschließend.
Setzen Sie verbindliche Erstellungsstandards durch: Benennung, Besitzer, Datenklassifizierung und Überprüfungsrhythmus.
Richten Sie Warnmeldungen ein für: ungewöhnliche Anmeldungen, inaktive Identitäten seit mehr als 30/60/90 Tagen und ablaufende Geheimnisse.
Verankern Sie Identitätsprüfungen in CI/CD (Policy-as-Code).

Bedingter Zugriff und Berechtigungen (praxisnahe Leitplanken)

Eine der wirkungsvollsten Funktionen moderner Identitätsplattformen ist die Möglichkeit, Leitplanken gezielt für nicht-menschliche Akteure anzuwenden. Indem Sie Richtlinien für Menschen und Workloads trennen, verhindern Sie, dass Bots Warnungen zu unmöglichen Reisen auslösen, und blockieren dennoch schädlichen Datenverkehr.

Getrennte Richtlinien für menschliche und Workload-Identitäten; interaktive Anmeldung für Workloads blockieren.
Benannte Standorte / Netzwerkeinschränkungen für App-only-Zugriff, wo machbar.
Zeitlich begrenzte Berechtigungen (PIM für App-Rollen, sofern verfügbar; geplante Zugriffsüberprüfungen).
Bereiche: Bevorzugen Sie App-Rollen bzw. ressourcenspezifische Rollen gegenüber verzeichnisweiten Rechten.

Protokollierung & Prüfung (was Sie dem Prüfer zeigen sollten)

Wenn Compliance-Beauftragte und Prüfer nachfragen, akzeptieren sie keine Tabellenkalkulationen oder mündlichen Zusicherungen mehr, wer Zugriff auf Backend-Skripte hat. Sie müssen Governance mit zentraler Protokollierung jederzeit nachweisen können.

App-/Workload-Besitzer, Zweck, Datensensibilität
Anmeldeprotokolle (Dienstprinzipal-Anmeldungen), Token-Zielgruppe, IP-Adresse, Client-App
Rollenzuweisungen (wer genehmigt hat, wann zertifiziert wurde)
Verlauf der Anmeldeinformationen (Typ, letzte Rotation, Ablauf)
Lebenszyklus: erstellt/geändert/deaktiviert/gelöscht mit verantwortlicher Person für die Änderung

KPI-Dashboard (Verbesserung nachweisen)

Um die Unterstützung der Führungsebene dauerhaft zu sichern, sollten Sie Leistungskennzahlen erfassen und berichten, die Ihre Risikoreduzierung bei nicht-menschlichen Identitäten im Zeitverlauf belegen.

% nicht-menschliche Identitäten mit Besitzer + Überprüfungsrhythmus (Ziel ≥ 95 %)
Verwaiste Dienstkonten (Ziel -> 0)
Geheimnisse älter als 90 Tage (Ziel -> 0; Zertifikate/föderierte Anmeldeinformationen bevorzugen)
Umfang der App-only-Rollen (Anzahl von „Directory.ReadWrite.All“ -> sinkend)
Prüfungsergebnisse für nicht-menschliche Zugriffe (Quartalsvergleich ↓)

Anti-Muster, die Sie beseitigen sollten

Während Sie Ihre Umgebung bereinigen, achten Sie darauf, dass Ihre Teams nicht in alte Gewohnheiten zurückfallen. Beseitigen Sie diese Anti-Muster umgehend:

Ein einzelnes generisches Dienstkonto über viele Systeme hinweg wiederverwenden
Passwörter in Skripten, web.config oder Key Vault ohne Rotationsrichtlinie hinterlegen
Global Admin / Owner „für alle Fälle“ vergeben, damit Jobs weiterlaufen
„Vorübergehende“ Ausnahmen für CA, die nie auslaufen

Quick Wins (diese Woche)

Um Ihre Sicherheitslage zu verbessern, müssen Sie nicht auf den Start eines großen Projekts warten. Hier sind vier Quick Wins, die Sie diese Woche umsetzen können:

Versehen Sie jede nicht menschliche Identität mit den Tags Owner, System und Data Class.
Stellen Sie einen risikoreichen Job auf Verbundanmeldeinformationen um (GitHub OIDC -> Entra).
Ersetzen Sie ein gemeinsam genutztes Dienstkonto in Power Automate durch eine Workload-Identität.
Erstellen Sie einen Bericht über Dienstprinzipale mit ablaufenden oder abgelaufenen Geheimnissen und richten Sie dafür geplante Warnungen ein.

Häufige Fragen (schnelle Antworten)

Brechen Workload-Identitäten ältere lokale Jobs?
Nein. Überbrücken Sie die Umstellung mit App-only-Authentifizierung, Zertifikaten oder Broker-Diensten und ersetzen Sie Kennwörter schrittweise.

Kann ich Conditional Access für nicht menschliche Anmeldungen erzwingen?
Ja, für unterstützte Abläufe (Anmeldungen von Dienstprinzipalen). Nutzen Sie Netzwerk-, Standort- und Gerätesignale, wo sie zutreffen, und blockieren Sie interaktive Anmeldungen.

Wie verhindere ich Wildwuchs?
Eine Workload-Identität pro Integration (nicht pro Team). Erzwingen Sie bei der Erstellung Namenskonventionen, Besitzer und Überprüfungen, und automatisieren Sie die Bereinigung inaktiver Identitäten.

Was ist mit Power Platform?
Verwenden Sie für Konnektoren und Dataverse Dienstprinzipale / Workload-Identitäten und hören Sie auf, gemeinsam genutzte Benutzerkonten zu verwenden.

Fazit

Mit Rotation allein lässt sich das Risiko von Dienstkonten nicht beseitigen. Entra Workload Identities bringen den nicht menschlichen Zugriff in dasselbe Zero-Trust-, Lebenszyklus- und Auditmodell, das Sie bereits für Benutzer verlangen – ohne Ausfälle und Feuerwehreinsätze. Beginnen Sie mit Ihren riskantesten „svc-“-Konten, wandeln Sie sie in verwaltete Workload-Identitäten um und machen Sie Ausnahmen wieder zur Ausnahme.

Wenn Ihnen dieser Beitrag gefallen hat, schauen Sie sich unbedingt die vollständige Diskussion in unserer Podcast-Folge an: Replace Service Accounts with Entra Workload Identities. Abonnieren Sie den Podcast für weitere Deep Dives zu Strategien für Unternehmenssicherheit in Microsoft 365 und Azure!