La fin du proxy : la sécurité contextuelle au point d'arrivée et au bord pour IA et TLS 1.3

Pendant des années, la stratégie de sécurité du réseau a été simple : l'acheminement et l'inspection. Les entreprises ont confiance dans les proxies du cloud pour décrypter le trafic, mettre en œuvre les politiques et enregistrer l'activité. Cette logique a fonctionné lorsque la plupart des interactions sensibles se sont produites sur des canaux que le réseau pouvait interpréter. Ce n'est plus le cas aujourd'hui: le travail se déplace vers le navigateur, les outils générateurs et les agents autonomes agissent à la vitesse de la machine, et les interactions critiques se produisent dans la couche de présentation, où les procurations traditionnelles n'arrivent pas.

L'élaboration de protocoles tels que TLS 1,3, QUIC et HTTP / 3 - conçu pour améliorer la sécurité et les performances - complique la capacité des intercepteurs de trafic à agir comme un homme dans le milieu sans briser la connexion. La spécification technique TLS 1.3 documente ces changements de conception: voir RFC 8446 (TLS 1.3). Les marins et les applications profitent également de techniques telles que épingle du certificat qui bloquent les interceptions forcées et causent des pannes de service critiques si le déchiffrement forcé est insisté.

Le résultat opérationnel est double et corrosif: d'une part, les organisations finissent par établir d'énormes listes d'exceptions afin que les applications légitimes ne se décomposent pas, réduisant leur périmètre de sécurité silencieusement; d'autre part, le détournement constant des sessions vers les proxies à distance introduit une pénalisation de la latence- la « taxe de visite » qui dégrade l'expérience utilisateur et encourage la recherche de raccourcis par l'équipement (Shadow IT), en élargissant la surface de risque.

L'arrivée de LLMs et d'agents automatisés rend visible une limitation structurelle : un proxy réseau peut voir une connexion HTTPS valide à un fournisseur IA, mais ne peut pas discerner Objectif contenu dans la charge utile ou le contexte sémantique d'une interaction lorsqu'elle se produit dans le navigateur avant de quitter l'organisation. D'ici là, l'opération, qui consiste à copier le code sensible à une demande publique ou à permettre à un agent de récupérer la documentation interne, a déjà été consommée en dehors du cadre de l'inspection traditionnelle.

Devant ce scénario, l'alternative binaire - bloquer toute utilisation de l'IA ou l'autoriser sans contrôle - est impossible. Blogging favorise le travail caché et la perte de productivité, lui permettant d'aveugler l'équipe de sécurité. La réponse ne peut être plus la même : une réouverture est nécessaire qui conduira à l'évaluation des politiques dernière section de la connexion, c'est-à-dire le terminal et le navigateur, où apparaissent la copie / coller, les invites et l'invocation d'agent.

L'évaluation et la mise en œuvre des contrôles au point d'interaction offrent trois avantages stratégiques: protection contextuelle, parce que le contenu tel que texte copié, invites et fichiers peuvent être analysés localement avant toute sortie de données; alignement avec les protocoles natifs car il ne force pas le chiffrement de bout en bout des protocoles modernes à casser; troisièmement, performance directe, parce que la plupart du trafic légitime peut se déplacer sans détours, récupérer la latence et l'expérience utilisateur. Les architectures qui combinent l'évaluation des paramètres et le routage dynamique des bords réduisent la nécessité d'une inspection universelle des nuages.

La mise en oeuvre de ce changement ne se limite pas à l'adoption de technologies : il s'agit de reconfigurer les processus et les responsabilités. Les organisations devraient commencer par cartographier les flux de données et cataloguer les types d'informations qui peuvent être obtenues par l'intermédiaire des LLM et des agents, en appliquant la classification et les étiquettes qui alimentent ensuite les politiques contextuelles. Il est essentiel de compléter les contrôles techniques par la gouvernance: règles sur l'utilisation de modèles publics, contrats avec les fournisseurs d'AI et formation pour enseigner la conception sûre et la reconnaissance des risques.

Sur le plan technique, il convient de déployer des solutions qui combinent DLP au navigateur ou aux extensions gérées, des agents terminaux capables d'intercepter les événements de copie/collage et les appels de processus de surveillance aux modèles API, et un plan de contrôle qui orchestre quand et comment rediriger le trafic vers le bord pour une inspection supplémentaire. Il importe également de tirer parti des bonnes pratiques et des cadres de normes, par exemple NIST Cadre de gestion des risques de l'IA fournit des critères utiles pour la gestion des risques de l'IV au niveau organisationnel.

Cependant, il y a des coûts et des compromis : l'inspection dans le paramètre augmente la complexité opérationnelle, soulève des questions au sujet de la confidentialité des utilisateurs et nécessite des modèles de confiance zéro qui distinguent entre les sessions et les données qui devraient être protégées et celles qui ne le sont pas. De plus, toutes les applications ne permettent pas une instrumentation facile; la solution pratique est généralement une combinaison d'isolement du navigateur pour les sessions peu fiables, de politiques basées sur le contenu pour les prompts et les agents, et de télémétrie centralisée pour la vérification et la réponse.

D'un point de vue organisationnel, la priorité immédiate devrait être double : d'une part, arrêter de s'appuyer sur des listes d'exceptions sans fin et mesurer l'effet réel des écarts sur la sécurité et la productivité; d'autre part, concevoir une voie de migration vers un modèle qui priorise l'évaluation contextuelle dans le paramètre et le routage dynamique vers le bord, au besoin. En termes opérationnels, cela se traduit par des tests de compatibilité TLS 1.3 / HTTP3, des déploiements pilotes DLP dans le navigateur et des exercices d'équipe violette qui simulent des fuites via des invites et des agents.

L'architecture que certains fournisseurs appellent "Paquet parfait" n'est pas une solution magique mais un cadre opérationnel : inspection initiale au point d'interaction, décisions locales et escalade sélective du cloud pour des sessions suspectes. Pour l'adopter avec des critères, il faut investir dans la visibilité locale, des politiques en fonction du contexte et une approche de sécurité qui privilégie à la fois la protection des données et l'expérience des utilisateurs. Pour comprendre les implications techniques de HTTP / 3 et QUIC, qui influencent également la stratégie d'inspection, il est utile de revoir la documentation technique telle que Google sur HTTP / 3: HTTP / 3 et performances.

Le défi ne disparaîtra pas : plus d'intégration entre SaaS, les extensions et les outils IA génèrent plus de points d'interaction en dehors du domaine traditionnel du réseau. La bonne nouvelle est que la solution est pratique et est à portée de main: mesurer, mettre en œuvre le paramètre, appliquer des politiques contextuelles, régir l'utilisation des modèles et rediriger seulement ce qui est nécessaire au bord. Ceux qui agissent maintenant vont réduire leur exposition et récupérer l'expérience utilisateur qui conduit la productivité, empêchant la sécurité de devenir la cause de l'évasion à l'IT Ombre.