Code Signing bei der Softwareentwicklung 6 Dont's bei Nutzung digitaler Zertfikate

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Venafi Inc.

Jeder Webdienst und jede Webseite sollte HTTPS verwenden. Die sichere Beschaffung und Bereitstellung der für die Absicherung von Webdiensten erforderlichen Zertifikate ist jedoch eine Herausforderung, insbesondere für Entwickler.

Für Entwickler gibt es schlichtweg keine einfache Möglichkeit, digitale Zertifikate so anzufordern, dass sie den Unternehmensrichtlinien entsprechen. Entwickler müssen wissen, wo sich die interne Zertifizierungsstelle (CA) befindet, dann muss ihnen der Zugriff darauf gewährt werden und sie müssen die entsprechenden Berechtigungsnachweise zur Authentifizierung besitzen.

Sobald sie diese Hürden überwunden haben, müssen sie wissen, wie sie ein Zertifikat mit den richtigen Eigenschaften anfordern können, einschließlich der Frage, wer es verwendet, wofür es verwendet wird und wie lange es gültig sein soll. All diese Verzögerungen werden Entwickler dazu verleiten, die Sicherheit zu umgehen, um ihre SLAs zu erfüllen.

Im Folgenden werden sechs gefährliche Möglichkeiten beschrieben, was Entwickler in der Praxis tun, um an digitale Zertifikate zu kommen:

1. Keine Verwendung von TLS/SSL zur Absicherung von Verbindungen

Wenn ein Großteil des DevOps-Prozesses automatisiert ist, werden manuelle Zertifikatsprozesse den Arbeitsablauf stören – etwas, was Entwickler lieber vermeiden würden. Tatsächlich finden es viele Entwickler einfacher, Zertifikate zu ignorieren als zuzulassen, dass die Sicherheit die Veröffentlichung verzögert. Die Bereitstellung von Webdiensten ohne HTTPS-Sicherung macht Endbenutzer verwundbar.

2. Eigene Zertifizierungsstellen einrichten

Selbst wenn Unternehmen Zertifikate verwenden und bereitstellen würden, suchen Entwickler oft nach Abkürzungen, um die normalerweise mühsamen Sicherheitsprozesse zu vereinfachen. Sie brauchen nicht weiter zu suchen als bis zu ihren DevOps-Plattformen, die ein Skript oder Anweisungen zur Verfügung stellen, die es Entwicklern erlauben, ihre eigene interne CA einzurichten. Auf diese Weise können Entwickler so viele Zertifikate ausstellen, wie sie benötigen, und zwar so schnell, wie sie diese benötigen.

Die Herausforderung besteht darin, dass diese Test-Zertifikate nicht immer durch unternehmenskonforme Zertifikate ersetzt werden, wenn die Anwendung in Produktion geht. Wenn das passiert, wird das betroffenen Unternehmen die Suche und den Austausch dieser Zertifikate bei deren Auslaufen deutlich erschweren und Angreifern das Eindringen erleichtern.

3. Einführung selbstsignierter Zertifikate

Unternehmen und besonders Security-Abteilungen sollten auch darauf achten, wie internen Entwickler selbstsignierte Zertifikate verwenden. Anstatt CA-Zertifikate zu kaufen, können Entwickler eine Open-Source-Implementierung von SSL und TLS namens OpenSSL herunterladen. Sie können dann die Zertifikate erstellen, die sie benötigen, um Software zu entwickeln und zu testen.

Wenn diese selbstsignierten Zertifikate in Produktionsversionen von Anwendungen verwendet werden, gefährden sie das Unternehmen. Wenn sie nicht ordnungsgemäß überwacht werden, können selbstsignierte Zertifikate es Cyberkriminellen ermöglichen, Man-in-the-Middle-Angriffe durchzuführen, die sich als Bank-, E-Commerce- und Social Media-Webseite ausgeben.

4. Erstellen von Zertifikaten mit schwachen Signatur-Algorithmen

Die Ablehnung oder schlechte Implementierung von Schlüsseln und Zertifikaten setzt Unternehmen nicht nur unnötigen Sicherheitslücken aus, sondern kann auch zu Chaos führen, indem inkonsistente, manuelle Schritte in eine zunehmend automatisierte Umgebung eingefügt werden.

Wenn die Kontrolle über die Sicherheit der Zertifikate nicht aufrechterhalten wird, können Angreifern leichter ein kompromittiertes, gestohlenes oder gefälschtes Zertifikat verwenden, um die Infrastruktur zu imitieren, abzuhören und zu überwachen und sogar die Kommunikationen entschlüsseln.

5. Umgehung oder völlige Ignorierung von Sicherheitsrichtlinien

Schließlich sind Entwickler in der Regel keine Sicherheitsexperten, und das wollen die meisten auch gar nicht sein. Es ist weniger wahrscheinlich, dass sie alles andere als die grundlegendsten Sicherheitsmaßnahmen in Betracht ziehen, um ihre Ziele zu erreichen, insbesondere angesichts früherer Kämpfe mit der fehleranfälligen manuellen Natur der Zertifikatsbereitstellung.

Das Ergebnis ist, dass Sicherheitsrichtlinien entweder vollständig ignoriert oder minimiert werden, um die Geschwindigkeit der DevOps aufrechtzuerhalten. Dieses Versehen kann blinde Flecken schaffen, die es Cyberkriminellen ermöglichen, sich in verschlüsselten Tunneln zu verstecken.

Die Geschwindigkeit der DevOps muss nicht auf Kosten der Sicherheit gehen. Es gibt Möglichkeiten, den Prozess der Beschaffung von Schlüsseln und Zertifikaten als Teil einer End-to-End-DevOps-Umgebung zu zentralisieren, zu standardisieren und zu automatisieren. Durch die Automatisierung des Zertifikatserwerbs können DevOps-Teams Anwendungen und IT-Dienste effektiver und sicherer bereitstellen.

6. Umgehung traditioneller Code-Signing-Richtlinien

Traditionelle Code-Signierungsprozesse, die von InfoSec-Teams eingerichtet wurden, passen möglicherweise nicht gut zu den CI/CD-Entwicklungspipelines von DevOps. Sie können manuellen Aufwand erfordern, Tage (oder länger!) in Anspruch nehmen, nicht automatisierbar sein, etc. Bedeutet dies, dass DevOps Teams das Code Signing ihrer Apps einstellen?

Eher nicht. Stattdessen finden sie vielleicht Wege, um laufende Prozesse zu umgehen. Dies könnte bedeuten, dass sie ihre eigenen Code Signing-Zertifikate erhalten (die möglicherweise nicht den InfoSec-Richtlinien-Standards entsprechen) oder dass sie private Code Signing-Schlüssel ohne angemessenen Schutz auf einem Build-Server speichern.

Jede dieser Praktiken birgt ein erhebliches Risiko für das gesamte Unternehmen. Der Ruf eines Unternehmens hängt von der Tatsache ab, dass deren Kunden darauf vertrauen können, dass die Anwendungen sicher sind und dass keine Malware von Dritten in sie eingefügt wurde. Mit schlechten Code Signing-Richtlinien oder unsicherer Speicherung von privaten Code Signing-Schlüsseln können Cyberkriminelle dies leicht umgehen.

Fazit

Die Geschwindigkeit von DevOps muss nicht auf Kosten der Sicherheit gehen. Es gibt Möglichkeiten, den Prozess der Beschaffung von Schlüsseln und Zertifikaten als Teil der End-to-End-DevOps-Umgebung zu zentralisieren, zu standardisieren und zu automatisieren.

Durch die Automatisierung des Zertifikatserwerbs können die DevOps-Teams Anwendungen und IT-Dienste effektiver und sicherer bereitstellen. Dazu müssen DevOps-Praktiker jedoch verstehen, dass sie eine wichtige Mitverantwortung für die Sicherheit tragen; es ist nicht nur die Aufgabe eines anderen.

* Eddie Glenn ist Senior Threat Intelligence Manager bei Venafi.

(ID:46675248)