In Betrieb · Souveräner Zugriff
Zugriff ohne offene Ports statt VPN
Zugriff ohne offene Ports mit Obhut: Zero-Trust-Fernzugriff aus Deutschland statt VPN. Der Agent hält Ziele geschlossen, die Edge prüft Identität, Gruppen, mTLS und JWT.
Zugriff ohne offene Ports bedeutet bei Obhut, dass Ihre privaten Ziele keinen einzigen eingehenden Port ins öffentliche Internet öffnen: Ein lokaler Agent baut ausschließlich eine ausgehende, gegenseitig authentifizierte Verbindung zur Obhut-Edge auf, und erst die Edge prüft Identität, Gruppen, Client-Zertifikat (mTLS) und JWT, bevor eine Anfrage überhaupt weitergeleitet wird. Damit tritt an die Stelle eines klassischen VPN-Zugangs ein Zero-Trust-Zugriffsmodell (ZTNA), in dem jede Anfrage einzeln autorisiert wird, statt ein ganzes Netz freizuschalten. Dieser Zugriffs-Datenpfad — Agent, Edge, Tunnel, TLS, Zugriffspolitik und Audit-Pfad — ist der veröffentlichte Kern von Obhut und heute in Betrieb.
Warum keine offenen Inbound-Ports
Jeder eingehende Port, den Sie für Fernzugriff öffnen — RDP, SSH, ein Admin-Panel, eine interne API — ist eine Angriffsfläche, die permanent gescannt wird. Beim Zugriff ohne offene Ports entfällt diese Fläche vollständig: Das Ziel nimmt keine eingehenden Verbindungen aus dem Internet an, sondern der Agent verbindet sich ausgehend zur Edge. Was nicht erreichbar ist, kann nicht direkt angegriffen werden.
So funktioniert der Zugriffspfad
Ein Agent läuft neben Ihrer Anwendung und hält das Ziel nach außen geschlossen. Er baut einen ausgehenden, TLS-gesicherten Tunnel zur Obhut-Edge auf. Die Edge terminiert die Verbindung des Aufrufers, prüft Identität über OIDC, Gruppenzugehörigkeit, Client-Zertifikat und JWT gegen die hinterlegte Zugriffspolitik und leitet nur erlaubte Anfragen durch den bestehenden Tunnel weiter. Jede Entscheidung wird gemessen und in den Audit-Pfad geschrieben.
ZTNA statt VPN
Ein klassisches VPN verbindet ein Gerät mit einem Netz und vertraut danach breit; ist der Tunnel erst aufgebaut, ist oft mehr erreichbar als nötig. Zero Trust Network Access dreht das um: Nicht das Netz wird freigeschaltet, sondern die einzelne Anfrage auf eine bestimmte Anwendung wird pro Aufruf gegen Identität und Regeln geprüft. Es gibt keinen offenen Netzzugang, den ein kompromittiertes Gerät ausnutzen könnte, und keinen eingehenden VPN-Konzentrator, der selbst zum Ziel wird.
Prüfung an der Edge, bevor weitergeleitet wird
Die Autorisierung passiert vollständig an der Edge, vor der Weiterleitung: Identität über OIDC, Gruppen- und Rollenregeln, Identitätsheader, mTLS-Client-Zertifikate und JWT/JWKS-Validierung. Erst wenn die Zugriffspolitik eine Anfrage erlaubt, erreicht sie die Anwendung durch den ausgehenden Tunnel. Erlauben, Ablehnen, Protokollieren und Herausfordern sind dabei explizite Entscheidungen im Datenpfad, nicht implizite Netzfreigaben.
Souverän aus Deutschland betrieben
Der Zugriffspfad läuft auf Infrastruktur in Deutschland (netcup), ohne US-Hyperscaler im Anwendungspfad. Die Kerntechnik — Agent, Edge, Zugriffspolitik, Messung und Audit-Kette — baut Obhut selbst, statt eine managed US-ZTNA-Plattform weiterzuverkaufen. Für Organisationen, die europäische Datenhoheit und einen prüfbaren Betrieb gegenüber Prüfern belegen müssen, ist das ein Unterschied zu US-SASE/ZTNA-Anbietern wie Zscaler oder Cloudflare Access.
Nachweisbar statt behauptet
Zugriffs- und Blockierungsentscheidungen werden signiert verkettet, sodass nachträgliche Änderung, Löschung oder Umsortierung erkennbar wird. Aus demselben Datenpfad entstehen Evidenzpakete, ein SIEM-Export und eine Kontrollsicht. Wer regulierten Fernzugriff belegen muss, erhält so eine prüfbare Faktenbasis statt einer reinen Zusicherung.
FAQ
Häufige Fragen zum Zugriff ohne offene Ports
Zugriff ohne offene Ports bedeutet, dass die geschützte Anwendung keinen eingehenden Port ins öffentliche Internet öffnet. Statt einen Port für Fernzugriff freizugeben, baut ein lokaler Agent eine ausgehende Verbindung zur Obhut-Edge auf. Die Edge prüft Identität, Gruppen, mTLS und JWT und leitet nur autorisierte Anfragen durch diesen bestehenden Tunnel weiter.
Ja, für den Anwendungszugriff. Ein VPN verbindet ein Gerät mit einem Netz und vertraut danach breit. Obhut setzt stattdessen auf Zero Trust Network Access: Jede Anfrage auf eine bestimmte Anwendung wird einzeln gegen Identität und Regeln geprüft, ohne dass ein ganzes Netz erreichbar wird und ohne eingehenden VPN-Konzentrator als Ziel.
Das Zugriffsmodell ist vergleichbar: ausgehender Konnektor, Prüfung der Identität an der Edge, keine offenen Inbound-Ports. Der Unterschied liegt in Jurisdiktion und Betrieb. Obhut wird in Deutschland betrieben, ohne US-Hyperscaler im Anwendungspfad, und baut die Kerntechnik selbst, statt eine managed US-Plattform weiterzuverkaufen. Das ist relevant für europäische Datenhoheit und für Nachweise gegenüber Prüfern.
Ja. Der Zugriffs-Datenpfad — Edge, Agent, Tunnel, TLS, Zugriffspolitik und Audit-Pfad — ist der veröffentlichte Kern von Obhut und in Betrieb. Sie können ein Konto anlegen, den Agenten neben eine Anwendung setzen und den Zugriff in der Konsole einrichten.
Die Edge prüft vor jeder Weiterleitung Identität über OIDC, Gruppen- und Rollenregeln, Identitätsheader, mTLS-Client-Zertifikate und JWT/JWKS gegen die hinterlegte Zugriffspolitik. Erst eine erlaubte Anfrage erreicht die Anwendung durch den ausgehenden Tunnel; jede Entscheidung wird gemessen und in den Audit-Pfad geschrieben.
Obhut unterstützt die Umsetzung entsprechender Anforderungen: Der Zugriffspfad erzeugt signierte, verkettete Ereignisse, Evidenzpakete, einen SIEM-Export und eine Kontrollsicht, mit denen sich Fernzugriff prüfbar belegen lässt. Obhut ist dabei ein Baustein und keine Zertifizierung oder Compliance-Garantie; vertragliche Zusagen folgen nach rechtlicher Prüfung.
Die produktiven Dienste laufen auf Infrastruktur in Deutschland, ohne US-Hyperscaler im Anwendungspfad. Die Vertrauensseite benennt den aktuellen Subprozessorenstand mit Zweck, Standort, Datenkategorien und AVV-Status; vertragliche Zusagen folgen nach rechtlicher Prüfung.
Ersten Zugriff ohne offene Ports einrichten.
Starten Sie kostenlos, setzen Sie den Agenten neben Ihre Anwendung und richten Sie den geprüften Zugriffspfad in der Konsole ein — oder begleiten Sie die Plattformvalidierung als Design-Partner.