Marie Innes, Solution Architect bei Red Hat, zeigt in diesem Listicle auf, welche Mythen um die Containerisierung anzutreffen sind und wie Unternehmen containerisierte Anwendungen sichern können.
Wie überall in der IT darf beim Einsatz von Open Source Software und Containern das Thema Sicherheit nicht zu kurz kommen. Die folgenden Mythen führen laut Red Hat zu Sicherheitsrisiken.
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 Sicherheitsmassnahmen müssen Unternehmen laut Red Hat trotzdem ergreifen, etwa für die verwendeten Basis-Images, den Build-Prozess oder das Deployment. Wichtig sei vor allem die ausschliessliche Nutzung von Container-Images aus vertrauenswürdigen Quellen. Beispiele seien 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ühre kaum ein Weg am Einsatz einer Plattform vorbei, die eine konsistente Entwicklung und Skalierung von containerisierten Anwendungen unterstütze. 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 könne ein Unternehmen zwar auf bewährte Security-Mechanismen zurückgreifen, sie müssten jedoch den neuen Gegebenheiten angepasst werden. In einer Zeit des Software-defined Everything, in der eine Vielzahl von Software-basierten Technologien genutzt werde, seien 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 müsse immer als Teil eines ganzen Prozesses betrachtet werden. Dabei gehe 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 könne also kein reines Audit-Thema sein. Vielmehr müsse ein Security-by-Design-Ansatz verfolgt werden.
Mythos 4: Für die Sicherheit reichen Schwachstellen-Scans
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 sei dies nur ein Aspekt, da Sicherheit immer als ganzheitlicher Prozess verstanden werden müsse und nicht auf ein Schwachstellen-Scanning reduziert werden könne. Es gehe 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 umfasse.
Mythos 5: Entwickler müssen sich doch nicht um Security kümmern
Mit über einer Million Open-Source-Projekten könnten Entwickler relativ einfach Bestehendes übernehmen, an die eigenen geschäftlichen Anforderungen anpassen und produktiv nutzen. Allerdings seien 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.
