kalafoto - Fotolia
Container-Sicherheit: Die Risiken von Image Repositories
Immer mehr Unternehmen setzen Container für ihre Entwicklung und tägliche Arbeit ein. Dabei stammen viele dieser Container aus unsicheren Quellen, ein Risiko für die IT Security.
Das starke Wachstum der Cloud hat auch zu einem Anstieg bei der Nutzung von Containern und von so genannten Container Image Repositories geführt. Aber geht von diesen Bezugsquellen für Container Images nicht das gleiche Risiko aus wie von Code Repositories bei GitHub? Vieles spricht dafür, dass die Antwort auf diese Frage „Ja“ lautet.
Anders als bei GitHub haben Unternehmen viele Möglichkeiten, um auf die Sicherheit von Container Image Repositories Einfluss zu nehmen. Außerdem kommt es auf die Art der zur Verfügung gestellten Images an.
Container Image Repositories gehören zu den wesentlichen Bestandteilen in PaaS-Umgebungen (Platform as a Service), die zur Entwicklung und zum Deployment von Anwendungen auf Container-Basis genutzt werden. Viele Entwickler, Admins und auch DevOps-Teams nutzen mittlerweile Container für ihre tägliche Arbeit. Die meisten von ihnen holen sich die benötigten Container aus verschiedenen Quellen, um möglichst schnell und flexibel neue Anwendungen entwickeln und einsetzen zu können.
Man sollte aber bedenken, dass nicht alle Container Image Repositories miteinander vergleichbar sind. So bieten die meisten großen Cloud-Anbieter interne Repositories an, die als Teil ihrer Cloud-Umgebungen genutzt werden können. Beispiele dafür sind etwa die Elastic Container Registry von Amazon, die Azure Container Registry von Microsoft und die Container Registry von Google. Wenn ein Unternehmen sich für ein eigenes Repository für die von ihm zum Beispiel in der Cloud genutzten Container-Images entscheidet, dann können dieselben Vorgaben und Sicherheitsrichtlinien genutzt werden, die bereits intern gelten.
Es gibt jedoch ein Problem. Viele Mitarbeiter greifen auf Container aus offenen, von Communities bestückten Repositories wie Docker Hub oder von Dritten betriebene Repositories von zum Beispiel Quay oder Sonatype Nexus zurück. Diese Dienste bieten einen leichten Zugriff auf Images, die von Individuen oder Unternehmen aus der Entwicklergemeinde bereitgestellt wurden. Nicht alle dort zu findenden Images werden jedoch ausreichend auf Schwachstellen und Sicherheitslöcher geprüft.
Die Situation wird noch unübersichtlicher, da auch große Soft- und Hardwareanbieter wie IBM und Oracle eigene offizielle Repositories anbieten. Darüber hinaus gibt es einige offene und durch die Community betriebene Repositories, die fast keine oder überhaupt keine Sicherheitsschranken errichtet haben.
Die Wahl des passenden Container Image Repositories
Aus mehreren Gründen sollten die IT-Security-Teams in Unternehmen in die Frage einbezogen werden, welche Container-Images ihre Kollegen nutzen und welche Optionen es gibt, um diese Images zu hosten. In vielen Umgebungen greifen Programmierer und QA-Tester (Quality Assurance) in ihrer täglichen Arbeit auf zahlreiche Images zu, um neue Funktionen zu entwickeln und zu testen. Die Wahl der dafür genutzten Repositories sollte mit internen oder externen Sicherheitsexperten abgeklärt werden. Oft gibt es mehrere Vor-, aber auch Nachteile, die gegeneinander abgewogen werden sollten.
So bieten die Registries der großen Cloud-Anbieter wie der Enterprise Container Service von Amazon oder die Azure Container Registry von Microsoft vorkonfigurierte Richtlinien für den Zugriff auf Daten, Logging-Funktionen zum Überwachen wichtiger Ereignisse und eine Integration in die APIs (Application Programming Interfaces) der Provider. Dazu kommen meist noch andere Funktionen wie Verschlüsselung und Identitäts-Management.
Diese Registries sind jedoch außerhalb ihrer Stammumgebungen nicht so leicht einsetzbar, so dass sie sich nur schwer für offene oder Multi-Cloud-Projekte eignen. Manche Registries, wie etwa die von GitLab bereitgestellte, können auch intern oder in einer gehosteten Umgebung genutzt werden. Sie bieten dann vor allem Vorteile für Teams, die die Entwicklungsplattform von GitLab nutzen. Dazu gehören dann aber auch Zugriffskontrollen, Überwachung und eine Integration in die genutzten Projekt-Lifecycles.
Aus Security-Sicht ist es von großer Bedeutung, die genutzten Container-Images kontinuierlich zu überwachen und fortlaufende Überprüfungen durchzuführen, um immer darüber im Bilde zu sein, auf welche Repositories und Registries gerade zugegriffen wird. Seit ein paar Jahren scannen manche Registries auch selbst nach Schwachstellen. Zunehmend lassen sich auch digitale Signaturen nutzen, um offizielle Container-Images identifizieren und überprüfen zu können, die auf dem jeweiligen Dienst angeboten werden.
So wurde etwa Docker Security Scanning bereits 2016 eingeführt. Es betrifft alle offiziellen Images, die auf dem Docker Hub angeboten werden. Die Funktion lässt sich auch als Add-on in privaten Docker-Repositories einsetzen. Docker Content Trust dient dagegen dazu, eine Überprüfung der digitalen Signaturen für alle offiziellen Images zu ermöglichen, die bei Drittanbietern gehostet werden. Dazu kommt Docker Trusted Registry. Damit lässt sich eine komplett selbst verwaltete Registry in Unternehmen einrichten, die Funktionen wie Zugriffskontrollen, Integration ins Active Directory sowie Scanning, Image Signing und Logging bietet.
Die IT-Sicherheitsexperten in einem Unternehmen sollten die zur Verfügung stehenden Optionen mit allen Teams besprechen, die Container für ihre tägliche Arbeit benötigen. Dabei gilt es, die optimale Balance aus Sicherheit und Nutzbarkeit zu finden. Das ist zwar nicht immer einfach, aber es gibt heutzutage einige sichere Möglichkeiten, die über die ursprünglichen Repositories der Community hinausgehen. Das Definieren von Sicherheitsrichtlinien und Kontrollen für alle genutzten Images und Repositories ist auf jeden Fall ein Schritt in die richtige Richtung, um die Sicherheit im Unternehmen zu verbessern.
Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!
