Los programadores conquistan la infraestructura de seguridad como serie de códigos, con componentes procedentes de fuentes no fiables.

Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrem Weg zur IaC-Sicherheit zu helfen.

Hast du die Herausforderungen gespielt? Was ist dein bisheriges Ergebnis? Bevor wir beginnen, schauen wir uns an, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:

Hast du noch etwas zu tun? Lesen Sie weiter:

Das anfällige Verhalten, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und Ressourcen bietet viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar ihren fertigen Code in Repositorys wie GitHub einzubringen, um von anderen verwendet zu werden, die Schwierigkeiten haben, ein Programm oder eine App richtig funktionieren zu lassen. Die Verwendung von abgeschlossenem Code zur Steuerung von Programmfunktionen erspart Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.

Die Verwendung von Codefragmenten aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein hohes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen eine der häufigsten Arten, mit denen sich sowohl größere als auch kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Sicherheitslücken versehentlich von ihren Urhebern verursacht. Es gab auch Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann geteilt, in der Hoffnung, Opfer zu verführen, die ihn dann in ihre Anwendungen einfügen.

Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?

Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung konfigurieren, die er gerade entwickelt. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, führen sie eine Google-Suche durch und finden jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Obwohl der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn einer neuen Anwendung hinzuzufügen. Dies kann in der Docker-Umgebung mit zwei Zeilen erfolgen:

FÜHREN SIE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Jetzt ruft das Docker-Image die Konfigurationsdatei des Drittanbieters dynamisch ab. Und selbst wenn die Datei getestet wurde und zu dem Zeitpunkt für in Ordnung befunden wurde, bedeutet die Tatsache, dass der Zeiger jetzt in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit besteht. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die gemeinsam genutzte Konfigurationsdatei die Anwendung anweisen, ganz anders als beabsichtigt zu arbeiten, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.

Eine bessere Möglichkeit, gemeinsam genutzte Ressourcen zu nutzen

Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher ausgeführt wird. Achten Sie bei der Bewertung von externem Code auf eine mögliche Verwendung darauf, Komponenten nur über sichere Links aus offiziellen Quellen zu beziehen. Und selbst dann sollten Sie niemals auf eine externe Quelle verlinken, um diesen Code abzurufen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte der genehmigte Code in eine sichere Bibliothek gebracht und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also so aussehen:

KOPIERE src/config/default-ssl.conf /etc/apache2/sites-available/

Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf einer lokalen Kopie dieser Dateien beruhen. Dadurch wird verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.

Zusätzlich zur Verwendung einer sicheren Codebibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um die Komponenten während des gesamten Softwarelebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mithilfe von Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Entfernen Sie abschließend alle ungenutzten oder unnötigen Abhängigkeiten und Funktionen, die mit dem externen Code mitspielen könnten.

Wenn Entwickler diese Schritte befolgen, können sie externe Ressourcen sicherer nutzen, ohne versehentlich Sicherheitslücken in ihren Anwendungen und ihrem Code zu verursachen.

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der IaC-Herausforderungen auf der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.