4 Fragen zum Thema Kubernetes Security

Bei Kubernetes Security sollte es vor allem um Prävention gehen. Diese Checkliste unseres Partners NeuVector hilft dabei.

Die Container-Lösung Kubernetes findet heute in der Anwendungsentwicklung breiten Einsatz. Denn Container beschleunigen und vereinfachen die Entwicklung und den Rollout von Anwendungen erheblich. Rechen- und Speicherressourcen werden sparsamer genutzt und Container machen Anwendungen plattformunabhängig und portabel. Damit eignen sie sich ideal für den Einsatz in modernen Multi-Cloud-Umgebungen.

Hand in Hand mit jeder Technologie geht stets die Frage nach ihrer Sicherheit. Bei Kubernetes Security geht es insbesondere um Prävention, um Sicherheitsvorfälle von vornherein zu vermeiden. Und nicht erst zu handeln, wenn das sprichwörtliche Kind in den Brunnen gefallen ist. Dabei ist es wichtig, dass die Sicherheitsmaßnahmen auch in containerisierten Umgebungen an die individuellen Bedürfnisse des Unternehmens angepasst werden. Ob das bereits so ist, können Unternehmen herausfinden, indem sie sich zum Thema Kubernetes Security mit folgenden vier Fragestellungen befassen:

• Frage #1: Braucht man Observability oder Network Inspection?
• Frage #2: Was genau bieten Kubernetes oder das genutzte Service Mesh NICHT?
• Frage #3: Braucht man Kubernetes Security, wenn das Unternehmen bereits eine Web Application Firewall nutzt?
• Frage #4: Wo liegen die Grenzen von Sicherheitstools in containerisierten Umgebungen?

weiterer Inhalt

• Paketerfassung wichtiger Aspekt
• Partnerschaft für Kubernetes Security

Frage #1: Braucht man Observability oder Network Inspection?

Beim Einsatz von Kubernetes werden oft auch sogenannte Service Meshs verwendet. Dabei handelt es sich um eine Infrastrukturschicht, die direkt in der Anwendung integriert ist. Mit einem Service Mesh lässt sich überprüfen, wie unterschiedliche Bausteine einer Anwendung ihre Daten miteinander teilen und wie gut sie interagieren. So wird die Kommunikation optimiert und Ausfälle können minimiert werden, auch wenn eine Anwendung immer größer wird.

Nun gehen DevOps-Teams oftmals davon aus, dass bei der Nutzung eines Service Mesh auch Netzwerksicherheit und Observability Teil der Dienste-Erkennung sind. Und genau diese Annahme führt häufig zu dem Irrglauben, dass Observability eine „vollumfängliche Beobachtbarkeit" beinhaltet. Dem ist aber nicht so. Denn ein Service Mesh kann nur erkennen, was zuvor dafür definiert wurde. Es bietet somit keine „Beobachtbarkeit“ für Anomalien im Netzwerkverkehr. Doch genau diese gilt es zu erreichen. NeuVector bietet dazu eine Lösung für Kubernetes Security, die all diese wichtigen Netzwerkaktivitäten erkennt - ob vorab definiert oder nicht. Denn die Fähigkeit, vollständige Einsicht in jede Schicht des Netzwerks zu haben, ist der kritischste Teil der Laufzeit-Container-Sicherheit.

NeuVector bietet hierzu Layer-7-Inspection. Das ermöglicht es, den Container-Netzwerkverkehr zu inspizieren und genau zu erkennen, wie jeder Anwendungsdienst mit anderen Anwendungsdiensten kommuniziert. Unternehmen erhalten damit eine vollständige Transparenz des Netzwerkverkehrs und können Angriffe stoppen, bevor sie eine Anwendung oder einen Workload erreichen. Zudem verhindert die Lösung, dass Unternehmensdaten durch kompromittierte Anwendungen über das Netzwerk verschickt werden.

Hilfreiche Fragestellungen

Um herauszufinden, ob ein Unternehmen eher Observability („Beobachtbarkeit“) oder umfassende Network Inspection benötigt hilft es, sich folgende Fragen zu stellen.

• Hat das DevOps/IT-Team wirklich Einblick in den gesamten Netzwerkverkehr oder nur in vorab definierte Teilbereiche?
• Wie wird zwischen normalem und anormalem Datenverkehr unterschieden?
• Bietet das eingesetzte Service Mesh Observaibilty oder kann es auch unbekannten Netzwerkverkehr abfangen?
• Sind Systemaufrufe der beste „Kill-Chain-Punkt“ für Netzwerkaktivitäten, um unerwünschtes Eindringen abzuwehren? Oder ist das Netzwerk selbst der beste Kill-Chain-Punkt für die Netzwerkaktivitäten?

Frage #2: Was genau bieten Kubernetes oder das genutzte Service Mesh NICHT?

Bei der Anschaffung einer neuen Lösung liegt das Augenmerk oft auf all den vielen Features und Funktionen, die sie bietet. Dabei verliert man schnell aus den Augen, darauf zu achten, welche Funktionalitäten eben NICHT enthalten sind. Aber genau diese Funktionen könnten für das Unternehmen letztlich am wichtigsten sein. Es kann beispielsweise vorkommen, dass es beim Zugriff auf sensible Datenspeicher plötzlich ein erhöhtes Datenaufkommen gibt. Die Ursache hierfür lässt sich jedoch nicht genau bestimmen, denn das Unternehmen hat dazu nichts im Service Mesh definiert. Wie also herausfinden, ob es sich um unbefugten Datenzugriff handelt und Daten geklaut werden?

Besteht nun lediglich Beobachtbarkeit (Observability) und Zugriff auf die Netzwerksegmente, die vorab definiert wurden, ist guter Rat teuer. Denn es könnte sein, dass ein Passwort geknackt wurde, das Zugang zur Infrastruktur des Unternehmens ermöglicht. Dabei muss es sich nicht unbedingt um SQL-Injection oder den Hack der Firewall handeln. Der „Täter“ kann auch aus dem eignen Unternehmen kommen. Er konnte sich vielleicht in einen Container hacken und dort nach offenen Ports auf anderen Containern suchen. Und er könnte dort vielleicht ein Root-Kit, Cloaks oder eine andere Hintertür installiert haben, um zukünftige Spionageaktionen zu verbergen.

Dann ist es schwer zu erkennen, ob jemand unerwünscht in das Netzwerk eingedrungen ist und was konkret verändert wurde. Und es ist schwer auffälliges Verhalten zu erkennen, dass sich nach außen wie legitimes Verhalten präsentiert. Doch eigentlich ist es in containerisierten Umgebungen heute wichtig, genau diese Arten von Auffälligkeiten erkennen zu können.

Hilfreiche Fragestellungen

Für Kubernetes Security ist es wichtig, folgende Fragen beantworten zu können:

• Angenommen die Vernetzung innerhalb eines Pods ist offen: Welche möglichen negativen Folgen hat es, wenn einer oder alle Container in diesem Pod kompromittiert werden?
• Wenn die Vernetzung von Pods tatsächlich offen ist: Was will man dagegen tun?
• Wurden alle schützenswerten Ressourcen identifiziert?
• Welche Aspekte und Ressourcen wurden bisher nicht identifiziert? Sollten sie vielleicht ebenfalls abgesichert werden? (Nicht vergessen: was nicht definiert wurde, ist nicht geschützt…)

Frage #3: Braucht man Kubernetes Security, wenn das Unternehmen bereits eine Web Application Firewall nutzt?

Fakt ist: Web Application Firewalls (WAF) können Ost-West-Netzwerkverkehr innerhalb einer containerisierten Umgebung nicht identifizieren oder blockieren. Eine WAF definiert Deployments und Services wie eine Straße auf einer Landkarte. Soll heißen: Sie definiert wohin der Datenverkehr gehen soll. Aber sie kann niemanden davon abhalten, in einen Graben zu fahren oder eine andere Strecke zu nehmen.

Auf eine Anwendung bezogen werden die Container folglich der Route folgen, die vorab definiert und festgelegt wurde. Ein Hacker wird jedoch versuchen, die Container auf eine andere Route umzuleiten, um an die Unternehmensdaten zu kommen. Und eine Web Applikation Firewall kann das nicht verhindern, da ihr der „Einblick“ in diesen Datenverkehr fehlt.

Hilfreiche Fragestellungen

Es gilt also herauszufinden:

• Hat das DevOps/IT-Team wirklich Einblick in den gesamten Datenverkehr oder nur in vorab definierte Bereiche?
• Wie kann Datenverkehr, der nicht spezifisch definiert wurde, gestoppt werden?
• Wie kann sichergestellt werden, dass Container nicht über Layer 7 der Netzwerkschicht via Tunneling angegriffen werden?
• Können Datenpakete innerhalb eines Clusters abgefangen werden, um zu sehen was in diesem Datenverkehr transportiert wird?

Frage #4: Wo liegen die Grenzen von Sicherheitstools in containerisierten Umgebungen?

Unter Umständen ist es schwer, die Grenzen eines bestimmten Tools zu kennen, bevor man es in der speziellen Unternehmensumgebung einsetzt. So kann es vorkommen, dass ein Unternehmen zwar weiß, dass es PCI-konform sein muss. Die Anforderungen an Data Loss Prevention (DLP) zu erfüllen, war in der alten Umgebung auch kein Problem. Doch inzwischen wurde die monolithische Anwendung mit Hilfe von Microservices und Containern modernisiert oder komplett neu geschrieben. Der ehemalige DLP-Ansatz hält einem Audit dann nicht mehr wirklich stand. 

Im Bemühen darum, DevOps-Vorgaben umzusetzen, wird die Sicherheit oftmals noch nicht mit integriert. So weiß das Unternehmen unter Umständen gar nicht, dass auch beim Einsatz von Containern auf DLP zu achten ist. Das Problem ist also gar nicht bekannt, weil man nicht einmal weiß, dass es sich um ein mögliches Problem handelt. Ein häufiges Beispiel, das viele Security Tools betrifft, ist der Umgang mit Sicherheitsabweichungen. In den allermeisten Fällen lauten die Einstellungen, Sicherheitsabweichungen „zu identifizieren“. Viel sinnvoller wäre es jedoch, Sicherheitsabweichungen „zu verhindern“. Viele Hersteller behaupten zwar, diese Funktionalität in ihren Produkten zu haben. Doch meist sind die Lösungen nur in der Lage, Aktivitäten zu erkennen, wenn der Angreifer schon im Container ist.

Bei Kubernetes Security ist es aber wichtig, nicht erst auf einen Sicherheitsvorfall zu reagieren, wenn der Software Kernel bereits kompromittiert wurde. Vielmehr gilt es zu vermeiden, dass Angreifer überhaupt zum Kernel der Anwendung vordringen können. Die Lösung von NeuVector für Kubernetes Security ist derzeit die einzige, die Sicherheitsabweichungen von vornherein verhindern kann. Denn sie stoppt Netzwerkanomalien oder anormale Prozesse, ohne dass die DevOps/IT-Teams eingreifen müssen. Nichts muss manuell genehmigt oder abgelehnt werden. Vielmehr erlernt die Lösung von NeuVector das spezifische Netzwerk- und Prozessverhalten der jeweiligen Unternehmensumgebung. Dies geschieht automatisch und so granular wie möglich anhand individueller Protokollüberprüfungen und Netzwerkrichtlinien auf Layer 7.

Hilfreiche Fragestellungen

Auch zu diesem Aspekt sollten sich Unternehmen folgende Fragen stellen:

• Können Netzwerkpakete innerhalb einer containerisierten Umgebung erfasst werden?
• Werden Netzwerksicherheitsrichtlinien automatisch auf Layer 7 erstellt?
• Wird das Layer-7-Protokoll überwacht, um Protocol-Tunneling-Angriffe zu verhindern?
• Können die bestehenden Netzwerksicherheitsregeln geordnet werden?
• Umfassen die bestehenden Netzwerksicherheitsregeln Allow- und Deny-Regelwerke?
• Können Netzwerk-, Prozess- und Datei-Sicherheitsrichtlinien, die dem individuellen Verhalten des entsprechenden Dienstes oder der Anwendung entsprechen, automatisch erstellt werden?
  
  

  

  Die NeuVector-Komponenten sind Container, die sich leicht auf virtuellen Maschinen oder Bare-Metal-OS-Umgebungen einsetzen lassen.

Paketerfassung wichtiger Aspekt für Kubernetes Security

Die tatsächliche Erfassung von Daten auf Paketebene (Paket Capture) ist auch bei Kubernetes Security wichtig. Denn nur sie bietet echten Einblick in den Netzwerkdatenverkehr und damit die Möglichkeit, Datenverkehr auf Netzwerkebene zu erlauben oder zu blockieren. Das Filtern von Sys Calls auf Kernelebene kann den Netzwerkverkehr nicht blockieren und auch nicht erfassen. Und wenn der Kernel erst einmal anormalen Netzwerkverkehr meldet, ist es ohnehin schon zu spät.

Deshalb ist es so wichtig, auch beim Einsatz von Kubernetes Netzwerkpakete inspizieren, validieren, erfassen und blockieren zu können. Denn damit haben Unternehmen Kontrolle über das erste und wichtigste Element der Angriffskette: das Netzwerk. Die Fähigkeit, Pakete auf Netzwerkebene erfassen zu können, bietet somit nicht nur bessere Observability, sondern auch bessere Sicherheitskontrollen.

Partnerschaft für Kubernetes Security

Jedes Unternehmen ist einzigartig und hat damit auch ein sehr individuelles Risikoprofil. Da ist es schwer, wirklich jede Schwachstelle zu finden oder die Sicherheitseinstellungen perfekt umzusetzen. Sehr viele bestehende Lösungen für Netzwerksicherheit bieten heute sehr guten Schutz. Doch das bedeutet nicht automatisch, dass sie auch die beste Wahl für die Absicherung von Netzwerkelementen in containerisierten Umgebungen sind.

Deshalb sollten sich Unternehmen vor allem fragen: Wie würden sie aktuell herausfinden, ob ihre Anwendungsumgebung kompromittiert wurde? Und wie lange würde es dauern, dieses herauszufinden? Wollen oder können Unternehmen diesen Fragestellungen nicht auf den Grund gehen, bietet sich die Zusammenarbeit mit einem Lösungsanbieter wie zum Beispiel einem Cloud Provider an.

So hat beispielsweise plusserver gerade die Cloud-native Sicherheitsplattform von NeuVector in sein Produktportfolio aufgenommen. So haben die Kunden die Möglichkeit, eine Kubernetes-Umgebung und die passende Security-Lösung aus einer Hand zu beziehen.