Blogs

  • Home
  • Blog
  • Herausforderungen der Image Supply Chain und Microservices

Herausforderungen der Image Supply Chain und Microservices

Einführung

Die Sicherheit der unternehmenseigenen IT-Infrastruktur gewinnt immer mehr an Bedeutung. Das Hauptaugenmerk liegt jedoch eher auf der Netzhärtung gegen externe Bedrohungen und weniger auf der Sicherheit der im Unternehmen eingesetzten Methoden und Software. Da immer mehr Unternehmen auf Microservices setzen, entstehen neue, derzeit noch zu sehr vernachlässigte Angriffsvektoren, die die mangelnde Sicherheit der von CRI verwendeten Images ausnutzen.

Dieser Artikel soll die umfassende Frage beantworten, welche Gefahren und Herausforderungen von einem Image ausgehen können, welche Hindernisse es bei der Absicherung der Schutzziele (CIA) gibt und wie diese überwunden werden können.

Wie Microservice zu einer großen Unsicherheit wird

Auf den ersten Blick ist die Beschaffung eines in einer Microservice-Umgebung zu verwendenden Images relativ einfach. Der erste Schritt besteht darin, festzustellen, welches Image für die vorgesehene Anwendung, z. B. einen Webserver, benötigt wird. Der nächste Schritt beinhaltet bereits eine Suche in einer umfangreichen Image Datenbank. Wird ein passendes Image gefunden, kann es heruntergeladen und direkt verwendet werden.
Wenn der oben beschriebene, zugegebenermaßen sehr lückenhafte Prozess dem von Ihnen verwendeten Verfahren ähnelt, ist es wahrscheinlich, dass Ihre Bilder große Sicherheitslücken aufweisen.

  • Stellen Sie sich vor, sie machen sich Ihr eigenes Image

Um das Sicherheitsrisiko zu minimieren, kehren wir zum allerersten Schritt zurück, der Bestimmung, welches Image benötigt wird. Handelt es sich nur um einen Webserver, wie im beschriebenen Fall, ist es sinnvoll, das Image selbst zu erstellen, um die verwendeten Artefakte und deren Versionen bestimmen zu können und eventuelle Sicherheitslücken bereits bei der Erstellung des Images zu schließen.
Natürlich ist es Ihnen ebenso klar wie mir, dass es mühsam ist, ein Image selbst zu erstellen. Aber es gibt einige Vorteile, die für diesen Weg sprechen, so können Sie sicherstellen, dass nur die nötigsten Pakete installiert werden. Das kann eine Menge Zeit und Platz sparen, vor allem wenn der betreffende Container hochskaliert wird. Ein weiterer großer Punkt ist die Frage des Vertrauens, natürlich kann man eine Konfigurationsdatei an vielen Stellen einsehen, aber wer garantiert, dass es sich wirklich um die richtige Datei handelt und dass niemand etwas verändert hat? Sobald man diese Vertrauensfrage stellt, ist man jedoch gezwungen, weiterzugehen, der nächste Schritt in dieser Sequenz ist leider: "Vertraue ich dem Basis-Image?
Natürlich werden viele Basisbilder von der offiziellen Website zur Verfügung gestellt, und in kleinerem Maßstab ist dies im Hinblick auf die Risikobewertung in den meisten Fällen ausreichend, vorausgesetzt natürlich, man vertraut der offiziellen Website. In größerem Maßstab kann es jedoch sinnvoll sein, zumindest einmal ein eigenes Basisbild zu erstellen, um wirklich die volle Kontrolle zu behalten. In manchen Anwendungsbereichen kann man nur seinem eigenen Unternehmen vollständig vertrauen. Wenn Sie die Artefakte selbst erstellen wollen, müssen Sie sich mit der Verifizierung der Artefakte befassen. Hier ist die Verwendung von Hash-Werten ratsam.
PGP-Schlüssel sind eine gute Möglichkeit, dies zu tun. Sie haben gegenüber anderen Hashes den Vorteil, dass die entsprechenden Schlüssel online gespeichert werden und somit doppelte Sicherheit gegen Angreifer bieten.

  • Images sind wie eine Schachtel Pralinen, man weiß nie, was man bekommt.

Wenn die Erstellung eines eigenen Images doch nicht in Frage kommt, weil entweder die Einrichtung des gewünschten Dienstes zu komplex und/oder zeitaufwendig ist, müssen natürlich auch bereits fertige Images zur Verfügung stehen, denn man will ja nicht ständig das Rad im Unternehmen neu erfinden. Außerdem sind einige Ressourcen überhaupt nicht verfügbar, entweder weil die Einrichtung des Images nicht wirklich dokumentiert ist oder der Dienst nicht Open Source ist.
Allerdings kommt es bei der Beschaffung dieser fertigen Images zu vielen sicherheitsrelevanten Unsicherheiten, so dass Sie sich die Frage stellen müssen: "Vertraue ich dem Urheber des Bildes? Wenn Sie die Frage mit nein beantworten, haben Sie drei Möglichkeiten. Die erste Möglichkeit ist, ein anderes Image eines Autors zu finden, dem Sie vertrauen können, dazu später mehr. Die nächste Möglichkeit wäre, den Inhalt des fraglichen Images "von Hand" zu überprüfen, aber das kann sich als große Herausforderung erweisen, insbesondere bei größeren und komplexeren Bildern, die viele Abhängigkeiten zu verschiedenen Bibliotheken aufweisen. Diese Möglichkeit besteht nur unter der Voraussetzung, dass der Autor auch Quellen für sein Bild zur Verfügung gestellt hat. Die dritte Möglichkeit ist dann die eigenständige Erstellung des Bildes wie oben beschrieben.
Wenn Sie die Frage, ob Sie dem Autor des Images vertrauen, mit Ja beantworten können, müssen Sie sich immer bewusst sein, dass Sie eine Vertrauenskette eingehen. Denn dadurch, dass Sie dem Urheber vertrauen, müssen Sie unweigerlich jedem Vertrauen entgegenbringen, das vom Urheber Vertrauen entgegengebracht wurde.

  • Imageverifikation

Wenn ein Image gefunden wurde, dessen Autor vertrauenswürdig genug ist und dessen Quellen gründlich überprüft wurden, besteht der nächste Schritt darin, zu prüfen, ob das erhaltene Image wirklich dem zuvor geprüften Image entspricht.
Natürlich wäre es jetzt einfach, wenn man das gefundene Bild direkt herunterladen könnte, indem man den Namen des gewünschten Bildes und den entsprechenden Tag angibt. Dies könnte jedoch zu weiteren Komplikationen führen, auf die der Autor dieses Mal keine direkte Kontrolle haben muss. Es ist nicht möglich, den Inhalt des durch ein Tag beschriebenen Images zu identifizieren, und die Referenz des Tags kann jederzeit durch ein anderes Image überschrieben werden. Daher kann die Kontrolle über die Auswahl der verwendeten Images nicht gewährleistet werden, da die Tags sowohl bewusst als auch unbewusst geändert werden können.
Um die gewünschte Version und damit die Qualität der verwendeten Images beibehalten zu können, sollten Referenzen immer mit Digests angegeben werden, da diese eindeutig auf den gewünschten Inhalt verweisen und nicht überschrieben werden können.
Neben der Gefahr der Verwendung eines Tags, dessen Referenz bereits überschrieben wurde, gibt es natürlich auch Angreifer, die ein Interesse daran haben, falsche Images einzuschleusen. Um dieser Gefahr zu begegnen, ist die Verwendung von Hash-Werten, wie in fast allen Bereichen der Verifizierung, eine gute Idee.

  • Schatz, hast du den Müll raus gebracht?

Nachdem die Image-Erstellung in irgendeiner Weise abgeschlossen ist, stellt sich die Frage, wo das Image gespeichert werden soll, damit es immer schnell und einfach in der entsprechenden Umgebung eingesetzt werden kann.
Für diesen speziellen Anwendungsfall wird die Container-Registry verwendet. Diese ist sehr flexibel und kann auch über einen eigenen Container abgebildet werden. Allerdings lassen komfortable Lösungen auch viele Sicherheitsaspekte außer Acht.
So sollte man der Container-Registry die gleichen Schutzziele zugestehen wie allen anderen wichtigen Daten. Zusätzlich empfiehlt es sich, neu hinzugefügte Images auf Malware zu überprüfen, bevor sie in die Registry aufgenommen werden. Unter anderem sollte die Registry immer aktualisiert und auf dem neuesten Stand gehalten werden, um sicherzustellen, dass alle relevanten Sicherheitsupdates eingespielt und neu entdeckte Sicherheitslücken geschlossen werden.
Nicht ganz außer Acht gelassen werden sollte auch das so genannte "House Keeping", also das regelmäßige Aussortieren von alten und nicht mehr verwendeten Images aus der Registry. Hier ist es wichtig, unnötige Redundanzen zu minimieren und im besten Fall zu vermeiden. Ein weiterer Vorteil einer aufgeräumten und sauberen Registry ist die Sicherstellung, dass keine alten Images mit bekannten Sicherheitslücken verfügbar bleiben. So könnte beispielsweise ein Angreifer, der aus dem Container ausbricht, ein altes und defektes Image nachladen und noch mehr Schaden anrichten.

Fazit

Abschließend bleibt nur die ernüchternde Erkenntnis, dass wir uns in dem Moment, in dem wir die Frage nach dem Vertrauen stellen, in ein Rabbit Hole begeben. In Zukunft wird jeder für sich selbst entscheiden müssen, wo er die Grenze ziehen will. Vor allem, wenn man sich bewusst ist, dass mangelndes Vertrauen immer zu mehr investierter Zeit und Kosten führt. Deshalb werden Vertrauensketten in Zukunft immer wichtiger werden und der Markt wird darauf reagieren müssen.

Sie haben Fragen?

Wenn Sie Fragen haben, die noch nicht beantwortet sind, können Sie sich gerne an uns wenden.

Wir freuen uns auf den Kontakt mit Ihnen!

Design Escapes

KubeOps GmbH
Hinter Stöck 17
72406 Bisingen
Germany

  • Telefon:

    +49 7433 93724 90

  • Mail:

    Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.

Downloadbereich
Zertifiziert als:

Die KubeOps GmbH ist Inhaberin der Unionsmarke KubeOps mit der Registrierungsnummer 018305184.

©KubeOps GmbH. Alle Rechte vorbehalten. Tochtergesellschaft der