Агенты программирования теперь получают доступ к оболочке реальных систем. Они запускают миграции, очищают каталоги, сбрасывают ветки и удаляют похожие на мусор файлы, обычно именно по вашему поручению. Но появился новый сценарий ошибки, из-за которого резервные копии для ИИ-агентов стали отдельной категорией: доступную агенту копию он может уничтожить, часто при выполнении поставленной задачи.
Это не гипотетический риск ради продажи хранилища. Пользователи, запускающие агентов в рабочей копии, нередко видели нежелательное удаление. Здесь описана устойчивая схема копирования и честно указано, от чего она не защищает.
Почему существующая копия не является резервной для ИИ-агента
Традиционная модель угроз предполагает отказ оборудования, ошибку человека или вымогательское ПО. Агенты пересекают все три категории, поскольку действуют с вашими данными доступа, со скоростью машины и с правдоподобным обоснованием.
Подключённый сетевой диск виден всему, что работает от вашего пользователя. То же относится к синхронизированной папке, сетевому диску и объектному хранилищу, ключи которого находятся в доступном агенту файле окружения. Если агент решит, что каталог содержит старую сборку, репозиторию нужен сброс или требуется освободить диск, всё видимое может попасть в область действий. Затем синхронизация переносит удаление в копию, ведь для этого она и предназначена.
Поэтому резервную копию для ИИ-агента отличает не облачное или локальное размещение, а доступность копии и её учётных данных из среды агента.
Схема резервирования для ИИ-агента: отправка без синхронизации
Этот момент часто реализуют неправильно, поэтому он заслуживает отдельного раздела.
Синхронизация по своей природе двунаправленна. Локальное удаление повторяется удалённо, что полезно для рабочих файлов, но уничтожает архив. Многие системы под названием резервных на деле являются синхронизацией: защищают от отказа диска, но не от удаления. Государственные рекомендации по устойчивости к вымогателям давно указывают на это. CISA рекомендует изолировать копию от защищаемой системы. Агент с оболочкой лишь создаёт новый быстрый способ нарушить условие.
Рабочая копия загружает новые материалы и не отражает удаления. Каталоги с датой или временем заставляют каждый запуск добавлять, а не заменять. Тридцать ежедневных копий дампа базы данных при обычных размерах часто дешевле часа объяснений, почему восстановление невозможно.
Разделение учётных данных решает задачу
Механизм несложен, что для резервных копий хорошо. Нужен путь только для отправки с данными доступа, которых никогда нет у рабочей среды.
Согласно описанным функциям Drive поддерживает привязанные к устройству пароли приложений, создаваемые в панели и отзываемые по одному. Отдельный секрет копирования хранится только на машине или в плановом задании, которое выполняет отправку. Его не должно быть в дереве проекта, общем файле окружения или доступном агенту месте. Агент свободно работает с рабочей копией, но не может аутентифицироваться в месте назначения.
Если задание работает на том же компьютере, храните секрет вне проекта с ограниченными файловыми правами. Отдельное устройство или плановый runner дают более чистую границу без общего файлового пространства. Копия сохраняется не только из-за запрета удаления, а потому что агенту нечего предъявить для входа. Системные и привилегированные доступы следует учитывать отдельно.
От чего резервная копия защищает и не защищает
Точность здесь важнее успокаивающего тона.
Она защищает от удаления или перезаписи файлов в рабочей среде, очистки каталога скриптом, случайного сброса репозитория и обычной человеческой ошибки с неверным путём rm. Она также покрывает случай, когда синхронизация точно повторила нежелательное удаление.
Она не защищает от человека с доступом к панели и вторым фактором, поскольку тот может отозвать пароли приложений и очистить корзину. Она не мешает намеренно удалить архив и не заменяет контроль версий исходного кода, который лучше решает другую задачу.
Резервная копия для ИИ-агента является одним слоем, а не полной программой безопасности. Обратное утверждение было бы преувеличением.
Короткий список для копирования
Он короче ожидаемого, поскольку большая часть рабочего каталога воспроизводима.
- Дампы баз данных. Их действительно нельзя создать заново. Ночные, датированные и хранящиеся столько, сколько разрешают тариф и политика.
- Файлы окружения и конфигурации. Маленькие, редко копируемые и трудные для восстановления. Именно их может удалить автоматическая очистка. Секреты требуют шифрования и ограниченного доступа.
- Загруженные пользователями материалы. Они не находятся под контролем версий, не воспроизводятся и часто замечаются только после пропажи.
- Важные созданные артефакты. Отчёты и экспорты, произведённые процессом, который позднее изменился.
Исходный код обычно здесь не нужен, поскольку правильно настроенный удалённый Git-репозиторий уже является независимой копией. Дополнительная копия не мешает, но это не цель данного слоя.
Как выглядит ночное задание
Реализация намеренно короткая. Чем меньше обслуживания, тем выше вероятность продолжительной работы.
Плановое задание запускается раз за ночь. Оно выгружает базу во временный файл, добавляет дату к имени, загружает в датированный путь на диске и удаляет локальную временную копию. Конфигурация и загрузки идут тем же путём. У задания собственный секрет вне проекта, а в логике работы с назначением совсем нет возможности удаления.
Две детали отличают рабочую схему от незаметно сломанной. Во-первых, путь назначения включает дату, чтобы каждый запуск создавал, а не заменял. Одинаковое имя каждый вечер даёт ровно одну копию за прошлую ночь и не помогает с проблемой, обнаруженной в четверг. Во-вторых, ошибки должны сообщаться явно. Копия, не создававшаяся шесть недель без предупреждения, особенно опасна, поскольку ей доверяли.
Проверка восстановления
Копия, из которой ничего не восстанавливали, остаётся гипотезой. Здесь большинство систем слабее всего.
Раз в квартал восстановите один файл в одноразовой изолированной среде. Проверьте три вещи: файл скачался целиком, он полный и не обрезан после частичного сбоя, процедура известна и задокументирована. Третий пункт важен, поскольку момент аварии не подходит для изучения процесса.
Восстановление также подтверждает, что необходимые пути доступа работают, а секрет не был отозван или изменён без обновления задания. При отсутствии мониторинга путь только для отправки может незаметно перестать работать, хотя всё выглядит нормально.
Как долго хранить данные
Срок хранения определяется объёмом и политикой, а не только техникой. Он обычно нужен дольше, чем сначала предполагают.
Ошибка не всегда заметна сразу. Удаление каталога видно через часы, а небольшое повреждение данных или пропажа ежемесячного файла могут скрываться недели. Тридцать ежедневных копий дают месяц истории и покрывают многие случаи. Для обычных дампов это небольшой объём, но крупные базы требуют расчёта.
Распространённая схема хранит ежедневные копии месяц, затем одну за каждый месяц в течение года. Рост ограничен, но остаётся глубокая история. Удаляйте по отдельному заданию с узкими правами и проверенной политикой. Если загрузчик умеет также удалять, исходный риск возвращается.
Где размещать копию
Drive привязан к почтовому аккаунту, уменьшая число сервисов и счетов. По описанным тарифам дополнение начинается с 250 ГБ за 3.20 $ в месяц, а ползунок доходит до 100 ТБ. Для копий важно и заявленное отсутствие платы за исходящий трафик, но условия тарифа следует проверить до крупного восстановления.
Хранилище можно объединять по аккаунту или ограничивать для отдельных ящиков, отделяя резервное назначение от других потребителей. Загрузка идёт по WebDAV или API, а подключение описано в руководстве WebDAV. Папку можно после проверки прав открыть другому аккаунту, чтобы коллега восстанавливал без ваших данных доступа. Это описано в материале как работают общие ссылки.
Здесь нет ничего экзотического: датированная папка, недоступный рабочей среде секрет и задание, которое только добавляет. Агенты снова сделали старый совет критически важным: спасает та копия, к которой ничто в рабочей среде не может аутентифицироваться.
