Security in Ultra-Large-Scale Systems

Computer Science and Media, Hochschule der Medien, Stuttgart, Deutschland

Abstract

Ultra-Large-Scale-Systeme (ULS) mit mehreren tausend Microservices untergraben die Grundannahme klassischer Perimeter-Sicherheit: Netzwerkgrenzen sind in Cloud-nativen Umgebungen diffus, und ein kompromittierter Workload kann laterale Bewegung im gesamten internen Netz ermöglichen. Diese Arbeit untersucht, welche Zero-Trust-Mechanismen für eine Plattform nach dem Vorbild von Uber mit über 5.000 Microservices geeignet sind und welche Trade-offs hinsichtlich Latenz, Komplexität und Betriebsaufwand entstehen.

Der Architekturentwurf leitet Sicherheitsanforderungen aus einem MITRE-ATT&CK-basierten Bedrohungsmodell ab, wählt Technologiebausteine anhand der sieben NIST-SP-800-207-Grundsätze aus und bewertet Trade-offs qualitativ auf Basis öffentlich zugänglicher Engineering-Dokumentationen.

Das Ergebnis ist ein Schichtenmodell aus WAF/Edge, API-Gateway als externem Policy Enforcement Point, Service Mesh mit automatischem mTLS und Storage-Ebene. Querschnitts-Services (SPIFFE/SPIRE für kurzlebige Workload-Identitäten, Open Policy Agent für ABAC-basierte Policies und HashiCorp Vault für dynamisches Secrets Management) wirken auf allen Schichten. OAuth 2.0 mit DPoP bindet Nutzer-Tokens kryptografisch an den Client; Envelope-Verschlüsselung schützt regulierungspflichtige Felder in Data Lakes, ohne Analytics vollständig zu unterbrechen.

Der kryptografische Overhead ist mit Hardware-Beschleunigung und Token-Caching beherrschbar. Die zentrale Adoptionshürde ist operative Komplexität: Control-Plane-Services erfordern koordinierte Hochverfügbarkeit über Cloud-Anbietergrenzen; ohne Plattform-Abstraktionen entstehen abweichende Sicherheitsimplementierungen. Aktuelle systematische Überblicksarbeiten zur Zero-Trust-Adoption bestätigen dies.

Index Terms — Zero Trust, Ultra-Large-Scale Systems, API Gateway, Service Mesh, SPIFFE/SPIRE, OAuth 2.0, OIDC, Threat Modeling, mTLS, Policy as Code

I. Einleitung

A. Motivation und Relevanz: Sicherheit in hochskalierenden Umgebungen

Moderne digitale Plattformen haben eine Größenordnung erreicht, die grundlegende Anforderungen an Software-Engineering und Sicherheitsarchitektur neu definiert. Northrop et al. beschreiben Ultra-Large-Scale-Systeme (ULS-Systeme) als softwareintensive Systeme, die heutige Systeme in jeder Messgröße übertreffen: dezentrale Kontrolle, kontinuierliche Evolution, heterogene Elemente und Ausfälle als Normalzustand statt als Ausnahme [1]. Zeitgenössische Plattformen verkörpern dieses Paradigma konkret: Uber betreibt mehr als 5.000 Microservices, 5.000 Datenbanken sowie über 500.000 analytische Jobs täglich und authentifiziert mehr als 150.000 Secrets in einem verteilten Ökosystem [2]. Die zugrundeliegende Infrastruktur umfasst rund vier Millionen CPU-Kerne [3].

Die Verteilung auf Hunderte bis Tausende eigenständiger Services vergrößert die Angriffsfläche erheblich. Relevante Angriffsvektoren umfassen Kompromittierungen der Software-Lieferkette (Supply-Chain-Angriffe), Insider-Bedrohungen durch privilegierte Operatoren sowie laterale Bewegungen zwischen Services nach einem initialen Zugriff [4]. Erschwerend kommt hinzu, dass die Sicherheitseigenschaften verteilter Teilsysteme nicht einfach kompositionell sind [5].

Das klassische Perimeter-Sicherheitsmodell, auch als Castle-and-Moat-Ansatz bezeichnet, gewährt dem gesamten Datenverkehr innerhalb der privaten Netzwerkgrenze implizites Vertrauen. NIST Special Publication 800-207 hält fest, dass der Netzwerkstandort einer Ressource kein ausreichendes Sicherheitsmerkmal ist, weil Cloud-native Deployments, Remote Access und Multi-Cloud-Umgebungen eine klar definierte Perimeterlinie auflösen [6]. Ein Jahrzehnt ZTA-Forschung bestätigt diesen Befund [7], [8].

Jüngste Sicherheitsvorfälle zeigen, zu welchen Folgen fehlende interne Netzsegmentierung führt. Beim Uber-Breach vom 19. September 2022 gelangte ein der Lapsus$-Gruppe zugeordneter Angreifer über kompromittierte Contractor-Zugangsdaten aus dem Darknet und gezielte MFA-Fatigue in das interne Netz [9], [10]. Von dort wurden das Privileged-Access-Management-System (Thycotic), AWS, Google Workspace, Slack und HackerOne kompromittiert, ohne dass der Angreifer den vermeintlich vertrauenswürdigen Netzwerkbereich verließ [11]. Der SolarWinds-Angriff von 2020 zeigt das gleiche Grundprinzip auf Infrastrukturebene: Ein manipulierter Software-Update-Mechanismus reichte aus, um tausende nachgelagerte Organisationen zu kompromittieren [12].

B. Problemstellung und Forschungsfragen

Obwohl die wissenschaftliche Literatur zur Zero Trust Architecture (ZTA) in den vergangenen Jahren erheblich gewachsen ist, fehlt bislang eine Analyse, die Zero Trust-Prinzipien von der Edge bis zur Datenhaltung für ein ULS-System mit mehreren tausend Microservices schichtübergreifend umsetzt und bewertet [13], [14]. Diese Arbeit adressiert folgende Forschungsfrage:

> Welche Zero-Trust-Mechanismen sind für ein ULS-System nach dem Vorbild der Uber-Plattform geeignet, und welche Trade-offs entstehen hinsichtlich Latenz, Komplexität und Betriebsaufwand?

Die Untersuchung beschränkt sich auf Software- und Infrastrukturebene. Physische Rechenzentrumssicherheit, Endpoint-Schutz und Mobile Device Management sowie detaillierte Compliance-Mapping (SOC 2, ISO 27001) werden nicht behandelt. Netzwerkmechanismen unterhalb von Layer 4 des OSI-Modells werden nur berücksichtigt, sofern sie unmittelbar mit Anwendungsschicht-Sicherheitskontrollen interagieren.

C. Zielsetzung und Beitrag des Papers

Ziel dieser Arbeit ist der Entwurf einer Zero-Trust-Sicherheitsarchitektur für ein ULS-System am Fallbeispiel einer Uber-ähnlichen Plattform. Das Paper liefert eine konsolidierte Schichtenarchitektur, die Edge-Load Balancing, API-Gateway, Service Mesh, asynchrone Nachrichtenkommunikation und Datenspeicherung integriert. Ergänzend wird der kryptografische Overhead (mTLS-Handshake, JWT-Validierung, Encryption-at-Rest) gegen Systemleistung und Betriebsaufwand abgewogen. Schließlich werden ausgewählte Technologien (SPIFFE/SPIRE, Istio, Open Policy Agent, OAuth 2.0/OIDC) anhand der NIST-ZT-Prinzipien qualitativ bewertet [6].

Der weitere Aufbau des Papiers gliedert sich wie folgt: Abschnitt II legt die Grundlagen zu ULS-Systemen, Bedrohungsmodell und Zero-Trust-Paradigma. Abschnitt III beschreibt die Methodik. Die Abschnitte IV und V stellen Architektur und Datenflüsse vor. Abschnitt VI erläutert die Sicherheitsmechanismen im Detail. Abschnitt VII analysiert Alternativen und Trade-offs, gefolgt von der Betrachtung der Auswirkungen auf benachbarte Systeme (Abschnitt VIII), einem Ausblick (Abschnitt IX) und dem Fazit (Abschnitt X).

II. Grundlagen und verwandte Arbeiten

A. Charakteristika von Ultra-Large-Scale Systems (ULS)

Der Begriff Ultra-Large-Scale System geht auf einen Bericht des Software Engineering Institute zurück, der softwareintensive Systeme beschreibt, deren Skalierung in jeder Messgröße – Codezeilen, Anzahl Beteiligter, Datenvolumen, Verbindungen, Hardware-Elemente – bestehende Systeme um Größenordnungen übertrifft [1]. Northrop et al. identifizieren fünf prägende Eigenschaften [1], [15]:

1. dezentrale Kontrolle ohne zentrale Autorität

2. kontinuierliche Evolution während des Betriebs

3. heterogene Bestandteile

4. konfliktäre Stakeholder-Interessen

5. Hardware- und Softwarefehler als Normalzustand statt als Ausnahme

Eine ergänzende Sicht betont Menschen nicht nur als Nutzer, sondern als Elemente des Systems [15], [16].

Zeitgenössische Plattformen verkörpern diese Definition. Uber betreibt rund 5.000 Microservices auf etwa vier Millionen CPU-Kernen und verarbeitet täglich über 500.000 analytische Jobs [2], [3]. Über 150.000 Secrets werden für Service-zu-Service-Authentifizierung verwaltet, ergänzt um Integrationen zu mehr als 400 Drittanbietern und SaaS-Anwendungen [2]. Vergleichbare Charakteristika treten bei großen Plattformanbietern auf und stehen im Fokus aktueller Forschung zu verteilten Systemen [17].

Aus dieser Skalierung folgt ein Sicherheitsproblem, das sich nicht kompositionell aus den Einzelkomponenten ableiten lässt. Die Sicherheitseigenschaften eines Systems entstehen erst aus den Interaktionen seiner heterogenen Teilsysteme [5].

B. Bedrohungs- und Angreifermodell

Als Klassifikationsrahmen dient die MITRE-ATT&CK-Matrix in ihrer Cloud-Ausprägung, die Taktiken und Techniken realer Angreifer entlang des Lebenszyklus eines Angriffs strukturiert [18], [19]. Auf Entwurfsebene wird STRIDE ergänzend zur Bedrohungsmodellierung einzelner Komponenten herangezogen.

Das Modell beruht auf drei Annahmen:

1. Das Netzwerk ist feindlich. Im Sinne von NIST SP 800-207 darf die physische oder logische Netzlage einer Ressource kein Vertrauen begründen, weshalb jede Verbindung unabhängig vom Standort authentifiziert und verschlüsselt werden muss [6].

2. Insider-Bedrohungen werden durch privilegierte Operatoren, Contractor und kompromittierte Identitäten als realistisch angenommen; der Uber-Vorfall von 2022 belegt diese Annahme [10], [11].

3. Mindestens ein Workload gilt zu jedem Zeitpunkt als potenziell kompromittiert, sodass laterale Bewegung zwischen Services und Privilegieneskalation explizit ins Modell aufgenommen werden [4].

Aus diesen Annahmen folgen die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit, ergänzt um Auditierbarkeit und Nicht-Abstreitbarkeit als Voraussetzung für forensische Aufklärung und regulatorische Nachweise. In Multi-Tenant-Umgebungen tritt zusätzlich die Mandantenisolation als eigenes Schutzziel hinzu [20], [21].

Außerhalb des Betrachtungsumfangs liegen physische Rechenzentrumssicherheit, Endpoint-Schutz und Social-Engineering-Abwehr auf Nutzerebene. Letztere wird zwar als Eintrittsvektor anerkannt, weil sie sowohl beim Uber-Breach als auch in vergleichbaren Vorfällen den initialen Zugriff ermöglichte [9], [10], ihre Abwehr gehört jedoch zu organisatorischen Kontrollen außerhalb der Softwarearchitektur.

C. Das Zero-Trust-Paradigma (gemäß NIST SP 800-207)

Den Begriff Zero Trust prägte ursprünglich Forrester Research um 2010 als Gegenentwurf zur perimeterbasierten Netzsicherheit. Eine erste großflächige Umsetzung im Unternehmensbetrieb dokumentierte Google mit dem BeyondCorp-Modell, das Vertrauen vom Netzwerkstandort entkoppelt und an authentifizierte Geräte und Nutzer bindet [22]. Standardisiert wurde das Paradigma 2020 durch NIST Special Publication 800-207 [6], ergänzt 2023 um SP 800-207A für zugriffsorientierte Steuerung in Cloud-nativen Umgebungen mit mehreren Anbietern [23].

NIST SP 800-207 formuliert sieben Grundsätze einer ZTA [6]:

1. alle Datenquellen und Rechenservices gelten als Ressourcen

2. jede Kommunikation wird unabhängig vom Netzwerkstandort gesichert

3. Zugriff auf einzelne Ressourcen erfolgt pro Sitzung

4. Zugriffsentscheidungen basieren auf dynamischen Richtlinien unter Berücksichtigung von Identität, Asset-Zustand und Verhaltensattributen

5. Integrität und Sicherheitslage aller Assets werden überwacht

6. Authentifizierung und Autorisierung erfolgen dynamisch und werden vor jedem Zugriff streng durchgesetzt

7. das Unternehmen sammelt Telemetrie über Assets, Infrastruktur und Kommunikation, um die Sicherheitslage fortlaufend zu verbessern.

Architektonisch trennt NIST diese Grundsätze in einen Policy Decision Point (PDP), der über Zugriffe entscheidet, und einen Policy Enforcement Point (PEP), der die Entscheidung in der Datenebene durchsetzt [6]. Der PDP setzt sich aus einer Policy Engine und einem Policy Administrator zusammen; die kontinuierliche Verifikation ergibt sich aus dem Zusammenspiel mit externen Signalquellen wie Identitäts- und Endpoint-Management. Systematische Übersichten der letzten Jahre bestätigen die wachsende Adoption des Modells und benennen offene Fragen zu Performance, Komplexität und Reifegrad der Werkzeuge [7], [8], [13], [14].

D. Relevante Publikationen und Standards (IETF RFCs, CNCF-Standards)

Auf Standardisierungsebene stützt sich diese Arbeit primär auf IETF-Spezifikationen. RFC 6749 definiert das OAuth-2.0-Autorisierungsframework und die delegierte Vergabe von Zugriffsrechten an Dritte [24]. RFC 7519 spezifiziert das JSON-Web-Token-Format (JWT) als kompakte, signierbare Repräsentation von Claims [25]. RFC 7523 ergänzt JWT als Profil für Client-Authentifizierung und Grant Types [26]. Für den Identitätstransfer zwischen Services in einer Service-Kette regelt RFC 8693 den OAuth 2.0 Token Exchange [27]. RFC 9449 (DPoP) bindet Access Tokens kryptografisch an den ausstellenden Client und mitigiert damit Token-Diebstahl auf Transportebene [28]. Für die Verifikation serverseitiger Identitäten bei TLS-Verbindungen, einschließlich der für mTLS relevanten SAN-Validierung, gilt RFC 6125 [29]. Ergänzend formulieren Sheffer et al. konkrete Empfehlungen zum sicheren Einsatz von TLS und DTLS [30].

Aus dem CNCF-Ökosystem sind vier Projekte für diese Arbeit zentral. SPIFFE und seine Referenzimplementierung SPIRE liefern verifizierbare Workload-Identitäten in Form von SVIDs (X.509 oder JWT) und übernehmen Node- und Workload-Attestation [31], [32]. Istio realisiert ein Service Mesh mit automatischer mTLS-Einbettung über Envoy-Sidecars oder eine Sidecarless-Variante; Performance-Vergleiche zu eBPF-basierten Alternativen liegen vor [33], [34]. Open Policy Agent ermöglicht zentral gepflegte, deklarative Autorisierungsentscheidungen über die Sprache Rego und implementiert damit den PDP außerhalb der Anwendungslogik [35]. Google ALTS dient als proprietäres Vergleichssystem für mTLS in einer einzelnen Trust-Domain [36].

Akademisch ordnen sich die folgenden Vorarbeiten ein. Haindl et al. liefern eine systematische Übersicht zu Inter-Service-Bedrohungen in Microservice-Architekturen und benennen mTLS, Workload-Identität und Policy-Engines als zentrale Mitigationen [4]. Olivero et al. ordnen die Sicherheitsforschung für Systems-of-Systems systematisch ein und zeigen die fehlende Kompositionalität von Sicherheitseigenschaften auf [5]. Viswanathan beschreibt die Umsetzung von Zero Trust in einer konkreten Cloud-Plattform und liefert empirische Daten zu Adoption und Limitierungen [37]. Rajendran et al. und Mushtaq et al. ergänzen aktuelle systematische Übersichten zur Identity-Federation und zu domänenübergreifenden ZTA-Umsetzungen [14], [13]. Diese Arbeiten schließen jeweils einzelne Schichten ab, lassen aber eine durchgängige Betrachtung von der Edge bis zur Datenhaltung offen.

III. Methodik

Der Architekturentwurf folgt drei aufeinander aufbauenden Schritten. Im ersten Schritt werden aus den Eigenschaften eines ULS-Systems nach Northrop et al. und dem in Abschnitt II.B dargelegten Bedrohungsmodell konkrete Sicherheitsanforderungen abgeleitet [1]. Resultat ist ein Anforderungskatalog, der verifizierbare Workload-Identität, verschlüsselte Transportverbindungen, feingranulare Autorisierung, Auditierbarkeit und Betriebsfähigkeit unter Teilausfall umfasst. Im zweiten Schritt werden Technologiebausteine ausgewählt, die den sieben Grundsätzen von NIST SP 800-207 (vgl. Abschnitt II.C) genügen [6]. Im dritten Schritt werden die gewählten Bausteine hinsichtlich Latenz, Betriebskomplexität und erreichtem Sicherheitsniveau gegenübergestellt.

Für die Komponentenauswahl gelten vier Kriterien:

1. Konformität mit NIST SP 800-207 beziehungsweise SP 800-207A für Cloud-native Umgebungen [23],

2. Reifestatus als CNCF-Graduated-Projekt oder vergleichbarer industrieller Reifegrad,

3. dokumentierter Produktionseinsatz bei mindestens einem Hyperscale-Betreiber sowie

4. öffentlich verfügbare Performance-Daten, die eine qualitative Latenzabschätzung ermöglichen.

Technologien, für die weder Betreiberdokumentation noch akademische Vergleichsmessungen vorliegen, werden nicht berücksichtigt.

Als Bezugsrahmen dient die Uber-Plattform, weil sie sowohl die Charakteristika eines ULS-Systems erfüllt [3] als auch einen hohen Grad an öffentlicher Architekturdokumentation bereitstellt. Die herangezogenen Primärquellen umfassen technische Blogbeiträge des Uber Tech Blogs zur SPIFFE/SPIRE-Einführung [38], zur API-Gateway-Architektur [39], zur Kafka-Absicherung [40] und zum Secrets-Management [2]. Als akademische Sekundärquellen dienen aktuelle Systematic Reviews zu Zero-Trust-Architekturen und Microservice-Sicherheit [7], [13], [4]. Normative Referenzen sind IETF-RFCs und NIST-Dokumente. Wo Uber-Dokumentation fehlt, werden öffentliche Architekturbeschreibungen von Netflix und Google ergänzend herangezogen [41], [36].

Das Vorgehen unterliegt drei Einschränkungen:

1. Interne Architekturdokumente und produktive Messdaten der betrachteten Plattformen stehen nicht zur Verfügung; die Analyse beruht ausschließlich auf öffentlich zugänglichen Quellen.

2. Die Trade-off-Bewertung bleibt qualitativ, da kein Laboraufbau realisiert wurde.

3. Die verfügbaren Engineering-Dokumente decken nicht alle Architekturebenen vollständig ab, sodass einzelne Designentscheidungen aus den veröffentlichten Prinzipien extrapoliert werden müssen.

IV. Architekturentwurf und Modulansicht

A. Architekturüberblick und Designprinzipien

Die Architektur folgt einem Schichtenmodell, das jeden Aufruf einer Ressource über mehrere unabhängig kontrollierbare Komponenten führt. Eingehender Traffic passiert zunächst die äußere Peripherie aus globalen Load Balancern und Web Application Firewalls, anschließend ein API-Gateway als Policy Enforcement Point auf Layer 7, danach ein internes Service Mesh mit automatischem mTLS und schließlich die jeweils zuständigen Microservices. Asynchrone Kommunikation wird über eine Kafka-Backplane geführt, persistente Daten in transactional Storages und Data Lakes abgelegt. Workload-Identität (SPIFFE/SPIRE), zentrale Policy-Auswertung (Open Policy Agent) und ein Secrets-Vault sind Querschnitts-Services, die auf allen Schichten wirken. Abbildung 1 skizziert das Zusammenspiel.

Drei Leitprinzipien strukturieren den Entwurf:

1. Defense in Depth verlangt, dass keine einzelne Kontrolle als hinreichend gilt; eine kompromittierte Schicht darf benachbarte Schichten nicht aushebeln [42], [34].

2. Least Privilege weist jeder Identität ausschließlich die für ihre Funktion notwendigen Rechte zu und ist damit Voraussetzung für die in NIST SP 800-207 geforderte dynamische, sitzungsbasierte Zugriffsentscheidung [6].

3. Fail Secure schreibt vor, dass im Fehlerfall der restriktivere Zustand eingenommen wird, sodass etwa eine fehlgeschlagene Token-Validierung zur Verweigerung statt zur Durchleitung führt.

Die Modulansicht entspricht damit den in der Literatur dokumentierten mehrschichtigen Sicherheitsmustern verteilter Systeme [4], [34].

B. Äußere Peripherie: Load Balancing und Web Application Firewall (WAF)

Die äußere Peripherie absorbiert volumenbasierte Angriffe und filtert generische Angriffsmuster, bevor Traffic die Anwendungslogik erreicht. Anycast-DNS leitet Anfragen auf den nächstgelegenen, gesunden Edge-Standort; dahinter verteilen Global Load Balancer den Traffic regionenübergreifend und sind Voraussetzung für die in Hyperscale-Umgebungen geforderte Failover-Fähigkeit [3]. Volumetrische und protokollbasierte Denial-of-Service-Angriffe werden auf dieser Ebene durch Edge-Rate-Limits, SYN-Cookies und Scrubbing-Center abgefangen [43].

Eine vorgeschaltete WAF filtert Angriffe auf Layer 7. Als Basis dient typischerweise das OWASP Core Rule Set, das Signaturen für Injection, Cross-Site Scripting und Protokollanomalien bereitstellt [44]. Ergänzende Bot-Mitigation reduziert automatisierte Account-Übernahmen und Credential-Stuffing-Versuche.

Die Entscheidung zwischen TLS-Terminierung an der WAF und TLS-Passthrough hat unmittelbare Sicherheitsfolgen. Terminierung erlaubt die Inspektion des Klartextverkehrs und damit die volle WAF-Regelauswertung, erfordert aber, dass die Edge-Komponente vertrauenswürdiger Bestandteil der Trust-Domain ist. Passthrough erhält die Ende-zu-Ende-Vertraulichkeit, verlagert die Filterung jedoch in das Backend und beschränkt die WAF auf Metadaten und Verbindungsmerkmale. Aktuelle Empfehlungen schreiben in beiden Fällen TLS 1.3 oder höher, deaktivierte Legacy-Cipher und PFS-fähige Suites vor [30].

C. Edge-Infrastruktur: Das API-Gateway als Policy Enforcement Point

Das API-Gateway ist der erste anwendungsnahe Policy Enforcement Point und konsolidiert Querschnittsfunktionen, die andernfalls in jedem Microservice dupliziert werden müssten [6]. Zu seinen Kernaufgaben zählen die Authentifizierung des Endnutzers, eine grobgranulare Autorisierung auf Ressourcen- und Methodenebene, Rate Limiting, Request-Validierung gegen ein verbindliches Schema sowie das Routing zur zuständigen Microservice-Instanz [39]. Bei einer Uber-ähnlichen Plattform mit mehreren tausend Backend-Services ist diese Konsolidierung Voraussetzung für konsistente Sicherheitskontrollen und einheitliche Telemetrie.

Die Token-Validierung erfolgt im Regelfall lokal über die Signaturprüfung von JWTs gegen den öffentlichen Schlüssel des Identity Providers [25]. Für Tokens mit Widerrufsanforderung oder für undurchsichtige Referenz-Tokens nach RFC 6749 wird die Introspection-Variante ergänzt [24]. Lokale Validierung minimiert Latenz, Introspection liefert stärkere Aktualitätsgarantien; produktive Gateways kombinieren beide Pfade abhängig vom Token-Typ.

Als Implementierungen kommen Open-Source-Komponenten wie Envoy, Kong und Ambassador in Betracht [45], [46], [47]; akademische Arbeiten zeigen die Eignung von Kong als Trägerschicht für JWT-basierte Microservice-Authentifizierung im Edge-Computing-Kontext [48]. Eigenentwickelte Gateways großer Plattformen verfolgen vergleichbare Designziele, optimieren aber zusätzlich Protokoll-Adaption und Backend-Routing [39].

D. Interne Infrastruktur: Service Mesh und asynchrone Backplanes (zum Beispiel Kafka)

Innerhalb der Trust-Domain übernimmt ein Service Mesh die mTLS-Einbettung zwischen Services, die Auflösung von Workload-Identitäten und die Durchsetzung feingranularer Layer-7-Policies. Das klassische Sidecar-Pattern injiziert einen Envoy-Proxy in jeden Pod und entkoppelt die Sicherheitskontrollen vollständig von der Anwendung [34]. Sidecarless-Varianten verlagern Operationen der Datenebene über eBPF in den Kernel und reduzieren so Speicher- und CPU-Overhead pro Workload [33], [49], [50]. Empirische Vergleiche der Mesh-Implementierungen zeigen, dass die mTLS-Aktivierung die Anfragelatenz in spürbarem, aber beherrschbarem Rahmen erhöht [51]. Die Workload-Identität liefert in beiden Varianten SPIFFE/SPIRE in Form kurzlebiger SVIDs, was die laterale Bewegung nach einem initialen Kompromiss erheblich erschwert [38].

Asynchrone Kommunikation wird über Kafka als Backplane geführt. Die Absicherung kombiniert TLS-Verschlüsselung des Transports, SASL/SCRAM oder SASL/OAUTHBEARER zur Client-Authentifizierung sowie topic-granulare ACLs zur Autorisierung von Producer- und Consumer-Operationen [52]. Großbetreiber ergänzen diese Mechanismen um zentral verwaltete Schlüsselrotation und mandantengetrennte Topic-Hierarchien [40].

E. Storage- und Analyse-Schicht (Data Lakes)

Die Storage- und Analyseschicht ist die letzte Verteidigungslinie und zugleich die datenintensivste. Voraussetzung jeder Schutzmaßnahme ist eine konsistente Datenklassifikation, die jedes Feld nach Schutzbedarf in Kategorien wie öffentlich, intern, vertraulich und personenbezogen einsortiert und damit Verschlüsselungs- und Zugriffsentscheidungen mechanisch ableitbar macht [20].

Data-Lake-spezifische Governance-Services wie AWS Lake Formation oder Databricks Unity Catalog setzen daraus zeilen-, spalten- und tag-basierte Zugriffsregeln um und verbinden Identity-Management mit objektbasierter Speicherung [53], [54]. In Multi-Tenant-Umgebungen ergänzen mandantenisolierende Maßnahmen wie getrennte Schlüsselhierarchien und partitionierte Compute-Ressourcen den Schutz vor Cross-Tenant-Zugriffen und Side-Channel-Angriffen [55], [56], [21].

Sensible Felder werden zusätzlich auf Anwendungsebene durch Tokenisierung oder formatbewahrende Pseudonymisierung geschützt; der Klartext verlässt das Vault nicht und bleibt für Analytics in einer kontrollierten Form referenzierbar [57], [58]. Damit bleibt die Schicht auch dann widerstandsfähig, wenn eine darüberliegende Komponente kompromittiert wird.

V. Datenfluss und Systemkommunikation

A. Synchroner Lebenszyklus einer Nutzeranfrage (Demand-Side)

Am Beispiel einer Buchungsanfrage lässt sich die Sicherheitskette vom Client bis zur Datenspeicherung vollständig nachverfolgen. Ein Nutzer ruft POST /v1/rides auf; das Sequenzdiagramm in Abbildung 2 zeigt die Abfolge der Sicherheitskontrollen je Schicht.

Die Anfrage verlässt den Client als HTTPS-POST mit einem DPoP-gebundenen Access Token gemäß RFC 9449. Dieser Token ist kryptografisch an den privaten Schlüssel des Clients gebunden, sodass er auf einem anderen TLS-Kanal nicht verwendbar ist [28]. Am API-Gateway, dem ersten anwendungsnahen Policy Enforcement Point, wird die JWT-Signatur lokal gegen den öffentlichen Schlüssel des Identity Providers geprüft, der DPoP-Proof validiert und eine grobgranulare Autorisierungsanfrage an den OPA-Policy-Decision-Point gestellt [6], [39], [25].

Vor der internen Weiterleitung tauscht das Gateway das externe Nutzertoken gegen ein internes Servicetoken aus. Der OAuth-2.0-Token-Exchange nach RFC 8693 behält das original Subject (sub) des Nutzers, fügt dem neuen Token den act-Claim mit der aufrufenden Service-Identität hinzu und schränkt den Scope auf das minimal Notwendige ein [27]. Das externe Token gelangt damit nicht in das interne Netz, während der Nutzerkontext für Audit und feingranulare Autorisierung erhalten bleibt. Netflix verfolgt einen vergleichbaren, tokenformat-agnostischen Ansatz: Ein einheitlicher Caller-Kontext wird über alle Service-Hops mitgeführt, unabhängig vom ursprünglichen Token-Format [41].

Im Service-Mesh belegt jede mTLS-Verbindung die Workload-Identität beider Peers durch ihre SPIFFE-SVIDs; der empfangende Service prüft, ob der Peer-SVID des Aufrufers für den angefragten Endpunkt autorisiert ist [38]. Für jeden weiteren Hop in der Aufrufkette – etwa vom Ride Service zum Driver-Matching-Service – führt der aufrufende Service einen neuen Token Exchange durch und schreibt den Nutzerkontext in den act-Claim fort [27], [14]. Jeder Hop ist damit einzeln rückverfolgbar: Wer hat im Auftrag welchen Nutzers aufgerufen? Das Gateway entfernt alle internen Header, bevor die Antwort den Client erreicht [4].

B. Asynchrone Telemetriedaten-Ströme (Supply-Side)

Neben synchronem Request-Response-Verkehr produziert die Plattform kontinuierlich asynchrone Event-Streams: Fahrtstatusereignisse, Aktualisierungen der Fahrerposition, Bezahlvorgänge und Audit-Events fließen über Kafka als zentrale Backplane [59]. Der direkte Schreibzugriff auf Kafka aus dem Anwendungscode heraus birgt das Risiko eines Datenverlusts, wenn ein Service nach dem Datenbank-Write, aber vor dem Topic-Publish abstürzt. Das Outbox-Pattern behebt dieses Problem: Der schreibende Service fasst Datenbankaktualisierung und Event-Eintrag in eine Outbox-Tabelle in einer einzigen Datenbanktransaktion zusammen. Ein separater Relay-Prozess liest die Outbox und überträgt Ereignisse erst dann an Kafka, wenn die Transaktion bestätigt ist; Datenbankkonsistenz und Ereignispublizierung sind damit atomar [4], [60].

Die Kafka-Absicherung kombiniert Transport-Verschlüsselung, Workload-Authentifizierung und feingranulare Autorisierung [40], [52]. TLS verschlüsselt alle Broker-zu-Client-Verbindungen; Producer und Consumer authentifizieren sich per SASL/OAUTHBEARER mit einem kurzlebigen JWT, das der lokale SPIRE-Agent ausstellt, sodass die Kafka-Identität direkt an die Workload-Identität gebunden ist. Topic-granulare ACLs legen fest, welche Workload welche Topics beschreiben oder lesen darf; ein kompromittierter Service hat damit maximal Zugriff auf die Topics, für die er Rechte besitzt. Großbetreiber ergänzen diese Mechanismen durch mandantengetrennte Topic-Hierarchien und zentral verwaltete Schlüsselrotation [40].

Replay-Schutz wird auf Payload- und Infrastrukturebene realisiert. Jedes Event enthält einen Timestamp und eine monoton steigende Sequenznummer; Consumer verwerfen Nachrichten, deren Timestamp außerhalb eines Toleranzfensters liegt oder deren Sequenznummer bereits verarbeitet wurde. Auf Infrastrukturebene verhindern Consumer-Group-Offsets eine doppelte Verarbeitung nach Service-Neustart [52].

Eine Schema Registry dient als Vertrauensanker für die Datenintegrität jedes Topics. Producer dürfen ausschließlich Nachrichten veröffentlichen, die einem registrierten, versionierten Schema entsprechen; Consumer validieren eingehende Nachrichten gegen dieselbe Schema-Version. Damit wird verhindert, dass ein kompromittierter Service strukturell abweichende oder überdimensionierte Nutzdaten in die Ereignispipeline einschleust [40]. Die Schema-Versionierung erlaubt kontrollierte Weiterentwicklung des Datenformats ohne rückwirkenden Kompatibilitätsbruch [61], [62].

C. Abgrenzung von Steuerdaten (Control Plane) und Nutzdaten (Data Plane)

NIST SP 800-207 unterscheidet zwischen dem Policy Decision Point, der Zugriffsrichtlinien auswertet, und dem Policy Enforcement Point, der Entscheidungen in der Datenebene durchsetzt [6]. Diese konzeptionelle Trennung manifestiert sich als explizite Architekturgrenze zwischen Control Plane und Data Plane. Die Data Plane umfasst den gesamten Nutz- und Geschäftsdatenverkehr: synchrone API-Aufrufe zwischen Microservices, Kafka-Eventstreams und eingehende Nutzeranfragen. Die Control Plane schließt alle Komponenten ein, die den Sicherheitszustand der Plattform verwalten: SPIRE für SVID-Ausstellung und Trust-Bundle-Verteilung, OPA für Policy-Distribution und -Auswertung, HashiCorp Vault für Secret-Ausstellung und Schlüsselrotation sowie der Kubernetes-API-Server für Workload-Lebenszyklus und Netzwerkpolicies [23], [38].

Die Sicherheitsrelevanz dieser Trennung ergibt sich aus einem konkreten Angriffsszenario. Gelingt es einem Angreifer, einen Microservice in der Data Plane zu kompromittieren, erhält er Zugriff auf die Ressourcen, für die dieser Service berechtigt ist. Hätte dieselbe Workload aber auch Schreibzugriff auf die OPA-Policy-Distribution oder die SPIRE-Admin-API, ließen sich Richtlinien der gesamten Plattform verändern oder SVIDs für beliebige Workloads ausstellen [4]. Die Isolation der Control Plane stellt sicher, dass ein Angreifer, der einen einzelnen Service übernimmt, keine systemweiten Sicherheitsgarantien aushebeln kann; laterale Bewegung bleibt auf die Data Plane beschränkt.

In der Praxis wird die Trennung durch separate Netzwerksegmente, eigene mTLS-Identitäten für Control-Plane-Verbindungen und restriktive Netzwerkpolicies realisiert [23]. Data-Plane-Workloads erhalten SVIDs, die laut SPIFFE-Policy nur zur Kommunikation mit definierten Service-Peers berechtigen; der Zugriff auf die SPIRE-Admin-API und den OPA-Management-Endpunkt bleibt auf explizit privilegierte Betreiber-Identitäten beschränkt. Alle Control-Plane-Zugriffe werden vollständig und manipulationssicher protokolliert [6].

Verwaltungs-APIs sind die wertvollste Angriffsfläche innerhalb der Control Plane. Jeder erfolgreiche Schreibzugriff auf die Policy-Engine entspricht in seiner Wirkung einem Zugriff auf alle Services, für die die geänderte Policy gilt. Policy-Deployment, SVID-Revokation und Schlüsselrotation müssen daher Vier-Augen-Prinzip, automatisierte Drift-Erkennung und kryptografisch verankerte Audit-Trails voraussetzen. Uber hat im Kontext seiner IAM-Plattform Mechanismen entwickelt, die Policy-Änderungen deterministisch und auditierbar machen, um unkontrollierte Konfigurationsabweichungen auszuschließen [63].

VI. Sicherheitsentscheidungen und Implementierung

A. Service-to-Service Kommunikation und Workload Identity (SPIFFE/SPIRE)

Die SPIFFE-basierte Workload-Identität wird durch das SPIFFE Verifiable Identity Document (SVID) realisiert. X.509-SVIDs sind kurzlebige TLS-Zertifikate, deren Subject Alternative Name eine SPIFFE URI der Form spiffe://trust-domain/path trägt; der lokale SPIRE-Agent rotiert sie automatisch (typische TTL: 1 Stunde), ohne manuelles Zertifikatmanagement [38]. JWT-SVIDs kodieren dieselbe Identität als signiertes JSON Web Token und kommen dort zum Einsatz, wo kein TLS-Handshake stattfindet, etwa bei HTTP-Callbacks oder Legacy-Schnittstellen ohne gegenseitiges Zertifikat [31].

Das Attestationsproblem lautet: Der SPIRE-Server muss sicherstellen, dass ein Anfrager die behauptete Identität tatsächlich besitzt, ohne auf statisch bereitgestellte Secrets zu vertrauen. SPIRE löst dies auf zwei Ebenen. Der Node Attestor prüft die Knotenidentität anhand der Cloud-Provider-API, etwa das EC2 Instance Identity Document bei AWS oder das GCP Compute-Engine-Zertifikat [32]. Der Workload Attestor belegt Workload-Identitäten anhand von Kernel-Metriken (Linux-PID, cgroup-Hierarchie, Kubernetes Service Account), die der Agent lokal ausliest [38]. Der SPIRE-Server erteilt eine SVID erst, wenn beide Stufen bestätigt sind.

In Multi-Cloud-Umgebungen betreibt jede Cloud-Region eine eigene Trust Domain mit eigenem Root-CA. Der SPIRE Federation Exchange synchronisiert Trust Bundles zwischen Domains, sodass ein Workload in AWS die X.509-SVID eines GCP-Workloads verifizieren kann, ohne einen gemeinsamen Zertifizierungspfad zu benötigen [31], [14]. Diese Föderierung ist Voraussetzung für konsistentes mTLS über Anbieter- und Regionsgrenzen, ist aber eine der operativ aufwändigsten Aufgaben bei der SPIFFE-Einführung, da Trust-Bundle-Ablauf und Erneuerung in allen Domains koordiniert werden müssen [31].

B. Nutzerauthentifizierung an der Systemgrenze (OAuth 2.0 & OIDC)

An der Systemgrenze authentifiziert OAuth 2.0 in Verbindung mit OpenID Connect Endnutzer gegenüber der Plattform. Der Authorization Code Flow mit PKCE (RFC 7636) ist der empfohlene Grant Type für mobile und browserbasierte Clients: Der Client erzeugt einen zufälligen Code Verifier, leitet daraus eine Code Challenge (SHA-256-Hash) ab und übermittelt letztere mit dem Authorization Request [24]. Der Authorization Server prüft den Code Verifier erst beim Token-Tausch; ein abgefangener Authorization Code ist ohne den Verifier wertlos [64]. OpenID Connect ergänzt OAuth um ein ID Token, ein JWT mit Claims wie sub, email und amr, das ausschließlich der Nutzeridentifikation gegenüber dem Client dient; der Access Token bleibt opak [24].

RFC 9449 (Demonstrating Proof of Possession, DPoP) bindet den Access Token kryptografisch an ein asymmetrisches Schlüsselpaar des Clients: Bei jedem Request legt der Client einen DPoP-Proof-JWT im Header vor, den der Ressourcenserver gegen den im Token hinterlegten öffentlichen Schlüssel prüft [28]. Ein gestohlener Bearer Token ist damit auf einem anderen Kanal nicht verwendbar. RFC 8705 bietet mTLS-gebundene Access Tokens als Alternative, bei denen der Ressourcenserver den Client-Zertifikat-Fingerprint im Token verankert [65]; für mobile Apps mit wechselnden Netzwerkverbindungen ist DPoP gegenüber zertifikatbasiertem Binding praktikabler [66].

Access Tokens erhalten kurze TTL (5–15 Minuten), um das Missbrauchsfenster nach einem Kompromiss zu begrenzen. Refresh Tokens folgen dem Rotationsprinzip: Bei jeder Einlösung stellt der Authorization Server ein neues Refresh Token aus und invalidiert das vorherige [64]. Eine doppelte Einlösung desselben Tokens signalisiert eine Replay-Attacke und löst vollständige Session-Revokation aus. Der Speicherort ist sicherheitskritisch: Auf Mobilgeräten eignet sich ein Secure-Enclave-geschützter Keystore, in Browsern ein HttpOnly-Cookie mit SameSite=Strict [64].

C. Autorisierung: Policy as Code

Rollenbasierte Zugriffskontrolle (RBAC) weist Zugriffsrechte statisch vordefinierten Rollen zu. In ULS-Systemen mit mehreren tausend Microservices führt das zu Rollenexplosion, die den Administrationsaufwand auf ein nicht skalierbares Maß treibt [6]. Attributbasierte Zugriffskontrolle (ABAC) bewertet Zugriffsanfragen gegen Subjektattribute (Service-Identität, Team), Ressourcenattribute (API-Pfad, Datensensitivitätsklasse) und Kontextattribute (Aufrufzeit, Nutzerregion). Wenige allgemeine Policies decken damit einen großen Anteil des Autorisierungsraums ab, ohne für jede Service-Kombination eine eigene Rolle zu pflegen. Uber setzt ABAC für die Service-zu-Service-Autorisierung in seiner Microservice-Landschaft ein [35].

Open Policy Agent (OPA) übernimmt die Rolle des Policy Decision Points und wertet Policies in der deklarativen Sprache Rego aus. Eingabe ist ein JSON-Dokument mit Token-Claims, angefragter Ressource und Kontextinformationen; Ausgabe ist ein boolesches allow-Ergebnis mit optionaler Begründung [35]. OPA läuft als In-Process-Bibliothek mit gecachten Entscheidungen unter einer Millisekunde Latenz oder als Sidecar-PDP mit separatem Lebenszyklusmanagement [37]. Die Entscheidungslogik bleibt dabei außerhalb der Anwendungscodebasis und ist unabhängig davon aktualisierbar.

Policies liegen als versionierter Code im Versionskontrollsystem und durchlaufen denselben CI-Prozess wie Anwendungscode: Konformitätstests prüfen vor dem Merge, ob neue Richtlinien bestehende Sicherheitsanforderungen verletzen [63]. Die OPA Bundle API überträgt versionierte Policy-Pakete atomar an alle PDP-Instanzen und verhindert unkontrollierte Abweichungen zwischen Deployments (Policy Drift) [6]. Uber ergänzt dies durch automatisierte Sicherheitsanalysen für IAM-Policy-Änderungen, die unbeabsichtigte Rechteausweitungen deterministisch erkennen und blockieren [63].

D. Multi-Cloud Secrets Management (Vermeidung von Secret Sprawl)

Als Secret Sprawl wird die unkontrollierte Proliferation von Credentials und kryptografischen Secrets über Environment-Variablen, Kubernetes ConfigMaps, CI-Pipelines und Anwendungsrepositorys bezeichnet. Ursachen sind dezentrales Teamwachstum ohne übergreifende Secret-Governance und der geringe initiale Aufwand manuell erzeugter, statischer Credentials. Uber verwaltet über 150.000 Secrets für mehr als 400 Drittanbieter- und SaaS-Integrationen; ohne zentrales Inventar ist weder Überblick noch koordinierte Rotation möglich [2].

Bei Uber legt HashiCorp Vault eine gemeinsame API über cloud-native KMS-Services (AWS KMS, GCP Secret Manager, Azure Key Vault) [2]. Services kommunizieren ausschließlich mit der Vault-API; provider-spezifische Authentifizierungsmechanismen und Formatunterschiede bleiben von der Anwendung entkoppelt. Zur Authentifizierung gegen Vault akzeptiert die Kubernetes Auth Method einen SPIFFE-SVID als Credential, womit statische Vault-Tokens entfallen. Jede Workload-Identität erhält nur die Vault-Policies, die ihre Funktion erfordert [6].

Vault generiert Datenbankzugangsdaten on-demand mit kurzer TTL, typischerweise eine Stunde, und zieht sie nach Ablauf automatisch zurück [2]. Kompromittierte Credentials sind damit zeitlich eng begrenzt nutzbar. Für externe API-Keys greift automatische Rotation: Die alte Secret-Version bleibt für eine Draining-Periode parallel gültig (Dual-Key-Rotation), sodass laufende Anfragen keinen Fehler erhalten. Alle Rotationsoperationen werden im Vault-Audit-Log protokolliert [2].

E. Fine-Grained Encryption für Data-at-Rest (spaltenbasierte Verschlüsselung)

Festplatten- oder objektweite Verschlüsselung schützt vor physischem Medienzugriff, lässt aber einen privilegierten Datenbankbenutzer sämtliche Felder lesen, sobald das Speichermedium entschlüsselt ist. Spaltenbasierte Verschlüsselung isoliert den Schutz auf Feldebene, sodass sensible Attribute wie Zahlungsdaten oder personenbezogene Informationen unabhängig vom Rest der Tabelle geschützt werden [67]. Uber nutzt Apache Parquet Native Encryption, um einzelne Spalten mit feldspezifischen Data Encryption Keys (DEK) zu sichern, während nicht-sensible Spalten im Klartext verbleiben und Analytics-Abfragen ohne vollständige Entschlüsselung erlauben [67].

Der DEK verschlüsselt die Nutzdaten; er selbst wird durch einen Key Encryption Key (KEK) verschlüsselt, der im KMS liegt und das System nicht verlässt [67]. Der verschlüsselte DEK kann neben den Daten abgelegt werden. KEK-Rotation erfordert nur eine Neu-Verschlüsselung des DEK, nicht der gesamten Datenmenge. Der KMS-Audit-Trail protokolliert jeden KEK-Entschlüsselungsvorgang und gibt Auskunft darüber, welche Entität wann welche Daten entschlüsselt hat [68].

Das Löschen des KEK im KMS macht alle zugehörigen verschlüsselten DEKs dauerhaft unlesbar, ohne Datensätze physisch zu entfernen (Crypto Shredding) [67]. Für den GDPR-Löschanspruch (Right to Erasure) in verteilten Data Lakes mit Petabyte-Skala, wo Löschen auf Zeilenebene über zahlreiche Partitionen nicht praktikabel ist, ist Crypto Shredding der operativ praktikablere Mechanismus. Die DEKs bleiben in den Dateien, sind ohne den revozierten KEK jedoch kryptografisch wertlos.

F. Observability und Audit

Sicherheitsrelevante Ereignisse werden als strukturierte JSON-Objekte mit Pflichtfeldern protokolliert: timestamp, service, trace_id, span_id, user_sub, action, resource und decision [6]. Diese Struktur macht Logs maschinell auswertbar und erlaubt forensische Rekonstruktion ohne Freitext-Parsing. Eine Trace-ID entsteht beim ersten Eingang am API-Gateway und wird über alle nachgelagerten Service-Hops via HTTP-Header im W3C-Trace-Context-Format propagiert; damit lässt sich jede Nutzeranfrage schichtübergreifend nachvollziehen, einschließlich jeder Autorisierungsentscheidung, jedes Token-Tauschs und jedes Kafka-Ereignisses in deren Folge [6].

Append-only Log-Streams, etwa als Kafka-Topic mit unveränderlicher Retention oder als WORM-konfigurierter Objektspeicher, verhindern nachträgliche Änderungen. Über jeweils einen Batch von Log-Einträgen wird ein Merkle-Tree-Hash berechnet; dieser Hash wird in den Folgebatch eingebettet und erzeugt eine Kette kryptografisch verknüpfter Prüfsummen [63]. Jeder Bruch in dieser Kette zeigt eine Manipulation an und ist durch das SIEM unabhängig verifizierbar. Uber setzt dieses Prinzip in seiner IAM-Policy-Infrastruktur ein, um Audit-Trails gegen Verfälschung zu sichern [63].

Alle Logs, Metriken und Traces fließen in ein zentrales SIEM. Regelbasierte Korrelation erkennt bekannte Angriffsmuster der MITRE-ATT&CK-Matrix, etwa ungewöhnliche Zugriffsfolgen auf Verwaltungs-APIs (T1078: Valid Accounts) oder erhöhte Token-Einlösungsraten [6]. ML-basierte Anomalieerkennung identifiziert Abweichungen von der service-spezifischen Baseline, darunter ungewöhnliche Endpoint-Zugriffsmuster und Cross-Tenant-Zugriffe. Erklärbare KI-Modelle machen Alerting-Entscheidungen für Operatoren nachvollziehbar [69]. Da jeder Alarm mit der aufrufenden SVID und dem vollständigen Trace verknüpft ist, lässt sich ein Vorfall auf die betroffene Workload und den Nutzerkontext eingrenzen.

VII. Alternativen, Trade-offs und Evaluation

A. Identitätsbasierte Zero-Trust-Modelle vs. klassische IP-Netzwerksicherheit

Das klassische Perimetermodell erteilt dem internen Datenverkehr implizites Vertrauen: Firewalls und Netzsegmentierung sichern die Außengrenze, während East-West-Verbindungen innerhalb des privaten Netzes ohne explizite Authentifizierung ablaufen. Gegen Cloud-native Deployments ohne feste Netzwerkgrenze, gegen Insider-Bedrohungen und gegen laterale Bewegung nach einem initialen Kompromiss ist das Modell strukturell nicht ausgelegt [6], [4].

Identitätsbasierte ZTA-Modelle binden Vertrauen an verifizierbare Workload-Identitäten statt an Netzwerkadressen und authentifizieren jede Verbindung unabhängig vom Standort [6]. Dieser Ansatz adressiert Insider-Bedrohungen und Multi-Cloud-Betrieb direkt, setzt aber eine substanzielle Infrastruktur voraus: SPIFFE/SPIRE für Workload-Attestation, OPA für Policy-Auswertung und einen hochverfügbaren Vault für Secrets. Kanoon (2026) dokumentiert, dass SPIRE-Einführungen in der Praxis an Interoperabilitätslücken für Legacy-Systeme, SaaS-Integrationen und CI/CD-Pipelines scheitern können [31]. Systematische Reviews bestätigen, dass operativer Aufwand und Tooling-Komplexität zu den zentralen Adoptionshürden zählen [7], [13].

Die SPIFFE/SPIRE-Einführung bei Uber verlief in zwei Phasen: ZTA-Kontrollen liefen im Shadow Mode (Autorisierungsentscheidungen wurden protokolliert, nicht erzwungen), bevor einzelne, sicherheitskritische Services in den Enforcement-Modus wechselten. Dieses inkrementelle Vorgehen senkte Betriebsrisiken gegenüber einem Big-Bang-Ansatz erheblich [38].

B. Zentralisiertes API-Gateway vs. dezentrale Validierung in den Microservices

Ein zentralisiertes API-Gateway bündelt externe Authentifizierung und grobgranulare Autorisierung an einem Eintrittspunkt. Das vereinfacht das Auditing, weil alle externen Anfragen denselben Kontrollpfad durchlaufen, und reduziert Inkonsistenzrisiken. Die Konzentration auf diesen einen Punkt bleibt das strukturelle Problem: Fällt das Gateway aus, legt es entweder den gesamten eingehenden Verkehr lahm oder ermöglicht bei fehlerhafter Failover-Konfiguration unkontrollierten Datendurchfluss. Bei mehreren tausend Microservices bildet das Gateway überdies einen Engpass, der vertikale Skalierung voraussetzt [39].

Dezentrale Validierung verteilt die Token-Prüfung auf jeden empfangenden Service. Ausfallresistenz steigt, weil kein einzelner Service das Gesamtsystem blockieren kann. Die Kehrseite ist inkonsistente Enforcement: Unterschiedliche Implementierungen derselben Validierungslogik in Hunderten von Services erzeugen Divergenzrisiken, die schwerer zu prüfen sind als eine zentrale Implementierung [4].

Das hybride Modell dieser Arbeit kombiniert beide Ansätze: Das API-Gateway verantwortet die externe Authentifizierung und grobgranulare Autorisierung; das Service Mesh führt pro Hop die mTLS-Prüfung der Workload-Identität durch; ein gemeinsamer OPA-PDP liefert Entscheidungen für beide Schichten. NIST SP 800-207A empfiehlt diese PDP/PEP-Trennung: logisch zentralisierter PDP, eng am Datenpfad angesiedelter PEP [23]. Eine Fail-Secure-Konfiguration muss dabei operativ erzwungen werden: Ist der PDP nicht erreichbar, wird der Zugriff verweigert, nicht durchgeleitet [6].

C. Abwägung: Kryptografischer Overhead vs. System-Performance

Der kryptografische Overhead verteilt sich auf vier Bereiche.

mTLS-Handshake: Ein vollständiger TLS-1.3-Handshake erzeugt eine zusätzliche Round-Trip-Time und CPU-Last für die asymmetrische Schlüsselvereinbarung. TLS Session Resumption via Pre-Shared Keys verkürzt Folgeverbindungen auf einen einseitigen Round-Trip. SPIRE rotiert SVIDs mit einer Standard-TTL von einer Stunde; innerhalb dieser Periode können dieselben Peers Verbindungen ohne erneuten vollständigen Handshake aufnehmen [38]. Naors empirischer Vergleich von Service-Mesh-Implementierungen zeigt, dass mTLS-Aktivierung die P99-Latenz messbar, aber beherrschbar erhöht [51].

JWT-Verifikation: Lokale Signaturprüfung (RS256, ES256) liegt bei aktueller Server-Hardware im Sub-Millisekunden-Bereich. Das Caching von Validierungsergebnissen für die Restlaufzeit eines Tokens eliminiert redundante kryptografische Operationen bei Dauerverbindungen. Introspection-basierte Validierung – für Revokationsszenarien erforderlich – kostet einen zusätzlichen HTTP-Round-Trip, der durch Co-Location des OPA-Sidecars auf unter 1 ms reduzierbar ist [37].

Service-Mesh-Architektur: Connors (2024) vergleicht Istio Ambient Mode und Cilium und stellt fest, dass der Sidecarless-Ambient-Ansatz den Speicherbedarf pro Workload gegenüber der klassischen Sidecar-Variante erheblich senkt, bei vergleichbarem Sicherheitsniveau [33]. eBPF-basierte Implementierungen verlagern Paketverarbeitung in den Kernel-Raum und vermeiden Kontext-Switches zwischen User- und Kernel-Space [50], [49].

Encryption at Rest: AES-256-GCM mit AES-NI-Beschleunigung verursacht bei spaltenverschlüsselten Parquet-Lesezugriffen einen Overhead im einstelligen Prozentbereich [67], [70]. KEK-Operationen am KMS fallen ausschließlich bei DEK-Ladevorgängen und Rotationen an, nicht auf dem kritischen Lesepfad regulärer Analytics-Abfragen [67].

D. Qualitative Evaluation gegen Schutzziele

Tabelle 1 setzt die in Abschnitt II.B definierten Bedrohungen und Schutzziele den vorgestellten Mechanismen gegenüber.

Tabelle 1: Qualitative Evaluation: Bedrohungen und Schutzziele gegen architekturelle Mechanismen.

Vier Restrisiken verbleiben außerhalb der Abdeckung. Erstens setzt das SPIRE-Bootstrapping einen vertrauenswürdigen Attestationsmechanismus voraus; die Cloud-Provider-API selbst ist kompromittierbar [32]. Zweitens entsteht Policy Drift in OPA, wenn CI-seitige Konformitätstests für Policy-Änderungen nicht vollständig erzwungen werden [63]. Drittens hebelt Schreibzugriff auf die OPA-Bundle-API oder die SPIRE-Admin-API die Sicherheitsgarantien der gesamten Plattform aus; die Control Plane ist damit das hochwertigste Angriffsziel [4]. Viertens sind Supply-Chain-Angriffe auf CNCF-Projekte durch SBOM und signierte Image-Builds mitigierbar, aber nicht vollständig ausschließbar [13].

VIII. Integration und Auswirkungen auf benachbarte Systeme

A. Anforderungen an die Netzwerkinfrastruktur und das Skalierungsteam

Die Zero-Trust-Architektur stellt konkrete Anforderungen an die darunterliegende Netzwerkinfrastruktur. Jeder Service-Hop addiert einen mTLS-Handshake und, sofern keine gecachten OPA-Entscheidungen vorliegen, eine Policy-Abfrage. Damit das kumulierte Latenzbudget innerhalb akzeptabler Grenzen bleibt, benötigt die Plattform niedrige Round-Trip-Zeiten zwischen Services, ausreichend Bandbreite an den Netzwerksegmentgrenzen und Hardware-Beschleunigung für AES sowie asymmetrische Kryptografie auf den Worker Nodes [51], [33]. Sidecarless-Implementierungen auf eBPF-Basis verringern den ressourcenbedingten Overhead gegenüber klassischen Sidecar-Deployments, lassen den netzwerkbedingten Anteil aber weitgehend unverändert [33], [50]. Cloud-native Umgebungen setzen zunehmend Dual-Stack-Betrieb voraus; SPIFFE-SVIDs verwenden URI-basierte Identifikatoren der Form spiffe://trust-domain/path und sind damit IP-adressraumunabhängig, erfordern aber explizite Dual-Stack-Qualifizierung von Netzwerkpolicies, WAF-Regelwerken und Load-Balancer-Konfigurationen [23].

Die Control Plane fügt dem Betrieb drei hochverfügbar zu betreibende Services hinzu: SPIRE, OPA und HashiCorp Vault. Fällt einer dieser Services aus, werden neue Verbindungen im Fail-Secure-Modus abgewiesen; bestehende Verbindungen mit validen SVIDs laufen weiter, jedes Deployment, das frische Credentials benötigt, kommt jedoch zum Stillstand [6], [38]. In einer Multi-Cloud-Umgebung nach Uber-Vorbild erfordert das je Region eine eigene Hochverfügbarkeitskonfiguration und koordinierte Trust-Bundle-Rotation über Cloud-Anbietergrenzen hinweg; Trust-Bundle-Erneuerung über mehrere Trust Domains ist in der Praxis eine der operativ aufwändigsten Aufgaben bei der SPIRE-Einführung [31]. Ein dediziertes Plattform-SRE-Team mit eigenem On-Call, Runbooks und von der Data Plane entkoppelten Deployment-Zyklen ist strukturell zwingend erforderlich [31], [3].

B. Einflüsse auf Data Engineering und Storage-Pipelines

Feldbasierte Spaltenverschlüsselung nach dem DEK/KEK-Modell (vgl. Abschnitt VI.E) hat direkte Folgen für Analytics-Abfragen. Query-Engines können Prädikate auf verschlüsselten Spalten nicht an die Speicherschicht delegieren, weil der Speicher-Layer keine Entschlüsselungskapazität besitzt; betroffene Zeilen müssen zunächst vollständig geladen und entschlüsselt werden, bevor ein Filter greift [67]. Uber begegnet dem durch selektive Verschlüsselung bei Apache Parquet: Nur regulierungspflichtige Felder werden per DEK gesichert, analytisch relevante, aber nicht-sensible Spalten verbleiben im Klartext und erlauben volle Predicate-Pushdown-Optimierung [67]. Der DEK-Abruf beim Jobstart via KMS-API ist einmalig pro Analytics-Job und fällt damit nicht auf dem kritischen Query-Pfad an.

Format-erhaltende Verschlüsselung (Format-Preserving Encryption, FPE) bietet einen Kompromiss für Downstream-Systeme mit unveränderlichem Schema: FPE bildet Klartexte auf Chiffretexte gleichen Formats ab, sodass eine Kontonummer nach der Verschlüsselung numerisch und gleich lang bleibt, und erlaubt schemaabhängigen Systemen die Verarbeitung ohne vollständige Entschlüsselung [58]. Tokenisierung ersetzt Feldwerte durch opake Token, die nur über einen zentralen Token-Auflösungsservice für autorisierte Entitäten aufgelöst werden können; Aggregationen und Joins über tokenisierte Felder sind semantisch eingeschränkt [20]. Kafka-basierte Streaming-Pipelines sind betroffen, wenn Consumer-Prozesse verschlüsselte Payloads verarbeiten: Sie benötigen DEK-Zugriff über die Vault-API und müssen Token-Auflösung in ihre Verarbeitungslogik integrieren; die Schema Registry sichert strukturelle Konsistenz, ersetzt aber keine Feldzugriffskontrollen auf Anwendungsebene [40].

C. Developer Experience (DevEx) und operative Umsetzung

Ohne Plattform-Abstraktionen ist jedes Entwicklungsteam gefordert, für jeden neuen Microservice dieselbe Infrastrukturlogik zu implementieren: SVID-Beschaffung, mTLS-Verbindungsaufbau, OAuth-2.0-Token-Exchange, Vault-Secret-Abruf und OPA-Anbindung. In einer Landschaft mit mehreren tausend Services führt das zu unterschiedlichen Implementierungen mit unterschiedlichen Fehlerklassen und erhöhtem Prüfaufwand [4], [31]. Systematische Reviews benennen operative Komplexität als eine der zentralen Adoptionshürden für Zero-Trust-Architekturen [7], [13].

“Goldene Pfade” (Golden Paths) über ein Internal Developer Platform (IDP) sind der etablierte Lösungsansatz: vorstrukturierte Service-Templates betten SPIRE-Agent, OPA-Sidecar und Vault-Initialisierung vorkonfiguriert ein, sodass ein neuer Service ZTA-konform startet, ohne dass das Entwicklungsteam Infrastrukturdetails kennen muss [71], [72]. Spotify verfolgt dieses Konzept unter dem Namen Golden Path, Netflix unter dem Begriff Paved Road [71]. Sprachenspezifische SDK-Bibliotheken kapseln darüber hinaus mTLS-Verbindungsaufbau und Token-Exchange hinter einfachen API-Aufrufen, sodass die Anwendungslogik frei von kryptografischen und Protokolldetails bleibt [2].

Lokale Entwicklungsumgebungen können die Control Plane selten vollständig replizieren. Gängige Abhilfe ist eine abgestufte Umgebungsstrategie: Integrationstests nutzen leichtgewichtige Mock-Implementierungen von SPIRE und OPA, lokale Entwicklungsmodi deaktivieren mTLS-Anforderungen kontrolliert. Uber hat bei der SPIFFE/SPIRE-Einführung auf inkrementellen Rollout gesetzt, bei dem Sicherheitskontrollen zunächst im Shadow Mode liefen, sodass Teams Compliance-Lücken schließen konnten, ohne Produktionsstörungen zu riskieren [38]. Dieser Ansatz lässt sich direkt auf eine strukturierte Einführungsstrategie für weitere ZTA-Komponenten übertragen [7].

IX. Ausblick

A. Evolution zu vollständig passwortlosen Systemen (Secretless Architectures)

Die SPIFFE/SPIRE-Einführung reduziert langlebige Credentials auf den initialen Bootstrapping-Schritt: Beim ersten Kontakt zwischen SPIRE-Agent und Server muss ein statischer Join Token oder ein Cloud-Provider-Attestor vorliegen [32]. Workload Identity Federation (WIF) beseitigt auch diese verbleibende Abhängigkeit. Externe Workloads – etwa CI/CD-Pipelines – präsentieren einem Cloud-Token-Service einen kurzlebigen OIDC-Token ihres nativen Identity Providers; der Token-Service stellt daraufhin cloud-spezifische Zugangsdaten aus, ohne dass vorab ein statischer Credential in einem Secret Store hinterlegt werden muss [73], [74].

Kanoon (2026) dokumentiert, dass SPIRE-Einführungen in der Praxis an Interoperabilitätslücken für SaaS-Integrationen und CI/CD-Pipelines scheitern können [31]; WIF schließt diesen Bereich für Cloud-native Umgebungen. Rajendran et al. zeigen, dass Identity Federation über Systemgrenzen hinweg der Richtung entspricht, in der Zero-Trust-Architekturen konvergieren [14]. Für die nutzerorientierte Seite der Authentifizierung bildet Passkey-Technologie das Pendant: FIDO2-basierte Passkeys ersetzen Passwörter durch geräteseitig gespeicherte asymmetrische Schlüsselpaare, die phishing-resistent sind und ohne serverseitige Credential-Speicherung auskommen [75].

B. Agentenlose Netzwerküberwachung und Bedrohungserkennung mittels eBPF

Das Sidecar-Muster injiziert pro Pod einen Envoy-Proxy; der damit verbundene Speicher- und CPU-Overhead skaliert direkt mit der Workload-Anzahl. eBPF-Programme laufen im Kernel-Space und ermöglichen Enforcement auf Packet-Ebene sowie Observability auf Syscall-Ebene, ohne einen eigenen Prozess je Workload zu benötigen [50], [49].

Tetragon, ein Subprojekt von Cilium, erweitert diesen Ansatz auf sicherheitsrelevante Kernel-Ereignisse: Hooks blockieren unzulässige Syscalls und senden Alerts in Echtzeit, sodass die Erkennungs-Reaktions-Zeitspanne ohne Containermodifikation sinkt [33], [49]. Der Kontext-Wechsel zwischen User-Space-Proxy und Kernel entfällt; Connors (2024) bestätigt empirisch, dass der Sidecarless-Ansatz den Speicherbedarf pro Workload gegenüber der klassischen Sidecar-Variante erheblich reduziert [33]. Ein offener Punkt bleibt die Portabilität: eBPF-Programme setzen mindestens Linux 5.8 voraus, was bei heterogenen Node-Flotten (etwa ältere GPU-Nodes in Analyse-Clustern) zu Inkompatibilitäten führen kann [49].

C. Post-Quantum-Kryptografie

Staatliche Akteure sammeln bereits heute verschlüsselte TLS-Verbindungen mit dem Ziel, diese rückwirkend zu entschlüsseln, sobald fehlertolerantere Quantenrechner verfügbar sind (Harvest Now, Decrypt Later). Für SVID-gesicherte mTLS-Verbindungen, die auf ECDSA P-256 aufbauen, und für JWT-Signaturen mit RS256 oder ES256 ist die Migration auf Post-Quantum-Algorithmen strukturell notwendig.

NIST hat 2024 drei PQC-Standards finalisiert: ML-KEM (FIPS 203) für den Schlüsselaustausch, ML-DSA (FIPS 204) als primären Signaturalgorithmus sowie SLH-DSA (FIPS 205) als Hash-basierten Fallback [76], [77], [78]. TLS 1.3 unterstützt hybride Schlüsselaustausch-Verfahren wie X25519Kyber768, sodass ein phasenweiser Migrationspfad möglich ist: Im hybriden Modus bleibt Rückwärtskompatibilität erhalten, während der Schlüsseltausch quantensicher wird. Für SPIRE bedeutet die vollständige Migration, die Root-CA und alle Intermediate-CAs auf ML-DSA umzustellen und Trust-Bundle-Rotation über alle Trust Domains zu koordinieren. Ein Cryptographic Bill of Materials (CBOM), das alle aktiven Algorithmen, Schlüssellängen und Zertifikate der Plattform inventarisiert, ist Voraussetzung jeder priorisierten Migrationsreihenfolge [68].

D. KI-gestützte Bedrohungserkennung

Regelbasierte SIEM-Korrelation erkennt bekannte Angriffsmuster, schlägt aber bei neuartigen Angriffspfaden ohne bekannte Signatur fehl. ML-basierte Anomalieerkennung bildet service-spezifische Baselines aus API-Aufrufmustern, Token-Ausstellungsraten und Service-Traffic und erkennt Abweichungen, die statische Schwellenwerte verfehlen würden [69], [37]. Erklärbare Modelle, die ein Ranking der ausschlaggebenden Features liefern, sind dabei für operatives Alerting relevant: Operatoren müssen Eskalationsentscheidungen nachvollziehbar begründen können, was bei reinen Black-Box-Modellen nicht möglich ist [69].

Die Gegenrichtung wiegt mindestens ebenso schwer. Xu et al. zeigen, dass generative KI Zero-Trust-Annahmen auf mehreren Ebenen unterhöhlt: Synthetische Identitäten bestehen Verifikationsschritte, manipulierte Telemetrie verschiebt Modell-Baselines, und KI-generierte Angriffsvektoren reduzieren die Detection-Latenz auf Angreiferseite [79]. Adversarial-ML-Angriffe gegen den Anomalie-Detektor selbst (etwa gezielt konstruierter Verkehr, der die Baseline in Richtung des Angriffsverhaltens verschiebt) erfordern kontinuierliches Retraining auf aktuellen Daten sowie eine externe Modell-Integritätsprüfung. Werden autonome KI-Agenten in die Plattform integriert, entstehen zusätzliche Angriffsflächen: De Witt (2025) identifiziert Prompt-Injection und unkontrollierte Toolchain-Zugriffe als offene Sicherheitsprobleme in Multi-Agent-Systemen [80].

X. Fazit

Diese Arbeit untersucht, welche Zero-Trust-Mechanismen für ein ULS-System nach dem Vorbild der Uber-Plattform geeignet sind und welche Trade-offs bezüglich Latenz, Komplexität und Betriebsaufwand entstehen.

Technisch lässt sich die Forschungsfrage beantworten. Verifizierbare Workload-Identität durch SPIFFE/SPIRE eliminiert statische Credentials und ermöglicht automatisches mTLS über Trust-Domain-Grenzen hinweg. Das API-Gateway als externer Policy Enforcement Point, kombiniert mit einem Service Mesh für East-West-Encryption und einem gemeinsamen OPA-PDP, ergibt ein konsistentes Schichtmodell, das laterale Bewegung nach einer initialen Kompromittierung strukturell eingrenzt. Policy as Code mit Rego löst die Rollenexplosion, die RBAC in tausenden Microservices verursacht. Spaltenbasierte Envelope-Encryption schützt regulierungspflichtige Felder in Data Lakes, ohne Analytics-Abfragen vollständig zu unterbrechen. Der kryptografische Overhead dieser Mechanismen ist mit Hardware-Beschleunigung und Token-Caching beherrschbar.

Der strukturell schwerere Trade-off ist operativer Art. Control-Plane-Services müssen hochverfügbar betrieben, über Cloud-Anbietergrenzen koordiniert und gegen kompromittierte Workloads mit plattformweitem Schreibzugriff isoliert werden. Ohne Plattform-Abstraktionen und Golden Paths erzeugt die parallele Entwicklung tausender Microservices divergente Sicherheitsimplementierungen mit unterschiedlichen Fehlerklassen. Systematische Reviews bestätigen, dass operative Komplexität und fehlende Tool-Reife die zentralen Adoptionshürden für ZTA sind, nicht Latenz.

Das Vorgehen hat drei Grenzen. Die Trade-off-Bewertung bleibt qualitativ, weil keine Labormessungen die Latenzabschätzungen validieren. Alle Erkenntnisse beruhen auf öffentlich zugänglichen Quellen; interne Plattformdaten stehen nicht zur Verfügung. Einzelne Designentscheidungen sind aus publizierten Prinzipien extrapoliert, nicht aus vollständigen Architekturdokumenten abgeleitet.

Auf technischer Seite stehen Post-Quantum-Kryptografie-Migration und eBPF-gestützte Sidecarless-Mesh-Implementierungen als nächste konkrete Schritte an. Workload Identity Federation schließt verbliebene Lücken bei CI/CD-Pipelines und SaaS-Integrationen. Ob Zero Trust in ULS-Systemen dauerhaft umsetzbar bleibt, hängt davon ab, ob Plattformteams die operative Komplexität durch Automatisierung und entwicklerfreundliche Abstraktionen beherrschbar halten.

Literaturverzeichnis

[1] L. Northrop et al., “Ultra-Large-Scale Systems: The Software Challenge of the Future,” Jun. 2006.

[2] “Building Uber’s Multi-Cloud Secrets Management Platform to Enhance Security,” Uber. Accessed: May 13, 2026. [Online]. Available: https://www.uber.com/us/en/blog/building-ubers-multi-cloud-secrets-management-platform/

[3] M. Bansal et al., “Uber’s Failover Architecture: Reconciling Reliability and Efficiency in Hyperscale Microservice Infrastructure,” arXiv:2603.07345, Mar. 2026, doi: 10.48550/arXiv.2603.07345.

[4] P. Haindl, P. Kochberger, and M. Sveggen, “A Systematic Literature Review of Inter-Service Security Threats and Mitigation Strategies in Microservice Architectures,” IEEE Access, vol. 12, pp. 90252–90286, 2024, doi: 10.1109/access.2024.3406500.

[5] M. A. Olivero, A. Bertolino, F. J. Dominguez-Mayo, M. J. Escalona, and I. Matteucci, “A systematic mapping study on security for systems of systems,” International Journal of Information Security, vol. 23, no. 2, pp. 787–817, Apr. 2024, doi: 10.1007/s10207-023-00757-0.

[6] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero Trust Architecture,” National Institute of Standards and Technology, NIST SP 800-207, Aug. 2020, doi: 10.6028/NIST.SP.800-207.

[7] M. L. Gambo and A. Almulhem, “Zero Trust Architecture: A Systematic Literature Review,” Journal of Network and Systems Management, vol. 34, no. 1, p. 25, Jan. 2026, doi: 10.1007/s10922-025-09998-x.

[8] Y. He, D. Huang, L. Chen, Y. Ni, and X. Ma, “A Survey on Zero Trust Architecture: Challenges and Future Trends,” Wireless Communications and Mobile Computing, vol. 2022, no. 1, p. 6476274, 2022, doi: 10.1155/2022/6476274.

[9] “2022 Uber Breach: Social Engineering and the Lapsus$ Gang.” Accessed: May 13, 2026. [Online]. Available: https://ironscales.com/blog/ransomware-gangs-lapsus

[10] J. Salmon, “The Uber Breach Case Study: Cybersecurity Lessons Learned,” HumanFirewall, Nov. 2023.

[11] “What Caused the Uber Data Breach in 2022? | UpGuard.” Accessed: May 13, 2026. [Online]. Available: https://www.upguard.com/blog/what-caused-the-uber-data-breach

[12] “Angriff auf die Lieferkette von SolarWinds,” Fortinet. Accessed: May 16, 2026. [Online]. Available: https://www.fortinet.com/de/resources/cyberglossary/solarwinds-cyber-attack.html

[13] S. Mushtaq, M. Mohsin, and M. M. Mushtaq, “A Systematic Literature Review on the Implementation and Challenges of Zero Trust Architecture Across Domains,” Sensors (Basel, Switzerland), vol. 25, 2025, doi: 10.3390/s25196118.

[14] R. N. Rajendran, S. K. Anumula, D. K. Rai, and S. Agrawal, “Zero Trust Security Model Implementation in Microservices Architectures Using Identity Federation,” arXiv:2511.04925, Nov. 2025, doi: 10.48550/arXiv.2511.04925.

[15] S. Hissam, M. Klein, G. Moreno, L. Northrop, and L. Wrage, “Ultra-Large-Scale (ULS) Systems: Socio-Adaptive Systems.”

[16] “(PDF) Ultra-large-scale Systems,” in ResearchGate, doi: 10.1145/1176617.1176645.

[17] A. Sekar, “The Future of Large-Scale Distributed Systems: Trends, Challenges, and Opportunities,” International Journal of Scientific Research in Computer Science, Engineering and Information Technology, 2025, doi: 10.32628/cseit25112792.

[18] “Understanding MITRE ATT&CK Cloud Matrix for Security,” Safe Security. Accessed: May 13, 2026.

[19] “What Is MITRE ATT&CK Framework?,” Palo Alto Networks. Accessed: May 13, 2026. [Online]. Available: https://www.paloaltonetworks.com/cyberpedia/what-is-mitre-attack

[20] W. Hashim and N. A.-H. K. Hussein, “Securing Cloud Computing Environments: An Analysis of Multi-Tenancy Vulnerabilities and Countermeasures,” SHIFRA, 2024, doi: 10.70470/shifra/2024/002.

[21] R. A. Sunarjo et al., “Addressing Cybersecurity Risks in Multi Cloud Environments for Digital Transformation,” in 2025 4th International Conference on Creative Communication and Innovative Technology (ICCIT), 2025, pp. 1–6, doi: 10.1109/iccit65724.2025.11167220.

[22] R. Ward and B. Beyer, “A New Approach to Enterprise Security.”

[23] R. Chandramouli and Z. Butcher, “A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments,” National Institute of Standards and Technology, NIST Special Publication (SP) 800-207A, Sep. 2023, doi: 10.6028/NIST.SP.800-207A.

[24] D. Hardt, “The OAuth 2.0 Authorization Framework,” Internet Engineering Task Force, RFC 6749, Oct. 2012, doi: 10.17487/RFC6749.

[25] M. B. Jones, J. Bradley, and N. Sakimura, “JSON Web Token (JWT),” Internet Engineering Task Force, RFC 7519, May 2015, doi: 10.17487/RFC7519.

[26] M. Jones, B. Campbell, and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” Internet Engineering Task Force, RFC 7523, May 2015, doi: 10.17487/RFC7523.

[27] M. B. Jones, A. Nadalin, B. Campbell, J. Bradley, and C. Mortimore, “OAuth 2.0 Token Exchange,” Internet Engineering Task Force, RFC 8693, Jan. 2020, doi: 10.17487/RFC8693.

[28] D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. B. Jones, and D. Waite, “OAuth 2.0 Demonstrating Proof of Possession (DPoP),” Internet Engineering Task Force, RFC 9449, Sep. 2023, doi: 10.17487/RFC9449.

[29] P. Saint-Andre and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” Internet Engineering Task Force, RFC 6125, Mar. 2011, doi: 10.17487/rfc6125.

[30] Y. Sheffer, P. Saint-Andre, and T. Fossati, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),” Internet Engineering Task Force, RFC 9325, Nov. 2022, doi: 10.17487/RFC9325.

[31] A. Kanoon, “Everyone Wants SPIFFE. Almost No One Can Afford to Build It Right,” Aembit, May 2026. Accessed: May 13, 2026. [Online]. Available: https://aembit.io/blog/everyone-wants-spiffe-almost-no-one-can-afford-to-build-it-right/

[32] “Workload Identity Bootstrapping: A Comprehensive Guide,” Non-Human Identity Articles. Accessed: May 13, 2026. [Online]. Available: https://nhimg.org/nhi-101/workload-identity-bootstrapping

[33] M. Connors, “Scaling in the Clouds: Istio Ambient vs. Cilium,” Istio. Accessed: May 13, 2026. [Online]. Available: https://istio.io/latest/blog/2024/ambient-vs-cilium/

[34] C. Holigi, “Security Architecture Patterns for High-Volume Distributed Enterprise Platforms,” Computer Fraud and Security, no. 2026.

[35] “Attribute-Based Access Control at Uber,” Uber. Accessed: May 13, 2026. [Online]. Available: https://www.uber.com/us/en/blog/attribute-based-access-control-at-uber/

[36] “Application Layer Transport Security,” Google Cloud Documentation. Accessed: May 11, 2026. [Online]. Available: https://docs.cloud.google.com/docs/security/encryption-in-transit/application-layer-transport-security

[37] J. Viswanathan, D. K. N, and S. U. Kumar, “Zero Trust Security for Web Applications in Microservice-Based Environments,” in 2024 First International Conference on Data, Computation and Communication (ICDCC), Nov. 2024, pp. 488–494, doi: 10.1109/ICDCC62744.2024.10960955.

[38] “Our Journey Adopting SPIFFE/SPIRE at Scale,” Uber. Accessed: May 13, 2026. [Online]. Available: https://www.uber.com/us/en/blog/our-journey-adopting-spiffe-spire/

[39] “The Architecture of Uber’s API Gateway,” Uber. Accessed: May 11, 2026. [Online]. Available: https://www.uber.com/de/en/blog/architecture-api-gateway/

[40] “Securing Kafka Infrastructure at Uber,” Uber. Accessed: May 13, 2026. [Online]. Available: https://www.uber.com/us/en/blog/securing-kafka-infrastructure-at-uber/

[41] Netflix Technology Blog, “Edge Authentication and Token-Agnostic Identity Propagation,” Medium, Feb. 2021. Accessed: May 11, 2026. [Online]. Available: https://netflixtechblog.com/edge-authentication-and-token-agnostic-identity-propagation-514e47e0b602

[42] C. K. Rudrabhatla, “Security Design Patterns in Distributed Microservice Architecture,” arXiv.org, Aug. 2020. Accessed: May 13, 2026. [Online]. Available: https://arxiv.org/abs/2008.03395v1

[43] A. Singh and B. B. Gupta, “Distributed Denial-of-Service (DDoS) Attacks and Defense Mechanisms in Various Web-Enabled Computing Platforms: Issues, Challenges, and Future Research Directions,” Int. J. Semantic Web Inf. Syst., vol. 18, pp. 1–43, 2022, doi: 10.4018/ijswis.297143.

[44] “Coreruleset/Coreruleset.” CRS Project, May 2026.

[45] “Envoy Proxy – Home.” Accessed: May 16, 2026. [Online]. Available: https://www.envoyproxy.io/

[46] “Emissary-Ingress/Emissary.” Emissary Ingress, May 2026.

[47] “Most Trusted Open Source API Gateway | Kong Gateway,” Kong Inc., Jul. 2023. Accessed: May 16, 2026. [Online]. Available: https://konghq.com/products/kong-gateway

[48] R. Xu, W. Jin, and D. Kim, “Microservice Security Agent Based On API Gateway in Edge Computing,” Sensors, vol. 19, no. 22, p. 4905, Jan. 2019, doi: 10.3390/s19224905.

[49] “eBPF Ecosystem Progress in 2024–2025: A Technical Deep Dive – Eunomia.” Accessed: May 13, 2026. [Online]. Available: https://eunomia.dev/blog/2025/02/12/ebpf-ecosystem-progress-in-20242025-a-technical-deep-dive/

[50] M. Abranches, O. Michel, E. Keller, and S. Schmid, “Efficient Network Monitoring Applications in the Kernel with eBPF and XDP,” in 2021 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), Nov. 2021, pp. 28–34, doi: 10.1109/NFV-SDN53031.2021.9665095.

[51] Y. Naor, “Performance Comparison of Service Mesh Frameworks: The MTLS Test Case.”

[52] “Kafka Security Overview.” Accessed: May 13, 2026. [Online]. Available: https://kafka.apache.org/42/security/security-overview/

[53] “Sicherer Data Lake – AWS Lake Formation – AWS,” Amazon Web Services, Inc. Accessed: May 16, 2026. [Online]. Available: https://aws.amazon.com/de/lake-formation/

[54] “Unity Catalog,” Databricks. Accessed: May 16, 2026. [Online]. Available: https://www.databricks.com/product/unity-catalog

[55] S. Yadav and S. Abidin, “Enhancing Security in Multi-Tenant Cloud Environments: Threat Detection, Prevention, and Data Breach Mitigation,” Journal of Information Systems Engineering and Management, 2025, doi: 10.52783/jisem.v10i22s.3472.

[56] A. Pandit and R. Pandit, “Side-Channel Attacks in Multi-Tenant Cloud Environments: Prevention & Mitigation,” International Journal of Innovations in Science Engineering And Management, 2025, doi: 10.69968/ijisem.2025v4i293-105.

[57] M. Kosinski and J. Holdsworth, “What Is Tokenization? | IBM,” Jan. 2025. Accessed: May 16, 2026. [Online]. Available: https://www.ibm.com/think/topics/tokenization

[58] M. Dworkin, “Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption,” National Institute of Standards and Technology, NIST Special Publication (SP) 800-38G, Aug. 2016, doi: 10.6028/NIST.SP.800-38G.

[59] “Disaster Recovery for Multi-Region Kafka at Uber,” Uber. Accessed: May 11, 2026. [Online]. Available: https://www.uber.com/de/en/blog/kafka/

[60] “Microservices Pattern: Pattern: Transactional Outbox,” microservices.io. Accessed: May 16, 2026. [Online]. Available: http://microservices.io/patterns/data/transactional-outbox.html

[61] “Confluentinc/Schema-Registry.” Confluent Inc., May 2026.

[62] “Schema Registry for Confluent Platform | Confluent Documentation.” Accessed: May 16, 2026. [Online]. Available: https://docs.confluent.io/platform/current/schema-registry/index.html

[63] W. Zi, S. Avinash, and A. Zakir, “Adding Determinism and Safety to Uber IAM Policy Changes,” Sep. 2025.

[64] M. McGloin and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” Internet Engineering Task Force, RFC 6819, Jan. 2013, doi: 10.17487/rfc6819.

[65] “RFC 8705 Deep Dive: Turning Access Tokens into ‘Unstealable Tokens’ with mTLS,” DEV Community, Feb. 2026. Accessed: May 13, 2026. [Online]. Available: https://dev.to/kanywst/rfc-8705-deep-dive-turning-access-tokens-into-unstealable-tokens-with-mtls-406

[66] R. Krishnan, A. Prasad, D. Lopez, and S. Addepalli, “TLS-Session-Bound Access Tokens for OAuth 2.0,” Internet Engineering Task Force, Internet-Draft draft-mw-oauth-tls-session-bound-tokens-04, Apr. 2026.

[67] “One Stone, Three Birds: Finer-Grained Encryption @ Apache Parquet,” Uber. Accessed: May 13, 2026. [Online]. Available: https://www.uber.com/us/en/blog/one-stone-three-birds-finer-grained-encryption-apache-parquet/

[68] Themefisher, “CBOM (Cryptographic Bill of Materials): Why Every Enterprise Needs One.” Accessed: May 13, 2026. [Online]. Available: https://www.qcecuring.com/blog/cbom-cryptographic-bill-of-materials-guide

[69] S. Islam, N. Basheer, S. Papastergiou, M. Ciampi, and S. Silvestri, “Intelligent dynamic cybersecurity risk management framework with explainability and interpretability of AI models for enhancing security and resilience of digital infrastructure,” Journal of Reliable Intelligent Environments, vol. 11, 2025, doi: 10.1007/s40860-025-00253-3.

[70] “Parquet Modular Encryption,” Parquet. Accessed: May 16, 2026. [Online]. Available: https://parquet.apache.org/docs/file-format/data-pages/encryption/

[71] “Designing Golden Paths.” Accessed: May 13, 2026. [Online]. Available: https://www.redhat.com/en/blog/designing-golden-paths

[72] “5 Engineering Platform Strategies from Top Teams.” Accessed: May 13, 2026.

[73] “Workload Identity Federation – Microsoft Entra Workload ID.” Accessed: May 13, 2026. [Online]. Available: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation

[74] “Workload Identity-Föderation | Identity and Access Management (IAM),” Google Cloud Documentation. Accessed: May 13, 2026. [Online]. Available: https://docs.cloud.google.com/iam/docs/workload-identity-federation?hl=de

[75] L. Tran, B. Zhang, R. Pawanja, and R. H. Khokhar, “The Passwordless Authentication with Passkey Technology from an Implementation Perspective,” arXiv:2508.11928, Aug. 2025, doi: 10.48550/arXiv.2508.11928.

[76] National Institute of Standards and Technology, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” U.S. Department of Commerce, Federal Information Processing Standard (FIPS) 203, Aug. 2024, doi: 10.6028/NIST.FIPS.203.

[77] National Institute of Standards and Technology, “Module-Lattice-Based Digital Signature Standard,” U.S. Department of Commerce, Federal Information Processing Standard (FIPS) 204, Aug. 2024, doi: 10.6028/NIST.FIPS.204.

[78] National Institute of Standards and Technology, “Stateless Hash-Based Digital Signature Standard,” U.S. Department of Commerce, Federal Information Processing Standard (FIPS) 205, Aug. 2024, doi: 10.6028/NIST.FIPS.205.

[79] D. Xu, I. Gondal, X. Yi, T. Susnjak, P. Watters, and T. R. McIntosh, “The Erosion of Cybersecurity Zero-Trust Principles Through Generative AI: A Survey on the Challenges and Future Directions,” Journal of Cybersecurity and Privacy, vol. 5, no. 4, p. 87, Dec. 2025, doi: 10.3390/jcp5040087.

[80] C. S. de Witt, “Open Challenges in Multi-Agent Security: Towards Secure Systems of Interacting AI Agents,” ArXiv, vol. abs/2505.02077, 2025, doi: 10.48550/arxiv.2505.02077.