Ein Ausfall am Montagmorgen beginnt selten mit einem dramatischen PKI-Fehler. Er beginnt mit einem Zertifikat, von dessen Existenz niemand wusste. Das RADIUS-Zertifikat auf einem WiFi Authentifizierungsserver läuft am Wochenende ab, die erste Schicht trifft ein, und Hunderte von Benutzern können keine Verbindung herstellen. Der Bereitschaftstechniker durchsucht Dashboards, Anbieterportale, alte Tabellenkalkulationen und Serverspeicher, bevor er die eigentliche Ursache entdeckt.
Dieser Vorfall ändert die Fragestellung. Bei der Frage, wie Zertifikate verwaltet werden sollen, geht es nicht hauptsächlich darum, Schlüssel zu generieren oder auf "Verlängern" zu klicken. Es ist eine Frage der Sichtbarkeit, der Eigentümerschaft, der Abhängigkeiten und des zuverlässigen Handelns in Netzwerk-, Identitäts-, Anwendungs- und Geräteteams. Ein Zertifikatslebenszyklus funktioniert nur dann, wenn jemand jedes Zertifikat identifizieren, die davon abhängigen Systeme verstehen und die für den Austausch verantwortliche Person oder Automatisierung erreichen kann.
Warum unkontrollierte Zertifikatsvermehrung das eigentliche Problem ist
Die unkontrollierte Verbreitung von Zertifikaten nimmt in Organisationen mit gemischter Infrastruktur ganz natürlich zu. Netzwerkingenieure verwalten RADIUS- und VPN-Zertifikate. Sicherheitsteams überwachen SAML- und OIDC-Signaturzertifikate. DevOps-Teams stellen TLS-Anwendungszertifikate über Cloud-Plattformen oder CI/CD-Pipelines aus. IT-Administratoren stellen Geräte-Registrierungszertifikate über Endpunkt-Managementsysteme bereit.
Jedes Team kann für sich genommen vernünftig agieren und dennoch eine Infrastruktur schaffen, die niemand als Ganzes überblicken kann.
Praktische Regel: Behandeln Sie jedes Zertifikat als produktive Abhängigkeit und nicht als eine Datei, die zufällig auf einem Server liegt.
Tabellenkalkulationen scheitern, weil sie das erfassen, woran sich jemand erinnert, und nicht das, was die Umgebung tatsächlich verwendet. Sie erkennen Zertifikate selten automatisch, stellen die Kette vom Leaf-Zertifikat über die Zwischen- bis zur Root-CA nicht zuverlässig dar und können Ihnen nicht sagen, ob ein Zertifikat auf einen zweiten Load Balancer, eine Appliance oder einen vom Anbieter verwalteten Dienst kopiert wurde. Eine Tabellenkalkulation kann eine Überprüfung unterstützen, aber sie sollte nicht das System sein, das Sie vor einem Ausfall warnt.
Das betriebliche Risiko ist in der britischen Berichterstattung gut dokumentiert. Nur 34 % der befragten Personen hatten einen vollständigen, aktuellen Überblick über ihre digitalen Zertifikate, während 74 % sehr oder äußerst besorgt über Ausfälle waren, die durch abgelaufene Zertifikate verursacht wurden. Dieselbe Berichterstattung ergab, dass 51 % isolierte Tools als große Herausforderung nannten und 47 % der befragten Führungskräfte sich immer noch auf Tabellenkalkulationen für die manuelle Verfolgung verließen. Diese Zahlen stammen aus dem UK certificate visibility and sprawl reporting.
Der Kompromiss zwischen langen und kurzen Laufzeiten
Langlebige Zertifikate reduzieren den Wartungsaufwand. Sie lassen jedoch auch ein größeres Zeitfenster, in dem ein kompromittierter privater Schlüssel nützlich bleiben kann, und ein vergessenes Zertifikat kann unbemerkt bleiben, bis eine nicht damit zusammenhängende Systemänderung es offenlegt.
Kurzlebige Zertifikate reduzieren dieses Risiko, erfordern jedoch eine zuverlässige Automatisierung. Die Erneuerung muss einen neuen Schlüssel generieren, das Ersatzzertifikat abrufen, die vollständige Kette verteilen, es auf den richtigen Endpunkten bereitstellen und überprüfen, ob die Clients dem neuen Ergebnis vertrauen. Der UK DWP PKI standard legt unterschiedliche maximale Lebensdauern für Root-, Richtlinien-, Subordinate- und End-Entity-Schlüssel fest, was verdeutlicht, warum eine einzige pauschale Richtlinie selten für jede Zertifikatsklasse funktioniert.
Der erste praktische Schritt ist daher nicht die Automatisierung. Es ist ein einheitliches Inventar, das Erkennung, Eigentumsverhältnisse, Abhängigkeiten, Risikoklassifizierung und Bereitstellungsnachweise kombiniert. Ohne dieses Fundament erneuert die Automatisierung nur die Zertifikate, die ein einziges Tool sehen kann, während Schatten-Zertifikate andernorts unbemerkt weiter altern.
Aufbau eines vollständigen Zertifikatsinventars
Eine produktive Bestandsaufnahme beginnt mit der Erkennung, nicht mit der manuellen Dateneingabe. Führen Sie authentifizierte Scans der von Ihrem Unternehmen betriebenen Dienste durch, einschließlich TLS- und Verzeichnisdienst-Endpunkten, und fragen Sie dann die Plattformen ab, die Zertifikate ausstellen oder speichern. Netzwerkscans können offengelegte Zertifikate auf Ports wie 443, 636, 8443 und 1812 identifizieren. Die serverseitige Erfassung sollte Windows-Zertifikatsspeicher, Speicherorte im Linux-Dateisystem, Java-Keystores, Reverse-Proxies, Load-Balancer, Firewalls, Wireless-Controller und verwaltete Appliances überprüfen.
Behandeln Sie Verzeichnisdienste als separate Erkennungsquelle. Fragen Sie Zertifikatsobjekte und Profile in Microsoft Entra ID, Active Directory, Google Workspace, Okta und Plattformen für die Endpunktverwaltung ab. Ein Zertifikat wird unter Umständen nie auf einem überwachten Port angezeigt, steuert aber dennoch die Geräteauthentifizierung oder den WiFi-Zugriff. Netzwerkhersteller stellen eine weitere Fehlerquelle dar: Wireless-Controller, Firewalls, VPN-Gateways und RADIUS-Plattformen können jeweils eigene Kopien mit separaten Erneuerungsverfahren und Zuständigkeiten besitzen.
Vor der Zuweisung normalisieren
Discovery-Tools liefern inkompatible Formate. Konvertieren Sie deren Ergebnisse in einen Datensatz pro Zertifikat und führen Sie anschließend eine Deduplizierung anhand von Seriennummer, Fingerabdruck und gegebenenfalls Public-Key-Identität durch. Behalten Sie genügend Kontext bei, um eine ungenutzte Datei von einer aktiven Produktionsabhängigkeit zu unterscheiden. Erfassen Sie auch den Anbieter und die Discovery-Methode, damit ein fehlendes Ergebnis auf ein Quellsystem zurückgeführt werden kann, anstatt fälschlicherweise als Nichtvorhandensein interpretiert zu werden.
| Feld | Beispielwert | Zweck |
|---|---|---|
| Betreff | Dienst- oder Geräteidentität | Identifiziert den Zertifikatsbetreff |
| Aussteller | Name der Zwischen-CA | Zeigt, welche Stelle es signiert hat |
| SANs | DNS-, E-Mail-, URI- oder Geräte-Identifikatoren | Erfasst die Identitäten, die Clients validieren |
| Schlüsselverwendung | Serverauthentifizierung oder Clientauthentifizierung | Verhindert die Nutzung in der falschen Rolle |
| Ablaufdatum | Gültigkeitsenddatum | Steuert die Erneuerungsplanung |
| Seriennummer | Von der CA ausgestellter Identifikator | Unterstützt Audit und Widerruf |
| Speicherort | Serverspeicher, Appliance, Verzeichnisprofil oder Vault | Zeigt, wo der Austausch stattfinden muss |
| Eigentümer und Kontakt | Benanntes Team und Eskalationskontakt | Ermöglicht das Ergreifen von Maßnahmen |
| Abhängigkeitskette | Zwischen- und Root-Beziehungen | Offenbart gemeinsame Fehlerquellen |
| Status | Aktiv, bereitgestellt, abgelaufen, widerrufen oder ungenutzt | Trennt Risiken von historischem Ballast |
Die Zuweisung von Verantwortlichkeiten entscheidet darüber, ob ein Inventar Maßnahmen auslösen kann. "Netzwerk" oder "IT" gibt nicht an, wer eine Änderung genehmigt, die Bereitstellung durchführt oder auf Ausfälle reagiert. Weisen Sie einen Service-Eigentümer, ein Betriebsteam, einen Eskalationskontakt und eine geschäftliche Kritikalität zu. Wenn ein RADIUS-Zertifikat das Mitarbeiter-WiFi unterstützt, erfassen Sie den Netzwerkdienst, den Backup-Betreiber, den Plattform-Eigentümer und den Autor des Änderungsprozesses, der die Bereitstellung autorisiert.
Ketten zuordnen und Risiken klassifizieren
Ein Leaf-Zertifikat kann fehlschlagen, weil seine Gültigkeit abgelaufen ist, der Server ein Intermediate-Zertifikat ausgelassen hat oder ein Client der Root-CA nicht mehr vertraut. Ordnen Sie jedes Leaf-Zertifikat seinem Intermediate-Zertifikat und jedes Intermediate-Zertifikat seiner Root-CA zu. Markieren Sie anschließend gemeinsame Abhängigkeiten. Eine einzige Intermediate-CA kann unabhängige Dienste unterstützen, was deren Austausch in eine koordinierte Änderung über Verzeichnisdienste, Server und Netzwerkanbieter hinweg verwandelt.
Verwenden Sie Klassifizierungen, die die betrieblichen Konsequenzen widerspiegeln:
- Produktionskritisch: WiFi Authentifizierung, VPN-Zugriff, Identitäts-Gateways, Zahlungsdienste und Systeme mit direkten Auswirkungen auf die Benutzer.
- Anwendungsorientiert: Öffentliches Web-TLS, APIs, Reverse-Proxies, Ingress-Controller und Kundenportale.
- Intern: Service-to-Service mTLS, Maschinenidentitäten, administrative Schnittstellen und Entwicklungsumgebungen.
Schatten-Zertifikate erfordern einen separaten Abgleich. Fragen Sie Anwendungsteams, Managed Service Provider und Netzwerkanbieter, wo private Schlüssel gespeichert sind, welcher Anbieter jedes Zertifikat ausgestellt hat und wie die Verlängerung durchgeführt wird. Vergleichen Sie diese Antworten mit Verzeichnisdienst-Einträgen, Appliance-Exporten und Scan-Ergebnissen.
Ein vollständiges Inventar ist ein kontinuierlich gepflegtes Kontrollregister und keine einmalige Liste. Es verknüpft Zertifikate mit Systemen, Personen, Anbietern, Abhängigkeiten und Bereitstellungsnachweisen. So erhält die Lifecycle-Automatisierung eine zuverlässige Datenquelle, anstatt zuzulassen, dass jedes Tool nur die Zertifikate verwaltet, die es selbst sehen kann.
Ausstellen und Bereitstellen von Zertifikaten mit Verzeichnisdiensten
Ein Gerät kann als verwaltet angezeigt werden, obwohl der zertifikatsbasierte Zugriff dennoch fehlschlägt. In der Praxis liegt das Problem meist an der Schnittstelle zwischen Identität, Schlüsselgenerierung, Vertrauensinstallation und Service-Bereitstellung. Betrachten Sie die Ausstellung als einen kontrollierten Workflow: Generieren Sie das Schlüsselpaar, erstellen Sie den CSR, validieren Sie Identität und Richtlinie, signieren Sie über die genehmigte CA und installieren Sie dann das Zertifikat samt Kette. Behalten Sie die Generierung des privaten Schlüssels nach Möglichkeit auf oder nahe am Endpunkt. Der CSR beweist den Besitz dieses Schlüssels, daher sollte der Schlüssel nicht über E-Mail, Ticketsysteme oder freigegebene Administratorordner übertragen werden.
Microsoft Entra ID Bereitstellungen nutzen häufig Intune-Zertifikatsprofile mit SCEP oder PKCS12. SCEP eignet sich für verwaltete Geräte, die ihre eigenen Schlüssel generieren und Zertifikate über einen kontrollierten Connector anfordern. PKCS12 kann ein Zertifikat und einen privaten Schlüssel verpacken, wenn das Bereitstellungsmodell dies erfordert, aber der Transport oder die Speicherung dieses Pakets erfordert strengere Kontrollen. Verknüpfen Sie jedes Profil mit der Geräte- oder Benutzeridentität, definieren Sie die Schlüsselverwendung und erfassen Sie die ausstellende CA und die Vertrauenskette im zentralen Inventar. Dieser Datensatz verhindert, dass die Zertifikatsansicht eines einzelnen Anbieters zur einzigen Quelle der Wahrheit wird.
Google Workspace-Umgebungen erfordern dieselbe Trennung zwischen Identität und Zertifikatsmaterial. Nutzen Sie das Google Endpoint Management für Richtlinien verwalteter Geräte und verwenden Sie anschließend die Directory API sowie den Kontext der Organisationseinheit, um jedes Zertifikat mit seinem Gerät oder Benutzer und der dafür geltenden Richtlinie zu verknüpfen. Eine exportierte Zertifikatsdatei beweist keine erfolgreiche Bereitstellung. Bestätigen Sie, dass der Endpunkt das Profil erhalten, das vertrauenswürdige Root-Zertifikat installiert hat und das Client-Zertifikat gegenüber dem vertrauenden Dienst vorweisen kann.
Okta kann zu zertifikatsbasierten Entscheidungen zur Vertrauenswürdigkeit von Geräten beitragen, aber das Vorhandensein eines Zertifikats allein schließt die Authentifizierung nicht ab. Kombinieren Sie die Zertifikatsvalidierung und den Gerätestatus mit den geltenden Anmelde- und Multi-Faktor-Richtlinien. Wenn ein Gerät den verwalteten Bestand verlässt, verknüpfen Sie das Verzeichnisereignis mit der Deaktivierung oder dem Widerruf des Zertifikats. Eine manuelle Erkennung hinterlässt verwaiste Anmeldeinformationen und führt zu Lücken zwischen Verzeichniseinträgen, CA-Konsolen und Netzwerkgeräten.
Wahl der CA nach Anwendungsfall
Verwenden Sie eine öffentliche CA für öffentlich zugängliche Namen und Dienste, die ein breites Vertrauen der Clients erfordern. Verwenden Sie eine private CA für interne Geräteidentitäten, mTLS und kontrolliertes Unternehmensvertrauen. Ein hybrides Modell trennt öffentliche Webzertifikate von internen Identitätszertifikaten, während jede PKI den entsprechenden Ausstellungs- und Widerrufskontrollen folgt. Dokumentieren Sie die Eigentümerschaft und die Bereitstellungsschnittstellen für jeden Anbieter, damit die Erneuerungsautomatisierung Server, Verzeichnisdienste und Netzwerkanbieter erreichen kann.
Die Schlüsselspeicherung beeinflusst auch die Wiederherstellung und die Reaktion auf Vorfälle. Hardware-gestützte Schlüssel in TPMs erschweren das Auslesen und eignen sich für verwaltete Laptops und zweckgebundene Geräte, bei denen die Plattform eine stabile Hardware-Identität bietet. Software-Schlüsselspeicher sind über verschiedene Hardware- und Wiederherstellungs-Workflows hinweg einfacher zu handhaben, erfordern jedoch einen stärkeren Endpunktschutz und strengere Zugriffskontrollen.
WiFi bringt einen praktischen Kompromiss mit sich. Ein Gerätezertifikat muss die routinemäßige Wartung des Betriebssystems überstehen, ohne den Zugriff zu unterbrechen, während das Unternehmen dennoch eine Möglichkeit benötigt, es nach einer Kompromittierung oder einem Eigentümerwechsel zu ersetzen. Testen Sie die Erneuerung auf Windows, macOS, iOS und Android, einschließlich des Verhaltens des Supplicants nach einer Profilaktualisierung. Teams, die den Aufwand für die lokale RADIUS-Verwaltung reduzieren möchten, können neben einer selbstverwalteten Bereitstellung auch RADIUS-as-a-Service für zertifikatsbasiertes WiFi evaluieren.
Verwaltung von Rotation, Erneuerung und Widerruf
Um 2 Uhr nachts kann ein Zertifikat bei der CA erfolgreich erneuert werden und ein Dienst dennoch offline bleiben. Das Gerät lehnt möglicherweise die Kette ab, der private Schlüssel passt nicht, oder die Anwendung erfordert einen manuellen Neustart. Rotation, Erneuerung und Widerruf gehören daher zu einem einzigen betrieblichen Workflow, nicht zu drei separaten Tickets. Die Erneuerung ersetzt ein ablaufendes Zertifikat. Die Rotation sollte in der Regel einen neuen Schlüssel generieren, da die Beibehaltung des alten privaten Schlüssels dessen Sicherheitsrisiko verlängert. Der Widerruf betrifft Kompromittierungen, Stilllegungen oder Richtlinienentscheidungen, die ein Zertifikat vor dem Ablauf ungültig machen.
Legen Sie das Verlängerungsfenster so frühzeitig fest, dass Bereitstellungsfehler vor dem Ablauf diagnostiziert werden können. Verfolgen Sie die CA-Genehmigung getrennt von der Installation und dem Status des Dienst-Reloads. An diesem Unterschied wird die Zertifikatswucherung sichtbar: Verschiedene Anbieter, Verzeichnisdienste, Appliances und Anwendungsbesitzer melden oft unterschiedliche Teile desselben Lebenszyklus.
Erneuerung als Bereitstellungs-Workflow konzipieren
Ein zuverlässiger Workflow sollte:
- Erneuerungsfenster erkennen: Bewerten Sie Gültigkeit, Dienstkritikalität, Anbieter und Bereitstellungskomplexität.
- CSR und Schlüssel neu generieren: Erstellen Sie einen neuen privaten Schlüssel und befolgen Sie die UK DWP PKI-Lebenszyklusanforderungen.
- Genehmigungsschritt anwenden: Erfordern Sie die Bestätigung des Diensteigentümers für Systeme mit hoher Priorität, während richtlinienkonforme Verlängerungen mit geringem Risiko automatisch fortgesetzt werden können.
- Austausch vorbereiten: Installieren Sie das Zertifikat und die vollständige Kette auf einem sekundären Endpunkt, Knoten, Listener oder Testprofil.
- Vor dem Wechsel validieren: Überprüfen Sie Name, Schlüsselverwendung, Kettenaufbau, Client-Vertrauen und Anwendungsverhalten.
- Kontrollierten Wechsel durchführen: Leiten Sie den Datenverkehr oder die Authentifizierung auf den erneuerten Endpunkt um, ohne den Dienst offline zu nehmen.
- Nachweise aufzeichnen: Aktualisieren Sie das gemeinsame Inventar mit Seriennummer, Fingerabdruck, Anbieter, Speicherort, Eigentümer, Genehmigung und Bereitstellungsergebnis.
Ersetzen Sie bei Hochverfügbarkeitsdiensten einen Knoten nach dem anderen. Validieren Sie das reale Client-Verhalten, bevor Sie mit den restlichen Knoten fortfahren. Behalten Sie das vorherige Zertifikat für ein Rollback nur dort, wo die Richtlinie es zulässt, und entfernen Sie nach der Umstellung veraltete private Schlüssel. Das Inventar sollte auch erfassen, ob der jeweilige Anbieter eine automatisierte Installation und einen Reload unterstützt, da eine Verlängerung durch die Zertifizierungsstelle allein den Wechsel nicht abschließt.
Widerruf sichtbar machen
Der Widerruf funktioniert nur, wenn vertrauende Clients den Status abrufen und erzwingen können. Hosten Sie Widerrufsinformationen zentral mit hoher Verfügbarkeit und verwalten Sie dann die CRL-Verteilung, OCSP-Responder oder beides entsprechend der Umgebung. Testen Sie auch das Ausfallverhalten. Ältere Clients arbeiten möglicherweise weiter, wenn Statusdienste nicht verfügbar sind, was Incident-Respondern ein falsches Gefühl der Kontrolle vermittelt.
Behandeln Sie verwaiste Zertifikate als Untersuchung und nicht als reine Bereinigungsaufgabe. Bestätigen Sie, dass kein Dienst, kein Gerät, kein Backup-Prozess, kein Verzeichnis-Workflow und keine Anbieterintegration mehr vom Zertifikat abhängt, bevor Sie es als stillgelegt markieren. Das Entfernen eines widerrufenen Zertifikats von einem Endpunkt löst den Vorfall nicht, wenn ein anderes System ihm weiterhin vertraut oder ein alternatives Zertifikat mit derselben Identität aktiv bleibt.
Das britische Zertifizierungsmodell für digitale Identitäten verknüpft das Zertifikatsmanagement zudem mit dem Rhythmus von Nachweisen und Überprüfungen. Dienste im UK Digital Identity and Attributes Trust Framework erfordern eine Zertifizierung durch eine zugelassene Konformitätsbewertungsstelle. Zertifikate sind in der Regel für drei Jahre gültig, wobei alle 12 Monate eine Überwachung erwartet wird - typischerweise innerhalb von 30 Tagen vor oder nach dem Jahrestag der Zertifizierung. Die Anforderungen des britischen Zertifizierungsprogramms legen fest, dass Dienste vor dem Ablauf des Zertifikats neu zertifiziert werden müssen. Die Zertifizierung gilt für den bewerteten Dienst und nicht automatisch für die gesamte Organisation.
Bereitstellung von zertifikatsbasiertem WiFi-Zugang in echten Veranstaltungsorten
Zertifikatsbasiertes WiFi funktioniert an Veranstaltungsorten gut, wenn die Identität, die Vertrauenskette und die Supplicant-Konfiguration aufeinander abgestimmt sind. EAP-TLS beseitigt das Problem gemeinsam genutzter Passwörter, ersetzt aber ein einzelnes Geheimnis durch einen Lebenszyklus, der Client-Zertifikate bereitstellen, die korrekte Root-CA installieren, das WLAN-Profil konfigurieren und den Zugriff widerrufen muss, wenn sich die Verzeichnisidentität oder die Gerätebeziehung ändert.
Auf einem Unternehmenscampus ist das sauberste Muster in der Regel eine Mitarbeiter-SSID, die EAP-TLS mit verzeichnisgestützten Gerätezertifikaten nutzt, und eine separate SSID für Gäste. Passpoint kann es verwalteten Geräten ermöglichen, das entsprechende Netzwerk zu finden und ihm beizutreten, ohne wiederholt Anmeldeinformationen eingeben zu müssen. Für ältere Geräte, die den erforderlichen Zertifikatsablauf nicht abschließen können, kann ein iPSK Segment gerätespezifische Schlüssel bereitstellen, während das Hauptnetzwerk für Mitarbeiter strengere Identitätskontrollen beibehält.
Ein Krankenhaus hat einen schwierigeren Mix. Verwaltete klinische Arbeitsstationen unterstützen möglicherweise EAP-TLS, während Spezialgeräte, Scanner, Pumpen und von Anbietern gewartete Geräte möglicherweise nur eingeschränkte Supplicant-Funktionen haben. Verschieben Sie diese Geräte in eng definierte Netzwerksegmente, dokumentieren Sie ihr Vertrauensmodell und definieren Sie eine kompensierende Kontrolle, anstatt die SSID für die Mitarbeiter für jeden Client zu schwächen.
In einer Einzelhandelskette müssen zentrale Richtlinien mit lokalen Switching- und Wireless-Varianten koexistieren. Meraki, Aruba, Ruckus und andere Anbieter bieten unterschiedliche Zertifikats-, RADIUS-, Passpoint- und Onboarding-Steuerungen. Halten Sie die Zertifikatsrichtlinie herstellerneutral und testen Sie das genaue Profil auf jeder Hardware-Familie. Aruba-kompatible WiFi Hardware-Optionen können im Rahmen dieses herstellerübergreifenden Designs bewertet werden.
| Hersteller | EAP-Methode | RADIUS-Integration | Passpoint-Unterstützung | Onboarding-Komplexität |
|---|---|---|---|---|
| Cisco Meraki | EAP-TLS, abhängig von der Plattformkonfiguration | Cloud-verwaltetes Wireless mit externen RADIUS-Optionen | Verfügbar über unterstützte Wireless-Funktionen | Moderat |
| Aruba | EAP-TLS und andere Enterprise-EAP-Methoden | Controller- oder Cloud-verwaltete RADIUS-Integration | Verfügbar über unterstützte WLAN-Funktionen | Moderat |
| Ruckus | EAP-TLS und herstellerunterstützte Enterprise-Methoden | RADIUS-Integration über WLAN-Verwaltung | Verfügbar über unterstützte Bereitstellungen | Moderat |
| Gemischte Infrastruktur | Standardisierung auf EAP-TLS, sofern Clients dies unterstützen | Richtlinien zentralisieren, Attribute der einzelnen Hersteller testen | Roaming- und Profilverhalten pro Plattform validieren | Hoch |
Testen Sie die Fehler, nicht nur die Anmeldung
Eine erfolgreiche Erstverbindung beweist sehr wenig. Testen Sie ein Zertifikat mit dem falschen SAN, einem fehlenden Intermediate-Zertifikat, einem abgelaufenen Root-Zertifikat im Vertrauensspeicher des Geräts, einem gesperrten Client-Zertifikat, einem RADIUS-Timeout und einem Gerät, das nach einem Betriebssystem-Update zurückkehrt. Bestätigen Sie, dass der Benutzer einen nützlichen Wiederherstellungspfad sieht und nicht in einer Endlos-Authentifizierungsschleife landet.
Richten Sie eine Ausweichlösung für Geräte ein, die kein EAP-TLS unterstützen, aber isolieren Sie diese nach Rolle und setzen Sie einen Austauschplan durch. Der häufigste Fehler in der Praxis besteht darin, das Ausnahmenetzwerk zum Standardnetzwerk werden zu lassen, weil das Onboarding übereilt durchgeführt wurde.
Automatisierung von Überwachung und Multi-Provider-Governance
Ein zentrales Dashboard sollte für jedes Zertifikat vier Fragen beantworten: Was ist es, wo wird es verwendet, wer ist der Eigentümer und was passiert als Nächstes. Es sollte den Status von öffentlichen CAs, privaten PKIs, Cloud-nativen Diensten wie AWS ACM, Google Certificate Manager und Azure Key Vault sowie von Verzeichnisplattformen, Netzwerk-Controllern, Load Balancern und Application Stores erfassen.
Monitoring erfordert mehr als nur ein Ablaufdatum. Überprüfen Sie die Vollständigkeit der Kette, die Übereinstimmung von Schlüssel und Zertifikat, die SAN-Abdeckung, die Schlüsselverwendung, die Erreichbarkeit von Sperrlisten, die Konsistenz der Bereitstellung und ob das auf dem Endgerät beobachtete Zertifikat mit dem im Inventar erfassten Zertifikat übereinstimmt. Alarmieren Sie die Verantwortlichen über das System, das sie bereits nutzen, und eskalieren Sie erst, wenn der Verantwortliche nicht reagiert oder die verbleibende Zeit eine höhere Risikoschwelle überschreitet.
Die betrieblichen Argumente für eine Automatisierung sind bei den britischen Zertifizierungs-Workloads stark ausgeprägt. Die Evaluierungsdaten zu Cyber Essentials verzeichneten 132.094 verliehene Zertifikate seit Beginn des Programms, 27.027 eindeutige zertifizierte Organisationen im Vereinigten Königreich in den vorangegangenen 12 Monaten und insgesamt 35.434 Zertifizierungen in diesem Zeitraum. Im Jahr 2022 verzeichnete das Programm laut der Evaluierung des britischen Cyber Essentials-Programms 24.300 Zertifizierungen, darunter 16.554 Rezertifizierungen und 7.746 Erstzertifizierungen. Der Arbeitsaufwand ist stark von Verlängerungen geprägt, weshalb Kalender, die Erfassung von Nachweisen, Aufgaben für Auditoren und Erinnerungen eher auf die Rezertifizierung als auf die einmalige Ausstellung ausgelegt sein sollten.
Anbieter steuern, ohne ein neues Silo zu schaffen
Die Konsolidierung auf eine einzige Zertifizierungsstelle kann Richtlinien, Verträge, Vorlagen und den Support vereinfachen. Sie kann jedoch auch ein Klumpenrisiko darstellen und Migrationen teuer machen. Ein Multi-Provider-Modell erhöht die Ausfallsicherheit und eignet sich möglicherweise besser für verschiedene Anwendungsfälle, jedoch nur, wenn das Unternehmen Inventarfelder, Eigentumsregeln, Freigabeprozesse, Richtlinien zur Schlüsselgenerierung und das Berichtswesen standardisiert.
Ein praktischer Reifegradpfad sieht wie folgt aus:
- Reaktiv: Teams finden abgelaufene Zertifikate erst nach einem Vorfall.
- Erfasst: Ein gemeinsames Inventar existiert, aber Erkennung und Aktualisierungen erfolgen weiterhin manuell.
- Überwacht: Endpunkt-Scans und Anbieter-Integrationen erkennen Änderungen und senden besitzerbasierte Warnungen.
- Orchestriert: Eine genehmigte Automatisierung generiert Schlüssel, fordert Zertifikate an, stellt Ersatz bereit, validiert Dienste und aktualisiert Datensätze.
- Gesteuert: Policy-as-Code, Audit-Nachweise, Anbieter-Redundanz, Ausnahmebehandlung und Lebenszyklus-Analysen werden im gesamten Bestand angewendet.
Automatisieren Sie nicht jede Verlängerung am ersten Tag. Beginnen Sie mit der Erkennung und der Eigentümerschaft, automatisieren Sie Zertifikate mit geringem Risiko und behalten Sie Freigabeprozesse für die Authentifizierungsinfrastruktur und gemeinsam genutzte Zwischenzertifikate bei. Für Teams, die drahtlose Endpunkte verwalten, kann ein WiFi SSL-Zertifikatsprüfer die gezielte Validierung unterstützen, sollte jedoch das maßgebliche Inventar ergänzen und nicht ersetzen.
Purple bietet identitätsbasierte WiFi Authentifizierung, Mitarbeiterzugang auf Zertifikatsebene, Verzeichnisintegrationen, Passpoint und iPSK Unterstützung in gemischten Netzwerkumgebungen. So helfen wir Teams, die Bereitstellung und den Widerruf von Zertifikaten mit dem tatsächlichen Standortbetrieb zu verknüpfen. Prüfen Sie, wie sich Purple in Ihren WiFi Zertifikatslebenszyklus einfügt, und besuchen Sie Purple, um eine Implementierung basierend auf Ihren Verzeichnisdiensten, Netzwerkanbietern und Onboarding-Anforderungen zu besprechen.
