Die meisten Industriegeräte liefern eine Weboberfläche mit, das integrierte HMI eines PLC, die Konfigurationsseite eines Antriebs, ein Gebäudemanagement-Dashboard. Viele davon kommunizieren über unverschlüsseltes HTTP auf Port 80, 8080 oder ähnlichen Ports, ohne nennenswerte Authentifizierung, und jene, die HTTPS anbieten, liefern oft ein abgelaufenes oder selbstsigniertes Zertifikat, das der Browser ablehnt. Access Gate stellt Identität und Verschlüsselung vor diese Oberflächen, ohne das Gerät anzufassen. Zwei Entscheidungen prägen die Einrichtung: wie TLS terminiert wird und ob eine Anmeldung vor der App liegt.
Wie das Gate eine Weboberfläche absichert
Access Gate ist ein protokollbewusster Proxy: Der Browser verbindet sich mit dem Gate, das Gate setzt Identität und Richtlinie durch, und das Gate verbindet sich seinerseits weiter mit dem Gerät. Da die Sitzung am Gate terminiert wird, kann es dem Benutzer ein sauberes, vertrauenswürdiges Zertifikat präsentieren, unabhängig davon, was das Gerät auf seiner Seite tut, und es kann eine Authentifizierung verlangen, bevor die App überhaupt erreichbar ist. Das Gerät bleibt genau so, wie es ist, einschließlich unverschlüsseltem HTTP.
Entscheidung 1: wie TLS terminiert wird
Es gibt drei sinnvolle Modi, in absteigender Reihenfolge ihrer Verbreitung bei Industriegeräten:
- Terminieren und im Klartext weiterleiten. Der Browser erhält HTTPS zum Gate; das Gate spricht das native HTTP des Geräts auf der geschützten Seite. Dies ist der Standard für ein Gerät, das nur unverschlüsseltes HTTP spricht. Zugangsdaten und Session-Cookies werden nicht mehr im Klartext über das Netzwerk übertragen, und das Gerät benötigt keine eigene kryptografische Funktion.
- Terminieren und neu verschlüsseln. Das Gerät stellt bereits HTTPS bereit (oft mit einem selbstsignierten Zertifikat). Das Gate verbindet sich auf der geschützten Seite per HTTPS damit, und Benutzer sehen weiterhin das vertrauenswürdige Zertifikat des Gates, nicht das des Geräts. Verwenden Sie diesen Modus, wenn auch das geschützte Segment verschlüsselt sein muss.
- Passthrough. Das Gate erzwingt Erreichbarkeit und Identität, terminiert aber kein TLS; der Browser handelt TLS direkt mit dem Gerät aus. Verwenden Sie diesen Modus nur, wenn das eigene Zertifikat des Geräts bereits vertrauenswürdig ist.
Entscheidung 2: liegt eine Anmeldung davor?
- Über den Access Screen. Verlangen Sie, dass sich der Benutzer an einem Access Screen authentifiziert, bevor die Web-App erreichbar ist. Dies ist der richtige Standard für jedes HMI mit schwacher oder gemeinsam genutzter Anmeldung auf Geräteebene, es stellt echte Identität vor eine Seite, die keine hat.
- Passthrough. Überspringen Sie den Bildschirm, wenn die App über eine eigene, angemessene Authentifizierung verfügt und Sie nur Verschlüsselung und Netzwerkkontrolle benötigen.
Einrichtung
- Fügen Sie das Asset einem Enclave hinzu, siehe Ein Asset mit Enclaves schützen.
- Fügen Sie unter Enclaves → [Ihr Enclave] → Access Control eine
allow-Regel hinzu. - Wählen Sie den Principal (Benutzer, IdP-Gruppe oder Rolle) und die Asset(s), dann speichern Sie.
- Wählen Sie den TLS-Modus (terminieren, neu verschlüsseln oder passthrough) und entscheiden Sie, ob ein Access Screen davorliegt.
- Verweisen Sie Benutzer auf die URL des Assets oder dessen Overlay-IP.

Sie können Access Gate nutzen, um eine Identitäts- und Verschlüsselungsschicht vor eine App zu schalten, die nur Klartext spricht, indem Sie einen Access Screen mit TLS-Verschlüsselung kombinieren.

Eigenheiten eingebetteter HMIs
Industrielle Weboberflächen sind selten dafür gebaut, hinter einem Proxy zu laufen. Die wiederkehrenden Stolpersteine:
- Fest kodierte
http://<ip>-Links. Manche HMIs betten absolute URLs ein, die direkt auf die Geräte-IP zeigen und das Gate umgehen. Erreicht man die App über den Overlay-Namen oder die Overlay-IP statt über die direkte Geräteadresse, bleiben diese Links innerhalb des vermittelten Pfads. - Gemischte Inhalte. Eine über HTTPS ausgelieferte Seite, die Skripte oder Bilder über unverschlüsseltes HTTP nachlädt, wird vom Browser blockiert. Wenn Sie TLS am Gate terminieren, während das Gerät bei HTTP bleibt, kann dies zutage treten; erreicht man die Assets über denselben Overlay-Pfad, vermeidet man den Konflikt.
- WebSockets. Live-Dashboards und SCADA-Webclients nutzen häufig WebSockets (
ws://oderwss://). Sie laufen über dieselbe HTTP(S)-Freigabe, aber prüfen Sie, ob der Upgrade durchgängig erlaubt ist, falls ein Dashboard keine Aktualisierungen mehr liefert. - Selbstsignierte Gerätezertifikate. Wenn das Gerät HTTPS mit einem selbstsignierten Zertifikat bereitstellt, ermöglicht der Modus Terminieren-und-neu-verschlüsseln dem Gate, sich auf der geschützten Seite zu verbinden, während Benutzer weiterhin das vertrauenswürdige Zertifikat des Gates sehen.
Zusammenfassung
Sie haben ein Web-HMI oder eine Geräteverwaltungsseite über ein Enclave veröffentlicht, gewählt, wie TLS terminiert wird (Klartext weiterleiten, neu verschlüsseln oder passthrough), und entschieden, ob ein Access Screen den Benutzer zuerst authentifiziert, sodass ein Legacy-Gerät Verschlüsselung und Identität davorgeschaltet bekommt, ohne dass auf seiner Seite etwas geändert wird.
Greifen Sie dazu, wann immer ein Industriegerät eine unverschlüsselte oder selbstsignierte HTTP-Oberfläche mit schwacher Authentifizierung bereitstellt und Sie Verschlüsselung sowie Zugriffskontrolle benötigen, ohne das Gerät zu verändern.