ИИ Claude Code по ошибке удалил продакшен-базу данных разработчика вместе с резервными копиями

Истории о вышедших из-под контроля AI-агентах всегда привлекают внимание, часто вызывая чувство «злорадства» по отношению к нашим виртуальным помощникам. Однако иногда ошибки происходят из-за недостаточного контроля, как в случае с Алексеем Григорьевым, который подробно описал, как заставил Claude Code уничтожить годы записей на своём веб-сайте, включая резервные снимки (снапшоты) для восстановления.

Всё началось, когда Григорьев захотел перенести свой сайт AI Shipping Labs на AWS и объединить его инфраструктуру с сайтом DataTalks.Club. Сам Claude советовал против этого варианта, но Григорьев счёл, что содержание двух отдельных инфраструктур не стоит хлопот и затрат.

Разработчик использует Terraform — утилиту для управления инфраструктурой, которая может создавать (или уничтожать) целые среды, включая сети, балансировщики нагрузки, базы данных и, естественно, сами серверы. Он поручил Claude запустить Terraform plan для настройки нового сайта, но забыл загрузить критически важный файл state, который содержит полное описание текущей конфигурации.

Claude сделал то, что хотел Григорьев, и создал инфраструктуру для сайта Shipping Labs, однако оператор остановил процесс на полпути. Из-за отсутствия файла состояния были созданы дублирующиеся ресурсы. Григорьев попросил Claude идентифицировать дубликаты, чтобы исправить ситуацию, а затем загрузил файл состояния, полагая, что теперь всё под контролем.

Изображение: Microsoft

К сожалению, на этом этапе Григорьев предположил, что бот продолжит очистку дублирующихся ресурсов и только потом заглянет в файл состояния, чтобы понять, как всё должно быть настроено изначально. Инструменты вроде Terraform могут быть очень безжалостными, особенно в сочетании со слепым послушанием. Поскольку у Claude теперь был файл state, он логически следовал ему, запустив операцию Terraform «destroy» в рамках подготовки к правильной настройке.

Учитывая, что описание инфраструктуры включало сайт DataTalks.Club, это привело к полному удалению конфигурации для обоих сайтов, включая базу данных с записями за 2,5 года и снапшоты базы данных, на которые Григорьев рассчитывал как на резервные копии. Оператору пришлось обратиться в службу поддержки Amazon Business, которая помогла восстановить данные примерно за день.

В своём разборе инцидента Григорьев описывает меры, которые он принимает, чтобы избежать подобных ситуаций в будущем: настройку периодического тестирования восстановления БД, применение защиты от удаления для разрешений Terraform и AWS, а также перемещение файла состояния Terraform в хранилище S3 вместо локальной машины. Он также признал, что «слишком полагался на AI-агента для запуска команд Terraform», и теперь запрещает агенту делать это, вручную проверяя каждый план, который предлагает Claude, чтобы самостоятельно запускать любые разрушительные действия.

Соблазнительно списать эту историю на очередную «ошибку глупого бота», но, скорее всего, большинство системных администраторов заметят фундаментальные проблемы в подходе Григорьева, включая предоставление широких полномочий тому, кто по сути является его подчинённым, а также изначальное отсутствие ограничения прав в производственной среде.

Возможно, главный урок заключается в том, что нельзя предполагать, будто Claude обладает контекстом (каламбур не преднамерен), чтобы понять, что означает существование второго веб-сайта, — точно так же, как не понял бы этого и младший системный администратор.

Источник: Tomshardware.com