Госсектор

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

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

Главное о менеджере паролей для госсектора за 5 минут

• Менеджер паролей для госсектора — это СЗИ (средство защиты информации) или общесистемное ПО для централизованного управления учётными данными в ГИС, ИСПДн и на объектах КИИ.
• Ключевое отличие от корпоративного решения — не в функционале, а в контуре применения: дополнительная нормативная база (152-ФЗ, 187-ФЗ, приказы ФСТЭК), требования к развёртыванию и криптографии.
• Выбор продукта начинается не со сравнения рейтингов, а с проверки допуска: сертификация ФСТЭК, запись в реестре отечественного ПО и соответствие модели развёртывания классу защищённости системы.
• Требования делятся на 8 групп — от нормативной применимости и размещения данных до контроля доступа, аудита и пользовательского опыта. Конкретный набор фиксирует проектная документация на систему.
• Для значимых объектов КИИ развёртывание на собственной инфраструктуре часто становится обязательным условием, а не опцией.
• Пассворк — менеджер паролей и сертифицированное ФСТЭК СЗИ (№ 5063, 4-й уровень доверия), включён в реестр отечественного ПО (№ 6147).
• Внедрение проходит пять фаз: аудит и подготовка, выбор и закупка, пилотное внедрение, полное развёртывание, аттестация и передача в эксплуатацию.

Что такое менеджер паролей для госсектора и чем он отличается от корпоративного

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

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

• Нормативная база. Корпоративный менеджер паролей подчиняется внутренним политикам компании и, опционально, отраслевым стандартам. Решение для госсектора дополнительно подпадает под 152-ФЗ, 187-ФЗ и приказы ФСТЭК.
• Требования к развёртыванию. В коммерческом секторе облачное размещение — норма. Для значимых объектов КИИ и систем высокого класса защищённости развёртывание на собственной инфраструктуре часто становится обязательным условием, а не опцией.
• Криптография. Корпоративному решению достаточно индустриального стандарта (AES-256). Для систем определённого класса защищённости проектная документация может требовать поддержку ГОСТ-алгоритмов.
• Сертификация и импортозамещение. Для госсектора сертификат соответствия ФСТЭК России и запись в реестре отечественного ПО — обязательные условия допуска к закупке, а при работе с ГИС и КИИ использование иностранного ПО дополнительно ограничивают указы Президента №166 и №250.

Какие требования предъявляют к менеджеру паролей в госсекторе

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

Группа 1. Нормативная и закупочная применимость

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

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

Группа 2. Размещение и контроль данных

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

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

Группа 3. Безопасность хранения

Группа охватывает шифрование данных, управление ключами и то, как система защищает основное хранилище.

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

Группа 4. Аутентификация и контроль доступа

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

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

Группа 5. Интеграции и администрирование

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

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

Группа 6. Аудит, SIEM и отчётность

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

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

Группа 7. Работа с паролями и общими секретами

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

Группа 8. Клиенты и пользовательский опыт

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

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

Как Пассворк закрывает эти требования

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

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

Нормативная база и сертификация

Размещение и изоляция данных

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

Шифрование и защита хранилища

Пассворк поддерживает серверное и клиентское шифрование (архитектура zero-knowledge): сервер получает и хранит только зашифрованные данные, а расшифровка происходит на устройстве пользователя.

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

Роли, группы и политики сейфов

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

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

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

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

Сертификаты совместимости с российскими ОС

Пассворк официально совместим с ведущими российскими операционными системами и инфраструктурными решениями. Менеджер паролей стабильно работает на Astra Linux, РЕД ОС, Альт Сервер, SelectOS, ОС «МСВСфера» и других отечественных дистрибутивах. Совместимость подтверждена двусторонними сертификатами с разработчиками платформ.

Для государственной организации, которая строит инфраструктуру на отечественном стеке (например, Astra Linux с MultiDirectory и Pangolin DB) это означает готовое, проверенное совместно с разработчиками решение.

Аутентификация и авторизация

Аутентификация в Пассворке настраивается по ролям и группам, а не единой политикой на всю систему: 2FA можно сделать обязательной, а требования к паролю входа и мастер-паролю задаются раздельно.

Интеграции с инфраструктурой

Пассворк синхронизируется с LDAP и Active Directory, поддерживает SSO и предоставляет полнофункциональный API для автоматизации административных операций: создания пользователей, назначения прав и выгрузки событий аудита без ручного вмешательства (более 400 операций).

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

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

Журнал действий и интеграция с SIEM

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

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

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

Управление паролями и общими секретами

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

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

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

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

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

Нативные приложения и техническая поддержка

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

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

Сводная таблица: требование госсектора → ответ Пассворка

Пошаговый план внедрения менеджера паролей в госорганизации

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

Фаза 1. Аудит и подготовка

1. Инвентаризация учётных записей и парольных практик.
2. Определение перечня систем, попадающих под КИИ, ГИС или ИСПДн.
3. Формирование требований к СЗИ на основе класса защищённости.
4. Назначение ответственных: офицер безопасности и администратор.

Фаза 2. Выбор и проверка

5. Проверка реестра отечественного ПО и реестра сертифицированных СЗИ ФСТЭК.
6. Запрос коммерческого предложения с учётом 44-ФЗ или 223-ФЗ.
7. Проверка сертификата ФСТЭК на сайте регулятора.
8. Тестирование пилотной установки на тестовом контуре.

Фаза 3. Пилотное внедрение

9. Развёртывание на тестовой среде в изолированном контуре.
10. Интеграция с LDAP/AD, настройка SSO для пилотной группы.
11. Импорт существующих паролей в защищённое хранилище.
12. Пилот на группе 10–20 пользователей, сбор обратной связи.

Фаза 4. Полное развёртывание

13. Развёртывание в продуктивной среде на всей инфраструктуре.
14. Настройка ролевой модели (RBAC) по принципу наименьших привилегий.
15. Настройка политик паролей: сложность, срок действия, история переиспользования.
16. Массовое подключение пользователей, обучение сотрудников и администраторов.

Фаза 5. Аттестация и мониторинг

17. Аттестационные испытания, если требуются по проектной документации.
18. Настройка регулярного аудита, интеграции с SIEM и оповещений.
19. Формирование регламента аварийного восстановления.
20. Передача в эксплуатацию с регламентом ежеквартального аудита политик и прав доступа.

Заключение

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

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

Готовы повысить уровень безопасности? Пассворк — сертифицированное ФСТЭК средство защиты информации. Пассворк закрывает все пункты требований из этой статьи: от локализации данных до интеграции с SIEM и российскими ОС. Разверните Пассворк в тестовом контуре и проведите пилотное внедрение бесплатно.

Часто задаваемые вопросы о менеджерах паролей для госсектора

Можно ли использовать облачный менеджер паролей в госсекторе?

Только если облачная инфраструктура аттестована по требованиям ФСТЭК и принадлежит российскому провайдеру. Для значимых объектов КИИ допустимо исключительно развёртывание на собственной архитектуре.

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

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

Как проверить, что менеджер паролей действительно включён в реестр отечественного ПО?

Проверка выполняется на официальном сайте reestr.digital.gov.ru по названию продукта или ИНН правообладателя. В выписке из реестра указан регистрационный номер записи, класс программного обеспечения и дата включения — эти данные стоит запросить у поставщика как отдельный артефакт для ТЗ.

Что такое СЗИ?

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

Что такое КИИ?

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

Чем ролевая модель доступа отличается от группового управления правами?

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

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

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

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

Сертификация ФСТЭК: что это, кому нужна и как пройти

Разбираем систему сертификации ФСТЭК: кто обязан применять сертифицированные СЗИ, как устроена процедура от заявки до выдачи сертификата, чем отличаются уровни доверия УД-6 — УД-4 и какие обязательства возникают после получения сертификата.

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

Пассворк: как разделить контуры ИБ и бизнеса

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

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

21 июля 2026 года Минцифры вынесло на общественное обсуждение проект Доктрины развития системы противодействия правонарушениям, совершаемым с использованием информационно-коммуникационных технологий (ИКТ).

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

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

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

Главное о Доктрине Минцифры за 5 минут

• 21 июля 2026 года Минцифры вынесло на общественное обсуждение проект Доктрины развития системы противодействия ИКТ-правонарушениям — рамочный документ до 2035 года.
• Документ продолжает серию решений 2024–2026 годов: Концепции противодействия (декабрь 2024), законов «Антифрод» и «Антифрод 2.0», запуска ГИС «Антифрод» в марте 2026 года.
• Реализация разбита на три этапа: 2027–2028 — создание нормативной базы, 2029–2030 — внедрение механизмов, 2031–2035 — их развитие и донастройка.
• Центральный элемент архитектуры — Платформа, единая среда для обмена обезличенными сигналами о мошенниках между банками, операторами связи, цифровыми платформами и государством.
• Доктрина закладывает три сценария развития: базовый (достройка текущих механизмов), целевой (координация через жизненный цикл правонарушения) и опережающий — с переходом на криптографический цифровой токен вместо централизованных баз персональных данных.
• Для бизнеса документ вводит конкретные обязанности: плановый антифрод-аудит, оценку фрод-потенциала информационных систем и отраслевые стандарты защиты данных — особенно для высокорисковых отраслей.
• Отдельное направление — платформа согласий на базе ЕСИА: единая точка выдачи, хранения и отзыва согласий на обработку персональных данных.
• Документ пока в статусе проекта — Минцифры прямо указывает, что меры могут измениться по итогам общественного обсуждения.

Что такое Доктрина Минцифры и зачем она понадобилась

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

Документ опирается на пять действующих правовых актов:

Появление Доктрины именно сейчас объясняется масштабом проблемы и тем, что точечные меры не закрывают проблему системно. Во втором разделе документа приводится статистика МВД:

«Несмотря на то, что по итогам 2025 года количество ИКТ-преступлений по отношению к 2024 году снизилось на 11,8 % (с 765,4 тыс. до 675,4 тыс.), обозначенная проблема остается актуальной, в том числе потому, что инструменты мошенников постоянно совершенствуются».

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

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

Как объяснил Российской газете заместитель Председателя Правительства Российской Федерации Дмитрий Григоренко:

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

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

Хронология: как государство выстраивало антифрод-систему

Доктрина является продолжением серии решений, принятых за последние два года:

Три этапа реализации Доктрины Минцифры

Доктрина разбита на три этапа, каждый со своей задачей — от создания правовой базы до отладки уже работающих механизмов:

• Этап I (2027–2028 годы). Организационно-подготовительные мероприятия: разработка и принятие нормативных правовых актов для реализации ключевых направлений Доктрины, апробация потенциальными участниками создаваемых технологий, утверждение методик расчёта целевых показателей и возможная корректировка сроков и масштаба отдельных мероприятий по итогам.
• Этап II (2029–2030 годы). Создание организационных и технологических основ для реализации задач Доктрины, поэтапное внедрение механизмов противодействия правонарушениям, совершаемым с использованием ИКТ.
• Этап III (2031–2035 годы). Развитие созданных механизмов и формирование предложений по их дальнейшему совершенствованию в рамках системы противодействия.

Доктрина продолжает курс, заложенный в Концепции государственной системы противодействия противоправным деяниям (распоряжение Правительства РФ № 4154-р), и в плане мероприятий по её реализации (распоряжение Правительства РФ № 2207-р).

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

Центральный элемент Доктрины: Платформа (ГИС)

С 1 марта 2026 года создана государственная информационная система противодействия правонарушениям с использованием ИКТ (в Доктрине указана, как «Платформа»). Согласно статье 1 Федерального закона № 41-ФЗ, она призвана обеспечить оперативное предоставление всем участникам взаимодействия (правоохранительным органам, уполномоченным органам исполнительной власти, Банку России, финансовым организациям, операторам связи и цифровым платформам) информации о попытках мошенничества для их блокировки и предотвращения.

«Платформа является единой оперативной информационно-аналитической интеграционной средой, при взаимодействии с которой локальные (ведомственные и корпоративные) и отраслевые инструменты противодействия мошенничеству будут синхронизированы» (раздел II Доктрины Минцифры).

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

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

«Задачи оперативного противодействия мошенничеству, совершаемому с использованием ИКТ, распределяются между участниками взаимодействия в рамках сценариев противодействия правонарушениям» (раздел II Доктрины Минцифры).

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

Основные термины Доктрины Минцифры

Доктрина вводит новую терминологию для описания антифрод-контура — от «антифрод-мер» и «цифрового следа» до «фрод-потенциала» и «механизма обратного отслеживания». Важнейшие из них:

Три термина стоит выделить отдельно:

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

Шесть системных вызовов, которые Доктрина Минцифры ставит в основу архитектуры

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

Непрерывный процесс развития

Нормативно-правовая и кадровая база должна постоянно донастраиваться — иначе выявление, раскрытие и расследование преступлений с использованием ИКТ отстаёт от развития самих мошеннических схем.

«Необходимость совершенствования нормативно-правового и кадрового обеспечения для эффективного и оперативного выявления, раскрытия и расследования преступлений, совершаемых с использованием ИКТ» (здесь и далее — раздел II Доктрины Минцифры).

Унификация

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

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

Фрагментация информационного пространства

Банки, операторы и платформы работают автономно, поэтому нужен переход «от автономной работы к согласованным действиям».

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

Временной разрыв реагирования

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

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

Централизация как риск

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

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

Избыточность персональных данных

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

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

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

Девять направлений реализации Доктрины Минцифры

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

1. Повышение эффективности правоохранительной и контрольной деятельности

Направление сосредоточено на инструментах и полномочиях правоохранительных органов для расследования ИКТ-преступлений.

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

2. Развитие кадрового потенциала и научное обеспечение противодействия

Направление закрывает дефицит квалифицированных специалистов для работы в антифрод-подразделениях.

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

3. Развитие государственно-частного взаимодействия

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

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

4. Технологическое развитие и инфраструктура

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

• Создать защищённую государственную систему верификации юридически значимых идентификаторов и унифицировать форматы передачи данных правоохранительным органам
• Регламентировать сбор, проверку и оценку электронных (цифровых) доказательств и легализовать сведения, полученные с использованием специализированных программно-технических средств
• Внедрить систему учёта цифрового следа устройств для криминалистической идентификации и развивать инструменты компьютерно-технической экспертизы
• Совершенствовать механизмы использования средств видео-конференц-связи для проведения отдельных следственных действий
• Совершенствовать идентификацию и аутентификацию (в том числе на основе биометрии): исключить подмену данных при регистрации, закрепить условия применения на законодательном уровне, наполнить единую базу биометрии ЕБС (Единой биометрической системы) силами государства, банков, операторов связи и цифровых платформ
• Внедрить ИИ (искусственный интеллект) для выявления уязвимостей, прогнозирования новых видов правонарушений и повышения эффективности Платформы
• Совершенствовать механизмы управления финансовыми инструментами для граждан (отказываться от услуг и расторгать договоры банковского счёта) и совершенствовать состав данных при оказании дистанционных услуг
• Установить отраслевые стандарты антифрод-мер и контрольные показатели уровня риска для высокорисковых отраслей, с защитой конфиденциальности данных
• Проработать внедрение оценки фрод-потенциала информационных систем с учетом обеспечения соответствующего режима конфиденциальности сведений
• Ввести обязательный плановый антифрод-аудит организаций и оценку фрод-потенциала информационных систем
• Создать стимулы (регуляторные и нерегуляторные) для бизнеса, инвестирующего в эффективные антифрод-системы

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

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

5. Профилактика и взаимодействие с гражданами

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

• Повышать правовую, финансовую и цифровую грамотность граждан, формировать культуру безопасной цифровой среды и закрепить профилактику как ориентир госполитики в сфере информационной безопасности
• Привлекать институты гражданского общества и профильные некоммерческие организации к профилактике ИКТ-правонарушений
• Повышать осведомлённость о схемах мошенничества и проводить адресные программы для уязвимых групп: несовершеннолетних, пожилых людей, госслужащих, ИТ-специалистов
• Совершенствовать взаимодействие банков и операторов связи с правоохранительными органами при информировании граждан о совершённых в их отношении правонарушениях
• Внедрить инструменты обучения с имитацией мошеннических атак для проверки знаний и вести профилактическую работу с населением на принципе неотвратимости ответственности
• Включить курсы цифровой гигиены, цифровой и финансовой грамотности в программы общего, среднего профессионального и высшего образования
• Разработать алгоритм непроцессуальных форм профилактики с участием органов власти, бизнеса, учебных заведений и СМИ, расширить социальную рекламу и создать общероссийскую площадку по цифровой грамотности
• Организовать регулярный сбор и анализ обратной связи от населения для корректировки мер противодействия

6. Финансовое взаимодействие и возмещение ущерба

Направление регулирует распределение финансовой ответственности между банками, отправителями и получателями при мошеннических переводах

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

7. Обеспечение достоверности и защиты данных

Направление касается точности и защищённости данных в государственных информационных системах (ГИС) и Единой системе идентификации и аутентификации (ЕСИА).

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

8. Защита персональных данных

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

• Создать на базе ЕСИА платформу согласий — единый механизм выдачи, хранения и отзыва согласий на обработку персональных данных, определённых статьёй 9 Федерального закона № 152-ФЗ «О персональных данных»
• Сформировать правовые условия для сокращения случаев, когда операторы обрабатывают персональные данные на основании согласия
• Внедрить механизмы идентификации граждан организациями без передачи им персональных данных (в случаях, которые определит Правительство Российской Федерации)

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

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

9. Международное взаимодействие

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

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

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

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

1. Базовый сценарий

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

То есть: достраиваем то, что уже работает.

2. Целевой сценарий

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

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

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

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

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

3. Опережающий сценарий: цифровой токен

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

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

Доктрина фиксирует пять обязательных свойств ЦТ:

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

Отдельно Доктрина затрагивает биометрию — она может стать «ядром безопасной и бесшовной идентификации» в модели ЦТ, но использование остаётся добровольным. Для защиты от дипфейков закладывается переход к многофакторной защите: контроль «живости» лица (лайвнесс), выявление атак на биометрические предъявления и поведенческий анализ пользователя.

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

Что мешает реализации: пробелы нормативной базы

Раздел VI Доктрины прямо перечисляет семь неурегулированных вопросов действующего законодательства:

1. Нет механизма «обратного взыскания». Отсутствие правового механизма для реализации сервисов «обратного взыскания» похищенных средств
2. Нет критериев эффективности. Не формализовано, по каким показателям оценивать работу субъектов цифровой среды в борьбе с ИКТ-правонарушениями.
3. Нет адресной ответственности за данные. Участники информационного обмена не несут прямой ответственности за полноту, достоверность и скорость передачи данных.
4. Не проработана подготовка кадров. Комплексного регулирования по обучению профильных специалистов и системной профилактике правонарушений пока не существует.
5. Слабая база для этапа расследования — включает две проблемы сразу:
   • неэффективные механизмы борьбы с администрированием теневых цифровых ресурсов в анонимных сетях;
   • недоработанное регулирование процедур с цифровой валютой — изъятия, конфискации, обращения в доход государства, а также отсутствие однозначных оснований для квалификации операций с цифровой валютой как легализации (отмывания) преступных доходов.
6. Нет основы для государственно-частного взаимодействия. Не закреплено, как привлекать экспертов ИТ-компаний, ИБ-отрасли и банков к обучающим, экспертным и методическим мероприятиям.
7. Не определён формат правового просвещения. Особенности деятельности по правовому информированию населения в части противодействия ИКТ-правонарушениям не закреплены.

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

Кто и как реализует Доктрину Минцифры

За реализацию Доктрины отвечает Минцифры. Оно координирует работу МВД, ФСБ, Следственного комитета, Роскомнадзора, Генпрокуратуры, Банка России, регионов, а также банков, операторов связи и цифровых платформ.

Как устроена система на практике:

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

Что это значит для бизнеса

Доктрина — пока не закон, а вектор развития до 2035 года, и текст может измениться по итогам общественного обсуждения. Но три её элемента стоит воспринимать всерьёз уже на этом этапе: обязательный антифрод-аудит, оценку фрод-потенциала информационных систем и платформу согласий на базе ЕСИА. Первый этап реализации, 2027–2028 годы, — время, когда эти пункты могут получить конкретную юридическую форму.

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

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

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

Часто задаваемые вопросы о Доктрине Минцифры по антифроду

Когда Доктрина Минцифры вступит в силу?

Доктрина — проект, опубликованный 21 июля 2026 года для общественного обсуждения. После утверждения указом президента она станет рамочным документом на период до 2035 года. Первый этап реализации — нормативная база и апробация технологий — запланирован на 2027–2028 годы.

Что такое антифрод-система?

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

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

Платформа — государственная информационная система, запущенная 1 марта 2026 года на основании Федерального закона № 41-ФЗ. Она синхронизирует антифрод-системы банков, операторов связи, цифровых платформ и госорганов через обмен обезличенными сигналами об атрибутах мошенников, а не персональными данными граждан.

Что такое цифровой токен и заменит ли он паспорт?

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

Обязателен ли антифрод-аудит для всех компаний?

Доктрина Минцифры предполагает плановый антифрод-аудит и отраслевые стандарты в первую очередь для высокорисковых отраслей — финансов, связи, крупных цифровых платформ. Конкретный перечень отраслей и порядок аудита пока не закреплены нормативно и должны появиться на первом этапе Доктрины в 2027–2028 годах.

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

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

Придётся ли компаниям менять процессы работы с согласиями на обработку персональных данных?

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

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

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

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

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

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

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

7 способов взлома соцсетей: как воруют аккаунты в 2026 году

Число взломов аккаунтов в соцсетях выросло на 123% за год. Разбираем 7 методов, которые используют злоумышленники прямо сейчас, — и что конкретно закрывает каждый из векторов.

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

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

Проблема не в дисциплине или лени. Инструктажи по информационной безопасности (ИБ) объясняют, что делать, но не снимают конфликт между удобством и безопасностью, который сотрудник переживает десятки раз за рабочий день. В 2026 году к этому конфликту добавился новый источник: нейросети и теневые ИИ (Shadow AI), которыми сотрудники пользуются в обход правил безопасности.

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

Несоблюдение основ ИБ становится дороже с каждым годом. Регулирование ужесточилось: приказ ФСТЭК России № 117 и оборотные штрафы за утечки персональных данных подняли цену ошибки — и для компании, и для конкретного человека. Атаки изменились и правило «не открывай подозрительные письма» стало недостаточным. Разберём, какие знания и привычки сотрудникам нужны в 2026 году, чтобы не стать точкой входа для инцидента.

Главное за 30 секунд

• Информационная безопасность сотрудника — это не документ с политикой, а повседневные действия: уникальный пароль для каждого сервиса, двухфакторная аутентификация, проверка отправителя письма, блокировка экрана при отходе от рабочего места.
• Три угрозы определяют ландшафт атак 2026 года: фишинг-конвейеры (готовые наборы для массовых рассылок), дипфейки и компрометация учётных данных через переиспользование паролей.
• Теневой ИИ (Shadow AI) — использование сотрудниками нейросетей и чат-ботов без согласования с ИТ-отделом стало новым каналом утечки: данные, вставленные в промпт, покидают контур компании и не отслеживаются DLP и SIEM-системами.
• Регулирование ужесточилось: приказ ФСТЭК №117 обязывает операторов обучать персонал основам кибербезопасности и правилам работы с информацией, а за утечки персональных данных введены оборотные штрафы.
• Разовый годовой инструктаж не работает: знания без повторения забываются быстрее, чем компания успевает столкнуться с реальной атакой. Рабочий формат — короткие тренировки раз в месяц и регулярные напоминания об угрозах.
• Наказание даёт обратный эффект — сотрудники начинают скрывать ошибки. Цель проверки — закрепить привычку сообщать о подозрениях, а не найти виноватого.
• 14 правил цифровой гигиены — менеджер паролей, двухфакторная аутентификация, проверка отправителя, блокировка экрана и запрет на загрузку рабочих данных в публичные нейросети — закрывают большинство векторов атак.

Что такое информационная безопасность?

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

Почему сотрудники нарушают правила безопасности

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

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

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

Три главные угрозы 2026 года, которые касаются каждого сотрудника

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

Фишинг-конвейеры (PhaaS): почему «не переходи по ссылкам» уже не работает

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

Фишинговые письма грамотно имитируют внутреннюю переписку, используют реальные имена коллег и контекст текущих проектов.

Россия при этом входит в число самых атакуемых стран в мире: в период с июля 2024-го по сентябрь 2025 года на Россию пришлось около 14-16% всех глобальных атак, по данным отчёта Positive Technologies CODE RED 2026.

Социальная инженерия 2.0: дипфейки и таргетированные атаки

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

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

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

Компрометация учётных данных: пароли по-прежнему главный ключ

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

Ущерб от действий злоумышленников в ИТ-сфере за 2025–2026 годы превысил 600 млрд рублей, по данным F6. Компрометация учётных данных редко становится финальной целью атаки — чаще это первый шаг для горизонтального перемещения по инфраструктуре компании.

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

Shadow AI и Shadow IT: угроза, которую создают сами сотрудники

Теневые ИТ (Shadow IT) — это использование сотрудниками оборудования, программ и сервисов без согласования с ИТ-отделом и без учёта в корпоративной инфраструктуре. Теневой ИИ (Shadow AI) — его новая, более быстрорастущая разновидность: применение нейросетей, чат-ботов и внешних ИИ-сервисов для рабочих задач без одобрения и контроля ИТ- и ИБ-служб.

Сравнение Shadow IT и Shadow AI

80% сотрудников используют несанкционированные ИИ-инструменты в работе (Kiberboloid, 2026). Проблема не ограничивается рядовыми сотрудниками: 68% руководителей по безопасности, включая директоров по информационной безопасности, признаются, что сами используют несанкционированный ИИ в ежедневной работе. В России тенденция мягче: 26% сотрудников регулярно используют ИИ-инструменты в работе, 35% — периодически, по данным опроса hh.ru.

Эксперты ГК «Солар» называют Shadow AI «вторым Shadow IT»: в нейросеть сотрудник загружает данные из корпоративных систем — от общедоступной информации о компании до чертежей с расчётами и закрытых финансовых показателей. Встречаются случаи, когда сотрудники государственных структур загружают в публичные чат-боты чувствительные оперативные данные.

Почему это опасно:

• Потеря контроля над данными. Информация, загруженная в публичную нейросеть, обрабатывается на внешних, чаще иностранных серверах — компания не знает, где и как долго она там хранится.
• Риск дообучения и целевого поиска. Загруженные данные потенциально используются для дообучения модели, а в отдельных случаях становятся целью намеренного поиска злоумышленниками.
• Слепая зона для DLP и SIEM. Shadow AI не отслеживают системы предотвращения утечек данных (DLP) и управления событиями безопасности (SIEM) — они изначально не рассчитаны на мониторинг трафика к ИИ-сервисам.
• Потенциальное нарушение 152-ФЗ. Персональные данные клиентов или сотрудников в промпте потенциально создают высокий риск нарушения статьи 19 Федерального закона № 152-ФЗ «О персональных данных», даже без факта внешней утечки.
• Отсутствие аудиторского следа. Использование личного аккаунта в чат-боте не логируется корпоративными системами — при расследовании инцидента невозможно установить, какие данные и когда туда попали.
• Незащищённая интеллектуальная собственность. Фрагменты собственного кода или разработок компании, вставленные в промпт, потенциально становятся частью обучающего набора модели с неясным статусом прав.
  

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

Что изменилось в регулировании: ФСТЭК, штрафы и ответственность

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

С 1 марта 2026 года вступают в силу новые требования приказа ФСТЭК России №117 от 11.04.2025 к защите информации в государственных информационных системах. Документ требует, чтобы не менее 30% сотрудников подразделения ИБ имели профильное образование. Обязательное обучение персонала касается государственных органов, органов местного самоуправления, государственных унитарных предприятий и бюджетных учреждений.

В мае 2025 года в статью 13.11 КоАП РФ добавлены новые поправки. Размер штрафа для компании зависит от объёма утечки:

• От 3 до 5 млн рублей за утечку данных 1000–10 000 человек
• От 5 до 10 млн рублей при утечке данных более 10 000 человек
• От 10 до 15 млн рублей при утечке более 100 000 записей
• От 15 до 20 млн рублей за утечку биометрических данных

За повторную утечку персональных данных любой категории компания платит оборотный штраф в размере 1–3% годовой выручки, но не менее 20 млн рублей (для отдельных категорий данных — не менее 25 млн рублей). За тот же год Роскомнадзор зафиксировал 103 утечки данных, в результате которых пострадали около 50 млн записей о россиянах — для сравнения, в 2024 году было 135 утечек и 710 млн записей, по данным ТАСС.

Ответственность не ограничивается компанией. Административная ответственность по статье 13.11 КоАП РФ применяется независимо от умысла — по факту утечки или неправомерной обработки данных отвечает организация. Уголовная ответственность по статье 137 УК РФ «Нарушение неприкосновенности частной жизни» наступает только при доказанном прямом или косвенном умысле причинить вред человеку.

Сотрудника, который разгласил персональные данные коллег или клиентов, работодатель может уволить по подпункту «в» пункта 6 части 1 статьи 81 Трудового кодекса РФ:

«Разглашения охраняемой законом тайны (государственной, коммерческой, служебной и иной), ставшей известной работнику в связи с исполнением им трудовых обязанностей, в том числе разглашения персональных данных другого работника», — Статья 81 ТК РФ

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

14 правил цифровой гигиены сотрудника

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

1. Используйте менеджер паролей, а не память или блокнот

Только 4% сотрудников применяют менеджеры паролей, при этом 48% держат пароли в памяти, по данным Контур.Эгида. Если сотрудник использует один пароль для разных сервисов, утечка из одного из них открывает злоумышленникам доступ и к другим рабочим системам с тем же паролем.

Как делать правильно:

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

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

2. Включите двухфакторную аутентификацию везде, где это доступно

Двухфакторная аутентификация (2FA/MFA) делает бесполезным украденный пароль без физического доступа к устройству сотрудника. По данным ФСТЭК России, 69% проверенных организаций не используют двухфакторную аутентификацию для привилегированных пользователей — именно там, где цена компрометации выше всего.

Не все методы 2FA одинаково надёжны. SMS-коды перехватывают через дублирование SIM-карты и социальную инженерию у оператора связи, а приложения-аутентификаторы уязвимы к фишингу в реальном времени.

Как делать правильно:

• Включите двухфакторную аутентификацию на рабочей почте, в CRM (1С, Битрикс24), таск-трекерах и любых системах с доступом к конфиденциальным данным.
• В качестве второго фактора минимально должны быть приложения-аутентификаторы, а не SMS-коды.
• Там, где сервис поддерживает ключи доступа (passkeys) — переходите на них. Ключ доступа привязан к конкретному домену и не работает на поддельном сайте, поэтому украсть его через фишинговую страницу невозможно.
• Для самых критичных учётных записей используйте аппаратные ключи безопасности. Это самый защищённый вариант второго фактора: закрытый ключ физически не покидает устройство и не может быть перехвачен удалённо, даже если компьютер сотрудника заражён.

3. Проверяйте адрес отправителя и подлинность собеседника в мессенджерах

Фишинговые-конвейеры (Phishing-as-a-Service) копируют стиль и логотипы компаний, но домен отправителя почти всегда выдаёт подделку при внимательной проверке. Фишинг остаётся основным способом первичной компрометации корпоративных сетей.

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

Как делать правильно:

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

4. Разделяйте личное и рабочее в браузере

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

Как делать правильно:

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

5. Не подключайтесь к рабочим сервисам через публичный Wi-Fi

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

Как делать правильно:

• При работе вне офиса раздавайте интернет с мобильного телефона вместо подключения к открытому Wi-Fi.
• Если подключение к публичной сети необходимо, используйте только корпоративный VPN.

6. Блокируйте экран при отходе от рабочего места

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

Как делать правильно:

• Блокируйте экран комбинацией Win + L на Windows или Cmd + Ctrl + Q на macOS каждый раз, когда встаёте из-за стола (даже на пару минут).
• Если работаете с ноутбуком вне офиса блокируйте экран при любом отвлечении, не только при полном уходе с места. В общественных местах посторонний человек может просто взглянуть на открытый экран рядом и увидеть переписку, документы или пароли, которые вы вводите.
• Настройте автоматическую блокировку экрана после короткого периода неактивности (1–2 минуты) как страховку на случай, если забыли заблокировать вручную.

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

Личные каналы связи не подпадают под корпоративный контроль систем предотвращения утечек данных (DLP, Data Loss Prevention) и мониторинга событий безопасности (SIEM, Security Information and Event Management). По данным InfoWatch, в России сотрудники с доступом к данным компании втрое чаще, чем в мире, используют мессенджеры для несанкционированной передачи данных — 13,2% инцидентов против 5% в мире.

Как делать правильно:

• Ведите рабочую переписку только в корпоративных каналах, которые контролирует ИТ-отдел.
• Не пересылайте рабочие документы и учётные данные в личные чаты — даже «на минутку» или «для себя».

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

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

Как делать правильно:

• Делитесь файлами адресно — указывайте конкретные адреса коллег, а не открывайте общий доступ.
• Ограничивайте права доступа (только просмотр, без скачивания и редактирования) и закрывайте доступ после завершения совместной работы.
• Проведите ревизию прямо сейчас. Проверьте все свои облачные диски — рабочие и личные, если через них передавались корпоративные файлы. Найдите документы с настройкой «доступно по ссылке всем». Замените такой доступ на адресный или закройте его полностью.

9. Не подключайте к рабочему компьютеру неизвестные USB-устройства

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

Как делать правильно:

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

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

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

Как делать правильно:

• Устанавливайте обновления операционной системы, браузера и рабочих приложений сразу после уведомления, особенно если оно помечено как критическое или касается безопасности.
• Не отключайте автоматические обновления на рабочем устройстве самостоятельно. Если обновление мешает работе — сообщите в ИТ-отдел, а не блокируйте процесс через настройки.
• Если в компании работает централизованное управление обновлениями (patch management), не устанавливайте несогласованные версии ПО и не откладывайте присланные обновления по собственной инициативе.

11. Контролируйте демонстрацию экрана на созвонах

Демонстрация всего рабочего стола вместо отдельного окна раскрывает случайным участникам звонка открытые чаты, документы и вкладки с внутренними системами.

Как делать правильно:

• Делитесь экраном только конкретного приложения или вкладки, а не всем рабочим столом.
• Закрывайте личные вкладки и мессенджеры перед началом созвона.

12. Не храните рабочие файлы на личных устройствах

Личные ноутбуки и телефоны обычно защищены хуже корпоративных и не контролируются ИТ-отделом — перенос рабочих документов туда выводит данные из контура безопасности компании.

Как делать правильно:

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

13. Сообщайте о подозрительной активности, даже если это ложная тревога

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

Как делать правильно:

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

14. Не загружайте рабочие данные в публичные нейросети

Несанкционированное использование ИИ-сервисов с рабочими данными (Shadow AI) — быстрорастущий канал утечки. Объём конфиденциальной информации российских компаний, которую сотрудники загружали в общедоступные нейросети вроде ChatGPT и Google Gemini, вырос за 2025 год в 30 раз.

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

Как делать правильно:

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

Правило можно расширить и до общей темы теневого ИТ (Shadow IT): тот же принцип касается любых неавторизованных сервисов, которые сотрудник подключает сам, без ведома ИТ-отдела. Каждый такой сервис — точка, которую не видит ни DLP-система, ни SIEM-мониторинг, ни администратор.

Сводная таблица основ информационной безопасности сотрудника

Как компании выстроить обучение, которое будет работать

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

Почему разовый инструктаж не работает

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

За 2025 год в России зафиксировано 739 инцидентов утечки данных, в результате которых скомпрометированы 1,34 млрд записей персональных данных — подсчитали в InfoWatch. Почти половина (47%) киберинцидентов в 2025 году привела к нарушению основной деятельности компаний, по данным Positive Technologies. Ущерб от одного часа простоя из-за действий хакеров варьируется от 9,6 млн рублей в ритейле до 21,7 млн рублей в ИТ и телекоммуникациях, по оценке BI.ZONE.

Техническая брешь, которую не закроет тренинг

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

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

Опоры осведомлённости об инофрмационной безопасности

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

1. Короткие тренировки вместо годовых инструктажей. Занятие на 5–10 минут раз в месяц запоминается лучше, чем восьмичасовой курс раз в год. Формат может быть простым: короткое видео с разбором реального письма, которое прислали мошенники сотруднику компании на прошлой неделе, тест из пары вопросов с объяснением ответа. Такие занятия не отрывают от работы и запоминаются за счёт повторения, а не объёма материала.
2. Регулярные напоминания о новых угрозах и базовых правилах. Раз в две недели — короткое сообщение в рабочем чате: новая схема обмана, о которой стоит знать, или напоминание простого правила («не открывайте вложения от неизвестных отправителей», «проверяйте номер счёта перед переводом»). Такие сообщения занимают минуту на прочтение, но держат тему в поле внимания сотрудников между тренировками.
3. Проверочные фишинговые письма — без наказания за ошибку. Компания периодически отправляет сотрудникам безопасные тестовые письма, имитирующие реальную атаку, чтобы проверить, кто на них откликнется. Сотрудник, который кликнул на такое письмо, должен увидеть разбор (что выдало подделку), а не выговор от руководителя.

4. Отдельная подготовка для сотрудников с высоким риском. Бухгалтерия, ИТ-специалисты и руководители чаще становятся целью направленных атак — в том числе звонков с поддельным голосом руководителя, созданным при помощи ИИ. Для этой группы полезны отдельные разборы таких сценариев: как распознать подделку и что делать, если звонок вызывает подозрение.
5. Оценка по фактам, а не по прохождению курса. Показатель «100% сотрудников прошли обучение» ничего не говорит о защищённости. Показатель «доля кликов на проверочные письма снизилась за квартал» говорит намного больше.

Что делать, если в компании нет ИБ-отдела

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

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

Заключение

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

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

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

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

Что такое информационная безопасность?

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

Зачем обучать сотрудников информационной безопасности?

Сотрудник — последняя линия обороны компании: 95,6% утечек данных в России происходят по вине персонала, по данным InfoWatch (2025). Обучение снижает число случайных ошибок (переход по фишинговой ссылке, ввод пароля на поддельном сайте), которые технические средства защиты не всегда способны предотвратить без соответствующей привычки у самого сотрудника.

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

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

Как часто нужно проводить обучение сотрудников информационной безопасности?

Оптимальный формат — короткие занятия по 10–20 минут раз в месяц вместо одного объёмного курса в год, дополненные регулярными напоминаниями о новых угрозах раз в одну-две недели. Регулярность закрепляет привычку лучше, чем объём материала: знания без повторения забываются быстрее, чем компания успевает столкнуться с реальной атакой.

Можно ли использовать один пароль для всех рабочих сервисов?

Нет. Один пароль для нескольких сервисов означает, что взлом самого незначительного из них открывает доступ ко всем остальным через переиспользование учётных данных. По данным Контур.Эгида (2025), так поступают 30% сотрудников — это одна из главных причин массовых компрометаций.

Что делать, если я перешёл по подозрительной ссылке?

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

Кто отвечает за информационную безопасность — ИТ-отдел или каждый сотрудник?

Формально ответственность закреплена за ИТ-отделом и службой безопасности: они настраивают системы защиты и контролируют их работу. Фактически безопасность зависит от каждого сотрудника, потому что 95,6% утечек в России происходят из-за действий персонала — умышленных или случайных (InfoWatch, 2025). Технические средства защиты не работают без базовых привычек пользователей.

Что такое брутфорс (Brute Force): виды, угрозы и защита

В первом квартале 2025 года число брутфорс-атак на российские организации выросло в 2,7 раза. 48% паролей из реальных утечек взламываются за минуту. Разбираем 8 техник перебора, объясняем, чем ИИ изменил атаки, и даём конкретные меры защиты: от парольной политики до управления учётными записями.

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

7 способов взлома соцсетей: как воруют аккаунты в 2026 году

Число взломов аккаунтов в соцсетях выросло на 123% за год. Разбираем 7 методов, которые используют злоумышленники прямо сейчас, — и что конкретно закрывает каждый из векторов.

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

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

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

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

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

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

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

Главное

• Сертификация ФСТЭК обязательна для защищаемых систем. СЗИ без сертификата нельзя легально применять в государственных информационных системах, информационных системах персональных данных и на значимых объектах КИИ.
• Сертифицируется конкретная версия продукта. Изменение кода или конфигурации требует повторного прохождения испытаний или инспекционного контроля.
• Уровень доверия определяет, в каких системах можно применять СЗИ. Шкала — от УД-6 (ГИС 3 класса, КИИ 3 категории) до УД-4 (ГИС 1 класса, КИИ 1 категории). УД-3 и выше — для систем с гостайной.
• Испытания проводит аккредитованная лаборатория, сертификат выдаёт ФСТЭК. Заявитель взаимодействует с лабораторией и органом по сертификации — ФСТЭК принимает финальное решение на основании экспертного заключения.
• После получения сертификата начинается инспекционный контроль. Ежегодная процедура подтверждает, что продукт соответствует заявленным характеристикам. При нарушениях сертификат может быть приостановлен или аннулирован.
• Сертификат с истёкшим сроком не означает запрет на эксплуатацию. Если производитель поддерживает продукт и запись в реестре ФСТЭК актуальна, продукт можно использовать дальше.

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

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

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

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

Что входит в полномочия ФСТЭК в части сертификации

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

Участники системы сертификации ФСТЭК России

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

Порядок сертификации средств защиты информации

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

Зачем нужна сертификация ФСТЭК

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

Кому нужна сертификация ФСТЭК

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

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

Что подлежит сертификации ФСТЭК

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

Согласно Приказу ФСТЭК России № 55 от 03.04.2018, сертификации подлежат три категории продуктов:

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

Что не сертифицируется по линии ФСТЭК:

1. Средства криптографической защиты информации (СКЗИ) — их сертифицирует ФСБ России по отдельной системе.
2. СЗИ иностранного производства, в отношении которых установлены ограничения или запреты на использование в РФ, — прямой запрет закреплён в Приказе № 55 (в ред. Приказа ФСТЭК № 121 от 05.08.2021).
3. Общесистемное ПО без функций защиты, бизнес-приложения (ERP, CRM), сетевое оборудование без встроенных функций защиты.

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

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

Практические особенности сертификации ФСТЭК

Сертификация — постоянный процесс управления соответствием. Несколько аспектов, которые важно учитывать на практике.

• Сертифицированная версия отличается от коммерческой. Продукт эксплуатируется в зафиксированной конфигурации, которая прошла испытания. Из-за этого возникают задержки обновлений: пока новая версия проходит испытания (в среднем 5–12 месяцев), сертифицированная остаётся на предыдущем релизе. Часть функциональности может быть ограничена.
• СЗИ с истёкшим сертификатом не нужно немедленно менять. Если производитель продолжает техническую поддержку продукта и запись о сертификате остаётся в реестре ФСТЭК — продукт можно эксплуатировать дальше. Статус поддержки отображается в реестре отдельной графой, его можно проверить публично.
• Инспекционный контроль — ежегодная обязанность. После получения сертификата производитель проходит плановый инспекционный контроль раз в год. Внеплановый контроль возможен при выявлении нарушений или существенных изменениях в продукте. По результатам контроля сертификат может быть приостановлен или аннулирован.
• В одной организации могут сосуществовать разные требования. Если компания эксплуатирует несколько информационных систем с разными категориями данных, одна система может требовать сертифицированных СЗИ, другая — нет. Это допустимо, но системы должны быть чётко разделены: их пересечение исключено.
• Требования ФСТЭК регулярно обновляются. Модель угроз меняется, вслед за ней обновляется и реестр сертифицированных СЗИ. Продукт, соответствующий требованиям сегодня, может потребовать замены при следующем обновлении нормативной базы. Переход на новые СЗИ и повторная аттестация выполняются поэтапно, чтобы не создавать разрывов в защите действующих систем.

Правовая основа системы сертификации СЗИ

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

Уровень 1: Федеральные законы (рамочные требования)

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

Вывод с этого уровня: федеральные законы говорят «надо защищать» и «надо подтверждать соответствие СЗИ», но не говорят «только сертификат ФСТЭК». Это решается ниже.

Уровень 2: Постановления Правительства РФ (конкретизация)

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

Уровень 3: Приказы ФСТЭК (главный практический уровень)

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

Вывод: приказы №117, №21, №31 и №239 создают спрос на сертификат. Приказ №55 описывает, как этот сертификат получить.

Уровень 4: Методические документы ФСТЭК (разъяснения)

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

Что такое уровень доверия ФСТЭК

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

Шкала включает 6 уровней — от базового (УД-6) до максимального (УД-1). Уровни доверия введены Приказом ФСТЭК России № 76 от 02.06.2020, который с 1 января 2021 года заменил ранее действовавший Приказ № 131.

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

Минимально допустимый уровень доверия для каждого типа систем задаётся отраслевыми приказами ФСТЭК: № 17 — для ГИС, № 21 — для ИСПДн, № 239 — для значимых объектов КИИ (критической информационной инфраструктуры).

6 уровней доверия ФСТЭК

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

Сертификация как часть архитектуры безопасности

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

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

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

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

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

Часто задаваемые вопросы о сертификации ФСТЭК

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

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

Сколько действует сертификат ФСТЭК?

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

Чем сертификация ФСТЭК отличается от лицензии ФСТЭК?

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

Можно ли использовать несертифицированное СЗИ в госорганизации?

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

Как проверить, действителен ли сертификат ФСТЭК?

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

Что происходит с сертификатом при обновлении продукта?

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

Нужна ли повторная сертификация при смене инфраструктуры?

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

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

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

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

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

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

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

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

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

С 23 по 26 июня в Санкт-Петербурге, на базе Технической академии Росатома, прошла ежегодная конференция РОСАТОМ / Информационная безопасность 2026. Площадка собрала более 500 участников из 130 компаний, представлено 120 докладов.

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

Новый ландшафт ИБ: от бумажной безопасности к практической

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

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

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

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

Доклад технического директора Пассворка был посвящён проблеме, которую в отрасли редко обсуждают открыто — «слепым зонам» в управлении корпоративными секретами.

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

Это приводит к серьёзным рискам:

• Неконтролируемый онбординг и отзыв доступов. При увольнении сотрудника сложно гарантировать, что все его доступы к критическим ресурсам отозваны.
• Отсутствие аудита. Без единого журнала и истории изменений нельзя оперативно выяснить, кто и когда получал доступ к конкретному ресурсу.
• Затянутое расследование инцидентов. Восстановление хронологии событий по разрозненным источникам занимает дни вместо минут.

Для субъектов КИИ это прямой регуляторный риск и потенциальный вектор атаки.

Как устроено системное управление секретами

Главная идея нашего доклада — перейти от пассивного хранения паролей к управлению доступами как непрерывному процессу. Доступ привязывается к роли сотрудника, а не выдаётся вручную «навсегда».

Архитектура сейфов как граница доступа

Сейф — изолированное зашифрованное пространство с чёткой ролевой моделью. Доступ определяют группа и роль пользователя. Администратор всегда видит, кто имеет доступ к сейфу, и отзывает права в один клик.

Роли и группы

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

Политики сейфов

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

Готовность к промышленной эксплуатации: технические и регуляторные аргументы

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

Главный вывод конференции

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

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

Интерактивная схема API: сравнение версий и готовые примеры

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

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

Пороговое восстановление доступа в Пассворке: схема Шамира

Администратор сейфа уволился без передачи дел или потерял мастер-пароль — и ключ шифрования исчез вместе с ним. Разбираем, как пороговое восстановление по схеме Шамира возвращает доступ силами нескольких доверенных сотрудников, без раскрытия чужих мастер-паролей и без нарушения zero-knowledge.

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

Менеджер паролей для организаций госсектора: выбор и внедрение

Менеджер паролей для госсектора должен соответствовать 152-ФЗ, 187-ФЗ и требованиям ФСТЭК: сертификация, реестр отечественного ПО, локализация данных. Разбираем 8 групп критериев выбора, план внедрения в 5 фаз и то, как этим требованиям отвечает Пассворк.

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

22 июня 2026 года Президент США Дональд Трамп подписал указ «О защите страны от продвинутых криптографических атак» — первый в американской истории документ с жёсткими, юридически обязывающими дедлайнами перехода на постквантовую криптографию.

Первый абзац указа формулирует угрозу без дипломатических оговорок:

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

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

Подобная стратегия называется Собирай сейчас, расшифруй потом (Harvest Now, Decrypt Later, HNDL), и именно она стала главным обоснованием для указа.

Российские регуляторы — ФСБ, Минцифры, ФСТЭК, Росстандарт и ТК 26 движутся в том же направлении, хотя и по собственной траектории. Россия не адаптирует зарубежные алгоритмы, а разрабатывает собственные: «Шиповник», «Гиперикум» и «Кодиеум» проходят открытый криптоанализ в рамках ТК 26. Параллельно страна уже эксплуатирует одну из крупнейших в мире квантовых коммуникационных сетей (магистральную сеть РЖД) и запускает промышленные пилоты QKD в финансовом секторе, телекоммуникациях и ТЭК.

Главное

• Атака идёт уже сейчас. Стратегия HNDL не требует квантового компьютера: злоумышленники перехватывают и архивируют зашифрованный трафик сегодня, чтобы расшифровать его после Q-Day. Данные с долгим сроком конфиденциальности под угрозой прямо сейчас.
• Q-Day ближе, чем казалось. Ещё в 2023 году эксперты называли горизонт 2035–2040 годов. Исследование Google в марте 2026 года сократило оценку необходимых ресурсов в 20 раз. Google, IBM и Cloudflare сошлись на 2029 годе как внутреннем дедлайне перехода.
• Под угрозой — асимметричная криптография. Алгоритм Шора взломает RSA, ECDSA и ГОСТ Р 34.10-2012 за минуты. Симметричные шифры (AES-256, Кузнечик, Магма) сохраняют достаточный уровень защиты: алгоритм Гровера лишь снижает стойкость вдвое.
• Регуляторы установили жёсткие дедлайны. Указ Трампа от 22 июня 2026 года обязывает федеральные системы США и их подрядчиков перейти на стандарты NIST к 2030–2031 годам. ЕС, Великобритания и Германия установили аналогичные сроки. Через требования к подрядчикам дедлайны распространяются на глобальный ИТ-рынок.
• Россия строит суверенный постквантовый стек. ТК 26 разрабатывает три алгоритма-кандидата — «Шиповник», «Гиперикум» и «Кодиеум». Принятие национальных стандартов прогнозируется в ближайшие годы. Россия входит в тройку стран с действующими квантовыми вычислителями на всех четырёх основных платформах.
• Практика опережает стандарты. Пилоты QKD уже запущены в финансовом секторе (ВТБ, Газпромбанк, НСПК), телекоммуникациях (Билайн) и ТЭК (НОВАТЭК). Магистральная сеть РЖД длиной 7 858 км служит базовой инфраструктурой для новых корпоративных подключений.
• Первый шаг — аудит, не замена алгоритмов. Постквантовый переход начинается с аудита: инвентаризации всех криптографических алгоритмов, ключей и сертификатов в инфраструктуре. Без этого невозможно оценить масштаб задачи и расставить приоритеты миграции.

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

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

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

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

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

Что такое Q-Day?

Квантовый день (Q-Day, День Q) — условное название момента, когда криптоаналитически релевантный квантовый компьютер (CRQC) достигнет достаточной мощности для взлома современных алгоритмов шифрования. Точная дата неизвестна, но атаки, рассчитанные на этот момент, идут уже сейчас.

Математическую основу угрозы заложил Питер Шор в 1994 году. Его алгоритм показал: задачи факторизации больших чисел и дискретного логарифмирования, на которых держатся все широко используемые асимметричные алгоритмы (RSA, ECC, Диффи-Хеллман), принципиально разрешимы на квантовом компьютере за практически приемлемое время.

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

Это означает, что под угрозой оказывается вся инфраструктура, которая опирается на асимметричную криптографию: TLS, SSH, PKI, электронные подписи, блокчейн.

Для симметричных алгоритмов (AES-256, Кузнечик) угроза иная и менее критичная. Алгоритм Гровера снижает эффективную длину ключа вдвое: AES-256 и ГОСТ Р 34.12-2015 («Кузнечик») становятся эквивалентом 128-битной защиты. Этот уровень стойкости ФСБ России и Национальный институт стандартов и технологий США (NIST) признают достаточным на обозримую перспективу.

Насколько близок Q-Day?

Ещё в 2023 году большинство экспертов называли Q-Day горизонтом 2035–2040 годов. Сейчас прогнозы сжались. Большинство мировых и российских аналитиков ориентируются на 2028–2030 годы. При этом они подчёркивают: ключевой риск начинается раньше квантового дня — именно через HNDL-атаки.

В марте 2026 года Google опубликовал исследование, которое резко сдвинуло оценки. Команда Райана Баббуша и Хартмута Невена показала: для взлома 256-битной эллиптической криптографии (основы блокчейнов, цифровых подписей и большинства протоколов аутентификации) достаточно менее 500 000 физических кубитов. Это в 20 раз меньше предыдущих оценок. Алгоритм Шора на такой машине решит задачу за считанные минуты.

Ещё раньше, 25 марта 2026 года, Google объявил внутренний дедлайн перехода на постквантовую криптографию к 2029 году и призвал другие команды последовать примеру. Android 17 уже интегрирует постквантовые цифровые подписи на основе ML-DSA, а Chrome поддерживает PQC-шифрование.

IBM и Cloudflare называют тот же горизонт. В июне 2025 года IBM анонсировала план создания первого крупномасштабного отказоустойчивого квантового компьютера к 2029 году. В апреле 2026 года Cloudflare сдвинул собственный целевой срок полной постквантовой защиты на тот же год — после исследовательских прорывов Google и Oratomic в области квантовых алгоритмов. Три крупнейших технологических игрока независимо друг от друга сошлись на одной дате.

Что такое Harvest Now, Decrypt Later?

Собирай сейчас, расшифруй потом (Harvest Now, Decrypt Later, HNDL) — это стратегия, при которой злоумышленник перехватывает и архивирует зашифрованные данные сегодня, не имея возможности их прочитать, с расчётом расшифровать после появления криптоаналитически релевантного квантового компьютера. Атака не требует квантового компьютера прямо сейчас — она требует терпения и дискового пространства.

«Ждать появления угрозы, чтобы начать действовать, — путь к катастрофе. Во-первых, существует угроза «собирай сейчас, расшифруй потом». Уже сегодня злоумышленники могут накапливать зашифрованный трафик: переписку, финансовые документы, медицинские данные. Когда появится квантовый компьютер, они смогут расшифровать всё, что собирали годы. Если ваша информация должна оставаться тайной 10−30 лет, сегодняшние методы её не спасут», — Иван Чижов, заместитель руководителя лаборатории криптографии по научной работе компании «Криптонит» (Криптонит, 2026)

Как работает HNDL

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

1. Перехват. Злоумышленники собирают большие объёмы зашифрованного трафика и конфиденциальных данных.
2. Хранение. Перехваченные данные складируются на неопределённый срок: расшифровать их сейчас невозможно.
3. Расшифровка. После появления квантовых компьютеров весь накопленный архив расшифровывается.

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

Кого это касается в первую очередь

HNDL-атака бьёт прежде всего по данным с долгим сроком актуальности — тем, которые останутся чувствительными через 5, 10 или 20 лет. Чем дольше данные сохраняют ценность, тем выше риск.

Общий знаменатель — время. Злоумышленнику не нужно взламывать шифрование прямо сейчас. Достаточно собрать данные и подождать.

Глобальная регуляторика

Международная реакция на квантовую угрозу перешла из научной плоскости в нормативную. Ключевые юрисдикции уже установили обязывающие сроки или активно готовят стандарты — независимо от того, приняли ли они алгоритмы Национальный институт стандартов и технологий США (NIST) или разрабатывают собственные.

США

В августе 2024 года NIST утвердил три постквантовых стандарта:

• FIPS 203 (ML-KEM) — механизм инкапсуляции ключей, основан на алгоритме CRYSTALS-Kyber. Предназначен для защиты каналов связи от HNDL-атак.
• FIPS 204 (ML-DSA) — алгоритм цифровой подписи, основан на CRYSTALS-Dilithium. Заменяет ECDSA и RSA-подписи.
• FIPS 205 (SLH-DSA) — алгоритм цифровой подписи на основе хеш-функций (SPHINCS+). Альтернатива ML-DSA с иной математической базой.

Все три алгоритма уже реализованы в основных криптографических библиотеках (OpenSSL 3.x, BoringSSL, libsodium) и доступны для внедрения.

Указ от 22 июня 2026 года «О защите страны от продвинутых криптографических атак» перевёл рекомендации в жёсткие дедлайны. До 31 декабря 2030 года все федеральные системы будут обязаны перейти на постквантовые алгоритмы защиты каналов связи. До 31 декабря 2031 года — завершить замену алгоритмов цифровой подписи, которые удостоверяют подлинность документов, кода и сертификатов.

Раздел 6(c) указа — самый острый инструмент давления на рынок: Федеральный совет по регулированию закупок США обязан опубликовать правило, требующее от всех подрядчиков федерального правительства соответствия стандартам NIST FIPS, включая алгоритмы постквантовой криптографии, к 31 декабря 2030 года.

Это создаёт цепную реакцию. Microsoft, AWS, Google, SAP и тысячи других вендоров, работающих с федеральными заказчиками, обязаны обеспечить совместимость своих продуктов с постквантовыми стандартами к 2030 году или потерять выход на крупный рынок.

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

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

Риторика указов подчёркивает: для США постквантовый переход — вопрос технологического лидерства. Дедлайны 2030–2031 годов обязательны для всего федерального сектора США и через требования к подрядчикам будут распространяться на глобальный ИТ-рынок.

Китай

Управление государственной коммерческой криптографии (OSCCA) в феврале 2025 года запустило программу разработки алгоритмов следующего поколения. Национальные постквантовые стандарты ожидаются к 2028–2029 годам.

Действующая криптографическая база Китая (алгоритмы семейства ShangMi — SM2, SM3, SM4), уязвима перед квантовыми компьютерами. Параллельно Китай развивает крупнейшую в мире инфраструктуру квантового распределения ключей (QKD) — технология позволяет передавать криптографические ключи с абсолютной защитой от перехвата, используя законы квантовой механики. Квантовые технологии включены в число главных приоритетов 15-го пятилетнего плана развития Китая.

Европейский союз

В апреле 2024 года Европейская комиссия выпустила официальную рекомендацию по переходу на постквантовое шифрование (документ № 2024/1101). В развитие этой инициативы в июне 2025 года была представлена «Скоординированная дорожная карта внедрения постквантового шифрования». Финальный срок перехода установлен на декабрь 2030 года.

План миграции разделен на три этапа:

1. Инвентаризация (до конца 2025 года) — аудит текущих ИТ-систем и поиск уязвимых алгоритмов шифрования.
2. Гибридные пилотные проекты (2026–2027 годы) — тестирование новых алгоритмов совместно с классическими методами защиты.
3. Полный переход (до конца 2030 года) — окончательный отказ от устаревшего шифрования и внедрение постквантовых стандартов.

Каждые полгода участники процесса отчитываются о результатах перед Агентством Европейского союза по кибербезопасности (ENISA).

Великобритания

В марте 2025 года Национальный центр кибербезопасности Великобритании (NCSC) опубликовал трёхэтапную дорожную карту перехода на новые стандарты безопасности.

План миграции включает следующие шаги:

1. Инвентаризация и аудит (до 2028 года). Организациям необходимо полностью проверить свои ИТ-системы и составить подробную спецификацию криптографических материалов (Cryptographic Bill of Materials, CBOM). Этот реестр покажет, какие именно алгоритмы, ключи и сертификаты используются в инфраструктуре.
2. Защита критических систем (до 2031 года). На этом этапе планируется перевести наиболее важные государственные и корпоративные системы на гибридную криптографию — комбинацию классических и новых алгоритмов шифрования.
3. Полный отказ от устаревших алгоритмов (до 2035 года). К этому моменту организации должны полностью прекратить использование уязвимых криптографических алгоритмов (таких как RSA, ECDH и ECDSA) и перейти на постквантовые стандарты.

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

Германия

Федеральное ведомство по информационной безопасности Германии (BSI) последовательно публикует требования по переходу на новые стандарты защиты с 2021 года. Актуальная версия технического руководства ведомства (документ BSI TR-02102 за 2024 год) содержит следующие положения:

• Гибридный режим. Ведомство рекомендует использовать новые алгоритмы постквантового шифрования ML-KEM (для защиты каналов связи и обмена ключами) и ML-DSA (для создания цифровой подписи) только совместно с классическими методами защиты.
• Сроки перехода. Полную миграцию ИТ-систем на новые стандарты безопасности планируется завершить до 2030 года.
• Гибкость в выборе стандартов. В отличие от многих других стран, Германия разрешает компаниям использовать альтернативные криптографические алгоритмы, даже если они не входят в стандарты американского Национального института стандартов и технологий (NIST). Главное условие — математически доказанная надежность этих алгоритмов.

Южная Корея

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

• Для создания цифровых подписей утверждены алгоритмы AIMer и HAETAE.
• Для безопасного обмена ключами шифрования выбраны алгоритмы SMAUG-T и NTRU+.

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

1. Пилотное внедрение (2025–2028 годы). Тестирование южнокорейских алгоритмов в реальных инфраструктурах и запуск первых тестовых проектов.
2. Полная миграция (до 2035 года). Окончательный переход государственных ведомств и бизнеса на новые стандарты безопасности.

Сравнительная таблица: регуляторика постквантовой криптографии

Российские реалии

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

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

«Как и в любой наукоёмкой отрасли, в криптографии всегда всё начинается с фундамента и дальше прорастает во всё более и более прикладные области. И когда мы говорим про текущее состояние дел, мы понимаем, что у нас есть фундамент — свой, надёжный, суверенный. На нём мы строим российскую криптографию и создаём решения, которые не отстают от зарубежных аналогов, а в ряде направлений опережают мировые разработки», — Станислав Смышляев, генеральный директор компании «КриптоПро» (CNews, июнь 2026)

Суверенный статус российских квантовых разработок подтверждают и данные «Росатома». Директор по квантовым технологиям госкорпорации Екатерина Солнцева на конференции ЦИПР-2026 (Нижний Новгород, май 2026) сообщила:

«В зарождающейся квантовой индустрии известно приблизительно 100 типов квантовых алгоритмов, из которых примерно 20 воспринимаются как основные и 80 являются модификациями. У нас есть российские версии всех основных квантовых алгоритмов и порядка тридцати модификаций. То есть стек квантового программного обеспечения покрыт у нас уже достаточно хорошо. И сейчас мы приходим к тому, чтобы научиться использовать имеющиеся наработки для практических задач».

Российские эксперты сходятся в оценке приоритетов. Главный риск — не коллапс в день появления квантового компьютера, а сценарий Собирай сейчас, расшифруй потом (HNDL, Harvest Now, Decrypt Later).

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

На ПМЭФ-2026 (сессия «После гонки кубитов: кто строит квантовое будущее», 4 июня) участники зафиксировали смену фазы: российский рынок переходит от доказательства работоспособности технологии к её масштабированию в корпоративном секторе. «Иннопрактика» выделила три сценария квантовой трансформации для крупных компаний: пилоты на действующей ИТ-инфраструктуре, новые коммерческие сервисы для операторов ЦОД и долгосрочные стратегии перехода на квантово-защищённые каналы связи.

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

Симметричная криптография: что уже защищено

Российские симметричные алгоритмы Кузнечик (ГОСТ Р 34.12-2015) и Магма (ГОСТ Р 34.12-2015) устойчивы к квантовым атакам в своём нынешнем виде. Алгоритм Гровера снижает эффективную стойкость симметричного ключа вдвое: 256 бит → 128 бит эффективной стойкости. 128-битный уровень безопасности считается достаточным по современным криптографическим стандартам. Хеш-функция Стрибог (ГОСТ Р 34.11-2012) также устойчива к известным квантовым атакам.

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

Алгоритмы-кандидаты

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

• Шиповник — российский кандидат на постквантовую схему электронной цифровой подписи, основанный на кодах с исправлением ошибок (аналог семейства BIKE/HQC в конкурсе NIST). Компания Криптонит опубликовала открытую реализацию алгоритма. При успешном завершении криптоанализа Шиповник может стать первым российским постквантовым стандартом ЭЦП.
• Гиперикум — кандидат на постквантовую схему подписи на основе хеш-функций. Использует российский стандарт хеширования Стрибог-256 (ГОСТ Р 34.11-2012) как криптографическое основание — аналогично тому, как западный SLH-DSA (FIPS 205) строится на SHA-3. Разработка ведётся сотрудниками QApp в рамках деятельности подгруппы ТК 26.
• Кодиеум — постквантовый механизм инкапсуляции ключей (KEM), разработанный Криптонитом в 2024 году. Функционально является постквантовым аналогом протокола Диффи-Хеллмана: защищает передачу ключей шифрования при установке защищённого соединения. Как и Шиповник, основан на математической задаче декодирования случайного кода с исправлением ошибок. Проходит процедуру разработки методических рекомендаций по стандартизации в ТК 26.

Все три алгоритма проходят открытый криптоанализ — обязательный этап перед стандартизацией.

Практика внедрения: российские пилоты 2025–2026

Россия не ждёт принятия стандартов, чтобы начать практическую работу. Несколько крупных проектов уже перешли от концепции к реальной эксплуатации.

Финансовый сектор

QApp и Газпромбанк — компания QApp завершила пять пилотных проектов с Газпромбанком в области постквантовой защиты финансовых коммуникаций.

QApp и НСПК (Национальная система платёжных карт, оператор «Мир») — два пилотных проекта:

• Защита электронного документооборота — НСПК интегрировала решение Qtunnel компании QApp в систему электронного документооборота. Постквантовые алгоритмы шифрования заменили асимметричные схемы, уязвимые к атакам квантовых компьютеров. Проект реализован совместно с Российским квантовым центром (РКЦ).
• PQC PAY — разработка и тестирование квантово-устойчивых платёжных транзакций по протоколу BLE (Bluetooth Low Energy). Проект направлен на защиту бесконтактных платежей от будущих квантовых атак.

ВТБ — в мае 2026 года банк завершил пилотное тестирование защищённого канала связи на основе квантового распределения ключей (QKD). Между двумя московскими ЦОД банка проложена специализированная оптоволоконная линия: оборудование компании «Инфотекс» генерирует и автоматически распределяет симметричные ключи шифрования со скоростью до одного ключа в минуту без физических носителей и участия сотрудников в процессе доставки. Любое внешнее воздействие на канал мгновенно фиксируется через изменение фазы или амплитуды фотона. Партнёрами проекта выступили РЖД и «Иннопрактика». Результаты представлены на ПМЭФ-2026.

Топливно-энергетический комплекс

НОВАТЭК — в апреле 2026 года на объектах ПАО «НОВАТЭК» впервые в российском ТЭК протестировано оборудование квантового распределения ключей. Использовалось решение ViPNet QTS производства «ИнфоТеКС» — система для построения квантовой криптографической сети произвольной топологии.

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

Телекоммуникации

Билайн и РЖД — в апреле 2026 года ПАО «ВымпелКом» и РЖД совместно с «ИнфоТеКС» провели пилотные испытания QKD на реальной корпоративной сети. Московские офисы Билайна и РЖД подключили к узлу магистральной квантовой сети РЖД с помощью оборудования ViPNet.

В программу испытаний вошли генерация и распределение ключей шифрования, организация IP-связности, передача данных, VoIP-звонки и видеоконференцсвязь по защищённому каналу. Использовались программно-аппаратные комплексы «ИнфоТеКС»: ViPNet РУКС, шифратор канального уровня ViPNet L2Q-10G и криптошлюз ViPNet Coordinator HW 1000. Все тесты прошли успешно.

Инфраструктура

Квантовая сеть РЖД — магистральная квантовая сеть протяжённостью 7 858 км, охватывающая 27 регионов России. Это одна из крупнейших квантовых коммуникационных сетей в мире. Сеть использует технологию QKD для защиты критических железнодорожных коммуникаций.

Первый квантово-устойчивый TLS-шлюз — совместная разработка QApp и компании «С-Терра» обеспечивает постквантовую защиту HTTPS-трафика на уровне сетевого шлюза. Это позволяет организациям внедрять PQC без замены всей клиентской инфраструктуры.

Наука и государство

НТУ «Сириус» разработал два программных комплекта (SDK):

• SDK «Сириус-Q. Решатель QUBO» — инструмент для квантовых оптимизационных задач.
• SDK «Сириус-Q. КНАА-2-ЭЦП» — реализация квантово-устойчивой электронной цифровой подписи.

В марте 2026 года оба SDK одобрены Минцифры России для защиты национальных блокчейн-экосистем. Это первый официальный государственный акт признания конкретных постквантовых инструментов в России.

Заключение

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

Россия движется по собственной траектории: суверенные алгоритмы-кандидаты проходят криптоанализ, пилоты QKD запущены в финансовом секторе, ТЭК и телекоммуникациях, стандарты ожидаются в 2026–2027 годах. Направление совпадает с глобальным — сроки и инструменты отличаются.

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

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

Часто задаваемые вопросы о постквантовой криптографии

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

Постквантовая криптография (PQC) — это класс криптографических алгоритмов, устойчивых к атакам как классических, так и квантовых компьютеров. В отличие от квантовой криптографии (QKD), PQC работает на обычном «классическом» оборудовании и не требует квантовых каналов связи. Стандарты PQC основаны на математических задачах, для которых не существует эффективного квантового алгоритма: решётки, коды с исправлением ошибок, хеш-функции.

Что такое атака Harvest Now, Decrypt Later (HNDL)?

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

Когда появится криптографически значимый квантовый компьютер (Q-Day)?

Точной даты не знает никто, но консенсус экспертного сообщества сместился к 2028–2030 годам. Google, IBM и Cloudflare независимо друг от друга назвали 2029 год внутренним дедлайном перехода. Ключевое препятствие — коррекция квантовых ошибок: современные процессоры содержат тысячи физических кубитов, тогда как для взлома RSA-2048 алгоритмом Шора потребуются миллионы логических стабильных кубитов. Темп решения этой инженерной проблемы и определит реальный срок Q-Day.

Какие российские постквантовые алгоритмы разрабатываются?

ТК 26 («Криптографическая защита информации») продвигает три алгоритма-кандидата: «Шиповник» (схема ЭЦП на кодах с исправлением ошибок), «Гиперикум» (схема подписи на основе хеш-функции «Стрибог-256») и «Кодиеум» (механизм инкапсуляции ключей, постквантовый аналог протокола Диффи-Хеллмана). Все три проходят открытый криптоанализ. Принятие национальных стандартов прогнозируется в 2026–2027 годах.

Устойчивы ли российские ГОСТы к квантовым атакам?

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

Чем QKD отличается от постквантовой криптографии?

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

ГОСТ-шифрование для разработчиков: алгоритмы, СКЗИ и интеграция 2026

ГОСТ-стек хорошо специфицирован — сложность в интеграции. Разбираем четыре актуальных стандарта с OID-ами, механику шифрования изнутри, типичные точки отказа в nginx, Docker и браузерах, классы СКЗИ и границы лицензирования ФСБ и ФСТЭК.

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

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

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

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

Пассворк: как разделить контуры ИБ и бизнеса

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

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

В 2025 году ФСТЭК проверила более 700 значимых объектов КИИ и выявила свыше 1 200 нарушений в части обеспечения информационной безопасности. Направлено более 2 000 требований об устранении недочётов и составлено 603 протокола об административных правонарушениях.

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

Государство намерено сделать процесс перехода на российское ПО неизбежным. В том числе через финансовое принуждение:

«Ключевой вызов этого года — сформировать базу для придания этому процессу неизбежности. Тогда, если компания не хочет переходить на российское ПО и ПАКи на КИИ-объектах, пусть пополняет бюджет, из которого мы будем стимулировать дальше этот процесс. В нашем понимании единственный механизм принуждения — это всё-таки какие-то серьёзные штрафы финансовые на те компании, которые нарушают сроки», — Максут Шадаев, министр цифрового развития РФ (Интерфакс, 2026)

В то же время регулирование стало сложнее. 58-ФЗ, типовые отраслевые объекты, обновлённые формы категорирования, проект постановления Минцифры со сроками 2028–2036 годов — всё это появилось за последние два года. Требования различаются в зависимости от статуса организации, категории объекта и вида актива: ПО, СЗИ (средства защиты информации) или ПАК (программно-аппаратный комплекс). Часть запретов уже действует с 2025 года.

Главное

• Часть запретов уже действует. С 01.01.2025 иностранные СЗИ запрещены на всех ЗОКИИ, иностранное ПО — на ЗОКИИ госорганов и госкомпаний. Это действующие нормы.
• Проектируемый базовый дедлайн — 01.01.2028. К этой дате доля российского ПО на всех ЗОКИИ должна составить 100%. Срок содержится в проекте постановления, находящемся в Правительстве, и пока не утверждён окончательно.
• Специальные сроки 2031 и 2036 годов — не массовая отсрочка. Они обсуждаются только для участников особо значимых проектов и отдельных категорий ЗОКИИ. Рассчитывать на них без документальных оснований не следует.
• Штрафы за нарушение сроков готовятся. В июне 2026 года Минцифры подтвердило намерение сформировать нормативную базу для серьёзных финансовых санкций. Действующей нормой они пока не являются, но при планировании этот риск уже нужно учитывать.
• Регулирование усложнилось. 58-ФЗ, типовые отраслевые объекты, обновлённые формы категорирования — всё это появилось за последние два года. Требования различаются в зависимости от статуса организации, категории объекта и вида актива: ПО, СЗИ или ПАК.
• 2026 год — время подготовки, а не ожидания. Лишь 35% проверенных объектов КИИ соответствуют базовому уровню безопасности. ФСТЭК увеличивает число проверок. Компании, которые начнут аудит и ревизию категорирования сейчас, к дедлайну подойдут с готовым планом.

Что изменилось в импортозамещении КИИ к 2026 году

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

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

С 1 сентября 2025 вступил в силу 58-ФЗ и изменил архитектуру регулирования. Он существенно расширил полномочия Правительства РФ и создал нормативную основу для системного перехода на российское ПО и программно-аппаратные комплексы (ПАК) на значимых объектах КИИ. Правительство получило право устанавливать:

• перечни типовых отраслевых объектов КИИ;
• отраслевые особенности категорирования;
• порядок и сроки перехода на российское ПО и ПАК;
• требования к ПАК для ЗОКИИ;
• порядок мониторинга исполнения этих обязанностей.

В 2026 году появились первые подзаконные акты, реализующие 58-ФЗ. Постановление Правительства № 402 от 13.04.2026 установило отраслевые особенности категорирования объектов КИИ в сфере связи — они вступают в силу с 01.09.2026.

В мае 2026 года Минцифры представило проект постановления о сроках перехода ЗОКИИ на российское ПО с диапазоном 2028–2036 годов. По состоянию на июнь 2026 года проект находится в Правительстве и не утверждён окончательно.

2026 год — не период ожидания дедлайна 2028 года. Уже сейчас нужно уточнить состав объектов КИИ, провести аудит иностранного ПО и СЗИ, проверить наличие российских аналогов и подготовить согласованные дорожные карты перехода.

Кого касаются требования: субъект КИИ, объект КИИ, ЗОКИИ и типовые отраслевые объекты

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

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

Отдельный инструмент — типовые отраслевые объекты КИИ: перечни типов ИС, ИТКС и АСУ, утверждаемые Правительством РФ по отраслям. Они служат ориентиром для выявления объектов, подлежащих категорированию, — первый такой перечень утверждён распоряжением № 360-р от 26.02.2026.

Отрасли, на которые распространяется 187-ФЗ

Согласно Федеральному закону от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», к субъектам КИИ относятся организации в сферах:

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

Три категории значимости

Три категории значимости (первая, вторая и третья) определяют объём требований к системе обеспечения информационной безопасности (СОИБ). Первая категория соответствует наиболее критичным объектам и предполагает максимально жёсткие требования; третья — минимальные. Если объект КИИ не соответствует ни одному из критериев значимости, категория ему не присваивается.

Категорию объекту присваивают сами субъекты КИИ на основании оценки по пяти критериям, закреплённым в ст. 7 № 187-ФЗ:

Результаты категорирования субъект КИИ направляет в ФСТЭК России в течение 10 дней после принятия решения. Регулятор в течение 30 дней проверяет правильность присвоения категории.

Сроки перехода на российское ПО, СЗИ и ПАК

Проектируемый базовый срок перехода значимых объектов КИИ на российское ПО — 1 января 2028 года. По состоянию на июнь 2026 года этот срок содержится в проекте постановления, находящемся в Правительстве, и должен применяться после утверждения соответствующего акта. К этой дате доля российского программного обеспечения на ЗОКИИ должна составлять 100%.

Для отдельных сценариев в публикациях о проекте фигурируют специальные сроки — 1 января 2031 года и 1 января 2036 года. Обсуждаются следующие сценарии: участие в особо значимых проектах (ОЗП) с началом замещения до 01.09.2026, отсутствие российских аналогов, заключение контрактов ОЗП в 2026–2028 годах, а также отдельные условия для объектов КИИ второй и третьей категорий. До утверждения постановления эти условия следует считать проектируемыми и проверять по финальной редакции акта.

Матрица сроков: от 2022 до 2036 года (актуально на июнь 2026)

Ответственность за нарушение сроков: что известно на июнь 2026 года

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

Сроки по видам активов

Нормативная база: какие документы учитывать

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

Карта нормативных актов

• 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» — базовый закон. Вводит понятия субъекта КИИ, объекта КИИ, значимого объекта КИИ, устанавливает требования к безопасности и взаимодействию с ГосСОПКА (государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации).
• 58-ФЗ от 07.04.2025 — поправки к 187-ФЗ, вступившие в силу 01.09.2025. Расширяют полномочия Правительства: устанавливать типовые отраслевые объекты, отраслевые особенности категорирования, порядок и сроки перехода на российское ПО и ПАК, требования к ПАК, порядок мониторинга. Исключают ИП из числа субъектов КИИ. Обязывают субъектов КИИ использовать на ЗОКИИ ПО из реестра российского ПО Минцифры.
• Указ Президента РФ № 166 от 30.03.2022 (в ред. от 07.04.2025) — ограничивает закупки иностранного ПО для ЗОКИИ без согласования. С 01.01.2025 устанавливает запрет использования иностранного ПО на ЗОКИИ, принадлежащих госорганам и государственным организациям.
• Указ Президента РФ № 250 — обязывает всех владельцев ЗОКИИ перейти на российские СЗИ. С 01.01.2025 использование иностранных СЗИ на ЗОКИИ запрещено.
• Постановление Правительства РФ № 402 от 13.04.2026 — утверждает отраслевые особенности категорирования объектов КИИ в сфере связи. Вступает в силу 01.09.2026. Первый отраслевой акт, реализующий полномочия Правительства по 58-ФЗ.
• Приказ ФСТЭК России № 117 — с 01.03.2026 обновляет требования защиты информации для государственных информационных систем (ГИС) и иных систем государственных органов, ГУПов и учреждений. Актуален для организаций, у которых объекты КИИ одновременно являются ГИС.
• Приказ ФСТЭК России № 247 от 11.07.2025 — обновляет форму направления сведений о результатах категорирования объектов КИИ. С 01.09.2025 форма дополнена полем о наименовании типового отраслевого объекта КИИ, доменным именем и внешним сетевым адресом.
• Постановление Правительства РФ № 127 — устанавливает показатели критериев значимости объектов КИИ и порядок категорирования.
• Постановление Правительства РФ № 1478 — определяет требования к системам безопасности значимых объектов КИИ.
• Распоряжение Правительства РФ № 360-р от 26.02.2026 — утверждает перечень типовых отраслевых объектов КИИ. Триггер для ревизии состава объектов у субъектов КИИ.

Как категорирование связано с импортозамещением

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

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

Распоряжение Правительства № 360-р от 26.02.2026 утвердило первый такой перечень. Для субъектов КИИ это означает необходимость сверить собственный реестр объектов с типовым перечнем: не исключено, что часть систем, ранее не признававшихся объектами КИИ, теперь попадает в периметр регулирования.

Почему актуализация категорирования критична в 2026 году

Форма направления сведений о результатах категорирования обновлена Приказом ФСТЭК № 247: с 01.09.2025 она включает поле о наименовании типового отраслевого объекта КИИ. Если организация не сверила свои объекты с новыми перечнями и не актуализировала сведения — она рискует направить во ФСТЭК неполные данные.

Реестр ЗОКИИ также получил новый формат регистрационного номера: XXXXXX/Х/XX/Х, где зашифрованы порядковый номер, федеральный округ, сфера деятельности и тип объекта (ИС, АСУ или ИТКС). Сведения из реестра ежемесячно передаются государственным органам, уполномоченным на реализацию государственной политики в соответствующей сфере.

Отраслевые особенности категорирования

Первый отраслевой акт (Постановление Правительства № 402 от 13.04.2026 для сферы связи) вступает в силу 01.09.2026. Он определяет отраслевые признаки значимости и порядок расчёта показателей критериев значимости с учётом специфики телекоммуникационных объектов.

Аналогичные постановления для других отраслей (энергетика, финансы, транспорт, здравоохранение) ожидаются в 2026–2027 годах по мере реализации полномочий Правительства по 58-ФЗ. Субъектам КИИ из этих отраслей стоит отслеживать появление отраслевых актов и закладывать время на ревизию категорирования.

Что именно нужно заменить: ПО, СЗИ, ПАК и управление доступом

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

Три класса активов и логика их замены

• Российское ПО — программный продукт, включённый в единый реестр российского программного обеспечения Минцифры России. Включение в реестр подтверждает российское происхождение, но не означает автоматического соответствия требованиям безопасности для ЗОКИИ. Для ПО, используемого в качестве СЗИ, дополнительно требуется сертификат ФСТЭК или ФСБ.
• Средства защиты информации (СЗИ) — отдельный класс продуктов: антивирусные средства, межсетевые экраны, системы обнаружения вторжений, средства криптографической защиты, системы управления доступом и аутентификации. Для ЗОКИИ с 01.01.2025 действует запрет использования иностранных СЗИ (Указ № 250). Российское происхождение СЗИ подтверждается реестром Минцифры, а соответствие требованиям безопасности — сертификатом ФСТЭК или ФСБ в зависимости от класса продукта.
• Доверенные программно-аппаратные комплексы (ПАК) — связка программного и аппаратного компонентов, отвечающая отдельным требованиям доверенности. Требования к ПАК для ЗОКИИ устанавливаются Правительством РФ по 58-ФЗ. Базовый ориентир перехода на доверенные ПАК — 01.01.2030. Сроки и порядок перехода на ПАК отличаются от сроков перехода на ПО: их нельзя смешивать при планировании.

Реестр российского ПО: как проверять

Единый реестр российского ПО ведёт Минцифры России. При проверке продукта важно убедиться:

• что продукт включён в реестр и запись актуальна;
• что класс ПО в реестре соответствует функции, для которой оно применяется на ЗОКИИ;
• что для СЗИ дополнительно получен действующий сертификат ФСТЭК или ФСБ;
• что продукт функционально совместим с существующей инфраструктурой объекта.

План действий на 2026 год

В 2026 году компании должны провести ревизию объектов, уточнить категорирование, определить состав иностранного ПО/СЗИ/ПАК, проверить наличие российских аналогов и подготовить согласованный план перехода. Это минимальный набор действий, без которого старт миграции в 2027 году окажется неуправляемым. Ниже — Дорожная карта импортозамещения КИИ:

Этап 1

1. Ревизия объектов КИИ. Сверьте реестр объектов организации с распоряжением Правительства № 360-р (перечень типовых отраслевых объектов КИИ). Проверьте, не появились ли системы, которые теперь подпадают под определение типового отраслевого объекта КИИ, но ранее не были включены в реестр.
2. Актуализация сведений о категорировании. Обновите форму направления сведений во ФСТЭК с учётом Приказа № 247: добавьте наименование типового отраслевого объекта, доменные имена и внешние сетевые адреса. Если категорирование проводилось до 01.09.2025 — проверьте, нужен ли пересмотр категорирования и актуализация сведений во ФСТЭК.
3. Инвентаризация иностранного ПО, СЗИ и ПАК. Составьте полный реестр иностранного программного обеспечения, средств защиты и программно-аппаратных комплексов на каждом ЗОКИИ. Зафиксируйте: вендор, версия, функция, наличие или отсутствие поддержки, наличие российского аналога.
4. Назначение ответственных. Определите должностное лицо, ответственное за организацию перехода. Для федеральных органов власти и госкорпораций это требование закреплено в предложениях Минцифры: ответственный — не ниже заместителя руководителя.

Этап 2

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

Этап 3

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

Импортозамещение КИИ — это управляемый проект

Переход на российское ПО, СЗИ и ПАК на значимых объектах КИИ — многоэтапная программа, которая требует корректного определения объектов, инвентаризации активов, проверки аналогов и поэтапной миграции с контролем доступа и документированным планом отката.

Компании, которые начнут с ревизии категорирования и аудита иностранного ПО в 2026 году, к дедлайну 2028 года подойдут с готовым планом.

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

Управление учётными данными подрядчиков и сотрудников — отдельное требование при проверке ФСТЭК. Менеджера паролей и секретов Пассворк сертифицирован ФСТЭК и включён в реестр российского ПО Минцифры. Протестировать можно бесплатно

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

Кого касается импортозамещение КИИ в 2026 году?

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

До какого срока нужно перейти на российское ПО на значимых объектах КИИ?

Базовый срок — 1 января 2028 года: к этой дате доля российского ПО на ЗОКИИ должна составлять 100%. Для отдельных сценариев Минцифры предложило сроки 1 января 2031 года и 1 января 2036 года. По состоянию на июнь 2026 года эти сроки содержатся в проекте постановления Правительства и не являются окончательно утверждёнными нормами. Рассчитывать на них без документально подтверждённых оснований не следует.

Чем отличается субъект КИИ от значимого объекта КИИ?

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

Что такое типовые отраслевые объекты КИИ и зачем они нужны?

Типовые отраслевые объекты КИИ — перечни типов ИС, ИТКС и АСУ по отраслям, утверждаемые Правительством РФ на основании 58-ФЗ. Они служат ориентиром для выявления объектов, подлежащих категорированию, и унифицируют подход к субъектам одной отрасли. Первый перечень утверждён распоряжением № 360-р от 26.02.2026. Субъектам КИИ необходимо сверить свой реестр объектов с этим перечнем.

Достаточно ли включения продукта в реестр российского ПО для использования на ЗОКИИ?

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

Чем доверенный ПАК отличается от российского ПО?

Российское ПО — программный продукт, соответствующий критериям отечественного происхождения и включённый в реестр Минцифры. Доверенный ПАК — связка программного и аппаратного компонентов, отвечающая отдельным требованиям доверенности, которые устанавливает Правительство РФ по 58-ФЗ. Сроки и порядок перехода на ПО и ПАК различаются: проектируемый базовый ориентир для ПАК — 01.01.2030, для ПО — 01.01.2028. Оба срока содержатся в проектируемых актах и подлежат уточнению после их утверждения.

Что нужно сделать субъекту КИИ в 2026 году?

Провести ревизию реестра объектов с учётом типовых отраслевых перечней, актуализировать сведения о категорировании во ФСТЭК, составить реестр иностранного ПО/СЗИ/ПАК, проверить российские аналоги и их совместимость, запустить пилоты, подготовить дорожную карту, назначить ответственного и описать права доступа подрядчиков.

Как связаны импортозамещение и управление доступом?

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

Можно ли отложить импортозамещение КИИ?

В публикациях о проекте обсуждаются специальные сроки для нескольких сценариев: участие в особо значимых проектах с началом замещения до 01.09.2026, отсутствие российских аналогов, заключение контрактов ОЗП в 2026–2028 годах, а также отдельные условия для объектов КИИ второй и третьей категорий. Окончательный перечень условий зависит от утверждённой редакции постановления. Ни один из этих сценариев не действует автоматически.

Какие ошибки чаще всего допускают при импортозамещении КИИ?

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

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

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

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

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

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

Пассворк: как разделить контуры ИБ и бизнеса

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

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

У ИБ-отдела особый класс секретов: доступы к 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 год.

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