Das Prinzip: never trust, always verify

Zero Trust (ZT) ist nach NIST SP 800-207 ein Bündel von Sicherheitsparadigmen, das die Verteidigung von statischen, netzbasierten Perimetern weg verlagert und auf Nutzer, Assets und Ressourcen ausrichtet. Der zentrale Grundsatz: Es gibt keinen impliziten Vertrauensvorschuss, der allein auf dem physischen oder Netzwerkstandard beruht. Eine Anfrage aus dem eigenen Rechenzentrum, also von innerhalb eines klassischen Perimeters, muss dieselben Sicherheitsanforderungen erfüllen wie eine Anfrage aus dem offenen Internet.

NIST formuliert sieben Grundsätze (basic tenets). Die für APIs wichtigsten:

  • Jede Kommunikation wird gesichert, unabhängig vom Netzwerkstandort. Der Standort allein begründet kein Vertrauen; Vertraulichkeit, Integrität und Quellauthentisierung sind immer herzustellen.
  • Zugriff wird pro Sitzung gewährt (per-session), mit den geringstmöglichen Rechten (least privilege). Die Autorisierung für eine Ressource gewährt nicht automatisch Zugriff auf eine andere.
  • Zugriff folgt einer dynamischen Policy, die den beobachtbaren Zustand von Identität, Anwendung und anfragendem Asset einbezieht, ergänzt um Verhaltens- und Umgebungsattribute.

Für APIs ist die Konsequenz direkt: Es genügt nicht, am Eingang einmal zu authentifizieren und danach allem im internen Netz zu trauen. Jeder einzelne API-Aufruf trägt seine Identität mit und wird gegen die Policy geprüft.

AspektNIST SP 800-207CISA Zero Trust Maturity Model v2.0
RolleAbstrakte Architektur und GrundsätzeReifegrad-Rahmen zur Umsetzung
KernstrukturLogische Komponenten PE, PA, PEPFünf Säulen plus drei übergreifende Fähigkeiten
Säulen / KomponentenPE, PA, PEP entlang Control- und Data-PlaneIdentity, Devices, Networks, Applications and Workloads, Data
StufungDrei Umsetzungsvarianten (u. a. Microsegmentierung)Vier Reifegrade: Traditional, Initial, Advanced, Optimal
HerkunftNIST, USA, 2020CISA, USA, ausgerichtet an OMB M-22-09

NIST SP 800-207 und CISA ZTMM im Vergleich

Identität pro Request und Default-Deny

Aus den NIST-Grundsätzen folgt für APIs ein klares Durchsetzungsmuster: Identität pro Request statt Vertrauen pro Netzsegment. Jeder Aufruf führt einen überprüfbaren Identitätsnachweis mit, etwa ein OAuth 2.0-Zugriffstoken (häufig als JWT) oder ein Client-Zertifikat. Die Berechtigung wird bei jeder Anfrage neu ausgewertet, nicht nur beim ersten Login.

Die zweite Konsequenz ist Default-Deny: Was nicht ausdrücklich erlaubt ist, wird abgelehnt. Dieses Prinzip deckt sich mit der OWASP-Empfehlung gegen Broken Function Level Authorization (BFLA, API5:2023): Der Durchsetzungsmechanismus soll standardmäßig jeden Zugriff verweigern und nur explizit gewährte Rollen pro Funktion zulassen (deny all access by default, requiring explicit grants).

Zero Trust ersetzt damit nicht die Autorisierung in der Anwendung, sondern verlangt sie konsequent. Wichtig: Ein gültiges Token beweist nur wer ruft, nicht ob diese Identität gerade auf genau dieses Objekt zugreifen darf. Die objektbezogene Prüfung (gegen BOLA, API1:2023) bleibt Aufgabe des Dienstes und gehört in dessen Geschäftslogik.

Policy Enforcement Point am Gateway: PE, PA, PEP

NIST SP 800-207 zerlegt eine Zero-Trust-Architektur in logische Kernkomponenten, getrennt nach Control Plane und Data Plane:

  • Policy Engine (PE): trifft die eigentliche Zugriffsentscheidung. Sie wertet die Unternehmens-Policy plus externe Signale (z. B. Bedrohungs-Feeds) über einen Trust Algorithm aus und gewährt, verweigert oder widerruft Zugriff.
  • Policy Administrator (PA): baut den Kommunikationspfad zwischen Subjekt und Ressource auf oder ab, erzeugt sitzungsspezifische Tokens und steuert den PEP entsprechend der PE-Entscheidung.
  • Policy Enforcement Point (PEP): aktiviert, überwacht und beendet die Verbindung zwischen Subjekt und Ressource. Er ist die Stelle, an der die Entscheidung tatsächlich durchgesetzt wird.

Für APIs ist das API Gateway der natürliche Ort für den PEP am Nord-Süd-Verkehr: Es terminiert TLS, prüft Authentifizierung und setzt grobgranulare Policies pro Anfrage durch, bevor sie ein Backend erreicht. Entscheidend ist die Arbeitsteilung: Das Gateway als PEP fängt den Perimeter ab, aber die feingranulare, objektbezogene Autorisierung (BOLA) entscheidet weiterhin der Dienst. Ein Gateway-PEP ist notwendig, aber nicht hinreichend, ein Punkt, an dem Zero Trust und das Schichtenmodell der API-Security zusammenfallen.

Microsegmentierung und mTLS zwischen Diensten

NIST nennt die Microsegmentierung als eine der drei Umsetzungsvarianten einer Zero-Trust-Architektur: Einzelne Ressourcen oder kleine Gruppen verwandter Ressourcen liegen hinter einer eigenen Gateway-Sicherheitskomponente, die als PEP wirkt und Zugriff dynamisch pro Anfrage gewährt. Statt eines flachen, vertrauenswürdigen internen Netzes entstehen viele kleine, einzeln kontrollierte Zonen, sodass ein kompromittierter Dienst nicht automatisch lateral auf andere zugreifen kann.

Im Ost-West-Verkehr, also der Kommunikation der Dienste untereinander, wird der Grundsatz jede Kommunikation wird gesichert typischerweise über mTLS (mutual TLS) umgesetzt. Anders als bei einseitigem TLS weisen sich beide Seiten per Zertifikat aus, jeder Dienst erhält so eine kryptografische Workload-Identität. In Service-Mesh-Architekturen (etwa über Sidecar-Proxies) wird mTLS oft transparent für die Anwendung erzwungen.

  • TLS 1.3 (RFC 8446) ist die Transport-Grundlage für verschlüsselte, integritätsgesicherte Verbindungen.
  • OAuth 2.0 Mutual-TLS (RFC 8705) bindet zusätzlich Zugriffstokens an das Client-Zertifikat (certificate-bound access tokens), sodass ein gestohlenes Token ohne den passenden privaten Schlüssel unbrauchbar ist.

So entsteht ein durchgehender Identitätsfaden: vom externen Client über den PEP am Gateway bis zur authentisierten Dienst-zu-Dienst-Verbindung.

CISA Zero Trust Maturity Model: die fünf Säulen

Wo NIST SP 800-207 die abstrakte Architektur beschreibt, liefert das CISA Zero Trust Maturity Model (ZTMM, Version 2.0, ausgerichtet an OMB M-22-09) einen Reifegrad-Rahmen für die schrittweise Umsetzung. Es gliedert sich in fünf Säulen und drei übergreifende Fähigkeiten.

Die fünf Säulen:

  1. Identity (Identität)
  2. Devices (Geräte)
  3. Networks (Netzwerke)
  4. Applications and Workloads (Anwendungen und Workloads), hierunter fallen APIs und ihre Dienste
  5. Data (Daten)

Quer dazu liegen drei übergreifende Fähigkeiten: Visibility and Analytics, Automation and Orchestration und Governance. Jede Säule durchläuft vier Reifegrade: Traditional, Initial, Advanced und Optimal. Damit lässt sich Zero Trust nicht als Alles-oder-nichts, sondern als messbarer Weg behandeln, in dem etwa eine API-Landschaft von statischen, perimeterbasierten Kontrollen hin zu pro-Request-Autorisierung und automatisierter Policy-Durchsetzung reift.

Einordnung und Grenzen

Zero Trust ist ein Architekturprinzip, kein Produkt. NIST betont, dass keine einzelne Komponente eine vollständige ZTA herstellt, sie ergibt sich aus dem Zusammenspiel von PE, PA und PEPs entlang konsequent durchgesetzter Policies. Auch das BSI führt Zero Trust als Empfehlung für Behörden und Unternehmen.

Wichtige Abgrenzungen für die Praxis:

  • Zero Trust ersetzt keine Anwendungslogik. Der PEP am Gateway prüft Identität und grobe Policy; objektbezogene Autorisierung (BOLA) und funktionsbezogene Autorisierung (BFLA) müssen weiterhin im Dienst erzwungen werden.
  • mTLS sichert den Transport und die Workload-Identität, trifft aber keine fachliche Berechtigungsentscheidung über einzelne Datensätze.
  • Reifegrad statt Schalter. Die Umsetzung erfolgt schrittweise entlang der CISA-Säulen, nicht in einem einzigen Migrationsschritt.

NIST nennt zudem eigene Risiken einer ZTA, etwa die Kompromittierung des Entscheidungsprozesses (PE/PA) oder Denial-of-Service gegen den PEP: Wer alle Zugriffe über einen zentralen Durchsetzungspunkt leitet, muss dessen Verfügbarkeit und Integrität besonders absichern.

Quellen

Weiterlesen
DurchsetzungAPI Gateways als Policy Enforcement Point AutorisierungBroken Function Level Authorization IdentitätAPI-Authentifizierung