Проектирование систем защиты значимых объектов КИИ: от разработки ТЗ до ввода в эксплуатацию по ГОСТ 34

Нормативный фундамент и стадии создания систем защиты КИИ согласно 187-ФЗ и ГОСТ Р 59793

В 2023 году крупная региональная энергетическая компания не прошла проверку ФСТЭК России, несмотря на наличие межсетевых экранов следующего поколения (NGFW) и полностью укомплектованного штата специалистов по информационной безопасности. Причина крылась не в технических уязвимостях, а в отсутствии Технического проекта. Межсетевые экраны были закуплены по стандартному коммерческому брифу, а не на основе ГОСТ-ориентированного Технического задания. С точки зрения регулятора, системы защиты значимого объекта критической информационной инфраструктуры (ЗО КИИ) на предприятии юридически не существовало. В сфере защиты КИИ техническая мера признается легитимной только тогда, когда она спроектирована, обоснована и задокументирована в строгом соответствии с государственными стандартами.

Правовой и инженерный каркас: 187-ФЗ, Приказ №239 и ГОСТ 34

Проектирование системы защиты информации (СЗИ) для значимого объекта КИИ опирается на три уровня нормативных документов. Понимание их иерархии и взаимосвязей — первый шаг к квалифицированному управлению проектом.

Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры РФ» задает верхнеуровневый правовой контекст. Он определяет, что такое объекты КИИ, вводит процедуру категорирования и устанавливает уголовную ответственность (статья 274.1 УК РФ) за нарушение правил эксплуатации средств хранения, обработки или передачи охраняемой компьютерной информации. Закон говорит «что нужно защищать» и «что будет, если этого не сделать», но не дает инженерных инструкций.

Приказ ФСТЭК России от 25.12.2017 № 239 выступает связующим звеном между законом и технической реализацией. Документ содержит исчерпывающий перечень мер защиты (идентификация и аутентификация, управление доступом, регистрация событий безопасности и т.д.), которые обязательны к применению в зависимости от присвоенной категории значимости (первая, вторая или третья). Приказ отвечает на вопрос «какие механизмы безопасности должны быть реализованы».

Комплекс стандартов на автоматизированные системы (ГОСТ 34-й серии) и, в частности, ГОСТ Р 59793-2021, определяет инженерную методологию. Пункт 11 Приказа №239 прямо указывает, что создание СЗИ значимого объекта КИИ осуществляется в соответствии с ГОСТами. Стандарты отвечают на вопрос «как именно спроектировать, задокументировать и внедрить выбранные меры».

!Иерархия нормативной базы КИИ

Важнейший концептуальный нюанс, который часто упускают начинающие проектировщики: система защиты информации не является самостоятельной сущностью, висящей в вакууме. Согласно методологии ГОСТ, СЗИ — это всегда подсистема основной автоматизированной системы (АС), автоматизированной системы управления технологическим процессом (АСУ ТП) или информационной системы (ИС). Нельзя спроектировать защиту токарного станка с ЧПУ, не понимая архитектуры сети самого цеха. Проектная документация на СЗИ разрабатывается либо в составе проекта на создание новой АС, либо как проект модернизации существующей АС в части добавления функций безопасности.

Стадии создания системы по ГОСТ Р 59793-2021

В 2021 году на смену устаревшему, но десятилетиями применявшемуся ГОСТ 34.601-90, пришел ГОСТ Р 59793-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Стадии создания». Он осовременил терминологию, но сохранил фундаментальный принцип: проект должен двигаться от абстрактных бизнес-требований к конкретным техническим настройкам через серию контролируемых стадий.

Стандарт выделяет восемь основных стадий. Рассмотрим их через призму работы Главного инженера проекта (ГИПа), создающего систему защиты для значимого объекта КИИ.

Стадия 1. Формирование требований к АС

На этом этапе происходит осознание проблемы. Для объектов КИИ эта стадия фактически совпадает с процессом категорирования. Комиссия предприятия обследует бизнес-процессы, выявляет критичные системы, оценивает возможный ущерб от кибератак (экономический, социальный, экологический) и присваивает объекту категорию значимости. Результатом становится Акт категорирования и первичное понимание того, от каких угроз предстоит защищаться. Формируется модель угроз и нарушителей (МУиН).

Стадия 2. Разработка концепции АС

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

Стадия 3. Техническое задание (ТЗ)

ТЗ — это конституция проекта. Это единственный документ, имеющий абсолютную юридическую силу при приемке работ. Для систем защиты КИИ разработка ТЗ регламентируется отдельным стандартом ГОСТ 34.602-2020 (это подробнее разберём дальше).

В ТЗ закрепляются требования к архитектуре, функциям СЗИ, видам обеспечения (программному, техническому, организационному), а также перечисляются конкретные меры защиты из Приказа ФСТЭК №239, которые подрядчик обязан реализовать. Ошибка в ТЗ стоит дороже всего: если мера защиты не вписана в ТЗ, подрядчик имеет полное право ее не реализовывать, даже если она требуется по закону.

Стадия 4. Эскизный проект (ЭП)

Эскизный проект — это предварительные архитектурные решения. Документация этой стадии показывает, как в целом будет работать система, без привязки к конкретным вендорам и IP-адресам. Разрабатываются структурные схемы комплекса технических средств, схемы функциональной структуры.

Например, в ЭП фиксируется решение: «Для защиты периметра используется отказоустойчивый кластер межсетевых экранов уровня приложения (NGFW), а для защиты конечных точек — средства антивирусной защиты с централизованным управлением». Конкретные марки оборудования (UserGate, Континент, Kaspersky) здесь могут еще не фигурировать.

Стадия 5. Технический проект (ТП)

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

Если ЭП говорил «нужен кластер NGFW», то ТП говорит: «В стойку 42U в юните 15 и 16 устанавливаются два аппаратных шлюза Модель X, порт eth0 первого шлюза подключается к коммутатору Y патч-кордом категории 6a длиной 2 метра». ТП должен быть настолько подробным, чтобы любая посторонняя монтажная бригада могла по нему закупить нужное железо и собрать инфраструктуру.

Стадия 6. Рабочая документация (РД)

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

Здесь прописываются правила фильтрации (firewall rules), политики паролей (длина, сложность, срок действия), параметры аудита событий.

Стадия 7. Ввод в действие

Стадия физической реализации спроектированного. Включает в себя:

Строительно-монтажные работы (СМР) — установка серверов, прокладка кабелей.

Пусконаладочные работы (ПНР) — установка ПО, применение конфигураций из РД.

Предварительные испытания — проверка работоспособности системы подрядчиком.

Опытная эксплуатация — система работает в реальном времени под наблюдением, выявляются и устраняются «плавающие» ошибки (например, ложные срабатывания системы предотвращения вторжений).

Приемочные испытания — финальный экзамен системы перед комиссией заказчика на полное соответствие Техническому заданию.

Стадия 8. Сопровождение АС

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

!Жизненный цикл создания системы защиты по ГОСТ Р 59793-2021

Принцип воронки детализации: эволюция одного требования

Чтобы понять, почему ГОСТ требует такого количества стадий и документов, необходимо осознать принцип «воронки детализации» (прослеживаемости требований). Ни одно техническое решение не должно появляться из ниоткуда — оно должно быть прямым следствием высокоуровневого требования.

Проследим эволюцию одной меры защиты из Приказа ФСТЭК №239 на примере металлургического комбината. Возьмем меру УПД.1 (Управление учетными записями пользователей).

Закон (187-ФЗ + Приказ 239): Объект имеет 2-ю категорию значимости. Приказ 239 требует обязательной реализации меры УПД.1.

Стадия 1 (Требования): В Модели угроз зафиксирован риск несанкционированного доступа уволенных сотрудников к управлению прокатным станом.

Стадия 3 (ТЗ): В разделе «Требования к функциям СЗИ» появляется пункт: «Система защиты должна обеспечивать централизованное управление учетными записями с возможностью автоматической блокировки УЗ при увольнении сотрудника через интеграцию с кадровой системой».

Стадия 4 (Эскизный проект): В пояснительной записке фиксируется архитектурное решение: «Для реализации УПД.1 внедряется служба каталогов (Active Directory/FreeIPA) и система класса Identity Management (IdM)».

Стадия 5 (Технический проект): В спецификации появляется конкретный сервер для развертывания IdM. В схеме информационных потоков отрисовывается вектор взаимодействия между сервером IdM (IP 10.0.5.10) и сервером кадровой базы (IP 10.0.10.22) по порту 389.

Стадия 6 (Рабочая документация): В «Инструкции администратора» пишется пошаговый алгоритм: «Для настройки синхронизации откройте консоль IdM, перейдите в раздел X, введите строку подключения Y».

Стадия 7 (Ввод в действие): В Программе и методике испытаний (ПМИ) появляется тест-кейс: «Сценарий №14. Завести в тестовой кадровой базе приказ об увольнении Иванова И.И. Ожидаемый результат: учетная запись IvanovII в домене заблокирована в течение 5 минут. Фактический результат: Успешно».

Если убрать любую из этих стадий, цепочка порвется. Без ТП интегратор купит сервер, но не будет знать, куда его подключать. Без РД администратор не сможет настроить интеграцию. Без ПМИ никто не проверит, работает ли функция блокировки на самом деле. ГОСТ 34 — это инструмент предотвращения инженерного хаоса.

Практика управления проектом: объединение стадий

В реальной коммерческой практике жесткое последовательное выполнение всех восьми стадий с выпуском полного комплекта документов для каждой из них встречается редко — это слишком долго и дорого. ГОСТ Р 59793-2021 (как и его предшественник) содержит важнейшую оговорку: допускается объединять стадии и исключать разработку отдельных документов, если это зафиксировано в Техническом задании.

Наиболее частый паттерн в проектах по защите КИИ — создание Технорабочего проекта (ТРП). Это объединение Стадии 5 (Технический проект) и Стадии 6 (Рабочая документация).

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

Когда объединение в ТРП оправдано:

Проект реализуется одним системным интегратором «под ключ» (он сам проектирует, сам закупает, сам настраивает).

Используются типовые, хорошо известные решения (например, стандартное развертывание отечественных средств антивирусной защиты).

Сжатые сроки реализации проекта (до конца финансового года).

Когда объединение стадий недопустимо:

В масштабных проектах (например, внедрение системы защиты на десятках филиалов корпорации), где архитектуру (ТП) разрабатывает один подрядчик (консалтинговое бюро), а физический монтаж и настройку (РД и ПНР) будут выполнять региональные субподрядчики. В этом случае архитектура должна быть жестко зафиксирована, проверена и «заморожена» до начала разработки рабочих инструкций.

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

Также в 90% случаев в проектах по КИИ опускается Стадия 2 (Разработка концепции). Выбор архитектурных подходов переносится в предпроектное обследование и сразу фиксируется в Техническом задании.

Управление стадиями — это управление рисками. Задача ведущего специалиста или ГИПа на этапе старта проекта — грамотно сформировать раздел ТЗ «Стадии и этапы создания», определив тот минимально достаточный набор проектных шагов, который обеспечит прозрачность технических решений для регулятора (ФСТЭК), но не утопит команду в избыточной бюрократии. Документооборот ради документооборота убивает безопасность, но отсутствие прослеживаемой документации делает систему защиты юридически ничтожной. Баланс достигается глубоким пониманием того, какую инженерную задачу решает каждый конкретный артефакт ГОСТа.

Методология контроля качества и приемка проектной документации у внешнего подрядчика

На стол ложатся две тысячи страниц текста, упакованные в пятьдесят PDF-файлов. Внешний интегратор торжественно сдает Технический проект на систему защиты значимого объекта КИИ. Документы выглядят безупречно: строгие рамки по ЕСКД, правильные децимальные номера, логотипы на титульных листах. Заказчик подписывает акты сдачи-приемки. Спустя год, во время инцидента безопасности, дежурная смена открывает «Инструкцию администратора» и обнаруживает там машинный перевод рекламной брошюры вендора, а при попытке восстановить конфигурацию межсетевого экрана выясняется, что IP-адресация на схемах не совпадает с реальной сетью. Проект стоимостью в десятки миллионов рублей превращается в мертвый груз из-за проваленного этапа приемки документации.

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

Трехмерная модель аудита проектной документации

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

Трехмерная модель контроля включает:

Формально-нормативный срез — проверка комплектности и соответствия стандартам оформления.

Семантико-архитектурный срез — проверка технической логики, кросс-документной связности и покрытия требований ТЗ.

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

Рассмотрим каждый уровень детально, вооружившись конкретными методиками поиска дефектов.

Формально-нормативный контроль: отсечение хаоса

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

Базовым инструментом на этом этапе выступает Ведомость проекта (документ с шифром ТП, ЭП или ЭД по ГОСТ 34.201-2020). ГИП должен провести сверку по формуле , где — количество фактически предоставленных файлов, а — количество позиций, заявленных в Ведомости.

На что обращать внимание при формальном контроле:

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

Синхронизация версий. В колонтитулах или на листах утверждения часто остаются следы внутренних правок интегратора (например, «Версия 1.4 draft»). Принимается только финальная мажорная версия.

Наличие обязательных разделов. Проверяется структура ключевых документов (ПЗ, П2, П4) на соответствие требованиям ГОСТ 34.201-2020. Если в Пояснительной записке отсутствует раздел «Описание комплекса технических средств», документ бракуется формально.

Если уровень формального брака превышает допустимый порог (например, не хватает 10% документов из Ведомости), комплект возвращается подрядчику без перехода к следующим этапам проверки.

Семантико-архитектурный контроль: метод сквозной трассировки

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

Для выявления таких дефектов применяется метод «сквозной трассировки» (Traceroute method). ГИП выбирает одну конкретную сущность (информационный поток, сервер, меру защиты) и прослеживает ее путь через весь комплект документации.

Пример применения метода сквозной трассировки

Допустим, в Техническом задании (ТЗ) зафиксировано требование: «Подсистема мониторинга должна обеспечивать сбор событий безопасности с контроллеров домена Active Directory».

ГИП начинает трассировку этой функции по документам Технического проекта:

Документ П2 (Описание автоматизируемых функций): Проверяем, описан ли механизм сбора. Находим: «Сбор событий с ОС Windows осуществляется по протоколу WMI (порт TCP 135 и динамический диапазон TCP 49152-65535)». Логика верна.

Схема структурная комплекса технических средств: Ищем на схеме контроллер домена и сервер SIEM. Видим, что они находятся в разных сегментах сети, разделенных межсетевым экраном (МСЭ) ядра.

Документ П4 (Описание алгоритмов / Правила фильтрации): Открываем таблицу правил МСЭ ядра, чтобы проверить, разрешен ли трафик. Видим правило: Source: SIEM, Destination: DC, Port: TCP 135, Action: Allow.

Фиксация дефекта: ГИП обнаруживает критическую ошибку. В правилах МСЭ открыт только порт инициализации RPC (135), но забыт динамический диапазон (49152-65535), заявленный в документе П2. При внедрении сбор логов не заработает.

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

Поиск скрытых лицензионных ловушек

Вторая задача семантического контроля — сверка архитектурных решений (Пояснительная записка) со Спецификацией (В1). Подрядчик может красочно описать в ПЗ функционал потокового антивируса на веб-прокси или песочницы для проверки файлов. Однако ГИП обязан проверить, заложены ли соответствующие подписки (SKU) в Спецификацию.

Если в ПЗ функционал описан как обязательный, а в Спецификации заложена только базовая лицензия (Base License) без модулей URL-фильтрации и ATP (Advanced Threat Protection), заказчик столкнется с необходимостью экстренно искать бюджет на дозакупку лицензий на этапе внедрения.

Эксплуатационный контроль: синдром «копипасты»

Проектная документация создается не для проверяющих из ФСТЭК, а для инженеров, которые будут эксплуатировать систему ночью в выходной день при аварии. Самая распространенная болезнь Рабочей документации (РД) — это синдром «копипасты», когда подрядчик берет официальное руководство администратора (Admin Guide) от вендора СЗИ, переводит его на русский язык и вставляет в рамки ГОСТ.

Вендорское руководство отвечает на вопрос «Как в принципе можно настроить эту систему?». Эксплуатационная инструкция по проекту обязана отвечать на вопрос «Как именно эта система настроена в нашей конкретной инфраструктуре?».

Рассмотрим разницу на примере инструкции по настройке резервного копирования конфигурации межсетевого экрана.

| Признак | Вендорский Admin Guide (Брак для проекта) | Проектная инструкция (Качественный документ) | | :--- | :--- | :--- | | Параметры сервера | «Укажите IP-адрес вашего FTP/TFTP/SCP сервера в соответствующем поле». | «В поле Server IP укажите адрес корпоративного сервера резервного копирования: 10.50.1.15». | | Учетные данные | «Введите логин и пароль пользователя, имеющего права на запись». | «Укажите сервисную учетную запись svc_fw_backup. Пароль запрашивается в системе Secret Net Studio (ID секрета: 4012)». | | Расписание | «Настройте расписание резервного копирования в зависимости от ваших политик». | «Установите расписание: Ежедневно в 02:00 MSK. Тип копирования: Full». | | Действия при сбое | «Если резервное копирование завершилось с ошибкой, проверьте сетевое подключение». | «При получении алерта о сбое, создайте тикет в Jira на группу NetSec_Ops и проверьте доступность порта TCP 22 от МСЭ до 10.50.1.15». |

ГИП должен безжалостно браковать любые документы с шифром ИЭ (Инструкция по эксплуатации) или ИО (Инструкция по обеспечению), если они содержат вариативность действий без указания конкретных параметров, IP-адресов, имен учетных записей и ссылок на смежные системы заказчика.

Юридическая фиксация дефектов: Журнал замечаний

Найти ошибку — половина дела. Вторая половина — заставить подрядчика ее исправить. Худшая практика приемки — это комментарии в мессенджерах («Там на 15 странице схема поехала») или рецензирование прямо в файле MS Word с помощью инструмента «Исправления». При объеме в тысячи страниц комментарии в Word теряются, подрядчик принимает их выборочно, а доказать факт отправки замечаний юридически невозможно.

Единственный легитимный инструмент ГИПа — Ведомость (Журнал) замечаний. Это официальный табличный документ, который направляется подрядчику сопроводительным письмом.

Каждая запись в Журнале замечаний должна состоять из четырех обязательных элементов:

Локация дефекта: Точное указание документа, страницы, раздела и абзаца.

Суть дефекта: Что именно не так (фактическое состояние).

Нормативное обоснование: Почему это является дефектом (ссылка на пункт ТЗ, ГОСТ, приказ ФСТЭК или законы логики). Без обоснования замечание превращается во вкусовщину, которую подрядчик вправе отклонить.

Требуемое действие: Что конкретно должен сделать подрядчик для устранения.

> Пример идеальной формулировки замечания: > Локация: Документ АБВГ.465614.001-01 34 01 (ПЗ), стр. 45, раздел 3.2. > Дефект: В качестве средства защиты от НСД для серверов СУБД на базе ОС Oracle Linux 8 предложено средство X. > Обоснование: Согласно п. 4.1.2 Технического задания, все применяемые СЗИ должны иметь действующий сертификат ФСТЭК. На сайте ФСТЭК в реестре сертифицированных СЗИ средство X имеет сертификат только для ОС семейств Windows и РЕД ОС. Использование данного СЗИ на Oracle Linux 8 нарушает требование ТЗ. > Требуемое действие: Заменить средство X на альтернативное СЗИ от НСД, имеющее сертификат ФСТЭК для ОС Oracle Linux 8. Скорректировать Спецификацию (В1) и схемы подключений.

Классификация замечаний и критерии приемки

Для управления процессом доработки ГИП может вводить веса дефектов:

Критичные () — архитектурные ошибки, невыполнение требований ТЗ, отсутствие сертификатов ФСТЭК, нехватка лицензий в спецификации, неработоспособные схемы маршрутизации.

Средние () — отсутствие конкретики в инструкциях, несовпадение IP-адресов между схемой и таблицей, неполное описание алгоритмов.

Минорные () — опечатки, съехавшее форматирование, ошибки в нумерации страниц, не влияющие на технический смысл.

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

Управление изменениями при устранении замечаний (Эффект Гидры)

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

Если ГИП потребовал заменить модель межсетевого экрана из-за снятия ее с производства (End-of-Sale), недостаточно проверить только обновленную Спецификацию. Необходимо провести регрессионный контроль документации. Замена аппаратной платформы МСЭ влечет за собой:

Изменение токопотребления и тепловыделения (влияет на требования к инженерным системам в ПЗ).

Изменение количества юнитов в стойке (влияет на чертежи размещения оборудования).

Изменение интерфейсов — например, вместо медных RJ-45 появились оптические SFP+ (влияет на схемы кабельных соединений и спецификацию на трансиверы).

Изменение синтаксиса команд (влияет на эксплуатационные инструкции).

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

Комплектность и правила оформления проектных документов по ГОСТ 34.201-2020

В 2023 году крупный металлургический комбинат подал во ФСТЭК России пакет документов на создание системы защиты значимого объекта КИИ (АСУ ТП плавильного цеха). Технические решения были безупречны: резервированные межсетевые экраны, строгая сегментация, отечественные средства криптографической защиты. Однако регулятор вернул проект на доработку без рассмотрения технической сути. Причина крылась в формальной плоскости: подрядчик сдал «Технический проект» в виде одного текстового файла на 500 страниц, проигнорировав номенклатуру, шифры и комплектность, требуемые государственными стандартами. В мире защиты критической информационной инфраструктуры форма документа так же важна, как и его содержание, поскольку именно стандартизированная форма обеспечивает проверяемость, прослеживаемость и юридическую значимость принятых решений.

Архитектура комплекта документов: от меню к конкретике

ГОСТ 34.201-2020 «Виды, комплектность и обозначение документов при создании автоматизированных систем» — это главный навигатор по проектной документации. Его центральная часть — таблица 2, представляющая собой матрицу, где по вертикали перечислены возможные виды документов, а по горизонтали — стадии создания системы, на которых эти документы разрабатываются.

Стандарт оперирует тремя уровнями обязательности документов:

О — документ обязателен к разработке.

Р — документ рекомендуется (решение принимает разработчик совместно с заказчиком).

Д — документ допускается (разрабатывается при специфических условиях).

В контексте систем защиты КИИ статус документов часто меняется под давлением профильных нормативных актов. Приказ ФСТЭК №239 устанавливает жесткие требования к документированию мер защиты. Если ГОСТ 34.201-2020 помечает документ «Описание алгоритма (проектной процедуры)» индексом «Р», то для реализации меры защиты УПД.2 (Управление правилами разграничения доступа) этот документ фактически становится обязательным («О»), так как без него невозможно доказать регулятору, по какой логике настроены списки контроля доступа (ACL) на маршрутизаторах.

Распространенная ошибка: «Технический проект» как один документ

Новички в проектировании часто путают стадию проектирования и сам документ. Подрядчик может сказать: «Мы пришлем вам Технический проект в пятницу». В реальности Технический проект — это не один файл, а комплект, который, согласно ГОСТ 34.201-2020, может включать до двадцати различных документов.

Базовый минимум стадии Технического проекта для подсистемы ИБ включает:

Ведомость технического проекта (ТП) — оглавление всего комплекта.

Пояснительная записка к техническому проекту (ПЗ) — общее описание архитектуры, обоснование выбора средств защиты информации (СЗИ) и расчеты.

Схема структурная комплекса технических средств (С1) — топология сети с указанием мест установки СЗИ.

Описание комплекса технических средств (П1) — характеристики серверов, межсетевых экранов, датчиков.

Описание автоматизируемых функций (П2) — детальное описание того, как именно подсистема ИБ реализует требования Приказа №239 (например, как работает антивирусная защита, как собираются события безопасности).

Дешифровка децимального номера

Каждый документ в системе ГОСТ 34 должен иметь уникальный идентификатор — децимальный номер (обозначение). Это не просто порядковый номер, а структурированный код, который позволяет мгновенно понять происхождение, суть и версию документа, не открывая его.

Обозначение строится по строгой формуле.

!Структура децимального номера проектного документа

Разберем составные части на примере реального шифра: АБВГ.465614.001-01 34 01

Код организации-разработчика (АБВГ). Четырехбуквенный код, который присваивается организации при регистрации в кодификаторе предприятий. Если проект делает внутренний ИТ-отдел, допускается использовать условный код, зафиксированный в приказе по предприятию.

Код классификационной характеристики (465614). Шестизначное число, определяемое по Общероссийскому классификатору продукции (ОКПД2) или классификатору ЕСКД. Для программных средств и информационных систем часто используются коды группы 50 (например, 501400) или специфические коды для комплексов технических средств.

Порядковый регистрационный номер (001). Трехзначное число от 001 до 999. Присваивается конкретной системе или подсистеме. Если мы проектируем подсистему ИБ для АСУ ТП, ей присваивается номер 001, а системе резервного копирования — 002.

Номер редакции документа (-01). Две цифры после дефиса. Первая редакция обычно не нумеруется (дефис отсутствует), вторая обозначается как -01, третья как -02 и так далее. Это критически важно для управления изменениями.

Код вида документа (34 01). Самая важная смысловая часть. Двухзначный код части (обычно 34 для АС) и код самого документа.

Коды видов документов — это алфавит проектировщика. Их необходимо знать наизусть:

ПЗ — Пояснительная записка.

ТП — Ведомость технического проекта.

ЭД — Ведомость эксплуатационных документов.

П2 — Описание автоматизируемых функций.

П3 — Описание постановки задачи.

В4 — Чертеж формы документа (видеограммы). В ИБ используется для описания дашбордов SIEM-систем или форм отчетов об инцидентах.

ПМ — Программа и методика испытаний (критически важный документ для сдачи системы).

Ведомость: паспорт и юридический щит проекта

Среди всего многообразия документов выделяются два: Ведомость технического проекта (код ТП) и Ведомость эксплуатационных документов (код ЭД).

Ведомость — это не просто оглавление. Это юридически значимый перечень всего, что подрядчик передает заказчику. Если документа нет в Ведомости, с точки зрения приемки он не существует. Если подрядчик разработал великолепную «Инструкцию администратора безопасности», но забыл включить ее в Ведомость ЭД, заказчик имеет полное право заявить, что комплект документации передан не полностью, и заблокировать оплату этапа.

В Ведомости указываются:

Наименование документа.

Его децимальное обозначение.

Количество листов.

Количество экземпляров (для бумажных копий) или формат файла (для электронных).

При проверках ФСТЭК инспектор первым делом запрашивает Ведомость. Сверив перечень документов с требованиями технического задания, он сразу видит «дыры» в проектировании. Например, если в ТЗ указано требование по криптографической защите каналов связи (мера ЗИС.3), инспектор будет искать в Ведомости документ с кодом П4 (Описание алгоритма), где описаны схемы маршрутизации и настройки IPsec-туннелей.

Интеграция требований ФСТЭК в структуру ГОСТ 34.201

Сложность проектирования систем защиты КИИ заключается в том, что Приказ №239 требует создания специфических организационно-технических документов, названия которых напрямую не бьются с таблицей 2 ГОСТ 34.201-2020. Задача проектировщика — грамотно «приземлить» сущности ИБ на классические виды документов АС.

Рассмотрим типичные примеры такого маппинга:

| Требование / Сущность ИБ (Приказ ФСТЭК №239) | Целевой документ по ГОСТ 34.201-2020 | Пояснение | | :--- | :--- | :--- | | Матрица доступа (кто куда имеет право ходить) | П3 (Описание постановки задачи) или приложение к П2 | Описывает логику разграничения прав до реализации в конкретном ПО. | | Правила фильтрации межсетевого экрана | П4 (Описание алгоритма) | Детальный синтаксис правил (Source, Destination, Port, Action), реализующий матрицу доступа. | | Политика парольной защиты | И3 (Инструкция по формированию и ведению БД) или отдельный ОРД | Правила создания, смены и хранения учетных данных. | | План реагирования на инциденты ИБ | И1 (Инструкция по эксплуатации) | Пошаговый алгоритм действий дежурной смены при обнаружении атаки. | | Спецификация закупаемых лицензий и СЗИ | В1 (Спецификация оборудования) | Перечень аппаратных и программных средств с артикулами (Part Numbers) для закупки. |

Если попытаться сдать регулятору документ с названием «Матрица доступа.xlsx» без присвоения ему децимального номера и привязки к коду П3 или П2, это будет расценено как нарушение порядка создания АС. Любой артефакт должен быть обернут в оболочку ГОСТ.

Правила оформления: ЕСКД и ГОСТ 2.105

Наличие правильного комплекта документов — это половина успеха. Вторая половина — их корректное визуальное и структурное оформление. Текстовые документы автоматизированных систем оформляются по правилам Единой системы конструкторской документации (ЕСКД), а именно по ГОСТ 2.105-2019 «Общие требования к текстовым документам» и ГОСТ 2.104-2006 «Основные надписи».

Для ИТ-специалистов, привыкших писать документацию в свободной форме в корпоративных wiki-системах, требования ЕСКД часто становятся шоком. Однако в государственном секторе и на объектах КИИ эти требования непреложны.

Рамки, штампы и основные надписи

Каждый лист проектного документа должен иметь рамку и основную надпись (в просторечии — «штамп»).

!Пример оформления титульного листа и рамки по ГОСТ

На первом листе документа (сразу после титульного) располагается большая основная надпись по форме 2 (ГОСТ 2.104). В ней указываются:

Децимальное обозначение документа.

Наименование документа.

Стадия разработки (например, литера «Т» для технического проекта).

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

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

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

Титульный лист vs Лист утверждения

Еще одна точка преткновения — разница между титульным листом (ТЛ) и листом утверждения (ЛУ).

Титульный лист является первым листом самого документа. На нем указываются грифы секретности или конфиденциальности (например, «Коммерческая тайна»), наименование организации, децимальный номер и название документа. На титульном листе ставятся подписи авторов и руководителей организации-разработчика.

Лист утверждения (ЛУ) — это отдельный документ, который выпускается на один текстовый документ или на комплект документов. Его главная задача — собрать согласующие подписи со стороны Заказчика и других заинтересованных ведомств. Если проектная документация на систему защиты КИИ согласовывается с ФСБ (в случае использования криптографии высокого класса), штампы согласования ставятся именно на Листе утверждения.

Децимальный номер Листа утверждения формируется добавлением кода «-ЛУ» к номеру основного документа (например, АБВГ.465614.001-01 34 01-ЛУ). В современных реалиях электронного документооборота ГОСТ допускает не выпускать отдельный ЛУ, если все подписи собираются в электронной системе и подтверждаются ЭЦП, однако при сдаче проектов в государственные органы бумажные ЛУ с «синими» печатями все еще остаются стандартом де-факто.

Структурирование текста

ГОСТ 2.105 жестко регламентирует подачу материала:

Разделы должны иметь порядковые номера (1, 2, 3).

Подразделы нумеруются в пределах раздела (1.1, 1.2).

Пункты — в пределах подраздела (1.1.1, 1.1.2).

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

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

Особое внимание уделяется ссылкам. Нельзя написать «настроить межсетевой экран согласно инструкции производителя». Ссылка должна быть точной: «настройка правил фильтрации осуществляется в соответствии с п. 4.2 документа Руководство администратора АБВГ.465614.050 И1». Это формирует ту самую прослеживаемость, без которой невозможно провести качественные испытания системы.

Проектирование систем защиты — это инженерная дисциплина, где качество технического решения неотделимо от качества его документирования. Строгое следование ГОСТ 34.201-2020 и правилам ЕСКД трансформирует набор разрозненных идей, скриптов и схем в отчуждаемый продукт. Правильно закодированный, укомплектованный и оформленный проект позволяет любому квалифицированному инженеру, не участвовавшему в первоначальной разработке, развернуть, настроить и безопасно эксплуатировать систему защиты КИИ на протяжении всего ее жизненного цикла, а самой организации — уверенно проходить аудиты регуляторов.

Разработка ТЗ и ЧТЗ на подсистему безопасности по ГОСТ 34.602-2020 и приказу ФСТЭК №239

В 2021 году крупный региональный водоканал выделил 45 миллионов рублей на создание системы защиты своей критической информационной инфраструктуры (КИИ). Подрядчик честно поставил межсетевые экраны, внедрил систему сбора событий (SIEM) и установил антивирусы. Проект закрыли, акты подписали. Через полгода пришла проверка ФСТЭК России и выявила, что SIEM-система не собирает логи с устаревших контроллеров АСУ ТП, управляющих задвижками, так как они работают по проприетарному протоколу. Заказчик попытался предъявить претензии интегратору, но юристы подрядчика открыли Техническое задание (ТЗ) и указали на пункт: «Система должна обеспечивать централизованный сбор событий безопасности». Система его обеспечивает? Да. Требование интеграции со специфическими промышленными контроллерами в ТЗ было? Нет. Заказчику пришлось закупать дополнительные коннекторы за свой счет и выплачивать штраф.

Техническое задание — это не просто формальная бумага для запуска закупки. Это единственный юридически значимый инструмент, который защищает заказчика от получения неработающей системы, а подрядчика — от бесконечных «хотелок» заказчика, не оговоренных на старте.

Разделяй и властвуй: место ЧТЗ в архитектуре проекта

В терминологии ГОСТ 34-й серии существует строгая иерархия систем. Главным объектом проектирования всегда является Автоматизированная система (АС) — то есть бизнес-система или технологическая система, которая выполняет полезную работу. Это может быть ERP-система предприятия, биллинг оператора связи или АСУ ТП электростанции.

Система защиты информации (СЗИ) крайне редко существует в вакууме. Почти всегда она является подсистемой в составе основной АС. Из этого архитектурного факта вытекает важнейшее правило оформления документов.

Если объект КИИ создается с нуля или проходит глубокую модернизацию, разрабатывается единое Техническое задание (ТЗ) на всю АС. В этом ТЗ выделяется отдельный раздел (обычно 4.1.11 по ГОСТ 34.602-2020), где описываются требования к защите. Однако на практике требования по безопасности настолько объемны (особенно с учетом приказа ФСТЭК №239), что они перегружают основной документ.

Поэтому применяется механизм Частного технического задания (ЧТЗ).

!Иерархия ТЗ и ЧТЗ в проекте

ЧТЗ разрабатывается исключительно на подсистему информационной безопасности. Оно юридически подчиняется основному ТЗ на АС и детализирует его. Если же основная АС давно существует и работает, а мы лишь «навешиваем» на нее систему защиты (что типично для большинства проектов по 187-ФЗ), то СЗИ условно принимается за самостоятельную систему, и на нее пишется полноценное ТЗ.

Анатомия ГОСТ 34.602-2020: от бюрократии к инженерии

ГОСТ 34.602-2020 задает жесткую структуру разделов. Проблема большинства специалистов по ИБ заключается в том, что они пытаются механически скопировать текст приказа ФСТЭК №239 в разделы ГОСТа. Это приводит к созданию нежизнеспособных документов. Рассмотрим ключевые разделы стандарта и то, как их нужно заполнять в реальности.

Раздел 1. Общие сведения

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

Акт категорирования объекта КИИ (с указанием присвоенной категории значимости: первой, второй или третьей).

Модель угроз безопасности информации (МУБИ), утвержденную заказчиком.

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

Раздел 2. Назначение и цели создания

Цель создания СЗИ КИИ — это не «установка антивируса». Цель всегда формулируется через бизнес-риски и законодательство: «Обеспечение непрерывности выполнения критических процессов (указать каких именно) путем нейтрализации актуальных угроз безопасности, а также выполнение требований приказа ФСТЭК России от 25.12.2017 №239 для значимого объекта КИИ 2-й категории».

Раздел 4. Требования к системе

Это сердце документа. Ошибка на этом этапе стоит миллионов рублей. Раздел делится на три важнейших подраздела.

4.1. Требования к системе в целом. Здесь описывается архитектура. Именно тут нужно указать, что система защиты не должна «положить» технологический процесс. Формулировки должны быть измеримыми: > «Установка агентов средств защиты на рабочие станции операторов АСУ ТП не должна приводить к утилизации центрального процессора более чем на в штатном режиме работы».

Здесь же описываются требования к интеграции. Если СЗИ должна брать данные о пользователях из корпоративного Active Directory, это пишется в пункте 4.1.

4.2. Требования к функциям (задачам). Это место для трансляции мер ФСТЭК. 4.3. Требования к видам обеспечения. Здесь мы требуем конкретное аппаратное обеспечение, совместимость с операционными системами (программное обеспечение) и квалификацию администраторов (организационное обеспечение).

Искусство трансляции: язык ФСТЭК vs язык инженера

Приказ ФСТЭК №239 написан нормативным языком. Он говорит, что должно быть сделано, но не говорит, как и чем. Инженер в ТЗ должен перевести это требование в проверяемые технические параметры.

Рассмотрим процесс трансляции на примере меры ЗИС.3 (Обеспечение защиты информации в виртуальной инфраструктуре).

Допустим, наша АС развернута на кластере VMware. Если в ТЗ (раздел 4.2) написать: «Система должна обеспечивать реализацию меры ЗИС.3», подрядчик может просто включить встроенные логи гипервизора и сказать, что мера выполнена. Чтобы получить реальную защиту, ГИП должен декомпозировать меру на инженерные требования.

| Текст приказа №239 (Мера ЗИС.3) | Инженерная трансляция в ТЗ (Раздел 4.2 ГОСТ 34.602-2020) | | :--- | :--- | | Идентификация и аутентификация субъектов доступа и объектов доступа в виртуальной инфраструктуре | Подсистема защиты виртуализации должна интегрироваться с существующим сервером RADIUS заказчика для аутентификации администраторов гипервизора. | | Управление доступом субъектов к объектам в виртуальной инфраструктуре | Подсистема должна обеспечивать микросегментацию сети на уровне гипервизора (vNIC) с возможностью создания правил фильтрации между виртуальными машинами внутри одного хоста. | | Регистрация событий безопасности в виртуальной инфраструктуре | Подсистема должна фиксировать события создания, удаления, миграции (vMotion) и изменения конфигурации виртуальных машин с передачей логов по протоколу Syslog в ядро SIEM-системы. |

Обратите внимание: в правой колонке появились термины «RADIUS», «микросегментация», «vNIC», «Syslog». Мы не называем конкретного вендора (это запрещено антимонопольным законодательством на этапе ТЗ, если нет специального обоснования), но мы задаем жесткие технологические рамки. Подрядчик уже не сможет поставить дешевое решение, не умеющее фильтровать трафик внутри хоста виртуализации.

Ловушки формулировок и правило проверяемости

Главный враг качественного ТЗ — качественные прилагательные и наречия. Слова «быстрый», «надежный», «современный», «удобный», «по возможности» должны быть безжалостно удалены из текста.

В инженерии существует Правило проверяемости: Если для требования нельзя написать однозначный сценарий тестирования (тест-кейс), это требование не имеет права находиться в ТЗ.

Пример из практики: Требование в исходном проекте ТЗ: «Система защиты должна обладать высокой отказоустойчивостью и быстро восстанавливаться после сбоев». Как это проверить на испытаниях? Выдернуть шнур питания. Система восстановилась через 4 часа. Подрядчик говорит: «Для такого класса систем 4 часа — это очень быстро». Заказчик считает, что быстро — это 5 минут. Спор переходит в суд, где заказчик проигрывает, так как критерий не был зафиксирован.

Корректная формулировка (с использованием метрик RTO/RPO): «Архитектура подсистемы управления средствами защиты должна исключать единую точку отказа (SPOF). Время восстановления доступности консоли управления (RTO) при выходе из строя основного узла не должно превышать минут. Допустимая потеря событий безопасности (RPO) в момент переключения на резервный узел составляет (потеря событий не допускается, требуется буферизация на агентах)».

Такое требование элементарно проверяется на приемочных испытаниях: имитируется авария, включается секундомер, проверяется счетчик логов до и после.

Требования к документированию и приемке

Раздел 5 ГОСТ 34.602-2020 «Требования к документированию» часто заполняют отпиской: «Подрядчик должен разработать документацию по ГОСТ 34». Это фатальная ошибка.

ГОСТ 34.201-2020 содержит десятки видов документов. Если вы не укажете конкретный перечень, подрядчик сделает минимальный набор, с которым вам потом будет невозможно эксплуатировать систему. В ТЗ необходимо прямо перечислить децимальные коды и названия документов, которые вы ждете на выходе.

Минимальный жизнеспособный набор для СЗИ КИИ, который нужно зафиксировать в ТЗ:

Ведомость технического проекта (ТП)

Пояснительная записка (ПЗ) — здесь будет обоснование выбора наложенных средств защиты.

Схема структурная комплекса технических средств (С1) — архитектура.

Руководство администратора (И3) — без него ваши сотрудники не смогут управлять системой.

Программа и методика испытаний (ПМ) — правила приемки.

Раздел 7 «Порядок контроля и приемки» тесно связан с ПМ. Здесь ГИП должен заложить этапы испытаний. Для КИИ критически важно прописать проведение предварительных испытаний на тестовом стенде (или в ограниченном сегменте) до начала опытной эксплуатации. Нельзя ставить новые межсетевые экраны в разрыв промышленного трафика без этапа опытной эксплуатации, который должен длиться не менее 1-2 месяцев. В ТЗ прямо указывается: «Переход к приемочным испытаниям допускается только после завершения опытной эксплуатации продолжительностью не менее 30 календарных дней и устранения всех замечаний, зафиксированных в Журнале опытной эксплуатации».

Чек-лист проверки готового ТЗ/ЧТЗ

Когда подрядчик (или ваш подчиненный) приносит проект ТЗ на согласование, используйте следующий фильтр:

След Модели угроз: Каждая актуальная угроза из МУБИ должна иметь зеркальное отражение в виде функционального требования в разделе 4.2.

След Приказа №239: Все базовые меры для вашей категории КИИ (плюс адаптированные меры) переведены в инженерные термины интеграции, протоколов и пропускной способности.

Ограничения среды: В разделе 4.1 четко прописаны ограничения по нагрузке на сеть, CPU, RAM защищаемых узлов.

Отсутствие «воды»: В тексте нет слов «гибкий», «масштабируемый» без указания конкретных пределов (например, «масштабируемый до узлов без замены аппаратной платформы управления»).

Матрица доступа: Зафиксировано требование разработать ролевую модель доступа к самой СЗИ (администратор, аудитор, офицер безопасности).

Техническое задание — это чертеж будущего фундамента. Чем точнее в нем прописаны допуски, интерфейсы взаимодействия с существующим ИТ-ландшафтом и критерии успешности, тем меньше пространства для манипуляций остается на этапе внедрения. Глубокая проработка ЧТЗ на старте экономит месяцы разбирательств на этапе ввода значимого объекта КИИ в эксплуатацию.

Проектирование подсистемы ИБ: Стадия Эскизного проекта и обоснование выбора мер защиты

В 2023 году крупная генерирующая компания закупила партию межсетевых экранов нового поколения (NGFW) на сумму более 30 миллионов рублей для защиты сегмента АСУ ТП. Оборудование было приобретено сразу после утверждения Технического задания, минуя этап концептуального проектирования. На этапе пусконаладки выяснилось, что контроллеры турбин обмениваются данными по проприетарному протоколу второго уровня (L2), который закупленные NGFW воспринимали как аномалию и блокировали на аппаратном уровне. Попытка отключить инспекцию привела к тому, что дорогие устройства превратились в обычные коммутаторы. Проект был заморожен, а бюджет признан неэффективно израсходованным. Эта ситуация — классическое следствие пропуска стадии Эскизного проекта, где архитектурные гипотезы должны проверяться на жизнеспособность до выбора конкретных вендоров.

Архитектурная песочница: зачем нужен Эскизный проект

В методологии ГОСТ 34 Эскизный проект (ЭП) выполняет роль концептуального фильтра. Если Техническое задание отвечает на вопрос «что должна делать система», а Технический проект — «как именно, с какими IP-адресами и настройками она будет это делать», то Эскизный проект отвечает на вопрос «каким принципиальным путем мы пойдем».

Для значимых объектов КИИ стадия ЭП критически важна из-за главного правила промышленной безопасности: средство защиты информации (СЗИ) не должно нарушать непрерывность технологического процесса. Именно на этой стадии проектировщик формирует высокоуровневую архитектуру, выделяет домены доверия и определяет классы необходимых решений без привязки к конкретным артикулам (SKU) оборудования.

Ключевым документом стадии является Пояснительная записка к эскизному проекту (ПЗ). В контексте 187-ФЗ и Приказа ФСТЭК №239 этот документ становится юридическим и техническим обоснованием того, почему была выбрана именно такая архитектура защиты. ПЗ должна содержать анализ объекта автоматизации, описание концептуальных решений и, что наиболее важно, логику адаптации базового набора мер защиты.

!Концептуальная архитектура эшелонированной защиты КИИ

В Пояснительной записке проектировщик обязан зафиксировать границы сегментов КИИ. На практике это означает разделение сети на технологический, демилитаризованный и корпоративный сегменты с описанием разрешенных информационных потоков (кондуитов) между ними. На этом этапе мы не пишем правила маршрутизации, но жестко фиксируем постулат: «Прямой обмен трафиком между корпоративным сегментом и сетью контроллеров ПАК запрещен, взаимодействие осуществляется исключительно через промежуточные серверы в демилитаризованной зоне».

Адаптация мер защиты по Приказу ФСТЭК №239

Приказ ФСТЭК №239 предоставляет базовый набор мер защиты в зависимости от присвоенной категории значимости объекта КИИ. Однако слепое копирование этого набора в проектную документацию — грубая ошибка, которая не пройдет проверку регулятора. Базовый набор должен быть адаптирован под конкретную инфраструктуру.

Процесс адаптации в Эскизном проекте включает три последовательных шага:

Исключение неактуальных мер. Если в технологическом сегменте физически отсутствуют и запрещены беспроводные сети, меры подгруппы ЗТС (защита беспроводных соединений) исключаются. В ПЗ это фиксируется с четким обоснованием: «Меры ЗТС.1–ЗТС.5 не применяются в связи с отсутствием точек доступа и беспроводных интерфейсов на объекте КИИ, что подтверждается актом обследования №...».

Уточнение мер. Базовые меры часто сформулированы обобщенно. Проектировщик должен перевести их на язык конкретных архитектурных решений. Например, мера ИНЦ.2 (мониторинг безопасности) уточняется до концепции сбора событий: «Сбор событий безопасности осуществляется с уровня ОС серверов SCADA и активного сетевого оборудования с передачей в централизованную систему корреляции событий».

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

Результатом этого этапа является Адаптированный базовый набор мер, который ложится в основу выбора классов СЗИ.

Искусство обоснования компенсирующих мер

Самый сложный и творческий этап разработки Эскизного проекта — работа с компенсирующими мерами. В промышленных сетях (АСУ ТП) регулярно возникают ситуации, когда реализация требования ФСТЭК технически невозможна или напрямую угрожает технологическому процессу.

Рассмотрим классическую проблему: мера АВЗ.1 (реализация антивирусной защиты). Объект КИИ — система управления газораспределительной станцией. Операторские станции (АРМ) работают на базе устаревшей операционной системы Windows XP Embedded, так как проприетарное ПО вендора АСУ ТП не поддерживает современные ОС. Установка любого современного сигнатурного антивируса вызывает неконтролируемую перезагрузку АРМ (BSOD) из-за конфликта драйверов уровня ядра.

С точки зрения закона, невыполнение меры АВЗ.1 для значимого объекта недопустимо. С точки зрения инженерии, ее выполнение приведет к аварии. Выход — разработка и обоснование компенсирующих мер.

В Пояснительной записке ЭП необходимо выстроить строгую логическую цепочку. Для этого применяется математическая логика покрытия рисков. Если — риск, который закрывает базовая мера, а — риск, который закрывает набор компенсирующих мер, то проектировщик должен доказать неравенство: (остаточный риск при использовании компенсирующих мер должен быть меньше или равен остаточному риску при базовой мере).

В нашем случае с АВЗ.1 обоснование в ПЗ будет выглядеть следующим образом:

Фиксация невозможности: «Реализация базовой меры АВЗ.1 невозможна в связи с несовместимостью современных средств антивирусной защиты с ОС Windows XP Embedded, что подтверждается официальным письмом производителя АСУ ТП (Приложение А). Установка СЗИ приведет к нарушению требования непрерывности технологического процесса».

Определение нейтрализуемой угрозы: «Мера АВЗ.1 направлена на нейтрализацию угрозы внедрения и исполнения вредоносного кода (УБИ.01)».

Выбор компенсирующих мер: «Для нейтрализации УБИ.01 предлагается следующий комплекс компенсирующих мер:

- Аппаратная блокировка всех USB-портов на АРМ (мера ЗНИ.8). - Внедрение системы Application Control в режиме «белого списка» (мера ЗИС.22), разрешающей запуск только исполняемого файла SCADA-системы. - Изоляция сегмента АРМ на сетевом уровне с запретом любого входящего трафика, кроме технологического (мера ЗИС.3)».

Вывод: «Предложенный комплекс мер делает невозможным доставку и запуск вредоносного кода на АРМ, что полностью нейтрализует целевую угрозу без установки сигнатурного антивируса».

Такой подход защищает проект от претензий регулятора и сохраняет работоспособность объекта.

Сравнение альтернативных вариантов архитектуры

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

Для этого в ПЗ включается раздел с анализом альтернатив. Сравниваются не конкретные продукты (например, Kaspersky против Dr.Web), а концептуальные подходы.

Рассмотрим выбор подхода к реализации меры ЗИС.3 (защита виртуальной инфраструктуры) для серверного фермы КИИ.

Вариант 1: Традиционный сетевой подход. Установка физических межсетевых экранов на границе кластера виртуализации. Весь трафик между виртуальными машинами (East-West трафик) выводится на физический коммутатор, инспектируется МСЭ и возвращается обратно. Плюсы: Независимость от гипервизора, высокая производительность аппаратных МСЭ. Минусы: Эффект «тромбона» (задержки при маршрутизации), невозможность контролировать трафик внутри одного хоста виртуализации без его вывода наружу.

Вариант 2: Использование встроенного гипервизорного МСЭ (микросегментация). Развертывание виртуальных межсетевых экранов на уровне vNIC (виртуальных сетевых карт) каждой машины. Плюсы: Отсутствие задержек, гранулярный контроль трафика вплоть до конкретного процесса, отсутствие необходимости перестраивать физическую сеть. Минусы: Жесткая привязка к платформе виртуализации, потребление ресурсов CPU самих серверов.

В Эскизном проекте проектировщик сводит эти характеристики в матрицу принятия решений, добавляя критерии стоимости владения (TCO) и сложности эксплуатации. Если объект КИИ требует обработки транзакций в реальном времени с минимальными задержками ( мс), проектировщик обоснованно отклоняет Вариант 1 и фиксирует в ПЗ выбор Варианта 2. В будущем, на стадии Технического проекта, этот обоснованный выбор сузит круг поиска до 2-3 конкретных вендоров, поддерживающих микросегментацию для используемого гипервизора.

Оценка влияния на производительность и экономическая целесообразность

Ключевой барьер при согласовании проектов защиты КИИ со стороны бизнеса — это страх деградации производительности систем и непрозрачность бюджета. Эскизный проект должен снимать эти страхи через предварительные расчеты.

Проектировщик должен оценить накладные расходы на ИБ. Например, если концепция предполагает внедрение агентов системы мониторинга информационной безопасности (EDR/XDR) на технологические серверы, в ПЗ фиксируются граничные условия: «Выбранный класс решений не должен утилизировать более 5% ресурсов CPU и 512 МБ оперативной памяти в штатном режиме работы». Это требование станет жестким критерием при выборе конкретного ПО на следующей стадии.

Экономическое обоснование на стадии ЭП формируется укрупненно. Здесь не нужны копейки, здесь нужен порядок цифр (CAPEX и OPEX). Проектировщик показывает, что, например, выбор единой платформы управления безопасностью (Unified Threat Management) вместо зоопарка разрозненных решений от разных вендоров позволит сэкономить 30% бюджета на этапе внедрения и снизит требования к количеству дежурных смен SOC (Security Operations Center) в два раза.

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

Крупная региональная генерирующая компания успешно защитила Эскизный проект по модернизации системы информационной безопасности АСУ ТП. В документации была заложена передовая система мониторинга событий (SIEM), концептуально одобренная регулятором. Однако на этапе монтажа выяснилось, что ядро промышленной сети не поддерживает технологию SPAN для зеркалирования трафика, а выделенная под управление подсеть уже занята программируемыми логическими контроллерами (ПЛК). Проект был заморожен на три месяца, потребовалась экстренная закупка дополнительных коммутаторов и полная переработка IP-адресации. Эта ситуация — классическое следствие разрыва между архитектурной концепцией и инженерной реальностью. Преодолеть этот разрыв призвана стадия Технического проекта.

Согласно ГОСТ Р 59793-2021, регламентирующему стадии создания автоматизированных систем, Технический проект — это не просто папка с чертежами, а полноценная стадия жизненного цикла (стадия 4). На этом этапе концептуальные требования Технического задания (ТЗ) трансформируются в конкретные инженерные решения, готовые к внедрению.

В практике проектирования систем защиты значимых объектов КИИ стадию Технического проекта часто объединяют со стадией Эскизного проекта (стадия 3). ГОСТ допускает такое слияние, однако оно не отменяет целей эскизного проектирования. Эскизный проект необходим в ситуациях, когда требования ТЗ можно реализовать несколькими принципиально разными способами, и среди них нет однозначно предпочтительного.

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

В соответствии с ГОСТ 34.201-2020 и требованиями приказа ФСТЭК №239, Технический проект на создание системы защиты состоит из строго определенного набора документов. Базовый комплект включает пять ключевых элементов, каждый из которых выполняет свою функцию в процессе легализации и внедрения наложенных средств защиты информации (СЗИ).

1. Ведомость технического проекта (ТП)

Ведомость технического проекта — это навигационный документ, реестр всех разработанных материалов. В контексте ГОСТ Р 51583-2014, который определяет порядок создания защищенных систем, Ведомость фиксирует полноту комплекта документации.

Для проверяющего органа или Главного инженера проекта (ГИПа) Ведомость служит первичным чек-листом. В ней указываются шифры документов, их наименования, количество листов и форматы. Если подрядчик сдает проект, в котором Ведомость ссылается на «Схему кабельных проводок», а физически этот документ отсутствует или имеет другой шифр, проект возвращается на доработку без дальнейшего чтения. Строгая нумерация и кодирование по ГОСТ 34.201-2020 (например, АБВГ.460000.001-ТП) обязательны.

2. Пояснительная записка (ПЗ)

Пояснительная записка — смысловое ядро Технического проекта. Если остальные документы содержат сухие таблицы и схемы, то ПЗ связывает их в единую логическую структуру. В контексте защиты КИИ Пояснительная записка должна исчерпывающе отвечать на требования регулятора.

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

Обоснование выбора СЗИ. Здесь проектировщик доказывает, что выбранное оборудование и программное обеспечение закрывает актуальные угрозы из Модели угроз и нарушителей, а также соответствует мерам приказа ФСТЭК №239. Обоснование должно включать ссылки на сертификаты ФСТЭК России, подтверждающие заявленные уровни доверия.

Этапы построения подсистемы защиты. Защита значимого объекта КИИ редко внедряется одномоментно. В ПЗ расписывается очередность: например, сначала разворачивается подсистема антивирусной защиты на рабочих станциях операторов, затем внедряется система обнаружения вторжений (СОВ) в режиме мониторинга, и только на третьем этапе настраивается активная блокировка трафика межсетевыми экранами.

Описание архитектурных решений. Текстовое описание того, как система интегрируется в существующую инфраструктуру без нарушения технологического процесса (АСУ ТП).

3. Схема реализации системы защиты на объекте

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

!Сравнение высокоуровневой логики взаимодействия и детальной технической реализации сетевой защиты.

Разработка схем (документы с шифрами Э1, Э2, Э3 или графические приложения к ПЗ) требует учета физической и логической топологии.

Физическая архитектура и отказоустойчивость

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

Fail-open (Открытый отказ) — при аппаратном сбое средства защиты (например, СОВ) трафик начинает проходить сквозь него без фильтрации. Безопасность временно снижается, но технологический процесс не прерывается. Обязательно для критичных узлов АСУ ТП.

Fail-close (Закрытый отказ) — при сбое устройство блокирует любой проходящий трафик. Применяется там, где компрометация данных страшнее остановки системы (например, шлюзы доступа к системам управления криптографическими ключами).

На схемах физической реализации проектировщик должен явно указать использование специализированных сетевых карт с функцией аппаратного Bypass для реализации режима Fail-open.

Логическая архитектура и пропускная способность

Логическая топология описывает уровни L2 и L3 модели OSI. На схемах фиксируются таблицы IP-маршрутизации, виртуальные локальные сети (VLAN) и правила трансляции адресов (NAT).

!Историческая схема логической топологии ARPANET

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

Базовый расчет требуемой пропускной способности для передачи событий безопасности выглядит так:

Где — требуемая полоса пропускания в бит/с, — пиковое количество генерируемых событий в секунду (EPS, Events Per Second), — средний размер одного события в байтах, а умножение на 8 переводит байты в биты.

Если расчетное значение превышает 80% от емкости стандартного гигабитного порта (1 Gbps), в Техническом проекте необходимо закладывать агрегацию каналов (LACP) или переход на интерфейсы 10 Gbps.

Детализация решений: Документы П2, ПВ и ПА

Хотя Пояснительная записка и Схемы дают общее представление, инженерная глубина Технического проекта достигается за счет специализированных документов по ГОСТ 34.201-2020. Они часто оформляются как приложения к ПЗ или самостоятельные тома.

Описание автоматизируемых функций (П2)

Этот документ объясняет, как именно работает система. Здесь нормативные требования превращаются в инженерные алгоритмы.

Возьмем меру ЗИС.19 (Защита от вредоносного кода). В Техническом проекте прописывается пошаговый алгоритм:

HTTP/HTTPS запрос пользователя перехватывается прокси-сервером.

Прокси-сервер по протоколу ICAP передает загружаемый файл на сервер потокового антивируса.

Антивирусное ядро распаковывает архивы (до 5 уровней вложенности) и проверяет файл по сигнатурным базам.

При чистом вердикте файл передается пользователю.

При обнаружении вредоносного кода прокси-сервер разрывает соединение, выдает пользователю HTML-страницу с предупреждением и отправляет Syslog-сообщение в SIEM-систему.

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

Информационное (ПВ) и программное (ПА) обеспечение

Для систем защиты информации (СЗИ) информационное обеспечение — это форматы логов, структуры баз данных уязвимостей и политики хранения инцидентов. Важнейшая задача проектировщика здесь — расчет емкости систем хранения данных (СХД) для выполнения требований законодательства (хранение инцидентов ИБ не менее 3 лет).

Расчет полезного объема хранилища вычисляется по формуле:

Где — требуемый объем дискового пространства в байтах, — среднее количество событий в секунду, — средний размер события, — время хранения в секундах, — коэффициент сжатия данных, обеспечиваемый СУБД (обычно от 5 до 10 для текстовых логов).

Документ ПА фиксирует версии операционных систем и прикладного ПО. В сфере КИИ нельзя написать просто «ОС Linux». Необходимо указать конкретный дистрибутив, его версию и наличие сертификата ФСТЭК.

> Программное обеспечение системы защиты должно быть совместимо не только между собой, но и с защищаемой АСУ ТП. Установка сертифицированного агента антивируса может вызвать «синий экран» (BSOD) на серверах SCADA-системы из-за конфликта драйверов уровня ядра. В документе ПА проектировщик обязан зафиксировать матрицу совместимости.

Интеграция со смежными системами

Система защиты КИИ должна взаимодействовать с IT-инфраструктурой предприятия. В Техническом проекте описываются интерфейсы сопряжения. Сравним два базовых подхода на примере сбора событий с серверов:

| Параметр | Агентский сбор (Agent-based) | Безагентский сбор (Agentless) | | :--- | :--- | :--- | | Принцип работы | На каждый защищаемый сервер устанавливается программа-агент, которая читает локальные логи и отправляет их. | Сервер безопасности сам подключается к защищаемым узлам (по WMI, RPC, SSH) и забирает логи. | | Нагрузка на сеть | Минимальная (данные сжимаются и фильтруются агентом). | Высокая (передается большой объем сырых данных, частые опросы). | | Влияние на защищаемый узел | Требует установки стороннего ПО (риск конфликтов с АСУ ТП), потребляет CPU/RAM узла. | Не требует установки ПО, но требует открытия высоких привилегий (учетная запись администратора). | | Отражение в ТП | Фиксация версий агентов в ПА, открытие одного порта (например, TCP 514) в схемах. | Описание сервисных учетных записей в ПВ, открытие пула динамических портов. |

4. Порядок ввода в действие подсистемы защиты

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

В соответствии с ГОСТ Р 59792-2021, регламентирующим проведение испытаний, этот документ описывает последовательность легализации системы:

Автономные испытания: Проверка работоспособности каждого СЗИ в отдельности на стенде или в изолированном сегменте.

Комплексные испытания: Проверка взаимодействия всех СЗИ между собой (например, корректность передачи логов от межсетевого экрана к SIEM).

Опытная эксплуатация: Работа системы защиты на реальном объекте, но в пассивном режиме. Межсетевые экраны работают в режиме IDS (только обнаружение), антивирусы не удаляют файлы, а только формируют алерты. В этом разделе проектировщик прописывает длительность опытной эксплуатации (обычно от 1 до 3 месяцев) и критерии ее успешного завершения.

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

5. Ведомость покупных изделий (ВП)

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

Это мост между инженерным отделом и отделом закупок. В спецификациях недопустимы обобщения. Проектировщик указывает точные артикулы (SKU), количество лицензий, сроки технической поддержки, длины патч-кордов и типы трансиверов (SFP-модулей). Ошибка в одной букве артикула может привести к закупке межсетевого экрана без криптографического модуля, что сделает невозможным выполнение требований ТЗ по организации ГОСТ-VPN.

Контроль качества: Чек-лист ГИПа

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

Синхронизация с ТЗ: Каждое требование из Технического задания (ГОСТ 34.602-2020) имеет отражение в Пояснительной записке с указанием конкретного механизма реализации.

Матрица совместимости: В документе ПА явно указано, что версии операционных систем АСУ ТП поддерживаются выбранными агентами СЗИ.

Расчеты емкости и полосы: В документах присутствуют математические расчеты ( для сети, для СХД). Значения не взяты «из головы».

Режимы отказа: На схемах и в ПЗ явно указаны режимы Fail-open/Fail-close для каждого устройства, устанавливаемого в разрыв технологического трафика.

Актуальность сертификатов: В спецификациях (ВП) указаны артикулы сертифицированных версий СЗИ, а срок действия сертификатов ФСТЭК не истекает в ближайший год.

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

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

Детализация проектных решений: Разработка Спецификаций и ведомостей оборудования и ПО

Крупная региональная энергетическая компания выделила 45 миллионов рублей на модернизацию подсистемы безопасности значимого объекта КИИ. Технический проект был согласован, оборудование закуплено и доставлено на площадку. В день монтажа выяснилось, что закупленные межсетевые экраны нового поколения (NGFW) невозможно подключить к ядру сети: в Техническом проекте была заложена агрегация каналов по оптике, а в Спецификации подрядчик забыл указать SFP+ трансиверы, стоимость которых составляла менее 1% от бюджета. Проект был заморожен на два месяца из-за бюрократических процедур дозакупки. Эта ситуация иллюстрирует главную проблему финальных стадий проектирования: разрыв между инженерной мыслью и номенклатурной реальностью.

Спецификация оборудования и программного обеспечения (в терминах ГОСТ 34 — документ вида В1) — это точка, где абстрактные архитектурные решения, IP-адреса и политики безопасности превращаются в конкретные коробки, лицензионные ключи и бухгалтерские активы. Если Технический проект описывает, как система будет работать, то Спецификация определяет, что именно необходимо купить, чтобы эта работа стала возможной.

Архитектура документа и номенклатурная точность

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

!Декомпозиция позиции спецификации на закупку NGFW

Каждая позиция в спецификации должна обладать свойством однозначной идентификации. Производители ИТ-оборудования и средств защиты информации (СЗИ) используют систему артикулов (Stock Keeping Unit, SKU), где каждый символ кодирует определенную характеристику.

Сравним два подхода к формированию позиции для сервера управления SIEM-системой.

| Параметр | Инженерное описание (допустимо в ПТ) | Номенклатурное описание (обязательно для В1) | | :--- | :--- | :--- | | Наименование | Сервер 2U, 2 процессора, 256 ГБ RAM, 4x10G | Сервер [Название вендора] [Модель] | | Артикул (SKU) | Отсутствует | SRV-DL380-G10-BTO | | Детализация состава | Блоки питания с резервированием, рельсы для стойки | 2x CPU-6230, 8x RAM-32G-DDR4, 1x NIC-4x10G-SFP+, 2x PSU-800W, 1x RAIL-KIT-2U | | Риск при закупке | Поставщик привезет сервер без жестких дисков и кабелей питания, так как они не указаны явно. | Нулевой. Спецификация однозначно определяет шасси и все внутренние компоненты. |

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

Особое внимание уделяется физическим интерфейсам. Если в документе ПТ (Описание комплекса технических средств) на схеме показано подключение СОВ (системы обнаружения вторжений) к SPAN-порту коммутатора через оптический кабель, Спецификация должна содержать:

Саму аппаратную платформу СОВ.

Сетевой модуль SFP/SFP+ для СОВ (если не встроен).

Оптический трансивер для СОВ (соответствующей длины волны, например, 850 нм для многомода).

Оптический трансивер для коммутатора ядра (если свободных нет в наличии у заказчика).

Оптический патч-корд нужной длины и с нужными коннекторами (LC-LC).

Специфика КИИ: Сертификаты ФСТЭК, формуляры и техническая поддержка

Главное отличие спецификации на подсистему ИБ значимого объекта КИИ от обычного ИТ-проекта — необходимость учета требований регуляторов (Приказ ФСТЭК №239) к оценке соответствия СЗИ. Нельзя просто купить лицензию на антивирус или межсетевой экран; необходимо приобрести сертифицированное средство защиты.

В номенклатуре вендоров сертифицированная версия и обычная коммерческая версия — это разные артикулы. Более того, сертификация ФСТЭК требует поставки так называемого «медиакомплекта» (или установочного комплекта).

!Медиакомплект сертифицированного СЗИ

Медиакомплект — это физический артефакт, который доказывает легитимность использования СЗИ на объекте КИИ. В спецификации он должен быть прописан отдельной строкой. Обычно он включает:

Верифицированный дистрибутив на оптическом диске или защищенном USB-носителе.

Формуляр (паспорт) изделия с уникальным номером и голографическим знаком ФСТЭК России.

Заверенную копию сертификата соответствия.

> Формуляр — это главный документ для проверяющих органов. Если в организации развернуто 1000 агентов сертифицированного антивируса, но нет ни одного формуляра с голограммой, с точки зрения ФСТЭК средства защиты на объекте отсутствуют.

Второй критический аспект — техническая поддержка. Приказ ФСТЭК №239 (мера ОЖС.2) прямо требует обеспечения СЗИ гарантийной и технической поддержкой, включая получение обновлений баз решающих правил и патчей безопасности.

Если проектировщик заложит в Спецификацию только аппаратную платформу и базовую лицензию, заказчик получит «кирпич», который перестанет обновляться через год (или вообще не начнет, если обновления требуют отдельной подписки). Правильно сформированный блок закупки межсетевого экрана уровня приложения (NGFW) для КИИ выглядит как конструктор:

HW-FW-1000 — Аппаратная платформа.

LIC-FW-BASE — Базовая лицензия на функции межсетевого экранирования (бессрочная).

LIC-IPS-1Y — Подписка на обновления сигнатур системы обнаружения вторжений (на 1 год).

LIC-URL-1Y — Подписка на категоризацию веб-трафика (на 1 год).

FSTEC-PACK — Медиакомплект и формуляр ФСТЭК.

SUP-STD-1Y — Сертификат стандартной технической поддержки вендора (доступ к обновлениям прошивки и порталу ТП).

Комплект ЗИП и обеспечение отказоустойчивости

Для значимых объектов КИИ первой и второй категорий метрика RTO (допустимое время простоя) часто исчисляется минутами. В таких условиях полагаться исключительно на SLA вендора по замене вышедшего из строя оборудования (даже Next Business Day) недопустимо. Проектировщик обязан заложить в Спецификацию комплект ЗИП (запасные части, инструменты и принадлежности).

ЗИП делится на одиночный (ЗИП-О) для конкретного изделия и групповой (ЗИП-Г) для группы однотипных изделий. При проектировании систем защиты обычно формируют ЗИП-Г, рассчитываемый по принципу или в зависимости от интенсивности отказов.

Что обязательно включается в раздел ЗИП Спецификации:

Оптические трансиверы. Это расходный материал, который выходит из строя чаще всего. Если в проекте используется 20 модулей 10G-SR, в ЗИП закладывается минимум 2-3 запасных.

Блоки питания. Серверы и аппаратные шлюзы безопасности должны иметь резервируемые блоки питания (Hot-Swap). Запасной блок питания в ЗИП позволяет инженеру восстановить схему резервирования за 5 минут, не дожидаясь курьера от производителя.

Жесткие диски / SSD. Для серверов управления и узлов хранения логов SIEM-систем, работающих в RAID-массивах, наличие холодных или горячих (Hot Spare) запасных дисков критично для предотвращения деградации массива при сбое одного накопителя.

Важно отличать ЗИП (холодный резерв, лежащий на складе) от архитектурного резервирования (например, кластера Active-Passive). Кластер описывается в Техническом проекте как единый функционирующий узел, состоящий из двух устройств. ЗИП — это имущество, которое не участвует в информационном обмене до момента аварии.

Преодоление барьеров 44-ФЗ и 223-ФЗ: Описание «или эквивалент»

Многие субъекты КИИ (государственные корпорации, бюджетные учреждения) обязаны проводить закупки в соответствии с федеральными законами 44-ФЗ или 223-ФЗ. Эти законы запрещают указывать в закупочной документации конкретные товарные знаки без добавления слов «или эквивалент» (за редкими исключениями, например, при обеспечении совместимости с уже имеющимся оборудованием).

Если ГИП (главный инженер проекта) просто напишет в Спецификации «Межсетевой экран VendorName Model X или эквивалент», отдел закупок заказчика будет обязан принять заявку от любого поставщика, предложившего дешевый SOHO-роутер, формально подходящий под определение «межсетевого экрана».

Чтобы защитить проектное решение, Спецификация дополняется детализированными техническими требованиями к каждой позиции (часто оформляется как отдельное Приложение к Спецификации или раздел в ТЗ на закупку). Искусство проектировщика заключается в том, чтобы описать требуемое устройство через набор объективных, измеримых характеристик, которые отсекают нецелевые аналоги, но не нарушают антимонопольное законодательство.

Вместо указания конкретного процессора пишут: «Количество ядер вычислителя — не менее 16, базовая тактовая частота — не менее 2.4 ГГц». Вместо указания проприетарной технологии кластеризации пишут: «Поддержка отказоустойчивого кластера в режимах Active-Passive и Active-Active с синхронизацией сессий без прерывания TCP-соединений при переключении нод». Для СЗИ обязательно добавляется параметр: «Наличие действующего сертификата ФСТЭК России по требованиям к межсетевым экранам типа А не ниже 4 класса защиты».

Чек-лист ГИПа: Контроль качества Спецификации

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

1. Проверка прослеживаемости (Traceability). Откройте документ ПТ (Описание комплекса технических средств) и структурную схему сети. Каждое устройство, нарисованное на схеме, должно иметь отражение в Спецификации. Если на схеме 5 серверов, а в спецификации 4 лицензии на гипервизор — это брак.

2. Проверка информационного обеспечения (документ ПВ). В документе ПВ производится расчет объема хранимых данных (например, логов для SIEM). Если расчет показывает потребность в 50 ТБ полезной емкости при RAID 6, Спецификация должна содержать сервер с соответствующим количеством дисков, учитывающим потери на четность и форматирование (например, 8 дисков по 10 ТБ).

3. Проверка программного обеспечения (документ ПА). Все операционные системы, СУБД и прикладное ПО, описанные в ПА, должны быть залицензированы в Спецификации. Частая ошибка — забытые лицензии клиентского доступа (CAL) для Microsoft Windows Server или СУБД, на которых разворачиваются консоли управления СЗИ.

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

Как это крепится в стойку? (Включены ли Rail Kits, если они не идут в базе).

Как это питается? (Заложены ли кабели питания нужного типа — C13/C14 или C19/C20, соответствуют ли они розеткам в PDU заказчика).

Как это подключается к сети? (Трансиверы, патч-корды, DAC-кабели).

5. Проверка жизненного цикла (End-of-Sale). Проектирование крупных систем КИИ может занимать от 6 до 12 месяцев. К моменту готовности Спецификации оборудование, заложенное на этапе Эскизного проекта, может быть снято с продажи (статус End-of-Sale). ГИП обязан потребовать от проектировщиков актуализации артикулов по текущим прайс-листам вендоров на момент выпуска документации.

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

В 2021 году крупный субъект электроэнергетики потратил более 120 миллионов рублей на закупку межсетевых экранов уровня приложения (NGFW), систем класса SIEM и песочниц. Технический проект был выполнен безупречно, оборудование смонтировано, IP-адресация настроена. Однако при первой же проверке регулятор выписал предписание о несоответствии системы защиты требованиям приказа ФСТЭК №239, а система не была допущена к эксплуатации. Причина крылась не в технике: в организации отсутствовал документ, официально назначающий администратора безопасности, не был утвержден регламент реагирования на инциденты, а пароли от учетных записей NGFW передавались в ИТ-отдел через мессенджер. Дорогая аппаратная архитектура оказалась юридически и процессуально мертвой.

Проектирование системы защиты значимого объекта КИИ не заканчивается на выборе спецификаций и настройке маршрутизации. Технические средства защиты информации (СЗИ) — это лишь инструмент. Организационно-распорядительная документация (ОРД) — это логика применения данного инструмента, закрепленная юридически. Без ОРД любая техническая мера защиты считается нереализованной.

Место ОРД в структуре ГОСТ 34 и требованиях регулятора

В парадигме комплекса стандартов ГОСТ 34 организационно-распорядительная документация относится к двум видам обеспечения: организационному (документы с индексом «О») и информационному. На стадии разработки Рабочей документации (или объединенного Технорабочего проекта) проектировщик обязан создать комплект документов, который описывает, как именно персонал будет взаимодействовать с техническими решениями.

Базовый порядок создания защищенных систем регламентируется ГОСТ Р 51583-2014. Этот стандарт требует, чтобы требования по защите закладывались на самых ранних этапах, а не «навешивались» на готовую систему. При этом Приказ ФСТЭК №239 (пункт 12) прямо требует реализации обширного перечня групп мер, большинство из которых невозможно закрыть исключительно программно-аппаратными средствами:

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

Меры вроде «с) информирование и обучение персонала» или «м) планирование мероприятий» реализуются исключительно через разработку, утверждение и внедрение соответствующих приказов, регламентов и планов. Задача проектировщика (ГИПа или ведущего специалиста) — обеспечить их бесшовную интеграцию с бизнес-процессами предприятия-заказчика, пройдя все стадии создания по ГОСТ Р 59793-2021.

Проектирование ОРД на различных стадиях по ГОСТ Р 59793-2021

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

Техническое задание (ТЗ) и Частное техническое задание (ЧТЗ)

Согласно ГОСТ 34.602-2020, Техническое задание — это фундаментальный документ, определяющий, что именно должно быть создано. Если система защиты создается как подсистема в рамках большой АСУ ТП, разрабатывается Частное техническое задание (ЧТЗ).

Для организационных мер ключевым является раздел ТЗ «Требования к видам обеспечения» (подраздел «Требования к организационному обеспечению»).

Типичная ошибка новичка — писать в ТЗ общие фразы: «Подрядчик должен разработать документы по ГОСТ». Это приводит к тому, что подрядчик сдает шаблоны из интернета.

Правильная формулировка в ТЗ должна быть предельно конкретной и опираться на приказ ФСТЭК: > «В рамках создания подсистемы защиты Подрядчик обязан разработать проекты организационно-распорядительных документов, регламентирующих процессы управления доступом (меры группы «б» приказа ФСТЭК №239). Документация должна включать матрицу доступа, регламент предоставления и отзыва прав, а также форму заявки на доступ. Срок блокировки учетной записи при увольнении сотрудника в разрабатываемом регламенте не должен превышать 2 часов с момента издания кадрового приказа».

Эскизный проект (ЭП)

На стадии Эскизного проекта (ГОСТ 2.119-73, применяемый в связке с ГОСТ 34) закладываются концептуальные решения. В контексте ОРД здесь формируется «Пояснительная записка к эскизному проекту» (код документа ПЗ).

В ЭП проектировщик еще не пишет сами инструкции, но он обязан определить:

Перечень ролей в будущей системе (Администратор ИБ, Администратор ИТ, Пользователь, Аудитор).

Необходимую численность персонала для обслуживания СЗИ.

Требования к квалификации (например, необходимость наличия сертификатов по конкретному NGFW).

Технический проект (ТП) и Спецификации

Технический проект — это детальная архитектура. Согласно ГОСТ 34.201-2020, здесь рождается документ с кодом «О1» — «Описание организационной структуры».

В этом документе проектировщик фиксирует, как именно отдел ИБ будет взаимодействовать с ИТ-отделом и технологами АСУ ТП. Здесь же разрабатываются проекты Положений и Регламентов.

Спецификации оборудования (Спецификация оборудования, изделий и материалов) на стадии ТП жестко увязываются с ОРД. Если в спецификации заложена закупка аппаратных токенов (Рутокен, JaCarta) на 500 пользователей, в Техническом проекте должен появиться процесс их учета, выдачи и отзыва, который позже ляжет в основу Журнала учета машинных носителей информации.

Иерархия организационно-распорядительной документации

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

!Иерархическая структура уровней организационно-распорядительной документации компании.

Разделим документы на четыре фундаментальных уровня.

| Уровень | Тип документа (по ГОСТ 34.201-2020) | Назначение | Кто утверждает | Частота обновления | | :--- | :--- | :--- | :--- | :--- | | I. Стратегический | Политика / Концепция (ПЗ) | Декларирует цели, принципы и высокоуровневые правила. Отвечает на вопросы «Что мы защищаем?» и «Почему?». | Руководитель организации (Генеральный директор) | Раз в 3–5 лет или при смене бизнес-модели. | | II. Процессный | Регламент / Положение (О1, О2) | Описывает конкретный процесс, роли, зоны ответственности и метрики (SLA). Отвечает на вопросы «Кто?», «Когда?» и «В какие сроки?». | Технический директор / Директор по ИБ | Ежегодно или при изменении оргштатной структуры. | | III. Операционный | Инструкция / Руководство (ИЭ, ИО) | Содержит пошаговые алгоритмы действий для конкретной роли в конкретной системе. Отвечает на вопрос «Как именно нажимать кнопки?». | Начальник отдела ИБ / ИТ | При каждом обновлении версий ПО или СЗИ. | | IV. Доказательный | Журнал / Акт / Заявка | Фиксирует факт выполнения действий, описанных в регламентах и инструкциях. Является главным доказательством для ФСТЭК. | Ведется исполнителями непрерывно | Ежедневно / по факту события. |

Проектировщик системы защиты КИИ редко разрабатывает документы I уровня (обычно они уже существуют на предприятии). Основной объем работы ложится на уровни II, III и IV.

Разработка регламентов: архитектура бизнес-процесса ИБ

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

Правильно спроектированный Регламент управления доступом должен содержать следующие структурные блоки:

Матрица ролей и ответственности. Кто инициирует заявку на доступ? Кто ее согласовывает? Кто технически создает учетную запись? Кто контролирует корректность выдачи?

Временные нормативы (SLA). Регулятор требует своевременного блокирования доступа при увольнении сотрудника. В регламенте это выражается математически через предельное время реакции. Пусть — момент формирования приказа об увольнении в отделе кадров, а — момент технической блокировки учетной записи в Active Directory. Регламент фиксирует жесткое условие:

где 2 часа — это максимально допустимое окно уязвимости, согласованное с бизнес-подразделениями.

Маршрут движения информации. Как именно ИТ-отдел узнает об увольнении? Через систему электронного документооборота (СЭД), служебную записку или автоматический триггер из кадровой системы?

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

> Регламент не должен содержать технических команд (CLI) или скриншотов интерфейса. Если завтра заказчик заменит систему Service Desk с Jira на отечественную платформу, логика регламента (кто кому передает заявку) не должна измениться. Изменится только инструкция.

Интеграция со смежными подразделениями

ОРД по защите КИИ не может существовать в вакууме отдела информационной безопасности. Защита значимого объекта КИИ неизбежно затрагивает кадровую службу, охрану (физический доступ), юридический отдел и технологов.

При проектировании Регламента реагирования на компьютерные инциденты (мера «п» из приказа №239) необходимо предусмотреть действия диспетчера технологического процесса. Если СЗИ фиксирует аномалию в промышленном сегменте сети, ИБ-специалист не имеет права самостоятельно обрывать связь или перезагружать промышленный контроллер (ПЛК). Регламент должен четко фиксировать процедуру: ИБ-специалист уведомляет главного технолога, и только технолог принимает решение об остановке процесса, оценивая риски аварии.

Разработка инструкций: отписка от вендора против реального руководства

Документы операционного уровня (инструкции администратора, инструкции пользователя) разрабатываются в строгом соответствии с ГОСТ 34.201-2020 (коды документов ИЭ — инструкция по эксплуатации, ИО — инструкция оператора).

Самый распространенный способ провалить сдачу проектной документации — скачать с сайта производителя СЗИ 500-страничное «Руководство администратора» и приложить его к проекту под видом Инструкции. Вендорское руководство описывает возможности системы в вакууме. Проектная Инструкция описывает функции, реализованные в рамках конкретного Технического проекта, с учетом конкретной IP-адресации, топологии и политик.

Качественная Инструкция администратора безопасности должна включать:

Конкретные адреса и доступы. (Например: «Подключение к консоли управления NGFW осуществляется по адресу https://10.15.20.5:443 строго из VLAN управления»).

Пошаговые алгоритмы для штатных задач. Как добавить новое правило межсетевого экранирования? Как выгрузить лог-файл за определенный период для передачи в ГосСОПКА?

Действия при нештатных ситуациях (мера «р»). Что делать администратору, если СЗИ перешло в режим Fail-close и заблокировало технологический трафик?

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

Инструкции должны быть строго ролевыми. Инструкция пользователя (оператора АСУ ТП) должна занимать 2-3 страницы и содержать только то, что касается лично его: правила парольной защиты, запрет на подключение личных флеш-накопителей и порядок действий при появлении окна антивируса.

Доказательный уровень: Журналы учета и акты

Для проверяющих органов ФСТЭК и ФСБ действует жесткое правило: «Если действие не зафиксировано в журнале или акте, значит, оно не выполнялось». Проектировщик обязан разработать формы этих документов и передать их заказчику в составе Рабочей документации.

К критически важным формам доказательной документации относятся:

Журнал учета машинных носителей информации (мера «г»).

Журнал учета средств защиты информации и эксплуатационной документации к ним.

Журнал учета инцидентов информационной безопасности (мера «п»).

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

В эпоху цифровизации многие заказчики пытаются вести все реестры в Excel. Однако для ряда процессов, особенно связанных с учетом сертифицированных СЗИ, криптографических ключей (СКЗИ) и машинных носителей, регуляторы требуют ведения строгих бумажных форм. Проектировщик должен заложить в ОРД требования к оформлению таких журналов: страницы должны быть пронумерованы, журнал прошнурован, концы шнуровки оклеены бумажной печатью с оттиском печати организации и подписью ответственного лица. Это обеспечивает свойство неотрекаемости.

Если проектируется электронный журнал (например, в системе Service Desk), ОРД должна содержать требования к его защите: невозможность удаления записей администратором системы (Append-only), автоматическое логирование времени внесения записи и привязка к доменной учетной записи.

Испытания ОРД по ГОСТ Р 59792-2021

Разработанная документация должна пройти проверку на стадии ввода в действие. ГОСТ Р 59792-2021 регламентирует порядок проведения испытаний систем защиты. Ошибка ГИПов заключается в том, что на испытаниях они проверяют только технику (пингуется ли сервер, блокируется ли вирус).

ГОСТ требует проверять систему в комплексе с персоналом. На предварительных испытаниях (ПИ) комиссия обязана проверить:

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

Знание персоналом своих инструкций.

Как протестировать меру «п» (реагирование на инциденты)? Комиссия инициирует учебный инцидент (например, подключение несанкционированной флешки к АРМ оператора). Далее по секундомеру проверяется:

Заметил ли оператор окно блокировки?

Кому он позвонил (согласно Инструкции пользователя)?

Как быстро Администратор ИБ зафиксировал событие в Журнале инцидентов (согласно Регламенту)?

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

Критерии качества и чек-лист проверки ОРД для ГИПа

При приемке комплекта ОРД у субподрядчика ведущий специалист или ГИП должен использовать следующий алгоритм валидации:

Проверка на полноту покрытия (Traceability). Необходимо рассчитать коэффициент покрытия организационными мерами:

где — количество мер из ТЗ, для которых разработаны конкретные пункты в регламентах, а — общее количество мер ФСТЭК, подлежащих организационной реализации. Значение должно быть строго равно 100%.

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

Проверка на непротиворечивость. Сроки в разных документах не должны конфликтовать. Если Политика ИБ требует расследования инцидента за 24 часа, а Регламент реагирования отводит на сбор логов 48 часов — это критический дефект.

Проверка на тестируемость. Любое требование в инструкции должно быть проверяемым. Фраза «Администратор должен регулярно проверять логи» — нетестируема. Фраза «Администратор проверяет журнал событий безопасности межсетевого экрана ежедневно до 10:00 местного времени» — пригодна для аудита.

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

Порядок проведения и документирования испытаний системы защиты по ГОСТ Р 59792-2021

В 2019 году команда системного интегратора развернула систему предотвращения вторжений (IPS) на металлургическом комбинате. Инженеры проверили связность сети, убедились, что интерфейсы активны, подписали акт выполненных работ и уехали. Через два дня по расписанию запустилось масштабное резервное копирование баз данных АСУ ТП. IPS классифицировала этот аномально плотный поток трафика как DDoS-атаку и заблокировала его. Очередь пакетов переполнила буферы коммутаторов ядра, что привело к потере связи с контроллерами управления печами. Доменная печь была экстренно остановлена, финансовые потери составили десятки миллионов рублей. Проблема заключалась не в качестве оборудования, а в том, что система защиты была переведена в промышленную эксплуатацию без прохождения регламентированных стадий испытаний под реальной нагрузкой.

Инженерная философия ГОСТ Р 59792-2021

Внедрение подсистемы информационной безопасности на значимом объекте КИИ — это всегда хирургическое вмешательство в работающий технологический или бизнес-процесс. Чтобы минимизировать риски, ГОСТ Р 59793-2021 (стадии создания) и детализирующий его ГОСТ Р 59792-2021 (испытания) устанавливают жесткий эшелонированный подход к проверке проектных решений.

Испытания не являются разовым событием. Это непрерывный процесс доказательства того, что система соответствует Частному техническому заданию (ЧТЗ), который разбит на три последовательные стадии:

Предварительные испытания (ПИ) — проверка работоспособности системы в тепличных, изолированных условиях.

Опытная эксплуатация (ОЭ) — проверка системы в реальной среде, но с правом на ошибку и под усиленным контролем.

Приемочные испытания (ПрИ) — финальная юридическая фиксация готовности системы к промышленному использованию.

!Эшелонированный подход к испытаниям

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

Программа и методика испытаний (ПМИ) как сценарий проверки

Основой для всех проверок является документ с шифром «ПМ» (Программа и методика испытаний). Он разрабатывается на стадии Технического проекта и утверждает правила игры до начала самих тестов.

Главное правило ПМИ: документ должен быть написан настолько алгоритмично, чтобы испытания мог провести сторонний инженер, не участвовавший в проектировании. ПМИ исключает качественные оценки («система должна работать быстро») и оперирует только бинарными состояниями («успешно / неуспешно») на основе измеримых метрик.

Качественная методика испытаний строится в виде таблицы тест-кейсов, где каждый шаг жестко детерминирован.

| Идентификатор | Требование ЧТЗ | Исходное состояние | Действие | Ожидаемый результат | Критерий успеха | | :--- | :--- | :--- | :--- | :--- | :--- | | TC-NET-01 | п. 4.2.1 (Изоляция сегмента АСУ ТП) | Межсетевой экран включен, правила маршрутизации применены. ПК инженера подключен к корпоративному сегменту (VLAN 10). | С ПК инженера выполняется команда ping 192.168.100.5 (IP-адрес ПЛК в VLAN 20). | Пакеты ICMP блокируются. В консоли управления МСЭ фиксируется событие Drop. | Отсутствие ответов ICMP Echo Reply. Наличие записи в логе МСЭ с указанием правила Deny_Corp_to_SCADA. | | TC-AUTH-03 | п. 4.3.2 (Блокировка УЗ при увольнении) | Учетная запись ivanov_i активна в Active Directory и IdM-системе. | В кадровой системе (1С) статус сотрудника меняется на «Уволен». | В течение 15 минут учетная запись ivanov_i переводится в группу Disabled_Users в AD. | Попытка авторизации под ivanov_i на АРМ оператора завершается отказом (Access Denied). |

Для оценки полноты ПМИ используется матрица трассировки (Traceability Matrix) и расчет коэффициента покрытия требований:

где — общее количество функциональных требований в ЧТЗ, а — количество требований, для которых разработан хотя бы один тест-кейс. В проектах защиты КИИ коэффициент должен быть строго равен .

Предварительные испытания (ПИ): синтетическая среда

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

ПИ делятся на два этапа:

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

Комплексные испытания. Проверка взаимодействия компонентов между собой. На этом этапе проверяется, что события от антивируса успешно доставляются в SIEM-систему, парсятся и отображаются в консоли оператора.

Испытания проводятся на тестовых стендах, либо на боевом оборудовании, но в технологические окна (периоды планового простоя АСУ ТП). На этом этапе моделируются деструктивные воздействия, которые недопустимо проверять на работающем заводе.

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

Результат ПИ фиксируется в Протоколе предварительных испытаний. Если тест-кейс провален, он заносится в «Ведомость замечаний». Подрядчик обязан устранить замечание и провести регрессионное тестирование — повторно выполнить не только проваленный тест, но и связанные с ним сценарии, чтобы убедиться, что внесенное исправление не сломало смежные функции.

Опытная эксплуатация (ОЭ): столкновение с реальностью

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

!Пульт управления АСУ ТП

Особенность ОЭ систем информационной безопасности заключается в том, что средства защиты (особенно IPS, WAF, системы контроля устройств) на первых этапах часто переводятся в режим мониторинга (Monitor-only) или обучения. Они фиксируют нарушения, но не блокируют процессы. Это необходимо для выявления ложноположительных срабатываний (False Positives).

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

«14.10, 08:30 — Замечено замедление открытия мнемосхемы в SCADA после установки агента СЗИ от НСД. Загрузка CPU сервера достигла 98%».

«15.10, 11:15 — SIEM-система генерирует 500 инцидентов в час о неудачной авторизации служебной учетной записи сканера уязвимостей. Требуется корректировка правил корреляции».

Длительность ОЭ для значимых объектов КИИ обычно составляет от 1 до 3 месяцев. За это время система проходит через различные циклы нагрузки (конец месяца, формирование отчетов, пиковые часы работы предприятия).

В ходе ОЭ проверяется не только техника, но и организационно-распорядительная документация (ОРД). Если в инструкции написано, что при обнаружении вируса на флешке администратор должен изолировать АРМ от сети в течение 10 минут, на этапе ОЭ инициируется учебный инцидент. Если администратор тратит 40 минут на поиск нужного пункта в консоли управления, инструкция возвращается на доработку.

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

Приемочные испытания (ПрИ): юридический рубеж

Приемочные испытания — это финал проекта. В отличие от ПИ, где инженеры сутками сидят в серверной, ПрИ — это работа Приемочной комиссии. В комиссию входят представители заказчика (ГИП, служба ИБ, служба АСУ ТП), подрядчика, а в ряде случаев — представители регуляторов.

Задачи комиссии на ПрИ:

Проверить комплектность проектной и эксплуатационной документации (наличие всех ведомостей, спецификаций, формуляров на сертифицированные СЗИ).

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

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

Выборочно провести контрольные проверки по ПМИ. Комиссия не прогоняет все 100% тест-кейсов, она выбирает наиболее критичные сценарии (например, отработку отказа кластера или блокировку несанкционированного доступа).

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

Для Главного инженера проекта (ГИПа) Акт приемочных испытаний — это главный юридический щит. Если через год на предприятии произойдет инцидент ИБ, комиссия ФСТЭК поднимет проектную документацию. Если окажется, что вектор атаки не был учтен в ТЗ, вина ложится на аналитиков. Но если вектор был в ТЗ, а система его не заблокировала — поднимут ПМИ и Протоколы испытаний. Наличие подписей в Акте подтверждает, что на момент сдачи система функционировала штатно и соответствовала всем требованиям нормативной базы, а уязвимость стала следствием некорректной эксплуатации или деградации системы во времени.

Проектирование систем защиты КИИ по ГОСТ 34 — это не просто написание текстов, это создание инженерного механизма. И испытания по ГОСТ Р 59792-2021 являются тем самым полигоном, где абстрактные требования регуляторов, переведенные в строгие спецификации технического проекта, доказывают свою состоятельность в условиях суровой промышленной реальности.

Процедуры внедрения и ввода в эксплуатацию объекта КИИ согласно требованиям регуляторов

Крупное металлургическое предприятие успешно завершило модернизацию АСУ ТП прокатного стана. Подрядчик установил межсетевые экраны, настроил SIEM-систему, провел приемочные испытания и подписал двусторонний Акт. Оборудование мигало индикаторами, трафик фильтровался, руководство выдохнуло и закрыло проект. Спустя три месяца плановая проверка ФСТЭК России выписала предприятию предписание о приостановке эксплуатации значимого объекта КИИ и инициировала административное производство. Причина крылась не в техническом сбое или взломе, а в юридическом вакууме: система де-факто работала, но де-юре так и не была введена в эксплуатацию. Отсутствовал Аттестат соответствия, не был издан финальный приказ, а администраторы безопасности не были официально назначены на должности. Техническая готовность не тождественна правовой легитимности.

Переход от успешных испытаний к промышленной эксплуатации — это смена парадигмы. Если на этапе проектирования и тестирования главным документом было Техническое задание, то на этапе ввода в действие фокус смещается на доказательство соответствия системы государственным нормам. Для значимых объектов критической информационной инфраструктуры (ЗО КИИ) этот процесс строго регламентирован приказом ФСТЭК №239 и комплексом стандартов ГОСТ 34.

Подготовка к вводу в действие: организационный фундамент

Прежде чем вызывать внешних аудиторов или подписывать финальные приказы, главный инженер проекта (ГИП) обязан убедиться, что инфраструктура готова к приему системы с точки зрения процессов и людей. Стадия «Ввод в действие» по ГОСТ Р 59793-2021 начинается с организационных мероприятий.

Первый критический шаг — комплектование штата. Система защиты информации (СЗИ) не может функционировать автономно. В штатном расписании должны быть выделены единицы для администраторов безопасности, аналитиков SOC (если применимо) и специалистов по эксплуатации СЗИ. Назначение оформляется внутренним приказом по организации. Без этого документа последующая аттестация невозможна, так как аудитор обязан проверить, кто именно обладает привилегированным доступом к консолям управления.

Второй шаг — обучение персонала. К моменту ввода в эксплуатацию все администраторы и пользователи должны быть ознакомлены с организационно-распорядительной документацией (ОРД), разработанной на предыдущих этапах. Факт обучения фиксируется в журналах инструктажа. Если в ходе проверки выяснится, что оператор АСУ ТП не знает, как действовать при блокировке его учетной записи антивирусом, это трактуется как невыполнение организационных мер защиты.

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

Оценка соответствия: Аттестация объекта информатизации

Согласно статье 11 Федерального закона №187-ФЗ и пункту 17 Приказа ФСТЭК №239, значимые объекты КИИ подлежат обязательной оценке соответствия требованиям по безопасности. Законодательство допускает две формы такой оценки: приемка (испытания) или аттестация. Однако на практике для государственных информационных систем (ГИС) аттестация обязательна, а для корпоративных ЗО КИИ она является де-факто стандартом индустрии, так как обеспечивает наивысшую юридическую защиту для владельца объекта в случае инцидента.

Аттестация — это комплексная независимая проверка, подтверждающая, что объект информатизации в конкретных условиях эксплуатации соответствует требованиям регулятора. Важнейшее слово здесь — «независимая». Организация, которая проектировала и внедряла систему защиты, как правило, не имеет права ее аттестовывать из-за конфликта интересов. Для этого привлекается сторонний лицензиат ФСТЭК России — орган по аттестации.

Границы объекта аттестации

Ключевая ошибка начинающих проектировщиков — попытка аттестовать «программное обеспечение» или «серверную стойку». Аттестуется объект информатизации целиком.

В границы объекта аттестации входят:

Основная автоматизированная система (серверы, рабочие станции, ПЛК, сетевое оборудование).

Подсистема безопасности (наложенные и встроенные СЗИ).

Помещения, в которых расположены компоненты системы.

Кабельные трассы, соединяющие узлы.

Персонал, взаимодействующий с системой.

Процессы и документация (проектная и эксплуатационная).

!Границы объекта аттестации

Если сервер СЗИ находится в защищенной серверной, а консоль администратора безопасности выведена в общий open-space без контроля доступа, объект не пройдет аттестацию, так как граница физической безопасности нарушена.

Документальная база аттестации

Орган по аттестации начинает работу с экспертизы проектной документации. ГИП передает комиссии полный комплект, разработанный по ГОСТ 34: Техническое задание, Технический проект, Рабочую документацию, ОРД и акты проведенных ранее испытаний.

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

| Критерий | ПМИ (Приемочные испытания) | Программа аттестационных испытаний | | :--- | :--- | :--- | | Цель | Доказать, что система работает так, как написано в ТЗ. | Доказать, что система защищена так, как требует закон (Приказ №239). | | Разработчик | Подрядчик-интегратор. | Независимый орган по аттестации. | | Объект проверки | Функциональность, стабильность, отказоустойчивость. | Перекрытие каналов утечки, выполнение мер защиты, отсутствие уязвимостей. | | Результат | Акт приемочных испытаний. | Аттестат соответствия (или отказ в выдаче). |

Инструментальный контроль и управление уязвимостями

Центральным этапом аттестации является инструментальный контроль. Аудиторы используют сертифицированные сканеры безопасности для поиска уязвимостей в операционных системах, СУБД, сетевом оборудовании и прикладном ПО.

Приказ ФСТЭК №239 категорически запрещает ввод в эксплуатацию ЗО КИИ, если в нем присутствуют уязвимости, приводящие к нарушению безопасности информации. На практике это означает, что все критические и высокие уязвимости (с оценкой по шкале или внесенные в Банк данных угроз ФСТЭК) должны быть устранены.

Здесь ГИП сталкивается с суровой реальностью промышленной автоматизации. Представим SCADA-систему, работающую на базе Windows 7. Вендор оборудования запрещает обновлять ОС под угрозой потери гарантии, а сама Microsoft давно прекратила выпуск патчей. Сканер безопасности выдаст десятки критических уязвимостей. Означает ли это провал аттестации?

Нет, если ГИП грамотно применит механизм компенсирующих мер. Если уязвимость невозможно закрыть установкой обновления (патчем), угроза должна быть нейтрализована архитектурно. В случае с Windows 7 аудитору предоставляется обоснование:

Узел физически изолирован от корпоративной сети и интернета (отсутствует вектор удаленной атаки).

На узле установлено средство контроля съемных машинных носителей (закрыт вектор локального заражения через USB).

Внедрен контроль активности приложений (Application Control) в режиме «белого списка» — запуск любого исполняемого файла, кроме легитимных процессов SCADA, блокируется на уровне ядра ОС.

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

Выдача Аттестата соответствия

Если документарная проверка, оценка ОРД и инструментальный контроль прошли успешно, орган по аттестации выпускает Заключение по результатам аттестационных испытаний и выдает Аттестат соответствия.

Аттестат — это строгий бланк, в котором указаны:

Наименование объекта информатизации.

Категория значимости (для КИИ) или класс защищенности.

Перечень разрешенного к обработке типа информации.

Организационные и технические условия эксплуатации.

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

Финальный аккорд: Приказ о вводе в эксплуатацию

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

Согласно методологии ГОСТ 34, стадия «Ввод в действие» завершается изданием организационно-распорядительного документа — Приказа о вводе системы в промышленную эксплуатацию. Это важнейший рубеж, который переводит проект из состояния капитальных затрат (CAPEX) в состояние операционных расходов (OPEX) и снимает с проектной команды основную ответственность, передавая ее службе эксплуатации.

Структура Приказа о вводе в эксплуатацию должна содержать несколько обязательных блоков.

Во-первых, четкое указание даты начала промышленной эксплуатации. Именно с этой даты (например, с 00:00 1 ноября текущего года) система считается боевой. Любые инциденты информационной безопасности, произошедшие после этой секунды, подлежат обязательному расследованию и передаче в ГосСОПКА (Государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак).

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

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

В-четвертых, утверждается порядок передачи исходных кодов (если система разрабатывалась на заказ), дистрибутивов, лицензионных ключей, формуляров на СЗИ и медиакомплектов в архив организации. ГИП обязан сформировать эталонный комплект документации (Master Copy), который будет храниться в сейфе. Любые расхождения реальных настроек с этим эталоном в будущем будут трактоваться как нарушение.

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

Архитектурный надзор и гарантийные обязательства

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

В первые месяцы промышленной эксплуатации система сталкивается с реальными, а не синтетическими нагрузками. Могут возникать ложные срабатывания (False Positives) систем предотвращения вторжений на специфический технологический трафик, который не был выявлен на этапе опытной эксплуатации. Решение таких проблем требует возврата к проектной документации.

Если для устранения ложного срабатывания требуется изменить архитектуру сети (например, перенести сенсор в другой сегмент), ГИП обязан провести оценку влияния этого изменения на выданный Аттестат соответствия. Любое изменение, затрагивающее границу объекта или состав базовых мер защиты, требует согласования с органом по аттестации. Внесение изменений «наживую», без обновления Технического проекта и ОРД, мгновенно делает Аттестат недействительным, возвращая организацию в зону юридического риска перед регулятором.

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