Fünf häufige "DIY PKI"-Fehler, die es zu vermeiden gilt

In the 12+ years that CSS has been helping organizations deploy Public Key Infrastructures, we frequently run into situations where PKI components are already present in the environment. Often it’s an older PKI that someone new to the organization has inherited and wants help evaluating; sometimes it’s a “temporary” deployment that an organization is looking to improve upon. In others, it may simply be a PKI design that a customer wants us to review and provide feedback before deployment. In any case, these “Do-It-Yourself” installations, like any PKI, can create problems, headaches, and occasionally even more serious issues if mistakes are made during the design, deployment, or operation of the PKI. And while it’s often quite easy to deploy PKI components, PKI does tend to be one of those technologies where you have exactly one chance to get it right: at install time. After that, many parameters are more or less set in stone, and a re-deployment becomes the only way to fix a mistake.

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

With many IT systems, a picture truly is worth a thousand words, and a diagram of the architecture’s “boxes and lines” makes up a majority of the design. This is the case for network diagrams, web/database application architectures, directory structures, and many other IT components. Following this mindset, many first-time PKI architects focus almost exclusively on the hierarchy of CAs: the makeup of Offline Root(s), Policy/Intermediate CAs, and Online Issuing CAs that will comprise the PKI.

However, while the CA hierarchy of a PKI is important to the design, it’s not the whole story. In fact, it’s usually not even the majority of the story, when it comes to scalability, availability, usability, or longevity. The “boxes and lines” get all the attention, but there are SO many other design decisions that are of equal or greater importance. Policies, security controls, CRL and revocation planning, algorithms and key sizes, and validity periods are some examples of areas that can have a more significant, lasting impact on PKI usefulness than the hierarchy of CAs.

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.

PKI enjoys a well-defined structure for policy and practices definition, in the form of Certificate Policy (CP) and Certification Practices Statements (CPS). These are excellent frameworks for defining the requirements governing a PKI, and the means by which an implementation would meet those requirements. Creating these documents can be a daunting task. However, it’s important to note that simply copying someone else’s set of CP/CPS documents verbatim will not suffice; these tools only have value if they truly represent your organization’s PKI requirements and operational processes.

Fehlende Planung des Lebenszyklus von Zertifikaten

Developing an issuance process – which is also secure — can take a significant amount of planning. And if the PKI is being used for embedded systems or network-enabled products or devices (the so-called “Internet of Things”), developing a secured, high-volume issuance process is also critical.

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.

This concern isn’t exclusively tied to certificate expiration, either. Depending on the application involved, planning for other certificate lifecycle events such as revocation or key archival and recovery processes can be even more important than certificate renewal planning.

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.

Despite this distinction, there is often still more focus on CA availability than CRL or OCSP availability, which are always at least as important. If your CRLs or OCSP servers are not available, all of your certificates can become unusable. Creating additional issuing CAs “for backup” sometimes solves a problem that doesn’t need to be solved, while placing a bigger burden on CRL and OCSP availability.

Die "Schablonen des Verderbens"

Die meisten Informationen in diesem Blog gelten für so gut wie jede PKI, unabhängig von der verwendeten software .
Der letzte Punkt bezieht sich jedoch direkt auf Microsoft-basierte CAs. Die meisten unserer Kunden verwenden Microsoft-CAs als PKI-Baustein, zum einen wegen der Funktionen und Möglichkeiten der software, 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.