Cybersicherheit und Container: Umstellung auf DevSecOps

10. April 2019

Die schnelle Einführung von Containern im Unternehmen sind eine einzigartige Gelegenheit dar, die generelle Sicherheitsstrategie zu verändern. Container stellen eine gute Möglichkeit dar, die Kluft zwischen Entwicklungs- und Sicherheitsteams zu überbrücken.

Anzeige
Leaderboard AD Serview

Davon ist Palo Alto Networks überzeugt. Ist es möglich, dass Container das Unternehmen einen Schritt näher an DevSecOps heranbringen? Palo Alto Networks nimmt das Thema unter die Lupe. Computing hat mehrere Entwicklungen durchlaufen. Die erste Welle war der Client-Server, der auf Bare Metal mit einem einzigen Betriebssystem und typischerweise einer Anwendung läuft. Die zweite Welle kam, als VMware 2001 in den Servermarkt einstieg. Dies läutete das Zeitalter des virtualisierten Computings ein. Die dritte Welle bringt die Gegenwart mit Containern. Die Einführung von Containern steht für die Geschwindigkeit von DevOps und den Wunsch, Anwendungen mobil zu machen. Derzeit noch nicht weit verbreitet im Unternehmen ist die vierte Evolution: Serverless oder Function as a Service (FaaS). Dies stellt eine vollständige Abstraktion des Computings dar, wobei der Verbraucher hardware- und betriebssystemunabhängig ist. Die beiden bekanntesten Implementierungen von FaaS sind Google Cloud Functions und AWS Lambda.

Sicherheit aufbauen

Sicherheit in die Container-Build-Phase zu bringen, bedeutet, sich auf die physische Konstruktion zu konzentrieren. Das Erste, was vor dem Bau eines Hauses ansteht, ist festzulegen, wie der gewünschte Endzustand aussehen soll. Bei der Containersicherheit ist das nicht anders, wie Palo Alto Networks berichtet. Die Sicherheit in der Bauphase sollte sich auf die Beseitigung von Schwachstellen, Malware und unsicherem Code konzentrieren. Da Container aus Bibliotheken, Binärdateien und Anwendungscode bestehen, ist es wichtig, dass Unternehmen ein offizielles Containerregister einrichten, wenn es nicht bereits existiert. Es ist die Aufgabe des Sicherheitsteams, hier Sicherheitsstandards umzusetzen. Das Hauptziel der Identifizierung und Erstellung einer Standard-Container-Registry ist die Erstellung vertrauenswürdiger Images. Ein Prozess muss festgelegt und automatisch durchgesetzt werden, dass kein Container aus einer nicht-vertrauenswürdigen Registry bereitgestellt wird. Mit über zwei Millionen Dockerized-Anwendungen ist Docker Hub wahrscheinlich das bekannteste Containerregister. Das bedeutet, dass es auch eine ideale Basis ist, um ein Gespräch mit den Entwicklern zu beginnen.

Sicherheit bereitstellen

In der Bereitstellungsphase verlagert sich der Fokus darauf, dass die Teams die Dinge richtig zusammenstellen. Es kann ein Image vorliegen, das zwar keine Schwachstellen aufweist, aber wenn es auf einem unsicher konfigurierten Kubernetes-Pod bereitgestellt wird, ist das Containerrisiko nicht ausreichend berücksichtigt. Ein Beispiel dafür ist dieser Fall: Die Bedrohungsforschung von Palo Alto Networks ergab, dass 46 Prozent der Unternehmen den Traffic zu Kubernetes-Pods von jeder Quelle akzeptieren. In der On-Prem-Welt ist dies gleichbedeutend mit der Bereitstellung eines Servers und dem anschließenden Offenlassen des Servers für das Internet. Unternehmen würden dies vor Ort nicht tolerieren, warum aber machen genau das fast die Hälfte der Unternehmen in der Public Cloud? Die Bereitstellung einer sicheren Konfiguration kann durch die Annahme eines Sicherheitsstandards sowohl für die Orchestrierung als auch für die Container-Engine der Wahl erreicht werden. Nicht zu vergessen ist, die notwendigen Prozesse und Tools für die Automatisierung und Überwachung zu installieren. Das Center for Internet Security (CIS) hat hier hervorragende Arbeit geleistet, um Sicherheitsstandards für Docker und Kubernetes zu schaffen, was sich als Ausgangspunkt anbietet. Wenn die Sicherheit richtig umgesetzt ist, sollte nur das „Gute“ es in die Runtime schaffen.

Runtime-Sicherheit

Bei der Laufzeitsicherheit geht es darum, neue Schwachstellen in laufenden Containern zu identifizieren und zu wissen, wie der Normalzustand aussieht. Dazu gehört auch die Untersuchung verdächtiger/anomaler Aktivitäten, die auf Zero-Day-Angriffe hinweisen könnten. Wenn das Sicherheitsteam von Anfang an dabei war (Build-Phase), ist es weitaus weniger komplex, Runtime-Sicherheit umzusetzen, anderenfalls ist es am besten, rückwärts zu arbeiten. Es ist wichtig, zu gewährleisten, dass der Endzustand sicher ist. Wenn man sich aber nur auf die Laufzeit konzentriert, werden die gleichen Probleme wahrscheinlich immer wieder auftreten. Interessanterweise stellte das IBM Systems Sciences Institute fest, dass die Kosten für die Behebung eines Fehlers während der Wartungsphase (d.h. der Laufzeit) 100-mal höher sind als bei der Konstruktion.

Einen Schritt näher in Richtung DevSecOps

Die schnelle Einführung von Containern im Unternehmen stellt nach Meinung von Palo Alto Networks eine einzigartige Möglichkeit dar, die Sicherheit zu verändern. Wenn Sicherheit von Anfang an in den Entwicklungszyklus integriert wird, werden sowohl das Sicherheitsteam als auch die Entwicklungsabteilung ein erhöhtes Verantwortungsbewusstsein spüren. Unternehmen können dies erreichen, indem sie ihre Sicherheitsbemühungen auf die Containersicherheitstriade Build, Deployment und Run konzentrieren. Sicherheitsteams, die dies im Rahmen einer ganzheitlichen Cloud-Sicherheitsstrategie umsetzen, werden feststellen, dass Container genau das sind, was sie brauchen, um DevSecOps einen Schritt näher zu kommen.

Palo Alto Networks

Lesen Sie auch