VPN, Bastionen, Server: Wie ein europäisches Rechenzentrum MFA für jeden Kunden anwendet

Ein Anbieter, der die Infrastruktur anderer Unternehmen hostet, hat nicht eine Gruppe von Benutzern zu schützen. Er hat Dutzende, die jeweils einer anderen Organisation angehören, und jeder erwartet, dass seine Identitäten, seine Richtlinien und seine Administratoren strikt von allen anderen getrennt bleiben. Die Hinzufügung von Multi-Faktor-Authentifizierung in diesem Kontext ist nicht dasselbe Problem wie die Einführung von MFA innerhalb eines einzelnen Unternehmens. Die Plattform muss sich wie viele unabhängige Authentifizierungsdienste gleichzeitig verhalten, während sie als ein System läuft, das ein kleines Team betreiben kann.

Dies ist die Situation, mit der ein europäisches Rechenzentrum auf uns zukam. Es schützt sensible Informationen und führt kritische Operationen im Namen seiner Kunden durch, indem es deren Systeme und in vielen Fällen auch deren Verzeichnisse hostet. Es wollte seinen Kunden starke Authentifizierung und Single Sign-On anbieten, als verwalteter Identitäts- und Zugriffsservice betrieben werden und nicht als nachträglich hinzugefügter zweiter Faktor, und es löste eine bestehende RSA-Implementierung ab. Der funktionale Umfang war von Anfang an breit gefächert: mehrere VPNs, Windows-Anmeldung sowohl online als auch offline und MFA für eine Vielzahl von Kundenumgebungen, einschließlich der Bastionen, die für den Zugriff auf die Kundensysteme verwendet werden. Die Benutzerpopulation zählte mehrere tausend Benutzer über alle Kunden hinweg.

Zwei Teile dieser Bereitstellung sind es wert, genauer betrachtet zu werden, da sie sich gut über diesen einen Anbieter hinaus verallgemeinern lassen. Das erste ist, wie das Lizenz- und Tenancy-Modell auf das eigene kommerzielle Angebot eines Anbieters abgebildet wird. Das zweite ist, wie die Zugriffskontrolle, nicht nur der zweite Faktor allein, in eine geschichtete Zugriffsarchitektur passt, die um Bastionen aufgebaut ist. Wir haben bereitgestellt OpenOTP, der RCDevs-Authentifizierungsserver, der über WebADM, die zentrale IAM-Konsole, die alle Dienste der Suite ausführt und steuert – von Verzeichnisverbund und Single Sign-On bis hin zu Zugriffsrichtlinien und delegierter Administration, wobei Multi-Faktor-Authentifizierung eine Schicht unter anderem darstellt. Rechenzentren und Managed Service Provider fallen eindeutig in den Geltungsbereich der NIS2, was (nicht zuletzt) dazu beiträgt, dass die Frage, wer sich bei was authentifizieren darf und wie dies protokolliert wird, hier Gewicht hat.

Warum Multi-Tenancy der schwierige Teil von IAM für einen Dienstanbieter ist

Die Schwierigkeit liegt nicht im zweiten Faktor selbst. Push-Benachrichtigungen, OTP oder FIDO2 sind gut verstanden. Der schwierige Teil ist die Skalierbarkeit der Isolation. Die Kundenbasis eines Anbieters ist selten einheitlich: Eine Handvoll sehr kleiner Kunden mit jeweils wenigen Benutzern sitzt neben größeren Kunden, die ihr eigenes Verzeichnis betreiben und erwarten, dass ihre eigenen Administratoren ihre eigenen Mitarbeiter verwalten. Ein Produkt, das eine Organisation, ein Verzeichnis und eine administrative Grenze voraussetzt, passt nicht in diese Struktur. Es zwingt den Anbieter entweder dazu, für jeden Kunden eine separate Installation einzurichten, was die Betriebskosten vervielfacht, oder alle in einen einzigen Bereich zu integrieren, was die Isolation aufhebt.

Was dieser Anbieter benötigte, war eine Plattform, die beide Arrangements gleichzeitig aufnehmen konnte: ein gemeinsamer Bereich für die kleinen Kunden und vollkommen getrennte Bereiche für die größeren, unter einer Konsole und einem Betriebsteam.

Lizenzierung, die das eigene Kundenmodell des Anbieters widerspiegelt

OpenOTP wird in einer Service Provider Edition angeboten, die genau dafür entwickelt wurde. Anstatt ein festes Produkt an eine einzelne Organisation zu lizenzieren, arbeitet der Anbieter von einer Multi-Tenant-Plattform und einer gebündelten Benutzerlizenz, die er nach eigenem Ermessen auf seine Kunden verteilt. Ein wachsender Kunde erhält einen größeren Anteil, ein schrumpfender Kunde gibt ihn wieder frei, und der Anbieter verhandelt nicht für jede Änderung einen separaten Vertrag neu. Die Komponenten werden à la carte ausgewählt, sodass jeder Kunde nur das erhält, was er nutzt, und der gesamte Stapel unter der eigenen Marke des Anbieters präsentiert werden kann.

Operativ bleibt dies kompakt. WebADM verwaltet die Mandanten von einer Konsole aus, die Suite ist darauf ausgelegt, Hunderte von einzelnen Client-Mandanten in einem Active/Active-Cluster zu hosten, und dasselbe Team verwaltet sie alle. Das Lizenzmodell folgt also eher dem kommerziellen Modell des Anbieters als umgekehrt: Der Anbieter verkauft Authentifizierung so, wie er bereits Hosting verkauft, und die Plattform wird gegen die Gesamtbevölkerung dimensioniert und nicht gegen eine starre Zählung pro Kunde.

Das Hosten jedes einzelnen Mandantenverzeichnisses nebeneinander

Das Mietmodell basiert darauf, wie Verzeichnisse angehängt werden. Für die kleineren Kunden betreibt der Anbieter einen einzigen gemeinsamen Mandanten, der von einem gemeinsamen Active Directory unterstützt wird, das sie alle zusammenhält. Für die größeren Kunden erhält jeder einen dedizierten Mandanten, der mit seinem eigenen Active Directory verbunden ist. In dieser Bereitstellung bedeutete dies ein gemeinsames Verzeichnis für die kleineren Kunden neben einer Reihe von dedizierten, pro Kunde getrennten Verzeichnissen auf derselben Plattform.

OpenOTP verbindet sich nativ mit jedem dieser Verzeichnisse. Active Directory bleibt die ultimative Quelle der Wahrheit für jeden Client: Beim Anmelden validiert OpenOTP das Passwort des Benutzers gegen das eigene Verzeichnis des Clients und wendet dann den zweiten Faktor – Push-Benachrichtigung, OTP oder FIDO2 – gemäß den für diesen Mandanten definierten Richtlinien an. WebADM stellt jedes Verzeichnis als eigenen isolierten Mandanten dar, sodass das gemeinsame Verzeichnis und die dedizierten Verzeichnisse nebeneinander bestehen können, ohne dass der Anbieter separate Installationen durchführen muss. Derselbe Ansatz erstreckt sich über Active Directory hinaus: OpenOTP funktioniert mit anderen LDAP-Verzeichnissen und integriert sich mit Entra ID, Okta, Google und weiteren Identitätsanbietern, sodass ein Anbieter, dessen Clients nicht alle auf Active Directory laufen, nicht blockiert wird.

Jeden Mandanten seine eigene Benutzerverwaltung laufen lassen, ohne Mandantengrenzen zu überschreiten

Ein Anbieter möchte nicht als Helpdesk für jeden einzelnen Benutzer seiner Kunden fungieren. Mit der Helpdesk-Anwendung kann der Anbieter die tägliche Benutzerverwaltung an jeden Kunden delegieren, sodass die eigenen Administratoren des Kunden tokens zurücksetzen, Benutzer registrieren und den First-Level-Support innerhalb ihres eigenen Mandanten übernehmen können.

Diese Delegation ist für die dedizierten Mandanten verfügbar und bewusst nicht für den gemeinsam genutzten. Ein Client, der sich im gemeinsam genutzten Mandanten befindet, teilt sich dieses Verzeichnis mit anderen Clients. Die Gewährung administrativer Zugangsrechte würde es ihm daher ermöglichen, Benutzer zu sehen, die nicht zu ihm gehören. Die Isolation, die den gemeinsam genutzten Mandanten für Kleinunternehmer wirtschaftlich macht, ist dieselbe Eigenschaft, die eine sichere Delegation darin verhindert. Größere Kunden auf dedizierten Mandanten haben keine solche Überlappung und erhalten daher ihre eigene delegierte Administration. Die Unterscheidung ist keine nachträglich angebrachte Einschränkung. Sie ergibt sich direkt daraus, wo die Identitäten der einzelnen Kunden gespeichert sind.

Wie MFA und Zugriffsrichtlinien in eine mehrschichtige Bastion-Architektur passen

Viele Anbieter setzen MFA für das VPN ein und betrachten den Fernzugriff als gelöst. In einer Hosting-Umgebung ist das nur das äußere Tor. Die wichtigen Systeme, die Server eines Kunden und die privilegierten Konten darauf, sitzen mehrere Schichten tiefer, und jede Schicht ist ein Ort, an dem ein Angreifer, der bereits eine Anmeldedaten besitzt, versucht, sich weiter vorzuarbeiten. Das Design besteht darin, dass eine gestohlene Anmeldedaten allein nicht ausreicht, und bei jeder Schicht wird eine Identitätsprüfung gemäß der Zugriffsrichtlinie des Mandanten durchgeführt, damit der Diebstahl von Anmeldedaten nicht zu einer seitlichen Bewegung führt. Der Zugriffspfad hat drei Kontrollpunkte, und die Prüfung gehört zu allen dreien.

Ein VPN schützt den Netzwerkrand, nicht die Berechtigungsgrenze

Die VPN-Verbindung eröffnet den Zugang zu einem definierten Segment der Infrastruktur und nicht zu allem auf einmal. Sie beweist, dass eine bekannte Person auf ein bekanntes Segment zugegriffen hat. Sie sagt nichts darüber aus, ob diese Person eine privilegierte Sitzung auf einem Server darin öffnen sollte. MFA am VPN ist notwendig und nicht ausreichend: Sie schützt die Grenze, während die Privilegierungsgrenze noch davor liegt.

Ein Bastion ist der Engpass für privilegierten Zugriff, daher authentifiziert er sich eigenständig.

Vom autorisierten Segment aus erreicht der Kunde einen Bastion-Host, einen Jump-Host, der eine Ebene tiefer liegt und von dem aus, und nur von diesem aus, die Zielsysteme erreicht werden. Die Bastion-Topologie folgt dem Tenant-Modell: Jeder größere Kunde hat seine eigene dedizierte Bastion, während sich kleine Kunden, die sich einen Tenant teilen, eine Bastion und einen gemeinsamen Pool von Ressourcen teilen. In jedem Fall ist die Bastion der Punkt, durch den jede privilegierte Sitzung fließt, weshalb sie niemals direkt dem Internet ausgesetzt wird (eine direkt erreichbare Bastion wird kontinuierlich gescannt und angegriffen) und weshalb die Anmeldung an der Bastion selbst nochmals geprüft wird, anstatt der vorgeschalteten VPN zu vertrauen. Hier wird nicht nur ein zweiter Faktor durchgesetzt, sondern auch die Zugriffsrichtlinie des Tenants: WebADM wertet die Bastion-Anmeldung anhand der eigenen Regeln dieses Clients über dieselbe Policy-Engine aus, die den Rest der Plattform steuert, sodass der Bastion-Zugriff eines Clients niemals die Richtlinie eines anderen Clients erbt. Der zweite Faktor ist eine Eingabe, die die Richtlinie neben der Identität des Benutzers und den Ressourcen, auf die er zugreifen darf, berücksichtigt.

Der Server-Login ist das letzte Tor, und es muss halten, wenn der Weg beeinträchtigt ist

Am Ende des Pfades befinden sich die Windows- und Linux-Server selbst. Der Windows-Login trägt MFA online und offline über den OpenOTP Credential Provider, was in einem Rechenzentrum relevant ist: Ein privilegiertes System muss für seine Administratoren auch dann erreichbar bleiben, wenn die Verbindung zum Authentifizierungsserver kurzzeitig unterbrochen ist, und ein offline-fähiger Login behält den zweiten Faktor an Ort und Stelle, anstatt ihn im ungünstigsten Moment zu verwerfen. Eine auf einer Ebene gestohlene Anmeldeinformation trägt keinen Angreifer durch die nächste Schicht, da jede von OpenOTP geschützte Anmeldung erneut nachfragt.

OpenOTP integriert sich an all diesen Punkten über die Protokolle, die sie bereits sprechen, anstatt den Anbieter zu bitten, sein Netzwerk neu zu verdrahten, was es demselben Richtlinienmodul ermöglicht, auf das VPN, das Bastion und den Server zuzugreifen, ohne drei separate Projekte durchzuführen.

Das Diagramm zeigt das generische Referenzmodell, bei dem die Dienste jedes Clients im Internet veröffentlicht werden. Diese Bereitstellung ist restriktiver: Es wird nichts online verfügbar gemacht, außer den Endpunkten, die für Push-Benachrichtigungen benötigt werden, die den RCDevs-Cloud-Push-Dienst erreichen. Die als HAProxy- und WAProxy-Cluster dargestellte Proxy-Ebene wird von F5-Geräten übernommen, die auch die Firewall-Funktionen an vorderster Front übernehmen, und die als separate Cluster dargestellten SQL- und LDAP-Speicher laufen direkt auf den beiden WebADM-Knoten statt auf dedizierten Speicherebenen. Jeder Client erreicht seinen eigenen Mandanten über ein eigenes dediziertes VPN und eine eigene URL, niemals über eine gemeinsam genutzte öffentliche Schnittstelle.

Skalierung desselben Modells über mehrere Rechenzentren

Nichts an diesem Design ist an einen einzigen Standort gebunden. Ein Anbieter, der mehrere Rechenzentren betreibt, platziert einen WebADM-Knoten in jedem: entweder einen vollständigen Cluster pro Rechenzentrum oder einen Knoten eines globalen Clusters pro Standort. Die Plattform erstreckt sich darüber, ohne die Art und Weise, wie Mandanten, Verzeichnisse oder Richtlinien definiert sind, zu ändern. Das Hinzufügen eines Rechenzentrums bedeutet das Hinzufügen eines Knotens, nicht den Neuaufbau des Authentifizierungsdienstes. Ein Anbieter kann von einem Standort zu mehreren wachsen oder eine neue Region übernehmen, und dasselbe Mandanten-Modell bleibt unverändert.

Für einen Anbieter in dieser Position ist der nützliche Punkt, dass der Authentifizierungsdienst nicht für jeden Kunden einzeln installiert werden muss und bei der Verwaltung nicht auf Isolation verzichten muss. Eine Multi-Tenant-Plattform kann einen gemeinsamen Mandanten für kleine Kunden und dedizierte Mandanten für große Kunden aufnehmen, das eigene Verzeichnis jedes Kunden anhängen, die Administration delegieren, wo die Isolation dies zulässt, MFA über VPNs, Bastionen und Server-Logins erzwingen und sich über so viele Rechenzentren erstrecken, wie der Anbieter betreibt.

Weiterführende Literatur

• OpenOTP für Dienstleister (MSSP-Edition): https://www.rcdevs.com/mssp-partners/
• Lizenzfunktionen und Editionen: https://www.rcdevs.com/license-features/
• OpenOTP im Vergleich mit Cloud IAM- und MFA-Lösungen: https://www.rcdevs.com/compare_cloud_iam_and_mfa_solutions/
• WebADM, die zentrale IAM-Konsole: https://www.rcdevs.com/products/webadm/
• MFA im VPN und SSL VPN: https://www.rcdevs.com/solutions/vpn/