Инициативный ИИ
Случай, произошедший со стартапом PocketOS, выглядел бы комичным, если бы не обернулся реальной катастрофой. ИИ-агент Cursor, работавший на базе Claude Opus, за девять секунд уничтожил не только основную базу данных компании, но и все резервные копии. Более 1600 клиентов остались без доступа к своим данным, а восстановление оказалось невозможным: последняя пригодная копия была трёхмесячной давности.
Система не была взломана и не действовала злонамеренно. По словам основателя PocketOS Джера Крейна, агент работал в тестовой среде и столкнулся с проблемой доступа. Вместо того чтобы остановиться, он начал искать решение самостоятельно, обнаружил API-токен в стороннем файле и применил его для выполнения команды. Эта команда уничтожила том данных в инфраструктуре Railway — тот самый, где находилась рабочая система.
Самое показательное в этой истории — не ошибка, а то, что её ничто не остановило. Ни запрос подтверждения, ни проверка окружения, ни предупреждения о риске. Команда была выполнена, а вместе с ней исчезли и резервные копии, потому что они хранились в том же логическом пространстве. Позднее агент «признал» нарушение собственных правил, но это уже не имело значения: данные были утрачены.
Этот случай важен не как экзотический сбой ИИ, а как концентрированное проявление старой проблемы: резервные копии существовали, но не были независимыми.
Примеры из прошлого
Если отмотать назад, становится ясно, что подобные катастрофы происходили задолго до широкого внедрения ИИ. В 2014 году компания Code Spaces прекратила существование после того, как злоумышленник получил доступ к её облачному аккаунту и удалил всю инфраструктуру. Бэкапы не помогли, потому что находились в том же контуре управления и подчинялись тем же правам.
В 2017 году GitLab столкнулся с потерей данных из-за ошибки администратора. Попытка восстановления показала, что резервные копии либо повреждены, либо устарели, либо зависят от той же системы хранения. Инцидент стал публичным уроком: наличие бэкапов не гарантирует восстановления.
В том же году вирус NotPetya разрушил инфраструктуру Maersk. Заражение распространилось по всей сети, и доступные резервные копии оказались затронуты вместе с рабочими системами. Компания смогла восстановиться лишь благодаря единственному офлайн-серверу, который случайно оказался вне зоны поражения.
В 2019 году атака шифровальщика на Travelex: бэкапы существовали, но были доступны из заражённой среды и потому не спасли ситуацию.
Пожар в дата-центрах OVHcloud в 2021 году добавил к этой картине физическое измерение. У части клиентов резервные копии находились в том же дата-центре, что и основные данные. Когда площадка была уничтожена, исчезло всё.
Наконец, пожар в государственном дата-центре Южной Кореи в 2025 году продемонстрировал, что проблема не ограничивается коммерческими компаниями. Система G-Drive оказалась фактически привязана к одной площадке, и при её уничтожении данные восстановить не удалось.
Все эти истории различаются по причинам, но совпадают по сути: резервные копии находились в той же системе — логически, физически или административно — и потому исчезали вместе с основной инфраструктурой.
Выживает то, что вне системы
На этом фоне особенно показателен случай Maersk. Несмотря на масштаб разрушений, компания смогла восстановить систему благодаря одному уцелевшему контроллеру домена, который находился вне заражённой сети. Это не было заранее продуманной стратегией — скорее совпадением, — но именно этот фактор оказался решающим.
Этот пример важен тем, что он показывает: выживает не тот бэкап, который существует, а тот, который недоступен катастрофе, разрушившей остальное. В контексте более современных атак это становится критическим. Получив административный доступ к системе управления, атакующий способен распространить разрушительные команды на десятки тысяч устройств. В такой архитектуре любая резервная копия, доступная из этого контура, автоматически попадает под угрозу.
Именно поэтому восстановление после кибератак определяется не количеством копий, а степенью их изоляции.
Как должна храниться копия
Практический вывод из этих историй состоит в том, что резервное копирование должно рассматриваться как целостная модель, а не как отдельная операция. Ключевым элементом становится геораспределение — не формальное размещение в «облаке», а реальное разделение зон отказа.
Это означает, что данные должны существовать в независимых контурах: в разных дата-центрах, желательно в разных регионах и у разных провайдеров. Доступ к ним не должен осуществляться через те же учётные записи и системы управления, которые используются для основной инфраструктуры. В противном случае компрометация одного контура автоматически распространяется на все остальные.
Не менее важно разорвать синхронность. Репликация в реальном времени удобна, но она переносит не только данные, но и ошибки. Геораспределённая система должна предусматривать задержку и версионирование, позволяющие вернуться к состоянию до инцидента.
И наконец, в такой системе неизбежно существуют копии данных, которые недоступны для автоматических процессов и не могут быть затронуты тем же контуром управления. Именно они остаются последним рубежом защиты, потому что всё, что управляется изнутри системы, в случае компрометации перестаёт быть надёжным.
Почему это произойдёт снова
История PocketOS не является чем-то выходящим за рамки естественного. Она лишь сжала во времени то, что происходило и раньше: система, обладающая достаточными правами, уничтожает данные вместе с их резервными копиями. Разница в том, что теперь это происходит быстрее и без участия человека.
Опыт последних лет — от Code Spaces до OVHcloud — показывает, что катастрофа начинается не в момент удаления данных. Она начинается тогда, когда резервная копия перестаёт быть независимой.
ИИ, атаки или человеческий фактор — лишь триггеры. Причина всегда одна: единая зона разрушения.
И если эта зона не устранена архитектурно, печальный инцидент обязательно произойдёт. Вопрос лишь в том, сколько времени на это потребуется — часы, минуты или девять секунд.
Что скажете?
ссылка на оригинал статьи https://habr.com/ru/articles/1036226/