Госсектор

Выбор менеджера паролей для финансовой организации начинается с вопроса, какой документ Банка России вы выполняете. Банки применяют Положение № 851-П, некредитные финансовые организации (НФО) — Положение № 757-П. Оба требуют соответствия ГОСТ Р 57580.1-2017, но уровни защиты и периодичность оценки у них разные.

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

Рисков за год стало больше. По данным InfoWatch, в российских финансовых организациях зафиксировано 44 утечки против 29 годом ранее, и рост дали в основном небольшие микрофинансовые организации (МФО) и страховые компании. С 2027 года требования к ним растут: страховые организации переходят на стандартный уровень защиты, а МФО впервые попадают в перечни уровней Положения № 757-П.

Почему учётные данные сотрудников — слабое место финансовой организации

Нарушения со стороны сотрудников и кража учётных данных дают заметную долю инцидентов в российских финансовых организациях. По данным ГК «Солар» за 2025 год, 30% подтверждённых инцидентов связаны с нарушением сотрудниками политик безопасности, ещё 15% — с кражей учётных данных. В обоих случаях злоумышленнику или нарушителю нужен только действующий доступ.

Цифры за 2025 год

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

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

Какие документы Банка России задают требования к защите информации: банки и НФО

ГОСТ Р 57580.1-2017 сам не определяет, кто обязан его применять. Обязанность и уровень защиты устанавливают нормативные акты Банка России. Банки выполняют Положение № 851-П, некредитные финансовые организации (НФО) — Положение № 757-П. Изменения в 757-П из Указания № 7219-У вступают в силу 1 января 2027 года.

Что такое уровень защиты информации

Уровень защиты информации — это набор мер из ГОСТ Р 57580.1-2017, который организация обязана выполнять для своих информационных систем. Уровней три: минимальный (третий), стандартный (второй) и усиленный (первый).

Банки: Положение № 851-П

Положение Банка России от 30.01.2025 № 851-П зарегистрировано Минюстом России 06.03.2025 (№ 81462) и действует с 29.03.2025. Оно распространяется на кредитные организации (КО) и филиалы иностранных банков. Положение № 683-П утратило силу (п. 16 851-П).

Уровень защиты задаёт п. 3.1:

• Усиленный применяют системно значимые КО, КО — операторы услуг платёжной инфраструктуры системно значимых платёжных систем и КО, значимые на рынке платёжных услуг.
• Стандартный применяют остальные КО.
• Минимальный применяют филиалы иностранных банков до 31.12.2026, с 01.01.2027 они переходят на стандартный уровень (п. 15 851-П).

НФО: Положение № 757-П и изменения с 2027 года

Положение № 757-П от 20.04.2021 зарегистрировано Минюстом России 15.06.2021 (№ 63880) и заменило Положение № 684-П (п. 4.5 757-П). Оно распространяется на НФО из перечней пп. 1.4.2–1.4.4: страховые организации, НПФ, профессиональных участников рынка ценных бумаг и другие. МФО войдут в перечень с 01.01.2027.

Указание № 7219-У от 28.10.2025 (зарегистрировано Минюстом России 06.02.2026, № 85262) вступает в силу 01.01.2027. До этой даты действует текущая редакция 757-П. После неё:

• Страховые организации, НПФ и регистраторы входят в перечень стандартного уровня (пп. 1.4.3 в новой редакции).
• МФО входят в перечень минимального уровня (пп. 1.4.4): с 01.01.2027 — большинство МФО, с 01.01.2028 — все, включая МФО предпринимательского финансирования и МФО с государственным или муниципальным учредителем.

Остальные НФО распределены по уровням перечнями пп. 1.4.2–1.4.4.

Банк, совмещающий деятельность с НФО

Если банк совмещает деятельность с НФО и формирует для объектов информационной инфраструктуры один контур безопасности, он применяет наиболее высокий из требуемых уровней защиты (п. 3.1 851-П; п. 4.2 757-П в редакции 7219-У).

Сводка: какой документ и уровень применяются

Чем требования к банкам отличаются от требований к НФО

У банков и НФО общая основа, ГОСТ Р 57580.1-2017, но разные документы, наборы уровней, периодичность внешней оценки и сроки сообщения об инциденте. Банки подчиняются 851-П и проходят оценку не реже раза в два года. У НФО действует 757-П, и сроки зависят от уровня защиты.

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

Минимальный уровень НФО отличается от стандартного: об инциденте сообщают в течение 24 часов, а обязанность проводить оценку соответствия по новому п. 1.5 757-П установлена только для усиленного и стандартного уровней.

Что изменится для НФО с 1 января 2027 года

С 1 января 2027 года Указание № 7219-У переводит страховые организации, НПФ и регистраторов на стандартный уровень защиты по ГОСТ Р 57580.1-2017 и включает МФО в Положение № 757-П на минимальном уровне.

Что меняется по существу

• Страховщики, НПФ и регистраторы получают стандартный уровень (пп. 1.4.3 757-П в новой редакции).
• Внешняя оценка. По сообщению Банка России, эти организации не реже раза в три года привлекают сторонних специалистов для проверки уровня защиты и оценивают программное обеспечение и приложения, в том числе клиентские.
• Сообщение об инциденте: 3 часа для усиленного и стандартного уровней, 24 часа для минимального.
• По сообщению Банка России, МФО должны применять антивирусные средства и регистрировать события защиты информации.» Ссылка на пресс-релиз ЦБ.

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

Чек-лист подготовки к 01.01.2027 (5 шагов):

1. Инвентаризация учётных записей. Определите, в каких системах работают сотрудники и у каких записей нет владельца.
2. Отказ от групповых учётных записей. У каждого сотрудника личная запись. Общие доступы выдавайте через права на хранилище, а не пересылкой паролей по почте и в чатах.
3. Ролевая модель. Привяжите права к роли и группе каталога.
4. Журнал аудита с выгрузкой в SIEM. Фиксируйте входы и изменения прав. Срок хранения задаёт политика организации.
5. Многофакторная аутентификация. Сначала для администраторов, затем для всех с доступом к критичным системам.

Что ГОСТ Р 57580.1 требует от управления доступом: учётные записи и пароли

Ни 851-П, ни 757-П не называют менеджер паролей. Они требуют реализовать уровень защиты по ГОСТ Р 57580.1-2017, а меры процесса «Управление доступом» без централизованного учёта учётных данных на практике не подтвердить. Ниже карта мер: требование, функция менеджера паролей и то, что показать проверяющему.

Карта мер: от требования ГОСТ Р 57580.1 к функциям менеджера паролей

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

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

Как выбрать менеджер паролей для банка или НФО: 7 критериев под требования ЦБ

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

Проблемы с парольной политикой массовые. По данным Positive Technologies (результаты пентестов 2024–2025 годов, межотраслевая выборка), у 97% компаний нашли недостатки в её реализации, у 70% из них риск оценили как критический.

Чек-лист выбора менеджера паролей для финансовой организации (7 критериев)

1. Интеграция с AD/LDAP и SSO. Учётная запись, отключённая в каталоге, должна терять доступ к сейфам. Спросите поставщика, через какое время блокировка в Active Directory закрывает доступ.
2. Разделение обязанностей. Администратор системы технически не должен видеть содержимое личных сейфов сотрудников. На пилоте проверьте, может ли администратор прочитать личную запись.
3. Журнал аудита с экспортом в SIEM. Срок хранения журнала задаёт политика организации. Данные о действиях работников в автоматизированных системах банк хранит не менее пяти лет (п. 5.2.5 851-П), поэтому журнал менеджера паролей лучше выгружать во внешнее хранилище. Уточните формат событий и системы-получатели.
4. Шифрование на стороне клиента. ГОСТ или AES-256 и модель нулевого разглашения (zero-knowledge): сервер хранит только шифротекст, взлом сервера не раскрывает пароли. Узнайте, где генерируются ключи и что лежит на сервере.
5. Многофакторная аутентификация для входа. Обязательна для администраторов, на усиленном уровне нужна всем. Проверьте набор факторов: TOTP, ключи доступа, биометрия, вход через SSO.
6. Модель размещения и устойчивость. Собственный сервер в закрытом контуре или облако, отказоустойчивая конфигурация, резервные копии. Защищённость зависит от харденинга сервера: его размещают в защищённом сегменте и ограничивают административный доступ. Поддерживаемые конфигурации и харденинг должны быть описаны в документации.
7. Зрелость поставщика. Сертификат ФСТЭК, лицензии ФСТЭК и ФСБ, запись в реестре российского ПО, безопасная разработка, программа поиска уязвимостей.

Как Пассворк закрывает требования ЦБ к учётным данным в банке и НФО

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

Учётные записи и права

Пассворк подключается к SSO, Active Directory и LDAP: импортирует пользователей и группы, сопоставляет группы каталога с группами Пассворка и отзывает доступ, когда учётную запись отключают в каталоге

• Права. Назначаются через роли, политики сейфов и группы. Для сейфов можно назначить обязательных администраторов.
• Парольная политика. Длина, набор символов и срок действия задаются на уровне сейфа, папки или записи.
• Вход. Доступны двухфакторная аутентификация (TOTP, приложение «Пассворк 2ФА», биометрия, ключи доступа и аппаратные ключи) и SSO.

Эти функции отвечают строкам карты мер про уникальные записи, владельцев доступа, ролевую модель, парольную политику и MFA.

Аудит для оценки соответствия

Журнал хранит историю действий пользователей и изменений. События экспортируются в syslog, Event Viewer и SIEM. Панель безопасности показывает старые, слабые и скомпрометированные пароли с фильтрами по сейфам, папкам и пользователям. Это соответствует мерам по инвентаризации учётных записей и журналам аутентификации.

Доступ для подрядчиков

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

Секреты для приложений и интеграций

Учётные данные приложений относятся к отдельному контуру, но хранить их можно в той же платформе. Для CI/CD и интеграций Пассворк выдаёт секреты через REST API, консольную утилиту passwork-cli, Python SDK и Docker-образ CLI. Сервисные аккаунты получают токены с ограниченными правами, поэтому пароли и ключи не приходится держать в конфигурационных файлах и скриптах.

Хранение и размещение

Коробочная версия устанавливается на сервере заказчика, в том числе в изолированном контуре.

• Шифрование. ГОСТ или AES-256. Клиентское шифрование по модели нулевого разглашения (zero-knowledge) оставляет на сервере только шифротекст.
• Отказоустойчивость. Строится горизонтальным масштабированием серверов приложений и репликацией базы данных.
• Совместимость. Пассворк имеет официальные сертификаты совместимости с российскими платформами: операционными системами (РЕД ОС, Astra Linux, ОС «МСВСфера», ОС «Атлант», Альт Сервер, SelectOS), СУБД (Pangolin DB, Nexign Nord), службами каталогов и администрирования (MultiDirectory, РЕД АДМ), а также с решениями для привилегированного доступа и аутентификации (СКДПУ НТ, Аладдин JMS 4LX). Полный перечень приведён на странице сертификатов совместимости.

Пример из практики: МТС Банк

МТС Банк развернул Пассворк в отказоустойчивой конфигурации на РЕД ОС, подключил LDAP и включил обязательную двухфакторную аутентификацию для всех сотрудников. Для банка решающим стало то, что администраторы системы не имеют доступа к личным сейфам пользователей (кейс МТС Банка).

Сертификаты и границы применения

Пассворк сертифицирован ФСТЭК России (сертификат № 5063, 4-й уровень доверия), имеет лицензии ФСТЭК и ФСБ и включён в реестр российского ПО (запись № 6147).

Заключение

База у банков и НФО одна, ГОСТ Р 57580.1-2017. Различаются документ, уровень защиты и периодичность внешней оценки. С 2027 года страховые организации, НПФ и регистраторы переходят на стандартный уровень, и разрыв с банками сокращается. Меры управления доступом без единого учёта учётных данных подтвердить трудно.

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

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

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

Какое положение ЦБ действует для банков вместо 683-П?

С 29 марта 2025 года требования к защите информации кредитных организаций устанавливает Положение Банка России № 851-П от 30.01.2025. Положение № 683-П утратило силу (п. 16 851-П). Уровень защиты по-прежнему задаётся по ГОСТ Р 57580.1-2017: усиленный или стандартный, в зависимости от типа кредитной организации.

Что меняется для страховых компаний и НПФ с 1 января 2027 года?

Указание № 7219-У включает страховые организации и НПФ в перечень НФО стандартного уровня защиты по ГОСТ Р 57580.1. О выявленных инцидентах нужно сообщать в Банк России в течение трёх часов, а уровень защиты проверять с привлечением сторонних специалистов не реже раза в три года.

Как часто банк и НФО проходят оценку соответствия по ГОСТ Р 57580.2?

Банк проходит оценку не реже одного раза в два года с привлечением проверяющей организации, уровень соответствия не ниже четвёртого (пп. 13.2–13.4 851-П). НФО усиленного уровня оценивают соответствие не реже раза в год, стандартного уровня — не реже раза в три года (п. 1.5.3 757-П).

Обязан ли банк использовать менеджер паролей по требованиям ЦБ?

Нет, ни Положение № 851-П, ни Положение № 757-П не называют менеджер паролей. Они требуют обеспечить уровень защиты по ГОСТ Р 57580.1-2017 и подтвердить его на оценке соответствия. Управление доступом входит в стандарт, и менеджер паролей закрывает часть его мер: уникальные учётные записи, парольную политику, журналы.

Что показать проверяющей организации по учётным данным?

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

Расширенная версия Пассворка: что входит и чем отличается

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

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

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

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

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

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

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

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

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

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

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

1. Инвентаризация должна охватывать людей, подрядчиков и служебные учётные записи — не только «список паролей».
2. Роль, обоснование, срок и владелец доступа важнее самого факта наличия сложного пароля.
3. Парольная политика работает вместе с многофакторной аутентификацией, разграничением прав и аудитом действий.
4. Менеджер паролей и система управления привилегированным доступом (PAM) закрывают разные задачи, и путать их — техническая ошибка.
5. Изменения безопаснее начинать с пилотного проекта на ограниченном наборе систем, а не с одновременного охвата всего контура.

Что такое КИИ

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

Согласно ст. 2 Федерального закона № 187‑ФЗ:

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

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

Что регулируют 187‑ФЗ и приказ ФСТЭК № 239 для объектов КИИ

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

Требования приказа № 239 распространяются только на объекты, которые прошли категорирование и признаны значимыми. Для них документ предусматривает состав организационных и технических мер, включая управление учётными записями, модель управления доступом и назначение минимально необходимых прав.

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

Почему доступы становятся риском в производственном контуре

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

По данным Positive Technologies, промышленность вышла на первое место среди отраслей по числу успешных атак на организации в России: её доля выросла с 16% в 2024 году до 19% в 2025-м. Это не означает, что каждая атака начинается с компрометации пароля, но неуправляемые учётные записи расширяют поверхность атаки в любом сценарии.

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

Изолированность технологического сегмента не снимает эти риски: обслуживание, обновления и обмен данными с ИТ-контуром всё равно проходят через учётные записи, которые нужно инвентаризировать и регламентировать.

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

Карта доступов: кого и что учитывать на производстве

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

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

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

Пять действий по управлению доступом в производственном контуре

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

1. Инвентаризация

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

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

2. Классификация ролей и прав

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

3. Политики хранения и передачи секретов

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

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

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

4. Подрядчики и удалённые работы

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

1. Назначьте владельца доступа со стороны предприятия.
2. Зафиксируйте обоснование — какая задача требует доступа.
3. Установите срок действия, привязанный к длительности работ.
4. Согласуйте доступ с владельцем системы и по правилам предприятия.
5. Отозвите доступ сразу после завершения работ и зафиксируйте дату отзыва.

5. Регулярный пересмотр прав

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

Конкретные сроки предприятие устанавливает самостоятельно — они зависят от категории объекта, архитектуры и внутренних регламентов, а не от универсального требования.

Как начать без риска для производства: пробное внедрение

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

1. Выбрать ограниченный набор систем и согласовать владельцев. Начните с одного цеха или одной группы инженерных станций, а не со всего предприятия сразу.
2. Составить реестр аккаунтов и определить критичность. Используйте чек-лист инвентаризации из раздела о пяти действиях по управлению доступом.
3. Настроить роли, правила выдачи и отзыв доступа. Определите, кто утверждает доступ и по каким критериям.
4. Перенести секреты и проверить сценарии восстановления. Убедитесь, что доступ к критичным паролям сохраняется даже при недоступности ответственного сотрудника.
5. Зафиксировать результаты, замечания и правила масштабирования. Оцените, что сработало, и определите порядок распространения практики на весь контур.

На этапе настройки ролей и правил выдачи доступа Пассворк помогает централизованно хранить корпоративные пароли и секреты, разграничивать права и фиксировать действия пользователей в самом продукте. Данные хранятся на сервере организации, администратор разграничивает права на уровне папок и сейфов, а журнал фиксирует действия пользователей и историю изменений. Пассворк интегрируется с LDAP, единым входом (SSO) и SIEM. Сертификат ФСТЭК № 5063 подтверждает соответствие 4-му уровню доверия.

Эти возможности не заменяют проект по категорированию объекта и сами по себе не гарантируют соответствия приказу ФСТЭК России № 239. Состав мер определяет предприятие совместно со службой ИБ.

Какие документы подготовить для внутренней проверки

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

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

Заключение

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

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

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

Часто задаваемые вопросы о контроле доступов в КИИ на производстве

Какие учётные записи нужно включить в инвентаризацию КИИ?

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

Чем менеджер паролей отличается от системы управления привилегированным доступом (PAM)?

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

Как снизить риск доступа подрядчика?

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

Как работать со служебными учётными записями?

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

Можно ли развернуть Пассворк в контуре предприятия?

Официальная страница Пассворка указывает хранение данных на сервере организации и варианты установки на Windows Server и Linux.5 Соответствие конкретному технологическому контуру, категории объекта и внутренним регламентам оценивают в проекте совместно с ИБ-службой предприятия — универсального ответа для всех объектов КИИ не существует.

Заменяет ли парольная политика полноценный контроль доступа?

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

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

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

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

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

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

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

Преимущества и недостатки Single Sign-On

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

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

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

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

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

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

1. Приказ № 55. Определяет, кто участвует в сертификации СЗИ (ФСТЭК, орган по сертификации, испытательная лаборатория, заявитель), по каким схемам и с какими сроками.
2. Когда сертификация обязательна. Для СЗИ в государственных информационных системах (ГИС), информационных системах персональных данных (ИСПДн) и на объектах критической информационной инфраструктуры (КИИ).
3. Путь от заявки до сертификата. 6 этапов с фиксированными сроками на каждом: от 15 календарных дней на рассмотрение заявки до 45 дней на экспертное заключение.
4. Приказ № 76. Задаёт глубину проверки — 6 уровней доверия, от 1-го (самый строгий, для гостайны) до 6-го.
5. Приказ № 240. Сертифицирует процесс безопасной разработки по ГОСТ Р 56939. № 55 оценивает «что вы сделали», № 240 — «как вы это делаете».
6. Приказ № 9 от 20.01.2026 (в силе с 02.05.2026). Уточнил состав документов на нескольких этапах сертификации и ввёл требование подавать перечень компонентов с открытым исходным кодом и образов контейнеров.
7. Пассворк. В апреле 2026 года прошёл все 6 шагов и получил сертификат ФСТЭК № 5063 с 4-м уровнем доверия — максимальным из применяемых для коммерческих СЗИ.

Что такое Приказ ФСТЭК № 55 и зачем он нужен

Приказ ФСТЭК от 3 апреля 2018 г. № 55 — рамочный документ, утверждающий Положение о системе сертификации средств защиты информации. Согласно пункту 2 Положения, документ определяет «состав участников системы сертификации... а также организацию и порядок сертификации продукции, используемой в целях защиты сведений» — то есть устанавливает правила проверки: кто проводит испытания, по каким критериям, кто выдаёт сертификат и как долго он действует.

Согласно пункту 3 Положения, сертификации подлежат три категории продукции:

1. Средства противодействия иностранным техническим разведкам, а также средства контроля эффективности противодействия иностранным техническим разведкам.
2. Средства технической защиты информации, включая средства, в которых они реализованы, а также средства контроля эффективности технической защиты информации.
3. Средства обеспечения безопасности информационных технологий, включая защищённые средства обработки информации.

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

• Приказ № 117 — для ГИС, сменивший № 17 с 1 марта 2026 года
• Приказ № 21 — для ИСПДн
• Приказ № 239 — для значимых объектов КИИ

Обязанность защищать такие системы закреплена статьёй 19 Федерального закона № 152-ФЗ «О персональных данных» и Федеральным законом № 187-ФЗ «О безопасности КИИ».

Приказ № 55, № 76 и № 240: что к чему

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

Коротко: № 55 отвечает на вопрос «что проверяют и как выдают сертификат», № 76 — «насколько глубоко проверяют», № 240 — «как вендор разрабатывает продукт ещё до всякой проверки».

• Приказ 55 — про продукт: соответствует ли готовое СЗИ требованиям безопасности.
• Приказ 240 — про процесс: использует ли разработчик безопасные практики при создании ПО.

Приказы № 55 и № 240 связаны напрямую. Пункт 71.1 приказа 55 касается разработчика СЗИ, у которого уже есть сертификат соответствия процедур безопасной разработки по приказу № 240. Когда он вносит изменения в сертифицированное СЗИ, в том числе добавляет новые функции безопасности, он вправе «проводить испытания средства защиты информации самостоятельно или с привлечением испытательной лаборатории».

Это упрощённый порядок сопровождения сертификата. Лаборатория по-прежнему контролирует процесс, но часть проверок заявитель выполняет сам. Поэтому сертификат по приказу № 240 стоит получить: он облегчает дальнейшее сопровождение сертификата по приказу № 55.

Но для большинства заявителей отправная точка всё же приказ № 55. Именно он определяет, получит ли продукт сертификат соответствия и попадёт ли в реестр ФСТЭК.

Схема процесса сертификации СЗИ в системе ФСТЭК России: этапы и участники

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

Ниже разберём каждый этап по порядку: кто за что отвечает, какие документы готовятся и где обычно возникают задержки.

Кто участвует в сертификации: 4 роли по Приказу № 55

Пункт 5 Положения перечисляет участников системы сертификации ФСТЭК России:

1. Федеральный орган по сертификации
2. Организации, аккредитованные ФСТЭК России в качестве органа по сертификации
3. Организации, аккредитованные ФСТЭК России в качестве испытательной лаборатории
4. Изготовители средств защиты информации

Разберём каждую роль.

ФСТЭК России: федеральный орган по сертификации

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

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

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

Согласно пункту 7 Положения, органы по сертификации «осуществляют сертификацию средств защиты информации, оформляют сертификаты соответствия средств защиты информации требованиям по безопасности информации».

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

Испытательная лаборатория

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

Лаборатория не может быть аффилирована с заявителем — это ключевое требование к её независимости.

Заявитель

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

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

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

Схемы сертификации: единичный образец, партия, серия

Пункт 12 Положения устанавливает три схемы сертификации. Выбор схемы определяет объём испытаний, состав проверок и сферу действия сертификата.

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

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

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

6 шагов заявителя: пошаговый план сертификации по Приказу 55

Раздел III «Порядок проведения сертификации средства защиты информации» перечисляет процедуры от подачи заявки до прекращения действия сертификата.

Шаг 1. Подготовка и подача заявки

Согласно пункту 19 Положения, до подачи заявки заявитель обязан:

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

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

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

Шаг 2. Рассмотрение заявки и принятие решения

Согласно пункту 23 Положения, ФСТЭК России рассматривает заявку в течение 15 календарных дней со дня её получения. Пункт 25 устанавливает основания для отказа:

• несоответствие назначения СЗИ компетенции ФСТЭК;
• отсутствие у заявителя необходимой лицензии;
• недостоверные сведения в заявке;
• наличие в банке данных угроз ФСТЭК сведений об уязвимостях средства защиты информации.

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

Шаг 3. Разработка программы и методики испытаний

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

Шаг 4. Сертификационные испытания

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

• оценку соответствия параметров и характеристик СЗИ требованиям по безопасности;
• проверку организации технической поддержки;
• проверку организации производства (при серийной схеме).

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

Шаг 5. Экспертное заключение органа по сертификации

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

Шаг 6. Выдача сертификата и внесение в реестр

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

Что изменилось в 2026 году: свежая редакция Приказа 55

Приказом ФСТЭК №9 от 20 января 2026 года в Положение внесены изменения: приказ зарегистрирован Минюстом России 20 апреля 2026 года, опубликован 23 апреля и вступил в силу 2 мая 2026 года. Редакция затронула несколько пунктов.

• Расширен перечень оснований для приостановки. Пункт 83 дополнен новым основанием: «непредставление сведений о внесении изменений в перечень заимствованных программных компонентов с открытым исходным кодом, входящих в состав средства защиты информации». Сам предельный срок приостановки — не более 90 календарных дней (п. 84) — в этой редакции не менялся: норма действовала и раньше, приказ № 9 её не переписывает.
• Уточнён состав документов для испытаний. Пункты 21, 28, 35, 37.2, 42, 43 и 52 в новой редакции детализируют требования к документации. В частности, в перечень документов к заявке и к материалам испытаний добавлен «перечень образов контейнеров, входящих в состав средства защиты информации» — прямой ответ регулятора на распространение контейнерных технологий в разработке ПО.
• Введены требования к формату документов. Новый пункт 52² устанавливает: документы представляются на бумажном носителе и в электронном виде, а часть документов — только в электронном. «В электронном виде должны быть представлены копии документов, идентичные подписанным (утвержденным) в бумажном виде документам».
• Уточнён порядок аннулирования решения о сертификации. Пункт 35 дополнен новым основанием: аннулирование происходит в том числе при «наличии в заключении органа по сертификации вывода о невозможности выдачи сертификата соответствия».

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

Заключение

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

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

Смежные темы: Приказы ФСТЭК и ФСБ № 117: в чём разница и Приказ ФСТЭК № 117: разбор изменений.

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

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

Что регулирует Приказ ФСТЭК № 55?

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

Чем приказ № 55 отличается от приказа № 76?

Приказ № 55 регулирует саму процедуру сертификации — кто и как её проводит. Приказ № 76 определяет уровни доверия — глубину проверки, от 1-го (для гостайны) до 6-го. Продукт сертифицируют по приказу № 55, а требования

Чем отличается Приказ 55 от Приказа 240?

Приказ 55 регулирует сертификацию готового продукта — средства защиты информации. Приказ 240 — сертификацию процесса безопасной разработки ПО, из которого этот продукт создаётся. Первый отвечает на вопрос «что получилось», второй — «как это делали». Сертификат по Приказу 240 даёт заявителю дополнительные права при сопровождении сертификата по Приказу 55 (п. 71.1 Положения).

Нужно ли переоформлять уже выданный сертификат после вступления в силу приказа № 9?

Нет. Приказ № 9 меняет требования к пакету документов для новых заявок и добавляет основание для приостановки сертификата при несообщении об изменении состава open-source компонентов — он не аннулирует уже выданные сертификаты. Срок их действия определяется условиями, указанными при выдаче.

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

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

Какие СЗИ подлежат обязательной сертификации ФСТЭК?

Обязательной сертификации подлежат средства защиты информации, применяемые в государственных информационных системах (ГИС), информационных системах персональных данных (ИСПДн), объектах критической информационной инфраструктуры (КИИ) и автоматизированных системах управления технологическими процессами (АСУ ТП). Обязанность защищать такие системы закреплена статьёй 19 Федерального закона № 152-ФЗ, Федеральным законом № 187-ФЗ «О безопасности КИИ» и Федеральным законом № 149-ФЗ «Об информации».

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

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

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

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

Пассворк 7.8: политики паролей

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

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

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

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

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

Теневой ИИ: как сотрудники сливают данные в нейросети

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

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

В 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-ФЗ. Первыми вышли отраслевые постановления по категорированию для атомной энергетики (№ 4 от 16.01.2026), банковской сферы и финрынка (№ 92 от 06.02.2026), науки (№ 246 от 07.03.2026) и ракетно-космической промышленности (№ 356 от 31.03.2026). Постановление Правительства № 402 от 13.04.2026 установило отраслевые особенности категорирования объектов КИИ в сфере связи — они вступили в силу с 01.09.2026. 27 июня 2026 года список пополнило постановление № 796 — для оборонной промышленности.

В мае 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 года

Действующие административные составы за нарушения требований безопасности КИИ сохраняются, и с 20 апреля 2026 года к ним добавился новый: за нарушение правил эксплуатации объекта КИИ или доступа к нему должностному лицу грозит штраф от 10 до 50 тыс. руб., компании — от 100 до 500 тыс. руб. (Федеральный закон от 09.04.2026 № 77-ФЗ).

Отдельные штрафы именно за несоблюдение сроков перехода ЗОКИИ на российское ПО по-прежнему находятся в стадии подготовки: с июня 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. Один из шести отраслевых актов 2026 года, реализующих полномочия Правительства по 58-ФЗ.
• Постановление Правительства РФ № 796 от 27.06.2026 — утверждает отраслевые особенности категорирования объектов КИИ в оборонной промышленности.
• Приказ ФСТЭК России № 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/Х, где зашифрованы порядковый номер, федеральный округ, сфера деятельности и тип объекта (ИС, АСУ или ИТКС). Сведения из реестра ежемесячно передаются государственным органам, уполномоченным на реализацию государственной политики в соответствующей сфере.

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

К сентябрю 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 — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Унификация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как создать надёжный пароль в 2026: новые требования, правила и примеры

73% российских компаний до сих пор пользуются паролем по умолчанию — притом что одна лишняя буква длины часто защищает больше, чем весь набор спецсимволов. Разбираем, что на этот счёт думают ФСТЭК, NIST и OWASP, и как быстро собрать пароль, который устроит всех.

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

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

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

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

Главное

• Сертификация ФСТЭК обязательна для защищаемых систем. СЗИ без сертификата нельзя легально применять в государственных информационных системах, информационных системах персональных данных и на значимых объектах КИИ.
• Сертифицируется конкретная версия продукта. Изменение кода или конфигурации требует повторного прохождения испытаний или инспекционного контроля.
• Уровень доверия определяет, в каких системах можно применять СЗИ. Шкала — от УД-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 год.

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

Приказ ФСТЭК № 55: сертификация СЗИ простыми словами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роли и группы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

США

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

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

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

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

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

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

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

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

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

Китай

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

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

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

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

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

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

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

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

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

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

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

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

Германия

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

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

Южная Корея

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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