© istockphoto.com/Alex_Doubovitsky.
PHP Magazin
Die Deep Container Inspection im Fokus

Vertrauen ist gut, Kontrolle ist besser

Container gehören bei der Paketierung und Bereitstellung von Applikationen mittlerweile zum Mainstream. Eine Herausforderung beim Einsatz in Unternehmen bleibt aber die Containersicherheit. Hier setzt Deep Container Inspection (DCI) an. Sie sorgt dafür, dass Unternehmen ausschließlich vertrauenswürdige Containerimages in ihren Businessanwendungen nutzen.

Scott McCarty


Linux-Container bieten gewichtige Vorteile für Unternehmen: Sie vereinfachen und beschleunigen die Entwicklung und Verteilung neuer Anwendungen, da sie diese mit allen benötigten Komponenten in einem Paket kapseln und isolieren. Sie arbeiten ressourcensparend, weil sie kein eigenes Gastbetriebssystem mit zusätzlichen Bibliotheken benötigen, sondern sich direkt auf dem Hostbetriebssystem ausführen lassen. Zudem schaffen sie eine konsistente Betriebssystemumgebung für Entwicklung, Test und Betrieb von Anwendungen. Kein Wunder also, dass Container sich zu einer Mainstreamtechnologie entwickelt haben.

Nach Einschätzung von Red Hat ist die Containersicherheit eine der größten Herausforderungen. Einen Beleg dafür liefert eine Studie des IT-Marktforschers BanyanOps [1], der zufolge mehr als 30 Prozent der offiziellen Images im Docker Hub, dem zentralen Registry der Containerplattform Docker, Sicherheitslücken von hoher Priorität aufweisen und entsprechend verwundbar sind.

Aktuelles Vertrauensmodell birgt Schwächen

Eine Ursache dieser Schwachstellen bildet das aktuelle „Vertrauensmodell“. Bei der Verteilung von Container­images lassen sich zwei Akteure unterscheiden: Registry-Server und Containerhosts. Registry-Server verteilen die Images, Containerhosts cachen und betreiben sie. Der Transfer eines Images vom Registry-Server zum Containerhost geschieht meist via https-Protokoll, um den sicheren Transport über ein möglicherweise nicht vertrauenswürdiges Netzwerk sicherzustellen.

Dieser Transfer basiert auf einem so genannten „Kreis des Vertrauens“ [2]: Jeder Akteur in der Software Supply Chain [3] bestimmt dabei selbst, ob er dem vorgeschalteten Lieferanten vertraut. Administratoren können beispielsweise mithilfe eines Registry-Servers, der über Kontrollfunktionen wie Red Hat Satellite 6.1 mit Docker-Plug-in [4] verfügt, entscheiden, ob sie die Inhalte eines Container­images in ihrem Netzwerk zulassen.

Allerdings können Details wie das Alter oder die Version des Containers im Rahmen dieses Vertrauensmodells intransparent bleiben. Das heißt, der Anwender erkennt nicht, ob ein Containerimage noch vertrauenswürdig oder anfällig für Sicherheitslücken ist, weil die entsprechenden Updates nicht eingespielt wurden. Auch der Betrieb von Anwendungen mit veralteten Konfigurations- oder Datenbankdaten kann erhebliche Probleme verursachen.

Zudem gibt es wenig aussagekräftige Informationen darüber, ob Nutzer der Instanz vertrauen können, die das Containerimage erzeugt hat. Tools...

PHP Magazin
Die Deep Container Inspection im Fokus

Vertrauen ist gut, Kontrolle ist besser

Container gehören bei der Paketierung und Bereitstellung von Applikationen mittlerweile zum Mainstream. Eine Herausforderung beim Einsatz in Unternehmen bleibt aber die Containersicherheit. Hier setzt Deep Container Inspection (DCI) an. Sie sorgt dafür, dass Unternehmen ausschließlich vertrauenswürdige Containerimages in ihren Businessanwendungen nutzen.

Scott McCarty


Linux-Container bieten gewichtige Vorteile für Unternehmen: Sie vereinfachen und beschleunigen die Entwicklung und Verteilung neuer Anwendungen, da sie diese mit allen benötigten Komponenten in einem Paket kapseln und isolieren. Sie arbeiten ressourcensparend, weil sie kein eigenes Gastbetriebssystem mit zusätzlichen Bibliotheken benötigen, sondern sich direkt auf dem Hostbetriebssystem ausführen lassen. Zudem schaffen sie eine konsistente Betriebssystemumgebung für Entwicklung, Test und Betrieb von Anwendungen. Kein Wunder also, dass Container sich zu einer Mainstreamtechnologie entwickelt haben.

Nach Einschätzung von Red Hat ist die Containersicherheit eine der größten Herausforderungen. Einen Beleg dafür liefert eine Studie des IT-Marktforschers BanyanOps [1], der zufolge mehr als 30 Prozent der offiziellen Images im Docker Hub, dem zentralen Registry der Containerplattform Docker, Sicherheitslücken von hoher Priorität aufweisen und entsprechend verwundbar sind.

Aktuelles Vertrauensmodell birgt Schwächen

Eine Ursache dieser Schwachstellen bildet das aktuelle „Vertrauensmodell“. Bei der Verteilung von Container­images lassen sich zwei Akteure unterscheiden: Registry-Server und Containerhosts. Registry-Server verteilen die Images, Containerhosts cachen und betreiben sie. Der Transfer eines Images vom Registry-Server zum Containerhost geschieht meist via https-Protokoll, um den sicheren Transport über ein möglicherweise nicht vertrauenswürdiges Netzwerk sicherzustellen.

Dieser Transfer basiert auf einem so genannten „Kreis des Vertrauens“ [2]: Jeder Akteur in der Software Supply Chain [3] bestimmt dabei selbst, ob er dem vorgeschalteten Lieferanten vertraut. Administratoren können beispielsweise mithilfe eines Registry-Servers, der über Kontrollfunktionen wie Red Hat Satellite 6.1 mit Docker-Plug-in [4] verfügt, entscheiden, ob sie die Inhalte eines Container­images in ihrem Netzwerk zulassen.

Allerdings können Details wie das Alter oder die Version des Containers im Rahmen dieses Vertrauensmodells intransparent bleiben. Das heißt, der Anwender erkennt nicht, ob ein Containerimage noch vertrauenswürdig oder anfällig für Sicherheitslücken ist, weil die entsprechenden Updates nicht eingespielt wurden. Auch der Betrieb von Anwendungen mit veralteten Konfigurations- oder Datenbankdaten kann erhebliche Probleme verursachen.

Zudem gibt es wenig aussagekräftige Informationen darüber, ob Nutzer der Instanz vertrauen können, die das Containerimage erzeugt hat. Tools...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang