Warum ein Notfallsystem NICHT an euer Active Directory gehört

Es gibt eine Regel, die in der Unternehmens-IT so verinnerlicht ist, dass sie kaum noch hinterfragt wird: Alle Systeme werden zentral an das Active Directory (oder einen vergleichbaren Identitätsdienst) angebunden. Ein Login für alles, zentrale Rechtevergabe, sauberes On- und Offboarding. Das ist gute Praxis – für den Regelbetrieb.

Für ein Notfallsystem ist es ein Fehler. Und zwar kein kleiner.

Dieser Beitrag begründet eine bewusst kontraintuitive Entwurfsentscheidung: warum ein System, das den Ausfall der zentralen IT überbrücken soll, gerade nicht an die zentrale Identitätsverwaltung gekoppelt sein darf.

Die Logik des Regelbetriebs versagt im Notfall

Im Normalbetrieb ist die AD-Anbindung ein Gewinn. Sie reduziert Aufwand, vermeidet verwaiste Konten und macht Berechtigungen zentral steuerbar. Der Preis dafür ist eine Abhängigkeit: Jedes angebundene System kann nur genutzt werden, solange der Identitätsdienst erreichbar ist.

Diese Abhängigkeit fällt im Alltag nicht auf, weil das AD im Alltag läuft. Der springende Punkt ist der Ernstfall – und der sieht anders aus.

Im Ausfall ist das AD oft selbst betroffen

Ein Notfallsystem soll genau die Szenarien überbrücken, in denen zentrale IT-Dienste nicht mehr funktionieren. Und in vielen dieser Szenarien ist der Identitätsdienst nicht der unbeteiligte Zuschauer, sondern selbst Teil des Problems:

• Ransomware-Angriffe zielen häufig gezielt auf Domänencontroller, weil deren Kompromittierung dem Angreifer weitreichende Kontrolle verschafft.

• Ausfälle des Domänencontrollers – ob durch Hardware, Fehlkonfiguration oder Angriff – legen die zentrale Anmeldung lahm.

• Netzwerkstörungen können die Erreichbarkeit des Identitätsdienstes unterbrechen, selbst wenn dieser technisch intakt ist.

In all diesen Fällen gilt: Wäre das Notfallsystem an das AD gekoppelt, könnte sich niemand mehr anmelden – und zwar genau in dem Moment, in dem das System gebraucht wird. Die Daten wären sicher gespeichert, die Anwendung technisch funktionsfähig, und doch käme niemand hinein.

Der Begriff dafür: ein einzelner Ausfallpunkt

In der Sprache der Resilienz ist das ein „Single Point of Failure" – ein einzelner Punkt, dessen Ausfall das gesamte System unbrauchbar macht. Ein Notfallsystem, das an einer Abhängigkeit hängt, die im Notfall regelmäßig mitbetroffen ist, hebt seinen eigenen Zweck auf.

Die Konsequenz ist eindeutig: Ein Resilienzsystem braucht eine eigene, unabhängige Benutzerverwaltung. Es muss sich anmelden lassen, auch wenn ringsum alles andere steht.

Der ehrliche Preis: Doppelpflege

Diese Entscheidung ist kein Freifahrtschein – sie hat einen realen Nachteil, den man offen benennen sollte. Wenn Benutzerkonten nicht mehr zentral über das AD verwaltet werden, müssen sie parallel gepflegt werden. Neue Mitarbeitende brauchen auch im Notfallsystem ein Konto; ausscheidende Mitarbeitende müssen dort ebenfalls deaktiviert werden.

Diese Doppelpflege ist Aufwand, und sie ist ein Risiko, wenn sie schleift. Die Antwort darauf ist nicht, sie zu ignorieren, sondern sie zu organisieren:

• Dokumentierte Provisionierungs- und Deprovisionierungsprozesse, die das Anlegen und Sperren von Konten verlässlich regeln.

• Regelmäßige Rezertifizierung, bei der geprüft wird, ob die vorhandenen Konten noch berechtigt sind.

• Klare Zuständigkeiten, damit die Pflege nicht zwischen IT und Fachbereich verloren geht.

Der Aufwand ist gegen den Sicherheitsgewinn abzuwägen. Und diese Abwägung fällt für ein Notfallsystem eindeutig aus: Die Unabhängigkeit vom Identitätsdienst beseitigt einen kritischen Ausfallpunkt – der Resilienzbeitrag überwiegt den Aufwand der Doppelpflege deutlich.

Das Nachtschicht-Problem – und eine kontrollierte Lösung

Die Unabhängigkeit wirft eine praktische Folgefrage auf: Was passiert, wenn das KIS nachts, am Wochenende oder an Feiertagen ausfällt und kein Administrator verfügbar ist, um kurzfristig Konten für diensthabendes Personal anzulegen?

Für dieses Szenario gibt es ein optionales, eng kontrolliertes Verfahren: einen vorab definierten Notfall-Login, dessen einzige Berechtigung darin besteht, neue personalisierte Benutzerkonten anzulegen. Dieser Login hat bewusst keinen Zugriff auf klinische Daten. Die damit angelegten Konten sind personalisiert, sodass jede Handlung im Notfallbetrieb individuell nachvollziehbar bleibt.

Flankiert wird das durch klare Kontrollen: Das Krankenhaus definiert den Notfall-Login vorab und verwahrt die Zugangsdaten in eigener Verantwortung (etwa im versiegelten Umschlag im Notfallhandbuch oder im Tresor der Pflegedienstleitung). Der Funktionsumfang ist eingeschränkt, die zugewiesenen Folgerollen sind vorkonfiguriert, jede Nutzung wird revisionssicher protokolliert, und nach dem Wiederanlauf werden die angelegten Konten geprüft und bestätigt oder deaktiviert.

Das ist ein bewusster Kompromiss zwischen Verfügbarkeit und administrativer Kontrolle – zugeschnitten auf Situationen, in denen die Patientenversorgung Vorrang vor regulären Freigabeprozessen hat. Häuser, die diesen Kompromiss nicht eingehen wollen, können das Verfahren deaktiviert lassen.

Fazit

Die AD-Anbindung ist eine gute Regel – aber eine Regel für den Regelbetrieb. Ein Notfallsystem lebt von der umgekehrten Logik: Es muss unabhängig von genau den Diensten funktionieren, die im Ernstfall ausfallen. Die eigene Benutzerverwaltung ist deshalb kein Rückschritt gegenüber „Best Practice", sondern die konsequente Anwendung des Resilienzgedankens.

Genau dieser Überlegung folgt das Identitätskonzept von TrioMed: bewusst unabhängig vom zentralen Identitätsdienst des Krankenhauses, mit dokumentierten Prozessen gegen die Risiken der Doppelpflege und einem optionalen, kontrollierten Notfall-Login für die Zeiten, in denen kein Administrator erreichbar ist.

Warum diese Unabhängigkeit gerade bei Ransomware entscheidend ist, vertiefen wir im Beitrag „Ransomware im Krankenhaus: Warum Papier kein Notfallplan ist".