Пункт 7.6 приложения 3 к ПТКЗИ: резервное копирование информации

Смысл требования

Пункт 7.6 приложения 3 к ПТКЗИ – практический разбор требования «резервное копирование данных». Пункт 7.6 требует фактически обеспечить резервное копирование информации, состав которой определён по пункту 7.5.

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

Резервная копия нужна не для зелёного статуса в консоли, а для возврата информации в пригодное состояние после удаления, повреждения, сбоя оборудования или кибератаки.

Копия, которую никто не восстанавливал, остаётся предположением. Поэтому выполнение задания, защита репозитория и тестовое восстановление рассматриваются как части одного процесса.

Формулировка требования

Приложение 3 к Положению о порядке технической и криптографической защиты информации, пункт 7.6: «обеспечение резервного копирования информации».

Нормативная формулировка обычно короче, чем реальный процесс её выполнения. Поэтому при внедрении её следует разложить на понятные действия: определить объект контроля, назначить ответственных, установить технические правила и подготовить доказательства фактической реализации.

Обязательность применения

Требование обязательно для всех классов типовых ИС: 4-ин, 4-спец, 4-бг, 4-юл, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп.

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

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

Процесс резервного копирования

• задания для каждого ресурса;
• периодичность и сроки хранения;
• согласованность данных приложений и СУБД;
• определённый репозиторий;
• защита от чтения, изменения и удаления;
• мониторинг выполнения;
• проверка целостности;
• тестовое восстановление.

Конкретная технология не предписана. Решение должно соответствовать архитектуре ИС и обеспечивать заявленный результат.

Периодичность создания копий и периодичность тестового восстановления – разные параметры. База может копироваться каждые несколько часов, а полноценное восстановление проверяться по утверждённому графику и после существенных изменений.

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

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

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

Копия, реплика и архив

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

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

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

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

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

Что следует подтвердить при проверке

• соответствие заданий перечню 7.5;
• расписание и сроки хранения;
• последние результаты;
• обработку ошибок;
• права доступа к системе и репозиторию;
• защиту от удаления;
• контроль ёмкости;
• результаты тестового восстановления;
• договорные параметры провайдера.

Доказательства должны подтверждать фактическое состояние всей заявленной области, а не единичный пример.

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

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

Результат тестового восстановления должен содержать не только отметку «успешно». Следует фиксировать выбранную копию, длительность, место восстановления, проверенные функции, выявленные ошибки и решение владельца информации о пригодности данных.

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

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

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

Что закрепить в ТЗ, ЛПА и ОРД

• систему и способы копирования;
• периодичность и сроки хранения;
• места хранения;
• мониторинг и эскалацию ошибок;
• роли и полномочия;
• порядок тестового восстановления;
• изменение заданий;
• ответственность поставщика.

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

Такая формулировка остаётся применимой после замены оборудования или программного обеспечения и не требует полностью переписывать ЛПА при каждом техническом обновлении.

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

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

Типичные ошибки

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

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

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

Связанные материалы

• Пункт 7.5: состав информации для резервного копирования.
• Пункт 6.4: резервное копирование ВМ.
• Пункт 2.3: защита резервных копий от НСД.

Вывод

Пункт 7.6 требует устойчивого и проверяемого процесса резервного копирования.

Главное доказательство – подтверждённая возможность восстановить нужную информацию, а не только наличие успешных заданий.

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

Зрелый процесс подтверждает три вещи: нужная информация действительно попадает в копии, копии защищены от общего инцидента, а восстановление регулярно выполняется и укладывается в допустимое время.

Нормативная основа

• Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 7.6. Официальный источник.
• Положение о порядке технической и криптографической защиты информации – требования к ТЗ, ЛПА и эксплуатации. Официальный источник.

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