Госсектор

У ИБ-отдела особый класс секретов: доступы к SIEM, EDR, SOAR, аварийные учётные записи, SSH-ключи критичной инфраструктуры. Их чувствительность определяется не только содержимым, но и тем, что они раскрывают — архитектуру защиты и внутреннюю структуру безопасности.

Хранить такие секреты можно двумя способами:

• Для большинства компаний достаточно логической изоляции: одна инсталляция Пассворка с типами сейфов, ролями, MFA, LDAP/SSO и аудитом. Секреты разделены по назначению и владельцам, доступ разграничен через права и группы.
• Физическая изоляция (отдельный экземпляр Пассворка для ИБ-контура) нужна там, где данные должны быть скрыты от администраторов общего контура не только на уровне прав, но и на уровне самого факта существования: названий сейфов, структуры папок и журналов активности.

Физическая изоляция наиболее полно реализует принцип нулевого доверия (Zero Trust) через разделение полномочий. В этой модели ИТ-администраторы полностью исключаются из цепочки доверия, а управление системой переходит исключительно к ИБ-администраторам.

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

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

Какие секреты хранит ИБ-отдел и почему их нельзя смешивать с обычными доступами

ИБ-секреты отличаются от доступов кадрового отдела, финансов или проектных команд не только уровнем критичности, но и характером чувствительности. Компрометация пароля от корпоративного SaaS — это инцидент. Компрометация доступа к SIEM или EDR — это потенциальная потеря контроля над всей защитной инфраструктурой.

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

Какие секреты требуют особого режима хранения

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

Один экземпляр Пассворка с типами сейфов: когда этого достаточно

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

Одна инсталляция — рациональный стандарт по умолчанию. Она проще в эксплуатации: одно обновление, один процесс резервного копирования, одна интеграция с LDAP/AD и SAML SSO, один регламент. При этом уровень контроля над доступом может быть весьма детальным.

Модель типов сейфов

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

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

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

Роли и группы позволяют разграничить доступ подразделений без ручной настройки каждого пользователя. Интеграция с AD/LDAP упрощает добавление новых пользователей и отзыв доступов: сотрудник уходит — доступ отзывается через синхронизацию с каталогом. SAML SSO снижает трение при ежедневной работе. MFA и журнал действий обеспечивают контроль.

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

Два независимых экземпляра Пассворка: когда нужна физическая изоляция

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

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

Что даёт физическая изоляция

• Устойчивость к ошибкам. Ошибка в правах доступа в общем корпоративном контуре не раскрывает ИБ-секреты. Контуры физически разделены: некорректная настройка в одном не затрагивает другой.
• Закрытые метаданные. Администраторы общего контура не видят структуру ИБ-сейфов: ни названий, ни папок, ни активности. ИТ-администратор бизнес-экземпляра Пассворка не знает, какие системы и инструменты находятся под управлением ИБ-команды.
• Независимые администраторы. ИБ управляет своим экземпляром самостоятельно без пересечения с ИТ-администраторами общего контура. Каждая команда настраивает свой экземпляр независимо и не имеет прав в чужом контуре.
• Независимые политики. ИБ применяет собственные настройки: более жёсткие требования к MFA, короткий таймаут сессии, запрет офлайн-доступа, ограничения на экспорт, отдельные правила API-доступа — без компромиссов с требованиями бизнес-подразделений.
• Чистый журнал. ИБ-инсталляция фиксирует только события ИБ-команды без фонового шума от финансов, продаж и подрядчиков. Это упрощает расследования и сокращает время на анализ.
• Прозрачность для аудита. Контур проще описывать в документах модели угроз, при прохождении сертификации и внешних аудитов — в том числе по требованиям ФСТЭК и для объектов КИИ. Разделение контуров часто является требованием регулятора.

Когда ИБ-контур требует закрытой сети

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

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

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

Сравнение двух моделей

Локальный ИБ-инстанс и облако для бизнеса

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

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

Разделение доступов

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

Отдельный DevOps/SRE-контур: чем он отличается от ИБ-контура

DevOps-контур изолируется по другим причинам, чем ИБ-контур. ИБ-секреты требуют изоляции из-за конфиденциальности, независимого администрирования и требований к аудиту расследований. DevOps-секреты — из-за автоматизации, высокой частоты ротации, машинного потребления через API, CLI и SDK, а также большого числа интеграций с CI/CD-пайплайнами.

В одном инстансе можно создать тип сейфов «DevOps/CI-CD» и назначить команду разработчиков его администраторами. Отдельная DevOps-инсталляция оправдана при большом объёме машинных секретов, высокой частоте ротации и независимой команде разработки, которая должна управлять своим контуром без зависимости от общих администраторов.

Пассворк поддерживает API-first подход, CLI и SDK для работы с секретами, включая сценарии миграции, аудита и CI/CD-интеграций. Подробнее — в разделе документации «Пассворк как менеджер секретов».

Сравнение сценариев

Как выбрать архитектуру: один или два контура

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

Критерии выбора архитектуры хранения секретов

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

Как внедрить выбранную модель

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

1. Классифицировать секреты. Разделить данные на категории: обычные, ИБ-критичные, инфраструктурные, DevOps, аварийные. После этого понятно, какие данные требуют какого уровня изоляции.
2. Определить владельцев. Назначить ответственного бизнес- или технического владельца для каждого типа. У каждой категории секретов появляется ответственный.
3. Оценить чувствительность метаданных. Проверить, где опасны даже названия систем, папок и сейфов. Это покажет, где логической изоляции недостаточно.
4. Определить допустимых администраторов. Решить, кто может управлять контуром и кто не должен иметь технической видимости. Результат: понятная модель доверия и границы администрирования.
5. Выбрать модель. Одна инсталляция, две локальные, локальный ИБ-контур плюс облачный бизнес-контур или отдельный контур разработки. Архитектурное решение принято и обосновано.
6. Спроектировать типы сейфов. Создать целевую структуру сейфов, ролей, групп и правил создания. Итог: схема, которую можно реализовать и задокументировать.
7. Настроить интеграции. LDAP/SSO, MFA, API/CLI/SDK, SIEM, резервное копирование и мониторинг. Каждая интеграция получает чёткие границы и ответственного.
8. Ввести регулярную проверку прав. Проверять права, администраторов, журналы и структуру сейфов после изменений в командах и инфраструктуре.

Правильная архитектура начинается с классификации

Число инсталляций — следствие требований к изоляции. Одна инсталляция с продуманной моделью типов сейфов, ролями, LDAP/SSO, MFA и журналом действий закрывает потребности большинства компаний. Две инсталляции нужны там, где физическая изоляция данных, независимые администраторы и отдельный аудит — это обоснованное требование.

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

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

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

Часто задаваемые вопросы

Нужна ли ИБ-отделу отдельная инсталляция Пассворка?

Отдельный инстанс необходим, если ИБ-отдел хранит секреты, которые не должны быть видны администраторам общего контура даже на уровне структуры: доступы к SIEM, EDR, SOAR, сканерам, аварийные доступы, SSH-ключи, API-токены и сервисные пароли. Если таких требований нет, достаточно одной инсталляции с типами сейфов, ролями, MFA и аудитом.

Когда достаточно одной инсталляции Пассворка?

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

Чем физическое разделение лучше настройки прав доступа?

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

Что такое типы сейфов в Пассворке?

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

Может ли администратор общего инстанса видеть ИБ-сейфы?

Это зависит от модели ролей и прав, настроенных в системе. В Пассворке администратор может видеть список всех сейфов в системе, включая их названия и состав пользователей, если ему выданы полные права. Если сам факт существования ИБ-сейфов, их структура или названия не должны быть видны общему администрированию, нужно перенастроить систему ролей или рассмотреть отдельный ИБ-контур.

Как разделить личные, командные и инфраструктурные пароли?

Начните с классификации секретов, определите владельцев и создайте типы сейфов: личные, командные, ИТ, ИБ, DevOps, проектные и сервисные аккаунты. Для каждого типа задайте администраторов, права, MFA, аудит и даты аудита.

Как организовать аудит действий ИБ-команды?

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

Какие секреты нельзя хранить в общих сейфах?

В общих сейфах не стоит хранить аварийные учётные записи, root/admin-доступы, токены EDR/SIEM/SOAR, SSH-ключи критичной инфраструктуры, API-ключи облаков и секреты, раскрытие метаданных которых может навредить безопасности.

Как понять, что компании пора переходить от одной инсталляции к двум?

Триггеры перехода: апрет на видимость ИБ-метаданных ИТ-администраторами, требование независимого аудита ИБ-действий, регуляторные требования (ФСТЭК, КИИ), необходимость применения более жестких политик безопасности (MFA, сессии, экспорт) или выделение изолированного DevOps/SRE-контура.

Пассворк 7.1: типы сейфов

Типы сейфов В Пассворк 7.1 управление доступом стало более гибким благодаря системе типов сейфов. Типы сейфов решают главную проблему администраторов — как контролировать доступ к данным и делегировать управление сейфами в большой компании. Ранее выбор был ограничен двумя типами. Теперь можно создавать собственные типы сейфов под любые задачи и структуру

Блог ПассворкаИлья Шелыгин

Кейс-стади: МТС Банк и Пассворк

Как МТС Банк объединил управление паролями в единой системе с помощью Пассворка и повысил уровень безопасности.

Блог ПассворкаАнастасия Лебедева

Импортозамещение ИБ-решений (СЗИ): переход на российское ПО

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

Блог ПассворкаАнастасия Лебедева

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

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

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

Разбираем весь стек: стандарты и OID-ы, механику шифрования, точки отказа при интеграции, нормативные требования с конкретными ссылками.

Главное

• Актуальный ГОСТ-стек — четыре стандарта. «Кузнечик» и «Магма» — шифрование, «Стрибог» — хеширование, ГОСТ Р 34.10-2012 — подпись и согласование ключей, ГОСТ Р 34.13-2015 — режимы работы включая CTR-ACPKM. Всё остальное — устаревшие версии или режимы этих четырёх.
• Асимметричная криптография в ГОСТ данные не шифрует. ГОСТ Р 34.10-2012 формирует подпись и вырабатывает общий ключ по VKO. Шифрование данных — всегда симметричное, «Кузнечиком».
• «Магма» — не для шифрования данных. 64-битный блок создаёт риск атаки SWEET32 при объёме ~32 ГБ на ключ. Область применения — имитовставка и Key Wrap внутри CMS.
• openssl-gost-engine и КриптоПро — для разных задач. openssl-gost-engine не является сертифицированным СКЗИ. Для аттестованных систем и работы с КЭП нужен сертифицированный стек.
• Класс СКЗИ определяет модель угроз, а не администратор. Установить ПО с сертификатом КС2 без выполнения организационных требований этого класса — значит классу не соответствовать.
• Лицензия ФСБ нужна при работе с клиентами. Использовать КриптоПро для внутренних нужд можно без лицензии. Встроить СКЗИ в продукт для клиентов или обслуживать СКЗИ у клиентов — лицензируемая деятельность по ПП РФ № 313.
• ГОСТ затрагивает весь стек. Меняются TLS-профиль, форматы сертификатов, хранение ключей, клиентские приложения. Жизненный цикл КЭП требует отдельных процессов — сертификат действует год.
• Постквантовая миграция потребует переработки крипто-слоя. Российские постквантовые стандарты ожидаются в 2026–2027 годах. Проектируйте крипто-слой с абстракцией над алгоритмом — иначе миграция затронет всю кодовую базу.

Что такое ГОСТ-алгоритмы

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

В отличие от международных стандартов NIST (AES, SHA) и RSA, ГОСТ-алгоритмы построены на независимых математических основаниях и прошли отдельный криптоанализ. Для государственных информационных систем, объектов критической инфраструктуры и организаций под надзором ФСБ и ФСТЭК применение ГОСТ-криптографии является нормативным требованием.

Ключевые отличия от западных стандартов

Как устроены ГОСТ-алгоритмы: четыре стандарта и их OID-ы

OID (Object Identifier) — числовой идентификатор вида 1.2.643.7.1.1.5.2, который криптобиблиотеки и сертификаты используют для обозначения алгоритма. Когда OpenSSL встречает в сертификате незнакомый OID, он не может его обработать — отсюда unknown signature algorithm при вызове openssl verify без ГОСТ-движка. OID-ы нужно знать, когда разбираешь совместимость или отлаживаешь парсинг.

Весь актуальный ГОСТ-стек строится на четырёх стандартах — остальное либо устаревшие версии, либо режимы работы этих четырёх.

ГОСТ Р 34.12-2015: «Кузнечик» и «Магма»

ГОСТ Р 34.12-2015 — национальный стандарт Российской Федерации, устанавливающий алгоритмы двух блочных симметричных шифров: «Кузнечик» с размером блока 128 бит и «Магма» с размером блока 64 бита. Стандарт фиксирует математические конструкции, параметры и допустимые режимы работы, чтобы реализации от разных производителей СКЗИ давали идентичный результат и могли взаимодействовать без потери криптографической стойкости.

Кузнечик (RFC 7801, OID 1.2.643.7.1.1.5.2) — основной шифр для защиты данных. 128-битный блок, 256-битный ключ, SP-сеть (Substitution-Permutation) с 10 раундами.

Архитектура та же, что у AES: нелинейная замена байт плюс линейное перемешивание на каждом раунде. Принципиальное отличие от AES — отсутствие аппаратного ускорения на массовых процессорах. AES-NI встроен в каждый Intel/AMD с 2010 года, для «Кузнечика» аналог есть только в специализированных СКЗИ. На больших объёмах данных разрыв в производительности становится заметным.

Магма (RFC 8891, OID 1.2.643.7.1.1.5.1) — ГГОСТ 28147-89 с зафиксированными таблицами подстановок. 64-битный блок, 256-битный ключ, 32 раунда.

Размер блока определяет границу безопасного применения. При шифровании порядка 2³² блоков одним ключом (~32 ГБ) вероятность того, что два разных блока открытого текста дадут одинаковый шифртекст, становится статистически значимой (парадокс дней рождений и атака «дней рождений»). Наблюдатель, накапливающий зашифрованный трафик, может использовать эти совпадения для восстановления данных (атака SWEET32).

Поэтому «Магма» не шифрует данные. Её область применения — операции с заведомо малыми объёмами: имитовставка (выработка кода аутентификации сообщения, который подтверждает целостность и подлинность данных) и упаковка ключа (Key Wrap, шифрование одного ключа другим) внутри CMS.

ГОСТ Р 34.11-2012 «Стрибог»: хеширование

ГОСТ Р 34.11-2012 «Стрибог» (RFC 6986) — хеш-функция. OID 256-битного варианта — 1.2.643.7.1.1.2.2, 512-битного — 1.2.643.7.1.1.2.3. В 2018 году «Стрибог» вошёл в ISO/IEC 10118-3 — это единственный российский криптографический алгоритм с международной стандартизацией на уровне ISO.

256-битный вариант закрывает большинство задач. 512-битный применяется там, где данные должны оставаться защищёнными через 15–20 лет: долгосрочные архивы, юридически значимые документы.

ГОСТ Р 34.10-2012: электронная подпись и выработка ключа

ГОСТ Р 34.10-2012 (RFC 7091) — алгоритм электронной подписи на эллиптических кривых, используемый во всех российских криптографических профилях. OID 256-битного варианта — 1.2.643.7.1.1.1.1, 512-битного — 1.2.643.7.1.1.1.2.

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

Ключевое архитектурное отличие от RSA: асимметричная криптография в российской модели данные не шифрует. Она решает две задачи — формирование подписи и выработка общего ключа по протоколу VKO (Выработка Ключа Общего). VKO — российский аналог Diffie-Hellman: обе стороны обмениваются открытыми частями и независимо вычисляют один и тот же секрет, не передавая его по каналу. Шифрование данных всегда симметричное — «Кузнечиком».

CTR-ACPKM: механизм без западного аналога

ГОСТ Р 34.13-2015 вводит режим CTR-ACPKM (OID 1.2.643.7.1.1.4.2 для «Кузнечика», 1.2.643.7.1.1.4.3 для «Магмы»). Он решает проблему, которую стандартный CTR не решает.

CTR шифрует последовательный счётчик и накладывает результат на данные по XOR. Чем дольше работает один ключ, тем больше статистики накапливает наблюдатель — и тем выше риск атаки. ACPKM (Acyclic Pseudo-random Key Modification) периодически перегенерирует внутренние раундовые ключи прямо в процессе шифрования. Для прикладного кода это невидимо: ключ в API не меняется, поведение интерфейса не меняется. Меняется только внутреннее состояние шифра.

Прямого аналога в западных стандартах нет. Конкретные лимиты данных на ключ и обязательность ACPKM определяет профиль протокола: PKCS#5/PBES2 — RFC 9337, TLS 1.2 — RFC 9189, TLS 1.3 — RFC 9367.

Как работает ГОСТ-шифрование изнутри

ГОСТ использует гибридную схему. Стороны вырабатывают общий симметричный ключ по открытому каналу через протокол VKO — российский аналог Diffie-Hellman на эллиптических кривых. Данные шифруются этим симметричным ключом («Кузнечиком»), но не напрямую: сначала симметричный ключ упаковывается в отдельный зашифрованный контейнер — Key Wrap. Получатель сначала распаковывает ключ, затем расшифровывает данные.

Всё это происходит внутри формата CMS (Cryptographic Message Syntax) — стандартной ASN.1-структуры для зашифрованных и подписанных сообщений (RFC 5652). CMS — это то, что СКЗИ фактически передаёт при шифровании файлов и почты: не просто шифртекст, а контейнер, в котором упакованы зашифрованный ключ, параметры алгоритма и сами данные.

Схема шифрования в формате ГОСТ

Отправитель:

1. Генерирует эфемерную пару ключей (ec_ephemeral_priv, ec_ephemeral_pub). «Эфемерная» — одноразовая: создаётся для одного сообщения и уничтожается после использования. При реальном уничтожении это даёт прямую секретность (forward secrecy): если завтра утечёт основной ключ, вчерашние сообщения расшифровать не получится.
2. Генерирует случайный CEK (Content Encryption Key, 256 бит) — симметричный ключ для шифрования данных.
3. Генерирует UKM (User Keying Material, 8 байт) — случайная соль, которая делает каждое соединение уникальным даже при одинаковых ключах.
4. Вырабатывает общий секрет по протоколу VKO: Z = VKO(ec_ephemeral_priv, recipient_pub_key, UKM). Обе стороны независимо вычисляют одну и ту же точку на эллиптической кривой, не передавая секрет по каналу.
5. Выводит ключ шифрования ключа через KDF: KEK = HKDF-Стрибог(Z, UKM, ...) KDF (функция выработки ключа) превращает сырой общий секрет Z в ключ нужной длины. KEK (Key Encryption Key) используется для шифрования CEK.
6. Упаковывает CEK: WrappedCEK = Магма-CBC-MAC(CEK) + Магма-ECB(CEK) на KEK CEK шифруется на KEK алгоритмом «Магма» с добавлением имитовставки для контроля целостности.
7. Шифрует данные: CipherText = Кузнечик-CTR(CEK, IV, plaintext)
8. Формирует и отправляет CMS EnvelopedData: {ec_ephemeral_pub, UKM, WrappedCEK, IV, CipherText}
9. ec_ephemeral_priv уничтожается.

Получатель:

1. Вычисляет тот же общий секрет: Z = VKO(recipient_priv_key, ec_ephemeral_pub, UKM)
2. Выводит тот же KEK через KDF.
3. Распаковывает CEK (Key Unwrap): проверяет имитовставку, расшифровывает CEK на KEK.
4. Расшифровывает данные на CEK.

Три момента, которые часто упускают

• VKO — это не просто ECDH. В стандартном ECDH стороны перемножают ключи. В VKO дополнительно учитываются UKM и идентификатор алгоритма — это влияет на итоговый общий секрет. КриптоПро и ViPNet исторически интерпретировали некоторые детали по-разному, отсюда проблемы совместимости при межсистемном взаимодействии.
• Key Wrap через «Магму» обязателен по стандарту — даже если основные данные шифруются «Кузнечиком». Старый ГОСТ Key Wrap описан в RFC 4357; для сценариев с PBES2/PBKDF2 — RFC 9337.
• UKM должен быть настоящим случайным материалом из ГПСЧ СКЗИ (аппаратный или программный генератор псевдослучайных чисел, сертифицированный ФСБ). Детерминированное значение или нули в UKM — схема формально работает, но теряет часть защитных свойств.

openssl-gost-engine: что работает, что нет

Для разработки и несертифицированных сценариев подходит openssl-gost-engine. Но здесь есть контекст, который обычно упускают в инструкциях.

ENGINE API устарел

OpenSSL поддерживает два способа подключить сторонние алгоритмы:

• Engine API — динамически загружаемый .so-файл, регистрирующий реализации через устаревший внутренний интерфейс
• Provider API — более изолированная архитектура, представленная в OpenSSL 3.0

OpenSSL 3.0 пометил Engine API как deprecated. gost-engine по-прежнему использует именно его — миграция на Provider API идёт (issue #496), но неспешно. В OpenSSL 4.0 ENGINE API уберут. Пока работает, но это нужно учитывать при планировании.

Поддержка по дистрибутивам

Сборка (Debian 12 / Ubuntu 24.04)

# CMake >= 3.18 обязателен для OpenSSL 3.x
sudo apt install cmake libssl-dev git

git clone https://github.com/gost-engine/engine gost-engine
cd gost-engine
git submodule update --init
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
cmake --build . --config Release
sudo cmake --install .

Путь к .so непредсказуем — всегда проверяйте:

find /usr /lib /usr/local -name "gost.so" 2>/dev/null

Настройка openssl.cnf

Добавьте в начало файла:

openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/gost.so
default_algorithms = ALL

CRYPT_PARAMS, встречающийся в старых инструкциях — устаревший параметр для ГОСТ 28147-89, сейчас не нужен.

# Проверка что движок живой
openssl engine -t gost

# Актуальные имена cipher suites (они менялись между версиями движка)
openssl ciphers | tr ':' '\n' | grep -i gost
# GOST2012-KUZNYECHIK-KUZNYECHIKOMAC, GOST2012-MAGMA-MAGMAOMAC, ...

Ключи и подпись

# paramset:A — параметры эллиптической кривой (конкретная кривая из стандарта).
# ГОСТ определяет несколько предопределённых наборов (A, B, C и ещё несколько),
# paramset:A — стандартный выбор для большинства задач.
openssl genpkey -algorithm gost2012_256 \
  -pkeyopt paramset:A \
  -out gost_private.pem

# Самоподписанный сертификат для тестов
openssl req -x509 -newkey gost2012_256 \
  -pkeyopt paramset:A \
  -nodes -keyout key.pem -out cert.pem \
  -md_gost12_256 \
  -subj "/C=RU/CN=test"

# Подпись и проверка
openssl dgst -md_gost12_256 -sign gost_private.pem \
  -out signature.bin document.pdf

openssl dgst -md_gost12_256 -verify gost_public.pem \
  -signature signature.bin document.pdf

Python: PyGOST

from pygost.gost3412_2015 import GOST3412Grasshopper
from pygost.gost34112012 import GOST34112012256

h = GOST34112012256(b"hello, gost")
print(h.hexdigest())

key = bytes(range(32))
cipher = GOST3412Grasshopper(key)
encrypted = cipher.encrypt(bytes(16))

API менялся между версиями 6.x и 7.x — проверяйте документацию при обновлении.

КриптоПро и сертифицированный стек

Когда нужна сертификация ФСБ — openssl-gost-engine не подходит. Нужны коммерческие средства криптографической защиты информации (СКЗИ): сертифицированные криптобиблиотеки и HSM-устройства.

КриптоПро CSP 5.0 — стандарт. Под Windows работает через CryptoAPI, под Linux — через собственный демон cprocspd. Есть версии для Astra Linux, Альт, РЕД ОС.

Конфигурация OpenSSL для КриптоПро:

[openssl_init]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /opt/cprocsp/lib/amd64/cp_gost.so
default_algorithms = ALL

Хранение ключей

Ключи хранятся в /var/opt/cprocsp/keys/<username>/. Ключевой контейнер — это директория из шести файлов, а не один файл:

container_name.000/
├── header.key
├── masks.key
├── masks2.key
├── name.key
├── primary.key
└── primary2.key

ViPNet CSP — альтернатива от ИнфоТеКС. На уровне PKCS#11 и CryptoAPI совместим с КриптоПро, но детали VKO реализованы немного иначе. При межсистемном взаимодействии (КриптоПро на одной стороне, ViPNet на другой) — проверяйте матрицу совместимости на tc26.ru перед выбором архитектуры. Там публикуются протоколы испытаний. Известен случай, когда Континент TLS Client 2 не распознавал КриптоПро CSP 5 как провайдера.

Где ломается интеграция

nginx и ГОСТ TLS

Долгое время ГОСТ-криптография в TLS была ограничена версией 1.2: RFC 9189 определяет наборы шифров (cipher suites) и механизмы согласования ключей именно для этого протокола. В 2022 году вышел RFC 9367, распространивший поддержку ГОСТ на TLS 1.3.

На практике разрыв между стандартом и реализацией остаётся значительным. Большинство сертифицированных СКЗИ по состоянию на 2026 год работают с TLS 1.2 — фактическая поддержка TLS 1.3 зависит от конкретного стека, версии криптобиблиотеки и браузера. Актуальный статус уточняйте у поставщика СКЗИ.

КриптоПро CSP 5.0 R2 поставляет патченный nginx (cpnginx):

ssl_certificate     /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;

ssl_protocols TLSv1.2;
ssl_ciphers GOST2012-KUZNYECHIK-KUZNYECHIKOMAC:GOST2012-MAGMA-MAGMAOMAC:LEGACY-GOST2012-GOST8912-GOST8912;
ssl_prefer_server_ciphers on;

Проблема с кешем сессий. Общий кеш TLS-сессий между воркерами не работает. Каждый воркер держит свой кеш — при балансировке между ними происходит полный handshake. Директива ssl_session_cache shared:SSL:10m; работает не так, как ожидается. Решения: включить ssl_session_tickets on; или вынести TLS-терминацию на выделенный шлюз (NGate, С-Терра, Континент TLS).

Второй вариант — поставить ГОСТ-шлюз перед обычным nginx. Он терминирует ГОСТ TLS, дальше идёт обычный HTTPS. Заодно решает проблему с session cache и убирает из nginx зависимость от СКЗИ.

Браузеры

Chromium и Firefox ГОСТ не поддерживают. Для пользовательского доступа к ГОСТ-сайтам нужен Яндекс Браузер или Chromium-GOST — open-source форк, есть Linux-сборки.

Важно разделять две разные задачи: ГОСТ TLS (защита соединения) и подпись документов в браузере. Для второго нужно расширение КриптоПро ЭЦП Browser Plugin — отдельный компонент, никак не связанный с TLS.

Docker

КриптоПро в контейнере требует конкретных флагов, без которых cprocspd не стартует:

docker run -d \
  --privileged \
  --security-opt seccomp=unconfined \
  --tmpfs /run \
  --tmpfs /run/lock \
  -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
  my-cryptopro-image

--tmpfs /run и --tmpfs /run/lock обязательны — без них cprocspd не создаёт lock-файлы. Ключи монтируются через volume:

volumes:
  - /var/opt/cprocsp/keys:/var/opt/cprocsp/keys:ro

Лицензия привязана к физическому хосту, а не к контейнеру. Пересоздание контейнера повторной активации не требует — смена хоста требует. Тестовая лицензия активируется автоматически на 3 месяца.

Если сертификация не нужна, проще использовать openssl-gost-engine в контейнере — без лицензионных ограничений. В репозитории gost-engine есть готовые Dockerfile для Debian и Alpine.

Сертификаты

ГОСТ-сертификаты формально являются X.509, но без ГОСТ-движка их не прочитать:

Signature Algorithm: GOST R 34.11-2012 with GOST R 34.10-2012 (256 bit)
  OID: 1.2.643.7.1.1.3.2
Public Key Algorithm: GOST R 34.10-2012 (256 bit)
  OID: 1.2.643.7.1.1.1.1
  Parameters: GOST R 34.10-2012 256-bit ParamSet A
    OID: 1.2.643.7.1.2.1.1.1

openssl verify без движка выдаст unknown signature algorithm. Это ошибка среды, не сертификата.

Классы СКЗИ: КС1, КС2, КС3

ФСБ устанавливает шесть классов защиты СКЗИ — КС1, КС2, КС3, КВ1, КВ2, КА1. Шкала идёт от минимальных программных требований до защиты от атак спецслужб с физическим доступом к оборудованию. Для большинства коммерческих задач актуальны первые три.

Требуемый класс определяется моделью угроз — документом, который составляется при аттестации системы и описывает актуальные векторы атак. Именно модель угроз диктует минимально допустимый класс СКЗИ, а не выбор администратора.

КЭП и форматы подписей

Квалифицированная электронная подпись (КЭП) по Федеральному закону № 63-ФЗ «Об электронной подписи» — строго регламентированная конструкция: алгоритм ГОСТ Р 34.10-2012, сертифицированное СКЗИ, сертификат от аккредитованного удостоверяющего центра (УЦ). С 2022 года КЭП юридических лиц выдаёт УЦ ФНС России.

Форматы подписей:

• CAdES (Advanced Electronic Signatures поверх CMS) — основной стандарт для государственных систем, СМЭВ, ФНС и большинства регуляторных интеграций.
• XAdES — то же самое для XML-документов.
• PAdES — подпись встраивается непосредственно в PDF-файл, без отдельного файла подписи.

Реализовывать эти форматы с нуля не нужно — существуют готовые решения. КриптоПро PDF и Office Signature закрывают задачи подписания документов. КриптоПро CAdES BES/T используется для интеграции со СМЭВ. КриптоПро DSS обеспечивает серверную подпись через REST API — актуально для систем, где подписание происходит на стороне сервера без участия пользователя.

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

Постквантовый горизонт

ГОСТ Р 34.10-2012 уязвим к алгоритму Шора — как RSA и ECDSA. Квантовый компьютер достаточной мощности появится не раньше 2030–2035 годов по оптимистичным оценкам. Однако уже сейчас актуальна стратегия «harvest now, decrypt later»: противник перехватывает и сохраняет зашифрованный трафик сегодня, чтобы расшифровать его после появления нужных вычислительных мощностей. Для данных с горизонтом конфиденциальности 15+ лет это риск, который требует проработки уже на этапе проектирования.

Симметричные алгоритмы устойчивее. Алгоритм Гровера снижает стойкость симметричных шифров вдвое по экспоненте: 256-битный ключ «Кузнечика» деградирует до ~128-битной эффективной стойкости — уровня, который по-прежнему считается достаточным.

В российском контуре постквантовую стандартизацию ведёт технический комитет ТК 26. Компания «Криптонит» опубликовала реализацию постквантовой схемы «Шиповник» на основе кодовой криптографии. Выход российских стандартов ожидается в 2026–2027 годах.

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

Что ломается первым: пять системных проблем

1. ГОСТ затрагивает весь стек, а не один компонент. Хранение ключей, форматы сертификатов, TLS-профиль, форматы подписей, клиентские приложения, reverse proxy — всё это меняется. Большинство систем мониторинга не понимают ГОСТ TLS и просто не видят соединения.
2. интетические бенчмарки вводят в заблуждение. Реальная производительность складывается из TLS handshake + десериализация CMS + VKO + Key Unwrap + расшифровка. На бенчмарке вы измеряете только расшифровку.
3. Жизненный цикл ключей остаётся без внимания. Сертификат КЭП действует год. У ключевых носителей тоже есть срок. Нужны процессы: кто инициирует перевыпуск, кто едет в УЦ, как обновляется в системе, что происходит в переходный период.
4. openssl-gost-engine берут там, где нужна сертификация. Он технически корректен, но не является сертифицированным СКЗИ — это разные требования, и их нельзя смешивать.
5. Придумывают собственную схему поверх стандарта. «Мы берём Кузнечик, но упаковку ключей сделали по-своему» — ломает безопасность (нестандартные схемы не проходили криптоанализ), совместимость и юридическую легитимность.

Лицензии ФСБ и ФСТЭК

Граница лицензирования неочевидна — не потому что её прячут, а потому что она действительно нетривиальна.

Основной документ — Постановление Правительства РФ № 313 от 16.04.2012 (редакция от 28.08.2023). В приложении — 28 видов лицензируемой деятельности: разработка СКЗИ, производство, распространение, монтаж и настройка на объектах клиентов, техническое обслуживание для третьих лиц, услуги в области шифрования.

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

Если вы разрабатываете приложение, интегрируете в него КриптоПро CSP через API и передаёте это приложение клиентам — вы распространяете «защищённую с использованием шифровальных средств информационную систему» по смыслу п. 2 Постановления Правительства № 313. Это требует лицензии ФСБ на разработку и распространение СКЗИ — даже если само СКЗИ клиент приобретает напрямую у КриптоПро.

Разграничение регуляторов

ФСБ регулирует криптографию: шифрование, электронную подпись, управление ключами. ФСТЭК — техническую защиту информации без криптографии: межсетевые экраны, контроль доступа, DLP, аттестацию информационных систем.

Два основных вида лицензий ФСТЭК:

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

Требования к получению обеих лицензий:

• не менее 3 штатных сотрудников с профильным образованием в области информационной безопасности;
• аттестованное помещение;
• аттестованные автоматизированные рабочие места (АРМ) разработчиков;
• выездная проверка ФСТЭК.

Ответственность

• Ст. 13.13 КоАП («Незаконная деятельность в области защиты информации»): граждане — 500–1 000 руб., должностные лица — 4 000–5 000 руб., юрлица — 30 000–40 000 руб. с возможной конфискацией средств защиты информации. Суммы по ч. 1 выглядят небольшими, но конфискация СКЗИ и оборудования означает остановку деятельности.
• Ст. 14.1 КоАП: ч. 2 (деятельность без лицензии) — штраф для юрлиц 40 000–50 000 руб.; ч. 3 (грубое нарушение лицензионных требований при наличии лицензии) — штраф до 200 000 руб. или административное приостановление деятельности до 90 суток.
• Ст. 171 УК наступает при совокупности условий: предпринимательская деятельность без лицензии и либо причинение крупного ущерба (от 2 250 000 руб.), либо извлечение дохода в крупном размере (от 2 250 000 руб.). Ч. 1 — штраф до 300 000 руб. или арест до 6 месяцев. Ч. 2 (организованная группа или особо крупный размер — от 9 000 000 руб.) — до 5 лет лишения свободы.

Заключение

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

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

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

Часто задаваемые вопросы

Чем openssl-gost-engine отличается от КриптоПро CSP?

openssl-gost-engine — открытая реализация ГОСТ-алгоритмов для OpenSSL, подходящая для разработки и тестирования. КриптоПро CSP — коммерческое СКЗИ с сертификатом ФСБ. Для систем, требующих аттестации или работы с квалифицированной электронной подписью, openssl-gost-engine не подходит: наличие корректной реализации алгоритма и наличие сертификата — разные требования.

Почему «Магму» нельзя использовать для шифрования больших объёмов данных?

64-битный блок «Магмы» создаёт birthday bound: при шифровании ~32 ГБ одним ключом вероятность коллизии двух блоков становится статистически значимой. Это основа атаки SWEET32. «Магма» предназначена для операций с заведомо малыми объёмами — имитовставки и Key Wrap внутри CMS. Для шифрования данных используется «Кузнечик» с 128-битным блоком.

Нужна ли лицензия ФСБ, если КриптоПро встроен в продукт для клиентов?

Да. Встраивая СКЗИ в продукт и передавая его клиентам, вы распространяете «защищённую с использованием шифровальных средств информационную систему» по смыслу п. 2 Постановления Правительства РФ № 313 от 16.04.2012. Лицензия требуется даже если клиент приобретает СКЗИ у КриптоПро напрямую — факт встраивания и распространения уже образует лицензируемую деятельность.

Как правильно перенести ключевой контейнер КриптоПро?

Ключевой контейнер КриптоПро — это директория из шести файлов (header.key, masks.key, masks2.key, name.key, primary.key, primary2.key), а не один файл. При переносе копируется вся директория целиком из /var/opt/cprocsp/keys/<username>/. Перенос отдельных файлов не работает — контейнер станет нечитаемым.

Что такое forward secrecy в контексте ГОСТ CMS и зачем уничтожать эфемерный ключ?

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

Что изменится при переходе на постквантовые стандарты?

ГОСТ Р 34.10-2012 уязвим к алгоритму Шора — как RSA и ECDSA. Российские постквантовые стандарты ожидаются в 2026–2027 годах. «Кузнечик» с 256-битным ключом под алгоритмом Гровера деградирует до ~128-битной стойкости — этого по-прежнему достаточно. Главный практический вывод: проектируйте крипто-слой с абстракцией над алгоритмом — захардкоженные вызовы VKO с конкретными параметрами кривой превратят миграцию в болезненный рефакторинг всей кодовой базы.

Как работает ГОСТ TLS и какие браузеры его поддерживают?

ГОСТ TLS 1.2 стандартизирован в RFC 9189, TLS 1.3 — в RFC 9367 (2022). На практике большинство сертифицированных СКЗИ в 2026 году работают с TLS 1.2. Chromium и Firefox ГОСТ не поддерживают. Для пользовательского доступа к ГОСТ-сайтам подходят Яндекс Браузер или Chromium-GOST. Подпись документов в браузере — отдельная задача, требующая КриптоПро ЭЦП Browser Plugin, не связанного с TLS.

Чем ТЗКИ отличается от СЗКИ и когда нужна каждая лицензия ФСТЭК?

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

Импортозамещение КИИ в 2026: сроки, требования и план перехода

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

Блог ПассворкаИлья Шелыгин

Постквантовая криптография: угрозы и стандарты — 2026

Квантовые компьютеры ещё не взломали ни одного шифра, но атаки уже идут. Разбираем HNDL-угрозу, глобальные дедлайны регуляторов, российские алгоритмы-кандидаты и первые промышленные пилоты QKD в России.

Блог ПассворкаИлья Шелыгин

Nexign: как Пассворк упростил управление паролями

Введение АО «Нэксайн» (Nexign) — российская компания с 33-летним опытом разработки высокотехнологичных enterprise-решений для различных отраслей экономики. Готовые продукты и решения Nexign обеспечивают быструю ИТ-трансформацию клиентов, чтобы крупный бизнес мог решать задачи в кратчайшие сроки с уверенностью в результате. В портфеле компании более 150 успешно выполненных проектов в 12 странах мира.

Блог ПассворкаАнастасия Лебедева

За последние три-четыре года криптография в России стала центральным вопросом цифрового суверенитета и операционной устойчивости бизнеса.

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

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

Важно понимать три вещи:

• Юридическая сила. ГОСТ-криптография — единственный путь, обеспечивающий юридическую силу электронных документов и легитимную защиту регулируемых данных.
• Штрафы и ответственность. Нарушение требований по применению сертифицированных средств криптографической защиты влечёт административные штрафы (которые в 2025 году существенно ужесточились), а в отдельных случаях — уголовную ответственность.
• Импортозамещение. После 2022 года стоимость и сложность интеграции ГОСТ-решений выросли, но доступность отечественных продуктов также увеличилась — рынок прошёл через бум импортозамещения.

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

Главное

• ГОСТ-криптография — единственный юридически признаваемый способ защиты персональных данных, государственных информационных систем и КИИ в России. После 2022 года она стала обязательной частью цифровой инфраструктуры для государственных органов, банков и операторов персональных данных.
• Три действующих стандарта: блочные шифры «Кузнечик» и «Магма» (ГОСТ 34.12-2018), хеш-функция «Стрибог» (ГОСТ Р 34.11-2012) и электронная подпись на эллиптических кривых (ГОСТ Р 34.10-2012). Все современные СКЗИ строятся на этих алгоритмах.
• Техническая стойкость сопоставима с западными аналогами (AES, RSA, SHA-2) — все алгоритмы обеспечивают криптографическую защиту уровня 256 бит и выше. Критическая разница — в регуляторной легитимности.
• Регуляторы: ФСБ России (лицензирование, сертификация СКЗИ, надзор), ФСТЭК России (некриптографические средства защиты), Роскомнадзор (операторы ПДн), ЦБ РФ (финансовый сектор). Каждый регулятор устанавливает свои требования к классу СКЗИ и срокам сертификации.
• Штрафы ужесточились с 2025 года: за использование несертифицированных СКЗИ — 50 000–100 000 руб. (юридические лица), за крупные утечки персональных данных — до 15–20 миллионов рублей, при повторных нарушениях — оборотные штрафы. В отдельных случаях (КИИ) — уголовная ответственность.
• Обязательные сценарии применения: государственные органы и ГИС (класс не ниже КС1), передача персональных данных по открытым каналам, КИИ (класс не ниже КС2), банковские операции, квалифицированная электронная подпись (КЭП), межведомственное взаимодействие через СМЭВ.
• Постквантовая угроза: асимметричные алгоритмы (ГОСТ Р 34.10-2012, RSA, ECDSA) уязвимы к алгоритму Шора. Российские постквантовые стандарты ожидаются в 2026–2027 годах. Симметричные шифры («Кузнечик», «Магма», «Стрибог») при достаточной длине ключа остаются стойкими даже в постквантовую эру.
• Импортозамещение после 2022 года: рынок отечественных СКЗИ прошёл через бум развития. Сегодня доступны зрелые продукты с сертификацией ФСБ и ФСТЭК, поддержкой ГОСТ , интеграцией в популярные платформы (Astra Linux, Альт, РЕД ОС).

Краткая история: от советских шифров до Кузнечика

Современный этап российской криптографии начинается с шифра, разработанного в конце 1970-х годов в Восьмом главном управлении КГБ СССР — подразделении, отвечавшем за правительственную связь и криптографическую защиту. Изначально шифр предназначался для защиты конфиденциальной информации, имел гриф «Совершенно секретно» и был открыт полностью только в мае 1994 года — через пять лет после формального принятия в качестве государственного стандарта постановлением Госкомитета СССР по стандартам № 1409 от 2 июня 1989 года под обозначением ГОСТ 28147-89.

ГОСТ 28147-89 — блочный шифр с 256-битным ключом и 64-битным блоком, основанный на сети Фейстеля с 32 раундами преобразования. Стал основой российской криптографической школы и первым отечественным стандартом, допущенным к защите государственной тайны без ограничений по уровню секретности.

Архитектура напоминает американский DES (Data Encryption Standard) — открытый стандарт блочного шифрования, принятый правительством США в 1977 году для защиты несекретной информации федеральных ведомств. DES использовал 64-битный блок с 56-битным ключом и сети Фейстеля.

ГОСТ 28147-89 использовал ту же архитектуру, но с критическим усилением: длина ключа увеличена с 56 до 256 бит. Это сделало советский стандарт практически неуязвимым к атакам полного перебора даже на суперкомпьютерах того времени — для взлома потребовалось бы 2²⁵⁶ операций, что превышает практические возможности атак брутфорсом даже с учётом современных распределённых вычислительных систем.

Зачем потребовались собственные стандарты

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

Советские криптографы строили независимую научную школу, опираясь на собственные математические исследования и криптоаналитические методы. Результатом стал стандарт, который превосходил западные аналоги: DES с 56-битным ключом был взломан методом брутфорса уже в 1998 году, в то время как ГОСТ 28147-89 остаётся стойким к атакам полного перебора до сих пор.

После распада СССР Россия унаследовала советские криптографические наработки и научную школу, начав их системно развивать. ГОСТ 28147-89 формально стал межгосударственным стандартом СНГ, а Россия запустила линейку собственных стандартов под индексом «Р».

Хронология ключевых стандартов

Сегодня российская криптография стоит на трёх «китах»: блочных шифрах «Кузнечик» и «Магма» (ГОСТ 34.12-2018), хеш-функции «Стрибог» (ГОСТ Р 34.11-2012) и схеме электронной подписи на эллиптических кривых (ГОСТ Р 34.10-2012).

Актуальные ГОСТ-алгоритмы: что работает сейчас

ГОСТ Р 34.12-2015 «Кузнечик»: современный блочный шифр

«Кузнечик» — основной российский блочный шифр с 2015 года. Использует 128-битный блок и 256-битный ключ, построен на SP-сети с 10 раундами. Применяется во всех современных средствах криптографической защиты информации (СКЗИ) для шифрования данных в каналах связи, VPN, TLS и электронной подписи. Обеспечивает стойкость 256 бит против классических атак.

Почему появился «Кузнечик»?

К началу 2010-х годов стало очевидно, что ГОСТ 28147-89 морально устарел: 64-битный блок создавал уязвимости при шифровании больших объёмов данных, а отсутствие фиксированной таблицы подстановок затрудняло сертификацию. Нужен был современный шифр, сопоставимый с AES по производительности и стойкости, но независимый от западных разработок.

Разработка велась Центром защиты информации и специальной связи ФСБ России совместно с АО «ИнфоТеКС». Технический комитет по стандартизации ТК 26 «Криптографическая защита информации» отвечал за стандартизацию и утверждение алгоритма, но непосредственная разработка криптографических примитивов — прерогатива ФСБ и аккредитованных организаций.

Результат («Кузнечик») получил международное признание: алгоритм опубликован в IETF (RFC 7801) и прошёл независимый криптоанализ.

Технические характеристики «Кузнечика»

• Размер блока: 128 бит (как у AES).
• Длина ключа: 256 бит (фиксировано, в отличие от AES с вариантами 128/192/256).
• Принцип работы: SP-сеть (Substitution-Permutation Network) с 10 раундами преобразований — подстановка, перестановка, смешивание с ключом.
• Стойкость: при использовании 256-битного ключа теоретическая стойкость составляет 2²⁵⁶ против классических атак методом полного перебора. Даже при гипотетическом применении квантового алгоритма Гровера эффективная стойкость остаётся на уровне 2¹²⁸ операций.
• Статус: актуальный, рекомендован к применению во всех новых разработках.

Важная деталь: в отличие от асимметричных алгоритмов (ГОСТ Р 34.10-2012, RSA), которые уязвимы к квантовому алгоритму Шора, симметричные шифры вроде «Кузнечика» остаются стойкими даже в постквантовую эру.

Где применяется «Кузнечик»

• Все современные СКЗИ, сертифицированные ФСБ после 2015 года
• VPN-туннели (КриптоПро NGate, ViPNet, Континент)
• Шифрование дисков и баз данных
• Электронная подпись (шифрование контейнеров ключей)
• Защищённые каналы связи в государственных информационных системах

ГОСТ Р 34.12-2015 «Магма»: преемник ГОСТ 28147-89

«Магма» — канонически стандартизированная версия легендарного советского шифра ГОСТ 28147-89. Описана в RFC 8891 и является прямым наследником криптографической традиции, заложенной в КГБ СССР в конце 1970-х годов.

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

ГОСТ 28147-89 служил основой российской криптографии более 25 лет. Но у него была серьёзная проблема: стандарт не фиксировал таблицы подстановок (S-блоки) — каждая организация могла использовать свои. Это создавало невозможность сертификации единого алгоритма (каждая реализация требовала отдельной проверки), проблемы совместимости между разными СКЗИ и сложность криптоанализа — нельзя было оценить стойкость ГОСТ 28147-89 как такового, только конкретных реализаций с известными таблицами подстановок.

В 2015 году алгоритм был стандартизирован заново под названием «Магма» с фиксированными таблицами подстановок. Это единственное отличие от оригинального ГОСТ 28147-89 — всё остальное осталось без изменений.

Технические характеристики «Магмы»

• Размер блока: 64 бита.
• Длина ключа: 256 бит.
• Принцип работы: классическая сеть Фейстеля с 32 раундами.
• Операции на каждом раунде:
  • Сложение по модулю 2³² (результат обрезается до 32 бит)
  • Табличная нелинейная замена через S-блок (теперь фиксированный)
  • Циклический сдвиг влево на 11 битов
• Статус: актуальный стандарт, но для новых разработок ФСБ и ТК 26 рекомендуют использовать «Кузнечик». «Магма» сохраняется в стандарте для обеспечения преемственности и специализированных применений.

Где применяется «Магма» сегодня

• Режим имитовставки (MAC) — для проверки целостности данных. «Магма» в режиме CBC-MAC используется в процедуре Key Wrap при шифровании сессионных ключей в ГОСТ CMS.
• Легаси-системы — поддержка совместимости со старыми СКЗИ, построенными на ГОСТ 28147-89.
• Встраиваемые системы — «Магма» менее требовательна к ресурсам, чем «Кузнечик», что делает её подходящей для микроконтроллеров и IoT-устройств.
• Гибридные схемы — в современных СКЗИ «Кузнечик» используется для шифрования данных, а «Магма» — для имитовставки.

Сравнение «Магмы» и «Кузнечика»

ГОСТ Р 34.13-2015: режимы шифрования

Стандарт определяет, как применять блочные шифры «Кузнечик» и «Магма» для защиты данных любого размера. Блочный шифр обрабатывает фиксированные порции (блоки по 128 бит), а режимы показывают, как с его помощью шифровать файлы, потоки и сетевой трафик.

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

Основные режимы

ГОСТ Р 34.10-2012: электронная подпись на эллиптических кривых

Стандарт электронной цифровой подписи (ЭЦП), основанный на математическом аппарате эллиптических кривых над конечными простыми полями. Это фундамент всей инфраструктуры квалифицированной электронной подписи (КЭП) в России — от подписания налоговых деклараций до государственных контрактов на миллиарды рублей.

Технические характеристики

• Длина ключей: 256 и 512 бит.
• Математическая основа: эллиптические кривые над простым полем (специальные математические структуры, где все вычисления выполняются по модулю большого простого числа)
• Стойкость: основана на сложности вычисления дискретного логарифма в группе точек эллиптической кривой.
• Применение: вся инфраструктура квалифицированной электронной подписи (КЭП) в России.
• Хеш-функция: работает в связке с «Стрибог» (ГОСТ Р 34.11-2012).
• Международное обозначение: описан в RFC 7091.
• Статус: актуальный. Принят в 2012 году, вступил в силу с 1 января 2013 года. Переходный период, в течение которого разрешалось использование ГОСТ Р 34.10-2001, продлевался до 31 декабря 2018 года. С 2019 года ГОСТ Р 34.10-2012 является единственным действующим стандартом ЭЦП в России.

Что изменилось по сравнению с ГОСТ Р 34.10-2001

ГОСТ Р 34.10-2001 (принят в 2001 году) был первым российским стандартом ЭЦП на эллиптических кривых, но поддерживал только 256-битные ключи и работал с устаревшей хэш-функцией ГОСТ Р 34.11-94.

ГОСТ Р 34.10-2012 принёс три ключевых улучшения:

1. Поддержка 512-битных ключей — критично для долгосрочной защиты (документы со сроком хранения 30+ лет). При гипотетическом появлении квантовых компьютеров 256-битные ключи могут быть скомпрометированы алгоритмом Шора, 512-битные дают дополнительный запас стойкости.
2. Интеграция с хеш-функцией «Стрибог» — новая функция с длиной 256 или 512 бит заменила устаревший ГОСТ Р 34.11-94. Это устранило теоретические уязвимости старой хеш-функции.
3. Новые параметры эллиптических кривых — стандарт определил кривые, оптимизированные для производительности и стойкости против современных атак (включая атаки на слабые кривые).

Где применяется

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

ГОСТ Р 34.11-2012 «Стрибог»: современная хеш-функция

«Стрибог» — основная российская криптографическая хеш-функция. Вычисляет «цифровой отпечаток» данных произвольной длины — уникальное значение фиксированного размера (256 или 512 бит), которое однозначно идентифицирует исходные данные.

Технические характеристики

• Длина хеша: 256 или 512 бит (выбирается в зависимости от требований безопасности).
• Размер блока входных данных: 512 бит.
• Архитектура: схема Меркла-Дамгора с функцией сжатия на основе конструкции Миягучи-Пренеля.
• Количество раундов: 12 раундов преобразований.
• Международное обозначение: описан в RFC 6986.В 2018 году «Стрибог» был включён в международный стандарт ISO/IEC 10118-3.
• Статус: актуальный. Заменил ГОСТ Р 34.11-94 с 1 января 2013 года. С 2019 года является единственной действующей хеш-функцией в российских стандартах криптографической защиты.

Что изменилось по сравнению с ГОСТ Р 34.11-94

ГОСТ Р 34.11-94 (принят в 1994 году) был построен на базе блочного шифра ГОСТ 28147-89 и имел фиксированную длину хеша 256 бит. К концу 2000-х годов стандарт устарел: криптоаналитики нашли способы построения коллизий (разных сообщений с одинаковым хешем) со сложностью ниже 2¹²⁸ операций — существенно быстрее, чем атака полным перебором. Длина хеша 256 бит стала недостаточной для долгосрочной защиты критичных данных, а зависимость от ГОСТ 28147-89 с нефиксированными S-блоками создавала проблемы совместимости между разными реализациями.

«Стрибог» решил эти проблемы:

1. Две длины хеша — 256 бит для обычных задач, 512 бит для долгосрочного архивирования и критичных систем.
2. Современная архитектура — независимая от блочных шифров, оптимизированная для производительности.
3. Стойкость к коллизиям — на сегодняшний день не найдено практических атак, снижающих стойкость ниже теоретической (2¹²⁸ операций для 256-битного хэша, 2²⁵⁶ для 512-битного).

Где применяется

• Электронная подпись — вычисление хеша документа перед подписанием (ГОСТ Р 34.10-2012 работает только в связке со «Стрибог»).
• Контроль целостности данных — проверка, что файл или сообщение не были изменены.
• Хранение паролей — вместо паролей в базе хранятся их хеши.
• Цифровые сертификаты — хеширование открытых ключей и данных сертификатов в инфраструктуре PKI.
• Блокчейн и распределённые реестры — российские блокчейн-платформы используют «Стрибог» для хеширования блоков.
• СКЗИ — имитовставка, Key Wrap, генерация ключевого материала.

Возможные уязвимости и дискуссии вокруг ГОСТ-криптографии

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

• Непрозрачность S-блоков «Кузнечика». В 2019 году криптограф Лео Перрин показал, что таблицы подстановки «Кузнечика» сгенерированы по скрытому алгоритму. Разработчики не раскрыли критерии выбора, что создаёт вопросы доверия. Практических атак на основе этой особенности не найдено (Cryptology ePrint Archive, 2019).
• Закрытость разработки. Российские стандарты разрабатываются ФСБ без открытых конкурсов — в отличие от западной практики. Это снижает доверие международного сообщества, но за 10+ лет не найдено практических атак, снижающих стойкость ниже заявленной.
• Квантовая угроза. ГОСТ Р 34.10-2012 уязвим к квантовому алгоритму Шора — как и RSA, ECDSA. Квантовый компьютер, способный взломать 256-битные ключи, появится не ранее 2030–2035 годов. Российские постквантовые стандарты ожидаются в 2026–2027 годах. Симметричные шифры остаются стойкими.
• Ограниченная аппаратная поддержка. ГОСТ-алгоритмы не имеют встроенного ускорения в массовых процессорах. Программные реализации медленнее AES и более уязвимы к атакам по сторонним каналам. Сертифицированные СКЗИ компенсируют это специализированными криптопроцессорами.

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

Сравнение с западными аналогами

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

Блочные шифры: «Кузнечик» и AES

Ключевые отличия

• Производительность: AES быстрее на современных процессорах благодаря встроенным инструкциям AES-NI (аппаратное ускорение на уровне CPU). «Кузнечик» компенсирует это специализированными ускорителями в сертифицированных СКЗИ, но на обычном железе без оптимизации работает медленнее.
• Экосистема: AES поддерживается всеми операционными системами, браузерами, облачными платформами и библиотеками из коробки. «Кузнечик» требует специализированного ПО (КриптоПро CSP, ViPNet, OpenSSL с патчами).

Электронная подпись: ГОСТ Р 34.10-2012, RSA, ECDSA

Ключевые отличия

• Архитектура: ГОСТ Р 34.10-2012 и ECDSA архитектурно близки — оба основаны на эллиптических кривых, используют схожие математические операции. Главное различие — в параметрах кривых и деталях алгоритма подписания.
• Размер ключей: RSA требует ключи в 4–8 раз длиннее для эквивалентной стойкости. 256-битный ключ на эллиптической кривой (ГОСТ, ECDSA) эквивалентен по стойкости 3072-битному ключу RSA. Это критично для мобильных устройств, смарт-карт и систем с ограниченными ресурсами.
• Производительность: RSA медленнее при генерации подписи (требует возведения в степень по большому модулю), но быстр при проверке. ГОСТ и ECDSA быстры в обеих операциях.

Хеш-функции: «Стрибог», SHA-2, SHA-3

Ключевые отличия

• Архитектура: «Стрибог» и SHA-2 используют классическую схему Меркла-Дамгора (последовательная обработка блоков). SHA-3 построен на принципиально иной конструкции «губка» (sponge) — более гибкой и устойчивой к определённым типам атак.
• Производительность: SHA-2 быстрее на современных процессорах благодаря аппаратной поддержке (инструкции SHA Extensions в Intel/AMD). «Стрибог» медленнее на обычном железе, но оптимизирован в российских СКЗИ.

Асимметричная криптография в ГОСТ: электронная подпись и обмен ключами

Блочные шифры («Кузнечик», «Магма») и хеш-функция («Стрибог») решают задачу симметричного шифрования — когда обе стороны заранее договорились об общем секретном ключе. Но как передать этот ключ по открытому каналу? Как подписать документ так, чтобы любой мог проверить подлинность, но никто не смог подделать? Эти задачи решает асимметричная криптография.

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

Два класса асимметричных алгоритмов

• Электронная подпись — классический асимметричный алгоритм с парой ключей: закрытый (секретный) ключ для подписания и открытый ключ для проверки. Математическая основа — задача дискретного логарифмирования на эллиптических кривых (ECDLP). На этом алгоритме построена вся инфраструктура квалифицированной электронной подписи (КЭП) в России.
• Протокол VKO (Выработка Ключа Общего) — российский вариант алгоритма Диффи-Хеллмана на эллиптических кривых. Позволяет двум сторонам по открытым каналам выработать общий секретный ключ для симметричного шифрования. Применяется в ГОСТ TLS при установке защищённого соединения и при шифровании сообщений в формате CMS/PKCS#7.

Принципиальное отличие от западной модели

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

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

Как работает ГОСТ-шифрование: от отправителя к получателю

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

Представьте сейф с двумя замками:

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

Этот секрет превращается в ключ шифрования через функцию выработки ключа (KDF, Key Derivation Function). Затем сессионный ключ оборачивается — шифруется с защитой от подделки. Данные шифруются на этом сессионном ключе, а эфемерный ключ уничтожается навсегда.

Что передаётся по каналу

Всё упаковывается в формат CMS (синтаксис криптографических сообщений):

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

Как это работает: пошаговая схема

Действия отправителя:

1. Генерация параметров. Создаёт эфемерную пару ключей (временный закрытый и открытый), случайную соль UKM (8 байт для уникальности сессии), сессионный ключ CEK (256 бит — им будут зашифрованы данные) и вектор инициализации IV (128 бит — начальное значение для режима шифрования).
2. VKO — выработка общего секрета. Вычисляет общую точку на эллиптической кривой, комбинируя свой эфемерный закрытый ключ с открытым ключом получателя из его сертификата. Результат — секретное число, которое знают обе стороны, но оно никогда не передаётся по сети.
3. KDF — выработка ключа шифрования. Общий секрет нельзя использовать напрямую. Функция HKDF-Стрибог превращает его в криптографически стойкий ключ шифрования ключей (KEK) — мастер-ключ, которым будет защищён сессионный ключ.
4. Обёртывание сессионного ключа. Защищает сессионный ключ CEK имитовставкой (MAC) — коротким «отпечатком», доказывающим целостность, затем шифрует весь пакет (CEK + MAC) на KEK алгоритмом «Магма». Это называется Key Wrap — упаковка ключа с защитой от подделки.
5. Шифрование данных. Шифрует данные на сессионном ключе CEK алгоритмом «Кузнечик» в режиме CTR — быстрое потоковое шифрование, подходящее для файлов любого размера.
6. Отправка. Формирует CMS-контейнер с эфемерным открытым ключом, солью UKM, обёрнутым сессионным ключом, вектором инициализации и зашифрованными данными. Эфемерный закрытый ключ навсегда уничтожается — он больше нигде не существует.

Действия получателя:

1. VKO — выработка общего секрета. Извлекает из CMS-сообщения эфемерный открытый ключ отправителя и соль UKM, затем вычисляет ту же общую точку на эллиптической кривой, используя свой закрытый ключ. Математика гарантирует: результат совпадёт с тем, что получил отправитель.
2. KDF — выработка ключа шифрования. Пропускает общий секрет через ту же функцию HKDF-Стрибог и получает тот же мастер-ключ KEK. Обе стороны теперь владеют одинаковым ключом, хотя никогда не передавали его друг другу.
3. Разворачивание сессионного ключа. Расшифровывает обёрнутый ключ алгоритмом «Магма» и извлекает сессионный ключ CEK вместе с имитовставкой MAC.
4. Проверка целостности. Пересчитывает имитовставку от CEK и сравнивает с полученной. Если значения не совпадают — ключ был повреждён при передаче или подделан злоумышленником. Расшифровка немедленно прерывается — работать с повреждённым ключом опасно.
5. Расшифровка данных. Только после успешной проверки целостности расшифровывает данные на проверенном сессионном ключе CEK алгоритмом «Кузнечик».

Почему это безопаснее RSA

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

Регуляторная среда: кто контролирует защиту информации

ФСБ России: главный регулятор

Федеральная служба безопасности — ключевой регулятор криптографии в России. Её полномочия:

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

ФСТЭК России: смежный регулятор

Отвечает за некриптографические средства защиты информации: межсетевые экраны, антивирусы, системы обнаружения вторжений. Граница ответственности проста: «всё, что шифрует» — ФСБ, «всё, что защищает без шифрования» — ФСТЭК.

Роскомнадзор: контроль операторов персональных данных

Роскомнадзор контролирует операторов персональных данных и проверяет выполнение требований 152-ФЗ — включая использование сертифицированных СКЗИ. Хотя не регулирует криптографию напрямую, именно Роскомнадзор штрафует за отсутствие СКЗИ при обработке ПДн.

Росстандарт и Минцифры

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

ЦБ РФ: регулятор финансового сектора

Центральный банк России устанавливает обязательные требования к криптографической защите для кредитных организаций, платёжных систем и операторов финансовых услуг. Ключевые документы: ГОСТ Р 57580.1-2017 (стандарт защищённости финансовых операций), Положения ЦБ № 683-П, 684-П, 719-П, 802-П. ЦБ РФ имеет право выдавать предписания об устранении нарушений, ограничивать операции (запрет на привлечение новых клиентов, открытие филиалов) и отзывать лицензии при систематических нарушениях или крупных утечках данных.

Как взаимодействуют регуляторы

ФСБ устанавливает требования к СКЗИ → Роскомнадзор проверяет их выполнение у операторов ПДн → ФСТЭК сертифицирует некриптографические СЗИ → Минцифры координирует импортозамещение и развитие инфраструктуры электронной подписи.

Законодательная база: что обязывает применять ГОСТ

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

Где использование ГОСТ-криптографии обязательно

1. Государственные органы и ГИС. Все федеральные, региональные и муниципальные органы власти обязаны применять сертифицированные СКЗИ.
2. Обработка персональных данных. При передаче ПДн по открытым каналам применение сертифицированных СКЗИ становится фактически обязательным.
3. Критическая информационная инфраструктура. Банки, операторы связи, энергетика, транспорт, здравоохранение обязаны строить защиту значимых объектов с применением отечественных сертифицированных средств.
4. Банки и финансовый сектор. Любые банковские операции, межбанковские взаимодействия, ДБО — везде применяется ГОСТ.
5. Электронная подпись и ЭДО. Любая квалифицированная электронная подпись построена на ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012.
6. СМЭВ и межведомственное взаимодействие. Построена исключительно на ГОСТ-криптографии.

Штрафы и ответственность за нарушения

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

Административная ответственность

Применяется при использовании несертифицированных СКЗИ, отсутствии лицензий ФСБ у поставщика или нарушении организационных требований (отсутствие журналов учёта, допуск неуполномоченных лиц). Особое внимание уделяется утечкам персональных данных: за повторный инцидент компании грозит оборотный штраф от 1% до 3% годовой выручки (но не менее 20 млн и не более 500 млн рублей).

Уголовная ответственность

• Статья 272 УК РФ (Неправомерный доступ к компьютерной информации): если деяние повлекло уничтожение или копирование данных — до 2 лет лишения свободы. При тяжких последствиях — до 7 лет.
• Статья 274 УК РФ (Нарушение правил эксплуатации средств хранения/обработки): если нарушение повлекло ущерб свыше 1 млн рублей — до 2 лет лишения свободы. При тяжких последствиях — до 5 лет.

Специфика финансового сектора

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

• Предписание об устранении нарушений — обязательное к исполнению в установленный срок (обычно 30–90 дней)
• Ограничение на проведение отдельных операций — запрет на привлечение новых клиентов, открытие филиалов
• Отзыв лицензии — в случае систематических нарушений или крупной утечки данных

Как избежать штрафов

• Используйте только сертифицированные СКЗИ — проверьте наличие сертификата ФСБ нужного класса (КС1, КС2, КС3) на сайте регулятора
• Проверьте лицензии поставщика — разработчик или интегратор СКЗИ должен иметь лицензию ФСБ на разработку, производство или распространение шифровальных средств
• Ведите журналы учёта СКЗИ — фиксируйте выдачу ключей, доступ к криптографическим модулям, инциденты
• Организуйте режим помещений — СКЗИ класса КС2 и выше требуют контроля доступа в серверные
• Обучите персонал — администраторы должны пройти обучение по работе с конкретным СКЗИ (требование Приказа ФСБ № 378)
• Уведомите регулятора — при вводе СКЗИ в эксплуатацию уведомите ФСБ (для КС2 и выше) или ФСТЭК (для ГИС)
• Проводите регулярные аудиты — проверяйте актуальность сертификатов, обновлений, соответствие организационных мер требованиям

Тренды и будущее российской криптографии

Постквантовая криптография

Главный долгосрочный риск — квантовые компьютеры, способные взломать алгоритмы, основанные на дискретном логарифме и факторизации.

В России активно ведутся работы:

• В ТК 26 создана рабочая группа «Постквантовые криптографические механизмы»
• Компания «Криптонит» опубликовала реализацию постквантового алгоритма «Шиповник» на основе кодовой криптографии
• Российские постквантовые стандарты ожидаются в 2026–2027 годах

Для сравнения: NIST в августе 2024 года уже утвердил первые постквантовые стандарты (ML-KEM). Важно, что ГОСТ-симметричные шифры («Кузнечик», «Магма», «Стрибог») при достаточной длине ключа считаются устойчивыми к квантовым атакам.

Заключение

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

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

После 2022 года рынок отечественных средств защиты информации прошёл через бум импортозамещения. Сегодня доступны зрелые продукты с сертификацией ФСТЭК, поддержкой российских стандартов и интеграцией в популярные платформы.

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

Если ваша компания работает с персональными данными, подпадает под КИИ или регулируется ЦБ — Пассворк решает задачу управления паролями с соблюдением всех регуляторных требований. Протестируйте бесплатно

Часто задаваемые вопросы

Чем ГОСТ-криптография отличается от западных стандартов?

ГОСТ-алгоритмы разработаны в России, сертифицированы ФСБ и являются единственными юридически признаваемыми для защиты персональных данных, государственных информационных систем и КИИ. Технически они сопоставимы по стойкости с западными аналогами (AES, RSA, ECDSA), но имеют другую математическую основу и архитектуру. Главное отличие — регуляторная легитимность: использование несертифицированных средств влечёт штрафы.

Обязательно ли использовать ГОСТ-криптографию для всех компаний?

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

Что такое постквантовая криптография и когда она появится в России?

Постквантовая криптография — это алгоритмы, устойчивые к атакам квантовых компьютеров. Современные асимметричные алгоритмы (ГОСТ Р 34.10-2012, RSA, ECDSA) теоретически уязвимы к алгоритму Шора, который может разложить большие числа за полиномиальное время. В России активно ведутся работы в ТК 26, компания «Криптонит» опубликовала реализацию постквантового алгоритма «Шиповник». Российские постквантовые стандарты ожидаются в 2026–2027 годах. Симметричные шифры («Кузнечик», «Магма», AES-256) при достаточной длине ключа остаются стойкими даже в постквантовую эру.

Можно ли использовать западные алгоритмы (AES, RSA) вместе с ГОСТ?

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

Что такое класс СКЗИ и как его выбрать?

Класс СКЗИ (КС1, КС2, КС3, КВ, КА) определяет уровень защиты и организационные требования. Выбор зависит от типа данных, уровня защищённости ИСПДн и анализа угроз. Операторам ПДн обычно достаточно КС1–КС2, государственным органам и банкам требуется КС2 и выше.

Нужно ли обучать сотрудников работе с СКЗИ?

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

Первый менеджер паролей с сертификацией ФСТЭК России

30 апреля 2026 года Пассворк получил сертификат ФСТЭК России № 5063 по 4-му уровню доверия — наивысшему для коммерческих средств защиты информации. Пассворк стал первым российским менеджером паролей, который может применяться в ГИС, ИСПДн, КИИ и АСУ ТП 1 класса защищённости.

Блог ПассворкаИлья Шелыгин

Постквантовая криптография: угрозы и стандарты — 2026

Квантовые компьютеры ещё не взломали ни одного шифра, но атаки уже идут. Разбираем HNDL-угрозу, глобальные дедлайны регуляторов, российские алгоритмы-кандидаты и первые промышленные пилоты QKD в России.

Блог ПассворкаИлья Шелыгин

Импортозамещение КИИ в 2026: сроки, требования и план перехода

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

Блог ПассворкаИлья Шелыгин

30 апреля 2026 года Пассворк получил сертификат соответствия ФСТЭК России № 5063 по 4-му уровню доверия — наивысшему из применяемых для коммерческих средств защиты информации. Сертификат подтверждает, что наш продукт соответствует самым строгим требованиям российского регулятора и может применяться в критически важных государственных и корпоративных системах.

Сертификация ФСТЭК — результат многомесячной работы команды разработки, службы безопасности и внешних аудиторов. Архитектура продукта, криптографические алгоритмы, механизмы управления доступом и журналирования прошли все этапы детальной проверки на соответствие требованиям приказа ФСТЭК России № 76 от 2 июня 2020 года.

Пассворк успешно прошёл все сертификационные испытания и на сегодняшний день является первым и единственным менеджером паролей в России с сертификатом ФСТЭК.

Область применения сертификата

Сертификат ФСТЭК и включение в реестр сертифицированных СЗИ снимает регуляторные ограничения для использования Пассворка в следующих типах систем:

• Государственные информационные системы (ГИС) — до 1 класса защищённости включительно.
• Информационные системы персональных данных (ИСПДн) — до 1 уровня защищённости включительно.
• Значимые объекты критической информационной инфраструктуры (КИИ) — до 1 категории включительно.
• Автоматизированные системы управления технологическими процессами (АСУ ТП) — до 1 класса защищённости включительно.

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

Почему это важно для наших клиентов

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

Для регулируемых отраслей

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

Сертификат ФСТЭК по 4-му уровню доверия:

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

Наличие сертификата ФСТЭК позволяет использовать Пассворк в информационных системах любого класса защищённости.

Для коммерческих организаций

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

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

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

Сертификаты и лицензии Пассворка

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

• Лицензия ФСТЭК на деятельность по технической защите конфиденциальной информации (ТЗКИ) — получена в июне 2024 года.
• Лицензия ФСТЭК на деятельность по разработке и производству средств защиты конфиденциальной информации (СЗКИ) — получена в июне 2024 года.
• Лицензия ФСБ России на работу с криптографическими технологиями — подтверждает право использовать и распространять криптографические средства защиты информации.
• Сертификат ФСТЭК России № 5063 по 4-му уровню доверия — Пассворк внесён в Государственный реестр сертифицированных средств защиты информации.
• Включение в Единый реестр российского ПО Минцифры России — Пассворк официально включён в реестр Минцифры (реестровая запись №6147) и может участвовать в государственных закупках.

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

Что проверяет ФСТЭК при сертификации

Сертификация ФСТЭК — это комплексная проверка продукта на соответствие требованиям безопасности информации. Проверка охватывает все критически важные аспекты архитектуры и функциональности решения:

• Технические меры защиты. Проверяется способность продукта предотвращать несанкционированный доступ к данным, наличие функций контроля целостности, механизмы идентификации и аутентификации пользователей.
• Документация и процессы разработки. ФСТЭК проверяет не только код, но и процессы: как организована разработка, тестирование, обработка инцидентов безопасности, обновление продукта.
• Соответствие нормативным требованиям. Продукт проверяется на соответствие руководящим документам ФСТЭК, включая требования к средствам контроля доступа, регистрации событий и защиты информации от несанкционированного доступа.
• Архитектура и криптография. Проверяется архитектура и шифрование данных, генерация ключей на стороне клиента, использование сертифицированных криптографических библиотек. ФСТЭК контролирует, что данные и ключи шифрования никогда не покидают инфраструктуру организации.
• Управление доступом и аудит. Проверяется реализация ролевой модели, интеграция с Active Directory, LDAP и SSO. ФСТЭК контролирует полноту журнала аудита: каждое действие пользователя фиксируется с детализацией — кто, когда и к каким данным получил доступ.

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

От сертификации к практике

Пассворк — российский продукт и средство защиты информации. Сертификат и лицензии ФСТЭК, ФСБ России, включение в реестр Минцифры закрывают все регуляторные требования для работы в системах любого класса защищённости.

Сертификация ФСТЭК — важный шаг, но далеко не финальный. Мы продолжаем развивать наш продукт: расширяем список интеграций с корпоративными системами, добавляем новые механизмы контроля доступа, углубляем возможности аудита и отчётности.

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

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

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

Кейс-стади: МТС Банк и Пассворк

Как МТС Банк объединил управление паролями в единой системе с помощью Пассворка и повысил уровень безопасности.

Блог ПассворкаАнастасия Лебедева

Импортозамещение ИБ-решений (СЗИ): переход на российское ПО

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

Блог ПассворкаАнастасия Лебедева

Приказ ФСТЭК № 117: разбор изменений, Кзи и штрафов

С 1 марта 2026 года Приказ ФСТЭК № 17 утратил силу. Его заменил Приказ № 117 с числовыми метриками КЗИ и ПЗИ, жёсткими сроками устранения уязвимостей и расширенной зоной ответственности. В статье рассмотрим, что изменилось и как подготовиться.

Блог ПассворкаИлья Шелыгин

В 2025 году ФСТЭК и ФСБ выпустили документы с одинаковым номером. Приказ ФСТЭК №117 от 11 апреля 2025 года и Приказ ФСБ №117 от 18 марта 2025 года регулируют разные аспекты защиты государственных информационных систем (ГИС), но действуют в одном правовом поле и распространяются на одни и те же организации. Выполнять придётся оба.

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

Приказ ФСТЭК №117 устанавливает общие требования к защите информации в ГИС и вступил в силу 1 марта 2026 года. Приказ ФСБ №117 регулирует применение криптографических средств защиты информации (СКЗИ) в тех же системах (вступил в силу 6 апреля 2025 года). Оба документа расширяют зону регуляторного контроля: теперь под их действие подпадают государственные унитарные предприятия (ГУП) и государственные учреждения.

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

Главное

• 1 марта 2026 года — дата вступления в силу Приказа ФСТЭК №117. Приказ ФСБ №117 действует с 6 апреля 2025 года — без переходного периода.
• Приказ ФСТЭК №117 — организационные и технические меры: управление доступом, модель угроз, аттестация, мониторинг, парольные политики.
• Приказ ФСБ №117 — исключительно криптография: СКЗИ, шифрование каналов, электронная подпись.
• Расширение периметра — под действие обоих приказов впервые подпадают ГУП и государственные учреждения. Прежде многие из них формально находились вне зоны обязательных требований.
• Новое в Приказе ФСТЭК №117 — процессный подход: непрерывный мониторинг, регулярный пересмотр модели угроз, жёсткие дедлайны устранения уязвимостей.
• Подрядчики в периметре — все сторонние организации, работающие с государственными ИС, обязаны соблюдать политику ИБ заказчика.
• Новые требования к привилегированному доступу — управление привилегированными учётными записями впервые выделено в самостоятельное мероприятие.
• Отправная точка для любой организации — инвентаризация и классификация информационных систем, актуализация модели угроз, разработка плана перехода с конкретными сроками и ответственными.

Законодательный фундамент и 216-ФЗ

Всё началось с Федерального закона №216-ФЗ от 8 августа 2024 года. Он внёс точечную, но принципиальную правку в часть 5 статьи 16 Федерального закона №149-ФЗ «Об информации, информационных технологиях и о защите информации».

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

"В части 5 статьи 16 после слова "системах," дополнить словами "иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений,", после слова "систем" дополнить словами ", иных информационных систем государственных органов, государственных унитарных предприятий, государственных учреждений" — Федеральный закон №216-ФЗ

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

Закон вступил в силу в день подписания, и оба ведомства (ФСТЭК и ФСБ) оперативно приступили к подготовке подзаконных актов.

Приказ ФСТЭК №117: перестройка подхода к защите

Приказ ФСТЭК России №117 от 11.04.2025 — это не обновление приказа №17, а полностью новый документ и иная логика построения системы защиты: от статического набора мер к непрерывному управляемому процессу.

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

Контекст ужесточения требований понятен: по данным компании «Еca Про», за 2025 год 73% всех утечек данных из российских организаций пришлось на госсектор — более 105 млн строк данных (Еса Про / Коммерсантъ, 2025). Политически мотивированные атаки и низкий уровень кибербезопасности в ряде структур сделали государственные системы главной мишенью.

Ключевые изменения по сравнению с предыдущей редакцией

• Расширение периметра действия — требования распространяются на ГУП и государственные учреждения, ранее они касались преимущественно органов государственной власти.
• Актуализация модели угроз — требования к её формированию обновлены с учётом современного ландшафта атак.
• Поэтапный переход вместо немедленной переаттестации — для действующих ГИС предусмотрен плановый переход согласно Информационному сообщению ФСТЭК № 240/22/1492.
• Усиление требований к управлению доступом — детализированные правила идентификации и аутентификации пользователей.
• Обязательная инвентаризация активов и контроль конфигураций — теперь это самостоятельное требование, а не рекомендательная мера.

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

Кого касаются новые правила

Приказ ФСТЭК №117 распространяется на все информационные системы, эксплуатируемые государственными органами, государственными унитарными предприятиями и государственными учреждениями на федеральном, региональном и муниципальном уровнях.

Это не только классические ГИС, но и ведомственные системы электронного документооборота, кадровые и бухгалтерские системы, отраслевые АСУ и любые другие ИС, используемые для обеспечения деятельности.

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

По данным Правительства РФ, в России функционирует более 4 000 ГИС, из которых около 3000 — региональные, а остальные — федеральные (ComNews, 2025). С учётом подрядчиков и смежных учреждений реальный масштаб охвата новых требований кратно выше.

Новая архитектура документа: от статичных мер к процессам

Главное концептуальное изменение Приказа ФСТЭК №117 — переход от статичной модели к процессному подходу. Прежняя логика предполагала однократное выполнение набора мер и периодическую аттестацию. Новая требует, чтобы защита информации была сквозным непрерывным процессом, встроенным в операционную деятельность организации и обязательной количественной оценкой результатов.

Это означает

• Постоянный мониторинг событий безопасности и состояния защитных мер
• Регулярный пересмотр модели угроз при изменении инфраструктуры или появлении новых угроз
• Документированные процедуры реагирования на инциденты с фиксацией результатов
• Отчётность перед ФСТЭК России на регулярной основе

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

Обязательные мероприятия: что должна делать каждая организация

Приказ №117 определяет перечень мероприятий, обязательных для всех организаций, попавших под его действие, независимо от класса защищённости их систем. Каждое мероприятие содержит конкретные требования, ряд которых появился впервые в российской регуляторике ИБ.

Управление уязвимостями с жёсткими дедлайнами

Критические уязвимости устраняются в течение 24 часов, высокого уровня опасности — в течение 7 календарных дней. При обнаружении уязвимости, отсутствующей в Банке данных угроз ФСТЭК (БДУ), оператор уведомляет регулятора в течение 5 рабочих дней.

Привилегированный доступ: отдельное направление регулирования

Управление привилегированным доступом (PAM) впервые выделено в самостоятельное мероприятие — в приказе №17 оно не регламентировалось отдельно.

«Посредством проведения мероприятий по обеспечению защиты информации при предоставлении привилегированного доступа должна быть исключена возможность получения привилегированного доступа к информационным системам лицами, для которых такой доступ должен быть исключен, а также использования повышенных прав доступа с нарушением внутренних стандартов и регламентов по защите информации», — п. 48 приказа ФСТЭК 117 от 11.04.2025

Пункт 48 приказа №117 устанавливает целый блок требований:

• Строгая аутентификация по ГОСТ Р 58833-2020 — многофакторная, с криптографическими протоколами. При технической невозможности — усиленная многофакторная аутентификация.
• Минимальные привилегии — каждая учётная запись получает только необходимые права.
• Персонификация — учётные записи с правом создания других привилегированных УЗ обязаны быть именными.
• Отключение встроенных УЗ — после первоначальной настройки отключаются или переименовываются, аутентификационная информация меняется.
• Обязательное журналирование — все действия с привилегированными учётными записями регистрируются и контролируются.

Запрещено совмещение ролей системного администратора, разработчика и администратора безопасности в рамках одной учётной записи. На практике это означает необходимость внедрения PAM-систем (Privileged Access Management). Организациям потребуются решения для централизованного управления привилегированными учётными записями, контроля сессий и журналирования действий администраторов.

Непрерывный мониторинг и отчётность

Мониторинг ведётся по ГОСТ Р 59547-2021 и охватывает четыре направления: анализ событий безопасности (SIEM, EDR, NDR, NGFW, WAF), контроль уязвимостей, мониторинг средств защиты и анализ актуальных угроз. Режим — 24/7, с обязательным взаимодействием с ГосСОПКА. Допускается применение доверенных технологий ИИ для анализа событий.

Аутентификация, удалённый доступ и мобильные устройства

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

Требования к подрядчикам

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

Парольная политика как измеримый критерий

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

Подразделение ИБ разрабатывает и внедряет парольную политику для всех учётных записей, связанных со значимыми объектами. Если соблюсти требования к сложности технически невозможно, необходим документ с компенсирующими мерами — сокращённый срок действия паролей или ограничение числа неудачных попыток ввода.

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

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

Деактивация учётных записей уволенных сотрудников и работников подрядчиков — отдельный измеримый показатель. При увольнении администратор системы получает официальное уведомление о блокировке; подразделение по ИБ контролирует исполнение. Это требует зрелого процесса управления логическим доступом, а не разовых действий.

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

Российский корпоративный менеджер паролей Пассворк позволяет закрыть сразу несколько критериев Кзи: принудительное применение требований к длине и сложности паролей, ролевая модель доступа к учётным данным, полное журналирование действий, контроль сервисных учётных записей, автоматический отзыв доступа при увольнении, поддержка FIDO2/WebAuthn и OTP для многофакторной аутентификации.

Пассворк помогает выполнить требования Приказа ФСТЭК №117 в части управления доступом: принудительное применение требований к длине и сложности паролей, ролевая модель доступа к учётным данным, полное журналирование действий, контроль сервисных учётных записей, автоматический отзыв доступа при увольнении, поддержка FIDO2/WebAuthn и многофакторной аутентификации. Протестируйте Пассворк бесплатно

Приказ ФСБ №117: фокус на криптографию и СКЗИ

Приказ ФСБ России №117 от 18.03.2025 утверждает требования о защите информации в государственных информационных системах и иных ИС госорганов, ГУП и госучреждений с использованием шифровальных (криптографических) средств.

Документ определяет, в каких случаях применение СКЗИ обязательно, какие классы криптосредств допустимы и как организовать их эксплуатацию. Приказ заменил ранее действовавший приказ ФСБ №524 от 24.10.2022.

Приказ зарегистрирован в Минюсте 26 марта 2025 года и вступил в силу 6 апреля 2025 года — без переходного периода, что потребовало от организаций немедленной оценки необходимых изменений.

В каких случаях обязательно применение СКЗИ

Использование сертифицированных ФСБ России СКЗИ обязательно, если выполняется хотя бы одно из условий:

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

Расширение на ГУП и госучреждения — принципиальное изменение: прежде многие из них формально находились вне зоны обязательного применения сертифицированных СКЗИ.

Применять разрешено только СКЗИ, сертифицированные ФСБ России. Класс применяемых криптосредств определяется уровнем угроз, зафиксированным в модели угроз конкретной системы.

Как два приказа №117 работают вместе

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

Разделение полномочий сохраняется: ФСТЭК регулирует общие вопросы защиты информации (управление доступом, мониторинг, уязвимости, подрядчики), ФСБ — всё, что связано с криптографией. Для оператора это означает необходимость обеспечить соответствие обоим наборам требований одновременно.

Синхронизация процессов

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

• Модель угроз разрабатывается с учётом требований обоих регуляторов: ФСТЭК определяет общий перечень актуальных угроз, ФСБ — угрозы, нейтрализуемые криптографическими методами
• Техническое задание на СЗИ включает как меры по Приказу ФСТЭК №117, так и требования к СКЗИ по Приказу ФСБ №117
• Аттестация системы защиты проводится с учётом выполнения требований обоих документов
• Управление доступом — точка пересечения обоих приказов: ФСТЭК регулирует идентификацию и аутентификацию, ФСБ — криптографическую защиту информации при её передаче за пределы контролируемой зоны.

Разрыв между этими двумя контурами — одна из наиболее распространённых ошибок при построении систем защиты ГИС.

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

Сравнение приказов: ФСТЭК и ФСБ

Оба документа действуют параллельно и взаимно дополняют друг друга. ФСТЭК определяет, что защищать и как выстроить систему защиты. ФСБ устанавливает, чем шифровать при выходе данных за контролируемый периметр.

Как выполнить требования обоих приказов

Для действующих ГИС ФСТЭК предусмотрел поэтапный переход. Информационное сообщение ФСТЭК России от 12.03.2026 № 240/22/1492 рекомендует разработать план перехода и реализовывать требования последовательно, не дожидаясь единовременной переаттестации всей системы.

1. Инвентаризация и классификация. Определите перечень ГИС в вашей организации, уточните их классы защищённости (К1–К3) и проверьте, попадает ли организация под действие обоих приказов. ГУП и государственные учреждения, ранее не проходившие аттестацию, начинают именно с этого шага.
2. Актуализация модели угроз. Пересмотрите действующую модель угроз с учётом новых требований ФСТЭК. Именно модель угроз определяет класс применяемых СКЗИ по приказу ФСБ — это точка синхронизации двух документов.
3. Разработка плана перехода. Согласно рекомендациям из Информационного сообщения № 240/22/1492, разработайте внутренний план перехода с конкретными сроками и ответственными. Зафиксируйте, какие меры уже реализованы, какие требуют доработки.
4. Реализация организационных мер (ФСТЭК). Разработайте или актуализируйте политики безопасности, регламенты управления доступом, процедуры реагирования на инциденты. Настройте идентификацию и аутентификацию пользователей согласно требованиям приказа.
5. Внедрение или замена СКЗИ (ФСБ). Проверьте, все ли каналы передачи данных за периметр защищены сертифицированными криптосредствами нужного класса. Несертифицированные решения подлежат замене. Убедитесь, что эксплуатация СКЗИ соответствует требованиям ФСБ.
6. Проведение аттестации. Для новых ГИС аттестация обязательна до ввода в эксплуатацию. Для действующих систем — в рамках поэтапного плана. Привлеките аккредитованный орган по аттестации.
7. Организация непрерывного контроля. Аттестация — не финальная точка. Настройте мониторинг событий безопасности, регулярный аудит прав доступа и контроль изменений конфигураций. Это требование ФСТЭК, которое действует на протяжении всего срока эксплуатации ГИС.

Общий контекст: ужесточение, измеримость, импортозамещение

Оба приказа №117 — часть масштабной трансформации российской регуляторики ИБ в 2024–2025 годах. Параллельно с ними вышел пакет изменений сразу по нескольким направлениям.

• Приказ ФСБ №539 от 23.12.2025 — порядок получения субъектами КИИ информации о средствах и способах проведения компьютерных атак и методах их обнаружения.
• Приказ ФСБ №540 от 24.12.2025 — расширение полномочий НКЦКИ: координация аккредитованных центров ГосСОПКА, право запрашивать результаты защитных мероприятий у субъектов КИИ.
• Приказ ФСБ №546 от 25.12.2025 — порядок обмена информацией об атаках и инцидентах между субъектами КИИ, а также с зарубежными и международными организациями. Заменяет Приказ №368 от 2018 года.
• Приказ ФСБ №554 от декабря 2025 — обновлённые требования к средствам ГосСОПКА. Заменяет Приказ №196.

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

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

Два приказа — логичное разделение зон ответственности. ФСТЭК выстраивает архитектуру защиты ГИС и проверяет её через аттестацию. ФСБ обеспечивает криптографический контур там, где данные покидают контролируемую зону. Вместе они формируют единую систему требований, которую нельзя выполнить частично.

Для ГУП и государственных учреждений, впервые попавших под действие обоих документов, 2025–2026 годы — время действовать методично: инвентаризация, модель угроз, план перехода, реализация мер. Статистика утечек из госсектора показывает, что цена промедления — не только штраф, но и реальный ущерб.

Часть организационных требований ФСТЭК — управление доступом, парольные политики, аудит — поддаётся автоматизации. Пассворк берёт на себя рутину: централизованное управление учётными данными, ролевая модель, журнал действий и интеграция с корпоративной инфраструктурой. Это высвобождает ресурс ИБ-команды для задач, которые автоматизировать нельзя, — аттестации, настройки СКЗИ и работы с регуляторами.

Начните подготовку к аттестации с управления доступом. Протестируйте Пассворк бесплатно в своей инфраструктуре

Часто задаваемые вопросы

Чем отличается Приказ ФСТЭК №117 от Приказа ФСБ №117?

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

На кого распространяются оба приказа №117?

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

Когда нужно выполнить требования Приказа ФСТЭК №117?

Приказ ФСТЭК №117 вступил в силу 1 марта 2026 года. Для действующих ГИС предусмотрен поэтапный переход согласно Информационному сообщению ФСТЭК № 240/22/1492 от 12.03.2026 — единовременная переаттестация всех систем не требуется. Приказ ФСБ №117 действует с 6 апреля 2025 года без переходного периода.

Когда обязательно применять СКЗИ по Приказу ФСБ №117?

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

Какие организации выведены из-под действия обоих приказов?

Оба приказа не распространяются на информационные системы Администрации Президента РФ, Совета Безопасности, Федерального Собрания, Правительства, Конституционного Суда, Верховного Суда и ФСБ России, а также на системы, обрабатывающие государственную тайну.

Что изменилось в управлении привилегированным доступом по Приказу ФСТЭК №117?

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

Какие сроки устранения уязвимостей установил Приказ ФСТЭК №117?

Критические уязвимости устраняются в течение 24 часов с момента обнаружения. Уязвимости высокого уровня опасности — в течение 7 календарных дней. При обнаружении уязвимости, отсутствующей в Банке данных угроз ФСТЭК, оператор обязан уведомить регулятора в течение 5 рабочих дней.

С чего начать выполнение требований обоих приказов №117?

Отправная точка — инвентаризация и классификация информационных систем организации. Затем актуализируется модель угроз: она одновременно определяет требуемые меры по ФСТЭК и класс СКЗИ по ФСБ. На основе модели угроз разрабатывается план перехода с конкретными сроками и ответственными.

Приказ ФСТЭК № 117: разбор изменений, Кзи и штрафов

С 1 марта 2026 года Приказ ФСТЭК № 17 утратил силу. Его заменил Приказ № 117 с числовыми метриками КЗИ и ПЗИ, жёсткими сроками устранения уязвимостей и расширенной зоной ответственности. В статье рассмотрим, что изменилось и как подготовиться.

Блог ПассворкаИлья Шелыгин

Импортозамещение ИБ-решений (СЗИ): переход на российское ПО

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

Блог ПассворкаАнастасия Лебедева

Пассворк на «Территории безопасности 2026»

1000+ участников, 90+ спикеров, четыре трека и доклад Пассворка. Рассказываем, как прошёл ежегодный ИБ-форум «Территория безопасности».

Блог ПассворкаАнастасия Лебедева

Запрет на новые закупки иностранных средств защиты для субъектов критической информационной инфраструктуры (КИИ) действует с 1 января 2025 года. Следующий дедлайн перехода существующих систем — 1 января 2028 года. По оценкам экспертов, к этому моменту реально завершат переход лишь 70–75% организаций (CNews, 2025).

Остальные будут догонять в спешке. А спешка при миграции ИБ-стека — это деградация защиты именно тогда, когда инфраструктура наиболее уязвима. ФСТЭК уже проверил более 700 значимых объектов КИИ и выявил свыше 1200 нарушений. При этом минимальный уровень киберзащиты достигнут только у 36% организаций (Инфофорум, 2026).

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

В статье — план перехода на российское ПО: от аудита текущего стека до типичных ошибок при выборе решений.

Главное

• Запрет на закупки уже действует. С 1 января 2025 года новые иностранные СЗИ на значимых объектах КИИ приобретать нельзя. Перейти на отечественное ПО нужно до 1 января 2028 года, для программно-аппаратных комплексов — до 1 декабря 2030 года.
• Обязаны переходить три категории организаций. Субъекты критической инфраструктуры, государственные и муниципальные органы, операторы персональных данных.
• Штрафы за утечки стали реальными. С мая 2025 года размер штрафа зависит от масштаба инцидента: от 3 до 15 млн рублей за первичное нарушение. При повторном — от 1 до 3% годовой выручки, но не менее 20 млн рублей. Иностранные решения без обновлений повышают вероятность инцидента — а значит, и вероятность штрафа.
• Два реестра — две разные вещи. Реестр Минцифры подтверждает, что продукт российский. Сертификат ФСТЭК подтверждает, что он безопасен. Продукт может быть в реестре без сертификата, и наоборот.
• Менять всё сразу — опасно. Когда одновременно заменяют несколько защитных систем, команда теряет контроль над происходящим именно в момент, когда инфраструктура наиболее уязвима.
• Пилот — обязателен. Российские решения нередко конфликтуют с привычными корпоративными системами: почтой, каталогом пользователей, учётными системами. Проблемы, которые не заметили на демо, обнаруживаются в продуктовой среде — и откат тогда стоит дороже, чем три месяца тестирования заранее.
• Иностранные продукты без обновлений — это не защита. Антивирус без свежих баз теряет эффективность за 2–4 недели. Межсетевой экран без патчей становится уязвимым. Продолжать работу на таких решениях — значит повышать вероятность инцидента. А за инцидентом теперь следуют штрафы, которые исчисляются миллионами.
• Государство субсидирует переход. Льготное кредитование от 1% годовых, налоговый вычет с коэффициентом 2 на расходы по российскому ПО, ускоренная амортизация. Большинство компаний об этих инструментах не знают и платят из бюджета полную стоимость.
• Есть легальная отсрочка, но только до 1 сентября 2026 года. Если завершить переход к дедлайну объективно невозможно, заключите контракт на внедрение отечественного аналога до этой даты. Это даёт до 48 месяцев на реализацию — предусмотренный законодателем инструмент планирования, а не лазейка.

Почему импортозамещение ИБ — это юридическая обязанность

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

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

Ключевые нормативные акты

Кому и когда обязательно переходить на отечественное ПО

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

Субъекты критической информационной инфраструктуры (КИИ)

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

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

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

Государственные и муниципальные органы

Для госорганов требования действуют с 2022 года. С 2026 года любое использование иностранного ПО в сфере ИБ становится невозможным. Бюджетные учреждения здравоохранения, образования и культуры также обязаны планировать переход, даже если они не являются субъектами КИИ в классическом смысле.

Операторы персональных данных (ПДн)

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

Сроки перехода для КИИ

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

Оборотные штрафы за утечки персональных данных

Федеральный закон №420-ФЗ, вступивший в силу 30 мая 2025 года, пересмотрел административную ответственность за утечки персональных данных — новые части 12–15 ст. 13.11 КоАП РФ ввели прямую зависимость штрафа от масштаба инцидента.

Градация штрафов для организаций за первичное нарушение

За повторное нарушение — оборотный штраф: от 1 до 3% совокупной годовой выручки, но не менее 20 млн и не более 500 млн рублей. Важная деталь: 50-процентная скидка при досрочной уплате штрафа по всем составам ст. 13.11 КоАП РФ не применяется (Федеральный закон № 420-ФЗ, ч. 1.3-1 ст. 32.2 КоАП РФ)

Первые судебные прецеденты по ст. 13.11 КоАП РФ (2026)

Что показывает первая практика

Оба решения демонстрируют одну тенденцию: суды пока склонны к максимальному смягчению наказания, используя все доступные процессуальные механизмы — статус микропредприятия, первичность нарушения, отсутствие отягчающих обстоятельств. В деле А40-351064/2025 штраф снижен в 25 раз относительно минимального порога санкции; в деле А56-4733/2026 штраф заменён на предупреждение, несмотря на утечку данных 70 000 человек.

Это не означает, что риск минимален. Механизм оборотных штрафов при повторном нарушении остаётся в полной силе: для компании с выручкой 1 млрд руб. повторный инцидент означает штраф от 20 млн руб. Кроме того, лояльность судов первой инстанции не гарантирована — практика только складывается, и позиция регулятора при обжаловании может изменить картину.

Связь с импортозамещением

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

Чем заменить иностранные ИБ-решения

Российский рынок ИБ прошёл точку невозврата. По данным ЦСР «Прогноз развития рынка кибербезопасности РФ 2025–2030», доля иностранных решений в общем объёме затрат российских компаний на ИБ снизилась до 7% по итогам 2024 года — против 11% годом ранее.

«Российский рынок ИБ за последние два года проделал серьезный путь - от экстренного импортозамещения к более зрелой фазе, где заказчики уже не просто ищут замену ушедшим вендорам, а выбирают решения по качеству, производительности и уровню поддержки. По сути, базовый этап импортозамещения пройден, и теперь рынок формируется вокруг нескольких крупных игроков с собственной разработкой и доказанной экспертизой», — Иван Чернов, директор по продуктовой стратегии UserGate

Для сравнения: в сегменте сетевой безопасности ещё недавно этот показатель достигал 40–50% (данные консалтинговой компании Б1, исследование «Рынок информационной безопасности России — 2024»). Сдвиг принципиальный.

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

По данным TAdviser, объём рынка ИБ России в 2025 году превысил 400 млрд рублей при росте 20–25%. В 2024 году рынок составил 314 млрд рублей (+26,3%) — выше мирового роста в 11,8% (ЦСР). К 2030 году эксперты ЦСР прогнозируют рост ёмкости рынка до 968 млрд рублей при среднегодовом приросте около 21%. Наибольший рост ожидается в сегментах сетевой и облачной безопасности, защиты данных, MDR и MSS.

Пассворк — российский менеджер паролей, сертифицированный ФСТЭК России по 4-му уровню доверия. Разверните решение внутри своей инфраструктуры, обеспечите полный контроль над данными и соответствие требованиям регуляторов. Протестируйте Пассворк бесплатно

Пошаговый план перехода на российское ПО

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

Этап 1. Аудит и инвентаризация

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

Чек-лист аудита

1. Составить реестр всех используемых ИБ-решений (иностранных и российских)
2. Указать сроки окончания лицензий для каждого продукта
3. Определить статус каждого решения: работает в штатном режиме / без поддержки / с ограниченной функциональностью
4. Зафиксировать, какие активы защищает каждый инструмент (периметр, конечные точки, данные, доступ)
5. Выявить зависимости: какие системы интегрированы между собой
6. Классифицировать объекты КИИ (если применимо) по категориям значимости
7. Оценить критичность каждого инструмента для непрерывности бизнеса
8. Оценить совместимость текущего оборудования с российскими решениями

Результат этапа: карта текущего ИБ-стека с приоритетами замены и оценкой рисков для каждого инструмента.

Этап 2. Проверка по реестрам и определение требований

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

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

Реестр Минцифры — реестр российского ПО. Включение подтверждает российское происхождение продукта. Обязателен для госзакупок по 44-ФЗ и 223-ФЗ.

Реестр сертифицированных СЗИ ФСТЭК — реестр средств защиты информации, прошедших испытания на соответствие требованиям безопасности. Обязателен для защиты КИИ и ГИС (государственных информационных систем).

Продукт может быть в реестре Минцифры, но не иметь сертификата ФСТЭК — и наоборот. Для защиты объектов КИИ нужны оба подтверждения.

Чек-лист подбора аналога

1. Проверить каждый планируемый к закупке продукт в реестре Минцифры
2. Проверить наличие сертификата ФСТЭК
3. Для СКЗИ — проверить сертификат ФСБ
4. Убедиться, что сертификат не просрочен (срок действия — как правило, 3 года)
5. Уточнить дорожную карту развития продукта на 2–3 года
6. Оценить стоимость владения: лицензии + внедрение + поддержка

Этап 3. Пилотный проект и тестирование

Пилотный проект (Proof of Concept, PoC) — единственный способ проверить, работает ли решение в вашей конкретной среде, а не в контролируемых условиях демонстрации вендора.

Что должно включать полноценное тестирование ПО

1. Развернуть тестовый стенд в изолированной среде
2. Проверить совместимость с существующими системами
3. Протестировать работу под нагрузкой
4. Собрать обратную связь от администраторов и ключевых пользователей
5. Оценить производительность и совокупную стоимость владения на горизонте 3–5 лет
6. Зафиксировать все выявленные ограничения и договориться с вендором о планах их устранения

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

Этап 4. Поэтапная миграция

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

Документируйте каждое изменение и держите план отката готовым для каждого этапа.

Чек-лист внедрения:

1. Составить план миграции с приоритизацией систем (некритичные → критичные)
2. Обеспечить параллельную работу старых и новых СЗИ на переходный период
3. Настроить правила миграции данных и политики безопасности
4. Задокументировать все изменения конфигурации
5. Разработать и протестировать план отката для каждого этапа

Этап 5. Обучение команды и адаптация процессов

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

Чек-лист обучения:

1. Организовать обучение администраторов у вендора или сертифицированного учебного центра
2. Провести тестирование на проникновение (пентест) после завершения миграции
3. Оптимизировать настройки СЗИ на основе первых 2–4 недель эксплуатации
4. Обновить внутреннюю документацию и регламенты ИБ
5. Настроить мониторинг и алертинг в SIEM-системе
6. Запланировать ревью через 3 месяца после запуска

Главные ошибки при миграции на российские ИБ-решения

Большинство неудачных проектов по импортозамещению объединяет неверный подход к планированию.

Заменим всё за один раз

Игнорирование проблем совместимости

Покупка ПО не из реестра Минцифры

Отсутствие плана отката

Надежда на параллельный импорт

Государственная поддержка: как сэкономить на переходе

Государство субсидирует переход на российские ИБ-решения тремя инструментами, о которых знают далеко не все.

• Льготное кредитование. Министерство цифрового развития реализует программу льготного кредитования для внедрения отечественного ПО. Для российских организаций и аккредитованных ИТ-компаний ставка составляет от 1% до 5% годовых, при этом максимальная сумма кредита на один проект может достигать 5 миллиардов рублей, а на комплексную программу — до 10 миллиардов рублей.
• Налоговые льготы. Организации получают право на ускоренную амортизацию отечественного ПО с коэффициентом 3. Расходы на российские СЗИ не только уменьшают налогооблагаемую базу по налогу на прибыль, но и могут учитываться с повышающим коэффициентом 2 (с 1 января 2025 года), что позволяет списывать затраты в двойном размере. Кроме того, реализация прав на ПО из реестра Минцифры освобождается от НДС (0%) для определённых категорий организаций (пп. 26 п. 2 ст. 149 НК РФ).
• Механизм легальной отсрочки. Если компания (например, субъект КИИ) объективно не успевает завершить переход к 1 января 2028 года, законодательство предусматривает возможность отсрочки. Для этого необходимо до 1 сентября 2026 года заключить контракт на внедрение отечественного аналога. Тогда у компании появляется до 48 месяцев на реализацию с возможностью дальнейшего продления. Это не лазейка — это легальный инструмент планирования, предусмотренный законодателем для организаций с объективно сложной инфраструктурой.

Пассворк: совместимость и регуляторный статус

Пассворк — российский менеджер паролей для бизнеса с развёртыванием на собственном сервере организации. Все данные об учётных записях хранятся внутри периметра: никакой зависимости от внешних сервисов.

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

Совместимость с российскими платформами подтверждена официальными сертификатами. Пассворк протестирован и сертифицирован совместно со следующими решениями.

Пассворк интегрируется с SSO, Active Directory и LDAP, поддерживает подключение к SIEM-системам и ведёт полный журнал действий пользователей — от создания записи до каждого факта просмотра пароля. Это напрямую закрывает требования регуляторов к разграничению доступа и аудиту при работе с объектами КИИ.

Браузерные расширения доступны для Chrome, Firefox, Edge и Safari. Мобильное приложение — в App Store, Google Play и RuStore.

Заключение: с чего начать прямо сейчас

Импортозамещение ИБ — не разовая закупка. Чем раньше начат аудит, тем больше времени на пилот, обучение персонала и поэтапную миграцию без авралов.

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

Здесь логично начать с Пассворка: корпоративный менеджер паролей разворачивается на вашем сервере, интегрируется с SSO, AD/LDAP и SIEM-системами и ведёт полный журнал действий. Продукт включён в реестр отечественного ПО Минцифры, сертифицирован ФСТЭК, компания-разработчик имеет действующие лицензии ФСТЭК и ФСБ — это закрывает требования регуляторов к разграничению доступа ещё на старте проекта.

Ключевые дедлайны уже наступили: с апреля 2026 года действуют новые штрафы по ФЗ №77-ФЗ, с июня 2026 года дорожная карта импортозамещения становится обязательной. Дедлайн для значимых объектов КИИ (1 января 2028 года) кажется далёким, но с учётом реальных сроков пилота, миграции и обучения персонала запас времени меньше, чем кажется.

Начните с аудита решений и управления доступами. Это честный первый шаг, после которого картина становится понятной.

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

Часто задаваемые вопросы

Нужно ли малому бизнесу импортозамещение ИБ?

Малый бизнес обязан соблюдать требования, если он является субъектом КИИ или оператором персональных данных. Медицинские клиники, страховые компании, образовательные организации, ритейл с базами клиентов — все они операторы ПДн. Для них обязательна защита ИСПДн российскими сертифицированными средствами.

Что такое Реестр Минцифры и зачем он нужен при импортозамещении?

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

Как проверить, есть ли продукт в реестре Минцифры?

Перейдите на reestr.digital.gov.ru, введите название продукта или ИНН производителя в строку поиска. Реестр публичный и обновляется в реальном времени. Для проверки сертификата ФСТЭК используйте отдельный реестр: reestr.fstec.ru. Проверяйте оба реестра перед каждой закупкой СЗИ.

Обязателен ли сертификат ФСТЭК России?

Сертификат ФСТЭК обязателен для средств защиты информации, используемых субъектами КИИ и операторами ИСПДн, обрабатывающими персональные данные 1–3 уровня защищённости. Наличие сертификата подтверждает соответствие продукта требованиям регуляторов и упрощает прохождение аудитов. Пассворк сертифицирован ФСТЭК России по 4-му уровню доверия.

Когда субъекты КИИ обязаны перейти на российское ПО?

Крайний срок перехода значимых объектов КИИ на отечественное программное обеспечение — 1 января 2028 года. Для программно-аппаратных комплексов (ПАК) предусмотрена возможность продления до 1 декабря 2030 года. Запрет на новые закупки иностранных средств защиты информации для КИИ действует с 1 января 2025 года согласно Указу №250.

Что такое пилотный запуск, и сколько времени он занимает?

Пилот — тестирование решения в среде, максимально приближённой к настоящей, для проверки работоспособности, совместимости и производительности ПО. Продолжительность теста для точечных решений, например, менеджера паролей, составляет 2–4 недели, для SIEM — 4–8 недель .

Что делать с иностранным ИБ-решением, которое уже работает без поддержки вендора?

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

Таблицы российских аналогов

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

Сетевая безопасность

NGFW — межсетевые экраны нового поколения

IDS/IPS — обнаружение и предотвращение вторжений

VPN-шлюзы и СКЗИ — криптографическая защита каналов

Защита конечных точек и выявление атак

EDR — обнаружение угроз на конечных точках

NTA/NDR — анализ сетевого трафика

Песочницы (Network Sandbox)

Мониторинг и управление (SIEM, SOAR, XDR)

SIEM — управление событиями безопасности

SOAR/IRP — автоматизация реагирования

XDR — расширенное обнаружение и реагирование

Защита данных (DLP, DCAP, DAM)

DLP — защита от утечек данных

DCAP — аудит неструктурированных данных

DAM — мониторинг баз данных

Идентификация и управление доступом (IAM, PAM, MFA)

IDM/IGA — управление учётными записями и правами

PAM — контроль привилегированных пользователей

MFA — многофакторная аутентификация

Корпоративный менеджер паролей

Защита приложений и веб-безопасность

WAF — защита веб-приложений

AST — анализ защищённости кода

Anti-DDoS — защита от распределённых атак

Промышленная безопасность (АСУ ТП)

При замене десятков иностранных систем учётные данные от новых решений нужно где-то хранить и контролировать. Менеджер паролей для бизнеса Пассворк закрывает эту задачу: локальное и облачное развёртывание, интеграция с AD/LDAP и SIEM-системами, ролевая модель доступа, лицензии ФСТЭК и ФСБ. Более 2000 компаний уже используют Пассворк, включая организации, прошедшие аудиты безопасности на системообразующих предприятиях.

Первый менеджер паролей с сертификацией ФСТЭК России

30 апреля 2026 года Пассворк получил сертификат ФСТЭК России № 5063 по 4-му уровню доверия — наивысшему для коммерческих средств защиты информации. Пассворк стал первым российским менеджером паролей, который может применяться в ГИС, ИСПДн, КИИ и АСУ ТП 1 класса защищённости.

Блог ПассворкаИлья Шелыгин

Постквантовая криптография: угрозы и стандарты — 2026

Квантовые компьютеры ещё не взломали ни одного шифра, но атаки уже идут. Разбираем HNDL-угрозу, глобальные дедлайны регуляторов, российские алгоритмы-кандидаты и первые промышленные пилоты QKD в России.

Блог ПассворкаИлья Шелыгин

Кейс-стади: МТС Банк и Пассворк

Как МТС Банк объединил управление паролями в единой системе с помощью Пассворка и повысил уровень безопасности.

Блог ПассворкаАнастасия Лебедева

Вступление

С 1 марта 2026 года правила защиты государственных информационных систем изменились. Приказ ФСТЭК № 17, действовавший 13 лет, утратил силу. На его место пришёл Приказ № 117 — документ, который меняет не только требования, но и логику оценки безопасности.

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

Главное

• Кзи — показатель защищённости. Коэффициент защищённости информации, числовой показатель от 0 до 1 — рассчитывается каждые 6 месяцев и направляется в ФСТЭК.
• Пзи — оценка зрелости процессов. Раз в 2 года организация подтверждает, что защита выстроена системно, а не держится на конкретных людях.
• Сроки устранения уязвимостей. Критические — 24 часа, высокие — 7 дней. Нарушение сроков напрямую снижает Кзи.
• Расширенная зона ответственности. Под действие приказа попадают не только ГИС, но и муниципальные информационные системы и системы ГУП. Для подрядчиков с доступом к государственным и муниципальным системам требования к информационной безопасности должны быть закреплены в документах, регулирующих такой доступ (в том числе в договорах).
• Новые требования к ИИ, кадрам и разработке. Системы с компонентами искусственного интеллекта — отдельный объект оценки. Не менее 30% сотрудников подразделения ИБ обязаны иметь профильное образование. Разработка ПО — только по ГОСТ Р 56939-2024.
• Практический вывод. Действующие аттестаты по Приказу № 17 сохраняют силу до истечения срока, но разработать план перехода на новые требования нужно уже сейчас — это прямая рекомендация ФСТЭК (информационное сообщение № 240/22/1492 от 12 марта 2026 года).

Что такое Приказ ФСТЭК № 117

Приказ ФСТЭК России № 117 — нормативный документ, вступивший в силу 1 марта 2026 года и устанавливающий требования к защите государственных, муниципальных информационных систем и систем ГУП. Он заменил Приказ № 17 (2013) и ввёл принципиально новый подход: вместо разовой аттестации — непрерывный расчёт числовых показателей защищённости.

Приказ принят во исполнение Федерального закона № 149-ФЗ «Об информации, информационных технологиях и о защите информации» и распространяется на операторов ГИС федерального и регионального значения, муниципальных информационных систем, систем ГУП, а также на их подрядчиков.

Почему отменили 17-й приказ и в чём суть Приказа № 117

Приказ ФСТЭК № 17 — нормативный документ 2013 года, устанавливавший требования к защите государственных информационных систем. Он определял состав организационных и технических мер, порядок аттестации ГИС и классификацию систем по уровню значимости обрабатываемой информации.

Приказ № 17 строился на качественной оценке, при которой организация получала класс защищённости: К1 (высокий, для систем с персональными данными и сведениями ограниченного доступа), К2 (средний) или К3 (низкий) — и аттестат соответствия. Класс присваивался один раз и пересматривался только при существенных изменениях в системе.

Приказ № 117 сохраняет классификацию систем: класс защищённости по-прежнему присваивается и пересматривается при изменении системы. Принципиальное новшество — числовые метрики Кзи и Пзи, которые дополняют классификацию и требуют регулярного пересчёта. Безопасность теперь измеряется числом, пересчитывается каждые полгода и сравнивается с базовым порогом.

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

Кого касаются новые требования

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

В России насчитывается свыше 4000 государственных информационных систем федерального и регионального значения. При этом 73% всех утечек данных из российских организаций в 2025 году пришлось на госсектор — именно это стало одним из триггеров ужесточения требований.

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

Главные нововведения: Кзи, Пзи и жёсткие сроки устранения уязвимостей

Три ключевых изменения Приказа № 117 — числовые метрики Кзи и Пзи и обязательные сроки устранения уязвимостей. Разберём каждое из них.

Кзи — коэффициент защищённости информации

Кзи — числовой показатель от 0 до 1, рассчитываемый по методике ФСТЭК от 11 ноября 2025 года (была принята отдельно) на основе 16 критериев в 4 группах:

• Организационные меры — наличие политик ИБ, регламентов, обучения персонала, контроля подрядчиков.
• Технические меры — средства защиты информации, управление доступом, парольные политики, шифрование.
• Контроль защищённости — сканирование уязвимостей, аудит конфигураций, пентесты.
• Реагирование на инциденты — наличие процедур, скорость реакции, взаимодействие с ГосСОПКА.

Базовый минимум Кзи равен 1. Значение ниже 1 означает наличие уязвимостей и требует разработки плана мероприятий, а критическое несоответствие наступает при Кзи ≤ 0,75.

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

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

Пзи — показатель уровня зрелости

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

Показатель рассчитывается раз в 2 года. Методика его расчёта на момент публикации статьи ещё не принята — ФСТЭК анонсировала отдельный документ, который определит конкретные критерии оценки. В качестве ориентира: подобные модели зрелости, как правило, описывают пять уровней — от неформализованных реактивных процессов до непрерывно улучшаемых и количественно контролируемых.

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

Кратко о Кзи и Пзи

Кзи отвечает на вопрос «защищены ли мы прямо сейчас от типовых угроз». Пзи — на вопрос «насколько зрелы наши процессы ИБ в целом». Первый считается раз в полгода и реагирует на оперативные изменения. Второй даёт стратегическую картину и пересматривается раз в два года.

Сроки устранение уязвимостей

Приказ № 117 впервые в российской регуляторике устанавливает обязательные сроки устранения уязвимостей. Раньше организация сама определяла, когда и как реагировать. Теперь дедлайны зафиксированы нормативно — их нарушение фиксируется при расчёте Кзи.

Отдельное требование: если организация выявила уязвимость, сведений о которой ещё нет в БДУ ФСТЭК, — передать информацию регулятору необходимо в течение 5 рабочих дней.

Критические уязвимости

Уязвимости, позволяющие злоумышленнику получить полный контроль над системой без аутентификации: удалённое выполнение кода, обход авторизации, захват привилегий. Срок устранения — 24 часа с момента публикации в БДУ ФСТЭК. На практике это означает: обнаружили утром — к следующему утру патч должен быть применён или уязвимость изолирована компенсирующими мерами.

Высокие уязвимости

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

Новые уязвимости из БДУ ФСТЭК

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

Средние и низкие уязвимости

Эксплуатация требует специфических условий и значительных усилий атакующего. Приказ № 117 не устанавливает для них единый срок — организация фиксирует дедлайны во внутреннем регламенте. Важно: регламент должен существовать в письменном виде и соблюдаться — его наличие и исполнение проверяется при расчёте Кзи.

Без автоматизации управления уязвимостями выполнить эти требования в масштабе крупной ГИС практически невозможно. Ручной контроль не обеспечивает нужную скорость реакции: к моменту, когда администратор вручную обнаружит критическую уязвимость и согласует патч, 24-часовое окно уже закроется.

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

Другие критичные изменения для бизнеса

Кадровые требования

Приказ № 117 устанавливает требования к квалификации специалистов по ИБ (п. 20): не менее 30% сотрудников подразделения кибербезопасности должны иметь профильное образование или пройти профессиональную переподготовку в области информационной безопасности.

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

Строгая аутентификация

Вводится понятие строгой аутентификации (по ГОСТ Р 58833-2020), которая становится обязательной для удалённого доступа к ИС, доступа с мобильных устройств и привилегированного доступа (администраторов). Это дополнительный аргумент в пользу внедрения специализированных решений для управления доступом.

Безопасная разработка

Приказ № 117 обязывает следовать ГОСТ Р 56939-2024 при самостоятельной разработке программного обеспечения — когда оператор или обладатель информации разрабатывает ПО для собственной ИС своими силами (п. 14, подп. «д»). Для таких организаций внедрение практик безопасной разработки становится обязательным условием аттестации системы.

Требования к системам на основе ИИ

Пункт 61 Приказа № 117 впервые вводит специальные требования для информационных систем, взаимодействующих с сервисами искусственного интеллекта. Требования разделяются по формату взаимодействия.

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

Отдельно предусмотрены требования к работе с недостоверными ответами ИИ:

• разработать статистические критерии выявления недостоверных ответов;
• собирать и анализировать такие ответы;
• ограничивать область принимаемых решений на основе недостоверных ответов.

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

Как выглядит расчёт Кзи на практике

Разберём условную региональную ГИС — систему учёта муниципального имущества. Все цифры в примере условные, структура расчёта — по методике ФСТЭК от 11 ноября 2025 года.

Структура Кзи: 4 группы, 16 показателей

Методика ФСТЭК делит все частные показатели на 4 группы с фиксированными весовыми коэффициентами:

Итоговый Кзи рассчитывается как сумма произведений: значение группы × её вес. Нормированное значение — Кзи = 1. Это не «отлично» — это минимально допустимый уровень.

Важная особенность методики: каждый частный показатель принимает только два значения — либо максимальное (из таблицы), либо 0. Промежуточных оценок нет. Мера либо реализована, либо нет.

Пример расчёта: условная ГИС

Группа 1 — Организация и управление (вес 0,10)

Группа 2 — Защита пользователей (вес 0,25)

Группа 3 — Защита информационных систем (вес 0,35)

Группа 4 — Мониторинг и реагирование (вес 0,30)

Итоговый Кзи

Кзи=0,070+0,175+0,228+0,195=0,668

Наш результат: 0,668 — критический уровень. Организация обязана разработать план мероприятий до следующей плановой оценки.

Что нужно исправить в первую очередь

Четыре провальных показателя с нулевым значением дали наибольшие потери. Приоритет — по весу группы:

Устранение всех четырёх нарушений даст расчётный Кзи ≈ 0,965. Для достижения Кзи = 1 дополнительно потребуется заключить договор на Anti-DDoS (k36).

Дополнительный риск: обнуление группы целиком

Методика содержит жёсткое правило (п. 35): если при повторной оценке в течение 12 месяцев тот же показатель снова получает 0 — весовой коэффициент всей группы обнуляется. Вся группа выпадает из расчёта.

Для нашего примера это означает: если k32 (уязвимости на периметре) снова окажется нулевым через полгода — группа 3 с весом 0,35 полностью обнулится. Итоговый Кзи не превысит 0,65 при любых других улучшениях.

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

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

Штрафы и ответственность в 2026 году

За нарушения требований защиты информации в ГИС штраф для юридического лица по ст. 13.12 КоАП составляет от 50 000 до 100 000 рублей. Если эти нарушения привели к утечке персональных данных, дополнительно применяется ст. 13.11 КоАП — штрафы достигают 500 000–1 000 000 рублей за каждый эпизод.

Помимо штрафов, нарушения создают риски при участии в госзакупках по 44-ФЗ и 223-ФЗ. Организация с неурегулированными требованиями ИБ фактически ограничивает себе доступ к государственным контрактам.

ФСТЭК в информационном сообщении № 240/22/1492 от 12 марта 2026 года разъяснила: организации обязаны разработать планы перехода с описанием мероприятий и сроков реализации. Это официальное требование регулятора.

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

Как корпоративный менеджер паролей помогает выполнить требования Приказа № 117

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

Корпоративный менеджер паролей Пассворк закрывает несколько критериев Кзи одновременно. Разберём конкретные показатели Кзи:

k21 — Парольная политика (вес 0,30)

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

k22 — Многофакторная аутентификация привилегированных пользователей (вес 0,30)

Показатель требует подтвердить, что МФА охватывает не менее 50% администраторов и привилегированных пользователей. Пассворк позволяет включить обязательную двухфакторную аутентификацию для всех пользователей централизованно — одной настройкой на уровне организации. Это гарантирует 100% охват привилегированных учётных записей и полностью закрывает требование k22 без ручного контроля каждого пользователя.

k23 — Отсутствие сервисных учётных записей с паролями по умолчанию (вес 0,20)

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

k24 — Удаление учётных записей уволенных сотрудников (вес 0,20)

Показатель проверяется через наличие ОРД с требованием об удалении учёток при прекращении трудовых отношений. Пассворк позволяет мгновенно отозвать доступ ко всем паролям и системам при увольнении сотрудника — в один клик, без риска пропустить отдельные учётные записи в разных системах.

k13 — Требования ИБ в договорах с подрядчиками (вес 0,30 в группе «Организация и управление»)

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

Снижение нагрузки на ИБ-команду

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

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

Пассворк входит в реестр отечественного ПО, имеет действующие лицензии ФСТЭК и ФСБ. Развёртывание — внутри инфраструктуры организации: данные не покидают периметр. Это значимо и для прохождения оценки Кзи, и для участия в закупках по 44-ФЗ и 223-ФЗ.

Заключение

Приказ № 117 — это переход от формальной аттестации к реальной, измеримой безопасности. Числовые метрики Кзи и Пзи, жёсткие сроки устранения уязвимостей и расширенная зона ответственности требуют не просто обновления документации, а перестройки процессов.

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

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

Управление доступом, контроль учётных записей, журнал действий — Пассворк закрывает эти задачи в одном решении, развёрнутом внутри вашей инфраструктуры. Протестируйте бесплатно → passwork.ru

Часто задаваемые вопросы

Что такое Кзи и как его считать?

Кзи — коэффициент защищённости информации, числовой показатель от 0 до 1. Рассчитывается по методике ФСТЭК на основе 16 критериев в 4 группах: организационные меры, технические меры, контроль защищённости и реагирование на инциденты. Базовый минимум — Кзи = 1 (при КЗИ ≤ 0,75 уровень считается критическим). Оценка проводится раз в 6 месяцев.

Что такое Пзи и зачем он нужен?

Пзи — показатель уровня зрелости процессов ИБ. Рассчитывается раз в 2 года по пятиуровневой шкале и отражает, насколько системно выстроена защита. Высокий Кзи при низком Пзи означает, что организация выполняет требования формально, но не устойчива к реальным инцидентам.

Кого касается Приказ № 117?

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

Действует ли мой аттестат по Приказу № 17?

Да, аттестаты сохраняют силу до истечения срока, но только при неизменности конфигурации системы. Любая модернизация потребует переаттестации по Приказу № 117. При этом расчёт Кзи по новой методике необходимо начать уже сейчас — это требование регулятора, зафиксированное в информационном сообщении ФСТЭК № 240/22/1492 от 12 марта 2026 года.

Какие штрафы грозят за нарушение требований?

За нарушение требований ФСТЭК (ст. 13.12 КоАП) штраф для юридического лица составляет до 100 000 рублей. Если нарушение привело к утечке персональных данных (ст. 13.11 КоАП) — до 1 000 000 рублей за каждый эпизод. Дополнительный риск: организации с неурегулированными требованиями ИБ фактически ограничивают себе доступ к государственным контрактам по 44-ФЗ и 223-ФЗ.

Что изменилось в требованиях к подрядчикам?

Приказ № 117 обязывает операторов ГИС и муниципальных информационных систем ознакомить подрядчиков с политикой защиты информации и закрепить в договоре обязанность соблюдать установленные регламенты (п. 16 и 26). Подрядчики не подпадают под действие приказа напрямую, однако оператор несёт ответственность за то, чтобы требования были зафиксированы документально и фактически соблюдались.

Что Приказ № 117 требует от организаций, использующих ИИ?

Пункт 61 Приказа № 117 вводит специальные требования для систем, взаимодействующих с сервисами искусственного интеллекта. Оператор обязан определить допустимые форматы запросов и ответов, контролировать соответствие каждого взаимодействия установленным границам, разработать критерии выявления недостоверных ответов и ограничивать принятие решений на их основе. В состав систем допускаются только доверенные технологии ИИ.

Как выполнить кадровые требования Приказа № 117?

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

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

Блог ПассворкаИлья Шелыгин

Двухфакторная аутентификация для бизнеса: внедрение и защита

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

Блог ПассворкаИлья Шелыгин

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

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

Блог ПассворкаАнастасия Лебедева