API-Gateway und Sicherheit: zentrale Regeln, klare Vertrauensgrenzen

Welche Aufgabe gehört an welche Stelle?

Die Aufteilung hängt von Ihrer Architektur ab. Eine frühe Prüfung kann unnötige Arbeit vermeiden, während eine Entscheidung über ein konkretes Objekt dessen aktuellen Kontext braucht.

Ein Gateway kann Autorisierung übernehmen, wenn es den benötigten Kontext zuverlässig besitzt und alternative Wege entsprechend geschützt sind. Es ist daher falsch, ihm grundsätzlich jede Rechteentscheidung abzusprechen. Bei komplexeren Anwendungen werden grobe Regeln am Eingang und genauere Regeln am Dienst jedoch häufig kombiniert. OWASP beschreibt beide Möglichkeiten und ihre Grenzen. OWASP: Microservices Security.

Die Objektberechtigung und Funktionsrechte helfen, die konkrete Entscheidungsgrundlage zu bestimmen. „Token gültig“ und „diese Rechnung gehört zu diesem Nutzer“ sind verschiedene Aussagen.

Den nachgelagerten Dienst vor unbeabsichtigtem Direktzugriff schützen

Wenn der Dienst nur auf das Gateway vertraut, darf ein beliebiger anderer Aufrufer nicht denselben Zugang mit selbst gesetzten Identitätsdaten nutzen. Prüfen Sie deshalb private und öffentliche Adressen, interne Routen, zusätzliche Ports und frühere Deploymentwege aus Ihrem API-Inventar.

Ein typischer Entwurf beschränkt den Netzwerkzugang auf den benötigten Weg und lässt den Dienst den aufrufenden Dienst beziehungsweise Proxy authentifizieren. Dazu kann etwa gegenseitige TLS-Authentifizierung oder ein passendes dienstgebundenes Token dienen. Die Auswahl braucht einen verwalteten Identitäts- und Schlüssellebenszyklus; ein gemeinsamer beliebiger Headerwert reicht nicht.

Manche Dienste sind absichtlich auch direkt erreichbar. Dann müssen auf diesem Weg die erforderlichen Regeln ebenfalls gelten. Entscheidend ist nicht, ob ein Port geschlossen heißt, sondern ob ein unerlaubter Aufruf irgendwo dieselbe Wirkung erreichen kann.

Eine Prüfung der öffentlichen Gatewayantwort zeigt diese internen Wege nicht. Der Beleg entsteht aus Konfiguration und kontrollierten Integrationsfällen mit eigenen Identitäten.

Identität verlässlich weitergeben

Nach einer Anmeldung benötigt der Dienst den richtigen Kontext: Wer ruft auf, für welchen Mandanten und mit welchen begrenzten Befugnissen? Klären Sie, welche Komponente diese Angaben erzeugt und wie die empfangende Komponente ihre Herkunft überprüft.

Ein möglicher Entwurf verwendet eine intern signierte, kurzlebige Darstellung der geprüften Identität. Der Empfänger prüft Aussteller, Gültigkeit und vorgesehene Zielgruppe. Ein anderer Entwurf lässt jeden Dienst ein für ihn bestimmtes Access Token selbst prüfen. Beide brauchen eine klar definierte Vertrauensbeziehung; die Wahl hängt vom Identitätsmodell und den unterstützten Protokollen ab. Erfinden Sie dafür kein eigenes ungeprüftes Kryptoverfahren.

Blindes Weiterreichen eines externen Tokens an alle Dienste vergrößert seinen möglichen Einsatzbereich und die Zahl der Stellen, an denen es offengelegt werden könnte. Ein ausschließlich intern bekannter Tokenname wäre umgekehrt kein Schutz ohne echte Prüfung. Die Details einer korrekten Tokenprüfung erklärt JWT validieren.

Als Mindestentscheidung muss erkennbar sein: Der Client kann die behauptete interne Identität nicht frei setzen, und der Dienst akzeptiert sie nur über den vorgesehenen verifizierten Weg. Vorhandene externe Header mit intern reservierten Identitätsnamen werden an der Grenze entfernt oder sicher überschrieben; mehrdeutige doppelte Angaben dürfen kein anderes Ergebnis im Backend erzeugen.

Proxyheader sind zunächst Behauptungen

Weiterleitungsheader können Informationen über ursprüngliche Clientadresse, Host und Protokoll transportieren. Sie werden erst durch eine korrekt konfigurierte Proxykette vertrauenswürdig. Wenn Ihre Anwendung beliebige mitgelieferte Werte übernimmt, können davon Links, Weiterleitungen, sichere Cookieentscheidungen oder IP-basierte Grenzen beeinflusst werden.

Express zeigt die konkrete Abhängigkeit am Beispiel trust proxy: Bei pauschalem Vertrauen muss der letzte vertrauenswürdige Proxy die relevanten X-Forwarded-Header zuverlässig entfernen oder überschreiben. Auch eine Konfiguration nach fester Zahl von Zwischenstationen kann bei unterschiedlich langen Wegen falsches Vertrauen erzeugen. Express: Behind proxies.

Übertragen Sie deshalb keine Konfigurationszeile, ohne die eigene Kette zu zeichnen: öffentlicher Eingang, gegebenenfalls weiterer Proxy, Gateway, Dienst. Legen Sie für jede Übergabe fest, wer den Wert setzt und welche direkte Gegenstelle der Empfänger akzeptiert. Proxies, die während eines Rollouts anders routen, gehören in die Prüfung.

Die Adresse aus einem korrekt verarbeiteten Proxyheader bleibt ein Netzsignal, keine sichere Personenidentität. Verwenden Sie sie nicht ohne weitere Grundlage als Ersatz für Kundenrechte oder eine organisationsweite Quote.

Zentrale Regeln konsistent halten

Wählen Sie für gemeinsame Aufgaben eine klar führende Stelle. Wenn Gateway und Anwendung unabhängig CORS-Header oder Fehlerantworten zusammensetzen, können widersprüchliche Antworten entstehen. Der CORS-Konfigurationsratgeber behandelt die fachliche Freigabe; bei nginx hilft die konkrete Konfigurationsanleitung.

Routenänderungen können die Wirkung einer Policy verändern. Prüfen Sie zusammen, welche externe Methode und welcher Pfad nach dem Rewrite im Backend ankommen und wo die Rechteprüfung greift. Eine neue Administrationsroute sollte nicht unbeabsichtigt eine allgemeine öffentlichere Regel erben. Testen Sie die tatsächliche Zuordnung, statt aus ähnlichen Routennamen auf gleiche Kontrolle zu schließen.

Auch Gatewayfunktionen haben Produktgrenzen. AWS erklärt beispielsweise, dass API-Schlüssel seiner Usage Plans nicht als Authentifizierung oder Autorisierung verwendet werden sollen und die zugehörigen Quoten keine garantierten harten Obergrenzen sind. Diese Aussage gilt für dieses AWS-Feature; sie ist kein pauschales Urteil über jede Form von API-Schlüssel. AWS: API Gateway Usage Plans.

Eine WAF oder Schemafunktion kann ergänzende Eingaben erkennen und filtern. Daraus folgt ohne Kenntnis der Regel und des Kontexts keine Freigabe von Objekt-, Feld- oder Geschäftsrechten.

Ausfälle und Änderungen vorab entscheiden

Was passiert, wenn der Identitätsdienst oder eine zentrale Policykomponente nicht erreichbar ist? Für einen geschützten Schreibzugriff darf ein technischer Fehler nicht still eine Freigabe bedeuten. Falls Ihre Architektur Entscheidungen zwischenspeichert, klären Sie Gültigkeit, Widerruf und das zulässige Alter. Ein lange gespeichertes „erlaubt“ kann veraltete Rechte fortschreiben.

Ein Gateway kann außerdem zu einer zentralen Ausfallstelle werden. Halten Sie Konfiguration und Änderungen nachvollziehbar, begrenzen Sie Verwaltungsrechte und schützen Sie dessen eigene Managementschnittstelle. Die zentrale Lage ist ein Grund für sorgfältigen Betrieb, keine automatische Sicherheitseigenschaft.

Bei Änderungen testen Sie zunächst den vorgesehenen Zugang mit gültiger und ungültiger eigener Identität. Ergänzen Sie unerlaubten Direktzugriff, selbst gesetzte interne Header, eine alternative Proxykette und den Ausfall der Policyentscheidung. Kontrollieren Sie sowohl die Antwort als auch, ob der Backendvorgang tatsächlich ausgeführt wurde.

Für das Manuskript wurde keine Gatewaykonfiguration verändert oder in Betrieb getestet. Übernehmen Sie den Entscheidungsweg in Ihre eigene freigegebene Testumgebung.

Einen sicheren Rücknahmeweg erhalten

Bewahren Sie die letzte geprüfte Konfiguration und die zugehörigen Versionen des Identitätsvertrags auf. Nehmen Sie eine fehlerhafte Route oder Policy gezielt zurück. Ein Backend vorübergehend öffentlich zu öffnen, um ein Gatewayproblem zu umgehen, würde die Architekturentscheidung verändern und braucht eine eigene sichere Ersatzlösung.

Prüfen Sie nach dem Wechsel erneut die relevanten erlaubten und verbotenen Wege. Nutzen Sie Korrelation zwischen Gateway und Anwendung, damit ein vorgelagerter Erfolg nicht einen späteren fachlichen Fehler verdeckt. Logging und Monitoring führt diese Beobachtungen zusammen.

Der API Security Check beobachtet öffentliche Antwortmerkmale. Er prüft keine interne Proxyvertrauenskette, Gatewayadministration oder durchgängige Rechteentscheidung. Für diese Zusagen benötigen Sie Architektur-, Konfigurations- und eigene Ablaufbelege.

Passende nächste Schritte