Sichere Kommunikation und Zero Trust

Warum der Netzwerkperimeter nicht mehr funktioniert

Jahrzehntelang schützten die meisten Organisationen ihre Systeme wie eine Burg mit Wassergraben. Eine Firewall trennte das vertrauenswürdige Innere vom nicht vertrauenswürdigen Internet, die Belegschaft verband sich über ein virtuelles privates Netzwerk (VPN) mit dem Inneren, und alles, was schon drinnen war, galt als freundlich. Services im Rechenzentrum riefen einander ohne Authentifizierung über einfaches HTTP auf, weil das Netzwerk selbst als Berechtigungsnachweis galt. Kapitel 6 nannte das Netzwerk ist sicher unter den Fallacies of Distributed Computing; das Modell der Perimetersicherheit ist dieser Trugschluss, zur Architektur gemacht.

Drei Dinge haben es zu Fall gebracht. Erstens wurde das Innere zu groß, um es zu verteidigen: Laptops reisen, die Belegschaft arbeitet von zu Hause, Partner verbinden sich, und eine einzige Phishing-E-Mail oder ein gestohlenes VPN-Passwort bringt einen Angreifer in den Burggraben. Ist er erst drinnen, bewegt er sich seitwärts von Rechner zu Rechner; das nennt man laterale Bewegung (Lateral Movement). Beim Angriff auf den US-Händler Target im Jahr 2013 nutzten die Angreifer zunächst Netzwerk-Zugangsdaten, die einem Dienstleister für Heizung und Lüftung gestohlen worden waren, gelangten von dort zu den Kassenterminals und erbeuteten Daten zu rund 40 Millionen Karten. Zweitens löste sich das Innere auf: Workloads laufen heute über mehrere Cloud-Konten, SaaS-Produkte und APIs Dritter verteilt, sodass es keine einzelne Mauer mehr gibt, auf die man eine Firewall setzen könnte. Drittens wurde das Innere dynamisch: Container entstehen und verschwinden jede Minute, und IP-Adressen werden wiederverwendet, sodass Regeln wie erlaube 10.0.4.0/24 den Zugriff auf 10.0.7.12 nichts Stabiles mehr beschreiben.

Die Idee, den Perimeter aufzugeben, ist älter als ihr Name. Das Jericho Forum, eine Gruppe von Sicherheitsverantwortlichen aus Unternehmen, warb ab 2004 für De-Perimeterisierung; John Kindervag, damals Analyst bei Forrester Research, prägte um 2010 den Begriff Zero Trust; und Googles BeyondCorp-Veröffentlichungen ab 2014 zeigten, dass es im großen Maßstab funktioniert. Das Motto lautet never trust, always verify (nie vertrauen, immer prüfen): Keine Anfrage gilt als vertrauenswürdig, nur weil sie von einem bestimmten Ort kommt.

Zero Trust nach der Definition des NIST

Der Referenztext ist die NIST Special Publication 800-207, Zero Trust Architecture, veröffentlicht im August 2020 (Rose, Borchert, Mitchell und Connelly). Sie beschreibt Zero Trust als eine Reihe von Prinzipien, die die Verteidigung von statischen, netzwerkbasierten Perimetern hin zu Nutzern, Assets und Ressourcen verlagern, und eine Zero-Trust-Architektur als den Plan einer Organisation, diese Prinzipien anzuwenden. Ihre zentrale Aussage lautet, dass einem Asset oder Benutzerkonto kein implizites Vertrauen allein aufgrund seines physischen oder logischen Netzwerkstandorts oder seiner Eigentümerschaft gewährt wird. Authentifizierung und Autorisierung sind eigenständige Funktionen, die ausgeführt werden, bevor eine Sitzung zu einer Ressource aufgebaut wird.

Die Publikation nennt sieben Grundsätze. Es lohnt sich, sie im Wortlaut zu kennen, denn viele Produkte behaupten, Zero Trust zu sein, erfüllen aber nur einen oder zwei davon.

Entscheidungs- und Durchsetzungspunkte

SP 800-207 beschreibt die Mechanik mit wenigen logischen Komponenten. Ein Policy Enforcement Point (PEP) sitzt vor einer Ressource und lässt Datenverkehr nur durch, wenn er dazu angewiesen wird: in der Praxis ein identitätsbewusster Proxy, ein API-Gateway, ein Sidecar eines Service Meshes oder ein Datenbank-Proxy. Der Policy Decision Point (PDP) trifft die Entscheidung. Das NIST teilt ihn in eine Policy Engine, die die Anfrage anhand von Richtlinie und Eingaben bewertet und entscheidet, und einen Policy Administrator, der die Entscheidung umsetzt, indem er den Pfad öffnet oder schließt, etwa durch Ausgabe eines kurzlebigen Sitzungstokens oder durch Konfiguration des PEP. Zu den Eingaben gehören der Identity Provider, der Zustand von Geräten und Workloads (Patchstand, Konfiguration, Integrität), Threat Intelligence, die Zugriffsrichtlinien selbst und Aktivitätslogs.

Entscheidung und Durchsetzung zu trennen ist derselbe Schritt wie die Trennung von Richtlinie und Mechanismus in Betriebssystemen, und er lohnt sich aus demselben Grund: Richtlinien lassen sich einmal schreiben, zentral prüfen, testen und ändern, während die Durchsetzung an jeden Ort verteilt ist, an dem Datenverkehr fließt. Die Policy Engines aus Abschnitt 8.3, etwa Open Policy Agent, sind oft die Engine hinter einem PDP. Die Designfrage für Architekten lautet, wo die Durchsetzungspunkte sitzen müssen, damit es keinen Weg an ihnen vorbei gibt, und wie die Entscheidung schnell und verfügbar bleibt, denn ein PDP im kritischen Pfad jeder Anfrage ist nun eine Abhängigkeit mit eigenem Budget für Verfügbarkeit und Latenz. Übliche Antworten sind, Entscheidungen für einige Sekunden zu cachen, kompilierte Richtlinien an den PEP zu verteilen, damit er lokal entscheiden kann, und vorab festzulegen, was geschieht, wenn der PDP nicht erreichbar ist (normalerweise Ablehnung, mit einer kleinen Allow-List für Health Checks).

BeyondCorp: Zero Trust für Menschen

Google begann nach dem Angriff von 2009, bekannt als Operation Aurora, sich von seinem privilegierten Firmennetzwerk zu lösen, und beschrieb das Ergebnis in BeyondCorp: A New Approach to Enterprise Security (Rory Ward und Betsy Beyer, ;login:, Dezember 2014), gefolgt von mehreren weiteren Veröffentlichungen. Das Design hat drei Hauptteile. Jedes Gerät ist in einem Geräteinventar erfasst und wird über ein Zertifikat identifiziert. Ein aus dem Internet erreichbarer Access Proxy steht vor jeder internen Anwendung; Beschäftigte erreichen Anwendungen über ihn aus jedem Netzwerk, auch aus dem Büronetzwerk, das keine besonderen Rechte erhält. Eine Komponente zur Vertrauensbewertung verknüpft, wer der Nutzer ist, mit dem Zustand des Geräts, um eine Vertrauensstufe zuzuweisen, und jede Anwendung legt die Mindeststufe fest, die sie verlangt.

Die Folge, die viele überraschte, war der Wegfall des VPN: Wer im Café sitzt, durchläuft dieselben Prüfungen wie jemand am Schreibtisch im Büro. Die Idee wird heute als Produkte unter den Namen Identity-Aware Proxy und Zero Trust Network Access (ZTNA) angeboten. Das Zero Trust Maturity Model der US-amerikanischen Cybersecurity and Infrastructure Security Agency (Version 2.0, April 2023) ist ein nützliches Werkzeug zur Selbsteinschätzung: Es bewertet fünf Säulen (Identität, Geräte, Netzwerke, Anwendungen und Workloads sowie Daten) von traditionell bis optimal, mit Sichtbarkeit, Automatisierung und Governance quer über alle.

Mutual TLS, Zertifikate und Workload Identity

Zero Trust zwischen Services braucht bei jedem Aufruf zweierlei: Verschlüsselung und eine starke Identität für beide Enden. Transport Layer Security leistet beides. TLS 1.3 (RFC 8446, August 2018) schließt seinen Handshake in einem Round Trip ab: Der Client sendet die unterstützten Algorithmen und einen Key Share, der Server antwortet mit seinem Key Share und seinem Zertifikat, und beide leiten mit ephemerem Diffie-Hellman Sitzungsschlüssel ab, sodass jede Sitzung Forward Secrecy hat (ein gestohlener Serverschlüssel kann aufgezeichneten früheren Datenverkehr nicht entschlüsseln). TLS 1.3 entfernte die schwachen Optionen früherer Versionen, darunter RSA-Schlüsselaustausch, Chiffren im CBC-Modus, RC4, SHA-1-Signaturen, Kompression und Renegotiation; TLS 1.0 und 1.1 wurden 2021 durch RFC 8996 formell für veraltet erklärt. Ein optionaler Zero-Round-Trip-Modus (0-RTT) lässt einen wiederkehrenden Client sofort Daten senden, doch diese frühen Daten kann ein Angreifer wiederholt einspielen, daher müssen sie auf idempotente Anfragen beschränkt bleiben. Große Browser und Cloud-Anbieter verwenden inzwischen auch einen hybriden Post-Quanten-Schlüsselaustausch, der X25519 mit ML-KEM kombiniert (2024 vom NIST als FIPS 203 standardisiert) und heute aufgezeichneten Datenverkehr gegen einen künftigen Quantencomputer schützt.

Ein Zertifikat bindet einen öffentlichen Schlüssel an einen Namen und ist von einer Zertifizierungsstelle (CA) signiert; der Client prüft die Signaturkette bis zu einer Wurzel, der er bereits vertraut. Dieses System aus CAs, Zertifikaten, Trust Stores und Widerruf ist eine Public-Key-Infrastruktur (PKI). Öffentliche Zertifikate werden zudem in Certificate-Transparency-Logs eingetragen, sodass ein fälschlich ausgestelltes Zertifikat für Ihre Domain auffallen kann. Gewöhnliches HTTPS authentifiziert nur den Server. Bei Mutual TLS (mTLS) legt auch der Client ein Zertifikat vor, sodass der Server erfährt, welcher Workload aufruft. Interne Zertifikate stammen von einer privaten CA, die die Organisation selbst betreibt, meist innerhalb ihrer Secrets- oder Mesh-Plattform, weil öffentliche CAs keine Zertifikate für interne Namen ausstellen.

Welcher Name gehört ins Zertifikat? Hostnamen und IP-Adressen sind schlechte Identitäten für Container. SPIFFE (Secure Production Identity Framework for Everyone, ein graduiertes Projekt der Cloud Native Computing Foundation) standardisiert Workload Identity: Jeder Workload erhält eine URI wie spiffe://fooddelivery.example/ns/prod/sa/orders und ein kurzlebiges SPIFFE Verifiable Identity Document, entweder ein X.509-Zertifikat für mTLS oder ein JWT. Die Referenzimplementierung SPIRE attestiert einen Workload (prüft, welcher Kubernetes-Service-Account oder welche Cloud-Instanz er tatsächlich ist), bevor sie das Dokument ausstellt, und rotiert es automatisch, typischerweise etwa stündlich. Autorisierungsregeln können dann orders darf payments aufrufen sagen, statt Adressen zu nennen.

Service Meshes

mTLS, Zertifikatsrotation, Wiederholungen und Autorisierung pro Aufruf in jedem Service und in jeder Sprache umzusetzen ist teuer und uneinheitlich. Ein Service Mesh verlagert diese Arbeit in die Infrastruktur. Im klassischen Design erhält jede Service-Instanz einen Sidecar-Proxy (Envoy in Istio, ein Rust-Mikroproxy in Linkerd), der ihren Datenverkehr abfängt; eine Control Plane stellt Identitäten aus, verteilt Richtlinien und sammelt Telemetrie. Neuere Designs ohne Sidecar, etwa der Ambient Mode von Istio, übertragen mTLS einem gemeinsamen Proxy pro Knoten und fügen nur dort einen separaten Proxy hinzu, wo Richtlinien auf HTTP-Ebene nötig sind. NIST SP 800-207A (September 2023) beschreibt dieses Muster als den Weg, Zero Trust auf Cloud-native Anwendungen anzuwenden: identitätsbasierte Segmentierung, bei der das Mesh die Richtlinien bei jedem Aufruf durchsetzt.

Ein Mesh ist eine bedeutende Plattformentscheidung. Es fügt pro Hop Latenz hinzu (meist gering, aber beim p99 messbar), Speicher pro Pod, eine Control Plane, die selbst hochverfügbar und abgesichert sein muss, und eine Lernkurve für jedes Team. Außerdem schützt es nur Datenverkehr, der durch das Mesh läuft: Ein Job, der sich direkt mit der Datenbank verbindet, umgeht es. Kleine Systeme mit einer Handvoll Services fahren oft besser mit mTLS über eine Bibliothek oder die Load Balancer der Plattform. Die entscheidenden Fragen sind, wie viele Services und Sprachen Sie haben und ob es ein Plattformteam gibt, das das Mesh betreibt (siehe Abschnitt 10.7).

Zertifikate automatisieren

Zertifikate laufen ab, und abgelaufene Zertifikate gehören zu den häufigsten Ursachen vermeidbarer Ausfälle. Am 6. Dezember 2018 ließ ein abgelaufenes Zertifikat in Ericsson-Software, die das britische Mobilfunknetz O2 nutzte, rund 32 Millionen Kunden den größten Teil eines Tages ohne Datendienst. Das Gegenmittel ist Automatisierung. Das ACME-Protokoll (Automatic Certificate Management Environment, RFC 8555, 2019), entwickelt für die Zertifizierungsstelle Let’s Encrypt, lässt Software die Kontrolle über eine Domain nachweisen (indem sie ein Token über HTTP ausliefert, einen DNS-Eintrag anlegt oder eine TLS-Challenge beantwortet), ein Zertifikat beziehen und es ohne menschliches Zutun erneuern. Let’s Encrypt, eine kostenlose, gemeinnützige CA, die 2015 mit der Ausstellung von Zertifikaten begann, machte kurzlebige, automatisch erneuerte Zertifikate zur Norm; Tools wie cert-manager tun dasselbe in Kubernetes, und jeder große Cloud-Load-Balancer kann Zertifikate für Sie verwalten.

Automatisierung ist nicht mehr optional. Nach dem Ballot SC-081 des CA/Browser Forum sank die maximale Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate für ab dem 15. März 2026 ausgestellte Zertifikate auf 200 Tage und sinkt ab dem 15. März 2027 auf 100 Tage und ab dem 15. März 2029 auf 47 Tage. Kurze Laufzeiten begrenzen den Schaden eines gestohlenen Schlüssels und verringern die Abhängigkeit vom Widerruf, der schon immer schlecht funktioniert hat. Architektonisch bedeutet das: Jedes Zertifikat, ob öffentlich oder intern, braucht einen Verantwortlichen, eine automatisierte Erneuerung, eine Überwachung der Ablaufdaten mit Alarmen lange vor der Frist und einen eingeübten manuellen Notfallweg.

Segmentierung und Mikrosegmentierung

Zero Trust bedeutet nicht, dass das Netzwerk keine Rolle mehr spielt; es bedeutet, dass das Netzwerk nicht mehr die einzige Kontrolle ist. Netzwerksegmentierung teilt die Infrastruktur in Zonen mit kontrollierten Pfaden dazwischen: öffentliche Subnetze für Load Balancer, private Subnetze für Services, isolierte Subnetze für Datenbanken und getrennte Cloud-Konten für Produktion, Staging und Sicherheitswerkzeuge. Mikrosegmentierung verkleinert die Zonen auf einzelne Workloads, sodass jeder Service Datenverkehr nur von den Aufrufern empfangen darf, die er braucht, und nur an seine deklarierten Abhängigkeiten senden darf.

In Kubernetes können alle Pods alle anderen Pods erreichen, solange keine NetworkPolicy-Ressourcen sie einschränken; der erste Schritt ist daher eine Default-Deny-Richtlinie pro Namespace, gefolgt von expliziten Freigaben. Die Kontrolle des ausgehenden Datenverkehrs (Egress) ist ebenso wichtig wie die des eingehenden: Ein kompromittierter Service, der keine Verbindungen ins Internet öffnen kann, kann gestohlene Daten nicht ohne Weiteres hinausschicken oder weitere Werkzeuge herunterladen. Security Groups in der Cloud, Kubernetes-Network-Policies und Autorisierungsrichtlinien des Meshes arbeiten auf verschiedenen Ebenen (Adressen und Ports, Pods und Labels, Workload-Identitäten und HTTP-Methoden) und werden am besten zusammen eingesetzt: Die äußeren Ebenen bieten groben Schutz, der auch eine Fehlkonfiguration des Meshes übersteht, die innere Ebene drückt die Absicht präzise aus. Das ist Defense in Depth (Abschnitt 8.1), angewandt auf das Netzwerk.

Das API-Gateway absichern

Das API-Gateway ist der wichtigste Durchsetzungspunkt zwischen dem Internet und den Services und hat daher mehrere Aufgaben. Authentifizierung: TLS terminieren, dann jedes Access Token validieren (Signatur mit fest vorgegebenem Algorithmus, Aussteller, Zielgruppe, Ablaufzeit und Not-before-Zeit), Anfragen ohne Token ablehnen und an die Services eine verifizierte Identität weitergeben, niemals die rohen Angaben des Clients. Rate Limiting: Anfragen pro Client, pro Nutzer und pro Route begrenzen, meist mit einem Token Bucket, und mit HTTP 429 samt Retry-After-Header antworten; eigene, strengere Limits schützen Login, Passwort-Zurücksetzung und das Einlösen von Gutscheinen vor Credential Stuffing und Enumeration. Eingabevalidierung: maximale Anfragegrößen und Header-Anzahlen durchsetzen, nur die deklarierten Content-Types akzeptieren und Bodys gegen das OpenAPI-Schema validieren, damit fehlerhafte Anfragen nie einen Service erreichen. Eine Web Application Firewall kann generische Angriffssignaturen ergänzen, ist aber eine Ergänzung, kein Ersatz für korrekten Code.

Kennen Sie die Grenzen eines Gateways. Es sieht die Route und das Token, aber nicht, ob Bestellung 81723 dem Kunden gehört, der sie anfordert. Broken Object Level Authorization, bei der ein Nutzer eine Kennung in der URL ändert und die Daten eines anderen liest, stand sowohl in der Ausgabe 2019 als auch in der Ausgabe 2023 der OWASP API Security Top 10 an erster Stelle, und nur der Service, dem die Daten gehören, kann sie verhindern. Services müssen daher jede Anfrage selbst autorisieren, mit der verifizierten Identität, die das Gateway weiterreicht. Ruft ein Service im Auftrag eines Nutzers einen anderen auf, sollte er ein Token weitergeben, das sowohl den Nutzer als auch den aufrufenden Service nennt, etwa per OAuth 2.0 Token Exchange (RFC 8693) bezogen, statt seines eigenen allmächtigen Berechtigungsnachweises; sonst macht ein Fehler in einem Service ihn zu einem Confused Deputy, der für jeden handeln kann.