Incidents associés
On aime tous les histoires de robots agents qui tournent mal, et on éprouve souvent une certaine jubilation à l'égard de nos compagnons virtuels. Cependant, il arrive que ces erreurs soient dues à une supervision insuffisante, comme ce fut le cas pour Alexey Grigorev, qui a eu le courage de raconter en détail comment Claude Code a effacé des années de données sur un site web, y compris les sauvegardes de restauration.
L'histoire commence lorsque Grigorev a voulu migrer son site web, AI Shipping Labs, vers AWS et partager la même infrastructure que DataTalks.Club. Claude lui-même a déconseillé cette option, mais Grigorev a estimé que le coût et les complications liés au maintien de deux environnements distincts ne valaient pas la peine.
Gregory utilise Terraform, un outil de gestion d'infrastructure capable de créer (ou de supprimer) des configurations complètes, incluant réseaux, répartition de charge, bases de données et, bien sûr, les serveurs eux-mêmes. Il a demandé à Claude d'exécuter un plan Terraform pour configurer le nouveau site web, mais a oublié de télécharger un fichier d'état essentiel contenant une description complète de la configuration à un instant donné.
L'article continue ci-dessous
Vous aimerez peut-être
Claude a suivi les instructions de Gregory et a créé une configuration pour le site Shipping Labs. Cependant, l'opérateur a interrompu le processus en cours. En l'absence du fichier d'état, des ressources dupliquées ont été créées. Gregory a demandé à Claude d'identifier ces ressources pour corriger le problème, puis a téléchargé le fichier d'état, pensant avoir résolu la situation.
Malheureusement, Gregory a supposé à ce moment-là que le bot continuerait à supprimer les ressources dupliquées et ne consulterait le fichier d'état qu'ensuite pour vérifier la configuration initiale. Terraform et les outils similaires peuvent être très impitoyables, surtout lorsqu'on les utilise sans réfléchir. Claude étant désormais en possession du fichier d'état, il a logiquement exécuté une opération de destruction Terraform afin de procéder à une restauration correcte.
Étant donné que la description de l'infrastructure incluait le site web DataTalks.Club, cette opération a entraîné la suppression complète de la configuration des deux sites, y compris une base de données contenant 2,5 ans d'enregistrements, ainsi que les instantanés de base de données sur lesquels Grigorev comptait comme sauvegardes. L'opérateur a dû contacter le support technique d'Amazon (https://www.tomshardware.com/tag/amazon), qui a permis de restaurer les données en une journée environ.
Dans son rapport d'analyse, Gregory décrit les mesures qu'il prend pour éviter que de tels incidents ne se reproduisent : mise en place d'un test périodique pour la restauration de la base de données, application de protections contre la suppression aux autorisations Terraform et AWS, et déplacement du fichier d'état Terraform vers un stockage S3 plutôt que sur sa machine locale. Il a également admis avoir « trop compté sur l'agent d'IA pour exécuter les commandes Terraform » et a décidé de le désactiver. Il examinera manuellement chaque plan présenté par Claude afin de pouvoir effectuer lui-même toute action destructive.
Recevez les meilleures actualités et les tests approfondis de Tom's Hardware directement dans votre boîte mail.
On pourrait être tenté de classer cette histoire dans la catégorie des « bots stupides qui ont mal tourné », mais il y a fort à parier que la plupart des administrateurs système auront repéré les problèmes fondamentaux de l'approche de Grigorev, notamment l'octroi de permissions très étendues à ce qui est en réalité un subordonné, ainsi que l'absence de limitation des permissions dans un environnement de production.
La principale leçon à tirer est peut-être qu'il ne fallait pas supposer que Claude ait même le contexte (sans jeu de mots) nécessaire pour comprendre la signification de l'existence du second site web, tout comme un administrateur système junior ne l'aurait pas.