Криптография в государственных системах: что меняет проект приказа ФСБ и что считать оператору уже сейчас

С 4 по 19 августа на regulation.gov.ru обсуждался проект приказа ФСБ России, который заменит действующий приказ от 18 марта 2025 года № 117 (идентификатор проекта 01/02/08-26/00169883). Николай Лобанов, независимый эксперт по информационной безопасности и защите критической информационной инфраструктуры специально для читателей Кибер Медиа разобрал проект по пунктам.

Что меняется по сфере действия

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

Пояснительная записка к проекту называет причину прямо: Федеральный закон от 29 декабря 2025 года № 568-ФЗ, который внёс изменения в закон об информации. Проект готовил 8 Центр ФСБ России.

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

Для практика это означает вот что. Раньше разговор шёл про систему как целое. Теперь в периметр прямо попадают компоненты, на которых система создаётся и эксплуатируется. Если вы поставляете в государственную систему платформу, среду разработки или СУБД, разговор о классе криптосредств теперь тоже ваш.

Сам приказ занимает три страницы. Он утверждает Требования, перечисляет исключения (системы Администрации Президента, Совета Безопасности, Федерального Собрания, Правительства, Конституционного и Верховного судов, самой ФСБ, а также системы с государственной тайной) и отменяет приказ № 117. Нормативное содержание находится в приложении, в Требованиях на девять страниц и восемнадцать пунктов.

Когда криптография становится обязательной

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

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

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

Модель угроз перестаёт быть формальностью

Два пункта проекта делают модель угроз главным документом проекта системы, а не приложением к отчётности.

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

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

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

Ещё один пункт того же ряда, пункт 5. Если документация на СКЗИ этого требует, в отношении аппаратных, программно-аппаратных и программных средств, вместе с которыми криптосредство будет штатно работать, проводится оценка влияния на выполнение предъявляемых к СКЗИ требований. Проводит её организация, уполномоченная на криптографические, инженерно-криптографические и специальные исследования СКЗИ по Положению ПКЗ-2005, утверждённому приказом ФСБ России от 9 февраля 2005 года № 66. Своими силами оператор или интегратор эту работу закрыть не может. Это отдельная работа со своим сроком, и в план проекта её нужно ставить заранее.

Как считается класс СКЗИ

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

• Шаг первый. Определяем уровень значимости информации. Его определяет обладатель информации или оператор, по степени возможного ущерба от нарушения конфиденциальности, целостности или доступности. Уровень высокий, если при нарушении хотя бы одного из этих свойств оператор или обладатель информации не могут выполнять возложенные на них функции. Средний, если не могут выполнять хотя бы одну функцию. Низкий, если функции выполняются, но с привлечением дополнительных сил и средств.
• Шаг второй. Определяем масштаб системы или сегмента: вся страна либо два и более субъекта Российской Федерации, один субъект, либо одно муниципальное образование или объекты одного государственного органа, предприятия, учреждения.
• Шаг третий. Смотрим таблицу приложения к Требованиям, она в материалах проекта отдельным файлом. При высоком уровне значимости получается КВ на федеральном масштабе, КС3 в пределах субъекта и КС2 на уровне муниципалитета или объектов одного органа. При среднем уровне: КС3, КС3 и КС1 соответственно. При низком: КС2, КС1 и КС1.
• Шаг четвёртый, где таблица перестаёт быть последним словом. Пункты с 11 по 15 поднимают класс в зависимости от того, что вы сами записали в модель угроз про возможности источника атак. Если источник может готовить и проводить атаки только вне контролируемой зоны, нужен КС1 и выше. Если внутри контролируемой зоны, но без физического доступа к аппаратным средствам, КС2 и выше. Если внутри с физическим доступом, КС3 и выше. Если источник может привлекать специалистов по разработке и анализу СКЗИ, включая анализ побочных электромагнитных излучений и наводок и использование недокументированных возможностей прикладного программного обеспечения, требуется КВ и выше. Если специалистов по недокументированным возможностям аппаратного и программного компонентов среды функционирования СКЗИ, то КА.

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

Ещё три пункта закрывают частые вопросы. Пункт 9: при взаимодействии с другими системами класс определяется по наиболее высокому классу среди взаимодействующих. Пункт 10: в системе из сегментов класс для взаимодействия сегментов между собой берётся не ниже наименьшего из классов этих сегментов. Пункт 16: для взаимодействия граждан с системой класс может быть ниже, чем определённый для самой системы, исходя из актуальных угроз. Пункт 17: если другой нормативный акт требует более высокого класса, применяется он.

Организационная часть, которую обычно недооценивают

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

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

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

Внутренний контроль раз в три года

Пункт 18 вводит внутренний контроль выполнения Требований. Оператор организует его сам либо с привлечением по договору лицензиата по пункту 1 части 1 статьи 12 закона о лицензировании. Периодичность: не реже одного раза в три года, конкретные сроки определяет оператор.

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

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

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

Чего в проекте нет?

Два места я считаю пробелами и написал об этом в замечаниях 18 августа.

Первое: нет регламента на случай недоступности криптографической инфраструктуры. Работа защищённой системы зависит от того, доступны ли средства проверки электронной подписи, средства установления защищённых соединений, инфраструктура управления ключами и сертификатами. Если криптографическую операцию выполнить нельзя, система или её отдельные функции останавливаются, и что делать оператору в этот момент, из проекта не следует. Я предложил предусмотреть порядок действий при такой недоступности с фиксацией её периодов в журналах и требования к резервированию компонентов криптографической инфраструктуры. Похожий подход уже поддержан другим разработчиком: в проекте правил возмещения из антифрод-пакета Минцифры, 02/07/07-26/00169315, моё предложение о приостановлении сроков на период недоступности государственной информационной системы отмечено учтённым.

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

Оба замечания на момент написания статьи числятся на портале необработанными. Процедура здесь не оценка регулирующего воздействия, а раскрытие информации, поэтому заключения об ОРВ не будет. Сводка предложений с позицией разработчика будет: этого требует пункт 20 Правил, утверждённых постановлением Правительства от 25 августа 2012 года № 851, и разместить её нужно не позднее дня направления проекта на согласование.

Что делать оператору сейчас?

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

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