Bildquelle: Bildquelle: Pexels / Foto-ID 60504 / https://www.pexels.com/photo/60504/ / C00 Lizenz
Automatische Systemkonten arbeiten im Hintergrund. Sie starten Dienste, verbinden Anwendungen, lesen Daten oder schreiben in andere Systeme. Genau deshalb werden sie gefährlich, wenn niemand mehr weiß, wem sie gehören und warum sie noch Rechte haben.
Mit automatischen Systemkonten sind Konten gemeint, die nicht einer einzelnen Person gehören, sondern von Diensten, Skripten, Schnittstellen oder Anwendungen genutzt werden. In vielen Umgebungen heißen sie Servicekonten. Für ITSM-Generalisten ist weniger der Name wichtig als die Betriebsfrage: Wer verantwortet dieses Konto, welchen Zweck erfüllt es und wann wird geprüft, ob die Rechte noch passen?
Ein technisches Konto ist trotzdem eine Verantwortung
Personenkonten lassen sich meist einem Mitarbeiter, einer Rolle oder einem Team zuordnen. Bei automatischen Konten ist das schwieriger. Sie tauchen in der Konfigurationsdatenbank, im Identitätsmanagement, in Tickets oder in technischen Skripten auf, aber selten mit einer verständlichen fachlichen Beschreibung. Solange alles läuft, fällt das kaum auf. Erst bei einem Audit, einem Sicherheitsvorfall oder einer Migration wird sichtbar, wie viel Vertrauen in einem namenlosen Konto steckt.
Der praktische Fehler beginnt oft klein. Für eine Schnittstelle wird ein Konto angelegt, es bekommt Lesezugriff auf Kundendaten, Schreibrechte auf ein System oder Zugriff auf ein Dateiverzeichnis. Später wird das Projekt übergeben, der Dienst verändert sich, die Anwendung wird ersetzt oder ein Lieferant verlässt die Umgebung. Das Konto bleibt aber aktiv, weil niemand sicher sagen kann, ob es noch gebraucht wird. Aus einer sauberen technischen Lösung wird ein stilles Dauerrecht.
Der Besitzer muss fachlich und technisch sichtbar sein
Ein Besitzer ist nicht nur der Administrator, der das Konto einmal angelegt hat. Sinnvoll ist eine doppelte Sicht: ein technischer Verantwortlicher, der Passwortwechsel, Schlüssel, Berechtigungen und Monitoring betreut, und ein fachlicher Service Owner, der bestätigen kann, dass Zweck und Datenzugriff noch benötigt werden. Diese Zuordnung gehört an eine Stelle, die der Betrieb im Alltag findet. Das kann ein Serviceeintrag, ein CMDB-Objekt, ein Berechtigungsticket oder eine gepflegte Kontenliste sein.
Der Eintrag sollte in normaler Sprache erklären, wofür das Konto arbeitet. „svc_app_read_01“ hilft im Audit kaum weiter. Besser ist eine knappe Beschreibung wie: „Automatisches Konto für den nächtlichen Import der Kundennummern aus System A nach System B, Besitzer: Service Owner Vertrieb, technische Betreuung: Plattformteam, nächster Prüftermin: 30.09.2026.“ So erkennt der Service Desk im Zweifel schneller, ob ein Alarm kritisch ist, wer freigeben darf und welche Folge ein Sperren des Kontos hätte.
Prüftermine verhindern Dauerrechte ohne Anlass
Automatische Konten brauchen keinen täglichen Review, aber sie brauchen einen festen Rhythmus. Ein Prüftermin zwingt zur einfachen Entscheidung: weiter nötig, Rechte reduzieren, Besitzer ändern oder Konto schließen. Diese Prüfung sollte nicht nur fragen, ob das Konto noch existiert. Sie muss den Zweck, die betroffenen Daten, die Schnittstelle, die letzten Nutzungsnachweise und die vergebenen Rechte betrachten.
NIST führt Zugriffskontrolle, Kontenmanagement und regelmäßige Überprüfung als zentrale Sicherheitsdisziplinen. Das britische National Cyber Security Centre ordnet Identitäts- und Zugriffsmanagement als Baustein ein, mit dem Organisationen kontrollieren, wer oder was auf Systeme zugreifen darf. Microsoft beschreibt Servicekonten ausdrücklich als Konten für Anwendungen oder Dienste und betont die Bedeutung von Verwaltung, Besitz und Begrenzung. Für den ITSM-Alltag heißt das: Ein Systemkonto ist kein reines Technikdetail. Es ist ein dauerhafter Zugangspunkt, der in Servicebetrieb, Risiko und Audit hineinwirkt.
So setzt Du die Kontrolle pragmatisch auf
- Erfasse automatische Konten mit Zweck, Dienst, Datenzugriff und technischer Kontaktrolle.
- Ordne jedem Konto einen fachlichen Besitzer zu, der den Bedarf bestätigen kann.
- Setze einen nächsten Prüftermin und halte das Ergebnis im Ticket oder in der Kontenliste fest.
- Trenne Konten für unterschiedliche Zwecke, statt ein starkes Sammelkonto für alles zu nutzen.
- Prüfe nach Migrationen, Lieferantenwechseln und größeren Releases, ob alte Konten noch aktiv sind.
Wichtig ist die Reihenfolge. Zuerst braucht der Betrieb eine verständliche Liste der wichtigsten automatischen Konten. Danach kommen technische Härtung, Passwortrotation, Schlüsselverwaltung und feinere Rechte. Wer mit Perfektion startet, bleibt oft in der Inventur stecken. Wer mit Besitzer, Zweck und Prüftermin beginnt, schafft schnell eine belastbare Grundlage für bessere Zugriffskontrolle.
Quellen und Einordnung: Microsoft Learn zu Service Accounts, NCSC zu Identity and Access Management, NIST SP 800-53 Rev. 5 zu Security and Privacy Controls. Stand der Quellenprüfung: 24.07.2026. Bildquelle: Pexels / Foto-ID 60504 / C00 Lizenz.
