Air-Gapped-MFA gemäß § 30 BSIG: Wie eine deutsche Behörde ohne die Cloud die Authentifizierung durchführt
Air-Gapped-MFA gemäß § 30 BSIG: Wie eine deutsche Behörde ohne Cloud authentifiziert
Manche Umgebungen sind so konzipiert, dass es keinen Ausweg gibt. Kein ausgehender Pfad ins Internet, kein Cloud-Callback, keine Abhängigkeit, die ein Netzbetreiber nicht sehen und kontrollieren kann. Für die Teams, die sie betreiben, ist diese Isolierung die Sicherheitskontrolle, und alles, was hinzugefügt wird, muss sie respektieren, anstatt heimlich ein Loch hindurch zu bohren.
Mit dieser Situation sah sich eine deutsche Behörde im Rahmen der deutschen NIS2-Vorschriften konfrontiert, die eine netzwerksegmentierte Umgebung betrieb, in der sich eine Reihe sensibler Geschäftsanwendungen hinter einem Air Gap befand. Die Organisation migrierte von einer SafeNet-Hardware-Token-Lösung, deren Betrieb für eine Nutzerbasis von fast tausend Personen zu aufwendig geworden war. Die Anforderung war einfach zu formulieren, aber schwer zu erfüllen: eine starke Authentifizierung in der isolierten Umgebung, ohne dass etwas hinzugefügt werden durfte, das von einem Dienst außerhalb des Perimeters abhängig wäre.
Warum Cloud-basierte MFA nicht dort laufen kann, wo es keinen Ausweg gibt
Die meisten heutigen Multi-Faktor-Authentifizierungen werden von der Cloud eines Anbieters bereitgestellt. Der auf der Kundenseite installierte Agent muss einen externen Endpunkt erreichen, um einen Faktor zu validieren, eine Push-Benachrichtigung zu leiten oder einfach zu überprüfen, ob seine Lizenz noch gültig ist. Innerhalb eines Segments ohne ausgehende Verbindung können diese Cloud-abhängigen Authentifizierungsabläufe nicht abgeschlossen werden.
Damit beschränkt sich die Auswahl auf Software, die vollständig auf den eigenen Servern der Organisation läuft – einschließlich der Lizenzierung. OpenOTP, der RCDevs-Authentifizierungsserver, und WebADM, die zentrale Konsole, die die Dienste der Suite steuert und verwaltet, wurden auf den eigenen Linux-Servern der Organisation innerhalb des isolierten Segments installiert. Die Lizenzaktivierung und -verlängerung erfolgten offline, sodass der Authentifizierungsdienst zu keinem Zeitpunkt eine Verbindung nach außen herstellen musste, um sich zu validieren. Da es keinen ausgehenden Datenpfad gibt, kommen Push-Benachrichtigungen und alle cloudbasierten Methoden hier grundsätzlich nicht in Frage: Der zweite Faktor muss etwas sein, das lokal validiert wird – auf Hardware, die die Organisation bereits kontrolliert.
Was §30 BSIG fordert und wo Multi-Faktor-Authentifizierung darin angesiedelt ist
Deutschland hat die NIS2-Richtlinie verspätet umgesetzt. Das NIS2-Umsetzungsgesetz trat am 6. Dezember 2025 in Kraft und überarbeitete das BSI-Gesetz (BSIG), über ein Jahr nach der EU-Umsetzungsfrist im Oktober 2024 und ohne Übergangsfrist: Die Verpflichtungen galten ab dem Tag des Inkrafttretens des Gesetzes.
§30 Abs. 2 BSIG legt zehn Kategorien von Mindestmaßnahmen für das Risikomanagement fest, die die betreffenden Unternehmen unter Berücksichtigung ihres Risikos angemessen und verhältnismäßig umsetzen müssen. Multi-Faktor- oder kontinuierliche Authentifizierung erscheint in der zehnten Kategorie, und Zugriffskontrolle ist in der neunten enthalten. Die übrigen acht decken Risikoanalyse, Incident Handling, Betriebskontinuität, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, die Überprüfung der Wirksamkeit der Maßnahmen, Schulungen und Kryptografie ab.
Gemessen am Gesetzestext ist die Rolle der MFA klar. Sie ist eine verpflichtende Maßnahme nach § 30 BSIG, und sie ist eine von zehn Kategorien. Starke Authentifizierung unterstützt die Verpflichtungen einer Einrichtung im Rahmen der Vorgaben; sie erfüllt diese nicht allein. Für eine Einrichtung, die bereits eine isolierte Umgebung betreibt, ist die eigentliche Frage daher enger gefasst: Lässt sich dieser Umgebung ein starker zweiter Faktor hinzufügen, ohne die ausgehende Abhängigkeit einzuführen, die durch die Isolation gerade verhindert werden soll?
Austausch eines MFA-Produkts ohne Entsorgung der vorhandenen Hardware-Token
Die Organisation hatte bereits fast tausend OATH-Hardware-Token im Einsatz, die im Rahmen von SafeNet ausgegeben worden waren. Eine weit verbreitete Annahme beim Anbieterwechsel ist, dass die Token-Flotte zusammen mit dem alten Server entsorgt wird und dass es sich bei dem Projekt in Wirklichkeit um eine Neuausstattung handelt, die als Migration getarnt ist.
Das muss nicht sein. OpenOTP funktioniert mit standardmäßiger OATH-Hardware (tokens), sodass die bereits im Einsatz befindlichen Geräte neu registriert und beibehalten wurden und über den natürlichen Schwund durch defekte Geräte oder die Aufstockung des Personalbestands hinaus nichts gekauft oder ersetzt werden musste. Bei einem Gerätebestand dieser Größe und in einer Umgebung, in der jedes Gerät innerhalb des isolierten Netzwerks verwaltet und registriert werden muss, ist dies der Unterschied zwischen einem kontrollierten Wechsel des Authentifizierungsservers und einer vollständigen Hardware-Einführung.
Identitäten in den eigenen Verzeichnissen der Organisation beibehalten
Die Umgebung enthielt mehrere Active Directory-Domänen. Anstatt diese Konten in ein eigenes Verzeichnis zu kopieren, stellte WebADM über einen LDAP-Mountpoint eine Verbindung zu jeder Domäne her: Die Konten wurden an Ort und Stelle gelesen und nie in ein Verzeichnis eines Drittanbieters repliziert. Active Directory bleibt die Quelle der Wahrheit, und bei der Anmeldung validiert OpenOTP das Passwort gegen das eigene AD der Organisation, bevor der zweite Faktor angewendet wird.
Für eine Organisation, die ihr Verzeichnis an sich bereits als sensibel betrachtet, ist dies kein nebensächliches Detail. Die Identitäten verlassen niemals den von der Organisation kontrollierten Bereich, und es gibt keine Schattenkopie der Benutzerdaten im System eines Anbieters, die separat gesichert, geprüft oder angefordert werden müsste. Die Authentifizierungsebene liest das Verzeichnis aus; sie übernimmt jedoch nicht die Verwaltung desselben.
Dies gilt auch für den Anbieter. OpenOTP wird in Europa von RCDevs entwickelt und veröffentlicht. Bei dieser Implementierung blieben die Identitäten und Authentifizierungsdaten innerhalb der von der Organisation kontrollierten Infrastruktur, ohne dass eine Abhängigkeit von einer außereuropäischen SaaS-Identitätsplattform bestand.
Was diese Bereitstellung umfasste und was nicht
Es lohnt sich, den Umfang genau zu definieren, da in einem regulierten Umfeld die Grenzen ebenso wichtig sind wie das Ergebnis. Innerhalb dieses Umfangs ermöglichte die Implementierung eine lokal validierte MFA, behielt die bestehende OATH-token-Flotte bei, behielt Active Directory als Identitätsinstanz bei und beseitigte jegliche Abhängigkeit von einem externen Authentifizierungs- oder Lizenzierungsdienst. Folgendes wurde nicht umgesetzt:
- allein schon dafür sorgen, dass die Organisation die Anforderungen von § 30 BSIG erfüllt, der über die Authentifizierung hinaus neun weitere Maßnahmenkategorien umfasst;
- eine phishing-resistente Authentifizierung einführen, da die bestehenden OATH-Einmalpasswörter (tokens) beibehalten und nicht durch FIDO2-Geräte ersetzt wurden;
- Active-Directory-Identitäten in ein beliebiges Verzeichnis eines Drittanbieters kopieren;
- sich auf Cloud-gesteuertes Push verlassen, was ein isoliertes Segment nicht unterstützen kann.
Nach dem isolierten Einsatz
Sobald die air-gapped-Bereitstellung in Betrieb genommen worden war, wurde dieselbe Authentifizierungsplattform auf den Fernzugriff in anderen, nicht isolierten Netzwerksegmenten über RADIUS ausgeweitet, ohne dabei einen Identitätsanbieter diesen Segmenten zugänglich zu machen. Der Kern blieb unverändert. Lediglich sein Wirkungsbereich änderte sich: von einer Umgebung, die so konzipiert war, dass es keinen Weg nach außen gab, hin zu Segmenten, die kontrollierte Zugänge erfordern.
Ergebnisse dieses Einsatzes
Gilt ausschließlich für dieses Projekt und stellt keine allgemeine Garantie dar.
- Die bestehende token-Flotte wird beibehalten Fast tausend OATH-Hardwaregeräte vom Typ token, die bereits im Einsatz waren, blieben im Betrieb, sodass über den natürlichen Schwund hinaus keine Anschaffungen oder Ersatzbeschaffungen erforderlich waren.
- Geringere Betriebskosten Authentifizierung konsolidiert in einer einzigen On-Premise-Konsole, WebADM, die die Dienste der Suite ausführt.
- Keine externen Abhängigkeiten Der Authentifizierungsservice läuft vollständig innerhalb des isolierten Segments, einschließlich Lizenzaktivierung und -erneuerung, ohne dass eine ausgehende Verbindung erforderlich ist.
- Identitäten verbleiben vor Ort Mehrere Active Directory-Domänen werden direkt über LDAP-Mountpunkte eingelesen, ohne dass die Konten in ein Verzeichnis eines Drittanbieters kopiert werden.
- Unterstützt die Authentifizierungsmaßnahme gemäß §30 BSIG Eine starke Authentifizierung gilt als eine der zehn Kategorien von Mindestmaßnahmen zum Risikomanagement gemäß § 30 Abs. 2 BSIG, nicht jedoch als eigenständige Compliance-Maßnahme.
Die Ergebnisse sind spezifisch für diese Bereitstellung und stellen keine allgemeine Zusage von Compliance oder Einsparungen dar.
Weiterführende Literatur
Rechtliche Quellen:
- §30 BSIG, amtlicher konsolidierter Text (Risikomanagementmaßnahmen)
- BSI, Verpflichtungen für NIS2-regulierte Unternehmen (die eigene Darstellung der Maßnahmen durch die Aufsichtsbehörde)
RCDevs:
- Offline-MFA und IAM für kritische Infrastrukturen in air-gapped-Umgebungen
- NIS2-Konformität mit OpenOTP
- Cloud-IAM und MFA-Produkte im Vergleich mit einer On-Premise-Lösung
Das ist möglich, vorausgesetzt, die Software läuft vollständig On-Premise und ist nicht von externen Diensten abhängig. In diesem Projekt liefen OpenOTP und WebADM auf den eigenen Linux-Servern der Organisation, wobei die Lizenzaktivierung und -erneuerung offline durchgeführt wurde, sodass der Authentifizierungsdienst niemals eine ausgehende Verbindung benötigte.
Multi-Faktor-Authentifizierung ist eine von zehn Kategorien von Mindestrisikomanagementmaßnahmen nach § 30 Abs. 2 BSIG, nicht die gesamte Compliance. Sie steht neben Risikoanalyse, Incident Handling, Kontinuität, Lieferkettensicherheit, Kryptografie und den übrigen. Im Rahmen dieses Projekts unterstützte MFA die Verpflichtungen der Einrichtung, anstatt sie allein zu erfüllen.
Standard-OATH-Hardware-Token können neu registriert statt entsorgt werden. Im Rahmen dieses Projekts wurden fast tausend SafeNet-Token, die bereits im Einsatz waren, in OpenOTP neu registriert, sodass über den natürlichen Schwund hinaus keine Anschaffungen oder Ersatzbeschaffungen erforderlich waren.
Die Konten bleiben an Ort und Stelle. In diesem Projekt hat WebADM über einen LDAP-Mountpoint eine Verbindung zu mehreren Active Directory-Domänen hergestellt und niemals Konten in ein Drittanbietersystem repliziert; Active Directory blieb die maßgebliche Quelle.
Lizenzaktivierung und -erneuerung werden offline durchgeführt, sodass kein Aufruf an einen externen Lizenzierungsdienst erforderlich ist. Dies ermöglichte es in diesem Projekt, den Authentifizierungsservice in einem isolierten Segment auszuführen.
Beim Login validiert OpenOTP das Passwort gegen das eigene Active Directory der Organisation, bevor der zweite Faktor angewendet wird. In diesem Projekt verblieb das Verzeichnis innerhalb der Perimeter der Organisation und blieb die Validierungsautorität.
