Au commencement était le monolithe. Il a longtemps été utile aux développeurs de logiciels et continue de l’être pour certains cas d’utilisation. Mais à mesure que les applications se sont développées, les monolithes sont devenus difficiles à développer, à sécuriser et à entretenir. Les microservices sont apparus comme une alternative : le monolithe est divisé en petits services autonomes qui exécutent une fonction métier unique et communiquent via un réseau pour fournir toutes les fonctionnalités de l' application. Au début, 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 inspiré le passage aux architectures basées sur REST et l’adoption généralisée de HTTP et de JSON comme protocole et méthode de sérialisation des données, respectivement.
Mais comme c’est souvent le cas avec la technologie, les développeurs ont continué à chercher des moyens encore meilleurs de concevoir des applications, par exemple pour surmonter les limitations inhérentes à l’orientation textuelle de SOAP et REST. L'un de ces systèmes est gRPC , que Google a développé pour connecter sa vaste gamme de services indépendants et autonomes. gRPC utilise des tampons de protocole (protobufs) comme mécanisme neutre en termes de plate-forme et de langage pour la sérialisation des données structurées, et HTTP/2 comme protocole de communication.
Parmi les avantages de gRPC par rapport aux autres frameworks d’API figurent son faible débit de latence, la prise en charge de plusieurs langues, la représentation compacte des données et le streaming en temps réel, qui le rendent particulièrement adapté à la communication entre microservices et sur des réseaux à faible consommation d’énergie et à faible bande passante. La popularité de gRPC a considérablement augmenté ces dernières années car elle permet de créer de nouveaux services plus rapidement et plus efficacement, avec une fiabilité et une évolutivité supérieures, et avec une indépendance linguistique pour les clients et les serveurs.
Un exemple notable des avantages du gRPC est l’open banking, qui utilise des technologies open source pour concevoir et fournir des API, permettant aux développeurs externes de proposer des services supplémentaires aux clients d’une banque ou d'une autre institution financière. L'open banking repose entièrement sur l’objectif de transmettre l’information financière de manière plus efficace et rapide. gRPC facilite cet objectif grâce au format compact des protocol buffers et au multiplexage HTTP/2, qui accélèrent le transfert des charges utiles de façon significative : environ 7 fois plus vite pour la réception et 10 fois plus vite pour l’envoi comparé aux API REST. Par conséquent, les institutions financières adoptent gRPC pour leurs communications interservices afin d’assurer une prestation plus rapide, efficace, fiable et scalable.
Un cas d'utilisation spécifique où la vitesse du gRPC constitue un avantage majeur est le processus d'intégration des clients, qui dans l'open banking est primordial pour le succès. Avec d’autres frameworks API, la création d’un nouveau compte peut être fastidieuse et prendre du temps, tant pour les institutions financières que pour les clients. Avec gRPC, le transfert de données rapide signifie que les clients peuvent créer un nouveau compte en quelques minutes. Cela augmente considérablement la satisfaction des clients tout en réduisant considérablement les coûts pour l’institution financière.
La norme gRPC et le format protocol buffers sont intégrés dans une bibliothèque open source. Protocol buffers offrent une meilleure protection contre les cyberattaques que d’autres formats, car notre parseur de bibliothèque rejette les requêtes mal formées et analyse minutieusement le comportement de la bibliothèque.
Mais certaines opportunités déconcertantes d’attaques contre gRPC subsistent. Par exemple, l'analyseur :
stream
l'un
des types composés et autorise la présence de plusieurs champsUn attaquant peut exploiter ces lacunes dans le protocole gRPC pour compromettre une application. Les tampons de protocole permettent également la création de champs qui ne sont pas définis dans les définitions de message. Cela garantit l’extensibilité de la conception, permettant la compatibilité avec les futures versions étendues d’un message, mais cela peut également rendre les applications vulnérables aux attaques de contrebande, dans lesquelles les attaquants intègrent des champs dans leurs requêtes qui ne sont pas explicitement codés comme autorisés dans l’ application.
NGINX App Protect est conçu pour protéger les applications modernes basées sur gRPC plus proches de l' application de service. Cela permet aux équipes AppDev, DevOps et DevSecOps de gérer la sécurité des application en tant que code et d'exploiter des outils natifs.
Par exemple, NGINX App Protect garantit que les institutions financières et leurs services sont conformes aux normes bancaires ouvertes lors de la mise en œuvre de gRPC pour leurs communications interservices. Le moteur de NGINX App Protect exécute une inspection approfondie des messages gRPC sur les requêtes filaires, analyse les messages du tampon de protocole 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 n'importe quelle demande et applique un mécanisme de détection d'attaque pour 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 de protocole pour les 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'il soit nécessaire de modifier sa configuration. Les fichiers proto gRPC sont fréquemment mis à jour dans le cadre des pipelines CI/CD, de sorte que la mise à jour des politiques de sécurité ne perturbe pas ou n'ajoute pas de surcharge à vos processus, et vos applications sont toujours protégées par la politique la plus récente et la plus à jour .
En plus de sécuriser le trafic est-ouest entre vos microservices basés sur gRPC, NGINX App Protect protège le trafic nord-sud de vos ressources exposées publiquement.
Bien que gRPC améliore la vitesse, l'efficacité et l'échelle des communications de service à service , il est essentiel de protéger et de sécuriser les données API (URL, en-têtes et charges utiles) et les services application qui exposent les API gRPC. C'est pourquoi NGINX App Protect est essentiel pour votre architecture application moderne.
Pour en savoir plus sur gRPC avec NGINX App Protect, regardez notre vidéo lightboard :
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, démarrez un essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d'utilisation .
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."