Parce que… c’est l’épisode 0x678! Shameless plug 25 et 26 février 2026 - SéQCure 2026 CfP 14 au 17 avril 2026 - Botconf 202628 et 29 avril 2026 - Cybereco Cyberconférence 20269 au 17 mai 2026 - NorthSec 20263 au 5 juin 2025 - SSTIC 2026 Description Introduction Nick Taylor, développeur advocate chez Pomerium à Montréal, a présenté une approche innovante pour sécuriser les serveurs MCP (Model Context Protocol) en utilisant les principes du Zero Trust et des identity-aware proxy. Développeur depuis longtemps et passionné par la construction d’outils, Nick apporte son expertise en sécurité et infrastructure pour répondre aux défis émergents de l’IA agentique. Le Model Context Protocol (MCP) Le MCP est un protocole récent créé par Anthropic en 2024 qui permet d’étendre les capacités des grands modèles de langage (LLM) en leur donnant accès à des outils externes. Comme l’explique Nick, pour ceux qui ont déjà travaillé avec des systèmes agentiques, le concept des “tool calls” sera familier : il s’agit d’outils que le LLM peut appeler pour enrichir son contexte et accomplir certaines tâches. L’exemple classique est celui de la météo : un LLM ne sait pas quel temps il fait aujourd’hui dans une région donnée. En appelant un outil météo, il peut obtenir cette information et fournir une réponse pertinente, comme “il fait 12 degrés Celsius à Montréal, mets ton manteau”. Sans cet outil, le LLM pourrait suggérer d’aller à la plage en maillot de bain, ce qui serait complètement inapproprié. Un serveur MCP est essentiellement une collection d’outils regroupés logiquement. Par exemple, le serveur MCP GitHub contient plusieurs outils pour interagir avec GitHub : créer un dépôt, créer une issue, ouvrir une pull request, etc. Nick compare MCP à “l’USB-C pour les outils en IA”, une analogie qu’il utilise avec précaution, anticipant l’évolution future du protocole. Les défis de sécurité Bien que MCP existe depuis moins d’un an, il connaît déjà une forte adoption, mais cette rapidité s’accompagne de préoccupations sérieuses en matière de sécurité. Le protocole et son écosystème sont encore en phase de maturation, et on observe un manque de réflexion sur la sécurité dans de nombreuses implémentations. Nick souligne un problème fondamental : le LLM ne comprend pas vraiment ce qui est “bon” ou “mauvais” en termes d’actions. Son rôle est simplement d’essayer d’exécuter les instructions qu’on lui donne. Si on lui demande de faire quelque chose, il tentera de le faire sans considération pour les conséquences. C’est pourquoi il est crucial de mettre en place des garde-fous (guard rails). Un cas d’usage préoccupant mentionné dans la discussion est celui où un MCP connecté à GitHub avec des permissions trop larges pourrait, sans contrôle approprié, effectuer des actions destructrices. Dans un cas extrême, un LLM pourrait même supprimer une base de données de production simplement parce qu’il suit les directives sans comprendre la gravité de l’action. Ce risque est d’autant plus sérieux que les développeurs, dans leur enthousiasme à construire des applications innovantes, ont tendance à négliger la sécurité au profit de la rapidité de développement. Le Zero Trust et l’identity-aware proxy Pour répondre à ces défis, Nick introduit le concept de Zero Trust, un modèle de sécurité développé par Google suite à une importante violation de données dans les années 2010. Le principe fondamental du Zero Trust, comme son nom l’indique, est de ne jamais faire confiance à personne et de toujours vérifier l’identité et le contexte. Traditionnellement, les entreprises utilisent des VPN pour sécuriser l’accès aux ressources internes. Cependant, une fois connecté au VPN, un utilisateur a souvent accès à l’ensemble du réseau interne, même s’il ne peut pas se connecter à certaines ressources spécifiques. Le modèle Zero Trust fonctionne différemment en utilisant un identity-aware proxy (IAP). Un IAP combine trois éléments essentiels : un fournisseur d’identité (IDP) comme Google, GitHub ou Okta, un moteur de politiques, et un reverse proxy. Lorsqu’un utilisateur tente d’accéder à une ressource, le système vérifie non seulement son identité mais aussi son contexte. Par exemple, même si Nicolas est authentifié, s’il essaie d’accéder à l’environnement de production alors qu’il n’est pas de garde (on-call), les politiques bloqueront l’accès. Une caractéristique unique de cette approche est que toutes les URL pour accéder aux ressources internes sont publiques, mais protégées par l’authentification et les politiques. Si une seule condition n’est pas remplie, le proxy n’entre jamais en jeu et l’accès est refusé. Cela diffère fondamentalement du VPN où, une fois connecté, on a un accès réseau même si on ne ...
Show More
Show Less
50 mins