Au commencement était le monolithe. Il a longtemps rendu de précieux services aux développeurs de logiciels, et reste encore adapté à certains cas d’usage. Mais à mesure que les applications se sont développées, les monolithes sont devenus difficiles à faire évoluer, à sécuriser et à maintenir. Les microservices sont alors apparus comme une solution alternative : le monolithe est décomposé en petits services autonomes qui assurent chacun une fonction métier unique et communiquent via un réseau afin de fournir toutes les fonctionnalités de l’application. À l’origine, les développeurs web utilisaient SOAP comme protocole de communication et XML pour encoder les données, mais beaucoup trouvaient cette combinaison lourde et lente. Cela a conduit à l’adoption d’architectures basées sur REST ainsi qu’à la généralisation de HTTP et de JSON comme protocole et méthode de sérialisation des données, respectivement.
Mais comme c’est souvent le cas dans le domaine technologique, les développeurs ont continué à chercher des moyens encore plus efficaces de concevoir des applications, notamment pour surmonter les limites inhérentes à l’orientation textuelle de SOAP et REST. L’un de ces systèmes est gRPC, développé par Google pour interconnecter son vaste éventail de services indépendants et autonomes. gRPC utilise des tampons de protocole (protobufs) comme mécanisme indépendant de la plateforme et du langage pour sérialiser des données structurées, et HTTP/2 comme protocole de communication.
Avantages de gRPC
Parmi les avantages de gRPC par rapport aux autres frameworks d’API figurent son débit à faible latence, sa prise en charge de plusieurs langages, sa représentation compacte des données et le streaming en temps réel. Ces caractéristiques le rendent particulièrement adapté aux communications entre microservices ainsi qu’aux réseaux à faible consommation d’énergie et à faible bande passante. La popularité de gRPC a considérablement augmenté ces dernières années, car il permet de créer de nouveaux services plus rapidement et plus efficacement, avec une fiabilité et une évolutivité accrues, tout en garantissant l’indépendance vis-à-vis du langage, tant pour les clients que pour les serveurs.
Un exemple marquant des avantages de gRPC est l’open banking, qui utilise des technologies open source pour créer et fournir des API, permettant ainsi à des développeurs tiers de proposer des services supplémentaires aux clients d’une banque ou d’un autre établissement financier. L’open banking repose entièrement sur l’idée de fournir des informations financières de manière plus efficace et performante. gRPC contribue à atteindre cet objectif, car le format compact des tampons de protocole et le multiplexage dans HTTP/2 permettent de transférer une charge utile donnée beaucoup plus rapidement qu’avec des API REST : environ 7 fois plus vite lors de la réception des données et 10 fois plus vite lors de leur envoi. Par conséquent, les établissements financiers adoptent gRPC pour leurs communications interservices afin de fournir des services plus rapidement, avec davantage d’efficacité, de fiabilité et d’évolutivité.
Un cas d’usage spécifique dans lequel la rapidité de gRPC constitue un avantage majeur est le processus d’intégration des clients, qui est essentiel à la réussite dans le secteur de l’open banking. Avec d’autres frameworks d’API, la création d’un compte peut s’avérer fastidieuse et chronophage, tant pour les établissements financiers que pour leurs clients. Grâce à la rapidité du transfert de données avec gRPC, les clients peuvent créer un compte en quelques minutes. Cela améliore considérablement leur satisfaction tout en réduisant sensiblement les coûts pour l’établissement financier.
Sécuriser gRPC
La norme gRPC et le format Protocol Buffers sont implémentés sous la forme d’une bibliothèque open source. Protocol Buffers est considéré comme plus résistant aux cyberattaques que d’autres formats de représentation des données, car l’analyseur de la bibliothèque rejette les requêtes malformées et permet d’examiner plus précisément le comportement de la bibliothèque.
Mais certaines possibilités préoccupantes d’attaques contre gRPC subsistent. Par exemple, l’analyseur syntaxique :
- Permet d’envoyer un flux de messages sans le mot-clé
stream - Autorise plusieurs occurrences d’un champ dans un message, même si le champ n’est pas déclaré comme répétable
- Ne vérifie pas les clés répétées dans les champs de type map ; seule la dernière occurrence de la clé est prise en compte
- Ne vérifie pas les types composés «
oneOf» et autorise la présence de plusieurs champs
Un attaquant peut exploiter ces failles du protocole gRPC pour compromettre une application. Les tampons de protocole permettent également de créer des champs qui ne sont pas définis dans les définitions de messages. Cela garantit l’extensibilité de la conception – en assurant la compatibilité avec de futures versions étendues d’un message – mais peut aussi rendre les applications vulnérables aux attaques par dissimulation, dans lesquelles les attaquants intègrent à leurs requêtes des champs que le code de l’application n’autorise pas explicitement.
NGINX App Protect sécurise les API gRPC
NGINX App Protect est conçu pour protéger les applications modernes basées sur gRPC au plus près de l’application de service. Les équipes AppDev, DevOps et DevSecOps peuvent ainsi gérer la sécurité des applications sous forme de code et tirer parti des outils natifs.
Par exemple, NGINX App Protect permet aux établissements financiers et à leurs services de respecter les normes d’open banking lorsqu’ils mettent en œuvre gRPC pour leurs communications interservices. Le moteur de NGINX App Protect effectue une inspection approfondie des messages gRPC dans les requêtes transmises sur le réseau, analyse les messages Protocol Buffers et détecte les données malveillantes dans les en-têtes et les charges utiles des messages, y compris dans toutes les structures de données imbriquées et complexes. L’inspection est effectuée sur chaque requête et applique un mécanisme de détection des attaques à chaque paramètre d’appel d’API.
Avec les API gRPC, vous utilisez l’interface gRPC pour définir la politique de sécurité dans le fichier de bibliothèque de types (fichier IDL) et les fichiers de définition proto des tampons de protocole. Lorsque les fichiers mis à jour sont chargés, NGINX App Protect commence immédiatement à appliquer les nouvelles politiques de sécurité, sans qu’aucune modification de sa configuration soit nécessaire. Les fichiers proto gRPC sont fréquemment mis à jour dans le cadre des pipelines CI/CD. La mise à jour des politiques de sécurité ne perturbe donc pas vos processus et ne leur impose aucune charge supplémentaire, tandis que vos applications restent toujours protégées par la politique la plus récente et la plus à jour.
En plus de protéger le trafic est-ouest entre les microservices basés sur gRPC, NGINX App Protect sécurise le trafic nord-sud entre vos ressources exposées publiquement.
Bien que gRPC améliore la rapidité, l’efficacité et l’évolutivité des communications entre services, il est essentiel de protéger et de sécuriser les données des API (URL, en-têtes et charges utiles), ainsi que les services applicatifs qui exposent des API gRPC. C’est pourquoi NGINX App Protect est indispensable à votre architecture d’applications modernes.
Pour en savoir plus sur gRPC avec NGINX App Protect, regardez notre vidéo explicative sur tableau lumineux :
Essayez NGINX App Protect gratuitement
Pour plus d’informations sur la prise en charge de gRPC dans NGINX App Protect, consultez la documentation.
Pour essayer NGINX Plus et NGINX App Protect avec vos API gRPC, commencez un essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d’usage.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.