- Service Accounts sind technische Konten, die von Anwendungen, Diensten und automatisierten Prozessen für die Authentifizierung verwendet werden. Sie laufen rund um die Uhr, haben oft übermäßige Rechte und werden selten überprüft.
- In einem durchschnittlichen mittelständischen Unternehmen existieren 50 bis 200 Service Accounts, von denen viele seit Jahren nicht angefasst wurden. Einige laufen unter Domain-Admin-Rechten, obwohl sie diese nicht benötigen.
- Die größten Risiken sind Passwörter, die nie geändert werden, übermäßige Berechtigungen, fehlende Zuordnung zu einem Verantwortlichen, keine MFA-Absicherung und kein Monitoring der Nutzung.
- Die Absicherung beginnt mit der Inventarisierung: Welche Service Accounts existieren? Welche Rechte haben sie? Wer ist verantwortlich? Werden sie noch benötigt? Danach folgen Least Privilege, Passwort-Rotation und Monitoring.
- Managed Service Accounts (MSA) und Group Managed Service Accounts (gMSA) in Active Directory automatisieren die Passwort-Rotation und eliminieren das Risiko statischer Passwörter. Für Cloud-Umgebungen bieten Workload Identities und Managed Identities ähnliche Vorteile.
Was sind Service Accounts und warum sind sie gefährlich?
Service Accounts sind technische Benutzerkonten, die nicht von Menschen, sondern von Anwendungen, Diensten und automatisierten Prozessen verwendet werden. Der Backup-Agent, der nächtlich die Datenbank sichert, authentifiziert sich über einen Service Account. Die ERP-Software, die auf die SQL-Datenbank zugreift, nutzt einen Service Account. Der Monitoring-Agent, der die Serverstatus abfragt, verwendet einen Service Account. Das Ticketsystem, das E-Mails aus einem Postfach liest, arbeitet mit einem Service Account.
Diese Konten sind allgegenwärtig, aber unsichtbar. Kein Mensch meldet sich morgens an und abends ab. Es gibt keinen Bildschirm, auf dem sich eine Session öffnet. Service Accounts laufen im Hintergrund, rund um die Uhr, sieben Tage die Woche. Und genau diese Unsichtbarkeit macht sie gefährlich.
Die Risiken von Service Accounts ergeben sich aus einer Kombination von Faktoren, die bei menschlichen Konten typischerweise besser kontrolliert werden.
Statische Passwörter: Das Passwort eines Service Accounts wird bei der Einrichtung gesetzt und dann nie wieder geändert. Nicht nach drei Monaten, nicht nach einem Jahr, nicht nach fünf Jahren. Der Grund ist pragmatisch: Wenn du das Passwort änderst, musst du es auch in der Anwendung ändern, die den Account nutzt. Und wenn du dabei einen Fehler machst, funktioniert die Anwendung nicht mehr. Also lässt man das Passwort unangetastet. In vielen Unternehmen laufen Service Accounts mit Passwörtern, die seit über einem Jahrzehnt nicht geändert wurden.
Übermäßige Berechtigungen: Bei der Einrichtung wird dem Service Account oft großzügig Rechte gegeben, weil niemand genau weiß, welche minimalen Rechte die Anwendung tatsächlich benötigt. "Gib dem Account Domain-Admin-Rechte, dann funktioniert es auf jeden Fall" ist ein Satz, den jeder IT-Administrator schon gehört oder selbst gesagt hat. Was als schnelle Lösung für ein konkretes Problem gedacht war, wird zu einem permanenten Sicherheitsrisiko.
Fehlende Zuordnung: Wer ist für den Service Account svc-backup-prod verantwortlich? Wer hat ihn angelegt? Welche Anwendung nutzt ihn? In vielen Unternehmen kann niemand diese Fragen beantworten. Der Mitarbeiter, der den Account vor fünf Jahren angelegt hat, arbeitet nicht mehr im Unternehmen. Die Dokumentation existiert nicht oder ist veraltet. Der Account läuft weiter, aber niemand fühlt sich zuständig.
Kein MFA: Service Accounts unterstützen in den meisten Fällen keine Multi-Faktor-Authentifizierung, weil kein Mensch anwesend ist, der einen zweiten Faktor bestätigen könnte. Damit entfällt eine der wirksamsten Schutzmaßnahmen gegen kompromittierte Zugangsdaten.
Kein Monitoring: Die Nutzung von Service Accounts wird selten überwacht. Wenn sich ein Service Account um 3 Uhr nachts an einem Server anmeldet, ist das normales Verhalten, weil er das jede Nacht tut. Aber wenn sich derselbe Account um 14 Uhr an einem anderen Server anmeldet, den er normalerweise nicht kontaktiert, fällt das ohne Monitoring nicht auf.
Die Dimension des Problems
In einem durchschnittlichen mittelständischen Unternehmen mit 200 bis 500 Mitarbeitern existieren typischerweise 50 bis 200 Service Accounts. In größeren Unternehmen können es tausende sein. Jeder einzelne ist ein potenzieller Angriffsvektor.
Die Angriffstechnik Kerberoasting zielt gezielt auf Service Accounts in Active Directory. Der Angreifer, der bereits über einen normalen Benutzeraccount verfügt, fordert Kerberos-Service-Tickets für alle Service Accounts an, die einen Service Principal Name (SPN) registriert haben. Diese Tickets sind mit dem Passwort-Hash des Service Accounts verschlüsselt. Der Angreifer extrahiert die Tickets und knackt sie offline mit Brute-Force-Methoden. Wenn das Passwort schwach ist (und bei Service Accounts, die vor Jahren eingerichtet wurden, ist es das oft), hat der Angreifer innerhalb von Minuten oder Stunden ein gültiges Passwort.
Der Angriff ist besonders tückisch, weil er keine privilegierten Rechte erfordert und kaum Spuren hinterlässt. Jeder Domain-Benutzer kann Kerberos-Service-Tickets anfordern, und die Anfrage sieht im Log wie normale Kerberos-Aktivität aus.
Schritt 1: Inventarisierung aller Service Accounts
Die Absicherung beginnt mit dem Wissen, was zu schützen ist. Wie beim IT-Asset-Management allgemein ist eine vollständige Inventarisierung aller Service Accounts der unverzichtbare erste Schritt.
Wo finden sich Service Accounts?
Active Directory: Die offensichtlichste Quelle. Service Accounts in AD lassen sich über verschiedene Wege identifizieren: Accounts mit einem Service Principal Name (SPN), Accounts in OUs mit Namen wie "Service Accounts" oder "Technical Users", Accounts, deren Name mit "svc-", "sa-", "srv-" oder ähnlichen Präfixen beginnt, und Accounts, bei denen das Flag "Passwort läuft nie ab" gesetzt ist.
Lokale Accounts auf Servern: Manche Dienste laufen unter lokalen Benutzerkonten, die nicht im Active Directory existieren. Diese Accounts werden oft bei der AD-Inventarisierung übersehen. Ein PowerShell-Skript, das auf allen Servern die Dienste abfragt und die verwendeten Accounts auflistet, deckt diese auf.
Cloud-Plattformen: In Azure sind es App-Registrierungen, Service Principals und Managed Identities. In AWS sind es IAM Users mit programmatischem Zugriff (Access Keys). In Google Cloud sind es Service Accounts im IAM. Jede Cloud-Plattform hat eigene Mechanismen, die separat inventarisiert werden müssen.
Anwendungen: Manche Anwendungen verwalten ihre eigenen Service Accounts intern. Datenbanken haben technische Benutzer für Replikation und Monitoring. Middleware-Systeme haben Integrationskonten. Diese Accounts sind von außen nicht sichtbar und müssen bei den Anwendungsverantwortlichen erfragt werden.
Was dokumentieren?
Für jeden Service Account solltest du folgende Informationen erfassen: Name und Speicherort (AD, lokal, Cloud), Zweck (welche Anwendung, welcher Dienst), Verantwortlicher (wer hat den Account angelegt, wer ist aktuell zuständig), Berechtigungen (Gruppenmitgliedschaften, Rollen, Zugriffsrechte), Passwort-Alter (wann wurde das Passwort zuletzt geändert?), Interaktive Anmeldung (ist die interaktive Anmeldung möglich oder gesperrt?), SPN-Registrierung (für Kerberoasting-Risikobewertung) und Kritikalität (wie gravierend wäre eine Kompromittierung?).
Schritt 2: Least Privilege umsetzen
Nach der Inventarisierung folgt die Reduzierung der Berechtigungen auf das notwendige Minimum. Dieser Schritt erfordert Zusammenarbeit mit den Anwendungsverantwortlichen, weil nur sie wissen, welche Rechte die Anwendung tatsächlich benötigt.
Der Prozess für jeden Service Account sieht folgendermaßen aus: Zunächst dokumentierst du die aktuellen Berechtigungen. Dann analysierst du mit dem Anwendungsverantwortlichen, welche dieser Berechtigungen tatsächlich benötigt werden. Du erstellst ein Ziel-Berechtigungsprofil mit den minimalen Rechten. In einer Testumgebung oder einem Wartungsfenster reduzierst du die Berechtigungen und überprüfst, ob die Anwendung weiterhin funktioniert. Und schließlich dokumentierst du das finale Berechtigungsprofil.
Ein häufiger Fall ist der Service Account, der Domain-Admin-Rechte hat, weil er auf einer bestimmten Dateifreigabe Schreibrechte benötigt. Die Lösung ist offensichtlich: Statt Domain-Admin-Rechten bekommt der Account nur die spezifischen NTFS-Berechtigungen auf der benötigten Freigabe.
Ein anderer häufiger Fall ist der Service Account für das Monitoring-Tool, der Lesezugriff auf alle Server benötigt. Statt Domain-Admin-Rechten reicht oft die Mitgliedschaft in der Gruppe "Performance Monitor Users" oder "Event Log Readers" auf den überwachten Servern.
Schritt 3: Passwort-Management
Das Passwort-Management für Service Accounts ist eine der größten Herausforderungen, weil die automatische Rotation mit der Konfiguration der nutzenden Anwendungen koordiniert werden muss.
Managed Service Accounts (MSA) und Group Managed Service Accounts (gMSA)
Die beste Lösung für Service Accounts in Active Directory sind Managed Service Accounts (MSA) und Group Managed Service Accounts (gMSA). Diese speziellen Kontotypen automatisieren die Passwort-Rotation vollständig. Active Directory generiert automatisch ein 240 Zeichen langes, zufälliges Passwort und rotiert es alle 30 Tage. Die Anwendung ruft das aktuelle Passwort bei der Anmeldung automatisch vom Domain Controller ab, ohne dass ein Mensch eingreifen muss.
MSAs sind an einen einzelnen Server gebunden, gMSAs können von mehreren Servern verwendet werden, was sie für Cluster-Szenarien und Load-Balancing geeignet macht.
Die Einschränkung: Nicht alle Anwendungen unterstützen gMSAs. Die Anwendung muss in der Lage sein, das Passwort vom DC abzurufen, anstatt es aus einer Konfigurationsdatei zu lesen. Windows-Dienste unterstützen gMSAs nativ, aber Drittanbieter-Software tut es oft nicht. Für jede Anwendung muss geprüft werden, ob gMSA-Support vorhanden ist.
Passwort-Rotation für klassische Service Accounts
Für Service Accounts, die nicht als gMSA umgestellt werden können, brauchst du einen manuellen oder semi-automatischen Rotationsprozess. Dieser Prozess umfasst die Generierung eines neuen, starken Passworts, die Änderung des Passworts im Active Directory, die Aktualisierung des Passworts in der Anwendungskonfiguration, den Neustart des Dienstes und die Überprüfung, ob die Anwendung ordnungsgemäß funktioniert.
Dieser Prozess sollte für jeden Service Account dokumentiert sein, sodass er auch von einem anderen Administrator durchgeführt werden kann. Die Dokumentation umfasst: welche Anwendung betroffen ist, wo das Passwort in der Anwendung konfiguriert ist (Konfigurationsdatei, Registry, Datenbank), ob ein Dienstneustart erforderlich ist und wie überprüft wird, ob die Anwendung nach der Passwortänderung funktioniert.
PAM-Lösungen wie CyberArk oder BeyondTrust können diesen Prozess automatisieren, indem sie das Passwort sowohl im AD als auch in der Anwendungskonfiguration gleichzeitig ändern. Für Unternehmen mit vielen Service Accounts kann sich die Investition lohnen.
Cloud-Umgebungen: Managed Identities
In Azure bieten Managed Identities eine elegante Lösung für Service Accounts in der Cloud. Statt eines Benutzernamens und Passworts erhält die Azure-Ressource (z. B. eine VM, ein App Service oder eine Azure Function) eine automatisch verwaltete Identität. Die Authentifizierung gegenüber anderen Azure-Diensten erfolgt über Tokens, die automatisch generiert, rotiert und invalidiert werden. Es gibt kein Passwort, das gespeichert, verwaltet oder gestohlen werden könnte.
In AWS bieten IAM Roles für EC2-Instanzen und Workload Identity für EKS ein ähnliches Konzept. In Google Cloud erfüllen Workload Identity Federation und Service Account Keys (wobei letztere vermieden werden sollten) diese Funktion.
Schritt 4: Interaktive Anmeldung einschränken
Service Accounts sollten sich nicht interaktiv anmelden können. Es gibt keinen legitimen Grund, warum sich jemand mit einem Service Account an einem Computer anmeldet und eine Desktop-Session öffnet. Wenn ein Service Account für eine interaktive Anmeldung verwendet wird, ist das ein starkes Indiz für Missbrauch.
In Active Directory kannst du die interaktive Anmeldung über die Eigenschaft "Log on to" einschränken. Dort listest du die Computer auf, auf denen sich der Service Account anmelden darf. Alle anderen Computer sind gesperrt. Zusätzlich kann über Group Policies die interaktive Anmeldung für Service Accounts unterbunden werden.
In Entra ID können Conditional Access Policies den Zugriff von Service Principals auf bestimmte Anwendungen und Bedingungen einschränken.
Schritt 5: Monitoring und Alerting
Service Accounts haben vorhersehbare Nutzungsmuster: Sie melden sich immer von denselben Quellsystemen an, immer zu ähnlichen Zeiten, immer an denselben Zielsystemen. Abweichungen von diesem Muster sind potenzielle Indikatoren für eine Kompromittierung.
Konfiguriere Alarme für folgende Ereignisse: Interaktive Anmeldung eines Service Accounts (sollte niemals vorkommen), Anmeldung von einem unbekannten Quellsystem, Anmeldung an einem unbekannten Zielsystem, Anmeldung außerhalb der üblichen Zeiten (z. B. wenn ein Batch-Job normalerweise nur nachts läuft), fehlgeschlagene Anmeldeversuche (können auf Brute-Force-Versuche oder Kerberoasting hindeuten) und Änderungen an den Eigenschaften des Service Accounts (Gruppenmitgliedschaften, SPN, Passwort-Flags).
Windows Event Forwarding kann die relevanten Security Events (Event ID 4624, 4625, 4768, 4769) von allen Servern an einen zentralen Collector senden. Von dort können sie im Rahmen einer Logging- und Monitoring-Strategie an ein SIEM oder ein einfaches Alerting-System weitergeleitet werden.
Schritt 6: Kerberoasting-Schutz
Kerberoasting ist der häufigste Angriff auf Service Accounts in Active Directory. Der Schutz umfasst mehrere Maßnahmen.
Starke Passwörter: Service Accounts mit SPNs sollten Passwörter mit mindestens 30 Zeichen haben, die zufällig generiert sind. Ein 30-Zeichen-Passwort aus Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen ist mit aktueller Hardware nicht in vertretbarer Zeit knackbar.
gMSAs bevorzugen: gMSAs haben automatisch generierte 240-Zeichen-Passwörter, die für Kerberoasting praktisch unknackbar sind.
AES-Verschlüsselung: Stelle sicher, dass die Kerberos-Tickets mit AES-256 verschlüsselt werden, nicht mit dem älteren RC4. AES-verschlüsselte Tickets sind deutlich schwerer zu knacken.
Monitoring: Überwache die Anforderung von Kerberos-Service-Tickets (Event ID 4769). Wenn ein einzelner Account in kurzer Zeit Tickets für viele verschiedene Service Accounts anfordert, ist das ein starkes Indiz für Kerberoasting.
Honeypot-Accounts: Erstelle einen Service Account mit einem SPN, aber ohne tatsächliche Funktion. Jede Ticket-Anforderung für diesen Account ist per Definition verdächtig, weil kein legitimer Dienst ihn nutzt.
Schritt 7: Rezertifizierung
Service Accounts müssen regelmäßig überprüft werden. Die Rezertifizierung stellt sicher, dass jeder Account noch benötigt wird, dass die Berechtigungen noch angemessen sind und dass ein Verantwortlicher zugeordnet ist.
Ein halbjährlicher Rezertifizierungszyklus ist für die meisten Unternehmen angemessen. Der Prozess umfasst den Export aller Service Accounts mit ihren Eigenschaften, die Prüfung durch den zugeordneten Verantwortlichen (wird der Account noch benötigt? Sind die Rechte angemessen?), die Deaktivierung nicht mehr benötigter Accounts (nicht sofort löschen, sondern zunächst deaktivieren und nach einer Karenzzeit löschen) und die Dokumentation der Ergebnisse.
Accounts, für die kein Verantwortlicher identifiziert werden kann, werden als "verwaist" markiert und in einem definierten Verfahren deaktiviert. Wenn innerhalb von 30 Tagen niemand die Deaktivierung bemerkt, wird der Account gelöscht.
Service-Account-Richtlinie
Eine Service-Account-Richtlinie definiert die verbindlichen Regeln für die Erstellung, Verwaltung und Überwachung technischer Konten. Sie sollte folgende Punkte abdecken.
Namenskonvention: Service Accounts folgen einem einheitlichen Namensschema (z. B. svc-
Regulatorische Einordnung
Service Accounts fallen unter mehrere Anforderungen der gängigen Rahmenwerke. ISO 27001 adressiert sie in Annex A.5.16 (Identitätsmanagement), A.5.17 (Authentifizierungsinformationen), A.5.18 (Zugangsrechte) und A.8.2 (privilegierte Zugangsrechte). NIS2 fordert in Artikel 21 Maßnahmen zum Zugangsmanagement, die auch technische Konten umfassen. Der BSI-Grundschutz behandelt das Thema in ORP.4 (Identitäts- und Berechtigungsmanagement).
Auditoren fragen gezielt nach Service Accounts: Wie viele gibt es? Wer ist verantwortlich? Wie oft werden Passwörter rotiert? Wie wird Least Privilege sichergestellt? Wer nicht auf diese Fragen vorbereitet ist, riskiert Audit-Feststellungen.
Service Accounts sind kein Randthema. Sie sind ein zentraler Bestandteil deines Berechtigungskonzepts und verdienen dieselbe Aufmerksamkeit wie die Konten deiner Mitarbeiter. In ISMS Lite kannst du die Inventarisierung, Rezertifizierung und Dokumentation deiner Service Accounts systematisch abbilden und für Audits nachweisen. Der Unterschied ist: Bei Mitarbeiterkonten hast du wahrscheinlich bereits Prozesse etabliert. Bei Service Accounts ist die Wahrscheinlichkeit hoch, dass du es erst noch tun musst. Beginne mit der Inventarisierung, und arbeite dich Schritt für Schritt durch die in diesem Artikel beschriebenen Maßnahmen. Jeder Schritt reduziert ein reales Risiko.
Weiterführende Artikel
- Berechtigungskonzept erstellen: Vom Rollenmodell bis zur Rezertifizierung
- Active Directory absichern: Härtung, Tiering und Monitoring
- Privileged Access Management (PAM): Admin-Konten unter Kontrolle
- Verzeichnisdienste: Active Directory vs. Entra ID vs. LDAP
- Logging und Monitoring: Strategie, Tools und Umsetzung im Mittelstand