GlobalSign Blog

Sicherheit der DevOps-Pipeline: Risiken selbstsignierter Zertifikate vermeiden

Sicherheit der DevOps-Pipeline: Risiken selbstsignierter Zertifikate vermeiden

SSL/TLS-Protokolle sind eine geschäftliche Notwendigkeit für die Sicherung von Verbindungen zwischen Apps, Geräten und Maschinen, die über das Internet zugänglich sind. Diese Protokolle erfordern Zertifikate, um Daten durch Verschlüsselung und Authentifizierung zu schützen und so potenzielle Manipulationen und böswillige Angriffe einzudämmen. Die sichersten Zertifikate werden von vertrauenswürdigen Zertifizierungsstellen (CAs) ausgestellt und validiert, wodurch eine entscheidende Vertrauenskette für die Authentifizierung gewährleistet wird. 

Was sind selbstsignierte Zertifikate?

  • Öffentlich vertrauenswürdige Zertifikate, die für öffentlich zugängliche Webserver und Anwendungen verwendet werden, müssen von einer externen, vertrauenswürdigen Drittanbieter-Zertifizierungsstelle ausgestellt werden, die den Domäneninhaber sicher verifiziert. Einige Organisationen betreiben auch ihre eigene interne PKI und stellen ihre eigenen privat vertrauenswürdigen SSL/TLS-Zertifikate für ihre internen Netzwerke aus, um Geräte und Benutzer zu authentifizieren.  
  • Selbstsignierte Zertifikate hingegen werden weder von einer öffentlichen noch einer privaten Zertifizierungsstelle signiert. Da die Informationen in den selbstsignierten Zertifikaten aber nicht von einer vertrauenswürdigen Zertifizierungsstelle überprüft und authentifiziert wurden, können sie Sicherheitswarnungen auslösen. Dies stellt ein erhebliches Problem dar, wenn Webbrowser und Betriebssysteme aufgrund von Sicherheitsrisiken vor Zertifikaten warnen, die nicht von einer öffentlich vertrauenswürdigen Zertifizierungsstelle signiert wurden. Ohne Authentifizierung über eine Zertifizierungsstelle können Benutzer nicht feststellen, ob ein Zertifikat vertrauenswürdig ist oder von böswilligen Akteuren generiert wurde. 

Warum sind selbstsignierte Zertifikate für Entwickler attraktiv?

Selbstsignierte Zertifikate werden von Entwicklern in internen Netzwerken mit geringem Risikograd sowie in Softwareentwicklungs- und Testphasen verwendet. 

  • Selbstsignierte Zertifikate bieten Zweckmäßigkeit und Agilität in allen Phasen des Entwicklungszyklus. 
  • Durch die Erzeugung selbstsignierter Zertifikate entfallen Wartezeiten für Verifizierungs- und Signaturprozesse, die sonst Zeitverlust, Frustration und Unterbrechungen verursachen. 
  • Für selbstsignierte Zertifikate gelten keine Regelungen zur Gültigkeitsdauer. Im Gegensatz dazu sind öffentlich vertrauenswürdige SSL/TLS-Zertifikate derzeit auf eine Gültigkeitsdauer von 13 Monaten beschränkt. 

Wenn Entwickler selbstsignierte Zertifikate verwenden, sollte es jedoch strenge Richtlinien zum Schutz und zur Zugriffssicherheit geben. Um den Überblick über alle Zertifikate und deren Authentizität zu behalten, ist ein etabliertes Team für die Zertifikatsverwaltung mit effizienten Überwachungstools unverzichtbar. Leider stehen die damit verbundenen Sicherheitsprobleme nicht immer im Vordergrund. So wie die Schatten-IT für mehr Komplexität und unnötige Risiken sorgt, können selbstsignierte Zertifikate zu erheblichen Risiken führen.

Warum Entwickler keine selbstsignierten Zertifikate nutzen sollten 

Das wichtigste Argument gegen selbstsignierte Zertifikate ist ganz einfach, dass sie nicht vertrauenswürdig sind. Außerhalb interner Netzwerke müssen SSL/TLS-Zertifikate von einer vertrauenswürdigen Zertifizierungsstelle signiert werden, um das wichtige Benutzervertrauen zu erreichen. Die Validierung durch eine vertrauenswürdige öffentliche Zertifizierungsstelle ist entscheidend, um die Gefahr nicht nachverfolgbarer betrügerischer Zertifikate, Spoofing und der Bereitstellung von bösartigem Code auszuschließen.

Risikofaktoren bei der Verwendung selbstsignierter Zertifikate

  1. Kein Widerrufsprozess – Es gibt keine Meldebehörde, um abgelaufene oder kompromittierte Zertifikate zu widerrufen, wodurch die böswillige Ausnutzung und Sicherheitsverletzungen möglich werden.  
  2. Mangelnde Transparenz, Bestandskenntnis und Kontrolle – Für Sicherheitsteams ist es schwierig, die Anzahl der Zertifikate, den Installationsort, den Besitz und die Speicherdetails des privaten Schlüssels zu ermitteln oder zu erfahren, ob ein Zertifikat kompromittiert ist. 
  3. Mangelnde technische Unterstützung – Intern erstellte Zertifikate beinhalten nicht die umfassende Kompetenz, die Verwaltungstools und die Widerrufsmechanismen, die öffentliche Zertifizierungsstellen bereitstellen können. 
  4. Mangelnde Compliance und Ausrichtung an Sicherheitsstandards – Oft fehlt es an Kenntnissen über Vorschriften und der Anwendung bewährter Verfahren zur Einhaltung von Compliance-Standards.

Warum gehostete PKI in DevOps eine sichere und vorteilhafte Alternative ist

Eine Public Key Infrastructure, kurz PKI, ist das technologische Ökosystem aus Richtlinien, Verfahren, Hardware und Software, das die Ausstellungs-, Verwaltungs-, Speicher- und Widerrufsprozesse für digitale Zertifikate ermöglicht. Die PKI ermöglicht die Erstellung digitaler Zertifikate, welche die Identität von Geräten, Benutzern und Diensten mithilfe von Datenverschlüsselung, digitalen Signaturen und der Ausstellung von Zertifikatsauthentifizierungen durch vertrauenswürdige Zertifizierungsstellen authentifizieren. Für Entwickler ist PKI-as-a-Service (PKIaaS) aufgrund seiner Benutzerfreundlichkeit, Skalierbarkeit, Effizienz und seiner Vertrauenswürdigkeit eine sehr gute Alternative zu selbstsignierten Zertifikaten.  

Vorteile von gehosteter PKI für DevOps

Ein gehostetes PKIaaS bietet zahlreiche Vorteile, darunter folgende:

  • Vollständige Transparenz, kontrollierte Verwaltung und Kenntnis aller ausgestellten Zertifikate
  • Eliminierung von Schwachstellen durch nicht vertrauenswürdige, nicht nachverfolgbare betrügerische Zertifikate oder Zertifikat-Spoofing
  • Schnellere Zertifikatsausstellung
  • Mehr Sicherheit bei der DevSecOps-Automatisierung
  • Reduzierung der SSL/TLS-Eigentumskosten
  • Automatisierte Zertifikatsbereitstellung
  • Enthält einen öffentlich vertrauenswürdigen Root, der mit allen Betriebssystemen und Browsern kompatibel ist
  • Freiheit von der internen Zertifikatsverwaltung 
  • Zeit- und Kosteneinsparungen bei der Verwaltung von Software, Wartung, Mitarbeiterschulung, Überwachung und Gesundheitsprüfungen

Der PKI-Service von GlobalSign für DevOps kann bei Zertifikatsherausforderungen helfen

GlobalSign kann mit unseren gehosteten, zuverlässigen und vertrauenswürdigen CA-Diensten die Herausforderungen bei DevOps-Zertifikaten meistern. Durch eine Partnerschaft mit GlobalSign haben Entwickler eine einzige Quelle für alle Zertifikatsanforderungen, so dass sie sich auf ihre Kernkompetenzen konzentrieren können. Unsere PKI-Expertise stellt sicher, dass Best Practices und Prüfanforderungen eingehalten werden, und sie bietet gleichzeitig erstklassigen Support sowie Service Level Agreements (SLA).

Die PKI-Zertifikatsdienste von GlobalSign werden mit kostengünstiger DevOps-Geschwindigkeit bereitgestellt und stellen außerdem sicher, dass Zertifikate und PKI-Komponenten auf dem neuesten Stand der Best Practices und Vorschriften sind.

Von GlobalSign gehostete PKI-Funktionen

  • Gehostete, mit RFC 5280 konforme Widerrufsdienste (CRL oder OCSP), sichere Offline-Schlüsselspeicherung sowie das Hosting und die Verwaltung spezifischer oder gemeinsam genutzter, öffentlicher oder privater Kundenstammverzeichnisse 
  • Bereitstellung über die GlobalSign-APIs oder die ACME-Integration
  • Direkte Integration in „Venafi as a Service“ und HashiCorp Vault verfügbar
  • Einbindung von Kubernetes Certmanager über Atlas
  • CLI-Tool für die Ausstellung, Erneuerung und den Widerruf von Zertifikaten mit HVClient   
  • Abdeckung des Zertifikatsbedarfs über den gesamten Softwarestack

Erfahren Sie mehr über die gehosteten PKI-Dienste von GlobalSign für DevOps

Share this Post

Aktuelle Blogs