Was ist dieTLS ? Ein umfassender Leitfaden zum Auffinden aller Zertifikate in Ihrer Umgebung

Diese Bestandsaufnahme war noch nie so wichtig wie heute.Die Gültigkeitsdauer von Zertifikaten verkürzt sichbis zum Jahr 2029 auf etwa anderthalb Monate, die Zahl derMaschinenidentitätensteigt weiter an, und Unternehmen beginnen mit den langwierigen Bemühungen, ihre kryptografische Infrastruktur auf postquantenkryptografische Lösungen umzustellen. Nichts davon ist möglich, wenn Sie nicht zunächst eine scheinbar einfache Frage beantworten können: Welche Zertifikate haben wir eigentlich, und wo befinden sie sich?

Eine kurze Anmerkung zur Terminologie: In diesem Leitfaden wird durchgehendTLSverwendet, da TLS das moderne Protokoll TLS , das die älteren SSL abgelöst hat. Die beiden Protokolle unterscheiden sich zwar technisch voneinander, doch in der Branche werdenSSLundTLSnach wie vor mehr oder weniger synonym verwendet, sodass die Begriffe in den meisten Tools und Dokumentationen als Synonyme behandelt werden.

Warum die Erkennung TLS wichtig ist

Die meisten Unternehmen haben kein Problem mit der Transparenz, weil sie nachlässig sind. Das Problem entsteht vielmehr dadurch, dass sich Zertifikate still und leise in alle Richtungen ansammeln – schneller, als es mit manuellen Verfahren nachverfolgt werden kann. Zertifikate werden von mehr als einer Zertifizierungsstelle ausgestellt, sowohl in Cloud- als auch in lokalen Umgebungen eingesetzt und von verschiedenen Teams angefordert, die jeweils ihr eigenes unmittelbares Problem lösen wollen. Infolgedessen gibt es keine zentrale Informationsquelle, und niemand kann mit Sicherheit sagen, wie viele Zertifikate es gibt oder wann das nächste abläuft.

Dies ist die Herausforderung, die Fachleute im Bereich der Zertifikatsverwaltung als mangelnde Transparenz bezeichnen. Mit steigender Anzahl an Zertifikaten wächst auch die Unsicherheit. Sie wissen nicht, wie viele Zertifikate Sie verwalten, und Sie wissen nicht, wie viele kurz vor dem Ablauf stehen. „Discovery“ ist die Lösung für diese konkrete Lücke: Die Lösung automatisiert die unternehmensweite Suche und erstellt eine genaue Bestandsaufnahme der Zertifikate, sodass Sie kostspielige und potenziell schädliche Ausfälle vermeiden können, die durch den Verlust des Überblicks entstehen.

Einige Faktoren machen die Sichtlücken heutzutage besonders gefährlich:

• Schattenzertifikate.
  Wenn eine Geschäftseinheit ein Zertifikat außerhalb der üblichen Kontrollmechanismen bezieht, wird dies von der Sicherheitsabteilung nie bemerkt. Genau diese blinden Flecken sind die Zertifikate, bei denen die Wahrscheinlichkeit am größten ist, dass sie unbemerkt ausfallen oder falsch konfiguriert sind.
• Zertifikatswucher.
  Da sich die Lebensdauer verkürzt, muss dasselbe Zertifikatweitaus häufiger erneuert werden, was den Betriebsaufwand vervielfacht und die Gefahr erhöht, dass etwas übersehen wird.
• Explosionder Maschinenidentitäten.
  Service-Meshes und Frameworks zur Identitätsverwaltung von Workloads stellen mittlerweile Zertifikate in Mengen aus, die niemand anfordert und die niemand jemals nutzen wird. Dabei handelt es sich um einen eigenständigen und weitaus größeren Bestand, der in großen Umgebungen automatisch entsteht und wieder verfällt, ohne jemals eine Anforderungsstelle durchlaufen zu haben.
• Von außen auferlegte Migration.
  Die wichtigsten kryptografischen Übergänge sind diejenigen, die man nicht selbst planen kann. Ohne eine vollständige Bestandsaufnahme, die auf der gesamten Vertrauenskette basiert, können Sie nicht einmal feststellen, welche Ihrer aktiven Zertifikate betroffen sind – und genau diese Bestimmung des Umfangs macht den größten Teil der Reaktion aus.Keine Grundlage für Richtlinien oder Planung.Ohne eine vollständige Bestandsaufnahme können Teams keine Richtlinien durchsetzen, keine Erneuerungen planen oder sich auf kryptografische Übergänge wie die Vorbereitung auf postquanten-sichere Systeme vorbereiten. Was man nicht sieht, kann man weder schützen noch migrieren noch bestätigen.

Diese beiden letzten Punkte verbinden die Bestandsaufnahme mit einem längerfristigen Horizont. Die Branche bereitet sich darauf vor, quantenresistente Kryptografie einzusetzen, um Informationen und Infrastruktur vor Angriffen durch große Quantencomputer zu schützen. Der erste Schritt bei jeder Migration dieser Art besteht darin, zu wissen, über welche Zertifikate man verfügt und auf welche Kryptografie diese basieren. Die Bestandsaufnahme bildet die Grundlage für alle Bemühungen um kryptografische Agilität.

Da Zertifikate auf dem X.509-Zertifikatsstandard basieren, erfasst ein gutes Bestandsverzeichnis die darin definierten strukturierten Details, wodurch die Aufzeichnungen sowohl für den Betrieb als auch für Audits von Nutzen sind.

So funktioniert die Erkennung von TLS

Die Erfassung ist keine einzelne Technik. Ausgereifte Programme kombinieren mehrere Methoden, da jede einzelne einen anderen Ausschnitt der Umgebung erfasst und kein einzelner Ansatz allein alles erfassen kann. Die drei Hauptansätze sind netzwerkbasiertes Scannen, CA-basierte Erfassung sowie agentenbasierte oder Cloud-basierte Erfassung.

Netzwerkbasiertes Scannen

Das Netzwerkscannen ist die bekannteste Methode. Ein Erkennungstool durchsucht die von Ihnen definierten Netzwerke, stellt eine Verbindung zu TLS her und extrahiert die dort gefundenen Zertifikatsdaten. In der Praxis definieren Sie den Umfang eines Netzwerks auf eine von drei Arten: anhand der Netzwerknotation (CIDR), anhand einzelner IP-Adressen oder anhand einzelner Hostnamen. Jedes definierte Netzwerk wird zu einem eigenen Erkennungsauftrag, wodurch Administratoren große Umgebungen segmentieren und die Leistung optimieren können, anstatt alles auf einmal zu scannen.

Verschiedene Kontrollmechanismen sorgen dafür, dass das Scannen effizient und sicher bleibt:

• Orchestrator-Pools.
  Scan-Aufgaben können je nach Standort an Orchestrator-Pools zugewiesen werden, sodass der richtige Scanner den richtigen Teil des Netzwerks erreicht.
• Portbereiche.
  Sie legen fest, welche Ports überprüft werden sollen, und konzentrieren den Scan so auf die Stellen, an denen TLS tatsächlich auf Verbindungen warten.
• Zeitpläne.
  Discovery-Jobs werden in festgelegten Intervallen ausgeführt und erfassen jeden Endpunkt innerhalb der Netzwerkdefinition.
• Ruhezeiten.
  Sie können Zeitfenster festlegen, in denen keine Scans durchgeführt werden. So vermeiden Sie Scans in sensiblen Zeiträumen und optimieren die Ausführung der Scans zeitlich und organisatorisch noch weiter.

Die Stärke des Netzwerkscans liegt darin, dass er Zertifikate ermittelt, die an den von Ihnen erreichbaren Endpunkten aktiv genutzt werden. Seine Einschränkung ist das genaue Gegenteil: Er erkennt nur, was in einem von Ihnen kontrollierten Netzwerk auf Verbindungen wartet, weshalb er am besten in Kombination mit den beiden anderen Methoden eingesetzt wird.

CA-basierte Entdeckung

Bei der CA-basierten Erkennung wird die Logik umgekehrt. Anstatt zum Endpunkt (den „Blättern“ in der PKI-Hierarchie) zu gehen, wendet man sich an den Aussteller, nach dem Prinzip, dass die Stelle, die ein Zertifikat ausgestellt hat, auch die maßgeblichen Aufzeichnungen darüber führt. Dadurch ergibt sich eine klare Trennung zwischen privatem und öffentlichem Bereich.

Bei einer internen PKI erfolgt die direkte Anbindung an die ausstellende Zertifizierungsstelle, um die von ihr ausgestellten Zertifikate aufzulisten. Bei Microsoft AD CS bedeutet dies, die CA-Datenbank über deren Verwaltungsschnittstellen oder command abzufragen; bei EJBCA erfolgt EJBCA über die REST- oder SOAP-API. Sie erhalten jedes von der Zertifizierungsstelle ausgestellte Zertifikat zusammen mit Metadaten zur Anfrage, wie z. B. dem Antragsteller, der verwendeten Vorlage oder dem Profil sowie dem Sperrstatus. Entscheidend ist, dass das Erkennungstool – je nach seinem Zeitplan – bereits bei der Erstellung jedes Zertifikats Informationen darüber erfassen kann, noch bevor das Zertifikat irgendwo eingesetzt wird.

Bei öffentlich vertrauenswürdigen Zertifikaten kommt der Mechanismus der Zertifikatstransparenz (Certificate Transparency, CT) zum Einsatz. Browser verlangen mittlerweile, dass öffentlich vertrauenswürdige Zertifikate in CT-Protokollen, die nur im Anhang ergänzt werden können, protokolliert werden, bevor sie akzeptiert werden. Wenn Sie also CT-Aggregatoren (wie crt.sh oder Censys) oder die Protokolle direkt für Ihre eigenen Domains abfragen, erhalten Sie eine Liste der Zertifikate, die von einer öffentlichen Zertifizierungsstelle für Sie ausgestellt wurden. Auf diese Weise lassen sich „Schattenzertifikate“ aufspüren: solche, die ein Team ohne Benachrichtigung der Sicherheitsabteilung erworben hat und auf einer Infrastruktur bereitgestellt hat, die Sie nicht scannen, sowie alle fehlerhaft ausgestellten Zertifikate, die Ihre Domains vortäuschen. Bei einem Scan Ihrer eigenen IP-Bereiche würden diese niemals entdeckt werden.

Die Stärke der CA-basierten Erkennung liegt in der Autorität und Vollständigkeit für einen bestimmten Aussteller, unabhängig davon, wo das Zertifikat letztendlich landet. Die Einschränkung ist das Gegenteil des Netzwerkscans: Ein CA-Eintrag gibt Auskunft darüber, dass ein Zertifikat ausgestellt wurde, nicht jedoch darüber, wo es sich befindet oder ob es verwendet wird. CT deckt nur öffentliche Zertifikate ab, und die interne Erfassung umfasst nur die Zertifizierungsstellen, die Sie erreichen können; daher ergänzen sich beide Verfahren, anstatt sich zu überschneiden. Um den Kreis zu schließen, korrelieren Sie die Ausstellungsdaten mit den Einsatzdaten.

Agentenbasierte und Cloud-basierte Erkennung

Die Agenten greifen die Schwachstelle an, die den beiden vorherigen Methoden gemeinsam ist: gespeicherte Zertifikate. Auf jedem Host wird ein ressourcenschonender lokaler Prozess installiert, der den Rechner von innen heraus überprüft. Er durchsucht das Dateisystem nach Zertifikats- und Schlüsseldateien (wie z. B. .pem, .crt, .pfx und .jks), liest Plattformspeicher wie den Windows-Zertifikatsspeicher und Java-Keystores aus und analysiert die Dienstkonfiguration, um zu ermitteln, welches Zertifikat an welchen Dienst gebunden ist. Da er mit lokalen Berechtigungen läuft, erkennt er, was über das Netzwerk nicht sichtbar ist: Zertifikate, die an keinen offenen Port gebunden sind, den genauen Speicherort der Dateien und die Dienstzuordnung sowie den Status des privaten Schlüssels. Außerdem kann es ein neu installiertes Zertifikat sofort nach dessen Erscheinen melden, anstatt erst beim nächsten Scan-Zeitfenster, und da derselbe Agent in Schlüsselverzeichnisse schreiben und Dienste neu starten kann, lassen sich Erkennung und Behebung in einem einzigen Kanal zusammenfassen. Der Nachteil liegt in der Flottenverwaltung: Sie müssen Agenten auf vielen Betriebssystemen bereitstellen und warten, und es wird immer Geräte und Systeme von Drittanbietern geben, auf denen Sie keinen Agenten installieren können.

Die Cloud-Erkennung überträgt dasselbe Prinzip auf Infrastrukturen, auf denen kein Host vorhanden ist, auf dem ein Agent installiert werden könnte. Moderne Zertifikate befinden sich zunehmend in Anbieterdiensten statt auf Servern. Daher erteilen Sie einem Erkennungstool API-Zugangsdaten mit Lesezugriff und führen eine Erfassung über Konten, Abonnements, Projekte und Regionen hinweg durch. In der Praxis umfasst dies Zertifikatsdienste und Secret-Manager, Konfigurationen von Load Balancern und CDN-Listenern, API-Gateways, TLS sowie Service-Mesh-Identitäten. Diese Zertifikate sind oft kurzlebig, werden automatisch bereitgestellt und sind zahlreich; zudem sind sie für Netzwerk-Scans vor Ort und für Host-Agenten praktisch unsichtbar. Die Schwachstelle liegt in der ausufernden Abdeckung: Jedes Konto und jede Region stellt eine separate Integration dar, und sobald jemand ein Konto einrichtet, das noch nicht integriert wurde, fällt dieser Bereich aus.

Ermittlung vs. Überwachung: Den Unterschied verstehen

„Erkennung“ und „Überwachung“ werden oft in einem Atemzug genannt, doch sie erfüllen unterschiedliche Aufgaben, und ein gut funktionierendes Programm benötigt beides.

Erkennungsaufträge suchen nach neuen Zertifikaten. Sie greifen auf jeden Endpunkt innerhalb eines definierten Netzwerks zu und nehmen bisher unbekannte Zertifikate in Ihr Inventar auf. Überwachungsaufträge hingegen betrachten nur vorhandene Zertifikate, die zur Nachverfolgung markiert wurden, und lösen bei Erreichen eines konfigurierten Ablaufschwellenwerts eine Warnmeldung aus. Mit anderen Worten: Die Erkennung findet, die Überwachung beobachtet.

Und so passen sie zusammen:

• Discovery erstellt das Inventar.
  Es beantwortet die Fragen „Was haben wir und wo befindet es sich?“.
• Durch die Überwachung bleibt der Bestand in einem guten Zustand.
  Sie liefert Antworten auf die Frage: „Was läuft bald ab oder weicht von den Richtlinien ab?“
• Beide laufen kontinuierlich.
  Discovery sollte nach einem wiederkehrenden Zeitplan ausgeführt werden, damit neue Zertifikate schnell erkannt werden, während die Überwachung parallel dazu läuft, um Warnmeldungen auszugeben, bevor etwas abläuft.

Eine sinnvolle Vorgehensweise besteht darin, die Erkennung so einzurichten, dass neu gefundene Zertifikate automatisch in die Überwachung aufgenommen werden, damit kein Zertifikat im Bestand unbeaufsichtigt bleibt. Auf diese Weise läuft die Frist für die Benachrichtigung über das Ablaufdatum bereits in dem Moment an, in dem ein Zertifikat erkannt wird.

Die Risiken, wenn Sie Ihre Zertifikate nicht finden

Die Argumente für die Discovery werden deutlich, wenn man sich vor Augen führt, was ohne sie schiefgeht. Jedes Risiko entspricht einer Lücke, die durch die Discovery geschlossen werden soll.

Unerwartete Ausfälle aufgrund abgelaufener Zertifikate

Ablaufende Zertifikate sind der Feind der Verfügbarkeit. Schon ein einziger übersehener Ablauftermin reicht aus, um eine ganze Reihe von Ausfällen auszulösen: Eine Anwendung reagiert nicht mehr, ein davon abhängiger Dienst meldet einen Fehler, und die Störung führt schließlich zu Ausfallzeiten, die sich auf die Kunden auswirken. Diese Ausfälle sind besonders frustrierend, da sie vollständig vermeidbar sind. Das Zertifikat ist nicht ausgefallen; es wurde einfach vergessen. Discovery beseitigt die Kategorie „vergessen“, indem sichergestellt wird, dass jedes Zertifikat erfasst ist und durch Überwachung bis zu seinem Verlängerungsdatum verfolgt wird, lange bevor es zu einem Problem wird.

Sicherheitslücken und Verstöße gegen Compliance-Vorgaben

Unentdeckte Zertifikate werden in der Regel am schlechtesten gepflegt. Sie basieren möglicherweise auf veralteten Protokollversionen oder schwachen Algorithmen, sind mit Vertrauensankern verknüpft, über die Sie keine Kontrolle mehr haben, oder enthalten Konfigurationen, die unbemerkt gegen Richtlinien verstoßen. Da niemand sie im Auge behält, werden sie zu den Schwachstellen, nach denen ein Angreifer sucht. Insbesondere ältere SSL TLS (TLS .TLS und 1.1) sollten zugunsten des modernen TLS TLS .3) deaktiviert werden, doch dies lässt sich nur durchsetzen, wenn Sie wissen, wo sich die veralteten Konfigurationen befinden.

Es gibt auch eine regulatorische Dimension. Rahmenwerke, die den Datenverkehr regeln, sehen vor, dass eine Verschlüsselung angewendet und verwaltet wird. Zum Beispiel,

• Anforderung 4 des PCI DSS befasst sich mit der Verschlüsselung der Übertragung von Karteninhaberdaten,
• Die Bestimmungen zur Übertragungssicherheit der HIPAA-Sicherheitsvorschrift gelten für geschützte Gesundheitsdaten während der Übertragung, und
• Artikel 32 der DSGVO schreibt die Verschlüsselung als Teil der Sicherheit der Verarbeitung vor.

Ein nicht verwaltetes, falsch konfiguriertes Zertifikat kann dazu führen, dass Sie die Anforderungen dieser Vorschriften nicht erfüllen, und Sie können die Einhaltung der Vorschriften für Zertifikate nicht nachweisen, die Sie nicht einmal auflisten können.

Unfähigkeit, sich auf kryptografische Umstellungen vorzubereiten

Zwei Entwicklungen verändern bereits jetzt das Zertifikatsmanagement: die Umstellung auf deutlich kürzere Gültigkeitsdauern und die letztendliche Umstellung auf postquantenresistente Kryptografie. Für beides müssen Sie wissen, worüber Sie verfügen. Sie können keine Umstellung auf quantenresistente Algorithmen planen, wenn Sie nicht wissen, welche Zertifikate welche Kryptografie verwenden, und Sie können sich nicht auf kürzere Gültigkeitsdauern einstellen, wenn Sie nicht den gesamten Bestand kennen, der schneller erneuert werden muss. Die Erfassung in Verbindung mit einem umfassenden Bestandsverzeichnis ist die Voraussetzung für ein Zertifikatslebenszyklusmanagement, das Zertifikate sicher von der Ausstellung bis zum Ablauf begleitet.

Worauf Sie bei einem Tool zur Erkennung von TLS achten sollten

Nicht alle Discovery-Tools sind gleich. Nutzen Sie die folgende Checkliste, um jede Lösung anhand der Anforderungen einer modernen, schnelllebigen Zertifikatsumgebung zu bewerten.

• Umfassende Erfassung.
  Das Tool sollte die Erfassung über das Netzwerk, über Zertifizierungsstellen (CA) sowie cloud-nativ unterstützen. Da jede einzelne Methode blinde Flecken hinterlässt, sollte als Erstes die Breite der Abdeckung überprüft werden.
• Detailliertheit pro Zertifikat.
  Ein Zertifikat zu finden ist nur der Anfang; der eigentliche Wert liegt in den damit verbundenen Attributen. Achten Sie auf die vollständige Kettenauflösung, den vollständigen Satz alternativer Namen des Zertifikatsinhabers, Gültigkeitsdaten, Schlüsseltyp und -größe sowie sowohl den vom Zertifikatsinhaber verwendeten Algorithmus für den Zertifikatsschlüssel als auch den für die Signatur. Diese Unterscheidung zwischen zwei Algorithmen ist für die kryptografische Flexibilität von Bedeutung, da die Authentifizierungsstärke eines Zertifikats nur so hoch ist wie die der schwächsten Signatur in seiner Kette.
• Automatisierte Planung.
  Discovery sollte nach wiederkehrenden Zeitplänen ohne manuellen Eingriff ausgeführt werden, wobei Steuerungsmöglichkeiten wie Ruhezeiten zur Steuerung des Zeitpunkts zur Verfügung stehen sollten.
• Zentralisierte Bestandsverwaltung.
  Ein einziges Repository sollte alle erfassten Zertifikate zusammenfassen, unabhängig davon, wie sie gefunden wurden, sodass es einen zentralen Ort für die Suche und die Berichterstellung gibt.
• Benachrichtigungen bei Ablauf.
  Konfigurierbare Benachrichtigungen sollten ausgelöst werden, wenn sich Zertifikate ihrem Ablaufdatum nähern.
• Integration in das Lebenszyklusmanagement.
  Die Bestandserfassung sollte direkt in die Workflows für Verlängerung, Bereitstellung und Widerruf einfließen und nicht als eigenständiger Bericht dienen.
• Skalierbarkeit.
  Die Unterstützung der Aufteilung großer Netzwerke in Scan-Zonen mithilfe von Orchestrator-Pools sorgt dafür, dass die Leistung auch bei wachsender Netzwerkumgebung beherrschbar bleibt.
• Berichterstellung und Compliance.
  Das Tool sollte auditfähige Berichte erstellen und im Idealfall einen zeitpunktbezogenen Verlauf speichern, damit Sie rückblickende Fragen beantworten können, beispielsweise welche Zertifikate während eines bestimmten Zeitraums aktiv waren.

Je detaillierter die Datensätze pro Zertifikat sind, desto mehr Möglichkeiten bietet das Inventar später, und auch die Verwaltung wird gründlicher und detaillierter. Attribute wie der Status des privaten Schlüssels (wo sich der Schlüssel befindet und ob er exportierbar ist), Bereitstellungsbindungen (jeder Ort, an dem ein Zertifikat installiert ist, nicht nur einer) und die Herkunft der Ausstellung (welche Zertifizierungsstelle, welche Vorlage, welcher Antragsteller) verwandeln eine flache Liste in etwas, auf dessen Grundlage Sie Audits durchführen und Migrationen vornehmen können. Wer bei der Datenerfassung an der Detailtiefe spart, schränkt stillschweigend die Möglichkeiten ein, die das Inventar später jemals unterstützen kann.

Die Auswirkungen kürzerer Gültigkeitsdauern von Zertifikaten auf die Erkennung

Der wichtigste Grund dafür, dass sich die Discovery von einem periodischen Projekt zu einer kontinuierlichen Praxis wandelt, ist die branchenweite Entscheidung, die Gültigkeitsdauer von Zertifikaten zu verkürzen. Das CA/Browser Forum hat eine schrittweise Verkürzung (Abstimmungsvorlage SC-081v3) genehmigt, bei der die maximale Gültigkeitsdauer über mehrere Jahre hinweg schrittweise gesenkt wird und bis Anfang 2029 bei etwa anderthalb Monaten (47 Tagen) liegt. Laut der Zusammenfassung des Zeitplans durch DigiCert wird die Gültigkeitsdauer in den Zwischenetappen Anfang 2026 auf 200 Tage und Anfang 2027 auf 100 Tage begrenzt, bevor die letzte Stufe in Kraft tritt.

Die betrieblichen Zahlen sprechen eine unerbittliche Sprache. Ein Zertifikat, das früher etwa einmal im Jahr überprüft werden musste, muss nun mehrmals im Jahr erneuert werden. Rechnet man das auf die gesamte Infrastruktur hoch, wird der Aufwand deutlich:

• Die manuelle Nachverfolgung reicht nicht mehr aus.
  Bei solchen Laufzeiten können Tabellenkalkulationen und Kalendererinnerungen nicht mehrmithalten. Die manuelle Nachverfolgung und Verlängerung ist zu diesem Zeitpunkt nicht nur ineffizient, sondern stellt sogar ein Risiko dar.
• Die Erfassung muss kontinuierlich erfolgen.
  Eine einmalige Prüfung ist fast sofort veraltet, wenn Zertifikate so schnell erneuert werden. Die Erfassung muss automatisiert und wiederkehrend erfolgen, damit das Bestandsverzeichnis nie zu weit von der Realität abweicht.
• Frühzeitige Investitionen zahlen sich aus.
  Unternehmen, die jetzt automatisierte Erkennung einführen, werden jeden Meilenstein mit kürzerer Laufzeit reibungslos bewältigen, während diejenigen, die abwarten, jede Kürzung als neue Krisensituation empfinden werden.

Kürzere Lebensdauern ändern nichts daran, was eine Discovery ist. Sie beeinflussen lediglich, wie oft sie ausgeführt werden muss, und machen eine manuelle Durchführung unmöglich.

Wie Keyfactor helfen Keyfactor

Keyfactor entwickelt, um genau die oben beschriebenen Herausforderungen bei der Erfassung zu lösen. Die SSL durchforstet definierte Netzwerke, um jeden TLS zu ermitteln und die Zertifikatsdaten in ein zentrales Inventar zu importieren. So erhalten Sie eine präzise Bestandsaufnahme, die mit manuellen Verfahren nicht aufrechterhalten werden kann.

Der Arbeitsablauf entspricht genau den zuvor behandelten Bewertungskriterien:

• Flexible, segmentierte Erfassung.
  Agilesecführt Erfassungsaufträge aus, die nach Netzwerken organisiert sind und zur Leistungsoptimierung segmentiert, nach Standort Orchestrator-Pools zugewiesen, in flexiblen Intervallen geplant sowie unter Berücksichtigung von Ruhezeiten angepasst werden können.
• Automatische Einbindung in die Überwachung.
  Zertifikate, die im Rahmen der Erkennung gefunden wurden, können automatisch in die Überwachung aufgenommen werden – mit konfigurierbaren Benachrichtigungen zum Ablaufdatum –, sodass kein Element unbeaufsichtigt in das Inventar gelangt.
• Lebenszyklus-Automatisierungund mehr.
  Keyfactor Command lässt sich in AgileSec integrieren und vereint Bestandsverwaltung, Lebenszyklusautomatisierung und Compliance-Berichterstattung, sodass das Auffinden eines Zertifikats nahtlos in dessen Verlängerung, Bereitstellung und Widerruf übergeht.
• Bereit für die nächsten Schritte.
  Die Plattform unterstützt die Vorbereitung auf kürzere Lebenszyklen und den Übergang zur Post-Quanten-Ära durch kryptografische Flexibilität und bietet Ihnen die für diese Veränderungen erforderliche Grundlage in Bezug auf Bestandsverwaltung und Automatisierung.

Das umfassende Portfolio Keyfactor, das unter anderem die Bereiche „Cryptographic Discovery & Inventory“ und „Certificate Lifecycle Automation“ umfasst, ist so konzipiert, dass die Erfassung nicht als isolierte Aufgabe betrachtet wird, sondern als Einstieg in ein umfassendes Zertifikatsmanagementprogramm.

Die wichtigsten Erkenntnisse

• Unter TLS versteht man den Prozess, bei dem alle Zertifikate in Ihrer Umgebung automatisch ermittelt und deren wesentliche Details erfasst werden.
• Ohne eine Bestandsaufnahme sind Unternehmen mit vermeidbaren Ausfällen, Sicherheitslücken und Verstößen gegen Compliance-Vorgaben konfrontiert.
• Erkennung und Überwachung ergänzen sich: Bei der Erkennung werden neue Zertifikate gefunden, während bei der Überwachung bekannte Zertifikate bis zu ihrem Ablauf verfolgt werden.
• Netzwerkscans, CA-basierte Erkennung sowie die Erkennung über Agenten oder die Cloud erfassen jeweils einen anderen Teil der Infrastruktur; daher kombinieren leistungsstarke Programme alle drei Ansätze.
• Angesichts der Entwicklung hin zu einer Lebensdauer von etwa 47 Tagen bis zum Jahr 2029 ist eine kontinuierliche, automatisierte Erfassung nicht mehr nur optional, sondern unverzichtbar.
• Ein leistungsstarkes Erkennungstool bietet umfassende Scans, detaillierte Informationen zu jedem einzelnen Zertifikat, automatisierte Zeitplanung, eine zentralisierte Bestandsverwaltung sowie die Integration in das Lebenszyklusmanagement.
• Keyfactor auf einer einzigen Plattform umfassende Funktionen zur Erkennung, Überwachung und Automatisierung des Zertifikatslebenszyklus.