Container in der Cloud per Zero-Trust-Modell absichern

Zero-Trust-Prinzipien für Container

Das Zero-Trust-Modell ersetzt ein vorbehaltloses Vertrauen mit einer gründlichen Verifikation, die jedes Mal durchgeführt werden muss, bevor ein Zugriff auf einen Dienst, ein Gerät, eine Anwendung oder einen Datenspeicher möglich ist. Diese Voraussetzung gilt auch dann, wenn sich etwa eine Maschine an einem bislang als vertrauenswürdig eingestuften Ort befindet oder wenn sich ein Anwender an einem vertrauten Netzwerk anmelden will.

Zero Trust verändert das alte Motto vertrauen, aber überprüfen in niemals vertrauen, sondern immer überprüfen. Damit ersetzt es das bisher oft angenommene gegenseitige Vertrauen mit Verfahren, die authentifizierte Zugriffe und zentralisierte Netzwerkkontrollen vorschreiben.

Zusätzlich erfolgen alle Verbindungen nur noch verschlüsselt. Mit einem solchen System lassen sich auch die Sicherheitsrisiken in dezentralisierten IT-Umgebungen adressieren. Zero Trust ist damit das ideale Modell, um für eine umfassende Sicherheit in Cloud-basierten Container-Umgebungen sorgen zu können.

Unternehmen können weiterhin traditionelle, auf dem Perimeter aufsetzende Maßnahmen und Firewalls verwenden und gleichzeitig das Zero-Trust-Konzept für die Maschine-zu-Maschine-Kommunikationen zwischen Containern und Microservices nutzen. In einem solchen Umfeld gilt jedoch eine Reihe von Prinzipien, die eingehalten werden müssen:

• Es darf kein vorgegebenes gegenseitiges Vertrauen zwischen Containern geben, sondern nur einen authentifizierten Zugriff auf Dienste. Die Authentifizierungen können verhindern, dass ein Hacker sich von einem kompromittierten Container oder System innerhalb eines Clusters leicht zu einem anderen vorarbeiten kann. Mit einer Authentifizierung lassen sich also die Auswirkungen von Angriffen verringern.
• Über lokale Zertifikate, die im TPM-Modul (Trusted Platform Module) des Hosts installiert werden können, entsteht ein Root of Trust (RoT), das auch die Container schützt. Mit diesen Zertifikaten kann für sichere Zugriffe durch die Administratoren gesorgt werden. Außerdem lassen sich dadurch Code-Änderungen absichern. Das bedeutet, dass alle Updates und Anwendungen blockiert werden, die nicht durch einen vorher authentifizierten Administrator angestoßen wurden und die nicht aus einem autorisierten und vertrauenswürdigen Code Repository stammen.
• Aus allen Änderungen an der virtuellen Infrastruktur und am Code werden mit Hilfe des lokalen Zertifikats Hash-Werte erstellt, die abgespeichert werden. Dadurch entsteht ein unveränderbares Protokoll, das für die Suche nach Fehlern und für Compliance-Kontrollen eingesetzt werden kann.
• Alle Container in einer geteilten Betriebssystemumgebung werden ähnlich wie in Sandboxen in virtuellen Maschinen (VMs) und virtuellen Netzwerken untergebracht.
• Verbindungen zwischen Containern oder zwischen Diensten werden mit einem Zertifikat und dem TPM authentifiziert und verschlüsselt. Es darf auf keinen Fall ein vorgegebenes Vertrauensverhältnis zwischen Containern geben, selbst dann nicht, wenn sie sich eine IP-Adresse teilen.

Services für Identity and Access Management (IAM) und Public Key Infrastructure (PKI) sorgen für eine zentrale Kontrolle der Objekte und Richtlinien. Dazu zählen auch die Anwender, von ihnen verwendete Zertifikate, Zwei-Faktor-Authentifizierungen, Rollen-basierte Zugriffskontrollen (RBAC) sowie Zertifikate für Geräte und für Code.

In ihrer Gesamtheit erlauben diese Prinzipien und die damit zusammenhängenden Kontrollen den Unternehmen die Sicherheit ihrer Container in der Cloud deutlich zu erhöhen, indem sie sicherstellen, dass Container und Microservices nur dann mit anderen Diensten kommunizieren dürfen, wenn die Verbindungen vorher freigegeben wurden.

Zusätzlich sorgen die Schutzmaßnahmen dafür, dass die damit gesicherten Container in unterschiedlichen Cloud-Umgebungen eingesetzt werden können, sogar auch in anderen Cloud-Regionen oder in hybriden Umgebungen. Dabei müssen aber überall dieselben Sicherheitsvorgaben wie in einer einzelnen Cloud-Umgebung gelten.

Der große Vorteil dieses Vorgehens ist, dass die Container durch die zugrundeliegende Infrastruktur geschützt werden.

Das Einführen von Zero Trust in öffentlichen Cloud-Diensten

Die vorgestellten Prinzipien sind im Kontext einer typischen Situation aus der Praxis leichter zu verstehen. Nehmen wir als Beispiel die Anfrage einer Anwendung auf einem Client nach einem Dienst in einem Container. Dazu greifen wir auf ein Szenario zu, das Google für BeyondProd dokumentiert hat. BeyondProd ist ein Tochterunternehmen des Suchmaschinenkonzerns, das sich um die interne Zero-Trust-Umsetzung von Google kümmert.

Das folgende Diagramm zeigt wie eine Anwendung über einen Frontend-Web-Server auf in einem Backend-Storage-Dienst gespeicherte Daten zugreifen kann:

1. Die Applikation baut zunächst eine TLS-Verbindung (Transport Layer Security) zum Server auf, um Daten anzufragen (die Abkürzung ALTS in dem oberen Diagramm steht für Application-Layer Transport Security). Beachten Sie, dass sowohl die Front- als auch die Backend-Systeme jeweils gültige TPM-Zertifikate benötigen, mit denen die TLS-Verbindung aufgebaut werden kann. Wenn eine der beteiligten Maschinen gefälscht wurde, ist sie nicht in der Lage, einen sicheren Kanal zu der anderen aufzubauen. Das liegt daran, dass die öffentlichen Public-Keys nicht zueinander passen.
2. Der Frontend-Server verarbeitet die Anfrage per REST API und leitet sie zum passenden Service weiter, der in einem Container untergebracht ist. Beachten Sie hier, dass jeder Service eine Identitätsnummer oder einen Account im IAM-System benötigt. Dazu kommen kryptographische Daten wie das öffentliche und private Schlüsselpaar. Sie können genutzt werden, um die Identität gegenüber anfragenden Clients zu bestätigen und um eine sichere, verschlüsselte Verbindung aufbauen zu können.
3. Anschließend authentifiziert der Frontend-Server die anfragende Maschine über eine zweite TLS-Verbindung, die er zu dem IAM-System aufbaut.
4. Sobald die Authentifizierung erfolgreich durchgeführt wurde, erstellt der Frontend-Server eine weitere mit TLS verschlüsselte Verbindung zu dem Storage-Service im Backend. Über sie kann nun ein Remote Procedure Call (RPC) abgesetzt werden.
5. In dem folgenden Schritt überprüft der Backend-Dienst, ob der Frontend-Server berechtigt ist, auf den Storage-Service zuzugreifen, und ob der authentifizierte Nutzer ebenfalls das Recht hat, auf die angeforderten Daten oder auch auf eine Dateifreigabe zuzugreifen.
6. Wenn auch nur einer dieser Checks nicht erfolgreich abgeschlossen werden kann, wird der Zugriff auf die Daten blockiert. Nur wenn alle Überprüfungen ohne Fehler durchgeführt werden können, werden die angeforderten Daten an den Frontend-Service übergeben. Dieser leitet sie dann wiederum an den anfragenden Client weiter.

Um es noch einmal klarzustellen, auch wenn das obige Beispiel Dienste und Fähigkeiten aus der Cloud von Google nutzt, können Unternehmen die vorgestellten Konzepte und Schritte für jede andere Container-Infrastruktur nutzen, die die folgenden Punkte erfüllt:

• Die Server benötigen TPMs sowie die Fähigkeit, eine kryptographische Überprüfung der Authentizität anderer Systeme durchführen zu können.
• Ebenfalls erforderlich ist ein Router, der authentifizierte TLS-Verbindungen herstellen kann und der per REST API gestellte Anfragen zu dem passenden Containerservice weiterleiten kann.
• Ein geeigneter IAM-Service zum Authentifizieren der Nutzer und um die Zugangsdaten kryptographisch überprüfen zu können.
• Eine bereits durch die zugrundeliegende Plattform erreichte Isolierung der einzelnen Container voneinander, auch wenn sie sich einen Cluster-Node teilen.
• Eine Netzwerkisolierung auf Basis der einzelnen Container sowie verschlüsselte Verbindungen zwischen den Containern innerhalb des virtuellen Netzwerks, das der Container-Host errichtet hat.

Auch wenn die einzelnen Details natürlich variieren, können Unternehmen doch die meisten Cloud-Container-Plattformen so konfigurieren, dass sie als Zero-Trust-Umgebungen fungieren können. Dazu zählen Amazon Elastic Kubernetes Service, Azure Kubernetes Service und VMware Tanzu Kubernetes Grid.

Allerdings erfordert das eine umfangreiche Planung und meist einiges an Aufwand, um alle erforderlichen Informationen zu finden. Darüber hinaus gibt es aber auch vorkonfigurierte SaaS-Angebote (Software as a Service), die das Zero-Trust-Konzept bereits umsetzen. Ein Beispiel dafür ist Aporeto, das nach Angaben des Herstellers mit allen Standard-Kubernetes-Nodes und -VMs zusammenarbeitet.

Es ist bereits erwiesen, dass das Zero-Trust-Konzept besonders gut in Multi-Cloud- und Multi-Tenant-Umgebungen funktioniert. Das liegt daran, dass der Ansatz dafür sorgt, dass alle Maschine-zu-Maschine-Verbindungen authentifiziert und geschützt sind.

Auch wenn die meisten Zero-Trust-Deployments in einer Multi-Cloud-Umgebung unterschiedliche Services und Funktionen in jeder der beteiligten Cloud-Plattformen nutzen, lassen sich doch die Sicherheitsrichtlinien, die Nutzer- und Gruppen-IDs sowie die Zertifikate in der Regel portieren und weiterverwenden – so muss es auch sein. Unternehmen, die sich für Microservices und Container in einer Cloud-Umgebung interessieren, sollten das Zero-Trust-Modell deswegen als Grundlage für ihre Architektur verwenden.