Automatisierung des Zertifikatswiderrufs mit OCSP und CRL in einer NAC-Umgebung

Automatisierung des Zertifikatswiderrufs mit OCSP und CRL in einer NAC-Umgebung Ein Purple Technical Briefing — ca. 10 Minuten --- EINFÜHRUNG UND KONTEXT — ca. 1 Minute Willkommen zur Purple Technical Briefing-Reihe. Ich bin Ihr Gastgeber, und heute befassen wir uns mit der Mechanik der Automatisierung des Zertifikatswiderrufs — insbesondere damit, wie OCSP und CRL innerhalb einer Network Access Control-Umgebung funktionieren und warum diese Entscheidung eine der am häufigsten übersehenen Sicherheitsfragen bei WiFi-Bereitstellungen in Unternehmen ist. Wenn Sie eine Hotelkette, ein Einzelhandelsnetzwerk, ein Stadion oder ein Netzwerk im öffentlichen Sektor mit Hunderten oder Tausenden von verbundenen Geräten betreiben, ist das Lifecycle-Management von Zertifikaten kein optionales Extra. Es ist der Unterschied zwischen einem Netzwerk, das Richtlinien in Echtzeit durchsetzt, und einem, das im Stillen widerrufene Anmeldedaten von Geräten beherbergt, die schon vor Wochen hätten getrennt werden müssen. Wir werden uns mit der technischen Architektur befassen, zwei reale Bereitstellungsszenarien durchgehen und mit den Fragen abschließen, die Ihr Team stellen sollte, bevor Sie sich an ein Produktions-Rollout wagen. Legen wir los. --- TECHNISCHER DEEP-DIVE — ca. 5 Minuten Zuerst wollen wir das Problem definieren, das wir lösen. In jedem über IEEE 802.1X authentifizierten Netzwerk — dem Standard, der WiFi in Unternehmen, kabelgebundenes NAC und die meisten modernen Architekturen für den Gastzugang unterstützt — authentifizieren sich Geräte entweder über Anmeldedaten oder Zertifikate. Zertifikate sind vorzuziehen, da sie nicht auf gemeinsam genutzten Geheimnissen basieren, an das Gerät gebunden sind und sich über Protokolle wie SCEP nahtlos in MDM-Plattformen integrieren lassen. Aber Zertifikate haben einen Lebenszyklus. Sie laufen ab, sie werden kompromittiert und Geräte werden außer Betrieb genommen. Wenn eines dieser Dinge passiert, benötigen Sie einen Mechanismus, der Ihrer Netzwerkinfrastruktur mitteilt: Dieses Zertifikat ist nicht mehr gültig, vertrauen Sie ihm nicht mehr. Dieser Mechanismus existiert in zwei Varianten: CRL (Certificate Revocation List) und OCSP (Online Certificate Status Protocol). Beginnen wir mit CRL. Eine Certificate Revocation List ist genau das, wonach es klingt — eine von Ihrer Zertifizierungsstelle (CA) signierte Liste aller Seriennummern von Zertifikaten, die widerrufen wurden. Ihre NAC-Infrastruktur — in der Regel ein RADIUS-Server wie FreeRADIUS, Cisco ISE oder Aruba ClearPass — lädt diese Liste regelmäßig von einem CRL-Verteilungspunkt herunter, bei dem es sich lediglich um einen HTTP- oder LDAP-Endpunkt handelt. Der RADIUS-Server speichert die Liste lokal im Cache und gleicht eingehende Zertifikatsseriennummern während des EAP-TLS-Handshakes mit ihr ab. Der betriebliche Vorteil von CRL liegt in der Einfachheit und der Offline-Resilienz. Sobald die Liste heruntergeladen ist, funktioniert die Widerrufsprüfung auch dann, wenn Ihre CA nicht erreichbar ist. Der Nachteil ist die Latenz. Wenn Sie ein Zertifikat um 9:00 Uhr morgens widerrufen und Ihr CRL-Aktualisierungsintervall 24 Stunden beträgt, könnte sich dieses Gerät bis zum nächsten geplanten Download weiterhin authentifizieren. In einer Hochsicherheitsumgebung — einem Krankenhaus, dem Backoffice eines Finanzdienstleisters, einem Regierungsnetzwerk — ist dieses Zeitfenster inakzeptabel. OCSP löst das Latenzproblem. Anstatt eine lokale, im Cache gespeicherte Liste zu pflegen, sendet Ihr RADIUS-Server für jedes zu validierende Zertifikat eine Echtzeit-Abfrage an einen OCSP-Responder – einen Dienst, der Ihrer CA vorgeschaltet ist. Der Responder liefert eine von drei Antworten: „Good“ (Gültig), „Revoked“ (Gesperrt) oder „Unknown“ (Unbekannt). Der gesamte Austausch findet inline während des EAP-TLS-Handshakes statt, in der Regel in weniger als 100 Millisekunden auf einer gut dimensionierten Infrastruktur. Der Nachteil von OCSP ist die Abhängigkeit von der Verfügbarkeit. Wenn Ihr OCSP-Responder ausfällt oder Ihr RADIUS-Server ihn aufgrund einer Netzwerkpartitionierung nicht erreichen kann, müssen Sie eine Richtlinienentscheidung treffen: Wählen Sie „Fail Open“ – d. h. die Authentifizierung wird fortgesetzt – oder „Fail Closed“ – d. h. der Zugriff wird verweigert, bis der Responder wieder erreichbar ist? „Fail Open“ sichert die Betriebszeit, schafft jedoch eine Sicherheitslücke. „Fail Closed“ wahrt das Sicherheitsniveau, kann aber bei einem Infrastrukturvorfall legitime Benutzer aussperren. Es gibt eine dritte Option, die man kennen sollte: OCSP-Stapling. Bei diesem Modell ruft der Zertifikatsinhaber – das Client-Gerät – regelmäßig eine signierte OCSP-Antwort vom Responder ab und fügt sie an den TLS-Handshake an. Der RADIUS-Server validiert die angehängte („gestapelte“) Antwort, anstatt eine eigene OCSP-Abfrage durchzuführen. Dies verringert die Last auf dem OCSP-Responder, eliminiert Datenschutzbedenken hinsichtlich der Offenlegung von Zertifikatsseriennummern gegenüber einem externen Dienst und erhöht die Ausfallsicherheit. Der Nachteil ist, dass nicht alle EAP-Supplicants Stapling unterstützen. Sie müssen daher die Client-Kompatibilität überprüfen, bevor Sie sich darauf verlassen. Wie fügt sich das nun in eine NAC-Architektur ein? Ihre NAC-Policy-Engine – sei es Cisco ISE, Aruba ClearPass, Juniper Mist oder ein Open-Source-Stack auf Basis von FreeRADIUS und PacketFence – sitzt zwischen dem Supplicant und dem Netzwerk. Wenn ein Gerät versucht, eine Verbindung herzustellen, empfängt der RADIUS-Server den Access-Request, führt die EAP-TLS-Aushandlung durch, validiert die Client-Zertifikatskette, prüft den Sperrstatus über OCSP oder CRL und stellt dann entweder ein Access-Accept mit einer VLAN-Zuweisung oder ein Access-Reject aus. Die Automatisierung greift auf zwei Ebenen. Erstens auf der Ebene der Zertifikatsausstellung: Ihre MDM-Plattform – Jamf, Intune, Workspace ONE – nutzt SCEP, um Zertifikate automatisch auf verwalteten Geräten bereitzustellen. Wenn ein Gerät abgemeldet oder außer Dienst gestellt wird, löst das MDM einen Sperraufruf an die CA aus, die die CRL aktualisiert und den OCSP-Responder benachrichtigt. Zweitens auf der Ebene der NAC-Durchsetzung: Ihr RADIUS-Server ist so konfiguriert, dass er OCSP abfragt oder seinen CRL-Cache nach einem festgelegten Zeitplan aktualisiert. So wird sichergestellt, dass Sperrentscheidungen ohne manuelles Eingreifen in die Zugriffsrichtlinie einfließen. Der kritische Integrationspunkt ist hier die Kommunikations-Pipeline zwischen CA und NAC. In einer gut konzipierten Bereitstellung ist die Sperrung eine vollautomatische Kette: Das MDM nimmt das Gerät außer Betrieb, löst die CA-Sperrung aus, die CA aktualisiert den OCSP-Responder und veröffentlicht eine neue CRL, der RADIUS-Server übernimmt die Änderung – entweder sofort über OCSP oder innerhalb des nächsten CRL-Aktualisierungsfensters – und dem Gerät wird beim nächsten Authentifizierungsversuch der Zugriff verweigert. --- IMPLEMENTIERUNGSEMPFEHLUNGEN UND STOLPERSTEINE — ca. 2 Minuten Hier sind einige praktische Ratschläge, die verhindern, dass Ihre Bereitstellung schiefgeht. Erstens: Definieren Sie Ihre Toleranz für Sperrlatenzen, bevor Sie Ihren Mechanismus wählen. Wenn Sie ein Hotel-Gäste-WiFi-Netzwerk betreiben, bei dem das Hauptrisiko in einem ausgemusterten Mitarbeitergerät besteht, ist ein CRL-Aktualisierungsintervall von 4 Stunden wahrscheinlich in Ordnung. Wenn Sie ein Netzwerk im Gesundheitswesen betreiben, bei dem ein kompromittiertes Gerät auf Patientendaten zugreifen könnte, benötigen Sie OCSP mit einer Fail-Closed-Richtlinie und einem hochverfügbaren Responder-Cluster. Zweitens: Betreiben Sie in der Produktion keinen einzelnen OCSP-Responder. Stellen Sie mindestens zwei hinter einem Load Balancer mit Zustandsüberwachung (Health Monitoring) bereit. Ein Ausfall des OCSP-Responders, der zu einem Fail-Closed-Verhalten führt, erzeugt schneller Support-Tickets als fast jeder andere Infrastrukturausfall. Drittens: Achten Sie auf die Größe Ihrer CRL. In großen Bereitstellungen – wir sprechen hier von Zehntausenden von Zertifikaten – können CRL-Dateien auf mehrere Megabyte anwachsen. Ein RADIUS-Server, der stündlich eine 5 MB große CRL über eine WAN-Verbindung herunterlädt, führt unweigerlich zu Durchsatzproblemen. Erwägen Sie Delta-CRLs, die nur Änderungen seit der letzten vollständigen CRL enthalten, oder migrieren Sie in Umgebungen mit hohem Datenaufkommen zu OCSP. Hier ist der vierte Punkt: Testen Sie Ihre Sperr-Pipeline regelmäßig. Es reicht nicht aus, OCSP zu konfigurieren und davon auszugehen, dass es funktioniert. Automatisieren Sie einen monatlichen Test: Zertifikat ausstellen, sperren, Authentifizierung versuchen, Ablehnung überprüfen. Wenn Ihre Überwachung einen defekten OCSP-Responder nicht erfasst, ist Ihr Sperrmechanismus reine Show. Fünftens: Stimmen Sie die Gültigkeitsdauer Ihrer Zertifikate mit Ihrer Sperrstrategie ab. Kurzlebige Zertifikate – 24 bis 72 Stunden – verkürzen das Zeitfenster für die Gefährdung kompromittierter Anmeldedaten und können Ihre Abhängigkeit von der Sperrinfrastruktur insgesamt verringern. Dies ist die Richtung, in die sich die Branche bewegt, und es lohnt sich, dies für neue Bereitstellungen zu prüfen. --- SCHNELLE FRAGEN UND ANTWORTEN — ca. 1 Minute Frage: Kann ich sowohl OCSP als auch CRL gleichzeitig verwenden? Ja. Die meisten RADIUS-Implementierungen unterstützen eine Fallback-Kette: Versuchen Sie zuerst OCSP und weichen Sie auf CRL aus, wenn der Responder nicht erreichbar ist. Dies bietet Ihnen Echtzeit-Prüfung unter normalen Bedingungen und Offline-Ausfallsicherheit bei Störungen. Frage: Lässt sich die Gäste-WiFi-Plattform von Purple in zertifikatsbasiertes NAC integrieren? Die Plattform von Purple arbeitet auf der Ebene des Gastzugangs und übernimmt die Authentifizierung über das Captive Portal, die Datenerfassung und die Analysen. Für Netzwerke von Unternehmensmitarbeitern, die 802.1X mit Zertifikatsauthentifizierung nutzen, lässt sich Purple in die zugrunde liegende Netzwerkinfrastruktur – die Access Points, Controller und RADIUS-Server – integrieren, anstatt den Stack für das Zertifikatsmanagement zu ersetzen. Die Gast- und Mitarbeiternetzwerke sind in der Regel segmentiert, wobei für jedes Netzwerk die jeweils geeigneten Authentifizierungsmechanismen verwendet werden. Frage: Wie sieht es mit der Compliance aus? PCI DSS 4.0 erfordert, dass der Zugriff auf Karteninhaber-Datenumgebungen eine starke Authentifizierung nutzt. Die GDPR verlangt angemessene technische Maßnahmen zum Schutz personenbezogener Daten. Beide Frameworks werden durch zertifikatsbasiertes 802.1X mit automatischer Sperrung erfüllt – vorausgesetzt, Sie können nachweisen, dass die Sperrung rechtzeitig erfolgt und getestet ist. Ihr Audit-Trail muss zeigen, wann Zertifikate gesperrt wurden und wann diese Sperrung an die Netzwerkdurchsetzung übermittelt wurde. --- ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE – ca. 1 Minute Zusammenfassend lässt sich sagen: Die Automatisierung der Zertifikatssperrung in einer NAC-Umgebung ist ein Problem auf drei Ebenen. Sie benötigen eine CA, die automatische Sperr-Trigger unterstützt, einen OCSP-Responder oder CRL-Verteilungspunkt, der hochverfügbar und angemessen dimensioniert ist, und einen RADIUS-Server, der so konfiguriert ist, dass er den Sperrstatus als Teil seiner Zugriffsrichtlinie durchsetzt. Die Entscheidung zwischen OCSP und CRL ist nicht binär – es ist eine Risikoabwägung, die im Kontext der Sicherheitsanforderungen, der Netzwerktopologie und der betrieblichen Reife Ihrer Umgebung getroffen werden sollte. Wenn Sie ein NAC-Deployment aufbauen oder überprüfen und verstehen möchten, wie sich die Plattform für Gast-WiFi und Analysen von Purple in die breitere Netzwerkarchitektur einfügt, führen Sie die Links in den Shownotes zu den entsprechenden technischen Handbüchern. Vielen Dank fürs Zuhören. Wir sehen uns beim nächsten Briefing. --- ENDE DES SKRIPTS