Госсектор

Только 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-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

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

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 год.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это означает

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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