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 (und solche Richtlinien wirken nur, wenn das Netzwerk-Plugin des Clusters sie durchsetzt); 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.

Browsersicherheit: Same-Origin-Policy, CORS und CSRF

Bisher waren die Aufrufer Services und Apps, die ihre eigenen Zugangsdaten halten. Ein Browser ist anders: Er führt Code vieler Websites nebeneinander aus und hängt die Cookies eines Nutzers automatisch an. Die Kundenwebsite und das Restaurantportal der Plattform haben daher eine Vertrauensgrenze im Browser des Kunden, wo kein Gateway hinkommt. Der Ausgangspunkt ist die Same-Origin-Policy. Zwei URLs teilen sich nur dann einen Origin, wenn Schema, Host und Port alle übereinstimmen, und Skripte eines Origins sind eingeschränkt darin, wie sie auf Ressourcen eines anderen zugreifen können. Die Einschränkung trifft vor allem das Lesen: Cross-Origin-Lesezugriffe werden typischerweise blockiert, Cross-Origin-Schreibzugriffe wie Formularübermittlungen typischerweise erlaubt.

Cross-Origin Resource Sharing (CORS) ist die kontrollierte Lockerung dieser Regel. Ruft die Website auf app.example.com die Adresse api.example.com auf, sind das verschiedene Origins, also muss die API mit Access-Control-Allow-Origin antworten und die Website nennen. Bei allem, was über eine einfache Anfrage hinausgeht (ein PUT oder DELETE, ein eigener Header, ein JSON-Body), fragt der Browser zuerst mit einem OPTIONS-Preflight um Erlaubnis. Drei Punkte werden oft missverstanden. Der Browser setzt CORS durch, der Server erklärt nur eine Policy; Tools wie curl ignorieren sie also, und die API muss weiterhin jeden Aufruf authentifizieren und autorisieren. CORS lockert die Same-Origin-Policy immer nur; es fügt keinen Schutz hinzu. Und eine einfache Anfrage erreicht den Server trotzdem und kann Wirkung entfalten: Nur die Antwort wird zurückgehalten. Ein Wildcard-Origin wird bei Anfragen mit Zugangsdaten abgelehnt, und jeden eintreffenden Origin einfach zurückzugeben, verfehlt den Zweck; vergleichen Sie ihn also mit einer Allowlist.

Cross-Site Request Forgery (CSRF) nutzt genau diese Lücke aus. Eine Seite einer anderen Website veranlasst den Browser, eine Anfrage an die Plattform zu senden, das Cookie des Kunden geht womöglich mit, und der Server sieht etwas, das aussieht, als ändere der Kunde eine Lieferadresse. Die wichtigsten Abwehrmaßnahmen von OWASP sind ein unvorhersagbares Token, das bei jeder zustandsändernden Anfrage geprüft wird (pro Sitzung, wo der Server Zustand hält, ein signiertes Double-Submit-Cookie, wo nicht), oder eine Prüfung des Sec-Fetch-Site-Headers mit Rückfall auf die Prüfung von Origin. Das SameSite-Cookie-Attribut aus Abschnitt 8.3 ist nützliche Defense in Depth, aber kein Ersatz: Lax sendet Cookies weiterhin bei seitenübergreifenden GET-Navigationen auf oberster Ebene, ein GET darf also nie den Zustand ändern. Ein per Skript in einem Authorization-Header gesendetes Token wird nicht automatisch angehängt und ist auf diese Weise nicht angreifbar, doch ein Backend for Frontend bringt Cookies zurück und braucht CSRF-Schutz. Eine Warnung: Cross-Site-Scripting hebelt all diese Abwehrmaßnahmen aus, was zur nächsten Kontrolle führt.

Content Security Policy und Sicherheits-Header

Content Security Policy (CSP) ist ein Antwort-Header, der dem Browser sagt, was eine Seite laden und ausführen darf. Ihr Hauptnutzen ist, den Schaden durch Cross-Site-Scripting zu begrenzen: Mit einer Policy werden eingeschleuste Inline-Skripte, Inline-Event-Handler und eval() blockiert, sofern die Policy sie nicht ausdrücklich erlaubt. Die W3C-Spezifikation macht deutlich, dass CSP am besten als Defense in Depth genutzt wird: Sie verringert den Schaden einer Injection, ersetzt aber nicht die Eingabevalidierung und die Ausgabekodierung. CSP Level 3 ist noch ein Working Draft, prüfen Sie also die aktuelle Version und die Browserunterstützung.

Allowlists von Hosts lassen sich oft umgehen und sind schwer zu pflegen, deshalb bevorzugen aktuelle Empfehlungen eine Strict CSP auf Basis von Nonces oder Hashes, zum Beispiel script-src 'nonce-RANDOM'; object-src 'none'; base-uri 'none'. Eine Nonce muss bei jeder Antwort ein neuer, unvorhersagbarer Wert sein, was eine architektonische Folge hat: Seiten müssen pro Antwort erzeugt werden, während zu gecachten statischen Seiten Hashes passen, die bei jeder Skriptänderung neu berechnet werden müssen. Jedes Drittanbieter-Skript, etwa ein Zahlungs-Widget oder ein Analyse-Tag, muss inventarisiert und erlaubt werden. Der sichere Rollout ist Content-Security-Policy-Report-Only: Die Policy meldet Verstöße an einen Endpoint, ohne etwas zu blockieren, und wird durchgesetzt, sobald die Berichte sauber sind. Die Direktive frame-ancestors 'none' verhindert zudem, dass andere Websites die Checkout-Seite in Frames einbetten, eine Abwehr gegen Clickjacking.

Einige weitere Header sind günstig und überall sinnvoll. Strict-Transport-Security (HSTS, RFC 6797) weist den Browser an, für die Website nur HTTPS zu verwenden; weil der allererste Besuch ungeschützt ist, können Websites auch die Aufnahme in die Preload-Liste der Browser beantragen. X-Content-Type-Options: nosniff hindert den Browser daran, Inhaltstypen zu erraten. Referrer-Policy: strict-origin-when-cross-origin hält Pfade und Bestellreferenzen aus dem Referrer heraus, der an andere Websites gesendet wird. Permissions-Policy schaltet Browserfunktionen ab, die eine Seite nicht braucht; die Kurierseite braucht womöglich Geolocation, die Speisekartenseite nicht. OWASP rät davon ab, sich auf den alten X-XSS-Protection-Header zu verlassen, und empfiehlt, ihn auf 0 zu setzen; prüfen Sie das Cheat Sheet auf aktuelle Werte.

Für den Architekten ist die Frage, wo diese Einstellungen liegen. Setzt jedes Team sie von Hand, wird ein Service sie vergessen. Setzen Sie sie einmal an der Edge oder im Gateway oder in einer gemeinsamen Vorlage, und testen Sie die deployten Antworten in der Pipeline als Fitness Function (Abschnitt 11.3).