Нужны ли для рабочих резервных копий отдельные учетные данные?

Резервная копия остается копией для восстановления только в том случае, если инцидент, повредивший рабочую систему, не может заодно стереть и ее. Это кажется очевидным, пока не изучишь учетные данные автоматического задания. Во многих системах один токен читает рабочие данные, записывает резервную копию, показывает старые копии, удаляет их по правилам хранения, меняет назначение и запускает восстановление. Передайте такой токен автономному агенту, и один ошибочный или скомпрометированный вызов API может превратить сбой рабочей системы в невозможность восстановления.

Решение не в том, чтобы написать более крупную и хитрую политику разрешений. Разделите действия над рабочими и резервными данными. Учетные данные, с которыми работает рабочая система, не должны удалять копии восстановления. Учетные данные, создающие резервную копию, не должны менять ее срок хранения. Восстановление должно иметь собственное подтверждение, поскольку оно возвращает чувствительные данные в активную среду. Каждая граница должна заставлять неправильный запрос завершаться ошибкой до того, как он приведет к последствиям.

Это задача проектирования, а не проблема конкретного поставщика. Такой подход работает независимо от того, попадают ли копии в объектное хранилище, управляемое хранилище резервных копий, снимки, физический аппарат или второй облачный аккаунт. Неизменяемость хранилища важна. Раздельное администрирование тоже важно. Но ни то ни другое не поможет, если обычная рабочая личность агента по-прежнему может управлять опасными настройками вокруг резервных копий.

Копия не отделена от рабочей системы, если одна личность может ее стереть

Копия восстановления должна переживать ожидаемые режимы отказа рабочей системы, включая злоупотребление привилегированными учетными данными. Если одна личность агента может вызвать и delete production database, и delete recovery vault, у вас есть дублированные данные, но нет изолированного восстановления.

Команды часто называют это разделением, когда рабочая система и резервные копии используют разные контейнеры, папки, регионы или имена ресурсов. Это схема хранения, а не разделение доступа. Одна личность с широкими правами может пройти через все эти границы за несколько запросов.

Проверка проста: возьмите учетные данные, доступные агенту рабочей системы, и выясните, что они могут сделать без другого человека, другой личности или физически отдельной плоскости управления. Если они позволяют выполнить хотя бы одно из следующих действий, влияние на восстановление слишком велико:

• Безвозвратно удалить точку восстановления или версию объекта.
• Сократить срок хранения, обойти его или снять блокировку.
• Отключить репликацию или перенаправить будущие копии.
• Изменить доступ к шифрованию так, чтобы восстановление завершалось ошибкой.
• Удалить хранилище резервных копий, проект, учетную запись или контейнер.

Проблема в том, что агенту вовсе не обязательно получать прямую инструкцию удалить резервные копии. Модель может выбрать слишком широкую команду очистки. Обертка инструмента может сопоставить безобидно звучащую операцию с опасной конечной точкой. Скомпрометированный репозиторий может убедить агента использовать все уже имеющиеся у него учетные данные. Защита должна работать, когда запрос неправильный, а не только когда подсказка была разумной.

Нужно контролировать два разных радиуса поражения. Первый, это ущерб плоскости данных: агент меняет или удаляет бизнес-данные. Второй, это ущерб плоскости восстановления: агент удаляет копии, отключает путь к ним или делает их расшифровку невозможной. Большинство команд уделяет внимание первому и оставляет второй на той же административной роли.

Обычно такое решение принимают ради удобства. Для очистки по сроку хранения нужны права удалять устаревшие копии, поэтому заданию резервного копирования выдают широкие права на удаление. Для проверки восстановления нужна привилегированная роль, и ее получает та же интеграция. Инженеру нужен один секрет в CI, поэтому роль постепенно набирает все разрешения. Каждый такой компромисс понятен. Вместе они дают обычному автоматизированному процессу власть над последней линией восстановления.

Запись резервной копии и управление ее сроком жизни, это разные задачи

Средству записи резервных копий нужен узкий и предсказуемый путь. Администратору хранения нужны полномочия менять или удалять копии. Оператору восстановления нужно право прочитать выбранную копию и вернуть ее в контролируемую цель. Когда все это считают одной задачей, личность резервного копирования становится опасной.

Полезно разделить действия на четыре класса:

1. Захват читает указанный рабочий источник и создает новый артефакт восстановления.
2. Размещение записывает этот артефакт в одно определенное место с нужными атрибутами хранения.
3. Восстановление читает выбранный артефакт и возвращает его только в разрешенную цель.
4. Администрирование меняет сроки хранения, блокировки, настройки хранилища, репликацию, доступ к шифрованию или правила удаления.

Захват и размещение часто могут выполняться без участия человека. Для восстановления обычно нужно новое подтверждение, поскольку оно может переместить большой объем чувствительной информации в новую рабочую среду. Администрирование должно полностью находиться вне обычного пути агента, за исключением узко определенных и отдельно подтвержденных аварийных процедур.

Не смешивайте очистку с захватом. Автоматическое удаление устаревших копий полезно, но это не значит, что средство записи должно постоянно иметь право безвозвратного удаления. Лучше передать правила жизненного цикла системе восстановления или отдельной роли хранения. Если платформа заставляет средство записи удалять собственные старые копии, ограничьте его права небольшой выделенной областью подготовки. Завершенные копии реплицируйте в защищенное место, где это средство не может их удалить или изменить.

Такое различие помогает заметить знакомую ошибку. Агент базы данных каждый час выполняет экспорт. Его роль может записывать данные в recovery/incoming/, просматривать префикс и удалять старые файлы. Через несколько месяцев команда хранения меняет назначение на recovery/. Ограничение старым префиксом исчезает, и агент получает права на удаление всех актуальных данных восстановления. Задание по-прежнему завершается успешно. Проблема обнаруживается лишь тогда, когда копия кому-то понадобится.

Используйте разные имена, которые выражают намерение прямо в разрешениях. backup-writer, backup-retention-admin и restore-operator понятнее, чем одна роль backup-service. Ясные имена сами по себе доступ не ограничивают, но с ними гораздо труднее формально одобрить сомнительную схему.

Раздельные учетные данные должны вести к разным полномочиям

Создание двух API-ключей для одной широкой административной роли не дает полезного разделения. Раздельные учетные данные имеют смысл только тогда, когда они ведут к полномочиям, которые злоумышленник, неисправный скрипт или агент не могут объединить.

Начните с небольшой карты доступа. Запишите каждый источник, назначение, набор учетных данных и опасную операцию. Укажите облачную учетную запись или подписку, а не только путь в хранилище. Карта должна отвечать на вопросы, которые часто пропускают схемы приложений:

• Какая личность создает копию?
• Какая личность может удалить существующую копию до запланированного срока?
• Какая личность может сократить срок хранения или вызвать его обход?
• Какая личность может изменить репликацию, блокировку хранилища или ключи шифрования, необходимые для восстановления?
• Какая личность может восстановить данные в сеть, имеющую доступ к рабочей системе?

Если на три или более вопроса отвечает одна служебная личность, разделите действия до того, как добавлять новую автоматизацию.

Практический минимальный вариант выглядит так:

Сначала эти личности могут находиться у одного поставщика, но у них должны быть разные роли, учетные данные и пути подтверждения. Более сильное разделение предполагает защищенное назначение в другой учетной записи, которой управляет другая административная группа. Еще более сильный вариант добавляет независимого поставщика удостоверений или среду восстановления, которую администраторы рабочей системы не могут незаметно изменить. Не откладывайте первоначальное разделение в ожидании идеальной структуры учетных записей.

Отдельная учетная запись тоже не поможет, если главный администратор рабочей системы может в любой момент принять роль администратора восстановления. Для небольшой организации без других возможностей это может быть приемлемо, но называйте вещи своими именами: это административное разделение по договоренности. Оно слабее границы, для пересечения которой нужен другой человек, аппаратный фактор или внешнее подтверждение.

Неизменяемость блокирует один вид удаления, но не все сбои восстановления

Неизменяемое хранилище защищает существующие копии от изменения или удаления в течение заданного срока хранения. Оно не доказывает, что новые копии продолжают поступать, что они содержат правильные данные, что ключи шифрования остаются доступными или что оператор сможет их восстановить. Это важный элемент защиты, но на нем нельзя строить весь план восстановления.

Рекомендации CISA StopRansomware советуют хранить резервные копии офлайн и обеспечивать шифрование и неизменяемость резервных данных. Это разумно, потому что злоумышленники часто атакуют системы резервного копирования после получения доступа к рабочей среде. Но рекомендацию не следует понимать как разрешение поместить учетные данные администратора хранилища в ту же автоматизацию, которая управляет приложением.

Amazon S3 Object Lock хорошо показывает разницу. В режиме compliance защищенную версию объекта нельзя перезаписать или удалить ни одному пользователю, включая корневого пользователя учетной записи, до даты окончания хранения. В режиме governance вызывающая сторона с s3:BypassGovernanceRetention может обойти защиту, если явно запросит обход. В документации Amazon также указано, что консоль автоматически добавляет этот заголовок для вызывающей стороны, у которой есть такое разрешение.

Режим governance полезен, особенно пока вы определяете приемлемый срок хранения. Но это не жесткая граница, если учетные данные агента позволяют обойти защиту. Не выдавайте агенту s3:BypassGovernanceRetention только потому, что кто-то хочет, чтобы задание очистки перестало завершаться ошибкой. Исправьте схему жизненного цикла.

Хранение в режиме compliance имеет цену: ошибочный срок может сохранить данные дольше, чем ожидалось, и сократить его уже нельзя. Принимайте это решение осознанно. Определяйте срок по требованиям к восстановлению, юридическим обязанностям, чувствительности данных, стоимости и времени, необходимому для обнаружения вторжения. Скопированная у другой команды общая настройка не заменяет план.

В версионируемом объектном хранилище есть еще одна ловушка. Простой запрос удаления может создать маркер удаления, а не окончательно стереть старую версию объекта. Из-за этого оператор, просматривающий последнюю версию, может решить, что восстановление сломано, хотя защищенная версия все еще существует. В процедуре восстановления нужно описать, как найти и получить нужную версию. Объект, который нельзя удалить, но невозможно найти во время инцидента, защищен лишь частично.

Вынесите опасные операции с резервными копиями за отдельное подтверждение

Обычное создание резервных копий должно быть скучной процедурой. Новому сеансу агента может потребоваться подтверждение для использования учетных данных средства записи, но отдельные вызовы захвата и размещения не должны требовать внимания человека, если они ограничены нужными источником и назначением. Люди быстро привыкают подтверждать повторяющиеся запросы, не читая их.

Опасные или необратимые действия требуют другого подхода. Удаление копии восстановления, сокращение срока хранения, изменение назначения репликации, отключение блокировки хранилища, экспорт материала для расшифровки или восстановление в среду, доступную из рабочей сети, должны останавливаться для нового конкретного подтверждения. В нем нужно простыми словами описать действие, указать учетные данные, цель и последствия.

Плохой запрос на подтверждение: Разрешить операцию резервного копирования?

Полезный запрос: Разрешить backup-retention-admin удалить 14 устаревших точек восстановления из archive-vault? Для копий без неизменяемого хранения это действие нельзя отменить.

Формулировка важна: она позволяет отклонить технически разрешенный, но операционно неправильный запрос. Когда рабочий агент внезапно просит изменить хранилище восстановления, это должно выглядеть странно еще до того, как кто-то начнет разбираться в имени действия IAM.

Подтверждение не заменяет разрешения. Рецензент тоже может одобрить неправильный запрос, особенно в два часа ночи, когда экран уже заполнен сигналами инцидента. Граница разрешений должна сделать опасные действия недоступными обычному средству записи. Подтверждение нужно для меньшего набора действий, которые намеренно оставлены возможными.

Sallyport соответствует этой схеме, когда агенту программирования нужно вызвать API резервного копирования или запустить задачу через SSH: храните учетные данные в хранилище приложения, разрешайте обычному сеансу использовать только учетные данные средства записи, а для учетных данных администрирования восстановления включите подтверждение каждого использования. Агент получает результат действия, но не сам секрет.

Такой подход решает и практическую проблему долгоживущих агентов. Не подтверждайте процесс один раз, предполагая, что все его будущие действия заслуживают такого же доверия. Новый процесс должен создавать собственный сеанс. Чувствительные учетные данные должны требовать отдельного согласия для каждого вызова, даже если процесс уже получил обычный доступ к резервному копированию.

Фрагмент политики должен сделать плохой вызов невозможным

Проверять разрешения проще, если тестировать запрос, который никогда не должен завершаться успешно. Следующий пример показывает роль размещения в стиле S3. Она может записывать новый объект только в назначенный префикс. У нее нет DeleteObject, обхода хранения, прав на политику контейнера и разрешения читать архив обратно.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteNewRecoveryArtifacts",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::recovery-archive-prod/incoming/database/*"
    },
    {
      "Sid": "DenyRecoveryAdministration",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:BypassGovernanceRetention",
        "s3:PutObjectRetention",
        "s3:PutObjectLegalHold",
        "s3:PutBucketPolicy",
        "s3:DeleteBucket"
      ],
      "Resource": "*"
    }
  ]
}

Это пример формы, а не политика, которую можно бездумно вставить в систему. В реальном развертывании могут понадобиться заголовки шифрования, действия для многочастичной загрузки, ограничение контейнера или отдельная роль для службы репликации. Смысл в том, чтобы любой читатель сразу видел: эта личность не может удалить артефакт восстановления.

После каждого изменения разрешений запускайте негативный тест. При активных учетных данных размещения удаление должно завершаться ошибкой, которую можно записать в журнал:

aws s3api delete-object \
  --bucket recovery-archive-prod \
  --key incoming/database/2026-07-22/backup.sql.zst

Здоровый результат выглядит примерно так:

An error occurred (AccessDenied) when calling the DeleteObject operation:
User is not authorized to perform: s3:DeleteObject on resource:
arn:aws:s3:::recovery-archive-prod/incoming/database/2026-07-22/backup.sql.zst

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

Не храните учетные данные администратора хранения рядом с учетными данными средства записи «на случай чрезвычайной ситуации». Именно во время чрезвычайных ситуаций сильнее всего хочется использовать широкие секреты. Держите эти учетные данные в отдельном хранилище и требуйте отдельного пути подтверждения или участия второго оператора.

Восстановление может раскрыть данные, даже если удаление заблокировано

Команды обычно считают восстановление безопасным направлением. Оно безопаснее удаления резервной копии, но все равно остается привилегированным действием. Восстановление клиентской базы в случайной среде разработки может раскрыть рабочие секреты, персональные данные, платежные записи или внутренние токены. Восстановление образа в сеть с подключением к рабочей системе также может занести устаревшие учетные данные и небезопасные службы.

Для восстановления нужны ограничения, соответствующие конкретной системе. Как минимум укажите исходную точку восстановления, целевую учетную запись или проект, целевую сеть и предполагаемую группу доступа. Если платформа поддерживает изолированную песочницу восстановления, используйте ее. Если нет, создайте ограниченную цель с контролем исходящего трафика и маршрутом в рабочую систему, отключенным по умолчанию.

Отдельное подтверждение восстановления нужно еще и потому, что оператору восстановления может понадобиться читать защищенные данные, а средству записи резервных копий этого права быть не должно. Право чтения иногда чувствительнее права записи. Задание экспорта может создавать зашифрованные данные, никогда не видя их в открытом виде. Задание восстановления часто делает эти данные доступными в открытом виде.

Хорошая проверка восстановления отвечает не только на вопрос «завершилась ли команда?». Она проверяет, что:

• Выбранная отметка времени соответствует сценарию инцидента.
• Артефакт можно расшифровать нужной личностью восстановления.
• Приложение запускается с изолированной конфигурацией.
• На месте ожидаемые записи и схема.
• Временная восстановленная среда уничтожается или остается под собственными правилами доступа.

Не проводите проверки только на самой простой вчерашней копии. Выбирайте более старые точки восстановления, разные источники данных и ситуации, где версию объекта или ключ шифрования нужно выбрать осознанно. Именно сложное восстановление показывает, соответствует ли инструкция реальности.

Сбой обычно начинается с безобидного запроса

Представьте агента программирования, у которого есть доступ к рабочей базе данных и CLI облачного поставщика. Он получает просьбу сократить расходы на хранение после того, как тестовая среда накопила старые экспорты. Агент просматривает широкий префикс хранилища, находит крупные объекты и отправляет команду удаления. Инженер хотел очистить файлы тестовой среды. Учетные данные охватывают и тестовую область, и архив, потому что использовать маску было удобнее.

Если в архиве включено обычное версионирование, команда может добавить маркеры удаления и скрыть текущие копии из обычного списка. Если используется хранение governance, а учетные данные включают право обхода, запрос может окончательно удалить версии. Если используется хранение compliance, запрос завершится ошибкой, и именно такого результата вы хотите.

Теперь изменим только схему учетных данных. Агент может использовать учетные данные очистки тестовой среды для тестового пути и учетные данные только для размещения новых записей в архиве. Ни один набор не позволяет просматривать или удалять защищенные объекты восстановления. Запрос завершается ошибкой еще до того, как превращается в инцидент. Администратор восстановления позже отдельно изучит вопрос расходов и решит, нужно ли менять правила жизненного цикла.

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

Храните журналы и разрешенных, и отклоненных действий восстановления. Запись отклоненного действия доказывает, что контроль сработал. Запись разрешенного действия показывает, какой процесс использовал какие учетные данные, к чему он обращался и когда. В Sallyport журнал сеансов и журнал активности дают эти два уровня свидетельств, а sp audit verify может проверить цепочку хешей офлайн без доступа к хранилищу. Это особенно полезно после инцидента: отчет резервного копирования со статусом «успешно» не объяснит подозрительный административный запрос.

Отчеты резервного копирования должны показывать полномочия, а не только успех

Большинство панелей резервного копирования показывают, завершилось ли задание и какой объем данных скопирован. Добавьте второй вид: какая личность внесла изменение, какую операцию она пыталась выполнить и приняла ли ее система. Безопасность восстановления незаметно слабеет, когда все отчеты сводят авторизацию к зеленому или красному значку задания.

Для каждого запуска записывайте идентификатор источника, идентификатор назначения, версию артефакта или идентификатор точки восстановления, класс учетных данных, состояние хранения и результат. Для отклоненного действия записывайте достаточно контекста для расследования, но не секреты и не чувствительное содержимое. По журналу должно быть понятно, чем полная резервная копия отличается от неудачной загрузки, обычное истечение срока хранения от ручного удаления, а заблокированный опасный вызов от отсутствующего разрешения, которое нужно пересмотреть.

Не выдавайте широкий доступ на чтение хранилища восстановления только для того, чтобы агент мог составить подробный отчет. Многие поставщики предлагают конечные точки метаданных, отчеты об инвентаризации или узко ограниченные вызовы состояния. Если агенту нужно читать манифест, создайте отдельный манифест с идентификаторами, контрольными суммами, временем захвата и состоянием хранения, а не каталог клиентских данных.

Полезная еженедельная проверка задает четыре вопроса:

1. Создал ли каждый ожидаемый источник пригодный для восстановления артефакт?
2. Пыталась ли какая-либо личность изменить срок хранения, удалить данные или изменить репликацию?
3. Может ли текущая личность записи обращаться к административным действиям восстановления?
4. Доказала ли проверка восстановления, что выбранная старая копия может изолированно запустить приложение?

Если команда не может ответить на эти вопросы по своим журналам, сначала улучшите журналы. Не считайте схему резервного копирования рабочей только потому, что задания завершаются успешно.

Сначала создайте границу, потом автоматизируйте ее

Начните с учетных данных, которые уже есть у агента или задания CI. Уберите возможность удалять копии восстановления, обходить сроки хранения, менять блокировки и репликацию, изменять настройки хранилища и администрировать учетную запись восстановления. Затем создайте личность размещения, которая может записывать только туда, куда должна. Одно это изменение закрывает распространенный путь от плохой инструкции к необратимому ущербу.

Следом перенесите управление жизненным циклом и сроками хранения на отдельную административную личность. Добавьте неизменяемое хранение на период восстановления, который организация действительно может обосновать. Направьте восстановление в ограниченную среду и требуйте конкретного подтверждения перед тем, как чувствительные данные появятся за пределами обычной рабочей среды. Наконец, проведите проверку, в которой выполняются и ожидаемое резервное копирование, и запрещенное удаление.

Система резервного копирования готова к работе агентов, когда агент может создать копию восстановления, не обладая полномочиями уничтожить ее. До этого автоматизация лишь ускоряет общую ошибку.