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

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

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

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

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

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

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

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

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

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

Требование обязательно для классов 4-бг, 4-дсп, 3-ин, 3-спец, 3-бг, 3-юл и 3-дсп. Для классов 4-ин, 4-спец и 4-юл оно является рекомендуемым.

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

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

Какие конфигурации резервировать

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

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

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

• Маршрутизаторы и L3-коммутаторы. Интерфейсы, маршруты, ACL, VPN и параметры динамической маршрутизации.
• Коммутаторы доступа. VLAN, назначения портов, агрегированные каналы и защита портов.
• Межсетевые экраны. Правила, объекты, NAT, VPN, сертификаты и параметры журналирования.
• Балансировщики и reverse proxy. Виртуальные сервисы, пулы, проверки доступности и TLS-настройки.
• Контроллеры Wi-Fi. Профили сетей, политики доступа, аутентификация и сведения о точках.
• Резервные устройства. Их состояние должно соответствовать рабочей конфигурации основного оборудования.

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

Как организовать резервное копирование конфигураций

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

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

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

• Определить перечень устройств и связать его с реестром активов.
• Выбрать безопасный способ экспорта: API, SSH/SFTP, встроенная система управления.
• Создавать версию после каждого изменения и дополнительно по расписанию.
• Хранить историю, а не только последний файл.
• Ограничить доступ к репозиторию и журналировать операции.
• Контролировать ошибки и отсутствие свежей копии.
• Проверять импорт на резервном либо лабораторном устройстве.

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

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

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

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

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

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

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

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

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

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

• Состав охватываемого телекоммуникационного оборудования;
• Периодичность и события, после которых создаётся копия;
• Формат, место и срок хранения версий;
• Роли по изменению конфигурации, хранению и контролю;
• Защиту паролей, ключей и сертификатов;
• Порядок тестового восстановления и действия при ошибке;
• Актуализацию заданий при вводе, замене и выводе устройств.

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

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

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

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

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

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

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

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

• Пункт 7.5: состав информации для резервного копирования.
• Пункт 7.6: резервное копирование информации.
• Пункт 4.2: замена и модернизация активов.

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

Вывод

Пункт 7.7 требует иметь актуальные и защищённые копии настроек всего значимого сетевого оборудования.

Рабочий процесс объединяет реестр устройств, автоматический экспорт, историю версий, защищённый репозиторий и тестовое восстановление.

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

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

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

• Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 – приложение 3, пункт 7.7. Официальный источник.
• Приказ ОАЦ № 98 от 27.05.2026 изменил отдельные положения приказа № 66, но не изменил строки 7.7–7.13 приложения 3. Официальный источник.

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