Излишне усердный разработчик заставил Claude с помощью Terraform уничтожить свою производственную конфигурацию, включая базу данных и её снимки. — tomshardware.com
Все любят хорошие истории о вышедших из-под контроля ботах-агентах, и в них часто присутствует доля злорадства по отношению к нашим виртуальным помощникам. Однако иногда ошибки можно объяснить ненадлежащим контролем, как в случае с Алексеем Григорьевым, который набрался смелости и подробно рассказал, как он заставил Claude Codeстереть многолетние записи на веб-сайте, включая резервные снимки восстановления. История начинается, когда Григорьев решил перенести свой веб-сайт AI Shipping Labs на AWS и использовать ту же инфраструктуру, что и у DataTalks.Club. Сам Claude советовал отказаться от этого варианта, но Григорьев решил, что не стоит утруждаться или тратиться на поддержание двух отдельных настроек.
Григорий использует Terraform — утилиту для управления инфраструктурой, которая может создавать (или уничтожать) целые конфигурации, включая сети, балансировку нагрузки, базы данных и, естественно, сами серверы. Он попросил Claude выполнить план Terraform для настройки нового веб-сайта, но забыл загрузить жизненно важный файл состояния (state file), который содержит полное описание конфигурации на любой момент времени.
Claude сделал то, что хотел Григорий, и создал конфигурацию для сайта Shipping Labs, однако оператор остановил его на полпути. Из-за отсутствия файла состояния были созданы дублирующиеся ресурсы. Григорий попросил Claude определить дублирующиеся ресурсы для исправления ситуации, а затем загрузил файл состояния, полагая, что он всё уладил.
К сожалению, на тот момент Григорий предположил, что бот продолжит очищать дублирующиеся ресурсы, и только после этого обратится к файлу состояния, чтобы увидеть, как всё должно было быть настроено изначально. Terraform и аналогичные инструменты могут быть очень нетерпимы к ошибкам, особенно в сочетании со слепым подчинением. Поскольку Claude теперь имел файл состояния, он логически последовал ему, выдав операцию Terraform “destroy” (уничтожить) в рамках подготовки к правильной настройке на этот раз.
Учитывая, что описание инфраструктуры включало веб-сайт DataTalks.Club, это привело к полному стиранию конфигурации обоих сайтов, включая базу данных с 2,5 годами записей и снимки базы данных, на которые Григорьев рассчитывал как на резервные копии. Оператору пришлось связаться со службой поддержки Amazon Business, которая помогла восстановить данные примерно через сутки.
В анализе инцидента Григорий описывает несколько мер, которые он принимает для предотвращения подобных случаев в будущем, включая установку тестового периода для восстановления базы данных, применение защит от удаления к разрешениям Terraform и AWS, а также перенос файла состояния Terraform в хранилище S3 вместо локальной машины. Он также признал, что “слишком полагался на AI-агента для выполнения команд Terraform”, и теперь запрещает агенту делать это, а сам будет вручную проверять каждый план, который предлагает Claude, чтобы выполнять любые разрушительные действия самостоятельно.
Заманчиво пометить эту историю как очередную “глупый бот вышел из строя”, но можно предположить, что большинство системных администраторов заметят основные проблемы в подходе Григорьева, включая предоставление широких разрешений тому, кто, по сути, является его подчинённым, а также отсутствие ограничения областью действия разрешений в производственной среде изначально.
Пожалуй, главный урок заключается в предположении, что Claude вообще имел контекст (каламбур нечаянный) для понимания того, что означало существование второго веб-сайта, точно так же, как младший системный администратор не смог бы этого понять.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Bruno Ferreira