Untertitel: Warum „intern“ keine Policy ist – und jede Anfrage Identität, Zweck und Berechtigung beweisen muss.
Fachverfahren rufen Daten bei anderen Diensten ab. Weil der Aufruf intern wirkt, genügt oft ein Netzwerkpfad oder ein alter API-Key. Monate später weiß niemand mehr: Wer hat was, wofür und auf welcher Grundlage geholt?
Zwei Extreme: Perimeter-Vertrauen (intern = sicher, Super-Keys) oder starre Sperren ohne Pfade (Workarounds, Schatten-APIs). Beides zerstört Vertrauen.
Die These in einem Satz
Zero-Trust API Gateway heißt: nie blind vertrauen – jede Anfrage beweist Identität, Zweck und Berechtigung; das Gateway erzwingt Least Privilege und macht Zugriffe auditierbar.
Nicht: „Niemand darf je zugreifen.“ Sondern: Prüfung pro Request – stark authentifizieren, eng autorisieren, protokollieren.
Zwei schlechte Extreme
Ohne Zero-Trust-Denken steckt Policy im Netz statt in der Anfrage – oder Sicherheit wird nur als Blockade gedacht. Vertrauen entsteht nicht durch dicke Außenmauern allein – sondern wenn Zugriffe nachweisbar, zweckgebunden und widerrufbar sind.
Was es nicht ist
Keine Magie mit null Risiko. Kein Verbot rechtmäßiger Behörden-Datenaustausche. Kein Vendor-Sticker als Architektur. Sondern kontinuierliche Prüfung an der Schnittstelle mit Governance und klaren Freigabepfaden.
Drei Säulen
1. Identität – wer ruft an?
Starke Identitäten für Nutzer und Workloads. Keine langlebigen Shared Secrets als Normalfall. Tokens und Zertifikate befristet und widerrufbar.
2. Autorisierung & Policy – was darf er?
Least Privilege: nur der Scope des Vorgangs. Deny-by-default am Gateway. Kontext wo sinnvoll – Zeit, Risiko, Zweck.
3. Observability & Governance – was ist passiert?
Audit-Log mit Wer, Was, Wann, Warum (datenschutzkonform). Anomalien und Widerruf. Policy erklärbar – nicht Blackbox. Zero-Trust ersetzt keine Haftung.
Der kulturelle Kern
| Extrem A | Extrem B | Zero-Trust-Mitte |
|---|---|---|
| Intern = vertrauenswürdig | Alles blockieren | Jede Anfrage beweisen |
| Netz = Policy | Kein legitimer Pfad | Policy am Gateway |
| Super-Key | Stillstand | Least Privilege |
| Kein Audit | Blinde Sperre | Protokoll mit Zweck |
Entscheidungsfilter
- Reicht „internes Netz“ als Vertrauensgrund – oder beweist jede Anfrage Identität und Zweck?
- Gibt es Super-Keys / Wildcards – oder scoped, befristete Berechtigungen?
- Wird jeder relevante Zugriff protokolliert und ist widerrufbar?
- Ist Deny-by-default die Regel – und sind legitime Pfade klar freigegeben?
- Kann die Policy erklärt werden (Audit, Aufsicht, Betrieb)?
Kurzformel
Zero-Trust API Gateway heißt: nie blind vertrauen – jede Anfrage beweist Identität, Zweck und Berechtigung; das Gateway erzwingt Least Privilege und macht Zugriffe auditierbar.
Leitlinie: Nie blind vertrauen · Jede Anfrage prüfen · Least Privilege am Tor
Serie System · Systembrief · Essay-Video auf YouTube @systembrief_de (Release laut Kalender 2026-10-30).