In den mehr als 12 Jahren, in denen CSS Unternehmen bei der Einrichtung von Public Key-Infrastrukturen unterstützt, sind wir häufig auf Situationen gestoßen, in denen PKI-Komponenten bereits in der Umgebung vorhanden sind. Oft handelt es sich um eine ältere PKI, die jemand, der neu im Unternehmen ist, geerbt hat und Hilfe bei der Evaluierung benötigt. In anderen Fällen handelt es sich einfach um einen PKI-Entwurf, den ein Kunde vor der Implementierung von uns überprüfen und uns Feedback geben lassen möchte. In jedem Fall können diese "Do-It-Yourself"-Installationen, wie jede PKI, Probleme, Kopfschmerzen und gelegentlich sogar schwerwiegendere Probleme verursachen, wenn beim Entwurf, der Bereitstellung oder dem Betrieb der PKI Fehler gemacht werden. Und obwohl es oft recht einfach ist, PKI-Komponenten einzusetzen, gehört PKI zu den Technologien, bei denen man genau eine Chance hat, es richtig zu machen: zur Zeit der Installation. Danach sind viele Parameter mehr oder weniger in Stein gemeißelt, und eine erneute Bereitstellung ist die einzige Möglichkeit, einen Fehler zu beheben.
In diesem Sinne ist diese Liste keineswegs allumfassend, aber hier sind fünf der häufigsten Fehler, die wir bei "DIY"-PKI sehen:
Über-Architektur der CA-Hierarchie
Bei vielen IT-Systemen sagt ein Bild mehr als tausend Worte, und ein Diagramm mit den "Kästchen und Linien" der Architektur macht einen Großteil des Entwurfs aus. Dies gilt für Netzwerkdiagramme, Web-/Datenbankanwendungsarchitekturen, Verzeichnisstrukturen und viele andere IT-Komponenten. Aus diesem Grund konzentrieren sich viele PKI-Architekten, die zum ersten Mal eine PKI entwerfen, fast ausschließlich auf die Hierarchie der CAs: die Zusammensetzung der Offline-Root(s), Policy/Intermediate CAs und Online Issuing CAs, aus denen die PKI bestehen wird.
Die CA-Hierarchie einer PKI ist zwar wichtig für das Design, aber nicht das Entscheidende. In der Tat ist sie normalerweise nicht einmal der Mehrheit der Geschichte, wenn es um Skalierbarkeit, Verfügbarkeit, Benutzerfreundlichkeit oder Langlebigkeit geht. Die "Kästchen und Linien" bekommen die ganze Aufmerksamkeit, aber es gibt SO viele andere Designentscheidungen, die genauso wichtig oder noch wichtiger sind. Richtlinien, Sicherheitskontrollen, CRL- und Widerrufsplanung, Algorithmen und Schlüsselgrößen sowie Gültigkeitszeiträume sind einige Beispiele für Bereiche, die einen größeren und dauerhafteren Einfluss auf die Nützlichkeit einer PKI haben können als die Hierarchie der Zertifizierungsstellen.
Eine zu starke Fokussierung auf die PKI-Hierarchie kann dazu führen, dass mehr "Kästchen und Linien" eingefügt werden - was zu Entwürfen führt, die mehr CAs als nötig umfassen. Diese zusätzlichen CAs haben ihren Preis: Server und HSM hardware, Betriebssystemlizenzen sowie die Betriebskosten, die durch die Überwachung weiterer Systeme entstehen.
Alles andere unterarchitektonisch
Manchmal ist es einfach zu einfach, auf "Weiter" zu klicken.
Leider gibt es bei PKI eine große Anzahl von Designaspekten, die, wenn sie einmal konfiguriert sind, nicht ohne eine vollständige Neueinrichtung geändert werden können, und wie bereits erwähnt, können viele dieser Aspekte einen erheblichen Einfluss auf die langfristige Nützlichkeit Ihrer PKI haben. Dazu gehören:
- CA-Zertifikatsnamen, Schlüsselgrößen und Signieralgorithmen: Diese sind Teil des Zertifikats jeder Zertifizierungsstelle und können nicht geändert werden. Und da PKI-Komponenten seit vielen Jahren im Einsatz sind, können die Auswirkungen der getroffenen Entscheidungen sehr groß sein.
- CRL-Verteilungspunkte (CDP): CRL-Standorte werden in die ausgestellten Zertifikate aufgenommen, so dass eine Änderung bedeutet, dass Sie jedes Zertifikat neu ausstellen müssen.
- Operative Richtlinien und angestrebte Sicherheitsstufen: In dem Moment, in dem Sie Ihr erstes Zertifikat ausstellen - ob Sie es nun geplant haben oder nicht -, legen Sie die Ausstellungspolitik für Ihre Zertifizierungsstelle fest. Und sobald Sie die Messlatte auf ein bestimmtes Niveau gesetzt haben, können Sie sie nur noch senken.
Viel zu viele PKIs werden mit weniger als den gewünschten Sicherheitskontrollen implementiert, um Zeit zu sparen oder den Betriebsaufwand zu verringern. Es ist wichtig, ein gutes Gleichgewicht zwischen einfacher Bedienung und einem ausreichend hohen Maß an Sicherheit zu finden.
Die PKI verfügt über eine klar definierte Struktur für die Festlegung von Richtlinien und Praktiken in Form von Zertifikatsrichtlinien (CP) und Erklärungen zu Zertifizierungspraktiken (CPS). Dies sind hervorragende Rahmenwerke für die Festlegung der Anforderungen an eine PKI und der Mittel, mit denen eine Implementierung diese Anforderungen erfüllen würde. Die Erstellung dieser Dokumente kann eine entmutigende Aufgabe sein. Es ist jedoch wichtig zu beachten, dass es nicht ausreicht, die CP/CPS-Dokumente eines anderen Unternehmens wortwörtlich zu kopieren; diese Instrumente haben nur dann einen Wert, wenn sie wirklich die Ihre PKI-Anforderungen und Betriebsprozesse Ihrer Organisation repräsentieren.
Fehlende Planung des Lebenszyklus von Zertifikaten
Die Entwicklung eines - auch sicheren - Ausstellungsverfahrens kann einen erheblichen Planungsaufwand erfordern. Und wenn die PKI für eingebettete Systeme oder netzwerkfähige Produkte oder Geräte (das so genannte "Internet der Dinge") verwendet wird, ist die Entwicklung eines sicheren, hochvolumigen Ausstellungsverfahrens ebenfalls entscheidend.
Ein häufiger Fehler bei der Bereitstellung zertifikatsfähiger Anwendungen besteht jedoch darin, sich nur auf den Rollout und die Aufgaben im Zusammenhang mit der ersten Anwendungsbereitstellung zu konzentrieren. Zertifikate laufen jedoch ab, und wenn die Planung nicht den gesamten Lebenszyklus von Zertifikaten umfasst, kann dies zu erheblichen Problemen führen. Das unerwartete und unkontrollierte Auslaufen von Zertifikaten kann zu erheblichen Ausfällen und Kosten führen.
Diese Sorge ist auch nicht ausschließlich mit dem Ablauf von Zertifikaten verbunden. Je nach Anwendung kann die Planung für andere Ereignisse im Lebenszyklus von Zertifikaten wie Widerruf oder Schlüsselarchivierung und Wiederherstellungsprozesse sogar noch wichtiger sein als die Planung der Zertifikatserneuerung.
Fehlgeleitete Verfügbarkeitsplanung
Verfügbarkeit ist ein Schlüsselbereich für jedes IT-Design, aber in gewisser Weise gibt PKI der Verfügbarkeit eine "Wendung", die manchmal nicht gut verstanden wird. Genauso wie Ihr Führerschein auch dann noch gültig und nutzbar ist, wenn die Zulassungsstelle geschlossen ist, sind digitale Zertifikate auch dann noch gültig und nutzbar, wenn eine Zertifizierungsstelle ausfällt. Das Einzige, was Sie nicht tun können, wenn eine Zertifizierungsstelle ausfällt, ist, neue Zertifikate auszustellen, was für die meisten Unternehmen nicht so wichtig ist, wie sicherzustellen, dass die vorhandenen Zertifikate noch funktionieren.
Trotz dieser Unterscheidung liegt der Schwerpunkt oft mehr auf der Verfügbarkeit von CA als auf der Verfügbarkeit von CRL oder OCSP , die immer mindestens genauso wichtig sind. Wenn Ihre CRLs oder OCSP-Server nicht verfügbar sind, alle können alle Ihre Zertifikate unbrauchbar werden. Die Einrichtung zusätzlicher ausstellender CAs "als Backup" löst manchmal ein Problem, das nicht gelöst werden muss, während die CRL- und OCSP-Verfügbarkeit stärker belastet wird.
Die "Schablonen des Verderbens"
Die meisten Informationen in diesem Blog gelten für so gut wie jede PKI, unabhängig von der verwendeten CA software .
Der letzte Punkt bezieht sich jedoch direkt auf Microsoft-basierte CAs. Wir sehen, dass die meisten unserer Kunden Microsoft-CAs als PKI-Baustein verwenden, zum einen wegen der Funktionen und Möglichkeiten von software und zum anderen, weil sie die Lizenzen bereits besitzen. Es gibt jedoch einige Bereiche, insbesondere in Bezug auf die Standard-Zertifikatsvorlagen, in denen die Benutzer in Schwierigkeiten geraten können.
Eine "nächste, nächste, nächste" Installation von Microsoft CA führt zu einer CA, die bereits für die Ausstellung einer Reihe verschiedener Zertifikate konfiguriert ist; eine solche Vorlage ist "Domain Controller", die von Domain Controllern zur Authentifizierung der Kommunikation untereinander verwendet wird. Interessanterweise sind Domänencontroller insofern etwas Besonderes, als sie so vorprogrammiert sind, dass sie ständig nach CAs in der Umgebung suchen, die Domänencontroller-Zertifikate ausstellen können, und wenn sie eines finden, melden sie sich automatisch an. Dies kann ein Problem sein oder auch nicht, aber es ist oft kein erwartetes Verhalten. Wenn keine Maßnahmen ergriffen werden, um dies zu vermeiden, wird nach der ersten CA-Installation in einer Active Directory-Gesamtstruktur jeder Domänencontroller in der Gesamtstruktur innerhalb von 90 Minuten ein Zertifikat haben.
Eine weitere Standardvorlage, die nachteilige Folgen haben kann, ist die Zertifikatsvorlage "Benutzer". Diese Vorlage hat einen verlockenden Namen und wird oft für die Ausgabe an eine große Anzahl von Unternehmensanwendern eingerichtet. Diese Vorlage kombiniert jedoch eine Reihe von verschiedenen Anwendungsfällen, darunter Authentifizierung, Microsoft EFS und E-Mail-Verschlüsselung. Diese Zertifikate ermöglichen es den Benutzern, Dateien und E-Mails zu verschlüsseln, enthalten jedoch keine Vorkehrungen für die Schlüsselarchivierung, wodurch Ihr Unternehmen dem Risiko des Datenverlusts ausgesetzt ist, wenn die Zertifikate später verloren gehen oder gelöscht werden.
