Приказ ОАЦ № 66: что он регулирует и как его правильно читать

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

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

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

Не перечень галочек, а каркас процесса

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

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

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

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

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

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

В этом смысле приказ № 66 — документ не столько про требования, сколько про последовательность мышления. Он заставляет переходить от абстрактной “защиты вообще” к защите конкретной системы с конкретной архитектурой и конкретными проверяемыми мерами.

Как приказ понимают неправильно

Практический сбой чаще всего выглядит одинаково. Организация принимает решение самостоятельно строить СЗИ, открывает приказ № 66 и почти сразу начинает обсуждать, какие продукты нужно поставить, какие приказы издать, какие журналы вести и как собрать комплект бумаг к аттестации. Внешне работа идёт, но на деле всё поставлено с ног на голову.

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

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

Что из этого следует владельцу ИС

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

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

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