Die meisten PKI-Programme beginnen nicht mit einem Auftrag. Sie beginnen mit einem Team, das sofort Zertifikate benötigt, und richten daher mithilfe einer „ open-source “-Plattform eine Zertifizierungsstelle (CA) ein – das System, das digitale Zertifikate ausstellt und verwaltet. Dies ist ein bewährter, schneller Weg, um den ersten Schritt zu machen und praktische Erfahrungen zu sammeln. Für viele Organisationen ist das genau die richtige Entscheidung.
Das Problem tritt erst später zutage, und es geht dabei selten darum, ob die Zertifizierungsstelle ( software ) funktioniert. Es geht vielmehr darum, welche Anforderungen an eine einzelne, selbstverwaltete Instanz überhaupt jemals gestellt wurden. Eine Zertifizierungsstelle, die interne Tests und eine frühe Einführung ohne Beanstandungen bewältigt hat, kann still und leise zu einem Single Point of Failure werden, sobald Produktionssysteme, kundenorientierte Dienste oder eine Konformitätsbescheinigung davon abhängig werden. Die Zertifizierungsstelle ( software ) hat sich nicht verändert. Was das Unternehmen von ihr erwartet, hat sich jedoch geändert.
Vom Proof-of-Concept bis zur Serienreife
Die Frage, die sich jede wachsende PKI-Umgebung irgendwann stellen muss, lautet nicht: „Funktioniert die software ?“ Sondern: „Entspricht die Art und Weise, wie wir sie betreiben, den aktuellen Erwartungen des Unternehmens?“ Ausfallsicherheit, Nachvollziehbarkeit und Kontinuität sind keine Funktionen, die man nachträglich hinzufügen kann; sie sind Eigenschaften der Architektur und des Betriebs eines Systems und nicht nur das, was es in einer Demo leisten kann.
Wie sich unternehmensweite Reife tatsächlich äußert
In ausgereiften PKI-Umgebungen wird die Zertifizierungsstelle als zentrale Infrastruktur betrachtet und nicht als Nebenprojekt, das nur ein einziger Ingenieur versteht. Für eine solche Konfiguration gelten in der Regel folgende Punkte:
- Die Architektur ist segmentiert.
Die Zertifizierungsstelle, die Registrierungsstelle (die vor der Ausstellung eines Zertifikats die Identitätsprüfung durchführt) und die Validierungsdienste sind voneinander getrennt, sodass ein Problem bei einem dieser Dienste die anderen nicht lahmlegt. Insbesondere die Validierung bleibt hochverfügbar, oft durch eine redundante Infrastruktur, selbst wenn andere Komponenten beeinträchtigt sind.
- Betriebsabläufe sind kein „Stammeswissen“.
Frühe Implementierungen basieren auf dem Fachwissen von ein oder zwei Personen. Das funktioniert so lange, bis es nicht mehr funktioniert: Jemand verlässt das Unternehmen oder die Umgebung wächst so stark, dass kein Einzelner mehr den Überblick behalten kann. Ausgereifte Teams setzen stattdessen auf standardisierte, wiederholbare Prozesse mit gemeinsamer Verantwortung.
- Compliance muss nachweisbar sein, nicht nur gegeben.
Hardware-gestützte Schlüsselspeicherung, die Integration mit cloudbasierten hardware Sicherheitsmodulen (HSMs) und manipulationssichere Prüfprotokolle dienen nicht nur dazu, gesetzliche Vorgaben zu erfüllen; sie ermöglichen es einem Team, bei einem Audit oder einer Vorfallanalyse auf die Aufforderung „Beweisen Sie es!“ ohne große Mühe zu reagieren.
Was ändert sich, wenn Sie auf eine Lösung der Enterprise-Klasse umsteigen?
Eine PKI-Lösung für Unternehmen wurde entwickelt, um diese Lücke zu schließen, ohne dass ein Team gezwungen ist, maßgeschneiderte Tools notdürftig an eine „ open-source “-Grundlage anzupassen. In der Praxis bedeutet dies: architektonische Unterstützung für Segmentierung und Hochverfügbarkeit, Konfigurationen, die von Haus aus den Compliance-Rahmenwerken entsprechen, sowie einen schnelleren Zugriff auf Updates, sobald sich Standards und Sicherheitslücken weiterentwickeln.
Zudem bietet es etwas, was eine selbstverwaltete, open-source Bereitstellung strukturell nicht leisten kann: ein Support-Modell. Open-source Community-Foren sind zwar eine echte Hilfe, aber sie basieren auf dem Best-Effort-Prinzip, und niemand haftet für Ihren Produktionsausfall. Ein Unternehmens-Support-Modell bedeutet Zugang zu PKI-Fachwissen, das bei Architekturentscheidungen helfen, die Problemlösung beschleunigen und auf Veränderungen in der kryptografischen Landschaft – darunter auch die Migration auf postquantene Lösungen – hinweisen kann, bevor diese zu einem Notfall werden.
Die eigentliche Entscheidung für Sicherheitsverantwortliche
Der Wechsel von einer selbstverwalteten Zertifizierungsstelle ( open-source) zu einer PKI-Plattform der Enterprise-Klasse ist kein einfaches Upgrade im Sinne von „ software “, und eine solche Darstellung wird den tatsächlichen Veränderungen nicht gerecht. Es handelt sich um eine Verlagerung der Risikoverantwortung: von der Kompetenz einer einzelnen Person hin zur Widerstandsfähigkeit der gesamten Organisation, von einer eigenständigen Bereitstellung hin zu einer langfristigen Partnerschaft mit einer festgelegten Support-Verpflichtung.
Um es ganz klar zu sagen: Wenn die Person, die Ihre PKI aufgebaut hat, morgen das Unternehmen verlassen würde, würde diese dann weiterhin genauso funktionieren? Wenn die ehrliche Antwort „Nein“ lautet, handelt es sich nicht um ein Problem der „ software “. Es ist ein Problem des Betriebsmodells, und es lohnt sich, es als solches anzugehen, bevor ein Ausfall oder ein Audit diese Entscheidung für Sie trifft.
Wie geht es nun weiter?
Es gibt keine festgelegte Größen- oder Reifegradschwelle, ab der jedes Unternehmen diesen Schritt gehen sollte; es hängt davon ab, inwieweit das Unternehmen bereits von der zugrunde liegenden PKI abhängig ist. Je früher diese Frage jedoch bewusst gestellt wird, anstatt erst durch einen Vorfall beantwortet zu werden, desto besser ist in der Regel das Ergebnis.
Einen detaillierten Überblick darüber, wie der Betrieb einer PKI auf Unternehmensniveau in der Praxis aussieht, finden Sie im CISO-Brief: „Operationalizing Trust“. Wenn Sie derzeit prüfen, welche Funktionen eine Unternehmens-PKI-Plattform bieten sollte, erfahren Sie hier, wie „Keyfactor “EJBCA Enterprise Edition darauf ausgelegt ist, diese Anforderungen zu erfüllen.
