Пошаговый алгоритм владельца ИС при самостоятельном проектировании, создании и аттестации СЗИ по приказу № 66

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

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

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

С чего начинается работа

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

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

Именно после этих двух шагов появляется право всерьёз говорить о проектировании СЗИ. До этого момента все разговоры о конкретных мерах почти всегда преждевременны.

Как выглядит основной маршрут

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

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

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

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

Документы и контрольные точки по пути

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

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

Отдельная контрольная точка появляется уже после получения аттестата соответствия: сведения по аттестованной СЗИ и установленные материалы должны быть представлены в ОАЦ в установленный срок. Этот момент нельзя оставлять “на потом”, потому что он уже относится не к проектной дисциплине, а к исполнению установленного порядка.

Нормативная база

• Указ Президента Республики Беларусь № 449 от 09.12.2019 — базовый акт, во исполнение которого принят приказ ОАЦ № 66. Источник
• Приказ ОАЦ № 66 от 20.02.2020 в редакции приказа ОАЦ № 259 от 10.12.2024 — задаёт порядок ТКЗИ в ИС и порядок аттестации СЗИ ИС. Источник
• Приказ ОАЦ № 259 от 10.12.2024 — закрепляет новую редакцию положений, применяемую по ТКЗИ и аттестации с 1 марта 2025 года. Источник
• Рекомендации ОАЦ по ТКЗИ в ИС — официально поясняют практическую логику этапов работ и отражают, в том числе, сроки представления сведений после получения аттестата соответствия. Источник

Где обычно всё ломается

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

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

Вывод

Самостоятельное проектирование, создание и аттестация СЗИ по приказу № 66 — это не набор разрозненных задач, а маршрут, в котором порядок действий критичен. Если идти по нему последовательно, владелец ИС получает управляемый процесс: от понимания системы к проектным решениям, от решений к реализации, от реализации к подтверждаемому результату. Если же пытаться решать всё одновременно, приказ № 66 превращается не в опору, а в источник постоянной путаницы.