OAuth le risque silencieux qui transforme les autorisations en portes d'accès à vos systèmes

La discussion des risques de l'intelligence artificielle dans les entreprises se concentre souvent sur le visible : les employés frappent des données sensibles sur les chatbots publics. Cependant, il y a une menace moins bruyante et plus pernicieuse qui mérite la priorité : Intégrations OAuth que les employés se connectent aux applications critiques (Google Workspace, Microsoft 365, Salesforce, etc.). Contrairement à une conversation avec un LLM, une connexion OAuth crée un pont persistant entre votre environnement et un troisième ; ce pont ne disparaît pas lorsque l'utilisateur cesse d'utiliser l'application et peut transformer un espace en fournisseur en une porte d'accès direct à vos systèmes.

Le cas récent qui a touché Vercel est illustratif : un test d'une application de productivité avec les permissions sur Google Workspace a fini par être le lien qui a permis aux attaquants de pivoter après avoir compromis le fournisseur. C'est une démonstration pratique de pourquoi il ne suffit pas de contrôler les données qui sont écrites dans un chat: nous devons contrôler les relations de confiance qui sont créées entre les systèmes. Pour lire une analyse technique de l'incident et comment les jetons et les autorisations ont été exploités, le rapport de recherche publié par les spécialistes de la sécurité est disponible: Déballage de la pause Vercel.

Ce n'est pas un cas isolé ou exclusif d'applications «AI». Ces dernières années, nous avons vu des campagnes de jetons et d'attaques basées sur OAuth qui ont frappé des milliers d'organisations, et l'arrivée d'outils AI qui orchestrent les flux entre les applications n'a fait que multiplier la surface d'attaque. Les attaquants ont fait d'OAuth un vecteur fiable parce qu'un jeton valide est, dans de nombreux cas, autant ou plus précieux qu'un titre de créance.

Les répercussions sur la sécurité de l'entreprise sont claires et opérationnelles : vous devez considérer les autorisations de demande comme des actifs essentiels. Premièrement, un modèle de consentement par défaut restrictif devrait être adopté dans votre identité organisationnelle et les utilisateurs ne devraient pas être en mesure de lier de nouvelles demandes sans approbation. Google Workspace et d'autres plateformes permettent de gérer l'accès de tiers; le guide officiel sur la manière de contrôler les applications de tiers dans Google Workspace est un bon point de départ pour les administrateurs: Gérer l'accès des applications tierces aux données Google Workspace.

L'hygiène opérationnelle est également importante : des audits réguliers des intégrations actives, des examens des permis demandés pour chaque application et la capacité de révoquer automatiquement les jetons contre les indicateurs d'engagement sont des mesures qui réduisent la fenêtre d'exposition. Il est également essentiel d'avoir des procédures de réponse qui comprennent le retrait massif du consensus et la rotation des clés et des jetons lorsqu'un fournisseur est compromis.

Il ne suffit pas de contrôler le fournisseur d'identité. De nombreuses connexions se produisent entre SaaS et SaaS et ne sont pas visibles du panneau d'administration principal. C'est pourquoi une combinaison de méthodes est nécessaire : inventorier les applications utilisées par ordinateur, surveiller l'authentification et le consensus à partir du navigateur et du SSO, et déployer la détection qui identifie les modèles de trafic d'API rares ou l'accès hors calendrier. En outre, les contrôles des paramètres et les politiques d'extension du navigateur aident à atténuer les vecteurs de livraison tels que les infostealers ou le phishing qui finissent en jetons vol.

Au niveau tactique, il y a des outils et des pratiques qui fonctionnent le mieux ensemble : appliquer des SSO obligatoires avec des politiques de consensus centralisées, exiger des MFA solides (idéalement avec des clés matérielles) pour les comptes à haut débit, limiter les champs d'application au minimum nécessaire et exiger des examens de sécurité aux fournisseurs avant de permettre l'intégration. Il est également utile de mettre en place des alertes qui détectent la création d'applications autorisées par l'utilisateur et de les soumettre à un examen automatique.

L'évolution de l'attaque - des campagnes d'hameçonnage qui entraînent des applications aux lacunes des fournisseurs qui stockent des jetons - nécessite une réponse qui combine gouvernance, technologie et formation. Les équipes de sécurité devraient cesser de considérer ces encombrements comme de « petits choix d'utilisateurs » et les considérer comme des relations de confiance qu'il faut gérer activement. Pour élargir la vue sur la façon dont les attaques par navigateur et OAuth changent l'image, il y a des rapports récents qui analysent des techniques telles que le phishing vice-code et d'autres vecteurs pertinents: Phishing du code de l'appareil: rapport technique.

Si votre organisation n'a pas encore de politique claire sur l'intégration OAuth et l'utilisation de l'IA, le temps d'agir est maintenant. Petites défenses préventives - bloc de consentement non autorisé, audits réguliers, détection de navigateur et contrôles de PDI - réduisent considérablement le risque qu'un test ou un utilitaire IA devienne le chemin d'accès pour un écart plus grand. Traiter OAuth comme une surface critique et coordonner les contrôles entre l'équipement d'identité, la sécurité des paramètres et la gestion des applications est la décision stratégique que vous pouvez éviter le prochain incident fournisseur.