On-premise Identitätsresilienz, ohne auf Souveränität zu verzichten: eine Alternative zu Entra ID

Viele Organisationen verwalten ihre gesamte Identitätsschicht von einer einzigen Website aus. Active Directory ist lokal installiert, eine darüberliegende Föderationsschicht authentifiziert Dutzende von nachgelagerten Anwendungen, und der Fernzugriff nutzt dieselbe Kette. Das funktioniert, bis die Website ausfällt. Ein Strom-, Netzwerk- oder Hardwareausfall an diesem einen Standort schaltet nicht nur Active Directory ab. Er legt jeden Dienst lahm, der für die Anmeldung darauf angewiesen ist.

Die übliche Antwort besteht darin, die Authentifizierung an einen Cloud-Identitätsanbieter, meistens Microsoft Entra ID, auszulagern, damit sich Benutzer auch dann noch anmelden können, wenn die On-Premise-Site nicht erreichbar ist. Das löst zwar die Verfügbarkeit. Es verlagert aber auch das Benutzerverzeichnis und die Authentifizierungsentscheidung aus dem eigenen Perimeter des Unternehmens in eine Infrastruktur, die einer anderen Gerichtsbarkeit unterliegt. Bevor man dies als den einzigen Weg akzeptiert, lohnt es sich zu untersuchen, wie die On-Premise-Identität resilient gestaltet werden kann, ohne von einem Hyperscaler abhängig zu sein.

Dies ist die Frage, mit der ein großer europäischer öffentlicher Betreiber derzeit mit uns arbeitet, und sie ist für jede kritische Einrichtung, die sich keinen Single Point of Failure bei der Identität leisten kann, eine häufige.

Warum ein Single-Site Active Directory jeden verbundenen Dienst gefährdet

Der Betreiber betreibt Active Directory an einem einzigen Standort. Davor authentifiziert eine On-Premises-Föderationsschicht (in diesem Fall Active Directory Federation Services) eine große Anzahl von Diensten, einschließlich des Fernzugriffs. Identitäten werden zentral erstellt und verwaltet, was solide ist. Die Schwäche ist geografischer Natur: Alles, was gegen dieses Verzeichnis authentifiziert wird, steht und fällt mit einem Standort.

Dies ist der Teil, der leicht zu unterschätzen ist. Die Sorge gilt nicht einer beschädigten Datenbank oder einem ausgefallenen Dienst, den ein lokaler Cluster auffangen könnte. Es geht um den Verlust des Standorts selbst. Wenn das Gebäude, sein Netzwerk oder die Stromversorgung ausfallen, fallen beide Hälften eines hochverfügbaren Paares am selben Standort mit aus. Ein Active-Active-Cluster mit zwei Knoten schützt vor einem Serverausfall. Er schützt jedoch nicht vor dem Ausfall des Standorts, an dem beide Knoten gehostet werden.

Die eigentliche Angriffsfläche ist also nicht Active Directory isoliert. Es ist die dahinterliegende Kette. Ein einziger Ausfall an einem Standort kann dazu führen, dass Benutzer sich nicht am Remotezugriff, an internen Systemen anmelden können. SSO und gleichzeitig für jede föderierte Anwendung. Für eine Organisation, deren Dienste laufen müssen, ist diese Konzentration das Problem, das es zu lösen gilt.

Verbessert die Verlagerung der Authentifizierung zu Entra ID tatsächlich die Ausfallsicherheit, und was kostet das?

Die Verlagerung der Authentifizierung zu Entra ID ist ein vernünftiger Instinkt. Wenn die Anmeldung in der Cloud stattfindet, hängt sie nicht mehr davon ab, ob die On-Premise-Site erreichbar ist. In dem vom Betreiber in Betracht gezogenen Modell würden Benutzer weiterhin in Active Directory erstellt und mit Entra ID synchronisiert, wobei die Authentifizierung in der Cloud gehandhabt wird. Die Verfügbarkeit verbessert sich, da der Cloud-Identitätsanbieter nicht vom Ausfall einer lokalen Site betroffen ist.

Was dies auch bewirkt, ist, dass sich die Identität verändert und wer sie kontrolliert. Das Benutzerverzeichnis wird in einen Dienst repliziert, der von einem in den USA ansässigen Anbieter betrieben wird, und die Authentifizierungsentscheidung verlagert sich ebenfalls dorthin. Die von den großen Anbietern angebotenen Datenresidenzoptionen können die Speicherung in Europa ermöglichen, aber, wie wir weiter unten erörtern, sind Residenz und Gerichtsbarkeit nicht dasselbe.

Es gibt eine zweite Kostenstelle, die leicht zu übersehen ist. Sobald die Authentifizierung von einem Cloud-Identitätsanbieter abhängt, hat das Unternehmen eine Abhängigkeit gegen eine andere eingetauscht. Die einzige On-Premise-Anlage ist nicht mehr der einzige Fehlerpunkt, aber der Cloud-Tenant und die Konnektivität dorthin sind es nun. Für einen wesentlichen Dienst ist dies ein Tausch, der bewusst und nicht standardmäßig erfolgen sollte.

Geographische Redundanz für lokale Identität ohne Hyperscaler

Es gibt eine weitere Möglichkeit, den Single Point of Failure zu beseitigen, und sie erfordert nicht, dass die Authentifizierung extern verlagert wird. Die On-Premise-Identitätsschicht kann mit einem zweiten Knoten an einem separaten Standort, einschließlich einer souveränen oder europäischen Cloud, erweitert werden, sodass der Ausfall des primären Standorts die Authentifizierung nicht zum Erliegen bringt.

Das ist wie WebADM, unsere LDAP-Administration und IAM-Konsole, ist dafür ausgelegt. Sie unterstützt einen Active-Active-Cluster, dessen Knoten sich an verschiedenen Standorten oder Rechenzentren befinden können, wobei das Verzeichnis, der SQL-Speicher und der Sitzungsstatus zwischen ihnen repliziert werden. Ein Knoten On-Premise und ein Knoten in einer souveränen Cloud bieten dem Unternehmen geografische Redundanz auf die gleiche Weise, wie ein Hyperscaler sie anbietet, während die Infrastruktur unter eigener Kontrolle bleibt. Es gibt eine praktische Einschränkung, die früh genannt werden sollte: Ein über Standorte verteilter Cluster erfordert eine kontrollierte Latenz zwischen den Knoten, die bei einem zweiten Standort in einer Cloud-Region überprüft werden muss.

Die Föderationsschicht kann auf die gleiche Weise redundant gemacht werden. Wo die nachgelagerten Dienste des Betreibers derzeit von einem On-Premise ADFS-Dienst abhängen, kann OpenOTP, unser Authentifizierungsserver, über seine Federation Services (SAML, OIDC und OAuth) als Identitätsanbieter fungieren und Multi-Faktor-Authentifizierung für den Fernzugriff hinzufügen. RADIUS-Bridge, die Komponente, die MFA für VPNs und Netzwerkausrüstung bietet. Da diese auf denselben geklasterten Knoten laufen, sind die Föderations- und VPN-Einstiegspunkte nicht mehr der einzige Fehlerpunkt. Ziel ist es nicht, das Verzeichnis zu ersetzen, sondern die gesamte Authentifizierungskette den Verlust eines beliebigen Standorts überdauern zu lassen.

Wie die Authentifizierung eine Ausfallzeit von Websites oder Active Directory übersteht

Damit die Alternative glaubwürdig ist, muss eine Frage präzise beantwortet werden: Wie funktioniert die Authentifizierung weiter, wenn der On-Premise-Standort oder das Active Directory nicht mehr erreichbar ist?

Damit diese Architektur resilient ist, ist der wichtige Punkt, wie OpenOTP und WebADM mit Active Directory bereitgestellt werden.

Im vorgeschlagenen Design bleibt Active Directory die maßgebliche Identitätsquelle. WebADM und OpenOTP können so konfiguriert werden, dass sie Benutzer und Gruppen aus Active Directory auslesen, ohne das AD-Schema zu ändern oder AD-Objekte zu modifizieren, vorausgesetzt, dem LDAP-Dienstkonto werden Lesezugriffsrechte gewährt und es sind keine AD-Write-Back-Funktionen aktiviert. Das von der RCDevs-Plattform verwendete operative Verzeichnis kann im suiteninternen OpenLDAP-Verzeichnis gehostet und über alle WebADM-Knoten hinweg repliziert werden.

Während des normalen Betriebs werden Benutzeranmeldeinformationen gegen Active Directory validiert. Sobald ein Benutzer erfolgreich authentifiziert wurde, kann OpenOTP gemäß Richtlinie lokale Offline-Validierungsdaten speichern, sodass die Authentifizierung bei einem vorübergehenden Verlust der Verbindung zu Active Directory oder zum primären Standort fortgesetzt werden kann. Dieser Mechanismus sollte nicht als Kopieren des Active Directory-Passworts in OpenLDAP beschrieben werden; die genaue Speicher- und Validierungsmethode hängt von der konfigurierten OpenOTP-Richtlinie ab.

Wenn Active Directory wieder erreichbar ist, wird die Online-Validierung gegen AD fortgesetzt. In Kombination mit WebADM- und OpenOTP-Knoten, die an zwei separaten Standorten bereitgestellt werden, ermöglicht dieses Design, dass die Authentifizierungskette den Ausfall eines Standorts übersteht, während das autoritative Verzeichnis unter der Kontrolle der Organisation bleibt.

Identitätsdaten unter europäischer Hoheitsgewalt: NIS2 und der CLOUD Act

Für einen Betreiber im öffentlichen Sektor gibt es zwei regulatorische Überlegungen, die dieser Architektur zugrunde liegen.

Das erste ist NIS2. Ein Betreiber dieser Art fällt im Allgemeinen als wesentliche Einheit unter die Verordnung, mit Verpflichtungen in Bezug auf Risikomanagement, Zugriffskontrolle, Kryptografie und Multi-Faktor-Authentifizierung. Die NIS2-Richtlinie schreibt weder ein bestimmtes Produkt vor noch verbietet sie einen bestimmten Anbieter. Gefordert wird, dass das Risiko angegangen wird, und eine starke Authentifizierung beim Zugriff auf kritische Dienste ist eine der Maßnahmen, die das von der NIS2 ins Visier genommene Risiko angehen. Die Ausweitung von MFA auf Fernzugriff, föderierte Anwendungen und administrative Konten adressiert dies direkt.

Der zweite Punkt ist die Gerichtsbarkeit, und hier divergieren Datenresidenz und rechtliche Reichweite. Der Betreiber selbst unterliegt nicht dem US CLOUD Act. Ein Cloud-Anbieter mit Sitz in den USA oder kontrolliert von einem US-amerikanischen Mutterunternehmen bleibt jedoch davon betroffen, unabhängig davon, wo die Daten physisch gespeichert sind. Das bedeutet, dass ein Benutzerverzeichnis, das in einen solchen Dienst repliziert wird, in den Geltungsbereich eines US-amerikanischen Rechtsverfahrens fallen kann, selbst wenn es in einer europäischen Region gespeichert ist. Die größten Anbieter bieten Schutzmaßnahmen und Optionen für EU-Datengrenzen, und der direkte Zugriff auf europäische Rechenzentren ist kein alltägliches Ereignis, wie einige Schlagzeilen suggerieren. Das Argument beruht nicht darauf, wie oft eine Anfrage gestellt wird. Es beruht auf der strukturellen Tatsache, dass die Daten unter einer ausländischen Rechtsordnung liegen, was genau das ist, was eine Souveränitätsanforderung ausschließen soll.

Die Beibehaltung des Verzeichnisses und der Authentifizierungsentscheidung an einem lokalen Standort, erweitert in eine souveräne Cloud anstelle eines Hyperscaler-Tenants, ermöglicht es dem Betreiber, die Resilienz-Anforderung zu erfüllen und gleichzeitig die Identitätsdaten unter europäischer Gerichtsbarkeit zu halten. Das ist der Handel, den der Umzug zu Entra ID nicht bietet.

Resilienz und Souveränität werden oft als eine Wahlmöglichkeit dargestellt: Kontrolle behalten und mit einem einzigen Ausfallpunkt leben, oder Redundanz erzielen, indem die Identität in die Cloud migriert wird. Wenn keines aufgegeben werden kann, stellt sich die Frage, ob die On-Premise-Basis konsolidiert und nicht ersetzt werden kann. Für diese Art von Einschränkung ist dies möglich.

Weiterführende Lektüre: Vergleich von Funktionen und Stufen von OpenOTP und Microsoft Entra ID.