Jeder TLS-Tunnel, den Access Gate aufbaut, und jedes vertrauenswürdige Zertifikat, das es anstelle eines selbstsignierten mit Browser-Warnung präsentiert, beruht auf einer PKI (Public-Key-Infrastruktur). Die PKI ist die Vertrauenskette, die einem Client ermöglicht zu überprüfen, dass er tatsächlich mit dem Gate spricht, und die es dem Gate ermöglicht, Zertifikate für die von ihm geschützten Assets auszustellen. Diese Seite erklärt, warum das wichtig ist, warum die PKI in der Regel der schwierige Teil ist, und die beiden Möglichkeiten, sie mit Access Gate bereitzustellen.
Warum eine PKI wichtig ist
Ein Zertifikat für sich allein beweist nichts; vertrauenswürdig wird es durch die Stelle, die es signiert hat. Eine PKI ist diese Stelle und die gesamte Maschinerie darum herum: Sie stellt Zertifikate aus, bürgt für sie über eine Signaturkette und gibt jeder Partei eine Möglichkeit zu prüfen, ob ein Zertifikat auf eine Wurzel zurückführt, der sie vertraut.
Ohne sie bleibt Ihnen das händische Verwalten selbstsignierter Zertifikate Gerät für Gerät. Jedes neue Gerät bedeutet ein weiteres nicht vertrauenswürdiges Zertifikat, eine weitere Browser-Warnung und einen weiteren Bediener, der darauf geschult ist, die Warnung zu ignorieren, die eigentlich einen Man-in-the-Middle-Angriff stoppen soll. Eine PKI ersetzt das durch einen einzigen Vertrauensanker: Vertrauen Sie der Wurzel einmal, und jedes Zertifikat darunter wird automatisch als vertrauenswürdig eingestuft.
Warum die PKI schwierig ist
Die Kryptografie ist nicht das Problem. Es ist der Lebenszyklus. Eine echte Bereitstellung muss all dies gleichzeitig lösen:
- Ausstellung und Verteilung. Jeder Endpunkt braucht das richtige Zertifikat, und jeder Client muss dem Aussteller vertrauen. Das richtige Material in großem Maßstab an die richtige Stelle zu bringen, macht den Großteil der Arbeit aus.
- Vertrauenslisten. Beide Seiten müssen der Kette vertrauen. Ein fehlendes Zwischenzertifikat oder eine nicht vertrauenswürdige Wurzel, und die Verbindung wird abgelehnt, oft mit einem undurchsichtigen Fehler.
- Rotation und Ablauf. Zertifikate laufen prinzipbedingt ab. Ein abgelaufenes Zertifikat ist ein Ausfall, und Zertifikate über eine ganze Flotte hinweg von Hand zu erneuern ist langsam und fehleranfällig, weshalb es liegen bleibt.
- Widerruf. Wenn ein Schlüssel kompromittiert wird, brauchen Sie eine Möglichkeit, das Vertrauen in sein Zertifikat zu entziehen, bevor der Angreifer es nutzt.
- Skalierung in OT. Feldgeräte können oft keinen Zertifikatsagenten ausführen oder dürfen gar nicht angefasst werden. Eine PKI pro Gerät ist schlicht unpraktikabel für genau die Geräte, die sie am dringendsten brauchen.
Deshalb setzen so viele Anlagen Verschlüsselung nur unzureichend ein. Nicht weil TLS schwierig ist, sondern weil das Tragen des Zertifikatslebenszyklus für Hunderte von Geräten es ist.
Wie die PKI von Access Gate funktioniert
Access Gate betreibt standardmäßig eine PKI und verwendet ein zweistufiges Zertifikatsmodell, das den Lebenszyklus von den Geräten weg auf das Gate verlagert:
- Ein Zwischenzertifikat, signiert von Ihrer Zertifizierungsstelle, das das Gerät nie verlässt.
- Endpunktzertifikate, die dynamisch aus dem Zwischenzertifikat generiert und an Assets und Clients übergeben werden, um jeden sicheren Tunnel aufzubauen.
Da Endpunktzertifikate bei Bedarf am Gate erzeugt werden, stellen Sie Zertifikate nicht Gerät für Gerät bereit. Das Gate wird zum Ausstellungspunkt, und die dahinter liegenden Legacy-Assets bleiben unberührt. Das ist die Verschiebung, die PKI in einem OT-Bestand praktikabel macht.
Die Ausstellung ist mit Ihrer Konfiguration verdrahtet. Die Netzwerke (vnets), die Sie in den Einstellungen von Access Gate definieren, sowie ihre Subdomains werden nativ verwendet, um die vom Gate generierten Endpunktzertifikate zu benennen und zu signieren, sodass es keinen separaten Schritt gibt, um der PKI mitzuteilen, für welche Namen sie ausstellen soll. Es ist eingebaut.
Bereitstellung: zwei Optionen
Wählen Sie danach, welcher Wurzel der Bestand vertrauen soll.
Option 1: die native PKI von Access Gate nutzen
Die interne PKI von Access Gate ist eine vollständige PKI, die das Gate selbst aufbaut und betreibt: Es ist die Wurzel und die Zertifizierungsstelle und erzeugt und pflegt die gesamte Kette ohne jede externe Abhängigkeit. Navigieren Sie zu Settings → PKI Management und klicken Sie auf Download TLS certificate. Installieren Sie dieses Zertifikat auf den Client-Rechnern, damit sie den sicheren Tunneln vertrauen, die das Gate aufbaut.
Nutzen Sie dies für Standorte, die heute keine Verschlüsselung haben und den einfachsten Weg wollen: Sie vertrauen der eigenen Wurzel des Gate einmal, und die PKI kümmert sich selbst um den Rest. Ideal für Labore, Pilotprojekte und in sich geschlossene Standorte.
Option 2: mit Ihrer eigenen Zertifizierungsstelle verketten
Die Zwischenoption integriert Access Gate in eine vorhandene PKI. Anstatt seine eigene Wurzel zu sein, verkettet sich das Gate mit der Zertifizierungsstelle Ihrer Organisation, sodass es unter einem Vertrauen ausstellt, das Ihr Bestand bereits anerkennt. Access Gate verwaltet die oben beschriebene zweistufige Liste: Das Zwischenzertifikat wird von Ihrer CA signiert und verlässt das Gerät nie, und Endpunktzertifikate werden dynamisch daraus generiert.
TLS-Tunnel werden auf der Seite Settings → Networking aktiviert. Klicken Sie auf Generate CSR (CSR = Certificate Signing Request), um das Signierdokument zu erhalten, signieren Sie es mit Ihrer Root-Zertifizierungsstelle und laden Sie das resultierende Zwischenzertifikat über Upload SCA hoch.
Nutzen Sie dies in der Produktion und in regulierten Umgebungen, in denen Zertifikate mit einer Unternehmens- oder Compliance-Wurzel verkettet sein müssen.
Zertifikatsrotation und Lebenszyklus
Das zweistufige Modell ist es, das die Rotation handhabbar macht:
- Endpunktzertifikate rotieren von selbst. Sie sind kurzlebig und werden bei Bedarf erzeugt, sodass das Gate sie automatisch neu ausstellt. Es gibt nichts, was pro Asset zu erneuern wäre, was den Fehlermodus beseitigt, der die meisten Zertifikatsausfälle verursacht.
- Das Zwischenzertifikat ist das einzige Zertifikat, das Sie besitzen. Geben Sie ihm und der signierenden Wurzel ausreichende Gültigkeit (eine signierende Wurzel ist oft etwa 10 Jahre gültig) und signieren oder erneuern Sie das Zwischenzertifikat, bevor es abläuft.
- Achten Sie auf den Ablauf von Zwischenzertifikat und Wurzel. Ein abgelaufenes Signierzertifikat verhindert die Ausstellung neuer Endpunktzertifikate, was neue Tunnel stillschweigend bricht, während bestehende fortbestehen.
- Beachten Sie die CA-Einstellungen. Die signierende CA benötigt ausreichende Pfadtiefe, um ein Zwischenzertifikat auszustellen, das wiederum Endpunktzertifikate ausstellt (Tiefe von mindestens 2). Wenn Sie Namens- oder Domänenbeschränkungen für die CA verwenden, eine empfehlenswerte Praxis, stellen Sie sicher, dass sie die vnet-Namen abdecken, für die das Gate ausstellen wird.
Wie Sie TLS für eine Enclave erzwingen, sobald die PKI vorhanden ist, erfahren Sie unter TLS-Verschlüsselung einrichten.
Zusammenfassung
Sie haben entweder die native PKI von Access Gate genutzt (laden Sie ihr Zertifikat herunter und vertrauen Sie ihm auf den Clients) oder das Gate mit Ihrer eigenen CA verkettet (erzeugen Sie eine CSR, signieren Sie sie mit Ihrer Wurzel und laden Sie das Zwischenzertifikat hoch). In jedem Fall erzeugt das Gate Endpunktzertifikate dynamisch und hüllt Assets in vertrauenswürdiges TLS, sodass Sie ein einziges Zwischenzertifikat statt eines Zertifikats pro Gerät verwalten.
Greifen Sie hierzu, bevor Sie TLS auf Enclaves erzwingen, wenn Sie vertrauenswürdige Zertifikate über den gesamten Bestand benötigen, ohne auf jedem Gerät ein Zertifikat aufzusetzen und von Hand zu pflegen.