La sécurité de l'IA est un défi en temps réel pour tout le monde, y compris Google

J’ai récemment eu l’occasion de m’entretenir avec Francis de Souza, directeur des opérations de Google Cloud, en coulisses lors d’un événement à Los Angeles. Au milieu du brouhaha ambiant, M. de Souza — qui s’exprime avec le ton calme et posé d’un professeur d’université — a donné des conseils pratiques aux entreprises qui doivent s’y retrouver dans le paysage actuel de la sécurité de l’IA. Il a déclaré : « Il y aura une période de transition, puis je pense que nous arriverons à une situation meilleure. »

Il ne parlait pas spécifiquement de Google à ce moment-là, mais il est clair que même Google est encore en train de relever ces défis.

Le message central de M. de Souza est celui que les professionnels de la sécurité tentent depuis longtemps de faire passer auprès des dirigeants, et qui revêt désormais un caractère d’urgence en raison de l’IA : la sécurité ne peut pas être une réflexion après coup. « À mesure que les entreprises s’engagent dans cette voie de l’IA, elles doivent adopter une approche par plateforme », a-t-il déclaré. « La sécurité n’est pas quelque chose que l’on peut ajouter après coup, ni quelque chose que l’on peut laisser aux employés de gérer de leur propre chef. » Il a notamment mis en garde contre l’« IA fantôme » — c’est-à-dire les employés utilisant des outils grand public sans contrôle de la part de l’entreprise — et a souligné que les entreprises devaient exiger dès le départ que leurs plateformes garantissent sécurité, gouvernance et auditabilité. « Il n’existe pas de stratégie d’IA sans stratégie de données et sans stratégie de sécurité. Elles doivent aller de pair. »

À noter : il ne faisait pas uniquement la promotion de Google Cloud. Lorsque je lui ai fait remarquer que ses conseils ressemblaient à une publicité pour Google, il a réagi. Google, a-t-il précisé, s’engage en faveur d’une approche multicloud, et il a fait valoir que les entreprises qui pensent opérer sur un seul cloud n’en sont presque certainement pas le cas. « Même si elles choisissent un seul cloud, elles s’appuient sur des applications SaaS, et certains de leurs partenaires commerciaux peuvent utiliser des clouds différents », a-t-il déclaré. « Il est important que les entreprises disposent d’une posture de sécurité cohérente d’un cloud à l’autre et d’un modèle à l’autre. »

Il a également fait valoir que le paysage des menaces avait changé de manière si fondamentale que les anciens modèles de défense sont désormais trop lents. Il a souligné que le délai moyen entre une première intrusion et le passage à la phase suivante d’une attaque était passé de huit heures à 22 secondes, et que la surface d’attaque s’était étendue au-delà du périmètre réseau traditionnel. « Outre votre infrastructure habituelle, vous disposez désormais de modèles. Vous disposez de pipelines de données utilisés pour entraîner ces modèles. Vous avez des agents, vous avez des invites. Tout cela doit être protégé. »

De Souza a mis en avant une menace qui ne retient pas suffisamment l’attention : les agents se déplaçant au sein des systèmes internes d’une entreprise peuvent mettre au jour des référentiels de données oubliés dont personne n’avait plus entendu parler depuis des années. « De nombreuses organisations possèdent d’anciens serveurs SharePoint [et des contrôles d’accès] qu’elles n’ont pas vraiment mis à jour, mais cela n’avait pas d’importance car personne ne savait vraiment où ils se trouvaient. Or, les agents qui parcourent votre entreprise trouveront ces ressources de données et en exposeront le contenu. »

La solution, selon lui, consiste à répondre à la vitesse des machines par la vitesse des machines. « Nous assistons aujourd’hui à l’émergence d’une défense entièrement basée sur des agents et native de l’IA, où les organisations peuvent déployer des agents pour piloter leur défense », a-t-il déclaré. « Au lieu d’une défense dirigée par des humains, voire d’une défense impliquant une intervention humaine, il est désormais possible de faire superviser par des humains une défense entièrement automatisée. » Il a ajouté que cela était devenu un enjeu de direction, et non plus uniquement un enjeu technologique. « C’est une question qui relève du conseil d’administration et de l’équipe de direction. Ce n’est pas seulement l’affaire de l’équipe de sécurité. »

Mais alors même que l’IA prend en charge une part croissante de la charge de travail liée à la défense, les personnes qualifiées pour la superviser se font rares — et les vulnérabilités introduites par l’IA elle-même se multiplient plus vite que les équipes de sécurité ne peuvent y remédier. « Nous allons avoir besoin de personnes pour faire face à l’apocalypse des bugs », a déclaré cette semaine Lea Kissner, responsable de la sécurité de l’information chez LinkedIn, au New York Times, ajoutant qu’elle ne s’attendait pas à ce que le secteur comprenne la sécurité de l’IA de manière durable à long terme avant au moins plusieurs années.

Ce qui nous ramène aux fournisseurs de plateformes eux-mêmes. Le Register a publié ces dernières semaines une série d’articles faisant état d’une vague de développeurs Google Cloud confrontés à des factures à cinq chiffres suite à des appels API non autorisés vers des modèles Gemini — des services que beaucoup d’entre eux n’avaient jamais utilisés ni activés intentionnellement. Ces cas suivaient tous le même schéma : des clés API initialement déployées pour Google Maps, rendues publiques conformément aux instructions de Google, avaient discrètement acquis la capacité d’accéder à Gemini après que Google eut élargi leur champ d’application sans communiquer clairement sur ce changement.

Rod Danan, PDG de la plateforme de préparation aux entretiens Prentus, a déclaré que sa facture avait atteint 10 138 dollars en environ 30 minutes après que des pirates eurent exploité sa clé API compromise. Isuru Fonseka, un développeur basé à Sydney dont le compte a été compromis de la même manière, s’est réveillé avec des frais s’élevant à environ 17 000 dollars australiens, alors qu’il pensait avoir mis en place un plafond de dépenses de 250 dollars. Ce qu’aucun des deux ignorait, c’est que les systèmes automatisés de Google avaient revu à la hausse leurs niveaux de facturation en fonction de l’historique de leur compte, portant ainsi leurs plafonds effectifs jusqu’à 100 000 dollars sans consentement explicite.

Google a remboursé les deux développeurs après la publication du premier article de The Register. Google a toutefois déclaré à The Register qu’il n’avait pas l’intention de modifier sa politique de reclassement automatique, affirmant qu’il privilégiait la prévention des interruptions de service plutôt que le respect des préférences budgétaires exprimées par les utilisateurs.

Par ailleurs, se pose la question distincte de ce qui se passe lorsqu’un développeur tente de mettre fin à ses activités. The Register a rapporté cette semaine les résultats d’une étude menée par la société de sécurité Aikido, qui a révélé que même les développeurs qui détectent une clé compromise et la suppriment immédiatement ne sont pas forcément à l’abri. Selon les conclusions d’Aikido, les attaquants peuvent apparemment continuer à utiliser cette clé pendant jusqu’à 23 minutes, car la révocation effectuée par Google se propage progressivement à travers son infrastructure. Joseph Leon, chercheur chez Aikido, a déclaré à The Register que pendant ce laps de temps, les taux de réussite sont imprévisibles — certaines minutes, plus de 90 % des requêtes sont encore authentifiées — et que les attaquants peuvent profiter de ce délai pour exfiltrer des fichiers et des données de conversation mises en cache depuis Gemini.

Leon a également noté que les formats d’identifiants plus récents de Google ne semblent pas présenter le même problème : les identifiants API des comptes de service sont révoqués en environ cinq secondes, et le nouveau format de clé de Gemini, préfixé par « AQ », prend environ une minute. « Les deux fonctionnent à l’échelle de Google », a-t-il écrit dans l’article d’Aikido consacré à ce sujet. « Les deux suggèrent que ce problème est techniquement résoluble pour les clés API de Google également. » En bref, selon Leon, cette fenêtre de 23 minutes n’est pas une contrainte technique, mais une question de priorités pour l’entreprise.

Cela mérite d’être pris en compte à la lecture des conseils de de Souza, qui sont pertinents et doivent être pris très au sérieux. Il n’a pas tort, mais il existe actuellement un décalage entre ce que les plateformes préconisent et la rapidité avec laquelle elles s’adaptent elles-mêmes, et il est bon d’en être conscient également.