genusphere Deployment: browserbasiertes ZTAA ohne VPN-Clients
6 Min. Lesezeit
Ich arbeite seit 2004 mit genua-Produkten. Als genusphere dazukam, hat es meine Sicht auf Remote Access veraendert. Statt einen VPN-Tunnel aufzubauen und zu hoffen, dass die Segmentierung haelt, oeffnet der Nutzer einen Browser, authentifiziert sich und erreicht genau die Anwendung, die er braucht. Nichts anderes. Kein Netzwerkzugang, keine Client-Software, kein Lateral Movement.
Dieser Guide ist das, was ich mir gewuenscht haette, als ich angefangen habe, genusphere zu deployen. Er behandelt die Architektur, wie Hochverfuegbarkeit in der Praxis funktioniert, wie man Keycloak mit Hardware-Tokens wie YubiKeys aufsetzt, und den Migrationspfad, den ich empfehle.
Architektur — wie die Teile zusammenpassen
genusphere laeuft auf Kubernetes mit drei Schichten. Wenn man die verstanden hat, ergibt sich der Rest.
Control Plane
Hier leben die Policies. Die Control Plane steuert Authentifizierung, Session-Management und das Dashboard fuer die Konfiguration. Sie verbindet sich mit dem Identity Provider — Keycloak oder Microsoft Entra ID — und setzt durch, wer auf was zugreifen darf.
Wenn die Control Plane abstuerzt, startet Kubernetes sie neu. Das ist einer der Gruende, warum der Kubernetes-native Ansatz zaehlt: Self-Healing ohne Eigenentwicklung.
Data Plane
Die Data Plane bewegt verschluesselten Traffic zwischen Nutzern und Anwendungen. Sie laeuft active-active — mehrere Instanzen verarbeiten gleichzeitig Traffic, nicht als Failover-Setup. Lastverteilung ist eingebaut. Faellt eine Instanz aus, absorbieren die anderen die Last ohne Unterbrechung.
In der Praxis heisst das: keine Wartungsfenster fuer Data-Plane-Updates. Eine Instanz nach der anderen aktualisieren, der Traffic fliesst weiter.
Connectors
Connectors sitzen nahe an den Zielanwendungen und bilden einen Micro-Perimeter um jede einzelne. Sie sind wie dedizierte Gatekeeper: jede Anwendung bekommt ihre eigene Connector-Gruppe, und jede Gruppe kann unabhaengig skalieren.
Das ist der Punkt, der ZTAA wirklich von VPN unterscheidet. Eine kompromittierte Session in einer Anwendung kann eine andere nicht erreichen, weil die Connectors isoliert sind. Lateral Movement ist architektonisch unmoeglich, nicht nur per Policy kontrolliert.
Hochverfuegbarkeit in der Praxis
HA ist eines dieser Themen, die im Slide Deck einfach aussehen und in der Produktion kompliziert werden. So handhabt genusphere das ueber die drei Schichten:
Data Plane: Active-active mit Lastverteilung. Mehrere Instanzen laufen, Traffic verteilt sich automatisch. Faellt eine Instanz aus, uebernehmen die anderen. Kein manueller Eingriff, kein Downtime.
Control Plane: Kubernetes uebernimmt das. Wenn der Control-Plane-Pod abstuerzt, startet Kubernetes ihn sofort neu. In einem sauber konfigurierten Cluster merkt man das nicht. Bestehende Sessions laufen ueber die Data Plane weiter — die Control Plane muss nur fuer neue Authentifizierungen und Policy-Aenderungen verfuegbar sein.
Connectors: Hier wird es interessant. Connectors deployt man als Connector-Gruppen — mehrere Connectors bedienen dieselbe Anwendung. Faellt einer aus, routet Traffic zu den verbleibenden. Man entscheidet selbst, wie viele Connectors pro Gruppe, je nach Verfuegbarkeits- und Performance-Anforderungen.
Das Fazit: genusphere hat keinen Single Point of Failure, wenn man es richtig deployt. Die Architektur ist so gebaut, dass jede Schicht eine Instanz verlieren kann, ohne dass Nutzer es merken.
Identity: Keycloak, YubiKeys und phishing-resistente MFA
Die meisten Umgebungen, in denen ich arbeite, nutzen entweder Microsoft Entra ID oder Keycloak fuer Identity. Beides funktioniert mit genusphere. Aber ich will ueber Keycloak im Detail sprechen, weil es interessante Moeglichkeiten eroeffnet.
Warum Keycloak parallel zu genusphere
Keycloak gibt volle Kontrolle ueber die Identity-Schicht. Man hostet es selbst, definiert die Authentifizierungsflows und ist nicht von einem Cloud-Anbieter abhaengig fuer etwas so Kritisches wie Zugriffssteuerung.
In einem typischen Setup deploye ich Keycloak parallel zum genusphere-Rollout. Waehrend die genusphere-Infrastruktur hochfaehrt, konfigurieren wir Keycloak mit den Authentifizierungsflows, die die Organisation tatsaechlich braucht — nicht was irgendein Cloud-Anbieter als Default definiert hat.
Hardware-Tokens: YubiKeys und FIDO2
Hier wird es konkret. Keycloak unterstuetzt WebAuthn, das heisst man kann FIDO2-Hardware-Tokens wie YubiKeys als zweiten Faktor nutzen. Der Nutzer steckt den Key ein, beruehrt ihn, und ist drin. Keine SMS-Codes, keine Authenticator-Apps, kein Phishing-Risiko.
Warum ist das wichtig? Weil die groesste Bedrohung fuer jedes Zero-Trust-Setup der Credential-Diebstahl ist. Wenn ein Angreifer ein Passwort und einen SMS-Code hat, ist er drin. Ein Hardware-Token ist eine andere Kategorie — der private Schluessel verlässt nie das Geraet, und er ist an die Domain gebunden. Phishing funktioniert nicht.
In der Praxis sieht das Setup so aus: - Keycloak laeuft als Identity Provider fuer genusphere - Nutzer registrieren ihren YubiKey ueber den Keycloak Self-Service-Flow - genusphere erzwingt, dass Authentifizierung ueber Keycloak laufen muss - Der Nutzer oeffnet einen Browser, authentifiziert sich mit Passwort + YubiKey-Touch und erreicht seine Anwendung
Kein VPN-Client. Kein SMS. Kein Lateral Movement. Das ist der Stack, den ich fuer Umgebungen empfehle, die Sicherheit ernst nehmen.
Dasselbe Prinzip gilt, wenn die geschuetzte Anwendung keine klassische Business-App ist, sondern eine privilegierte DXP-Oberflaeche. Dieses Muster beschreibe ich in Magnolia Author absichern: Zero Trust fuer CMS und AI Threats.
Entra ID fuer hybride Setups
Wenn die Organisation bereits Microsoft Entra ID nutzt, integriert sich genusphere direkt. SSO und MFA laufen ueber die bestehende Microsoft-Infrastruktur. In der Praxis landen viele Umgebungen bei einem Hybrid: Entra ID fuer interne Mitarbeiter, Keycloak fuer Auftragnehmer und Partner ohne Microsoft-Konto.
Deployment-Modell
Kubernetes-nativ
genusphere laeuft auf Kubernetes. Horizontale Skalierung, automatische Neustarts, Infrastructure-as-Code. Die Control Plane nutzt Kubernetes fuer Self-Healing. Connector-Gruppen skalieren mit dem Bedarf.
Wer bereits Kubernetes betreibt, passt genusphere in die bestehende Cluster-Verwaltung ein. Wer es noch nicht tut — das ist ein guter Grund anzufangen.
On-Premises-Souveraenitaet
Anders als Cloud-basierte ZTAA-Loesungen von Zscaler oder Cloudflare wird genusphere vom Kunden selbst gehostet und betrieben. Daten verlassen nie die eigene Infrastruktur. Fuer deutsche Organisationen mit VS-NfD-, KRITIS- oder BSI-Compliance-Anforderungen ist das oft der entscheidende Faktor.
Integration mit bestehender genua-Infrastruktur
genusphere ersetzt den Rest des genua-Stacks nicht — es erweitert ihn: - genugate bleibt als Perimeter-Firewall (EAL 4+ zertifiziert, nach wie vor der Goldstandard) - genucenter bietet einheitliches Management ueber genua-Produkte - genuscreen uebernimmt VPN-Traffic waehrend der hybriden Migrationsphase - genubox deckt industrielle Remote-Maintenance unter Zero Trust ab
Migrationspfad: wie ich es angehe
Jede Migration ist anders, aber das Muster, das ich wiederholt funktionieren sehe, hat vier Phasen.
Phase 1 — Verstehen, was da ist
Alle Anwendungen inventarisieren, die aktuell ueber VPN erreichbar sind. Klassifizieren: Webanwendungen, Windows-Legacy-Apps, Admin-Interfaces, Machine-to-Machine-Traffic. Herausfinden, was zu browserbasiertem ZTAA wechseln kann und was wirklich Netzwerkzugang braucht. Ehrlich sein — nicht alles kann umziehen, und das ist okay.
Phase 2 — Beweisen, dass es funktioniert
genusphere parallel zum bestehenden VPN deployen. Eine kleine Gruppe von Webanwendungen und eine definierte Nutzergruppe auswaehlen. Keycloak (oder Entra ID) aufsetzen, Connector-Gruppen konfigurieren, den Authentifizierungsflow mit Hardware-Tokens validieren. Diese Phase beweist das Modell, ohne die Produktion anzufassen.
Phase 3 — Anwendung fuer Anwendung umziehen
Inkrementell migrieren. Webanwendungen zuerst — das ist der einfachste Gewinn. Dann Legacy-Windows-Anwendungen ueber genuspheres browserbasierte Isolation. Zugriffslogs ueberwachen, Policies tunen, Nutzerbasis erweitern. Das VPN laeuft weiter fuer alles, was noch nicht umgezogen ist.
Phase 4 — VPN-Footprint reduzieren
Sobald die meisten Anwendungen ueber genusphere laufen, das VPN zurueckfahren. Manche Umgebungen behalten VPN fuer Site-to-Site-Tunnel oder Machine-to-Machine-Traffic. Das ist normal. Die hybride Phase endet, wenn der verbleibende VPN-Scope klein und klar definiert ist.
Wann genusphere passt — und wann nicht
genusphere passt stark, wenn man applikationsspezifische Zugriffskontrolle braucht, in einer regulierten Umgebung arbeitet und die Daten auf der eigenen Infrastruktur behalten will. Hybride Belegschaften, Auftragnehmer-Zugang, Partner-Onboarding — das sind die Kernanwendungsfaelle.
Es ersetzt nicht jedes VPN-Szenario. Site-to-Site-Tunnel, Machine-to-Machine-Kommunikation und manche Legacy-Protokolle brauchen weiterhin Netzwerkkonnektivitaet. Die praktische Antwort ist fast immer ein hybrider Betrieb: genusphere fuer Application Access, genugate VPN fuer den Rest, mit abnehmendem Umfang.
Wer das evaluiert und die Spezifika der eigenen Umgebung besprechen will — melden.
FAQ
Braucht genusphere einen VPN-Client auf dem Endgeraet?
Nein. Der Nutzer oeffnet einen Browser, authentifiziert sich ueber Keycloak oder Entra ID und landet direkt in der Anwendung. Kein Agent, kein Client, kein Tunnel.
Kann genusphere parallel zu einem bestehenden genugate VPN laufen?
Ja, und in den meisten Projekten, die ich begleitet habe, startet es genau so. Das VPN laeuft weiter fuer Workloads, die noch nicht umziehen koennen. genusphere uebernimmt Anwendung fuer Anwendung.
Wie sieht das Hochverfuegbarkeits-Setup aus?
Die Data Plane laeuft active-active mit Lastverteilung. Die Control Plane heilt sich ueber Kubernetes selbst. Connectors koennen als Gruppen mit Redundanz deployt werden. Faellt ein Connector aus, routet der Traffic automatisch zu den verbleibenden Instanzen.
Kann ich Hardware-Tokens wie YubiKeys zur Authentifizierung nutzen?
Ja. Mit Keycloak als Identity Provider kann man WebAuthn mit FIDO2-Hardware-Tokens wie YubiKeys konfigurieren. Das ergibt phishing-resistente MFA ohne SMS oder App-basierte Codes.