Gastbeitrag Die Container-Technologie ermöglicht, eine Applikation mit all ihren Abhängigkeiten in einem Image zu verpacken und es ohne Änderungen von der Entwicklung über den Test bis in eine produktive Umgebung weiterzuleiten. Mit Containern lässt sich eine durchgängige Konsistenz in unterschiedlichen Umgebungen sicherstellen, egal ob die Container auf physikalischen Servern, in virtuellen Maschinen oder in Private und Public Clouds laufen.
Statische Sicherheitsrichtlinien und Checklisten reichen für Container jedoch nicht aus – und vor allem skalieren sie nicht. Um die Geschäftsvorteile von Containern umfänglich nutzen zu können, ist es notwendig, dass Unternehmen ihre IT-Sicherheitsmaßnahmen in regelmäßigen Abständen überprüfen und weiterentwickeln. Die Überwachung und Einhaltung einer hohen IT-Sicherheit ist eine permanente Aufgabe. Und sie muss in jeder Phase des Lebenszyklus einer Container-Applikation und der Infrastruktur berücksichtigt werden. Bei der Überwachung der Container-Sicherheit geht es um Themen wie Container Content, Container Registry, Continuous-Integration (CI)- und Continuous Delivery (CD)-Pipeline sowie Continuous Deployment Policies.
Entwickler und IT-Betrieb müssen dafür sorgen, dass Images sicher laufen. Jedes Container-Image besteht aus einem grundlegenden Linux User Space Layer sowie weiteren Applikations-abhängigen Layern. So bietet beispielsweise Red Hat über einen Container Catalog Basis-Images für das Linux-Betriebssystem sowie eine große Zahl zertifizierter Images für verschiedene Programmiersprachen, Middleware und Datenbanken. Wichtig ist, dass es einen eindeutig festgelegten Workflow für den Zugriff auf extern und intern erstellte Container-Images gibt. Unternehmen, die bereits ein Binary Repository wie JFrog Artifactory oder Sonatype Nexus einsetzen, können dieses für den Transport der Container-Images nutzen.
Unabhängig davon, welche Registries Unternehmen einsetzen: Entscheidend ist, dass sie über Funktionen verfügen, um Sicherheitsrichtlinien und Workflows für die Verwendung von in der Registry gespeicherten Container-Images zu automatisieren. Zudem sollte ein Rollen-basierter Zugriff für die Container-Images vorhanden sein. Dazu kommen Funktionen zur Kennzeichnung von Images: freigegeben nur für die Entwicklung, für Tests und schließlich für die Übergabe in den produktiven Betrieb – egal, ob auf Bare-Metal-Servern, in virtuellen Maschinen oder in einer Cloud-Umgebung.
Wie bei jeder Applikation ist das Management der Production Builds ein zentraler Baustein zur Sicherstellung der Sicherheit eines Software Stack. Eine Source-to-Image-Funktion vereinfacht Entwickler- und IT-Betriebsteams die Zusammenarbeit in einer reproduzierbaren Build-Umgebung. Sobald ein Build abgeschlossen ist, sollte die Source-to-Image-Funktion das Image automatisch in die Private Registry transportieren.
Dies geschieht automatisch, wenn Entwickler eine Source-to-Image-Funktion verwenden. Viele Unternehmen nutzen Signaturen als weiteren Sicherheitscheck für Container-Images. Bevor ein Image in den produktiven Betrieb geht, müssen Signaturen verifiziert werden. Vielfach erfolgt die Prüfung heute noch per Skript; wünschenswert ist eine standardmäßige Integration in den Container Lifecycle.
Für den Fall, dass während des Build-Prozesses etwas schief geht oder für Situationen, in denen eine Schwachstelle entdeckt wird, nachdem ein Image implementiert wurde, benötigen Unternehmen einen weiteren Security Layer: Wichtig ist dieser deshalb, weil keine im Einsatz befindlichen Container gepatcht werden. Container sollten vielmehr neu erstellt und automatisch ersetzt werden.
Die Container-Infrastruktur schützen
Beim Schutz der Container-Infrastruktur sind beispielsweise folgende Aspekte gefragt: Container-Plattform, Container-Host, Multi-Tenancy, Network Isolation und Storage. Die sichere Nutzung von Containern in einem Unternehmensrechenzentrum und in einer Cloud-Umgebung erfordert ein Betriebssystem, das die Mandantenfähigkeit der Container Runtime verwalten kann: Die Multi-Tenant-Isolierung auf der Container-Plattform spielt eine entscheidende Rolle im Rahmen eines umfassenden Container-Sicherheitskonzepts – On-Premise und in der Cloud.
Die klare Trennung soll sicherstellen, dass kein Container Zugriff auf die Ressourcen eines anderen Containers erhält und dass auch die Ressourcen des zugrundeliegenden Hosts nicht zugänglich sind. Zur Umsetzung der Multi-Tenant-Isolierung stehen grundlegende Linux-Sicherheitstechnologien zur Verfügung. Es gibt mehrere Security Levels zum Schutz von Containern unter Linux: SELinux (Security-Enhanced Linux), Linux Namespaces, CGroups und Read Only Mounts. CGroups stellen sicher, dass ein einzelner Container nicht eine große Menge an Systemressourcen verbrauchen kann, und sie verhindern so einfache Denial-of-Service-Angriffe.
Im Kern ist SELinux ein Labeling-System. Jeder mit SELinux laufende Prozess erhält ein Label; das gilt auch für jedes File, Directory oder System Object. Standardmäßig stehen mehr als 400 SELinux-Module und -Policies zur Verfügung. Diese Vorschriften definieren Zugriffsregeln und der Kernel setzt diese durch. SELinux fungiert als Schutzmauer zwischen nicht vertrauenswürdigen Applikationen und dem restlichen Betriebssystem.
Linux Namespaces bieten die Grundlagen der Container-Isolierung. Ein Namespace trennt containerisierte Prozesse voneinander und präsentiert jedem Prozess nur seine „eigene Welt.“ Die aus Container-Sicht wichtigsten Namespaces sind der PID Namespace und der Network Namespace. Der PID Namespace sorgt dafür, dass ein containerisierter Prozess nur die Prozesse innerhalb des Containers sieht, aber keine Prozesse anderer Container auf dem Shared Host. Der Network Namespace ist eine isolierte Umgebung, die über einen eigenen Networking Stack verfügt und Container davor schützt mit anderen Containern auf dem gleichen Host zu kommunizieren.
Ein weiteres Beispiel sind User Namespaces. Sie ähneln den PID Namespaces und ermöglichen es einem Administrator, bestimmte Host-UIDs zu definieren, die einem Container zugeordnet sind. Folglich erhält ein Prozess dann volle Root-Privilegien für Operationen innerhalb des Containers und gleichzeitig darf er keine Operationen außerhalb des Containers ausführen. User Namespaces bietet Servern, die Linux-Container ausführen, zusätzliche Sicherheit, indem sie die Isolierung zwischen Host und Containern verbessern. Administratoren von Containern sind dann nicht mehr in der Lage, administrative Operationen auf dem Host durchzuführen, was die Sicherheit erhöht.
Mit Read Only Mounts lässt sich das Filesystem vor Containern schützen. Durch einen Read-Only-Zugriff auf Kernel-Schnittstellen wird ein Container daran gehindert, in das virtuelle Dateisystem sysfs zu schreiben und Kernelparameter zu ändern, die das gesamte System destabilisieren können.
Immer mehr Applikationen erfordern eine Zwei-Wege-Verschlüsselung. Dabei müssen beide Seiten ihre Identität nachweisen, um verschlüsselte Daten über eine sichere Verbindung austauschen zu können. Red Hat OpenShift Container Platform beispielsweise bietet standardmäßig einen containerisierten stateless HAProxy als Default Router. Es gibt drei konfigurierbare Möglichkeiten zur TLS-Terminierung: Edge, Re-Encryption und Passthrough. Entscheidend dabei ist, dass Entwickler und Administratoren auch beim Verschlüsseln eng zusammenarbeiten – das beginnt bei der Erstellung der Container-Images und reicht bis zu einem sicheren Einsatz der Container-Images über den gesamten Lebenszyklus.
In diesem Online-Seminar stellen wir Ihnen SkySQL vor, erläutern die Architektur und gehen auf die Unterschiede zu anderen Systemen wie Amazon RDS ein. Darüber hinaus erhalten Sie einen Einblick in die Produkt-Roadmap, eine Live-Demo und erfahren, wie Sie SkySQL innerhalb von nur wenigen Minuten in Betrieb nehmen können.
Nur rund die Hälfte schaltet während der Feiertage komplett vom Job ab. Die anderen sind…
Security-Experten von Check Point sind einer neuen Angriffsart auf die Spur gekommen, die E-Mail-Schutzmaßnahmen umgehen…
Hinter 84 Prozent der Zwischenfälle bei Herstellern stecken Schwachstellen in der Lieferkette. Auf dem Vormarsch…
Es kommt angeblich 2028 auf den Markt. Das aufgeklappte Gerät soll die Displayfläche von zwei…
Das System basiert auf Hardware von HPE-Cray und Nvidia. Die Inbetriebnahme erfolgt 2027.
Die Bundesnetzagentur hat ihr Gigabit-Grundbuch aktualisiert. Drei von vier Haushalten sollen jetzt Zugang zu Breitbandanschlüssen…
