Google Cloud et la sécurité IA : entre défis et vulnérabilités

Lors d'un événement récent à Los Angeles, Francis de Souza a pris la parole pour discuter de l'état actuel de la sécurité de l'intelligence artificielle (IA) dans les entreprises. Avec une approche posée, il a affirmé qu'une période de transition est inévitable avant d'atteindre une situation plus stable et sécurisée. Cette transition est également en cours chez Google.

Le message principal de de Souza, qui résonne depuis des années parmi les professionnels de la sécurité, est que la sécurité ne peut pas être une réflexion après coup, surtout avec l'essor de l'IA. Il a insisté sur le fait que les entreprises doivent adopter une approche plateforme dès le début de leur aventure IA. "La sécurité n'est pas quelque chose que vous pouvez ajouter plus tard, et ce n'est pas quelque chose que vous pouvez laisser aux employés faire seuls", a-t-il déclaré.

De Souza a mis en garde contre le phénomène du "shadow AI", où les employés utilisent des outils IA grand public sans supervision adéquate de l'organisation. Il a souligné que les entreprises doivent exiger des plateformes qu'elles offrent sécurité, gouvernance et auditabilité dès le départ. "Il n'existe pas de stratégie IA sans une stratégie de données et une stratégie de sécurité. Elles doivent aller de pair", a-t-il ajouté.

Bien qu'il ait évoqué Google Cloud, de Souza a précisé qu'il ne s'agissait pas uniquement de promouvoir ce service. En réponse à une observation sur la nature promotionnelle de ses conseils, il a expliqué que Google s'engage dans une approche multicloud. Selon lui, même les entreprises qui pensent opérer sur un seul cloud utilisent en réalité des applications SaaS et collaborent avec des partenaires commerciaux qui peuvent utiliser différents clouds. "Il est important que les entreprises aient une posture de sécurité cohérente à travers les clouds, à travers les modèles", a-t-il affirmé.

De Souza a également souligné que le paysage des menaces a évolué de manière si fondamentale que les anciens modèles défensifs sont désormais trop lents. Il a noté que le temps moyen entre une violation initiale et le passage à la prochaine étape d'une attaque est passé de huit heures à seulement 22 secondes. La surface d'attaque s'est également étendue bien au-delà du périmètre réseau traditionnel. "En plus de votre parc habituel, vous avez maintenant des modèles. Vous avez des pipelines de données utilisés pour entraîner les modèles. Vous avez des agents, vous avez des prompts. Tout cela doit être protégé", a-t-il expliqué.

Une menace spécifique que de Souza a signalée concerne les agents circulant dans les systèmes internes d'une entreprise. Ces agents peuvent découvrir des dépôts de données oubliés que personne n'a pris en compte depuis des années. "Beaucoup d'organisations ont 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. Mais les agents errant dans votre entreprise trouveront ces actifs de données et exposeront les données qui s'y trouvent", a-t-il averti.

Pour répondre à ces menaces, de Souza préconise de réagir à la vitesse des machines avec la vitesse des machines. "Nous voyons maintenant l'émergence d'une défense entièrement agentique, native à l'IA, où les organisations peuvent faire fonctionner des agents pour piloter leur défense", a-t-il déclaré. "Au lieu d'avoir une défense dirigée par des humains ou même un humain dans la boucle, vous pouvez maintenant avoir des humains supervisant une défense entièrement agentique." Il a ajouté que cela est devenu une question de leadership, pas seulement une question technologique. "C'est une question de niveau conseil et une question d'équipe exécutive. Ce n'est pas seulement un problème de l'équipe de sécurité."

Cependant, même si l'IA prend en charge une plus grande partie de la charge de travail défensive, les personnes qualifiées pour la superviser se font rares. Les vulnérabilités que l'IA elle-même introduit se multiplient plus rapidement que les équipes de sécurité ne peuvent les traiter. "Nous allons avoir besoin de personnes pour faire face à la bug-pocalypse," a déclaré Lea Kissner, responsable de la sécurité de l'information chez LinkedIn, ajoutant qu'elle ne s'attend pas à ce que l'industrie comprenne la sécurité de l'IA de manière durable à long terme pendant au moins quelques années.

Cela nous ramène aux fournisseurs de plateformes eux-mêmes. The Register a publié une série de rapports au cours des dernières semaines documentant une vague de développeurs de Google Cloud frappés par des factures à cinq chiffres suite à des appels API non autorisés aux modèles Gemini — des services que beaucoup d'entre eux n'avaient jamais utilisés ou activés intentionnellement. Les cas ont suivi un schéma familier : des clés API initialement déployées pour Google Maps, placées publiquement selon les propres instructions de Google, étaient devenues silencieusement capables d'accéder à Gemini après que Google ait élargi leur portée sans clairement divulguer le changement.

Rod Danan, PDG de la plateforme de préparation aux entretiens Prentus, a déclaré que sa facture avait atteint 10 138 $ en environ 30 minutes après que des attaquants aient exploité sa clé API compromise. Isuru Fonseka, un développeur basé à Sydney dont le compte a également été compromis, s'est réveillé avec des frais d'environ 17 000 AUD malgré sa conviction d'avoir mis en place un plafond de dépenses de 250 $.

Ce que ni l'un ni l'autre ne savaient, c'est que les systèmes automatisés de Google avaient mis à niveau leurs niveaux de facturation en fonction de l'historique de compte, élevant leurs plafonds effectifs jusqu'à 100 000 $ sans consentement explicite.

Google a remboursé les deux après que The Register ait publié son rapport initial. Cependant, Google a déclaré à The Register qu'il n'avait pas l'intention de changer sa politique de mise à niveau automatique des niveaux, affirmant qu'il priorise la prévention des pannes de service plutôt que l'application des préférences budgétaires déclarées par les utilisateurs.

Il y a la question distincte de ce qui se passe lorsqu'un développeur essaie de tout arrêter. The Register a rapporté cette semaine des recherches de la société de sécurité Aikido, constatant que même les développeurs qui attrapent une clé compromise et la suppriment immédiatement peuvent ne pas être en sécurité. Selon les résultats d'Aikido, les attaquants peuvent apparemment continuer à utiliser cette clé pendant jusqu'à 23 minutes car la révocation de Google se propage progressivement à travers son infrastructure. Le chercheur d'Aikido, Joseph Leon, a déclaré à The Register que pendant cette fenêtre, les taux de succès sont imprévisibles — dans certaines minutes, plus de 90 % des demandes sont encore authentifiées — et les attaquants peuvent utiliser ce temps pour exfiltrer des fichiers et des données de conversation mises en cache de Gemini.

Leon a également noté que les nouveaux formats de credentials de Google ne semblent pas avoir le même problème : les credentials API de compte de service se révoquent en environ cinq secondes, et le nouveau format de clé préfixé AQ de Gemini prend environ une minute. "Les deux fonctionnent à l'échelle de Google," a-t-il écrit dans le document connexe d'Aikido. "Les deux suggèrent que cela peut être techniquement résolu pour les clés API de Google aussi." En résumé, selon Leon, la fenêtre de 23 minutes n'est pas une contrainte d'ingénierie mais une question de priorités pour l'entreprise.

Cela vaut la peine d'être considéré en lisant les conseils de de Souza, qui sont judicieux et doivent être pris très au sérieux. Il n'a pas tort, mais il existe actuellement un écart entre ce que les plateformes prescrivent et la rapidité avec laquelle elles s'adaptent elles-mêmes, et il est bon d'en être conscient également.