DevOps und Container-Sicherheit

Sicherheit in den drei Phasen des Container-Einsatzes

| Autor / Redakteur: Hari Srinivasan / Peter Schmitz

Damit Sicherheitsteams Container über ihren gesamten Lebenszyklus hinweg schützen können, müssen sie die Docker-Container-Technologie verstehen und Prozesse und Tools einführen, die auf diese Umgebungen zugeschnitten sind.
Damit Sicherheitsteams Container über ihren gesamten Lebenszyklus hinweg schützen können, müssen sie die Docker-Container-Technologie verstehen und Prozesse und Tools einführen, die auf diese Umgebungen zugeschnitten sind. (Bild: Pixabay / CC0)

Die Popularität von Containern hat in den letzten Jahren enorm zugenommen. Und damit auch die Notwendigkeit, Anwendungen abzusichern, die DevOps-Teams mithilfe von Containern entwickeln und bereitstellen. Sicherheitsteams müssen diese Container über ihren ganzen Lebenszyklus hinweg schützen. Sicherheitsmaßnahmen müssen dabei nahtlos in die DevOps-Pipeline integriert werden.

Container schaffen besondere Sicherheits- und Compliance-Probleme. Viele davon rühren genau von den Eigenschaften her, die für Entwickler attraktiv sind, wie etwa, dass Anwendungen samt ihren Abhängigkeiten gepackt werden können, ohne ein Gastbetriebssystem zu benötigen. Zu den Sicherheitsherausforderungen zählen die Verwendung unvalidierter Software aus öffentlichen Repositories, die häufig ungepatchte Schwachstellen aufweist, und die Bereitstellung von Containern mit schwachen Konfigurationen.

Außerdem kommunizieren Container direkt über offene Netzwerk-Ports miteinander – wobei Host-Kontrollen umgangen werden – und sind aufgrund ihrer Flüchtigkeit schwer nachverfolgbar.

Sicherheitsziele für Container

Die Sicherheitsteams sollten bei der Container-Sicherheit vier Hauptziele verfolgen. Erstens müssen sie Übersicht über ihre gesamte Container-Umgebung gewinnen, indem sie alle Deployments erkennen und verfolgen, sowohl lokal als auch in Clouds.

Zweitens müssen sie Schwachstellen in Containern beseitigen und Einbrüche verhindern und erkennen. Ein drittes Ziel sollte sein, die Vorteile von REST-APIs zu nutzen, um DevOps-Produkte mit den Container-Sicherheitstools zu integrieren.

Und schließlich sollte das Container-Sicherheitsprogramm bei der Incident Response (IR) neue Wege gehen, zumal anfällige Container nicht „gepatcht“, sondern durch neue Container aus einem aktualisierten Image ersetzt werden.

Die Teams sollten das IR-Programm so anpassen, dass Informationen zu der neuen Betriebsumgebung für Container gesammelt werden, zum Beispiel zur Orchestrierungsplattform, und das „Rip and Replace“-Modell als IR-Element einplanen.

Schutz der Container-Pipeline

Alle drei Phasen des Container-Einsatzes – Build, Ship und Run – müssen abgesichert werden, wobei jede spezifische Anforderungen mit sich bringt.

Phase 1: Build

In dieser ersten Phase besteht das primäre Sicherheitsziel darin zu verhindern, dass anfällige Images in die Repositories Ihres Unternehmens gelangen. Dies ist besonders wichtig bei Images, die nicht von Grund auf neu erstellt werden, sondern ganz oder teilweise aus einem öffentlichen Repository bezogen werden – bei Container-Entwicklern eine gängige Praxis.

Um diese unsicheren Images aus Ihren Docker-Repositories herauszuhalten, sollten Sie REST-APIs oder native Plugins nutzen, damit Sicherheitsprüfungen automatisch innerhalb der bevorzugten CI/CD-Tools Ihres DevOps-Teams ausgeführt werden können. Sie sollten in der Lage sein, flexibel Parameter für das Blockieren von Images festzulegen – zum Beispiel die Existenz von Schwachstellen mit dem Schweregrad 3, 4 oder 5; die mangelnde Einhaltung von Compliance-Standards; und die offene Verwendung von Secrets in den Images.

Diese Integrationen geben dem Sicherheitsteam auch die Möglichkeit, den Entwicklern Zugang zu den Sicherheitstools zu gewähren. So können die Entwickler proaktiv bestimmte Sicherheitsfunktionen direkt von ihrem CI/CD-Tool aus ausführen, ohne dazu die Sicherheitsmitarbeiter heranziehen – und auf sie warten – zu müssen. Beispielsweise sollten die Entwickler Zugriff auf die Ergebnisdaten von Scans erhalten und Maßnahmen zur Problembehebung direkt über die Schnittstelle ihres CI/CD-Tools ergreifen können.

Phase 2: Ship

In dieser Phase müssen Sie dafür sorgen, dass die Images, die sich bereits in Ihren Repositories befinden, auf Schwachstellen überprüft werden. Die Registries und Repositories sollten inventarisiert werden. Hinzukommende Images sollten auf Schwachstellen gescannt werden. Außerdem sollten tägliche automatische Scans angesetzt werden, um nach neuen Schwachstellen zu suchen und die Images zu überprüfen, die den Repositories laufend hinzugefügt werden.

Ferner sollten Sie prüfen, ob die Images in Ihrem Unternehmen aus vertrauenswürdigen Quellen stammen, die ihre Images pflegen und veröffentlichte Schwachstellen beseitigen. Verwenden Sie Notar-Dienste wie den Docker's Notary Service oder ähnliche Lösungen, um die Images zu signieren und zu gewährleisten, dass in Ihrer Umgebung nur vertrauenswürdige Images genutzt werden.

Phase 3: Run

Da die Container-Images jetzt in Ihrer Registry abgelegt und für den produktiven Einsatz verfügbar sind, müssen Sie unbedingt Übersicht über die Laufzeitumgebungen haben. Sie müssen diese kontinuierlich überwachen können und in der Lage sein, Verstöße zu verhindern und darauf zu reagieren.

Die Sicherheitsteams müssen bösartige oder anfällige Container erkennen; feststellen, wo sie sich befinden; und ihre potenziellen Auswirkungen bewerten, abhängig davon, wie weit diese Container in Ihrer Umgebung verbreitet sind.

Entscheidend ist dabei, dass diejenigen Container markiert werden, die bereits auf dem System laufen und vom „unveränderlichen“ Verhalten ihres übergeordneten Images abweichen, was auf eine Sicherheitsverletzung hindeuten könnte.

Da Container dem Image folgen, ist es unbedingt erforderlich, das Verhalten der containerisierten Anwendung zu identifizieren und verdächtige Abweichungen zu erkennen, wie etwa unerwartete Systemaufrufe, Prozesse und Kommunikationen.

Die Sicherheitsteams müssen feststellen, wo diese Images in der Laufzeitumgebung zwischengespeichert werden, und sowohl aktive als auch inaktive Images ermitteln.

Wenn bösartige Container erkannt wurden, sollte Ihnen Ihr Sicherheitstool die Möglichkeit geben, Gegenmaßnahmen – Blockade oder Quarantäne – durchzusetzen und die Details zu den Anomalien einzusehen, damit Sie den Problemen auf den Grund gehen können. Ihre Betriebsabläufe dürften dadurch nicht beeinträchtigt werden, da Sie aus dem übergeordneten Image einen neuen Container erzeugen können, um den bösartigen zu ersetzen.

Noch besser wäre es, das Image mithilfe Ihres Tools automatisch mit den Sicherheitsrichtlinien abzugleichen und zu verhindern, dass aus nicht genehmigten Images Container erzeugt werden. Dazu können Orchestrierungsdienste wie Kubernetes eingesetzt werden, die mit Zutrittskontrollen verhindern, dass bösartige Container in die Umgebung gelangen.

Befolgen Sie außerdem die Sicherheitspraktiken, die für die Orchestrierungsumgebungen vorgeschrieben sind, um sichere Betriebsumgebungen nach dem „Least Access“-Modell zu schaffen. Wenn Sie Zugriff auf das zugrunde liegende Host-System haben, sollten Sie es gegen Schwachstellen schützen und dafür sorgen, dass es die Compliance-Anforderungen erfüllt.

Fazit

Wir hoffen, dass Ihnen dieser Beitrag geholfen hat, besser zu verstehen, welche besonderen Sicherheitsherausforderungen Container stellen, und wie Sie diese während des gesamten Lebenszyklus bewältigen können: durch Blockieren anfälliger Images, die in der Build-Phase in die Repositories gelangen; durch Absicherung von Images, die in der Ship-Phase in Ihre Registries geschoben werden; und durch Scannen während der Produktion in der Laufzeitphase, um gefährdete Container zu identifizieren und zu verwalten.

Über den Autor: Hari Srinivasan ist Director Product Management bei Qualys.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45572090 / Cloud und Virtualisierung)