kalafoto - stock.adobe.com
Container-basierte Anwendungen umfassend absichern
Für die risikominimierte Container-Nutzung ist ein holistischer Ansatz erforderlich, der die Supply Chain Security in den Fokus nimmt und alle Lebenszyklus-Phasen berücksichtigt.
Künstliche Intelligenz und Maschinelles Lernen, Edge Computing, Serverless Computing und auch die Containerisierung – was verbindet diese innovativen Technologien? Die Antwort ist einfach: Sie basieren auf Open-Source-Software.
Um die Wettbewerbsfähigkeit zu erhalten und die Innovationskraft zu stärken, kommen Unternehmen folglich kaum am Open-Source-Weg vorbei. Und wie überall in der IT darf dabei das Thema Sicherheit nicht zu kurz kommen. So weit, so gut. Rund um die Open-Source-Nutzung und damit auch um die Containerisierung existieren allerdings immer noch einige Irrtümer. Sie führen vielfach dazu, dass Unternehmen elementare Sicherheitsmaßnahmen nicht oder nur unzureichend ergreifen.
Irrtum 1: Sicherheit von Open-Source-Technologien ist Aufgabe der Community.
Prinzipiell zeichnet Open Source eine hohe Innovationskraft und Sicherheit aus. Dafür sorgen Communities mit tausenden von Mitwirkenden und in der Regel einer Vielzahl von Code-Reviewern. Trotzdem sind einige grundlegende Sicherheitsempfehlungen zu berücksichtigen.
So sollten Unternehmen bei der Container-Nutzung darauf achten, nur Container-Images aus vertrauenswürdigen Quellen einzusetzen. Zur Verfügung stehen dabei bewährte Basis-Images für das Linux-Betriebssystem und eine große Zahl zertifizierter Images für verschiedene Programmiersprachen, Middleware und Datenbanken. Mit einer digitalen Signatur kann das Sicherheitsniveau weiter erhöht werden, da sie bestätigt, dass ein Applikations-Container nicht durch einen Dritten verändert wurde.
Zudem sollte eine Registry genutzt werden, die Basisfunktionen zur Verwaltung der Container-Images enthält. Dazu gehört etwa ein rollenbasierter Zugriff für die Images, der die Push- und Pull-Berechtigungen regelt. Wichtig ist immer, dass es einen eindeutig festgelegten Workflow für den Zugang zu extern und intern erstellten Container-Images gibt. Idealerweise unterstützt die Registry auch eine Automatisierung der Richtlinien und Workflows zur Verwendung der Images.
Abgesehen von der Verifizierung der Herkunft eines Applikations-Containers ist auch die Überprüfung der Inhalte wichtig. Die Analyse des Programmcodes hinsichtlich Sicherheitslücken ist ein wesentlicher Erfolgsfaktor für die Entwicklung, Implementierung und den Betrieb vertrauenswürdiger Applikationen, die auf Container-Technologien basieren. Für die schnelle Überprüfung von Container-Inhalten ist der Einsatz von Sicherheitsscannern geeignet, die Schwachstellen in den Images erkennen.
Nicht zuletzt sollte ein Unternehmen aus Sicherheitsaspekten eine Plattform nutzen, die eine konsistente Entwicklung und Skalierung von containerisierten Anwendungen unterstützt. Wichtige Komponenten sind dabei Lifecycle-Management, Identitäts- und Zugriffsmanagement sowie die Sicherung der Plattformdaten.
Irrtum 2: Security ist keine Aufgabe der Entwickler.
Mit über einer Million Open-Source-Projekten ist es ein Leichtes für Entwickler, zu übernehmen, was andere entwickelt haben, es an die geschäftlichen Anforderungen anzupassen und es in der eigenen Umgebung einzusetzen. Gibt es für die Entwickler dabei jedoch keine Richtlinien, verliert man schnell den Überblick über mögliche Schwachstellen, die durch zahlreiche Versionen verschiedenster Bibliotheken im Unternehmen vorhanden sind.
Klare Policies und Regularien sind somit zwingend erforderlich, beispielsweise für die Kontrolle und Automatisierung der Erstellung von Containern. Unternehmen sollten außerdem Best Practices für die Sicherheit in der Anwendungspipeline beachten, vor allem im Hinblick auf die Integration automatischer Sicherheitstests in die Pipeline, einschließlich Registry, DIE (Integrierte Entwicklungsumgebung) und CI/CD-Tools. Zur Echtzeit-Überprüfung auf bekannte Sicherheitslücken und neue Schwachstellen ist es etwa möglich, Scanner mit CI zu integrieren.
Von Bedeutung sind zudem automatisierte Richtlinien, mit denen Unternehmen das Container- und Cluster-Deployment aus sicherheitstechnischer Sicht verwalten können. Dazu gehören ein richtlinienbasiertes Container Deployment, dass das Herunterladen von Images aus bestimmten Registries zulässt oder ablehnt, und ein richtlinienbasiertes Multi-Cluster-Management für das Deployment oder Migrationen über verschiedene Cloud-Anbieter hinweg.
Irrtum 3: Etablierte Sicherheitskonzepte für die Anwendungsentwicklung sind ausreichend
Container-Workload ist über viele Infrastruktur-Footprints verteilt – vom Rechenzentrum auf dem Campus bis zur Edge. In diesem Technologieumfeld kommt die traditionelle Perimeter-basierte Sicherheit an ihre Grenzen. Stattdessen muss jede Schicht des Infrastruktur-Stacks und jeder Schritt des Anwendungsentwicklungszyklus abgesichert werden. Zu berücksichtigen ist dabei etwa die große Zahl an Geräten, die im Bereich Internet of Things als Basis für die Container-Workloads dienen. Diese Geräte müssen immer auf dem aktuellen Patch-Level gehalten werden.
Ein Unternehmen kann zwar auf bewährte Security-Mechanismen zurückgreifen, sie müssen aber dem neuen Kontext angepasst werden. In einer Zeit des Software-defined Everything, in der eine Entkopplung der Software von der Hardware stattfindet und eine Vielzahl von softwarebasierten Technologien genutzt wird, sind auch andere Security-Konzepte erforderlich, etwa für Software-defined Network oder Software-defined Storage.
„Ein Unternehmen kann zwar auf bewährte Security-Mechanismen zurückgreifen, sie müssen aber dem neuen Kontext angepasst werden.“
Marie Innes, Red Hat
Irrtum 4: Security ist ein Audit-Thema
Security wird heute immer noch vielfach als Blocker gesehen, der die Entwicklung behindert. Folglich wird das Thema Security oft auch erst am Ende eines Entwicklungsprozesses aufgegriffen – oft erst dann, wenn eine Zertifizierung oder gesetzliche Regularien es erfordern.
Ein solches Vorgehen ist aus Sicherheitsgründen problematisch und darüber hinaus auch nicht effizient. Security muss als Teil eines ganzen Prozesses betrachtet und auch als Projektziel definiert werden. Dabei geht es keineswegs nur um technologische Fragestellungen, sondern auch um organisatorische Abhängigkeiten und eine enge Zusammenarbeit beziehungsweise geteilte Verantwortung aller Prozess-Stakeholder
Security kann also kein reines Audit-Thema sein. Das Gebot der Stunde lautet vielmehr Security by Design. Bezogen auf den Containerbereich und das Ziel „Einmal erstellen, überall bereitstellen“ heißt das, dass im Build-Prozess ein fehlerfreies Produkt entsteht, das im Produktivbetrieb eingesetzt wird. Dabei muss der Entwickler auch die angestrebte Unveränderlichkeit der Container berücksichtigen. Schließlich ist die Anwendung von Patching auf aktive Container kein gangbarer Weg. Container sollten immer neu erstellt und bereitgestellt werden.
Ein wichtiger Aspekt sind auch Shift-Left-Testing-Ansätze, also die frühzeitige Durchführung von Tests im Entwicklungsprozess. Sie führt zu einer schnelleren Fehlerbehebung und letztlich höheren Produktqualität. Im Prinzip geht es dabei um die Etablierung einer DevSecOps-Pipeline, bei der Sicherheitsaspekte in den DevOps-Prozess integriert werden. Idealerweise wird die Sicherheit dabei in reproduzierbarer und automatisierbarer Form möglichst nah am Quellcode implementiert – Stichwort „Security as Code“. Hier helfen eine durchdachte Automatisierung und ein gut integriertes Scan- und Test-Toolset dabei, die Geschwindigkeit, Agilität und Flexibilität beizubehalten, die DevOps letztlich auszeichnet.
Containerisierte Anwendungen umfassend sichern
Das Thema Sicherheit sollte sowohl organisatorisch als auch technologisch einen hohen Stellenwert einnehmen. Die verschiedenen Irrtümer zeigen, dass dabei teilweise noch Handlungsbedarf besteht. Vor allem muss der gesamte Lifecycle einer containerisierten Anwendung im Fokus stehen, also die Phasen „Design“, „Build“, „Run“, „Manage & Automate“ und „Adapt“.
„Sobald ein Unternehmen einen solchen ganzheitlichen Ansatz verfolgt, der IT-Security als kontinuierlichen Prozess begreift, ist es optimal aufgestellt für aktuelle und künftige Sicherheitsbedrohungen.“
Miriam Bressan, Red Hat
In der Design-Phase geht es dabei um die Identifizierung der Sicherheitsanforderungen und in der Build-Phase um die unmittelbare Integration von Sicherheit in den Applikations-Stack. Um den Betrieb sowie die Entwicklung zu entlasten, sollten vertrauenswürdige Plattformen mit erweiterten Sicherheitsfunktionen genutzt werden, deren Basis selbst unter Betrachtung der Supply Chain Security für Betriebssystem und Plattform-Software entwickelt wurde.
Die Phase „Manage & Automate“ umfasst 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.
Sobald ein Unternehmen einen solchen ganzheitlichen Ansatz verfolgt, der IT-Security als kontinuierlichen Prozess begreift, ist es optimal aufgestellt für aktuelle und künftige Sicherheitsbedrohungen. Und wenn die Sicherheit zum integralen Bestandteil der Prozesskette wird, ergibt sich automatisch ein positiver Nebeneffekt: Security wird nicht mehr als Blocker betrachtet, sondern vielmehr als Enabler einer modernen IT-Infrastruktur und damit auch als ein zentraler Innovationstreiber.
Über die Autorinnen:
Marie Innes ist Solution Architect bei Red Hat und Miriam Bressan ist Manager Solution Architects bei Red Hat.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
