Service Principals ohne Besitzer: das Risiko, für das niemand unterschreibt

Was ein technisches Konto ist, in einem Satz

Ein technisches Konto ist eine Identität, hinter der kein Mensch sitzt: eine Anwendung, ein Skript, ein Backup-Job, eine Schnittstelle zu einem Partner. In Microsoft Entra ID heißen sie App-Registrierungen und Service Principals, im lokalen Active Directory Dienstkonten, in Keycloak Clients. Sie melden sich mit einem Geheimnis oder einem Zertifikat an, nicht mit Passwort und Handy, und sie tun das rund um die Uhr.

In den Umgebungen, die wir sehen, gibt es davon oft mehr als Mitarbeitende. Das ist normal. Nicht normal ist, dass in vielen dieser Umgebungen niemand sagen kann, wofür ein Drittel davon da ist.

Warum das Risiko im Betrieb unsichtbar bleibt

Ein Mensch hat einen Vorgesetzten, einen Arbeitsvertrag und einen letzten Arbeitstag. Ein technisches Konto hat nichts davon. Es wurde für ein Projekt angelegt, das Projekt endete, das Konto blieb. Sein Geheimnis läuft irgendwann ab, dann bricht etwas, und die schnellste Lösung ist ein neues Geheimnis mit zwei Jahren Laufzeit. Rechte werden großzügig vergeben, weil das Skript sonst nicht lief, und nie wieder verkleinert. Multi-Faktor-Authentifizierung gibt es für diese Konten nicht.

Das Ergebnis ist ein Konto, das das gesamte Verzeichnis lesen oder sogar schreiben darf, dessen Geheimnis in einer Konfigurationsdatei auf einem Server liegt, und für das niemand zuständig ist. Wer es findet, hat Zugriff, ohne dass eine Anmeldung auffällt, weil sich das Konto ja ständig anmeldet.

Drei Fragen, die die Geschäftsführung stellen sollte

1. Wie viele technische Konten haben wir? Wenn die Antwort eine Schätzung ist, ist das bereits der Befund. Die Zahl ist mit Bordmitteln in einer Stunde ermittelbar.
2. Wer verantwortet jedes einzelne? Nicht die IT als Abteilung, sondern eine Person mit Namen. Ein Konto ohne Besitzer hat keinen, der es abschaltet, wenn es nicht mehr gebraucht wird.
3. Was darf das mächtigste davon? Ein einzelnes Konto mit Schreibrechten auf das Verzeichnis kann jede Sicherheitsmaßnahme aushebeln, die Sie für Menschen eingeführt haben. Die Antwort auf diese Frage gehört in den Risikobericht.

Was die Regelwerke erwarten

NIS2 verlangt in Artikel 21 Konzepte für Zugriffskontrolle und den Einsatz sicherer Authentifizierung. ISO/IEC 27001:2022 behandelt unter Identitätsmanagement ausdrücklich auch Identitäten, die keiner Person zugeordnet sind, und verlangt für jede einen Verantwortlichen. Der BSI IT-Grundschutz führt technische Benutzer im Baustein zum Identitäts- und Berechtigungsmanagement mit. Kurz: Die Regelwerke unterscheiden nicht zwischen Mensch und Maschine. Der Prüfer auch nicht.

So prüfen Sie das mit Bordmitteln

• Entra ID, Besitzer: Unter Anwendungen, App-Registrierungen und Unternehmensanwendungen lässt sich die Spalte Besitzer einblenden. Alles ohne Eintrag kommt auf die Liste.
• Entra ID, Geheimnisse: Unter Zertifikate und Geheimnisse jeder App-Registrierung stehen Ablaufdaten. Per Graph API liefert /applications?$select=displayName,passwordCredentials,keyCredentials alle auf einmal. Laufzeiten über einem Jahr sind ein Finding.
• Entra ID, Rechte: Anwendungsberechtigungen wie das Lesen oder Schreiben des gesamten Verzeichnisses stehen bei jeder App unter API-Berechtigungen. Diese Liste sollte kurz sein und jeden Eintrag begründen können.
• Active Directory: Dienstkonten mit nie ablaufendem Passwort findet Get-ADUser -Filter {PasswordNeverExpires -eq $true}. Jedes davon braucht einen Besitzer und einen Grund.
• Verwaltete Identitäten bevorzugen: Wo eine Anwendung in Azure läuft, ersetzt eine verwaltete Identität das Geheimnis vollständig. Kein Ablauf, nichts, das in einer Datei liegen kann.

Der Prozess, der Verantwortung herstellt

1. Jedes technische Konto hat zwei Besitzer mit Namen. Ohne Besitzer wird es nach einer Frist deaktiviert.
2. Geheimnisse laufen höchstens sechs Monate, Zertifikate höchstens ein Jahr. Der Ablauf ist ein Termin im Kalender des Besitzers, nicht eine Überraschung im Betrieb.
3. Rechte werden bei der Anlage begründet und einmal im Jahr überprüft. Was nicht mehr gebraucht wird, wird entfernt.
4. Ein Konto, das dreißig Tage keine Anmeldung zeigt, wird angesprochen, nach sechzig Tagen deaktiviert.
5. Die Liste mit Besitzern, Rechten und Ablaufdaten ist Teil des Risikoberichts, und die Geschäftsführung sieht sie einmal im Quartal.

Wo Bordmittel an ihre Grenzen stoßen

Die Portale zeigen jedes Konto für sich. Sie zeigen nicht, welche Gruppen, Rollen und Anwendungen an einem Konto hängen, und damit auch nicht, wie weit ein Vorfall reichen würde. Entra ID und Active Directory kennen sich gegenseitig nicht, ein Dienstkonto, das in beiden existiert, ist zwei Einträge in zwei Listen. Und keine der Listen hat eine Vergangenheit. Wer der Geschäftsführung zeigen will, dass die Zahl der besitzerlosen Konten von 40 auf 3 gefallen ist, braucht die Zahl von damals mit Datum.

Dieser Beitrag ist derzeit nur auf Deutsch verfügbar. This article is currently available in German only.