Bei dem ProtokollSSL / TLS geht es um Sicherheit und Authentifizierung. Es ermöglicht die Verschlüsselung der Datenkommunikation über offene Netze und schützt so vor Manipulationen und Abhören durch böswillige Akteure. Darüber hinaus authentifiziert die Verwendung von SSL Zertifikaten die kommunizierenden Parteien und schafft eine vertrauenswürdige Umgebung. Sicherheit und Authentifizierung sind die Bausteine für erfolgreiche Unternehmen in der digitalen Welt.
Um das erforderliche Maß an Vertrauen zu schaffen und die Verwendung von gefälschten Zertifikaten zu verhindern, die sich als legitime Unternehmen ausgeben, müssen die Zertifikate von SSL von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert und validiert werden. CAs stellen vertrauenswürdige Stammzertifikate aus, die in Vertrauensspeichern enthalten sind. Den digitalen Zertifikaten, die mit dem privaten Schlüssel des Stammzertifikats signiert sind, wird von allen Geräten und Anwendungen vertraut, deren Vertrauensspeicher die Stammzertifikate enthält. Auf diese Weise wird eine Vertrauenskette geschaffen, die zur Authentifizierung von Organisationen verwendet wird.
Heutzutage werden digitale Zertifikate verwendet, um Tausende von Verbindungen zwischen Maschinen, Geräten und Anwendungen zu sichern. Traditionell verwenden Unternehmen SSL/TLS Zertifikate, die von vertrauenswürdigen öffentlichen Zertifizierungsstellen (CAs) unterzeichnet wurden. Mit der Verbreitung von Technologien und Initiativen wie Cloud, Containerisierung, IoT und mobilen Geräten und der daraus resultierenden explosionsartigen Zunahme der Anzahl digitaler Zertifikate haben viele auch interne, private Zertifizierungsstellen eingesetzt, um diese Bereitstellungen zu sichern.
Schauen wir uns einige der wichtigsten Unterschiede an:
Öffentlich vertrauenswürdige Zertifikate
Öffentlich vertrauenswürdige SSL/TLS Zertifikate werden für öffentlich zugängliche Webserver und Anwendungen verwendet. Ein öffentlich vertrauenswürdiges Zertifikat kann nur von einer externen, vertrauenswürdigen Drittanbieter-Zertifizierungsstelle (z. B. Entrust, DigiCert usw.) ausgestellt werden, die den Domäneninhaber verifiziert.
Privat vertrauenswürdige Zertifikate
Privat vertrauenswürdige SSL/TLS Zertifikate werden verwendet, um Benutzer und Geräte im internen Netzwerk zu authentifizieren. Ein privat vertrauenswürdiges Zertifikat kann entweder von einer öffentlichen Zertifizierungsstelle ausgestellt werden oder, was häufiger der Fall ist, von einer Organisation, die eine eigene interne Infrastruktur für öffentliche Schlüssel betreibt (z. B. Microsoft CA).
Was ist ein selbstsigniertes Zertifikat?
Eine andere Strategie besteht darin, selbst signierte SSL Zertifikate auszustellen. Ein selbstsigniertes Zertifikat ist ein Zertifikat, das nicht von einer CA signiert ist - weder privat noch öffentlich. In diesem Fall wird das Zertifikat mit dem eigenen privaten Schlüssel signiert, anstatt es bei einer öffentlichen oder privaten CA anzufordern.
Selbstsignierte Zertifikate bieten einige Vorteile, wenn sie in internen Netzwerken und in den Entwicklungsphasen von software verwendet werden, sie können jedoch auch verschiedene Risiken mit sich bringen, wenn sie nicht angemessen sichtbar sind und kontrolliert werden.
Die größte Herausforderung bei selbstsignierten Zertifikaten besteht darin, dass Sicherheitsteams oft keinen Überblick darüber haben, wie viele sie haben, wo sie installiert sind, wem sie gehören und wie der private Schlüssel gespeichert ist. Es ist schon schwierig genug, den Überblick über Zertifikate zu behalten, die von verschiedenen öffentlichen und privaten Zertifizierungsstellen ausgestellt wurden. Es ist praktisch unmöglich, den Überblick über selbstsignierte Zertifikate zu behalten, die ohne ein formelles Anfrage- oder Genehmigungsverfahren ausgestellt wurden.
Wenn das Unternehmensnetzwerk angegriffen wird, gibt es keine Möglichkeit festzustellen, ob ein selbstsigniertes Zertifikat (und sein privater Schlüssel) kompromittiert wurde. Kompromittierte selbstsignierte Zertifikate können viele Sicherheitsprobleme mit sich bringen, da Angreifer die Identität des Opfers fälschen können. Im Gegensatz zu von Zertifizierungsstellen ausgestellten Zertifikaten können selbstsignierte Zertifikate nicht widerrufen werden. Die Unfähigkeit, den mit einem selbstsignierten Zertifikat verbundenen privaten Schlüssel schnell zu finden und zu widerrufen, stellt ein ernstes Risiko dar.
Die Risiken von selbstsignierten Zertifikaten und CAs in DevOps
Diese Risiken werden durch die Anzahl integrierter, selbstsignierter Zertifizierungsstellen in DevOps-Tools und Cloud-Diensten sowie durch selbstsignierte Zertifikate, die von Entwicklern ausgestellt werden, noch verstärkt.
Bei DevOps geht es um Geschwindigkeit und Agilität. Selbstsignierte Zertifikate ermöglichen es Entwicklern zwar, schnell und einfach Zertifikate zu erhalten, aber sie umgehen oft die Richtlinien, die Sie zur Sicherung Ihres Netzwerks eingeführt haben. Unabhängig davon, ob Entwickler ein selbstsigniertes Zertifikat erstellen oder eine selbstsignierte Zertifizierungsstelle einrichten, schaffen diese Methoden ein falsches Gefühl des Vertrauens in Ihren Entwicklungs- und Bereitstellungsprozess.
Warum sollten Entwickler also selbstsignierte Zertifikate verwenden? Die bessere Frage ist, warum sie es nicht tun sollten. Der übliche manuelle Prozess des Einreichens einer Zertifikatsignierungsanforderung (CSR) und des anschließenden stundenlangen Wartens auf die Überprüfung und Signierung ist einfach nicht intuitiv. Um Zeit und Frustration zu sparen, ist es für Entwickler sinnvoll, sich für selbstsignierte Zertifikate oder integrierte Zertifizierungsstellen wie HashiCorp Vault, Istio und Kubernetes zu entscheiden.
In ihrem Bericht "Managing Machine Identities, Secrets, Keys and Certificates" empfiehlt Gartner die Integration von Secrets Managern mit richtlinienkonformen Emittenten (öffentliche oder private CAs) und die Überwachung der Ausstellung von Secrets Managern durch Zertifikatsmanagementsysteme, um die Prüfung und Verwaltung des Lebenszyklus von ausgestellten Zertifikaten zu unterstützen.
Einfach eine selbstsignierte Zertifizierungsstelle einzurichten und große Mengen an Zertifikaten auszustellen, ohne die richtigen PKI-Praktiken und Zertifikatsrichtlinien einzuhalten, ist keine praktikable Option.
Trotz des offensichtlichen Vorteils, den Entwicklungsprozess zu beschleunigen, hat diese Praxis mehrere Auswirkungen auf die Sicherheit, da oft nicht an die Sicherheit gedacht wird. Nicht vertrauenswürdige, nicht nachverfolgte selbstsignierte Zertifikate können bei software Angriffen auf die Lieferkette verwendet werden und es böswilligen Akteuren ermöglichen, bösartigen Code einzuschleusen.
Unternehmen müssen sicherstellen, dass alle ihre Zertifikate von einem sicheren Root of Trust ausgestellt werden, mit Richtlinien und Best Practices übereinstimmen und während ihres gesamten Lebenszyklus verwaltet werden.
Die Alternative: Wechsel von der Selbstsignatur zur Selbstbedienung
Die Lösung zur Bewältigung dieser Herausforderung erfordert einen grundlegenden Wandel in der Art und Weise, wie Sicherheits- und Entwicklungsteams zusammenarbeiten. Letztlich müssen Sie den Entwicklern einen schnellen und einfachen Zugriff auf Zertifikate aus ihren Arbeitsabläufen heraus ermöglichen, ohne dabei Vertrauen und Richtlinien zu opfern.
Auf Keyfactor arbeiten wir mit DevOps-Teams zusammen, um den Wechsel von selbstsignierten Zertifikaten zu Zertifikaten als Service zu vollziehen. Das bedeutet, dass Entwickler Zertifikate über automatisierte Prozesse und APIs beziehen können, die direkt in Cloud-native Tools wie Jenkins, Ansible, Kubernetes, HashiCorp Vault, Istio und andere integriert sind. In der Zwischenzeit wird jedes Zertifikat von einer vertrauenswürdigen PKI as-a-Service ausgestellt und die Sicherheit behält die volle Transparenz und Kontrolle über jedes ausgestellte Zertifikat.
Ermöglichung von PKI as-a-Service in DevOps
PKI as-a-Service (PKIaaS) ist die richtige Mischung aus Vertrauen und Benutzerfreundlichkeit. Zertifikate werden von einer vertrauenswürdigen, privat verwurzelten PKI ausgestellt, und DevOps-Teams können Zertifikate einfach über Self-Service-Prozesse anfordern und ausstellen, wodurch der Bedarf an selbstsignierten Zertifikaten sinkt.
Wenn Sie mehr darüber erfahren möchten, wie Sie den Bedarf an selbstsignierten Zertifikaten eliminieren und die Automatisierung von Selbstbedienungsprozessen nutzen können, fordern Sie noch heute eine Demo von Keyfactor an.
