Rund um die Open-Source-Nutzung und damit auch um die Containerisierung existieren immer noch einige Mythen. Sie führen vielfach dazu, dass Unternehmen elementare Sicherheitsmaßnahmen nicht oder nur unzureichend ergreifen. Marie Innes von Red Hat zeigt, welche Mythen anzutreffen sind und wie Unternehmen containerisierte Anwendungen sichern können.
Foto: Red Hat
Die Autorin Marie Innes ist Solution Architect bei Red Hat
Open Source ist das Herzstück der meisten bahnbrechenden Technologien wie Künstliche Intelligenz und Maschinelles Lernen, Edge Computing, Serverless Computing und nicht zuletzt Containerisierung. Wie überall in der IT darf beim Einsatz von Open Source Software und Containern das Thema Sicherheit nicht zu kurz kommen. Dabei gibt es einige Missverständnisse, die verhindern, 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. So steht einer risikominimierten Container-Nutzung nichts im Wege.
Fünf gängige Mythen beziehungsweise Missverständnisse im Überblick:
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.
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.
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.
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.
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.
Die verschiedenen Mythen zeigen, dass das Thema Sicherheit sowohl organisatorisch als auch technologisch einen deutlich höheren Stellenwert einnehmen muss, und zwar im gesamten Lifecycle einer containerisierten Anwendung, also in den Phasen „Design“, „Build“, „Run“, „Manage & Automate“ und „Adapt“. In der Design-Phase geht es um die Identifizierung der Sicherheitsanforderungen und in der Build-Phase um die unmittelbare Integration von Sicherheit in den Applikations-Stack. Um den Betrieb zu entlasten, sollten vertrauenswürdige Plattformen mit erweiterten Sicherheitsfunktionen genutzt werden. Die Phase „Manage & Automate“ beinhaltet die Automatisierung der Systeme für Sicherheit und Compliance und „Adapt“ schließlich die regelmäßige Aktualisierung, wenn es Änderungen in der Security-Landschaft gibt.
Mit einem solchen holistischen Ansatz, der die Supply Chain Security in den Mittelpunkt stellt, ist ein 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.
 Axians.jpg&size=390x230&crop=0&trim=1)
