München, Starnberg, 13. Dez. 2022 - Security wird noch vielfach als Blocker gesehen, der die Entwicklungstätigkeit behindert; Sicherheit ist jedoch ein ganzheitlicher Prozess...
Zum Beitrag: 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. Marie Innes, Solution Architect bei Red Hat (1) zeigt für uns, welche Mythen anzutreffen sind und wie Unternehmen containerisierte Anwendungen sichern können.
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.
Fazit: 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."
(1) Das Foto zeigt Marie Innes, Solution Architect bei Red Hat (Bildquelle: Red Hat)
Querverweis:
Unser Beitrag > IT-Verantwortliche setzen auf Container-Technologien, Zero Trust und Machine Learning
Unser Beitrag > Was Softwarearchitekten über Managed Kubernetes wissen sollten