Red Hat bietet mit OpenShift eine Container-Orchestrierung an, die in der Basis auf Kubernetes aufbaut und von Red Hat mit Enterprise-Features erweitert wurde.
Während viele Unternehmen Ihre klassische IT mit Bordmitteln wie SE Linux und Windows Defender absichern und zusätzlich Firewalls erfolgreich gegen Bedrohungen von außerhalb einsetzen, sind sie im Container-Umfeld weniger restriktiv. Bereits mit der Implementierung einiger Standards erreichen Sie schon ein hohes Maß an Sicherheit.
Container Security ist ein komplexes Themenfeld. Viele Unternehmen setzen in der Sicherung Ihrer klassischen IT-Infrastruktur auf Windows Defender, SE Linux und nach außen über entsprechende Firewalls.
Gleichzeitig gibt es aber auch eine Menge Schatten-IT, für die sich niemand verantwortlich fühlt und die oft nur unzureichend abgesichert ist, zum Beispiel mit dem Passwort “1234”. Mit dem Einsatz von Containern - egal ob Docker, Kubernetes oder OpenShift - hat die Komplexität der IT-Landschaft nochmal zugenommen und die Kurzlebigkeit solcher Container erschwert das Prüfen von Sicherheitsfeatures. Zudem besteht die Gefahr, dass sich jeder User auf scheinbar vertrauenswürdige Images verlässt.
Es gibt dennoch Wege, auch Container nachhaltig abzusichern und gegen Angriffe und Missbrauch zu schützen. Die Implementierung von Container-Security setzt am Container-Lifecycle an, bei dem wir die Phasen Build, Deploy und Run unterscheiden können. In jeder Phase können wir das Maß an Sicherheit erhöhen, in dem wir uns anschauen, welche Komponenten jeweils eine Rolle spielen.
Wir unterstützen Sie gerne bei der Entwicklung und Umsetzung Ihrer individuellen Container-Sicherheitsstrategie via:
Während der Build-Phase kommt es darauf an, die einzelnen Komponenten, die am Build-Prozess beteiligt sind, abzusichern.
Gelingen kann dies durch die Nutzung von Drittinhalten aus vertrauenswürdigen Quellen oder der Verwendung einer eigenen, privaten Container Registry, mit integriertem Vulnerability-Scan. Alle Container, die man verwenden möchte aber nicht selbst gebaut hat, sollte man vor Verwendung auf Sicherheitslücken prüfen und sicherstellen, dass man selbst immer auch Container verwendet, die man geprüft hat.
Ein weiterer Weg, während der Build-Phase für ein hohes Maß an Sicherheit zu sorgen, ist Automatisierung. Vulnerability Scans von Container Images prüfen, dass keine Passwörter in Klartext, Root User-Berechtigungen etc. verwendet wurden. Sie sollten auf jeden Fall als fester Bestandteil von CI-/CD-Pipelines implementiert werden.
Darüber hinaus sollte versucht werden, sicherheitsrelevante Prozesse in Init-Container während der Pod-Initialisierung auszulagern oder Dienste wie Vault als Sidecar-Container in den Pod zu implementieren.
In der Deploy-Phase kommt es darauf an, die Containerplattform entsprechend zu sichern und sicherzustellen, dass diese nicht angegriffen werden kann.
Dabei kann schon die Wahl des zugrunde liegenden Betriebssystems der Containerplattform eine große Rolle spielen. Insbesondere in einem Kubernetes- oder OpenShift-Cluster ist es sinnvoll, dass alle Betriebssysteme gleich konfiguriert und im Optimalfall auch automatisiert ausgerollt werden können.
Bei der Auswahl sollte ein Betriebssystem gewählt werden, welches für den Betrieb von Containern ausgelegt ist und nur entsprechend wenige Systemeinstellungen zu ändern erlaubt. Neben dem zugrundeliegenden Betriebssystem sollte auch sichergestellt werden, dass die Containerplattform über ein solides Rollen- und Berechtigungs-Konzept verfügt, wodurch Außenstehende keinen Zugriff auf die Containerplattform erlangen und ihnen der Zugang entsprechend erschwert wird.
Dabei ist es auch möglich, Single-Sign-On auf Basis des Active Directory zu implementieren, wodurch nur registrierte Nutzer Zugang zum System erhalten. Ein wichtiger Punkt, den man beim Betrieb der Containerplattform berücksichtigen sollte, ist die Implementierung entsprechender Policies, die es unterbinden, dass sogenannte Privileged Pods mit De facto-Administrationsrechten auf das Betriebssystem ausgerollt werden, da diese ein besonders hohes Sicherheitsrisiko darstellen.
Während die ersten beiden Phasen darauf hinarbeiten, dass das Umfeld des Containers sicher ist und auch im Container selbst keine Sicherheitslücken aufklaffen, wird in der Run-Phase alles daran gesetzt, diesen während des Betriebs zu sichern.
Containerplattformen setzen dabei auf die Isolation von Containern und Anwendungen. Über Netzwerkpolicies ist es sinnvoll, innerhalb der Software-Defined-Networks Mikrosegmentierung zu implementieren, um den Zugriff auf Daten und Anwendungen einzuschränken und damit gegen potenzielle Angriffe abzusichern.
Containerplattformen wie OpenShift verschlüsseln zudem den Pod-To-Pod-Traffic. Mit Hilfe von Sidecar-Containern können Anwendungs-Pods mit zusätzlichen Logging- und Monitoring-Agents ausgestattet werden, die mit dem zentralen Monitoring- oder Logging-System kommunizieren und Realtime-Auswertungen und Alerting ermöglichen.
Containerplattformen bieten zudem Threat Detection und ermöglichen es damit, auf Angriffe beziehungsweise atypisches Verhalten der Pods zu reagieren.
Red Hat bietet mit OpenShift eine Container-Orchestrierung an, die in der Basis auf Kubernetes aufbaut und von Red Hat mit Enterprise-Features erweitert wurde.
Quay ist eine Container Registry, die Container-Images sicher speichert, verteilt und ausrollt - egal auf welcher Infrastruktur.
Bei Falco handelt es sich um ein cloud-native Open Source-Projekt, welches de facto die Threat Detection für Containerplattformen darstellt.
Die Zukunft der Anwendungsentwicklung hat mit der Containertechnologie bereits begonnen. Branchen-Kennern zufolge gerät Anwendungssicherheit in einer Zeit, in der immer häufiger immer gravierendere Sicherheitslücken aus Entwicklung und Betrieb auftreten, zunehmend mehr in den Fokus von IT-Security-Abteilungen in Unternehmen.
Der Trend geht zur Umsetzung von Zero Trust Szenarien, bei denen in jeder Phase des Lifecycles versucht wird, das Maximum an Sicherheitsmechanismen zu implementieren. In der Build-Phase zählt man dazu unter anderem Rootless Builds, verschlüsselte Container, Keyless Image Signing oder einen weitestgehend automatisierten Build-Prozess.
Die Deploy-Phase wird durch die harte Trennung von Mandanten und durch von Dritten zertifizierte Container-Images geprägt sein.
In der Run-Phase werden automatisierte Service Mesh Policies unabdingbar sein, um die komplexen Prozesse zwischen den Pods einer Anwendung abzusichern. Darüber hinaus werden Containerplattformen mit der Zeit und auf Basis des Anwendungsverhaltens immer intelligenter und können entsprechende Regeln beziehungsweise Handlungsempfehlungen vorschlagen.
Gern stehen wir Ihnen mit Know-how, konkreten Unterstützungsleistungen und zugehörigen Lizenz- und Supportangeboten zur Verfügung.