Stiefkind Verschlüsselung
DevOps-Teams sollten selbstsignierte- und Wildcard-Zertifikate vermeiden
Stiefkind Verschlüsselung – warum DevOps-Teams von selbstsignierten- und Wildcard-Zertifikaten Abstand nehmen sollten
Gastbeitrag von Hari Nair , Direktor Produktmanagement und Jens Sabitzer , Technical Engineer bei Venafi
Aktuell haben DevOps-Teams wirklich mehr als alle Hände voll zu tun. Doch damit nicht genug – das Thema Verschlüsselung fordert ebenfalls ihre Aufmerksamkeit.
Kryptographische Schlüssel und signierte Zertifikaten sorgen für eine sichere Kommunikation. Allerdings erfreut sich Verschlüsselung innerhalb von DevOp-Teams nicht gerade einer großen Beliebtheit. Schuld daran ist der Zeitfaktor.
Für die Anwendungsentwicklung bleibt vielfach nur ein enger zeitlicher Rahmen. Sich ein digitales, signiertes Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle ausstellen zu lassen, zieht sich fast immer in die Länge und bremst die gesamte Anwendungsentwicklung aus. Deshalb gehen viele Entwickler den sprichwörtlichen Weg des geringsten Widerstands und greifen auf sogenannte selbst-signierte Zertifikate zurück. In diesem Zusammenhang richten sie eine interne Zertifizierungsstelle ein. Allerdings beschwören sie damit ein Sicherheitsrisiko herauf, das viele übersehen.
Let’s Encrypt
Mit Let’s Encrypt steht eine kostenlose und frei zugängliche Alternative zur Verfügung, die zwar keine Extended-Zertifikate ausstellt, (vollständig grüne Browserleiste, vergleichbar mit dem von Let’s Encrypt zur Verfügung gestellten grauen Schloss) somit eignen sich diese „Domain Validation“-Zertifikate nicht für sämtliche Einsatzzwecke.
Die durch Let’s Encrypt zur Verfügung gestellten Zertifikate benötigen keine Überprüfung der Identität des Antragstellers, es findet lediglich eine automatisierte Prüfung statt, die nur die Kontrolle über das System zu einem bestimmten Zeitpunkt überprüft. Ein Beispiel was dabei schiefgehen kann, ist GoDaddy bei dieser Zertifizierungsstelle mussten aufgrund eines Fehlers in der Domain Validation 9.000 Zertifikate zurückgerufen werden.
Wenn die Schlüssel und Zertifikate, die von DevOps-Teams eingesetzt werden, nicht vernünftig verwaltet und regelmäßig überprüft werden, sind Cyberkriminelle in der Lage Schlüssel und Zertifikate zu nutzen, um ihre eigenen verschlüsselten Tunnel aufzubauen. Angreifer könnten auch Schlüssel nutzen, um in ein Netzwerk einzudringen, sich einen eigenen privilegierten Zugang zu ermöglichen, Malware zu installieren und große Mengen an sensiblen Unternehmens-Daten heraus zu schleusen, ohne, dass sie dabei detektiert werden. Wenn nur selbst-signierte Zertifikate verwendet werden, ist es nicht möglich festzustellen, welche wirklich von dem Unternehmen und welche von den Angreifern stammen.
Wildcard-Zertifikate als „Freifahrtschein“
Wesentlich schlimmer kommt es im Zusammenhang mit der Nutzung sogenannter Wildcard-Zertifikate. Dahinter verbirgt sich ein Art „Generalschlüssel“, der für eine ganze Reihe von Subdomains passt. Wenn Cyber-Kriminelle ein System infiltrieren, erhalten Sie Zugriff auf den Schlüssel welcher auf unzähligen weiteren Domains verwendet wird und können sogar selbst eigene Subdomains erstellen – alles mithilfe desselben Wildcard-Zertifikats. Weiterhin ermöglicht dieser Schlüssel das Mitlesen sämtlicher Kommunikation aller Systeme bei denen dieses Wildcard Zertifikat verwendet wird. Dadurch werden auch Man-in-the-Middle-Attacken ermöglicht. Zumeist bildet dies die Grundlage für die nächste Stufe des Angriffs z.B. (Spear)-Phishing.
Fazit
Egal ob selbst-signierte Zertifikate oder Wildcard-Zertifikate – beide setzen Unternehmen einer großen, zu allem Übel auch noch hausgemachten, Gefahr aus. Natürlich kostet die Beschaffung vertrauenswürdiger, signierter Zertifikate mehr Zeit, als eine kurzerhand selbstgebaute Version sofort zum Einsatz bringen zu können. Allerdings steht der Zeitaufwand keinesfalls im Verhältnis zum Imageschaden, den ein Angriff im Zusammenhang mit einem unsicheren Zertifikat hinterlasst. Welches Unternehmen möchte schon gern in Verbindung mit einer erfolgreichen Phishing-Attacke gebracht werden? Unternehmen sollten ihre DevOps Teams deshalb daraufhin anleiten, dass sie lediglich Zertifikate und Schlüssel von vertrauenswürdigen Zertifizierungsstellen für ihre Software-Entwicklung einsetzen. Darüber hinaus sollten Unternehmen in Lösungen investieren, mit deren Hilfe sich Zertifikate und Schlüssel automatisiert verwalten lassen.
