Нормативный источник: пункт 6.4 Приложения 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ).
Смысл требования
Пункт 6.4 приложения 3 к ПТКЗИ – практический разбор требования «резервное копирование ВМ». Пункт 6.4 устанавливает отдельное требование к резервному копированию виртуальных машин. Его предметом является возможность восстановить вычислительный компонент информационной системы вместе с виртуальными дисками, конфигурацией и необходимыми параметрами размещения, а не только сохранить отдельные файлы или записи базы данных.
Виртуальная машина обычно включает операционную систему, прикладное программное обеспечение, настройки сервисов, сетевые интерфейсы и метаданные платформы. Потеря ВМ может привести не только к утрате информации, но и к невозможности быстро восстановить среду её обработки.
Резервное копирование виртуальной машины необходимо рассматривать как восстановление работоспособного сервиса, а не только как сохранение виртуального диска. ВМ зависит от гипервизора, виртуальных сетей, хранилища, каталога пользователей и внешних сервисов. Поэтому следует заранее понимать, какие зависимости входят в копию, а какие восстанавливаются отдельно.
Периодичность определяется допустимой потерей данных. Для вспомогательного сервера может хватить ежедневной копии, но для активно изменяемой базы потребуется более частый механизм, журналы транзакций или совместное использование резервирования ВМ и штатных средств СУБД.
Формулировка требования
Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Дополнительные требования по обеспечению защиты информации в виртуальной инфраструктуре», пункт 6.4: «обеспечение резервного копирования виртуальных машин».
Обязательность применения
Требование является рекомендуемым для классов 4-ин, 4-спец и 4-юл. Для классов 4-бг, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп оно является обязательным.
Поскольку пункт находится в разделе требований к виртуальной инфраструктуре, он применяется при наличии виртуальных машин. Если соответствующая технология отсутствует, это отражается при определении применимости требований в техническом задании.
Резервная копия, снапшот и реплика
Снапшот фиксирует состояние ВМ на определённый момент и обычно зависит от исходного хранилища. Он полезен перед обновлением, но не заменяет резервную копию, размещённую в отдельном репозитории.
- Резервная копия создаётся по установленному заданию, имеет срок хранения и используется для контролируемого восстановления.
- Снапшот остаётся частью виртуальной среды и может быть утрачен вместе с исходным хранилищем.
- Реплика повышает доступность, но может повторить ошибочное удаление или повреждение данных.
- Экспорт ВМ без расписания, контроля целостности и проверки восстановления не образует полноценного процесса резервного копирования.
Допустима комбинация механизмов, но назначение каждого из них должно быть документировано.
Снапшот обычно находится в той же платформе и зависит от того же хранилища. Он удобен перед обновлением, но при отказе массива или компрометации управляющего контура может быть утрачен вместе с исходной ВМ.
Реплика повышает доступность и уменьшает время переключения, однако быстро повторяет логическое удаление, шифрование и часть ошибочных действий администратора. Поэтому реплика не заменяет независимую версионную резервную копию.
Какие ВМ включать в резервное копирование
- ВМ прикладного уровня: web-, application- и интеграционные серверы.
- ВМ с базами данных с учётом штатного способа обеспечения согласованности данных.
- Инфраструктурные ВМ: каталог, DNS, NTP, PKI, шлюзы администрирования и другие критичные сервисы.
- ВМ средств защиты, журналирования и мониторинга, если они входят в контур ИС.
- Сервисные ВМ резервного копирования, автоматизации и управления конфигурациями, когда они критичны для восстановления.
Для каждой машины определяются критичность, периодичность копирования, срок хранения, допустимая потеря данных и последовательность восстановления.
В перечень включаются не только прикладные серверы, но и контроллеры домена, DNS, серверы управления, журналы, системы лицензирования и другие зависимости. Без них восстановленное приложение может запуститься, но оставаться непригодным для эксплуатации.
Для каждой ВМ полезно фиксировать владельца, критичность, место размещения, задание, периодичность, срок хранения и дату последнего теста. Это позволяет обнаружить виртуальную машину, которая существует в кластере, но не охвачена резервным копированием.
Консистентность копий
Образ ВМ может быть технически создан, но оказаться непригодным для корректного восстановления приложения. Особенно это относится к СУБД, каталогам и транзакционным системам.
- Crash-consistent backup фиксирует состояние, сопоставимое с внезапным отключением питания.
- Application-consistent backup учитывает состояние приложения и журналов транзакций.
- Прикладная копия базы данных может дополнять копию ВМ.
- Тестовое восстановление подтверждает пригодность копии лучше, чем один успешный статус задания.
Выбор способа основывается на архитектуре ИС и документации используемых приложений.
Crash-consistent копия соответствует состоянию дисков при аварийном отключении питания. Для части систем этого достаточно, но СУБД и транзакционные приложения могут требовать application-consistent режима с корректной фиксацией журналов и незавершённых операций.
После обновления приложения, гостевого агента или СУБД консистентность следует проверить повторно. Ранее рабочий механизм может перестать корректно взаимодействовать с новой версией программного компонента.
Защита резервных копий
- ограничение доступа к backup-серверу и репозиторию;
- разделение прав на эксплуатацию ВМ и удаление копий, если это позволяет архитектура;
- защита от массового изменения и удаления;
- контроль передачи копий на другую площадку или во внешнее хранилище;
- журналирование создания, удаления и восстановления;
- контроль срока хранения и безопасного удаления устаревших копий.
Копия на том же хранилище и под теми же административными правами, что и продуктивные ВМ, создаёт общую точку отказа.
Учётные данные системы резервирования следует отделять от обычных доменных администраторов. Если одна скомпрометированная запись позволяет удалить продуктивные ВМ и все копии, резервирование не защищает от целевой атаки.
Для критичных ВМ необходима изолированная или неизменяемая копия, а также экземпляр на другой площадке. Это уменьшает вероятность одновременной потери исходной платформы и репозитория при аварии, пожаре или шифровании.
Что следует подтвердить при проверке
- актуальный перечень ВМ и назначенные им backup-политики;
- расписание, сроки хранения и целевые параметры восстановления;
- настройки согласованного копирования для ВМ с СУБД;
- успешные и неуспешные задания и порядок обработки ошибок;
- права доступа к системе резервного копирования и репозиторию;
- результаты проверки целостности и тестового восстановления;
- порядок восстановления ВМ только на разрешённые хосты и сетевые сегменты;
- договорные подтверждения, если услугу выполняет провайдер.
Скриншот одной успешной задачи не подтверждает полноту охвата всех значимых ВМ.
Проверяющему следует показать полный цикл на одной выбранной ВМ: наличие в перечне, задание, последние успешные копии, ошибки, срок хранения и восстановление в изолированной среде.
Результат теста должен содержать выбранную точку, длительность, место восстановления, проверенные функции и решение владельца сервиса о пригодности. Простая отметка «успешно» без прикладной проверки недостаточна.
Что закрепить в ТЗ, ЛПА и ОРД
- состав ВМ либо порядок формирования перечня;
- периодичность, сроки хранения, RPO и RTO или иные установленные параметры;
- требования к консистентности приложений и баз данных;
- места хранения, правила доступа и меры защиты репозиториев;
- порядок контроля заданий и обработки ошибок;
- порядок и периодичность тестового восстановления;
- последовательность восстановления взаимозависимых компонентов;
- ответственность владельца ИС и провайдера.
Типичные ошибки
- снапшоты считаются полноценными резервными копиями;
- часть ВМ отсутствует в заданиях после изменения инфраструктуры;
- копии хранятся только рядом с исходными ВМ;
- ошибки backup-заданий не контролируются;
- восстановление никогда не проверялось;
- ВМ с СУБД копируется без учёта согласованности данных;
- администратор продуктивной среды может удалить все копии без дополнительного контроля;
- в договоре с провайдером не определены параметры услуги.
Связанные материалы
- Пункт 6.3: безопасное перемещение виртуальных машин.
- Пункт 6.5: резервирование сетевого оборудования по схеме N+1.
- Пункты 7.5 и 7.6 приложения 3: состав информации и её резервное копирование.
Вывод
Пункт 6.4 требует доказуемой возможности восстановить виртуальные машины ИС из актуальных и защищённых копий. Для этого необходимо связать перечень ВМ с заданиями, контролировать согласованность данных, защищать репозиторий и проверять восстановление.
Требование выполнено качественно, когда владелец ИС может показать, какие ВМ резервируются, где хранятся копии, кто имеет к ним доступ и каким результатом подтверждена возможность восстановления.
Нормативная основа
- Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 6.4. Официальный источник.
- Положение о порядке технической и криптографической защиты информации – пункты 12 и 15. Официальный источник.