FIPS-validierte Verschlüsselung, ohne Eingriff in Maschinen.
Access Gate verschlüsselt jede Sitzung am Proxy. Produktionsmaschinen bleiben, wie sie sind. Alle Cipher Suites sind NIST-zugelassen und FIPS-konform nach SP 800-52.
Zuletzt aktualisiert:
Wie Access Gate CUI bei der Übertragung verschlüsselt.
Industrieprotokolle wie Modbus, EtherNet/IP und DNP3 übertragen im Klartext. Die Geräte, die diese Protokolle nutzen, lassen sich nicht auf TLS aufrüsten. Access Gate verschlüsselt deshalb den Verkehr zwischen Benutzer und Proxy mit FIPS-validierten Cipher Suites. Das Klartext-Segment zwischen Proxy und Produktionsmaschine ist in einer Micro-DMZ ohne externen Ausgang isoliert. Das erfüllt NIST 800-171 SC 3.13.8 (Verschlüsselung von CUI bei der Übertragung) als kompensierende Maßnahme.
Was validiert ist und wo Sie es prüfen.
Eine FIPS-Aussage zählt nur, wenn sie Modul und Zertifikat benennt. Access Gate liefert keine selbst geschriebene Kryptografie aus. Bei Access Gate CMMC Edition läuft die Verbindung zu CUI-Enklaven wie GCC High über einen IPsec/IKEv2-Tunnel (Libreswan) unter AlmaLinux 9, mit ab dem Bootvorgang erzwungenem FIPS-Modus. Dieser Tunnel ersetzt den standardmäßig enthaltenen Tailscale-Client, denn Tailscale basiert auf WireGuard, und WireGuard ist nicht FIPS-zugelassen. Der Datenverkehr ist mit AES-256-GCM, SHA-384 und ECDH P-384 mit Perfect Forward Secrecy geschützt, und Libreswan lehnt jeden nicht zugelassenen Algorithmus ab. Das unterstützt die Anforderungen von CMMC und NIST SP 800-171 an den Schutz von CUI bei der Übertragung. Die beiden FIPS 140-3 validierten Module im Tunnelpfad sind unten mit ihrem CMVP-Zertifikat aufgeführt, damit Sie sie selbst beim NIST prüfen können.
- Modul
- Kernel Cryptography Module for AlmaLinux 9
- Rolle im Tunnel
- ESP-Datenebene: verschlüsselt den Tunnelverkehr (AES-256-GCM)
- Hersteller
- CloudLinux Inc., Bereich TuxCare
- Standard
- FIPS 140-3, Gesamtlevel 1
- CMVP-Zertifikat
- Nr. 5441, validiert am 27. Juli 2026
- Modultyp
- Software, Multi-Chip Stand Alone
- Modul
- NSS cryptography module for AlmaLinux 9
- Rolle im Tunnel
- IKEv2-Schlüsselaustausch (ECDH P-384)
- Hersteller
- CloudLinux Inc., Bereich TuxCare
- Standard
- FIPS 140-3, Gesamtlevel 1
- CMVP-Zertifikat
- Nr. 5031, validiert am 25. Juni 2025
- Modultyp
- Software, Multi-Chip Stand Alone
Ein Punkt, der in einem SSP präzise formuliert gehört. Das NIST validiert kryptografische Module und vergibt Zertifikatsnummern; es zertifiziert keine Produkte. Die Zertifikate gehören zu den Modulen von TuxCare, nicht zu Access Gate selbst. Die präzise und belastbare Aussage lautet daher, dass Access Gate FIPS 140-3 validierte Module unter den CMVP-Zertifikaten Nr. 5441 und 5031 verwendet, in einer Form, die ein Auditor direkt im CMVP-Verzeichnis prüfen kann. Zertifikat Nr. 4750 war das vorläufige Kernel-Zertifikat; das NIST hat es durch Nr. 5441 ersetzt, und die ausgelieferte Appliance läuft mit der Kernel-Version, die Nr. 5441 abdeckt. Nennt Ihr SSP noch Nr. 4750, aktualisieren Sie es. Für das Assessment stellen wir auf Anfrage die Nachweise von der ausgelieferten Appliance bereit: die Prüfung des FIPS-Modus, die installierten Paketversionen passend zu jedem Zertifikat und das Libreswan-Log, das den aktiven FIPS-Modus zeigt.
Cipher Suites für TLS 1.3.
Die TLS-1.3-Suites von Access Gate. Alle bieten Perfect Forward Secrecy. Sie werden bevorzugt und zuerst ausgehandelt.
| Cipher Suite | Status | Reference |
|---|---|---|
| TLS_AES_128_GCM_SHA256 | FIPS | TLS 1.3, NIST SP 800-52, FIPS 197 (AES-128) |
| TLS_AES_256_GCM_SHA384 | FIPS | TLS 1.3, NIST SP 800-52, FIPS 197 (AES-256) |
Cipher Suites für TLS 1.2.
TLS-1.2-Suites für die Kompatibilität mit älteren Clients. ECDHE-Suites bieten Perfect Forward Secrecy. Suites mit RSA-Schlüsselaustausch sind FIPS-zugelassen, bieten aber kein PFS.
| Cipher Suite | Status | PFS | Note |
|---|---|---|---|
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | FIPS | Yes | ECDHE key exchange, forward secrecy |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | FIPS | Yes | ECDHE key exchange, forward secrecy |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | FIPS | Yes | ECDHE key exchange, forward secrecy |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | FIPS | Yes | ECDHE key exchange, forward secrecy |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | FIPS | Yes | CBC mode, forward secrecy |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 | FIPS | Yes | CBC mode, forward secrecy |
| TLS_RSA_WITH_AES_128_GCM_SHA256 | FIPS | No | No perfect forward secrecy |
| TLS_RSA_WITH_AES_256_GCM_SHA384 | FIPS | No | No perfect forward secrecy |
| TLS_RSA_WITH_AES_128_CBC_SHA256 | FIPS | No | No perfect forward secrecy |
Note on PFS: Suites ohne Perfect Forward Secrecy (PFS) sind FIPS-zugelassen, sollten aber nachrangig sein. Wird ein privater Schlüssel kompromittiert, lassen sich vergangene Sitzungen mit Nicht-PFS-Suites entschlüsseln. Access Gate handelt ECDHE-Suites zuerst aus. Reine RSA-Suites bleiben als Rückfall für ältere Clients verfügbar.
Maschinen behalten ihre nativen Protokolle.
Verschlüsselung am Proxy.
Die Verschlüsselung erfolgt am Access-Gate-Proxy. CNC-Fräsen, Etikettiersysteme und Qualitätsscanner nutzen ihre nativen Protokolle unverändert weiter. Keine Firmware-Updates nötig.
Klartext bleibt in einer Micro-DMZ.
Das Klartext-Segment zwischen Proxy und Produktionsmaschine liegt in einer isolierten Micro-DMZ. Keine Route ins Internet oder in andere Netzsegmente. Laterale Bewegung ist blockiert.
Nachweise für CMMC SC 3.13.8.
Access Gate erzeugt Exporte der TLS-Konfiguration, Logs der Cipher-Aushandlung und Netzpläne der Micro-DMZ. Das sind die Nachweise, die ein C3PAO-Assessment der kompensierenden Maßnahme verlangt.
Fragen zur FIPS-Verschlüsselung.
Alle Cipher Suites in Access Gate sind NIST-zugelassen nach FIPS 197 (AES) und SP 800-52 (TLS-Konfiguration).
Weder noch: Das NIST validiert Module, keine Produkte, und die korrekte Aussage lautet, dass Access Gate FIPS 140-3 validierte Module nutzt. Der IPsec/IKEv2-Tunnel zu CUI-Enklaven wie GCC High läuft auf dem Kernel Cryptography Module for AlmaLinux 9 (CMVP-Zertifikat Nr. 5441) und dem NSS cryptography module for AlmaLinux 9 (CMVP-Zertifikat Nr. 5031) von TuxCare, mit erzwungenem FIPS-Modus, AES-256-GCM und P-384-Schlüsselaustausch. Auf der Proxy-Seite basiert TLS auf dem Paket crypto/tls der Go-Standardbibliothek mit FIPS-zugelassenen Cipher Suites.
Access Gate bevorzugt zuerst TLS-1.3-Suites (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256). Unterstützt der Client kein TLS 1.3, fällt es auf TLS-1.2-ECDHE-Suites im GCM-Modus zurück. Reine RSA-Suites werden nur als letzte Option ausgehandelt.
Der Benutzer verbindet sich per TLS mit Access Gate. Access Gate terminiert die verschlüsselte Sitzung und leitet den Verkehr im nativen Protokoll (Modbus TCP, EtherNet/IP usw.) an die Produktionsmaschine weiter, innerhalb einer isolierten Micro-DMZ. Das Klartext-Segment hat keinen externen Ausgang.
SC 3.13.8 verlangt die Verschlüsselung von CUI bei der Übertragung. Für OT-Geräte, die nicht selbst verschlüsseln können, bietet Access Gate eine kompensierende Maßnahme: TLS auf dem Weg vom Benutzer zum Proxy, mit dem Klartext-Segment isoliert in einer Micro-DMZ. Das wird als Enduring Exception dokumentiert, mit der Proxy-Architektur als kompensierender Maßnahme.
NIS2 Artikel 21 verlangt angemessene Verschlüsselung der Netzwerkkommunikation. Access Gate erfüllt das mit FIPS-validiertem TLS auf allen Zugriffspfaden. Dieselben Cipher Suites und dieselbe Architektur gelten für CMMC- und NIS2-Projekte.
Ja. In der Richtlinienkonfiguration von Access Gate legen Sie fest, welche Cipher Suites verfügbar sind. Sie können reine RSA-Suites ganz abschalten und ECDHE für alle Verbindungen verlangen. Das empfiehlt sich für neue Installationen, in denen alle Clients ECDHE unterstützen.
Prüfen wir gemeinsam die Verschlüsselung.
Wir gehen die Cipher Suites, die Micro-DMZ und die CMMC-Nachweise für Ihre Werke mit Ihnen durch.
Vertrieb kontaktieren