Marie Innes von Red Hat über Container-Sicherheit 5 Container-Security-Mythen

Anbieter zum Thema

Red Hat GmbH

Fujitsu Technology Solutions GmbH

FTAPI Software GmbH

Outpost24 GmbH

Die Container-Sicherheit in etlichen Unternehmen leidet darunter, dass mit der Anwendungsvirtualisierung einige Falschbehauptungen und Legenden einhergehen. Marie Innes von Red Hat räumt mit einigen Mythen auf und erläutert, wie sich containerisierte Anwendungen absichern lassen.

„Wie überall in der IT darf beim Einsatz von Open Source Software und Containern das Thema Sicherheit nicht zu kurz kommen“, meint Solution Architect Marie Innes. Das gelte sowohl auf organisatorischer wie auch auf technischer Ebene sowie über alle Phasen des Lebenszyklus einer Anwendung hinweg.

Allerdings verhinderten in der Vergangenheit aufgeworfene Missverständnisse, die, dass ein ganzheitlicher, mehrschichtiger Sicherheitsansatz verfolgt wird. „Ein solcher Ansatz stellt die Supply Chain Security in den Vordergrund und berücksichtigt Container in allen Phasen – beim Erstellen, Bereitstellen und Ausführen“, schreibt Innes. So stehe einer risikominimierten Container-Nutzung nichts im Wege.

Im Folgenden gibt Marie Innes einen Überblich über fünf gängige Mythen und Missverständnisse:

Mythos 1: Für die Security bei Open-Source-Technologien sorgt allein die Community.

Hohe Innovationskraft und Sicherheit zeichnen Open Source aus, getragen von Communities mit Tausenden von Mitwirkenden. Einige grundlegende Sicherheitsmaßnahmen müssen Unternehmen trotzdem ergreifen, etwa für die verwendeten Basis-Images, den Build-Prozess oder das Deployment.

Wichtig ist vor allem die ausschließliche Nutzung von Container-Images aus vertrauenswürdigen Quellen. Beispiele sind bewährte Basis-Images für das Linux-Betriebssystem oder zertifizierte Images für Programmiersprachen, Middleware und Datenbanken.

Abgesehen von der Verifizierung der Herkunft eines Applikations-Containers sollte ein Unternehmen auch die Inhalte mit Sicherheits-Scannern überprüfen, um Schwachstellen in den Images zu erkennen. Darüber hinaus führt kaum ein Weg am Einsatz einer Plattform vorbei, die eine konsistente Entwicklung und Skalierung von containerisierten Anwendungen unterstützt. Sie sollte hauptsächlich Lifecycle-Management, Identitäts- und Zugriffsmanagement sowie die Sicherung der Plattformdaten bieten.

Mythos 2: Die bewährten Sicherheitskonzepte sind ausreichend.

Vom Rechenzentrum bis zur Edge ist Container-Workload über viele Infrastruktur-Footprints verteilt. Folglich muss auch jede Schicht des Infrastruktur-Stacks und jeder Schritt des Anwendungsentwicklungszyklus abgesichert werden.

Im Prinzip kann ein Unternehmen zwar auf bewährte Security-Mechanismen zurückgreifen, sie müssen jedoch den neuen Gegebenheiten angepasst werden. In einer Zeit des Software-defined Everything, in der eine Vielzahl von Software-basierten Technologien genutzt wird, sind auch andere Security-Konzepte erforderlich, etwa für Software-defined Network oder Software-defined Storage.

Mythos 3: Security ist nur ein Thema für Audits

Security wird vielfach als Blocker gesehen, der die Entwicklungstätigkeit behindert. Das Thema Security wird deshalb oft erst am Ende eines Entwicklungsprozesses aktiv angegangen. Ein solches Vorgehen ist sicherheitskritisch. Security muss immer als Teil eines ganzen Prozesses betrachtet werden. Dabei geht es nicht nur um technologische Fragen, sondern vor allem auch um organisatorische Abhängigkeiten und eine enge Zusammenarbeit aller Prozess-Stakeholder mit einer geteilten Verantwortlichkeit.

Security kann also kein reines Audit-Thema sein. Vielmehr muss ein Security-by-Design-Ansatz verfolgt werden. Bezogen auf den Container-Bereich und das Ziel „Einmal erstellen, überall bereitstellen“ heißt das, dass im Build-Prozess ein fehlerfreies Produkt entsteht, das im Produktivbetrieb eingesetzt wird.

Mythos 4: Für die Sicherheit reichen Schwachstellen-Scans.

Es ist richtig, Container mit Tools zu scannen, die kontinuierlich aktualisierte Datenbanken für Sicherheitslücken verwenden. Da permanent neue Schwachstellen auftreten, müssen Unternehmen die Inhalte ihrer Container-Images beim Herunterladen prüfen und den Sicherheitsstatus im Laufe der Zeit für alle bereitgestellten Images verfolgen.

Allerdings ist dies nur ein Aspekt, da Sicherheit immer als ganzheitlicher Prozess verstanden werden muss und nicht auf ein Schwachstellen-Scanning reduziert werden kann. Es geht letztlich immer um den gesamten Lebenszyklus eines Lösungs-Stacks und damit etwa auch um die Etablierung einer DevSecOps-Pipeline, die die Überwachung der Applikationssicherheit, den Schutz der Plattform und die Reaktion auf Runtime-Bedrohungen umfasst.

Mythos 5: Entwickler müssen sich doch nicht um Security kümmern.

Mit über einer Million Open-Source-Projekten können Entwickler relativ einfach Bestehendes übernehmen, an die eigenen geschäftlichen Anforderungen anpassen und produktiv nutzen. Allerdings sind auch klare Policies und Regularien zwingend erforderlich, etwa für die Kontrolle und Automatisierung der Erstellung von Containern. Unternehmen sollten überdies auch Best Practices für die Sicherheit in der Anwendungspipeline beachten, vor allem hinsichtlich der Integration automatischer Sicherheitstests.

Abschließend spricht sich Innes für einen holistischen Ansatz aus, der die Sicherheit der Software-Lieferkette in den Mittelpunkt stellt. So seien Unternehmen bestens für die Container-Nutzung gerüstet und „Security muss damit nicht mehr als Blocker gesehen werden, sondern kann vielmehr als Enabler einer modernen IT-Infrastruktur fungieren“, schreibt Innes.

(ID:48607581)