Les microservices derrière une passerelle API doivent-ils vérifier le jeton d'accès?

J'ai un tas de microservices qui ne sont accessibles qu'en externe via une passerelle API.

Ma passerelle API est configurée en tant que ressource OAuth et valide le jeton (vérifie la signature, etc.) avant de transmettre la demande en aval à un ou plusieurs microservices.

Alors que mes microservices ont besoin du jeton pour vérifier les étendues et les réclamations, est-il maintenant nécessaire que ce service valide également le jeton?

Cela semble un peu exagéré mais je ne trouve aucun conseil en ligne sur ce scénario.

La validation du jeton sur la passerelle API est-elle suffisante? Ou est-il préférable de le valider ultérieurement?

microservices

— fml
source

Ces mêmes services sont-ils accessibles en contournant la passerelle en interne ?

— Greg Burghardt

I cannot find any advice online about this scenario.Parce que cela dépend de plusieurs facteurs qui varient d'un projet à l'autre. Probablement dans la plupart des développements qui prétendent être une architecture MS, ils n'en ont pas besoin. De plus, dans de telles architectures, il devrait y avoir un serveur d'authentification qui le fera à la place des services (et au lieu de la passerelle bien sûr). Est le serveur d'authentification qui autorise la réussite ou non de la demande.

— Laiv

Si des appels internes peuvent contourner la passerelle, validez le jeton dans chaque microservice ou forcez tous les appels - internes et externes - à passer par la passerelle.

Personnellement, je ne ferais pas non plus confiance aux appels internes. Demandez-leur de passer par la passerelle, même au point de limiter le trafic via les règles de pare-feu. Sachez qui parle à qui et pourquoi. Cela permet de limiter votre surface d'attaque si quelqu'un viole votre réseau.

Cela introduit un point de défaillance unique, mais ce risque peut être atténué en équilibrant la charge des serveurs et en ayant des serveurs de basculement à portée de main en cas de problèmes catastrophiques.

D'un autre côté, si chaque service valide le jeton, et tout ce qui concerne le processus de validation change, vous avez des services N + 1 à mettre à jour.

— Greg Burghardt
source

J'ai entendu l'argument selon lequel "vous ne pouvez pas non plus faire confiance au trafic interne". Mais exposer une application à un nombre (relativement) restreint d'utilisateurs sur un intranet est bien loin d'exposer la même application à l'Internet public. C'est essentiellement la même chose que la différence entre un aimant de haut-parleur et un cyclotron.

— Robert Harvey

@RobertHarvey: Je pense que la justification que j'ai entendue pour "ne pas faire confiance au trafic interne" n'est pas tant le trafic légitime que le mur du réseau en cas d'intrusions. Surtout si votre système gère les informations personnelles, de santé, financières ou sensibles. Si quelqu'un entre par effraction, il est limité dans quoi d'autre il peut parler.

— Greg Burghardt

Si quelqu'un pénètre dans votre système, la validation du jeton serait le moindre de vos problèmes. Que vous deviez ou non valider le jeton au sein d'un réseau de confiance (et non accessible par des étrangers) pourrait dépendre du type de validations que nous effectuons et s'il y en a encore qui n'effectuent pas la validation. Comme par exemple, la performance. Revenons à votre raisonnement. Souhaitez-vous implémenter TLS dans un réseau privé? Souhaitez-vous chiffrer la communication entre deux composants fonctionnant côte à côte? La réponse probable est dépend .

— Laiv