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

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

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

Состав определяется по информационным ресурсам и бизнес-процессам, а не только по перечню серверов.

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

Вопрос должен звучать не «какие серверы копировать», а «какая информация потребуется, чтобы после сбоя продолжить работу и подтвердить её целостность».

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

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

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

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

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

Требование связано с пунктом 7.6, но является самостоятельным: сначала определяется объект резервирования, затем обеспечивается копирование.

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

Что включать в состав

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

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

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

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

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

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

Как определить содержание

• владелец информации;
• система-источник;
• формат и место хранения;
• критичность;
• объём и скорость изменения;
• зависимости;
• допустимая потеря данных;
• срок хранения копий;
• порядок проверки восстановления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Пункт 6.4: резервное копирование ВМ.
• Пункт 7.6: резервное копирование информации.
• Пункт 7.7: резервное копирование конфигураций телекоммуникационного оборудования.

Вывод

Пункт 7.5 формирует предмет резервного копирования.

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

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

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

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

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

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

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