PKI ist nicht nur ein weiteres software für Ihr Unternehmen. Sie ist eine kritische Infrastruktur. Sie ist die Grundlage für digitales Vertrauen die eine zuverlässige Möglichkeit bietet, den Zugriff zu kontrollieren und Geräte, Arbeitslasten und Menschen in großem Umfang sicher zu verbinden.
Daher erfordert die PKI erhebliche Investitionen und Anstrengungen für Aufbau und Wartung. Und diese Investition wird heute mehr denn je auf die Probe gestellt, da neue Anwendungsfälle, die Ausnutzung von Schwachstellen, das Auslaufen von software und künftige Risiken, die durch die Quantentechnologie zwingen die Unternehmen dazu, ihre Strategien zu überdenken.
Konkret, Microsoft PKI, besser bekannt als Active Directory Certificate Services (ADCS), ist seit ihrer Einführung im Jahr 2000 die De-facto-PKI-Lösung für viele Unternehmen. Das macht Sinn: Sie ist in Windows-Servern integriert, relativ einfach einzurichten und ziemlich gut in das Microsoft-Ökosystem integriert.
Aber wir schreiben jetzt das Jahr 2024, und die Zeiten haben sich geändert. Die IT-Landschaft ist nicht mehr mit der von vor 20 Jahren zu vergleichen; die Zahl der Anwendungsfälle und die schiere Menge an Zertifikaten ist erheblich gestiegen. Diese Situation hat viele Unternehmen zu der Frage veranlasst ob es an der Zeit ist, ihr ADCS zu ersetzen. Was ist also die Antwort? Die Antwort ist nicht eindeutig, aber es gibt wichtige Bereiche, die Sie bei der Bewertung der Anforderungen Ihres Unternehmens berücksichtigen sollten und die Ihnen helfen können, diese Frage ein für alle Mal zu beantworten.
Wie sich die Rolle der PKI seit der Veröffentlichung von ADCS entwickelt hat
Erinnern Sie sich an das Jahr 2000? Telefone klappten, CDs überschlugen sich, und es dauerte 10 Minuten, bis man seinen Computer hochfahren konnte. Wir kamen gerade aus der Dotcom-Ära, der iPod hatte gerade die Musikwelt revolutioniert, und das Einwahl-Internet starb gerade seinen langsamen Tod. Es war auch das Jahr, in dem Microsoft offiziell die Certificate Services, wie sie ursprünglich genannt wurden, einführte.
Zertifikatsdienste stützten sich auf statische Benutzerlisten und NTLM-Authentifizierung. Damals war PKI noch eine sehr teure monolithische Infrastruktur, für deren Installation und Inbetriebnahme Unternehmen viel Geld ausgeben mussten. Als jedoch immer mehr Unternehmen online gingen, stieg der Bedarf an Zertifikaten, was die Voraussetzungen für eine sehr schnelle Entwicklung der Technologie, insbesondere der PKI, schuf.
Im nächsten Jahrzehnt explodierten die Smartphones und damit auch die Verwaltung mobiler Geräte, da Unternehmen Authentifizierungsmethoden benötigten, um sicherzustellen, dass diese Geräte vertrauenswürdig sind und sicher mit dem Netzwerk verbunden werden können. Mit der Markteinführung von AWS, Google App Engine und Microsoft Azure bekamen wir auch einen ersten Vorgeschmack auf Cloud Computing.
Vor diesem Hintergrund hat Microsoft die Zertifikatsdienste sowohl 2003 als auch 2008 in bescheidenem Umfang weiterentwickelt.
Im Jahr 2003 wurden die Zertifikatsdienste in Active Directory integriert und offiziell zu ADCS. Zu diesem Zeitpunkt sah es mehr wie eine PKI aus als in der vorherigen Version und erfüllte den Zweck ziemlich gut für die Anwendungsfälle, die die meisten Unternehmen zu dieser Zeit benötigten. Das waren Anwendungsfälle wie das Hinzufügen eines Zertifikats auf diesem mobilen Gerät oder für dieses Wi-Fi-Netzwerk oder das Ermöglichen einer guten Authentifizierung auf entfernt verwalteten Workstations. Es ist wichtig, sich daran zu erinnern, dass dies vor der Verlagerung von Arbeitslasten in die Cloud geschah. Damals war die Cloud mehr ein Speichermechanismus als alles andere, da dort noch keine sinnvolle Arbeit stattfand.
Im Jahr 2008 wurde ADCS mit der Einführung des NDEs-Servers weiterentwickelt, bei dem es sich eigentlich nur um das Simple Certificate Enrollment Protocol (SCEP) handelt, das es bereits seit 2000 gibt. SCEP wurde ursprünglich für den Erhalt von Zertifikaten auf Cisco-Routern entwickelt, und als es auf eine größere Anzahl von Anwendungsfällen ausgeweitet wurde, wurden die Grenzen der Sicherheit erweitert. Der Zweck dieser Änderung war es, den Anforderungen von Mobiltelefonen gerecht zu werden, und es wurde zum Standard für den Erhalt von Zertifikaten auf Telefonen und Schwachstellen in SCEP begannen aufzutauchen (VU#971035 - Simple Certificate Enrollment Protocol (SCEP) authentifiziert Zertifikatsanforderungen nicht streng)
In den 2010er Jahren kamen Hybrid- und Multi-Cloud-Systeme auf, und DevOps begann sich durchzusetzen. Wir traten in eine Ära der Automatisierung und Containerisierung ein, und das bedeutete, dass plötzlich Zertifikate benötigt wurden, um alle Arten von Geräten und Diensten zu authentifizieren und die Maschine-zu-Maschine-Kommunikation zu schützen.
Schon bald wurde eine Vielzahl von DevOps-Tools rund um dieses Ökosystem entwickelt - darunter der Aufstieg von Hashicorp, Terraform und Vault sowie von Cloud-nativen Zertifikatsausstellern wie AWS Private CA, JetStack Manager und Google CA Service. Durch all dieses Wachstum wurde die Zertifikatslandschaft wesentlich komplexer.
Das war der Zeitpunkt, an dem wir begannen, über die Unternehmensnetzwerke und Rechenzentren hinaus zu expandieren und die Cloud als neue Arbeitsweise zu etablieren. Und dieser Wandel erforderte Authentifizierung. Wir brauchten Verschlüsselung, und so entstanden Protokolle wie EST und ACME, um Cloud-Bereitstellungen zu erleichtern. Dies ist ein Bereich, in dem Microsoft nicht mithalten konnte. Die Website Microsoft CA wurde für diese neuen Anwendungsfälle nur unzureichend entwickelt. Stattdessen sahen wir iterative Server-Ergänzungen und kleinere Funktions-Releases, aber keinen größeren Aufschwung, um mit dem Schritt zu halten, was Teams brauchen, um mit PKI erfolgreich zu sein.
Infolgedessen mussten sich die Sicherheitsteams entweder mit Problemen bei der Verwaltung von Zertifikaten auseinandersetzen, die an verschiedenen Orten aufbewahrt werden, oder sie mussten sich mit manuellen Lösungen zufrieden geben, die im großen Maßstab nicht gut funktionieren. In der Cloud-Ära, in der wir jetzt arbeiten, dreht sich alles um Skalierung. Und obwohl es Zusatzprodukte gibt, die in verschiedene ADCS-Umgebungen integriert werden können, sind die Teams immer noch stark durch die Tatsache eingeschränkt, dass ADCS nie für den Einsatz in Cloud-Umgebungen konzipiert wurde.
Zum Glück gibt es jetzt bessere Optionen. Es sind neue CA-Technologien entstanden, die besser für das Cloud-Zeitalter geeignet sind - Technologien, die nicht nur von Anfang an bewusst für unsere modernen Umgebungen konzipiert wurden, sondern die auch kontinuierlich in diese Richtung weiterentwickelt werden. All dies ist besonders wichtig im Zeitalter der 2020er Jahre, in dem Remote- und Hybrid-Arbeitskräfte und die weit verbreitete Nutzung von IoT Geräten eine Rolle spielen. So gibt es zum Beispiel neue Standards wie Matter, die das Tempo für die Verwendung von PKI vorgeben, um IoT Geräte zu sichern zu sichern und ihnen durch Maßnahmen wie Firmware-Signierung eindeutige Identitäten zu verleihen.
Was Microsoft PKI betrifft, so hat sich in der letzten Version 2022 nicht viel getan. Microsoft hat zwar vor kurzem die bevorstehende Veröffentlichung von Microsoft Cloud PKI angekündigt, aber diese scheint immer noch sehr stark auf den Einsatz vor Ort ausgerichtet zu sein. Allerdings können wir uns kein vollständiges Bild machen, da sie noch nicht veröffentlicht wurde.
Nun stehen weitere Veränderungen bevor: der Übergang zu Post-Quantum-Algorithmen. Es gibt eine Reihe neuer Algorithmen, die bald standardisiert werden sollen, und die Unternehmen prüfen bereits, was das für sie bedeutet, und bereiten sich darauf vor, sie zu übernehmen. Leider gibt es von Seiten des ADCS keine Bestätigung darüber, was sie in welchem Zeitrahmen für diese neuen Algorithmen unterstützen werden.
4 Häufige Szenarien, die die PKI an ihre Grenzen bringen
Bei all diesen Änderungen haben sich gemeinsame Szenarien herauskristallisiert, die die PKI an ihre Grenzen bringen und Unternehmen zwingen, einen Wechsel in Betracht zu ziehen:
1) Verfall der Wurzel oder Ende der Lebensdauer
Der Ablauf der Root-Zertifizierung ist einfach unvermeidlich und kann viele Formen annehmen. Nicht nur Ihre Root-CA läuft ab, auch Ihre ausstellende CA könnte auslaufen, oder Ihre Server oder HSMs hinter Ihrer PKI könnten das Ende ihrer Lebensdauer erreichen. Wie auch immer die Situation aussieht, in den meisten Fällen ist ein kompletter Neuaufbau Ihrer PKI von Grund auf erforderlich.
Für viele Unternehmen sieht dieses Szenario in etwa so aus: Die ausstellende Zertifizierungsstelle beginnt mit der Ausstellung neuer Zertifikate, die nur 13 Monate gültig sind, obwohl sie laut Vorlage zwei Jahre lang gültig sein sollten. Bei näherer Betrachtung stellt sich heraus, dass etwas in der Kette in 13 Monaten abläuft, und eine der Regeln der PKI besagt, dass Sie kein Zertifikat ausstellen dürfen, das länger als die Lebensdauer der Kette gültig ist.
Das führt zu abgeschnittenen Zertifikaten, was in der Organisation Panik auslöst, und es ist sehr störend, wenn man die PKI unter einem bestimmten Zeitdruck neu aufbauen muss. bestimmten Zeitrahmen denn dann passieren oft Fehler.
2) Mitarbeiterabwanderung und Qualifikationsdefizite
PKI ist nicht nur software, sondern eine kritische Infrastruktur mit einer bestimmten Lebensdauer. Oftmals überdauert diese Lebensdauer die Amtszeit des Mitarbeiters, der sie überhaupt erst geschaffen hat. Wenn das passiert, wird die PKI oft wie eine heiße Kartoffel auf den Schoß eines anderen geworfen, und von da an geht es einfach so weiter.
Während in einigen Unternehmen ein eigenes Team für den PKI-Betrieb zuständig ist, handelt es sich in vielen Fällen um einen Teilzeitjob für einen Vollzeitmitarbeiter. Im Allgemeinen sehen wir große Qualifikationslücken im Bereich PKI: Man kann PKI nicht studieren, und es gibt keine wirklich guten Bücher, die sich mit der täglichen Pflege der Infrastruktur befassen. Infolgedessen arbeiten viele Unternehmen mit altem Wissen, um zu wissen, wie ihre PKI betrieben wird. Aber in diesen Fällen, wenn die Mitarbeiter das Unternehmen verlassen und die Dinge nicht richtig dokumentiert sind, kommt es zu Problemen. Und jedes Mal, wenn man etwas tut, untergräbt man die Grundlage der Sicherheit, was die Organisation in eine schlechte Lage bringt. Niemand hat die Absicht, die Sicherheit zu verschlechtern, aber genau das passiert, wenn man immer wieder Pflaster anbringt und neue Anwendungsfälle auf einem unzureichenden Fundament hinzufügt.
3) Wachstumsschwierigkeiten
Der Umfang und die Geschwindigkeit der Ausstellung von Zertifikaten nehmen zu, brauchen die Teams mehr Protokolle, Integrationen und Infrastruktur um dies zu unterstützen. Und in vielen Fällen - insbesondere in letzter Zeit bei Teams, die sich auf ADCS verlassen - kann die PKI diese Anwendungsfälle einfach nicht unterstützen.
Dies hat dazu geführt, dass Unternehmen Punktlösungen je nach Bedarf implementieren, was dazu geführt hat, dass Teams heute im Durchschnitt über neun PKI/CA-Lösungen verfügen. Wenn alles ordnungsgemäß verwaltet wird, kann diese Zahl in Ordnung sein, aber in den meisten Unternehmen gibt es unterschiedliche Ausgabestellen für Zertifikate, die für sehr spezifische Anforderungen eingerichtet wurden. Wenn es keine umfassende Lösung für die gesamte Organisation gibt, sind Wachstumsschmerzen keine Seltenheit, und es ist schwer zu verstehen, woher die Dinge kommen und warum sie bestimmte Maßnahmen ergreifen.
Idealerweise sollten Organisationen zwei Quellen für die Ausstellung von Zertifikaten haben: eine für alle internen Ressourcen und eine für diejenigen, die öffentlich verwurzelt sein müssen, wie SSL/TLS. Wenn Sie diese Infrastruktur so weit wie möglich konsolidieren können, verringern Sie das Risiko, die Kosten und den Wartungsaufwand für Ihre PKI.
4) Risiko (sowohl bekannt als auch unbekannt)
Es braucht nur eine einzige Schwachstelle, um alles zu zerstören. Laut einem jüngsten Bericht der NSA und der CISAgehört der unsichere Einsatz von ADCS zu den zehn häufigsten Fehlkonfigurationen im Bereich der Cybersicherheit.
Leider gibt es viele bekannte Fehlerquellen, die ADCS unsicher machen können. Im Großen und Ganzen ist es sehr einfach, Fehler zu machen, sei es durch andere Ablenkungen oder unschuldige Fehler wie die Einrichtung der automatischen Registrierung für einen bestimmten Zertifikatstyp, durch die versehentlich jeder in der Organisation ein Code Signing-Zertifikat erhält.
Diese Fälle treten nur allzu oft auf und schaffen schwerwiegende Schwachstellen in der Infrastruktur, die Unternehmen dazu zwingen, ihre gesamte Einrichtung zu überdenken.
Ist es an der Zeit, Ihre PKI zu ersetzen?
Ob es an der Zeit ist, die PKI zu ersetzen, muss jedes Unternehmen für sich selbst beantworten, aber im Idealfall können Sie das herausfinden, bevor Sie eine Sollbruchstelle erreichen, die Sie zum Handeln zwingt.
Wenn Sie also sehen, dass Ihr Unternehmen auf eines der oben genannten Szenarien zusteuert - was sehr wahrscheinlich ist, wenn Ihr Unternehmen auf ADCS basiert, das nicht für die Skalierung, die Geschwindigkeit oder die Cloud-basierten Anwendungsfälle, die die heutige Umgebung erfordert, konzipiert wurde - kann die Antwort sehr wohl "ja" lauten.
Sind Sie bereit, die Verantwortung für Ihre PKI zu übernehmen? Markieren Sie Ihren Kalender für die Webinarreihe von Keyfactor, in der die Risiken und Grenzen der heutigen Microsoft-PKI untersucht werden und wie Unternehmen auf moderne Alternativen umsteigen.
