In jedem Unternehmen ab zwanzig Personen läuft parallel eine zweite Nutzergruppe, von der die Geschäftsführung nichts weiß. Sie bezieht kein Gehalt, geht nicht in Meetings und geht nicht in Rente. Sie meldet sich aber an den kritischsten Systemen an, oft mit Administratorrechten. Das sind Dienstkonten — und in den meisten KMU kann niemand sagen, wie viele davon existieren.
Das ist keine Theorie. In einem unserer Audit-Projekte lief die Integration zwischen Comarch Optima und dem Lagersystem unter einem Konto namens „integracja". Ein externer Berater hatte das Konto vier Jahre zuvor angelegt, es „vorsichtshalber" in die Gruppe Domain Admins aufgenommen — und danach hat es niemand mehr angefasst. Das Passwort lag als Klartext in einer Konfigurationsdatei auf einem Netzlaufwerk, auf das die gesamte Buchhaltung Lesezugriff hatte. Wäre ein Angreifer in dieses Netz gelangt — und in ein KMU-Netz zu gelangen ist heute nicht der schwierige Teil — hätte er einen vertrauenswürdigen Generalschlüssel gehabt.
Dieser Text handelt davon, warum solche Konten die größte und gleichzeitig die am häufigsten ignorierte Sicherheitslücke im Mittelstand sind — und was du dagegen mit einem normalen Budget tun kannst.
Was Dienstkonten sind
Ein Dienstkonto ist ein Konto, das nicht zu einer konkreten Person gehört. Angemeldet wird ein Prozess: ein Skript, eine Integration, ein Netzwerkdrucker, ein Backup-Job, eine Buchhaltungsanwendung, die sich mit der Bank verbindet. Typische Beispiele in einem Unternehmen mit 20–50 Personen:
- Das Konto hinter der Integration ERP–WMS oder ERP–KEP-Dienstleister.
- Das Konto, das nachts die Datenbank-Backups startet.
- Das technische Konto eines Webshops, der mit Comarch Optima oder Subiekt verbunden ist.
- Das Konto auf dem Multifunktionsdrucker, damit er in einen Freigabeordner scannen kann.
- Das Konto hinter einem Monitoring-Agenten (Zabbix, PRTG, Nagios), der die Server abklappert.
- Das Konto, unter dem ein PowerShell-Skript einmal pro Woche einen Bericht an die Geschäftsführung schickt.
Diese Konten haben eine Gemeinsamkeit: niemand meldet sich mit ihnen bewusst an. Sie sollen unsichtbar sein. Genau deshalb sind sie ein so lohnendes Ziel.
Warum sie ein Problem sind
Mitarbeiterkonten haben einen Lebenszyklus. Einstellung — Konto anlegen. Austritt — Konto deaktivieren. Passwörter rotieren. MFA einführen. Ein Dienstkonto hat diesen Zyklus nicht. Es wird einmal angelegt, „damit es läuft", und bleibt für immer. Das typische Muster im Mittelstand sieht so aus:
- Das Passwort ändert sich nie — weil „dann sowieso alles kaputtgeht".
- Berechtigungen wachsen, statt zu schrumpfen — weil es einfacher ist, eine Rolle hinzuzufügen, als zu prüfen, welche wirklich gebraucht wird.
- Das Passwort liegt in einer Datei — Konfigurationsdatei, Skript, Mail an einen Berater von vor drei Jahren.
- Keine MFA — weil ein Drucker keinen Code vom Handy bestätigen kann.
- Keine Logs — weil niemand die Überwachung von etwas eingerichtet hat, „was ohnehin die ganze Zeit läuft".
Der Effekt ist vorhersehbar. Ein Angreifer, der auf einem einzigen Rechner im Unternehmen gelandet ist (Phishing, Browser-Lücke, egal), sieht sich um. Er geht nicht direkt an den Domain Admin — den könnte jemand beobachten. Er geht an das Konto backup, integracja, sql-service. Er findet dessen Passwort in einem Skript, hinterlegt zu einem Zeitpunkt, als niemand Lust hatte, die Sache sauber zu machen. Von da an bewegt er sich als vertrauenswürdiger Prozess durch dein Netzwerk.
Bei einem Kunden — einem 18-Personen-Elektrogroßhandel — haben wir 4 Dienstkonten gefunden, jedes davon mit Domain-Admin-Rechten. Zwei davon hatten ihre Passwörter in .ini-Dateien auf einem Netzlaufwerk stehen, auf das jeder Mitarbeiter Lesezugriff hatte. Alle vier durch getrennte Konten mit dem tatsächlich nötigen Mindestumfang an Rechten zu ersetzen, hat uns 3 Wochen Arbeit gekostet. Der Preis dieser Arbeit war ein Bruchteil dessen, was dieselbe Firma ein Jahr zuvor für ein kommerzielles Antivirus-Produkt bezahlt hatte — und das wirkliche Loch, durch das ein Panzer gepasst hätte, lag genau dort.
Wie du sie inventarisierst
Bevor du irgendetwas änderst, musst du wissen, was du hast. Dienstkonten sind verstreut, es gibt also keinen einzigen „Liste anzeigen"-Knopf. Aber es gibt eine kurze, praxistaugliche Liste von Orten, an denen sie leben:
- Active Directory / Entra ID — filtere nach Konten, die sich nie interaktiv anmelden, aber aktive Sitzungen haben oder in privilegierten Gruppen stehen.
- Anwendungsserver — prüfe, unter welchem Konto die Windows-Dienste laufen (Services → LogOn). Alles in der Form
.\Administratorist fast immer einen Blick wert. - Datenbanken — welche Konten sich mit SQL Server, MySQL, Postgres verbinden. Konten wie
sa,root,appbedeuten fast immer etwas. - Skripte und geplante Aufgaben — Task Scheduler, cron, PowerShell-Skripte auf den Servern. Das Konto hinter einer Aufgabe ist ein Dienstkonto.
- SaaS-Anwendungen — Konten, die für Integrationen mit Comarch Optima, Banken, KEP-Dienstleistern, Shops verwendet werden. Sie tragen meist „api" oder „integration" im Namen oder sind Postfächer wie
it@firma.de. - Geräte — Drucker, Scanner, Kameras. Sie melden sich in der Regel mit einem einzigen Konto an einem Freigabeordner an.
Ergebnis ist eine Tabelle: Kontoname / wo es sich anmeldet / was es tut / wann das Passwort zuletzt angefasst wurde / wer weiß, wo dieses Passwort liegt. In den meisten KMU gibt es diese Tabelle nicht. Allein sie zu erstellen ist der halbe Erfolg.
Wie du sie verwaltest
Hygiene bei Dienstkonten ist kein großes Einzelprojekt. Es sind ein paar Gewohnheiten, die man einmal einführt und dann pflegt.
- Ein Konto = eine Aufgabe. Das Backup-Konto meldet sich nicht am Versanddienstleister-System an. Wenn ein Konto drei verschiedene Aufgaben erledigt, verlierst du bei einer Kompromittierung drei Dinge gleichzeitig.
- Least Privilege. Ein Integrationskonto zwischen ERP und WMS muss kein Domain Admin sein. Fast nie. Fange mit den kleinsten Rechten an und erweitere sie nur dann, wenn wirklich etwas nicht mehr läuft.
- Passwörter im Passwortmanager, nicht in einer Datei. Bitwarden, 1Password, KeePass — alles ist besser als Klartext auf der Platte. Enterprise-Werkzeuge (Azure Key Vault, AWS Secrets Manager) rotieren Passwörter zusätzlich automatisch — aber selbst ein einfacher Vault am Anfang ist eine Größenordnung besser als
config.ini. - Managed Service Accounts unter Windows. Wenn du Active Directory betreibst, rotieren gMSA (group Managed Service Accounts) ihre Passwörter selbst und beseitigen das „Passwort in einer Datei"-Problem vollständig. Eines der wenigen Dinge, die sich auch in einer kleinen Umgebung lohnen.
- Rotation alle 12 Monate. Einmal im Kalender eintragen. Wenn das Passwort nicht geändert werden kann, ohne alles neu zu starten, ist das ein Zeichen dafür, dass das Konto schlecht entworfen ist — kein Grund, es in Ruhe zu lassen.
- Alarme bei ungewöhnlichen Anmeldungen. Das Konto
backup, das plötzlich um 3 Uhr nachts vom Laptop der Buchhalterin aus einloggt, ist ein Angriff. Eine einfache E-Mail-Warnung reicht — du musst kein SIEM kaufen.
Wie es weitergeht
In den meisten Unternehmen, in die wir mit einem Security-Audit hineingehen, sind Dienstkonten das Element, an das vorher niemand gedacht hat. Nicht weil die Leute unverantwortlich wären, sondern weil diese Konten per Definition unsichtbar sind. Man sieht sie erst, wenn man sie bewusst zählt.
Wenn du nicht weißt, wie viele solcher Konten gerade in deinem Unternehmen laufen — rate nicht. Fang mit einem 30-Minuten-Gespräch an. Wir sagen dir, wo du suchen sollst, in welcher Reihenfolge du das Risiko senkst und was du selbst erledigen kannst, bevor du jemanden von außen einschaltest.
Ein Konto, das man nicht sieht, existiert deshalb nicht weniger. Es wird nur von niemandem geschützt.