Docker, Red Hat und andere Container-Anbieter setzen alles daran, ihre Container-Techniken auf dem Markt als sicher anzupreisen. Mit der Freigabe der Docker Engine 1.10 kommt Docker den Anforderungen der Benutzer nach wichtigen zusätzlichen Sicherheits-Features nach. So ist es jetzt möglich, jedem Container angemessene Gruppenrechte zuzuweisen und eine Trennung zwischen den routinemäßigen Container-Operationen und den Root-Rechten auf dem Serverhost vorzunehmen.

Ein weiteres Security-Feature der neuen Docker Engine ermöglicht den Betrieb von Seccomp - also den Secure Computing Mode - mit einem gegebenen Container und dem Linux-Kernel. Beliebige System Calls an den Kernel sind damit jetzt ausgeschlossen. Stattdessen wird eine Menge an geeigneten Calls definiert. Das Betriebssystem blockiert alle Calls, die diesem Profil nicht entsprechen.

Doch dies sind nur einige Aspekte der Container-Sicherheit. Schließlich muss auch gewährleistet sein, dass der dem gesamten Image zugrundeliegende Code keine Schwachstellen aufweist. Bleiben Unternehmen untätig, wenn es um Sicherheitslücken in ihren Software-Stacks und Anwendungsportfolios geht, greifen auch die übrigen Maßnahmen zu kurz. Ohne eine strenge Kontrolle des Open-Source-Codes bewirken die genannten Sicherheitsfeatures lediglich, dass Docker-Images genau die gleichen Bits enthalten, die von den Entwicklern ursprünglich dort eingestellt wurden - mit allen Schwachstellen in den Open-Source-Komponenten.

Docker und Co: Was steckt in Ihrem Container?

Es führt kein Weg an einer bewussten und fundierten Auswahl von Open-Source-Technologien vorbei. Ähnliches gilt für die Sorgfalt von Anwendern und Integratoren beim Nutzen von quelloffenem Code sowie für die fortlaufende Codewartung. Nur wer seinen Code wirklich kennt, kann ihn zuverlässig verwalten. Doch das setzt Transparenz und Einblick voraus.

Einblick in den Code zu haben, der sich in den Containern befindet, ist für die Sicherheit der Container unerlässlich. Laufend werden neue Schwachstellen entdeckt, die ältere Versionen von Open-Source-Komponenten betreffen. Daher sollte man schon frühzeitig in der Build- und Deployment-Phase wissen, dass der Container keine Sicherheitslücken enthält. Doch das allein reicht nicht aus. Die Absicherung der Container-Inhalte ist vergleichbar mit allen anderen Fragen zur Sicherheit von Software-Stacks. Doch wann und wie erhält man während und nach der Entwicklung Einblick in einen Container?

Ob ein Container ein Sicherheitsrisiko ist, hängt von der Sensibilität der Daten ab, auf die der Zugriff aus dem Container erfolgt, aber auch vom Ort, an dem der Container bereitgestellt wird: beispielsweise hinter einer Firewall oder nach außen mit dem Internet verbunden.

Mit dem Internet verbundene Web- und Cloud-Anwendungen sind begehrte Ziele für Cyberkriminelle und unterliegen dem größten Angriffsrisiko. Ein öffentlich zugängliches System wird immer einer Vielzahl von Angriffen ausgesetzt sein, wie beispielsweise Cross-Scripting, SQL Injection und Denial-of-Service. Angesichts der weitverbreiteten Open-Source-Frameworks und anderer Cloud- und Web-Anwendungskomponenten kommt der Beseitigung von Sicherheitslücken in diesen Systemen große Bedeutung zu.

Sicherheitslücken in Open-Source-Software

Open Source Software hat sich von einer Randerscheinung zu einem wichtigen Thema der Softwareentwicklung gemausert. Wer als IT- und Sicherheitsverantwortlicher die Integrität des intern entwickelten Codes oder des aus externen Open Source Repositories stammenden Codes gewährleisten will, muss Einblick in die Quellen, Ursprünge und Brauchbarkeit jeder Codezeile haben. Angesichts der Vielzahl der Quellen, aus denen Code heute in Anwendungen integriert wird, dürfte diese Aufgabe zunehmend schwieriger werden. Kostspielige und spektakuläre Sicherheitslücken - wie beispielsweise Heartbleed, Ghost, Freak - haben das deutlich gemacht.

Die Liste der Sicherheitslücken ist lang:

• Ein Beispiel ist eine SQL-Injection-Schwachstelle im Content-Management-System Joomla, das auf fast drei Millionen Websites weltweit läuft. Angreifer konnten sich darüber als Administratoren ausgeben und die Kontrolle der Website übernehmen, um dann weitere Angriffe durchzuführen.

• Weitere Schwachstellen wurden im Xen Hypervisor entdeckt, der in vielen Cloud-Umgebungen zur Server-Virtualisierung eingesetzt wird. Eine davon war der sogenannte Venom-Bug , mit dem aus einer virtuellen Maschine heraus Übergriffe auf andere virtuelle Maschinen des Servers möglich sind. Venom kann auch andere Hypervisoren schädigen, die den QEMU-Code (Quick Emulator) nutzen.

• Eine Schwachstelle im Multimedia-Framework des Betriebssystems Android, die 950 Millionen Geräte betraf, ermöglichte Angreifern die transparente Kontrolle der Geräte, ohne dass Benutzer oder Betreiber davon etwas merkten. Mit der als Stagefright bekannten Sicherheitslücke konnte der Media Player mit Rechten ausgestattet werden, über die er auf speziell präparierte Dateien zugreifen und bösartige Programme ausführen konnte.

Bremsen Sicherheitsbedenken Container aus?

Unternehmen erwarten von Containern handfeste Vorteile: bessere Skalierbarkeit der Anwendungen, weniger Deployment-Fehler, schnellere Markteinführungszeit und einfachere Anwendungsverwaltung. Ähnlich wie Open Source aus der Nische ins Zentrum der Unternehmens-IT vorgedrungen ist, haben sich auch Container zu einem ernstzunehmenden Thema entwickelt. Und auch hier stellt sich die Frage, ob Sicherheitsbedenken die weitere Verbreitung von Containern ausbremsen werden.

Branchenfachleute beurteilen die Lage unterschiedlich. Dave Bartoletti von Forrester Research ist davon überzeugt, dass Sicherheitsbedenken der weiteren Verbreitung von Containern nicht entgegenstehen. Er sieht Parallelen zum Siegeszug der Virtualisierungstechnologien, auch unter Sicherheitsaspekten.

Anders beurteilt Adrian Sanabria von 451 Research die Entwicklung: "Sicherheit hat heute einen hohen Stellenwert. Bestimmte Unternehmen werden keine Container einsetzen, solange bestimmte Standards nicht vorhanden sind". Eine von Red Hat im Januar 2015 durchgeführte Befragung von 194 IT-Unternehmen und Entscheidern in den Wirtschaftsräumen APAC, EMEA und Nordamerika ergab, dass für 53 Prozent der Befragten Sicherheit beim Einsatz von Containern an erster Stelle steht.

Unternehmen, die diese Bedenken ausräumen wollen, sind gut beraten, automatisierte Werkzeuge einzusetzen, um Transparenz und Kontrolle über alle Elemente ihrer Software-Infrastruktur zu erhalten - einschließlich der Container.

Warum eine rigide Open-Source-Hygiene wichtig ist

Angesichts der Vielzahl an Sicherheitslücken wird die Open-Source-Hygiene zu einem wesentlichen Bestandteil einer wirksamen Strategie zur Steigerung der Anwendungssicherheit. So wie die körperliche Hygiene die Neutralisierung von Infektionsquellen umfasst, gehört es zur Open-Source-Hygiene, keinen Code mit Sicherheitslücken in Software-Stacks und Anwendungsportfolios zu dulden. Dies ist für Container ebenso wichtig wie für jedes andere Element eines Software-Stacks.

Keine Software ist frei von Schwachstellen, Open-Source-Programme bilden hier keine Ausnahme. Das Erkennen und Beheben von Sicherheitslücken im Code wird zunehmend als obligatorisch erkannt und ist zentraler Bestandteil einer wirksamen Strategie zur Anwendungssicherheit. Für viele Unternehmen und Institutionen ist die Anwendungssicherheit heute enger denn je mit der Container-Sicherheit verbunden.

Zur Entwicklung einer durchgängigen Sicherheitsstrategie für Open-Source-Code stehen zahlreiche Werkzeuge zur Verfügung. Mit ihnen lässt sich der gesamte Bestand in Softwareportfolios katalogisieren. Das gilt für komplette Plattformen wie Linux, Android und Hadoop ebenso wie für einzelne Code-Komponenten bis hin zu Code-Schnipseln, die in den intern entwickelten Anwendungscode eingefügt werden.

Diese Scanning-Werkzeuge lassen sich nach Bedarf einsetzen oder können in den Entwicklungs-Workflow integriert werden. Sie liefern wichtige Informationen, ohne die Entwicklung zu bremsen und die Markteinführungszeit zu verlängern.

Nur mit robusten Prozessen lassen sich am Ende folgende wichtige Fragen beantworten:

• Welche Open-Source-Software befindet sich in einer Anwendung oder wird zusammen mit dieser eingesetzt?

• Wo genau befindet sich die Open-Source-Software in den Systemarchitekturen und in den Build Trees?

• Weist der Code bekannte Schwachstellen auf

• Wie sieht das Risikoprofil für den Open-Source-Code aus?