Anwenderbericht: Zero-Trust-Architektur auf Basis von Anthos Service Mesh – im Detail

Seit 2001 steigt die Anzahl von Cyberangriffen, Opferzahlen und finanziellen Schäden stetig: 2022 gab es pro Tag 2.200 Angriffe – im Durchschnitt alle 39 Sekunden einen (Website). Und mit neuen Angriffsflächen durch Ökosysteme wird es sicher nicht weniger. Und dann ist da auch noch das Thema Künstliche Intelligenz, die auch Kriminelle nicht nur für Phishing und Social Engineering nutzen werden. Zero-Trust-Architektur ist in der Lage, dagegenzuhalten. Bastian Hafer und Max Rigling von Senacor erklären im Detail, wie sich das mit Anthos Service Mesh umsetzen lässt.

von Bastian Hafer, Information Technology Security Analyst und Max Rigling Managing ConsultantManaging Consultant, Senacor

Künftig werden Unternehmen – was Cybersecutity angeht – zwar alles richtig machen (Verwendung sicherer Passwörter und Passwort-Manager, Nutzung eines zweiten Faktors für die Authentifizierung usw.) und trotzdem Mitarbeiter dubiose Anrufe und Textnachrichten aufgrund eines Datenlecks des Telefonanbieters erhalten. Betrugsschema wie die akute Bedrohung per Telefon aufgrund von polizeilichen Ermittlungen durch Europol oder der Vorgesetzte, der dringend die letzten Quartalszahlen auf seine private E-Mail zugeschickt benötigt, sind gegebenenfalls auch dem Leser bereits begegnet.

In der Welt der IT-Security vollzieht sich daher ein Paradigmenwechsel, welcher versucht, die ständig wachsende Zahl der Angriffe zu bekämpfen. Das Ziel besteht nicht mehr darin, den Angreifer fernzuhalten, sondern die Anwendungen, Ökosysteme sowie die gesamte Unternehmensarchitektur und -infrastruktur so zu gestalten, dass davon ausgegangen wird, dass ein erfolgreicher Hack bereits stattgefunden hat und das System den Schaden, den der Angreifer anrichten kann, begrenzt.”

Das Wort, welches dafür geprägt wurde, ist die “Zero-Trust”-Architektur, die wir auf Basis von Anthos Service Mesh auf der Google-Cloud-Plattform erfolgreich umgesetzt haben. In den folgenden Abschnitten möchten wir tiefer in dieses Thema eintauchen sowie die Geschichte von Zero-Trust, unsere Implementierung und die Fragen und Herausforderungen, die bei der Umsetzung aufgetreten sind, beleuchten.

Historische Hintergründe

Lange Zeit betrieben IT-Abteilungen von Unternehmen Server in ihren persönlichen Rechenzentren, auf denen sie Anwendungen hosteten, die entweder selbst entwickelt oder eingekauft und für die Bedürfnisse ihrer Unternehmen konfiguriert und angepasst worden sind. Auf diese Anwendungen griffen die Mitarbeiter an Terminals und Workstations in den Büros und Niederlassungen der Unternehmen zu, um ihre täglichen Aufgaben zu erledigen.

Nicht erst mit der Covid-Pandemie, sondern schon lange vorher hat sich dieses Arbeitsmodell erheblich verändert:

• Wissensarbeiter haben begonnen, von überall aus zu arbeiten, vom Büro aus, von zu Hause aus oder in einem Wohnmobil am Strand
• Standardanwendungen wie die Office Suite werden nicht mehr erworben und selbst gehostet, sondern vom jeweiligen Anbieter betrieben, lizenziert und über einen Browser abgerufen (SaaS), um die Komplexität der eigenen IT-Landschaft zu reduzieren
• (Produktions-)Maschinen sind in gewissem Maße intelligent geworden durch IOT-Geräte, die ständig Daten über das Internet an die Hersteller senden, um eine vorausschauende Wartung zu ermöglichen und somit Ausfälle und Kosten zu minimieren

Die Unternehmen von heute brauchen daher ein neues Sicherheitsmodell, das sich effizienter an die Komplexität der modernen Welt anpasst, den hybriden Arbeitsplatz mitdenkt und Menschen, Geräte, Anwendungen und Daten schützt, egal wo sie sich befinden.

Perimeter-Sicherheit

Die “traditionelle” IT, wenn man sie so nennen will, und ihre Rechenzentren funktionieren wie eine befestigte Burg mit Zugbrücke. Alles, was sich innerhalb der Umgrenzung befindet, gilt als freundlich gesinnt und erhält mehr oder weniger Zugriff auf alle Server und Anwendungen des Rechenzentrums. Alles, was sich außerhalb des Perimeters befindet, wird als böse angesehen und muss ferngehalten werden. Eine solche Perimeter-Verteidigung besteht meist aus mehreren Schichten, die das gesamte soziotechnische System umfassen, d. h. es wird nicht nur Hard- und Software eingesetzt, um Eindringlinge fernzuhalten. Mitarbeiterschulungen sind ein Beispiel für eine nicht-technische Schutzmöglichkeit, da Anwender die erste Verteidigungslinie gegen Angreifer darstellen, aber auch die Hauptquelle für Bedrohungen durch einfache Unachtsamkeit oder bewusste böswillige Absicht.

Um den gedachten Graben zu unserer Burg zu überwinden, wird in der Regel eine DMZ oder ein VPN als metaphorische Torbrücke eingerichtet, über die der Datenverkehr in den Perimeter hinein- und hinausfließen kann, um externen Nutzern wie Kunden den Zugriff auf Anwendungen wie Online-Banking oder eine Versicherungs-App zu ermöglichen.

In einer verteilten, cloud-nativen Welt funktioniert dieses Konzept allerdings nicht mehr. Jede externe Verbindung zu einem SaaS-Anbieter reißt ein weiteres metaphorisches Loch in unsere Burgmauern, so dass sie eher wie ein feiner Schweizer Käse aussieht als eine echte Festung. Unser “neues” Paradigma, mit dem wir versuchen, diese Realität zu bewältigen, nennt sich “Zero Trust”. Zero Trust bedeutet einen Mentalitätswandel und geht davon aus, dass es kein hundert Prozent sicheres System gibt, sondern dass der Schwerpunkt auf der Widerstandsfähigkeit und der Eindämmung von Angriffen liegt, um die Schadenswirkung so gering wie möglich zu halten und gleichzeitig eine funktionierende IT-Landschaft für Kunden und Mitarbeiter zu erhalten.

Definition des Zero-Trust-Paradigmas

Zero Trust basiert auf drei Grundprinzipien, die alle miteinander verbunden sind:

• Der Angreifer schafft es in das System: Irgendwann werden Hacker in Ihr System eindringen, es gibt keine 100%ige Sicherheit. Deshalb wollen wir den Aktionsradius des Angreifers und damit auch die Höhe des potenziellen Schadens so weit wie möglich reduzieren. Dies folgt dem weithin bekannten Paradigma der Defense in Depth, hebt es aber auf eine ganz neue Ebene.
• Least Privilege: Jeder Benutzer (sei es ein technischer Benutzer wie ein Dienstkonto oder eine natürliche Person) sowie jede Workload erhält nur eine sehr geringe Anzahl von Berechtigungen, und zwar genau so viel, wie für die Ausführung des zugrundeliegenden Anwendungsfalls erforderlich ist. Dies ergibt sich aus dem Paradigma der Segregation of Duties erweitert um die Zerlegung von Entitäten in ihre kleinsten Teilbereiche. Beispielsweise wird kein technischer Benutzer mehr für ein ganzes System angelegt, sondern mehrere, welche in ihrer Gesamtheit die für unser gesamtes System erforderlichen Berechtigungen ausmachen.
• Keine Perimeter mehr: Wir errichten keine Perimeter mehr, wie sie oben für die “traditionelle” IT beschrieben wurden, d. h. es gibt keine Unterscheidung mehr zwischen “innerhalb” und “außerhalb” unserer Organisation. Dies wird ersetzt durch eine explizite Authentifizierung (AuthN) und Autorisierung (AuthZ) jeder Workload bei Zugriffen auf Ressoucen. Außerdem ist dieser Zugriff immer nur temporär gewährt. Bei jeder Anfrage muss eine neue Authentifizierung erfolgen.

Diese Prinzipien verlagern den Schutz von einem nicht mehr existierenden (Netzwerk-)Perimeter viel näher an die tatsächliche Workload, wobei der Schwerpunkt auf der Anwendung und ihren Daten selbst liegt.

Das NIST hat in seiner Sonderveröffentlichung 800-207 “Zero Trust Architecture” (ZTA) eine Referenzarchitektur beschrieben, in der die verschiedenen Komponenten einer solchen Architektur sehr gut dargestellt sind. Dennoch ist es wichtig, sich vor Augen zu halten, dass diese Komponenten nur ein Beispiel darstellen. Die genaue Umsetzung muss immer individuell designt werden.

Wichtig sind zwei (neue) Komponenten, ein Policy Decision Point, der aus einer Policy Engine und einem Policy Administrator besteht und normalerweise in einer Control Plane läuft, und ein Policy Enforcement Point, der neben der Workload selbst läuft:

• Die Policy Engine (PE) ist für die Entscheidung zuständig, ob der Zugriff auf eine Ressource für eine bestimmte Workload zu einem bestimmten Zeitpunkt gewährt oder verboten wird.
• Der Policy Administrator (PA) setzt diese Entscheidung durch, indem er die Verbindung zwischen einem Aufrufer und einer Ressource zulässt oder verbietet.
• Der Policy Enforcement Point (PEP), an dem die oben genannte Entscheidung zur Beschränkung des Zugriffs auf die betreffende Ressource schließlich durchgeführt wird

In den folgenden Kapiteln wollen wir die konkrete Implementierung vorstellen, mit der wir eine Zero-Trust-Architektur aufgebaut haben, aber auch die Herausforderungen aufzeigen, denen wir dabei begegnet sind.

Überblick über den allgemeinen Aufbau

Die Anwendung ist semantisch in drei Teile aufgeteilt:

• Kundenauthentifizierung,
• Multi-Faktor-Authentifizierung und Berechtigungen, und
• Banking Services

Jeder dieser Teile erfüllt einen wichtigen Aspekt, der es uns insgesamt ermöglicht, eine sichere Anwendung zu betreiben, die in der Cloud gehostet wird. Jede unserer Teilanwendungen läuft auf zwei Kubernetes-Clustern in verschiedenen Regionen, um die Ausfallsicherheit im Falle eines regionalen Ausfalls innerhalb zu gewährleisten.

Istio Service Mesh wird verwendet, um weitere Sicherheitsfunktionen wie TLS (Transport Layer Security) Konfiguration und Vertrauensverwaltung von den Entwicklern zu abstrahieren, sowie Routing, clusterübergreifende Kommunikation und Service Discovery bereitzustellen. Die Abstraktion wird durch die automatische Einbindung eines Sidecar-Proxys in jeden Pod erreicht, auf dem ein Workload läuft. Dieser Proxy kümmert sich um den ein- und ausgehenden Verkehr. Die Verbindung zwischen dem Workload und dem Proxy erfolgt im Pod unverschlüsselt, wodurch die im NIST-Konzept erwähnte implizite Vertrauenszone auf ein Minimum reduziert wird. Der Sidecar-Proxy, auch bekannt als Istio-Proxy, terminiert eingehenden mTLS-Verkehr und stellt ausgehende Verbindungen auf mTLS mit einem Client-Zertifikat um, das automatisch bereitgestellt und verwaltet wird. Die Lebensdauer des Zertifikats kann auf einige Minuten minimiert werden, wenn ein verbesserter Schutz gegen Zertifikatsmissbrauch erforderlich ist, ohne die Architektur zu zerstören.

Das Service-Mesh umspannt beide Cluster einer Anwendung und schafft ein Multi-Cluster-Sicherheitsnetz, um die Resilienz zu verbessern. Für jeden potenziellen Ursprung des Aufrufs werden bestimmte Eingangspunkte in Form von Ingress-Gateways (im Wesentlichen vom Service Mesh verwaltete Layer-4-Load-Balancer) eingerichtet:

• Intern (innerhalb der Grenzen der Organisation)
• Extern
• Cross-Cluster

Die Kommunikation mit dem Cluster, zwischen den Clustern und innerhalb desselben Clusters wird durch mTLS geschützt, dass bei jeder Verbindung eine Identität für Server und Client bereitstellt. Das Service Mesh kann so konfiguriert werden, dass es eine benutzerdefinierte Zertifizierungsstelle verwendet und das erforderliche Vertrauen von dieser ableitet. Die Identität des letzten TLS-Clients außerhalb des Clusters bleibt an den Eingangsgateways erhalten, indem ein Header gesetzt wird, der entweder den Namen des Subjekts (CN) oder die alternativen Namen des Subjekts (SAN) enthält, die nachgelagert verwendet werden. Vorhandene Header werden entfernt, um Spoofing zu verhindern.

Zero Trust in Aktion

Wie eingangs beschrieben wird in einer Zero-Trust-Architektur weder der Quelle noch dem Ziel vertraut. Daher müssen für jeden Aufruf Identitäten und Authentifizierung für eine mögliche Autorisierung bereitgestellt werden.

In unserem System

• werden überprüfbare Identitäten über gegenseitige TLS-Client-Zertifikate bereitgestellt,
• erfolgt die Authentifizierung durch die Verwendung von JWTs (JSON Web Tokens), und
• wird die Autorisierung über Istios Konzept der Autorisierungsrichtlinien erteilt.

In den nächsten drei Unterkapiteln wird auf den jeweiligen Aspekt im Rahmen des Ziels eines Zero Trust Kubernetes Clusters eingegangen.

Identitäten – mTLS-Client-Zertifikate

In allen Clustern und für den gesamten eingehenden Datenverkehr wird mTLS eingesetzt, um sicherzustellen, dass alle Verbindungen zwischen Server und Client authentifiziert sind, die gesendeten Daten durch die TLS-Verschlüsselung vor neugierigen Blicken geschützt sind und die Integrität durch modernste Mechanismen zum Schutz der Nachrichtenintegrität gesichert ist.

Um Workloads zu authentifizieren und starke kryptografische Identitäten bereitzustellen, nutzt Istio SPIRE, eine Implementierung der SPIFFE-APIs. Die Identitäten können im Folgenden zur Authentifizierung und Autorisierung verwendet werden.

Anmerkung: In unserem speziellen Fall mit verteilten Multi-Kubernetes-Clustern müssen wir zwischen Aufrufern und Konsument unterscheiden. Naiv betrachtet sind die beiden Konzepte dasselbe, aber innerhalb der zugrundeliegenden Infrastruktur können sie sich unterscheiden. Wird ein bestimmter Microservice über das clusterübergreifende Ingress-Gateway von einem Microservice aus einem anderen Cluster aufgerufen, so ist der am Istio-Proxy des aufgerufenen Microservices ermittelte Aufrufer das Ingress-Gateway. Der Konsument hingegen ist der Microservice auf dem anderen Cluster. Da die Identitäten auf Zertifikaten basieren, die aus der mTLS-Verbindung extrahiert werden, wird der Aufrufer als die letzte TLS-terminierende Entität identifiziert, die die Ressource aufruft, während der Verbraucher die Entität ist, die die Anfrage initiiert hat.

Details zur Umsetzung

Um mTLS im gesamten Cluster durchzusetzen, erstellen wir eine Peer-Authentifizierungsressource im istio-system Namespace, wobei der mTLS-Modus auf strict gesetzt wird.

Die Sidecar-Injektion kann aktiviert werden, indem die entsprechenden Namespaces mit den Standard-Injection-Labels gekennzeichnet werden und sichergestellt wird, dass jeder Pod über einen designierten Sidecar-Proxy verfügt, der von SPIRE eine Identität erhält und sich innerhalb des Clusters ordnungsgemäß authentifizieren kann.

Authentifizierung per JWT

Die Authentifizierung erfolgt über signierte JWTs, die nach erfolgreicher Authentifizierung gegenüber der IAM (Identity and Access Management) Lösung, die auf dem oben erwähnten Kunden-Authentifizierungscluster läuft, gewährt werden.

JWT, definiert in RFC 7519, bietet eine Lösung zur sicheren Übertragung von Informationen innerhalb eines Json-Objekts. Die im Token enthaltenen Informationen werden unter Verwendung modernster asymmetrischer kryptografischer Primitive digital signiert. Die öffentlichen Schlüssel müssen sicher an alle Cluster verteilt werden, die so konfiguriert sind, dass sie das jeweilige Token akzeptieren.

Beispiel: Ein Anrufer, der einen geschützten Endpunkt aufrufen möchte, authentifiziert sich gegenüber dem vorgesehenen Authentifizierungssystem. Nach erfolgreicher Authentifizierung erstellt der JWT-Aussteller ein Token, das weitere Details enthält, wie z. B.,

• Issuer ID – Wer hat den Token ausgestellt
• Audience – Wer sollte den Token annehmen
• Expiry – Wie lange ist das Token gültig
• Audit Tracking – Fehlersuche und Prüfpfade
• Session-ID – Session handling

Dieses Token wird vom Aussteller mit dem privaten Schlüssel signiert und dann an den Aufrufer übergeben. Der Aufrufer kann nun das Token innerhalb des festgelegten Zeitrahmens verwenden, um den geschützten Endpunkt aufzurufen, der den öffentlichen Schlüssel des Ausstellers verwendet, um das Token zu validieren. Ist das Token gültig, d.h.

• kann der Inhalt auf die Signatur abgebildet werden und
• kann die Signatur mit einem öffentlichen Schlüssel aus dem Truststore überprüft werden

und können die darin enthaltenen Informationen gegen die konfigurierten Richtlinien validiert werden, d.h.

• die Audience stimmt mit der ID der Infrastrukturkomponente des geschützten Endpunkts überein und
• der Token ist noch nicht abgelaufen,

dann wird der Anruf bearbeitet, gefolgt von nachgelagerten weiteren Autorisierungsmechanismen.

Im Service Mesh erfolgt diese Überprüfung in den konfigurierten Zugangspunkten des Clusters, den Ingress-Gateways und innerhalb der istio-proxies, die in jedem Pod vorhanden sind und die erwähnte Abstraktion bezüglich z.B. mTLS, Service Discovery oder in unserem Fall JWT-Validierung für Microservices bereitstellen, wie im anfänglichen Architekturdiagramm dargestellt.

Details zur Umsetzung

Die Authentifizierungsressource von Istio kann im istio-system Namespace konfiguriert werden, um JWTs mit Schlüsseln zu verifizieren, die als Json Web Key Sets bereitgestellt werden. Weitere Einschränkungen für Ansprüche wie z.B. die Audience können festgelegt werden.

Autorisierung – Zugriffsbeschränkungen über Autorisierungsrichtlinien

Nachdem die Authentifizierung über das oben erwähnte Zusammenspiel zwischen der IAM-Management-Lösung, den ausgegebenen JWTs und der Validierung in den Clustern realisiert wurde, wird sich dieses Kapitel auf die Autorisierung konzentrieren.

Dem Policy Decision Point stehen folgende Informationen zur Verfügung:

• Identität des Anrufers in Form eines Client-Zertifikats
• Identität des anfänglichen Clusteraufrufers in einem Header erhalten
• JWT-spezifische Informationen (können bei Bedarf erweitert werden)
  • Signatur des Ausstellers
  • Expiry
  • Audience
  • Session-ID

Diese Details können in der Istio-Ressourcenautorisierungsrichtlinie verwendet werden, um den Datenverkehr auf die Anrufer und Verbraucher zu beschränken, die zur Abfrage des jeweiligen Dienstes berechtigt sind. Wir erweitern unsere Architektur, die bereits JWTs prüft, mit Autorisierungsrichtlinien an strategischen Punkten innerhalb der Kommunikation zwischen dem Aufrufer und dem Aufrufer, wie in ARCHITECTURE_WAVE2 zu sehen.

Auf der Gateway-Ebene beschränken wir die Kommunikation auf Clients, die gültige Zertifikate von einer vertrauenswürdigen Stelle besitzen. Das Subject oder ein Subject Alternative Name des Client-Zertifikats muss in der Liste der zulässigen Anrufer enthalten sein. Darüber hinaus muss die Anfrage über ein gültiges JWT verfügen, das wie zuvor beschrieben verifiziert wurde.

Innerhalb des Istio-Proxys unseres aufgerufenen Microservices erzwingen wir über die von mTLS bereitgestellte ID innerhalb des Clusters, dass der Aufrufer eines der Ingress-Gateways ist. Der anfängliche Cluster-Aufrufer, unser Konsument, der in einem Header erhalten bleibt, muss auf der Zulassen-Liste vorhanden sein, wobei das Prinzip der Segregation of Duties und des Least Privilige eingehalten wird. Beide Beschränkungen werden über eine Autorisierungsrichtlinie durchgesetzt, die mit jedem Workload eingesetzt wird. Diese Richtlinie erzwingt zusätzlich ein gültiges JWT aus der Aussteller-Schlüssel-Zuordnung, die in der Request Authentication Ressource definiert wurde, und schränkt bei Bedarf auf weitere Claims ein, z. B. auf die Audience.

Rollout – Zero Trust zum Leben erwecken

Die Migration von einer offenen Umgebung zu einer stärker eingeschränkten und regulierten Umgebung ist mit verschiedenen Herausforderungen verbunden. Der Ansatz muss sicher und widerstandsfähig, aber gleichzeitig skalierbar und leicht konfigurierbar sein. Die Migration selbst darf die laufende Entwicklung oder sogar die Produktion nicht behindern, während die Auswirkungen der Migration minimiert werden müssen.

Daher kann die Migration zu einer Zero-Trust-fähigen Kubernetes-Multi-Cluster-Umgebung in drei Schritte unterteilt werden:

1. Baseline – JWT-Validierung, Zulässigkeitsliste der JWT-Aussteller und Überprüfung der Audience
2. Welle 1 – Erlaubnisliste für externe Aufrufer des Clusters wird am Gateway validiert
3. Welle 2 – Erlaubte Liste von cluster-externen und -internen Verbrauchern, die am istio-Sidecar-Proxy validiert werden

Baseline – JWT

Um ein Minimum an Sicherheitskontrollen zu schaffen, muss die JWT-Validierung am Zugangspunkt des Clusters und für die clusterinterne Kommunikation konfiguriert werden. Letzteres stellt sicher, dass sich der Cluster von der peripheren Sicherheit zu Zero Trust entwickelt.

Welle 1 – Cluster-externer Aufrufer am Gateway

Die Gateways sind, wie bereits erläutert, nach Anwendungsfällen getrennt. Die Anwendung dieses Ansatzes ermöglicht die Implementierung kontextbezogener und kontextangepasster Sicherheitsmechanismen. Die Autorisierungsrichtlinien für die jeweiligen Zielgruppen können je nach ihrer erwarteten Sicherheitsreife streng oder nachsichtig sein. Sobald die Zielgruppe und ihre Identität bekannt sind, kann der Zugriff auf die Grenzen des Clusters beschränkt werden, indem nur Aufrufer akzeptiert werden, die aus bekannten Quellen stammen und sich über ein mTLS-Client-Zertifikat einer vertrauenswürdigen Zertifizierungsstelle ausweisen.

Da die Trennung der Gateways Teil des ursprünglichen Entwurfs ist, werden durch die Einschränkung der Aufrufer auf diese Weise nur Microservices aufgedeckt, die sich nicht an die vereinbarten Konzepte halten. Als Abhilfe müssen die Microservices das richtige Gateway verwenden und die Verbraucher des jeweiligen Microservices müssen die URL des aufgerufenen Endpunkts entsprechend ändern. Dies kann in den unteren Umgebungen des Staging-Prozesses leicht erkannt und entschärft werden.

Als Bonus für die Einhaltung der Vorschriften verfügt der Cluster-Eigentümer immer über eine Liste potenzieller Aufrufer für eventuelle Audits oder Sicherheitstests.

Welle 2 – Konsumenten am Istio-Proxy

Während die meisten der vorangegangenen Schritte während der Migration zu Zero Trust hauptsächlich von zentralen Teams durchgeführt wurden, erfordert der letzte Schritt Anstrengungen der Teams, die Microservices entwickeln und nutzen.

Um diese Teams von Anfang an zu unterstützen und Reibungsverluste, Widerstände und Probleme zu verringern, kann eine Basisliste der aktuellen Anrufer für die Teams erstellt werden. Ein Envoy-Filter kann vorübergehend eingesetzt werden, der Anrufe einschließlich relevanter Identitätsinformationen protokolliert. Ein Dry-Run Modus, den die Teams bewerten können, unterstützt bei der Migration und reduziert Fehler. Envoy-Filter können verwendet werden, um Anfragen oder Antworten über Lua-Code zu ändern oder zu bearbeiten. Durch die Protokollierung einer Warnmeldung mit Informationen über

• Anrufer-ID,
• Verbraucher-ID und
• Anfragetyp (Cluster intern/extern, anderer Cluster)

können Microservice-Teams die initialen Zugriffs-Listen befüllen, bevor die Einschränkungen durchgesetzt werden. Einfache Extraktionsskripte erleichtern diesen Prozess.

Sobald die Teams ihre Baseline aus den Protokollen erstellt haben, müssen die spezifischen Autorisierungsrichtlinien implementiert werden. Um die Komplexität der Autorisierungsrichtlinien vor den Teams zu verbergen, wurde ein obligatorisches helm chart speziell für die Bereitstellung in der Umgebung verwendet, dass eine Vorlage für eine Autorisierungsrichtlinie enthält, die mit vom Team bereitgestellten Werten gefüttert wird.

NIST-Konzept-Mapping

Um die vorgestellten Konzepte auf das beschriebene NIST Zero Trust Schema abzubilden, besitzt der aufrufende Akteur die Rolle des Systems. Der PEP-Agent wird durch den istio-Proxy repräsentiert und fragt das istio-Kernsystem als Policy-Administrator ab. Basierend auf den bestehenden Autorisierungsrichtlinien wird das istio-Kernsystem als Policy Engine den Zugriff gewähren oder verweigern. Die Entscheidung wird an den istio-Proxy als PEP-Gateway zurückgespielt.

Ergebnis und Herausforderungen

Die oben beschriebene Architektur ist im Einsatz und hat nicht nur zu einer Zero-Trust-Architektur geführt, sondern auch zu mehr Vertrauen in die Gesamtimplementierung angesichts aktueller Cyber-Bedrohungen. Mit dem gewählten Ansatz sind wir in der Lage, einfach zusätzliche Anwendungen oder einzelne Dienste zur Architektur hinzuzufügen, die dieselben Mechanismen nutzen können, um Vertrauen zwischen den Workloads herzustellen.

Bei unserer Implementierung standen wir vor mehreren Herausforderungen, die hauptsächlich auf die Art der Lösungsentwicklung selbst zurückzuführen waren. Während es sich bei der Kundenanwendung um eine Greenfield-Implementierung im Rahmen eines Leuchtturmprojekts zur Etablierung der Cloud handelte, kann die Migration zu einem vollständigen Zero-Trust-Ansatz als Brownfield betrachtet werden. Die meisten der verwendeten Komponenten wie die zentrale Authentifizierungsanwendung, das Berechtigungssystem sowie wesentliche Teile der JWT-Authentifizierungslösung waren bereits fertiggestellt. Die verantwortlichen Teams konzentrierten sich hauptsächlich darauf, zusätzliche Funktionen in ihre Systeme einzubauen, und zögerten, ihre Arbeitsabläufe zu ändern, um die oben genannten Anforderungen einer Zero-Trust-Architektur zu erfüllen.
Diese gegensätzlichen Prioritäten konnten wir überwinden, indem wir die gesamte Lösung einige Wochen lang im Dry-Run laufen ließen und eine erste Liste der erlaubten Zugriffe aus den Log-Dateien zusammenstellten. Die Teams, die für die Microservicres zuständig sind, mussten lediglich eine bestimmte Liste von Konsumenten abzeichnen, was den anfänglichen Zeitaufwand stark vereinfachte und die Hürde für spätere Feinabstimmungen senkte.

Schließlich fehlen vor allem aufgrund äußerer Beschränkungen, auf die wir keinen Einfluss haben noch einige Teile, die wir gerne eingeführt hätten. Eines davon wäre ein allgemeines Egress-Gateway, das den gesamten Datenverkehr über einen zentralen Punkt an unsere Backends weiterleitet, um Richtlinien durchzusetzen. Leider ist dies derzeit nicht möglich, da die bestehenden Backends und insbesondere die Netzwerkarchitektur es uns nicht erlauben, diese Lösung sicher zu entwickeln und zu testen. Auch hier wird deutlich, wie heikel die Einführung einer Zero-Trust-Architektur ist und wie hoch die möglichen Auswirkungen sind.

Zero-Trust-Architektur: Zusammenfassung

Basierend auf der Anzahl der aktuellen Bedrohungen, die wir in unserer Einführung hervorgehoben haben, in Verbindung mit einer immer stärker vernetzten Welt, die verteilte, cloud-native Architekturen nutzt, kann man leicht zu dem Schluss kommen, dass die Implementierung einer Zero-Trust-Architektur für jedes Unternehmen erforderlich ist.

Da wir beide davon überzeugt sind, dass langfristig jedes Unternehmen zu einer Zero-Trust-Architektur übergehen sollte, wobei der Schwerpunkt auf dem Teil des Paradigmas liegt, der sich mit der Annahme eines Einbruchs befasst, und weg von einer reinen Perimeter-Verteidigung, gibt es mehr Grauzonen, als eine einfache Schwarz-Weiß-Entscheidung. Vor allem, weil die meisten Sicherheitsprobleme immer noch durch unvorsichtige Benutzer verursacht werden.”

Die Implementierung einer Zero-Trust-Architektur ist eine Menge Arbeit und erfordert einen strukturierten und geplanten Ansatz, um erfolgreich zu sein. Vor allem, wenn man bedenkt, dass ein Fehler in der Zero-Trust-Durchsetzung oder eine fehlerhafte Implementierung katastrophale Auswirkungen auf die Systeme der Organisation haben kann, da keine Verbindung mehr möglich ist.

Der anfängliche Schwerpunkt muss auf der Erstellung einer Bestandsaufnahme der eigenen Infrastruktur, Dienste und Anwendungen, ihrer Identitäten, Anwendungsfälle und Anforderungen liegen, um die Implementierung richtig zu planen. Während der Implementierung ist ein Dry-Run Modus unerlässlich, um zu vermeiden, dass geschäftskritische Anwendungsfälle in der Produktion aufgrund fehlender Transparenz nicht explizit genannter Verbindungen sowie mangelnden Engagements und fehlender Zeitkapazitäten aller Teams für die Umsetzung der erforderlichen Voraussetzungen blockiert werden. Schließlich ist der Zero-Trust-Ansatz, wenn er einmal implementiert ist, nie in einem fertigen Zustand, sondern sollte dynamisch modifiziert (was im Vergleich zu den notwendigen Vorarbeiten jetzt viel einfacher ist) und angepasst werden, um auf neue Entwicklungen oder unvorhergesehene Angriffsmuster zu reagieren.Bastian Hafer und Max Rigling, Senacor