Wie unterscheiden sich Container und VMs bei der Sicherheit?

Sicherheit von Containern

So haben Anwendungscontainer unterschiedliche Eigenschaften, von denen einige die Security unterstützen und – je nach Verwendung – einige die Sicherheit untergraben können. Eine Schlüsseleigenschaft von Containern ist eine – zumindest historisch gesehen – durchlässigere Segmentierungsgrenze im Vergleich zur Verwendung eines Hypervisors.

Was bedeutet in diesem Zusammenhang eine durchlässigere Segmentierungsgrenze? Im Kontext der Betriebsystemvirtualisierung wird die Segmentierung vom Hypervisor unterhalb der Ebene des Gastbetriebssystems erzwungen. Die von einer Container-Engine verwendete Segmentierung funktioniert auf andere Weise. Container laufen auf der gleichen Betriebssysteminstanz wie die Container-Engine. Und sie laufen auch auf dem gleichen Betriebssystem wie andere Container. Dies ist der Fall, obwohl Container normalerweise weder untereinander noch mit der Container-Engine interagieren können.

Container nutzen Funktionen des Betriebssystems, um logische Umgebungen zu schaffen. In diesen sind Ansichten von Prozessen, Dateien und Netzwerkstatus füreinander unsichtbar sind. Dies wird über Namespaces bewerkstelligt. Das bedeutet jedoch, dass es an den Fähigkeiten des Betriebssystems liegt, die Segmentierung umzusetzen. Warum dies schwierig sein kann, kann beispielhaft ein Blick auf den Linux-Time-Namespace zeigen.

Bis März 2020 (Linux 5.6) war die Zeit nicht im Namensraum enthalten. Das bedeutet, dass, wenn Security-Teams auf einer Kernel-Version vor 5.6 – zum Beispiel dem 4.19-Kernel, der derzeit von Debian 10 verwendet wird – die Standardschutzmaßnahmen deaktivieren, die verhindern, dass ein Container die Zeit in den meisten Container-Engines ändert, wäre dies problematisch. Dies würde es dem Container ermöglichen, die Zeit auf dem gesamten Host zu ändern, andere Container eingeschlossen. In diesem Fall würde die Durchsetzung der Segmentierung von den OS-Versionen abhängen. Dies kann sehr komplex werden, wenn man die gesamte Funktionalität von Namespaces und cgroups berücksichtigt.

Darüber hinaus funktionieren Teile des Betriebssystems so, wie es immer getan haben: Der Root-Benutzer ist immer noch der Root-Benutzer. Sensible Dateien sind dort, wo sie schon immer waren und so weiter. Das bedeutet, dass es dem Administrator obliegt, dafür zu sorgen, dass der Host, auf dem die Container-Engine läuft, entsprechend gesichert und gehärtet ist.

Abgesehen davon, kann es potenzielle Sicherheitsvorteile geben, je nachdem, was man erreichen will. Ebenso wie bei der Betriebssystemvirtualisierung existieren sowohl Vor- als auch Nachteile. Die Verwendung von Containern fördert die Denkweise, alte oder veraltete Container zu eliminieren und neue, frische Container zu installieren. Dies wiederum reduziert die Konfigurationsabweichung im Laufe der Zeit, da einzelne Container nicht lange genug existieren, um eine „Persönlichkeit“ zu entwickeln.

In der Welt der OS-Virtualisierung hingegen können Instanzen lange Zeit bestehen bleiben. Das kann dazu führen, dass sie veralten, Backup-Dateien und alte Softwareartefakte sammeln und Konfigurationsänderungen erfahren. Diese würden in einer containerisierten Umgebung bei einer erneuten Bereitstellung zurückgesetzt werden.

Darüber hinaus sollte man die Vorteile für die Sicherheit nicht unterschätzen, die eine weitergehende Aufteilung von Diensten oder Anwendungskomponenten mit sich bringen kann. Diese würden sich ansonsten auf demselben virtuellen oder physischen Gerät befinden. Dies steigert den Wert eines breiteren, sicherheitsorientierten Bereitstellungsmodells, das auf Microservices basiert.

Security-Vorteile von Containern

• Die Risiken von Konfigurationsabweichungen werden reduziert, wenn Container ausgemustert und neu bereitgestellt werden.
• Container sind schlank und portabel; sie können schnell in neuen Umgebungen eingesetzt werden, um die Entwicklung zu erleichtern oder bei speziellen Tests Verwendung finden.
• Erstellungswerkzeuge wie Dockerfile liefern ein Manifest der Software und der Konfiguration.

Security-Nachteile von Containern

• Das Segmentierungsmodell ist kompliziert und wird auf Betriebssystemebene erzwungen.
• Die zugrunde liegenden Funktionen zu Durchsetzung der Segmentierung sind versionsabhängig.
• Die Sicherheit des zugrunde liegenden Hosts, auf dem die Container-Engine läuft, ist von größter Bedeutung.

Best Practices bei der Container-Security

Um die Sicherheit der eigenen Container-Umgebungen zu gewährleisten, sollten man einige wichtige Grundsätze beachten. Die nachfolgende Liste erhebt aber keinen Anspruch auf Vollständigkeit.

Die Orchestrierung beachten. Wie bei virtuellen Maschinen kann die Verwaltung von Containern im großen Maßstab schwierig werden. Der Einsatz von Tools wie Kubernetes sollten Sie in jedem Fall in Betracht ziehen. Dies bietet Unterstützung bei Bereitstellung, Skalierung und den Security-Diensten, einschließlich der Verwaltung von Geheimnissen.

Dockerfile oder YAML nicht außer Acht lassen. Einer der größten, aber auch oft übersehenen, Sicherheitsvorteile von Containern ist das Manifest. Wenn Sie sich die Build-Artefakte für einen Container ansehen, wissen Sie mit Sicherheit, was sich in diesem Container befindet und wie er konfiguriert ist. Dies kann aus Sicht der Sicherheitsüberprüfung ein großer Vorteil sein.

Container-Scans vornehmen. Herkömmliche Werkzeuge, wie zum Beispiel Tools zum Scannen auf Schwachstellen, funktionieren oft gut in einem VM-Kontext. Solche Images lassen sich dann oft scannen, genauso wie Sie es bei einem physischen Host tun würden. Container stellen da eine andere Herausforderung dar. Daher existieren spezielle Tools – wie zum Beispiel die Open-Source-Werkzeuge Anchore Engine und Clair. Damit lassen sich Images untersuchen, um verwundbare Software zu finden und Admins entsprechend zu benachrichtigen. Derlei Meldungen können direkt in die Entwicklungs- und Release-Pipeline integriert werden, um dies zu automatisieren.

Sidecar-Proxies in Betracht ziehen. Eine der Möglichkeiten, die Sicherheit zu verbessern, besteht darin, den Anwendungsfluss eines Containers vom zugrunde liegenden Netzwerk zu entkoppeln. Um dies zu erreichen, können Proxies wie Envoy, die typischerweise als Sidecar oder separater Container auf derselben Engine laufen, und Istio dabei helfen, den Datenverkehr zu überwachen. Damit können Sie eine Grundlage schaffen, um die zugrunde liegende Sicherheitsfunktionalität hinzuzufügen oder zu optimieren.

Virtuelle Maschinen und die Sicherheit

Der Umgang mit Hypervisoren und virtuellen Maschinen gehört für Security-Teams zum Alltag. Ein wichtiges Sicherheitsmerkmal in diesem Umfeld ist eine starke Segmentierungsgrenze. Dies sowohl zwischen virtuellen Hosts auf demselben Hypervisor als auch zwischen virtuellen Hosts und dem Hypervisor selbst.

Segmentierungsangriffe können in der Welt der Virtualisierung auf Hypervisoren oder auf der Hardware, auf der diese Hypervisoren laufen, stattfinden. Probleme auf Hardwareebene, wie beispielsweise TRRespass (CVE-2020-10255) haben Auswirkungen in einer virtuellen Umgebung, da sie Zustandsänderungen über die Segmentierungsgrenze hinweg verursachen können. Ebenso können Softwareprobleme in der Hypervisor-Software (beispielsweise CVE-2020-3999) DoS-Probleme (Denial of Service) oder Zugriff auf Informationen (zum Beispiel CVE-2020-3971) über diese Grenze hinweg verursachen.

Trotz dieser potenziellen Probleme ist die Segmentierung zwischen VMs und dem Hypervisor – und zwischen VMs selbst – so stark wie möglich ausgelegt. Das bedeutet, dass VMs in Situationen helfen, in denen eine starke Segmentierungsgrenze kritisch ist. Zum Beispiel, wenn Security-Teams nicht die Kontrolle über die gesamte Umgebung haben und/oder in einer mandantenfähigen Umgebung. Es kann auch von Vorteil sein, wenn Teams schnell Änderungen an der zugrunde liegenden Netzwerkkonfiguration vornehmen müssen, entweder durch Softwareänderungen oder wenn sie ein physisches Gerät in eine virtuelle Umgebung migrieren wollen.

Bei der Virtualisierung existieren jedoch auch einige potenzielle Nachteile in Sachen Security. Ohne systematische Planung können vor allem bei größeren Maßstäben schnell Verwaltungsprobleme auftreten. Etwa eine unerwünschte Verbreitung von Images, veraltete Images, die sich auf irgendwelchen Festplatten befinden sowie Probleme bei der Inventarisierung. Orchestrierung kann die Folgen dieser Probleme abmildern, wenngleich nicht vollständig beseitigen.

Unternehmen, die über Umgebungen mit umfangreichen physischen Assets verfügen, können die Migration von physischen auf virtuelle Systeme relativ einfach realisieren. Aus der Perspektive der Security kann das durchaus Vorteile haben. Die Virtualisierung eines physischen Hosts kann die Möglichkeit bieten, diese Geräte zu härten. Und Funktionen wie Snapshots können beim Patchen helfen.

Andererseits besteht in manchen Fällen auch ein Risiko, wenn ein Gerät, dass eigentlich außer Betrieb genommen werden sollte, weiterhin aktiv bleibt. Oder auch wenn einen Probleme der Vergangenheit einholen, wie zum Beispiel die Abweichung der Konfiguration, die sich einschleichen kann, wenn ein Server über viele Jahre hinweg bestehen bleibt.

Aus dem Blickwinkel der Entwicklung bietet die Virtualisierung eine Spielwiese, in der sie arbeiten können. Sie können die Cloud nutzen, um schnell neue Instanzen bereitzustellen. Mit Snapshots können sie eine VM auf eine bekannte, stabile Konfiguration zurücksetzen. Allerdings sind die Images meist groß und manchmal nicht so portabel, wie man sich wünschen würde.

Security-Vorteile virtueller Maschinen

• Es gibt eine starke Segmentierungsgrenze zwischen Workloads und zwischen Gast und Hypervisor.
• Es ist eine einfache Migration von physischen Systemen zu virtuellen möglich. Das ist hilfreich, wenn die physische Hardware veraltet ist.
• Snapshots können beim Testen von Patching-Maßnahmen und bei der Entwicklung helfen.

Security-Nachteile virtueller Maschinen

• Segmentierungsangriffe sind zwar selten, aber dennoch möglich und sie kommen vor.
• Virtuelle Workloads sind gerne mal sehr groß und daher weniger portabel.

Best Practices bei der Sicherheit von virtuellen Maschinen

Um die Sicherheit von virtuellen Umgebungen zu gewährleisten, sollten Admins einige wichtige Grundsätze beachten. Selbstredend ist auch hier nachfolgend kein Anspruch auf Vollständigkeit vorausgesetzt.

Wichtige Informationen einholen. Es ist wichtig, sich Kenntnisse über die verwendete Hypervisor-Plattform und die Sicherheitsfunktionen anzueignen. Wenn ein IaaS-Anbieter genutzt wird, sollte man dessen verfügbare Sicherheitsfunktionen und Konfigurationsoptionen kennen. Achten Sie auf Schwachstellen, die die Hypervisor-Plattform betreffen, sowie auf solche, die die zugrunde liegende Hardware betreffen.

Snapshots gezielt einsetzen. Snapshots können ein ganz treffliches Werkzeug in Sachen Sicherheit sein. Sie können das Patchen ungemein erleichtern, einen bekannten lauffähigen Zustand bewahren, für Entwickler gute Dienste leisten und vieles mehr. Snapshots sollten jedoch sicher gespeichert und verwaltet werden. Schließlich können sie sensible Informationen enthalten, wie Servergeheimnisse, einschließlich Passwörter und kryptografische Schlüssel.

Die Umgebungen richtig verwalten. Ziehen Sie Orchestrierungs-Tools oder andere Software in Betracht, um die eigene virtuelle Umgebung zu verwalten. Auch wenn Sie sich nicht für die Orchestrierung entscheiden, sollte Sie die VM-Nutzung im Auge behalten, um eine Ausuferung zu vermeiden. So lässt sich der Zustand und die mögliche Überalterung von Workloads im Blick behalten und sicherstellen, dass sie auf dem neuesten Stand gehalten werden.

Kompatible Werkzeuge auswählen. Stellen Sie sicher, dass Sie die richtigen Werkzeuge für Security-Aufgaben verwenden. Die verwendeten Tools müssen Ihre Nutzung widerspiegeln. So ist zum Beispiel ein virtueller Tap oder eine Port-Spiegelung operativ unterschiedlich, ob es einen eigenen Hypervisor betrifft oder einer IaaS-Umgebung (Infrastructure as a Service).

Eine Gegenüberstellung von Container- und VM-Sicherheit

Container und virtuelle Maschinen zu vergleichen und die Frage zu stellen „Was ist sicherer?“ ist ein bisschen wie die Fragestellung „Was ist nützlicher: ein Hammer oder eine Banane?“. Es kommt immer ganz auf den Nutzungskontext an. Zweifelsohne ist die Banane das bekömmlichere Frühstück aber weniger dienlich beim Einschlagen eines Nagels.

Für eine Legacy-Anwendung – vielleicht sogar eine, die derzeit auf einem physischen Host läuft – könnte Migration von physisch zu virtuell auf einen geschützten Hypervisor die richtige Lösung sein. Während eine neue Anwendung, die aus Hunderten von Microservices besteht, vielleicht besser in einer containerisierten Umgebung aufgehoben ist. Einige Unternehmen stehen Multi-Tenant-Containerplattformen aufgrund der historischen Namespacing-Komplexität bei Containern immer noch skeptisch gegenüber. Andere Organisationen bevorzugen die Vorteile durch die Minimierung der Konfigurationsabweichungen. Letztendlich hängt die Entscheidung davon ab, wo die Herausforderungen im eigenen Unternehmen liegen, die spezifische Nutzung und der Kontext im Geschäftsbetrieb.