Altern wie Milch, nicht wie Wein: Die Realität der Containersicherheit

Einfach gesagt: Container altern wie Milch, nicht wie Wein. Milch ist eine Schlüsselkomponente beim Kochen. Wenn die Milch sauer oder schlecht ist, dann wird es auch das zubereitete Gericht. Das Gleiche gilt für Container, zumal sie als Schlüsselkomponenten für Produktionssysteme angesehen werden. Ein abgestandener oder "gesäuerter" Container könnte einen ansonsten vielversprechenden Einsatz ruinieren.

Obsolete Container sind okay

In komplexen IT-Umgebungen von Unternehmen ist ein System nur so sicher wie sein schwächstes Glied, was bedeutet, dass ein veralteter Container zum Sprungbrett für böswillige Akteure werden könnte, um geschäftskritische Prozesse zum Erliegen zu bringen, Daten zu stehlen oder Schlimmeres. Die Frage wird dann lauten: Wie verjünge ich meine veralteten Container? Die Antwort ist erschreckend einfach. Gar nicht. Die Überalterung eines Containers ist unvermeidlich und muss anders angegangen werden.

Der Betrieb von containerisierten Anwendungen muss berücksichtigen, dass Container-Images unveränderlich und somit nicht dazu bestimmt sind, langfristig gepflegt zu werden; sie dienen einem bestimmten Zweck, und wenn dieser Zweck erreicht ist oder der Container diesen nicht mehr erfüllt, werden sie durch eine neue Version ersetzt. Neue Container mit aktualisierten Parametern werden eingeführt, um dem sich verändernden Software-Ökosystem besser gerecht zu werden.

Es ist wichtig, containerisierte Workloads als Fliessbandarbeit zu betrachten – diejenigen, die veraltet oder in irgendeiner Weise "auffällig" sind, werden laufend aussortiert und ersetzt. Linux-Container sind zwar von Natur aus Open Source, aber sie sind nicht ohne Weiteres durchschaubar; ein Mangel an Metadaten und unterstützenden Technologien rund um containerisierte Anwendungen können ihr Innenleben und vor allem das Alter aller darin enthaltenen Komponenten leicht verschleiern, was im Bereich von IT-Sicherheit schnell gefährlich werden kann.

Container: altbekannt oder Hype? Mehr zum Thema erfahren Sie hier.

Containersicherheit: Es ist ein Ökosystem, kein Job

Eine funktionale Containersicherheit erfordert, dass das Ökosystem ineinandergreift. Im ersten Schritt muss der Container unter Berücksichtigung der entsprechenden Sicherheitsvorkehrungen gebaut werden. Anschliessend muss der Entwickler oder Hersteller, der die containerisierte Applikation erstellt, die notwendigen Massnahmen für eine schadstellenfreie Anwendung ergreifen, und zwar fortlaufend, immer wieder – "continuous".

Wenn die Applikation zur Bereitstellung an das Operations-Team übergeben wird, muss es die entsprechenden Sicherheitskontrollen aktivieren. Ein Container-Stack ist nur so sicher wie sein schwächstes Element. Operations- und Sicherheitsteams müssen Ankündigungen von Fehlern und Schwachstellen beobachten und beurteilen, ob und welche ihrer containerisierten Anwendungen gefährdet sind. Wenn sie gefährdete Container finden, dann wiederholt sich der Zyklus der Herstellung und Bereitstellung, mit neu erstellten – somit gepatchten – containerisierten Anwendungen, um das Problem zu entschärfen.

Einfach ausgedrückt, ist es Aufgabe des Containerlieferanten (egal ob externer ISV oder interner Entwicklungsbetrieb) und nicht der Endbenutzer, Sicherheits-Updates kontinuierlich und häufig einzubinden. Plattform-­Hersteller unterstützen hier mit ihren Angeboten für ­Container-Zertifizierung und automatisierten Services für die fortlaufende Qualitätssicherung und Patch-Automa­tisierung.