Müssen Microservices hinter einem API-Gateway das Zugriffstoken überprüfen?

Ich habe eine Reihe von Microservices, auf die nur extern über ein API-Gateway zugegriffen werden kann.

Mein API-Gateway ist als OAuth-Ressource eingerichtet und überprüft das Token (Überprüft die Signatur usw.), bevor die Anforderung an einen oder mehrere Mikrodienste weitergeleitet wird.

Während meine Microservices das Token benötigen, um Bereiche und Ansprüche zu überprüfen, muss dieser Service jetzt auch das Token validieren?

Es scheint ein bisschen übertrieben, aber ich kann online keinen Rat zu diesem Szenario finden.

Ist die Validierung des Tokens am API-Gateway gut genug? Oder ist es empfehlenswert, es später erneut zu validieren?

microservices

— fml
quelle

Sind dieselben Dienste verfügbar, wenn das Gateway intern umgangen wird ?

— Greg Burghardt

I cannot find any advice online about this scenario.Weil es von mehreren Faktoren abhängt, die von Projekt zu Projekt variieren. Wahrscheinlich brauchen sie es in den meisten Entwicklungen, die behaupten, MS-Architektur zu sein, nicht. Darüber hinaus sollte es in solchen Architekturen einen Authentifizierungsserver geben, der dies anstelle der Dienste (und natürlich anstelle des Gateways) ausführt. Ist der Authentifizierungsserver, der die Anforderung weiterleiten lässt oder nicht.

— Laiv

Wenn interne Anrufe das Gateway umgehen können, überprüfen Sie entweder das Token in jedem Mikrodienst oder zwingen Sie alle internen und externen Anrufe, das Gateway zu durchlaufen.

Persönlich würde ich auch internen Anrufen nicht vertrauen. Lassen Sie sie das Gateway durchlaufen, bis der Datenverkehr über Firewall-Regeln begrenzt wird. Wissen, wer mit wem spricht und warum. Dies hilft, Ihre Angriffsfläche zu begrenzen, falls jemand jemals Ihr Netzwerk verletzt.

Dies führt zwar zu einem einzigen Fehlerpunkt, dieses Risiko kann jedoch durch Lastausgleichsserver und das Vorhandensein von Failover-Servern bei katastrophalen Problemen gemindert werden.

Wenn andererseits jeder Dienst das Token validiert und sich etwas am Validierungsprozess ändert, müssen Sie N + 1-Dienste aktualisieren.

— Greg Burghardt
quelle

Ich habe das Argument gehört, dass "Sie auch dem internen Verkehr nicht vertrauen können". Die Bereitstellung einer Anwendung für eine (relativ) kleine Anzahl von Benutzern in einem Intranet ist jedoch weit davon entfernt, dieselbe Anwendung dem öffentlichen Internet zugänglich zu machen. Dies entspricht im Wesentlichen dem Unterschied zwischen einem Lautsprechermagneten und einem Zyklotron.

— Robert Harvey

@RobertHarvey: Ich denke, die Rechtfertigung, die ich für "Vertraue nicht dem internen Verkehr" gehört habe, ist weniger der legitime Verkehr als vielmehr die Abschottung des Netzwerks im Falle von Eingriffen. Insbesondere, wenn Ihr System PII-, Gesundheits-, Finanz- oder vertrauliche Informationen verarbeitet. Wenn jemand einbricht, hat er nur begrenzte Möglichkeiten, mit was er sonst noch sprechen kann.

— Greg Burghardt

Wenn jemand in Ihr System eindringt, ist die Token-Validierung das geringere Problem. Ob Sie das Token in einem vertrauenswürdigen Netzwerk validieren sollten oder nicht (und für Fremde nicht zugänglich), hängt möglicherweise von der Art der von uns durchgeführten Validierungen ab und davon, ob die Validierung erneut durchgeführt wird. Wie zum Beispiel Leistung. Zurück zu Ihrer Argumentation. Würden Sie TLS in einem privaten Netzwerk implementieren? Würden Sie die Kommunikation zwischen zwei nebeneinander laufenden Komponenten verschlüsseln? Die wahrscheinliche Antwort ist abhängig .

— Laiv