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

Automatisierung der Zertifikatsperrung mit OCSP und CRL in einer NAC-Umgebung Ein technisches Briefing von Purple - ca. 10 Minuten --- EINFÜHRUNG UND KONTEXT - ca. 1 Minute Willkommen zur Reihe der technischen Briefings von Purple. Ich bin Ihr Gastgeber, und heute befassen wir uns mit der Mechanik der Automatisierung von Zertifikatsperrungen - 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 Netzwerk, das stillschweigend gesperrte Anmeldedaten von Geräten beherbergt, die schon vor Wochen hätten getrennt werden müssen. Wir werden die technische Architektur behandeln, zwei reale Bereitstellungsszenarien durchgehen und mit den Fragen abschließen, die Ihr Team stellen sollte, bevor Sie überhaupt an eine produktive Einführung denken. Legen wir los. --- TECHNISCHER DEEP-DIVE - ca. 5 Minuten Lassen Sie uns zunächst das Problem definieren, das wir lösen wollen. In jedem nach IEEE 802.1X authentifizierten Netzwerk - dem Standard, der Enterprise WiFi, kabelgebundenem NAC und den meisten modernen Gastzugangsarchitekturen zugrunde liegt - authentifizieren sich Geräte entweder über Anmeldedaten oder über Zertifikate. Zertifikate sind vorzuziehen, da sie nicht auf gemeinsam genutzten Geheimnissen beruhen, gerätegebunden 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 Certificate Authority signierte Liste aller gesperrten Zertifikatsseriennummern. 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 um einen einfachen 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-Resistenz. Sobald die Liste heruntergeladen ist, funktioniert die Sperrprüfung auch dann, wenn Ihre CA nicht erreichbar ist. Der Nachteil ist die Latenzzeit. Wenn Sie ein Zertifikat um 9:00 Uhr morgens sperren und Ihr CRL-Aktualisierungsintervall 24 Stunden beträgt, kann 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 Liste im Cache zu verwalten, sendet Ihr RADIUS-Server für jedes zu validierende Zertifikat eine Echtzeit-Anfrage an einen OCSP-Responder – einen Dienst, der Ihrer CA vorgeschaltet ist. Der Responder liefert eine von drei Antworten: Gut, Widerrufen oder Unbekannt. Der gesamte Austausch erfolgt inline während des EAP-TLS-Handshakes, auf einer gut dimensionierten Infrastruktur in der Regel in weniger als 100 Millisekunden. Der Kompromiss bei 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: Nutzen Sie Fail-Open (die Authentifizierung wird fortgesetzt) oder Fail-Closed (der Zugriff wird verweigert, bis der Responder erreichbar ist)? Fail-Open sichert die Betriebszeit, schafft aber eine Sicherheitslücke. Fail-Closed behält das Sicherheitsniveau bei, 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 Antwort, anstatt eine eigene OCSP-Anfrage zu stellen. Dies reduziert die Last auf dem OCSP-Responder, eliminiert Datenschutzbedenken bezüglich der Offenlegung von Zertifikats-Seriennummern 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 prü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 – befindet sich 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-Verhandlung durch, validiert die Client-Zertifikatskette, prüft den Widerrufsstatus ü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 verwaltete Geräte automatisch mit Zertifikaten zu versorgen. Wenn ein Gerät abgemeldet oder außer Dienst gestellt wird, löst das MDM einen Widerrufsaufruf 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, um sicherzustellen, dass sich Widerrufsentscheidungen ohne manuelles Eingreifen auf die Zugriffsrichtlinien übertragen.Der kritische Integrationspunkt hierbei ist die Kommunikationspipeline zwischen Zertifizierungsstelle (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 Sperrung in der CA 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. --- EMPFEHLUNGEN FÜR DIE IMPLEMENTIERUNG UND FALLSTRICKE - ca. 2 Minuten Lassen Sie mich Ihnen einige praktische Ratschläge geben, die verhindern, dass Bereitstellungen schiefgehen. Erstens: Definieren Sie Ihre Toleranz für die Sperrlatenz, bevor Sie Ihren Mechanismus wählen. Wenn Sie ein Hotel-Gäste-WiFi betreiben, bei dem das Hauptrisiko ein außer Dienst gestelltes Mitarbeitergerät ist, ist ein 4-stündiges CRL-Aktualisierungsintervall wahrscheinlich in Ordnung. Wenn Sie ein Netzwerk im Gesundheitswesen betreiben, in 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 einer Produktionsumgebung keinen einzelnen OCSP-Responder. Stellen Sie mindestens zwei hinter einem Load Balancer mit Systemzustandsüberwachung bereit. Ein Ausfall des OCSP-Responders, der zu einem Fail-Closed-Verhalten führt, generiert 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 mehrere Megabyte groß werden. Ein RADIUS-Server, der jede Stunde eine 5 MB große CRL über eine WAN-Verbindung herunterlädt, ist ein Durchsatzproblem, das vorprogrammiert ist. 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. Viertens: 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: Stellen Sie ein Zertifikat aus, sperren Sie es, versuchen Sie eine Authentifizierung, überprüfen Sie die Ablehnung. Wenn Ihre Überwachung einen defekten OCSP-Responder nicht erfasst, ist Ihr Sperrmechanismus reine Formsache. 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 kompromittierte Anmeldedaten und können Ihre Abhängigkeit von der Sperrinfrastruktur vollständig verringern. Dies ist die Richtung, in die sich die Branche bewegt, und es lohnt sich, dies für neue Bereitstellungen zu evaluieren. --- SCHNELLE FRAGEN UND ANTWORTEN - ca. 1 Minute Frage: Kann ich OCSP und 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üfungen unter normalen Bedingungen und Offline-Ausfallsicherheit bei Störungen. Frage: Lässt sich die Gäste-WiFi-Plattform von Purple in ein zertifikatsbasiertes NAC integrieren? Die Plattform von Purple läuft auf der Ebene des Gastzugangs und übernimmt die Authentifizierung über das Captive Portal, die Datenerfassung sowie Analysen. Für Mitarbeiternetzwerke in Unternehmen, die 802.1X mit Zertifikatsauthentifizierung nutzen, lässt sich Purple in die zugrunde liegende Netzwerkinfrastruktur - Access Points, Controller und RADIUS-Server - integrieren, anstatt den Stack für das Zertifikatsmanagement zu ersetzen. Gast- und Mitarbeiternetzwerke sind in der Regel segmentiert und nutzen jeweils die für sie geeigneten Authentifizierungsmechanismen. Frage: Wie sieht es mit der Compliance aus? PCI-DSS 4.0 verlangt, dass der Zugriff auf Karteninhaberdaten-Umgebungen eine starke Authentifizierung nutzt. Die GDPR fordert angemessene technische Maßnahmen zum Schutz personenbezogener Daten. Beiden Richtlinien wird durch zertifikatsbasiertes 802.1X mit automatischer Sperrung entsprochen - 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 Netzwerk-Durchsetzungspunkte übertragen wurde. --- ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE - ca. 1 Minute Zusammenfassend lässt sich sagen: Die Automatisierung der Zertifikatssperrung in einer NAC-Umgebung ist eine Herausforderung auf drei Ebenen. Sie benötigen eine Zertifizierungsstelle (CA), die automatische Sperr-Trigger unterstützt, einen OCSP-Responder oder CRL-Verteilungspunkt, der hochverfügbar und richtig dimensioniert ist, sowie einen RADIUS-Server, der so konfiguriert ist, dass er den Sperrstatus als Teil seiner Zugriffsrichtlinie durchsetzt. Die Entscheidung zwischen OCSP und CRL ist keine binäre Wahl - es ist eine Entscheidung zur Risikotoleranz, die im Kontext der Sicherheitsanforderungen, der Netzwerktopologie und des betrieblichen Reifegrads Ihrer Umgebung getroffen werden sollte. Wenn Sie eine NAC-Bereitstellung aufbauen oder überprüfen und verstehen möchten, wie sich die Gast-WiFi- und Analyseplattform von Purple in die umfassendere Netzwerkarchitektur einfügt, führen Sie die Links in den Shownotes zu den relevanten technischen Leitfäden. Vielen Dank fürs Zuhören. Wir sehen uns beim nächsten Briefing. --- ENDE DES SKRIPTS