SSL/TLS Zertifikate, die von vertrauenswürdigen öffentlichen oder privaten Zertifizierungsstellen (CAs) ausgestellt wurden, werden zur Authentifizierung einer einzelnen Domäne in öffentlich zugänglichen Websites verwendet. Organisationen mit einer Handvoll öffentlicher Domains und Subdomains müssten die gleiche Anzahl von digitalen Zertifikaten ausstellen und verwalten, was die Komplexität des Zertifikatslebenszyklusmanagements erhöht. Die gute Nachricht ist, dass es eine Lösung gibt, um diese Belastung zu umgehen.
Wildcard-Zertifikate versprechen Einfachheit, aber sind sie die Lösung für all unsere Gebete?
Dieser Blog wurde gemeinsam mit Robert Masterson von Thales verfasst.
Der Wandel hin zu Cloud-nativen Anwendungen verändert die Bausteine der IT. Die Entwicklung und Wartung von Infrastruktur und Anwendungen im eigenen Haus ist in vielen Fällen einfach keine Option mehr. Cloud-native Anwendungsentwicklung und die Verwendung von Containern und Orchestrierungs-Frameworks wie Kubernetes bieten unbestreitbare Vorteile in Bezug auf Leistung, Portabilität und Skalierung.
Für Sicherheitsteams ist es jedoch offensichtlich, dass die mögliche Angriffsfläche dadurch größer geworden ist. Die bedarfsorientierte, groß angelegte Bereitstellung von IT-Ressourcen in einer Mischung aus öffentlichen und privaten Clouds bedeutet, dass Sicherheitsschwachstellen oder Exploits oft unentdeckt bleiben können. Zu wissen, wem und was man vertrauen kann, ist ein ständiger Kampf, da bösartiger Code, nicht vertrauenswürdige Verbindungen und Fehlkonfigurationen nur zu einem führen - zu mehr Risiko.
Verschiedene Mechanismen helfen Anwendungs- und Sicherheitsteams, diese Risiken zu mindern, aber die Identität ist das Herzstück. Die Identifizierung aller "Dinge" (z. B. Arbeitslasten, Dienste, Code) in jeder Cloud oder jedem Netzwerk, die Überprüfung der Integrität und die End-to-End-Verschlüsselung von Verbindungen ist die halbe Miete. Zwei wichtige Funktionen, die dies ermöglichen, sind die Durchsetzung von Signaturen und die Vertrauensauthentifizierung, die beide durch die Verwendung von X.509-Zertifikaten erreicht werden können.
Alles unterschreiben
Entwickler sollten Code immer digital signieren, um Endbenutzer vor dem Herunterladen und Installieren von kompromittiertem Code zu schützen. Das Signieren des Codes stellt sicher, dass die Anwendung nicht von einem unbefugten Benutzer geändert werden kann, und bietet eine hohe Sicherheit, dass nur authentischer, vom Anbieter entwickelter und überprüfter Code ausgeführt wird. Sobald software in Containern für die Bereitstellung in der Cloud verpackt ist, können auch die Container signiert werden. Docker beispielsweise unterstützt Containersicherheit und -signierung, um die Integrität und den Herausgeber des Containers zu überprüfen.
Wir empfehlen beide Stufen der Signierung. Wenn die Anwendung signiert ist, der Container jedoch nicht, könnte ein böswilliger Benutzer neben dem legitimen Code möglicherweise auch anderen böswilligen Code auf dem Container ausführen. Die Erzwingung von Signaturen ist zweifellos notwendig, aber noch wichtiger ist der Schutz von Zertifikaten - und des zugehörigen privaten Schlüssels -, die für die Signierung verwendet werden. Wenn diese Schlüssel kompromittiert werden, können Angreifer sie verwenden, um bösartigen Code zu signieren und ihn als authentisch und vertrauenswürdig erscheinen zu lassen, genau wie Ihren software.
Keyfactor Code Assure wurde speziell für die Lösung dieser Probleme entwickelt. Die Plattform bietet Entwicklern programmatischen Zugang zu Zertifikaten, um Code zu signieren, während das Sicherheitsteam einen strengen Prüfpfad für alle Signieraktivitäten führt und sicherstellt, dass die privaten Schlüssel in einem integrierten Thales HSM sicher bleiben. Die Speicherung der privaten Schlüssel in einem FIPS 140-2 Level 3 zertifizierten Thales HSM - entweder vor Ort oder in der Cloud - stellt sicher, dass das Zertifikat nicht extrahiert oder kopiert werden kann, selbst wenn jemand Zugriff auf den Standort hat.
Insbesondere kann die Signierung aus der Ferne erfolgen, wodurch die Verteilung sensibler Schlüssel an mehrere Teams oder Standorte entfällt. Der Keyfactor Cryptographic Storage Provider (CSP) und die APIs ermöglichen die Integration in nahezu jede CI/CD-Pipeline oder jeden Build-Prozess, unabhängig davon, ob Sie Microsoft SignTool für ausführbare Windows-Dateien, jarsigner für die Java-Authentifizierung oder ein komplexeres Tool wie Jenkins verwenden.
Sichere Identitäten für alles einrichten
Die beste Praxis ist, sicherzustellen, dass jede Verbindung zu, von oder innerhalb eines Containers oder Clusters SSL/TLS verwendet, um gegenseitige Authentifizierung und Ende-zu-Ende-Verschlüsselung zu ermöglichen. Dies verhindert, dass unbefugte Angreifer eine Verbindung herstellen, die die Containersicherheit eines ganzen Clusters gefährden könnte. Es ist auch wichtig, die ausgestellten und aktiven Zertifikate SSL/TLS zu überwachen und zu prüfen. Unbekannte, betrügerische oder nicht konforme Zertifikate können zu einem unerwarteten Ausfall oder, schlimmer noch, zu einem Missbrauch führen, der unbeabsichtigten Zugriff auf eingeschränkte Systeme ermöglicht.
Kubernetes kann zum Beispiel selbst Zertifikate generieren und ausstellen, aber die meisten finden, dass es nicht die nötige Transparenz bietet, um sicherzustellen, dass keine unangemessenen Zertifikate ausgestellt wurden. Kubernetes unterstützt jedoch auch das ACME-Protokoll, mit dem Zertifikate von anderen Quellen, wie Let's Encrypt, bezogen werden können. Diese Protokollunterstützung ist in den Keyfactor ACME Server integriert, der als Teil von Keyfactor Command - unserer PKI-as-a-Service- und Zertifikatsautomatisierungsplattform - enthalten ist, um Zertifikate von jeder von Unternehmen unterstützten PKI, ob öffentlich oder privat, zu erhalten, die in der Keyfactor Plattform konfiguriert ist. Dies ermöglicht die sichere, automatische Ausstellung eines eindeutigen, vertrauenswürdigen Identitätszertifikats für jeden Container bei der Bereitstellung. Dies geschieht mit einer robusten rollenbasierten Zugriffskontrolle auf verschiedene Zertifikatsvorlagen oder -produkte sowie mit umfassenden Workflow-, Prüf- und Warnfunktionen, um sicherzustellen, dass keine Zertifikate ausgestellt oder verwendet werden, wenn dies nicht der Fall sein sollte.
Für Container ausgestellte Zertifikate sollten kurzlebig sein, um die Anzahl der zu einem bestimmten Zeitpunkt aktiven, nicht abgelaufenen Zertifikate zu begrenzen, die oft Tausende übersteigen kann. Dies trägt dazu bei, das Risiko einer Kompromittierung zu verringern und die Auswirkungen eines gestohlenen Zertifikats zu mindern, da es ohnehin bald abläuft. Das Zertifikat, das nicht kurzlebig sein kann, ist jedoch auch das wichtigste - das Zertifikat der Zertifizierungsstelle (CA) selbst.
Wie beim Code Signing ist die Sicherung der Zertifizierungsstellen, die die Zertifikate ausstellen, von entscheidender Bedeutung. Wenn eine Zertifizierungsstelle kompromittiert wird, können Angreifer ihre eigenen Identitäten ausstellen, die standardmäßig in Ihrem gesamten Ökosystem als vertrauenswürdig eingestuft werden, was extrem kostspielig sein kann, da jede von dieser Zertifizierungsstelle ausgestellte Identität ungültig wird. Die Plattform Keyfactor Command , die mit Thales HSMs integriert ist, um Ihre CA-Zertifikate und -Schlüssel zu sichern, gewährleistet robusten Schutz und vollständige Transparenz, Richtliniendurchsetzung und Automatisierung für alle Zertifikate.
Entdecken Sie, wie die Automatisierung des Lebenszyklus von Zertifikaten Ihnen helfen kann, DevOps- und Sicherheitsziele zu erreichen. Laden Sie das DevOps.com eBook herunter:
