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

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

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

Для кого расширенная версия Пассворка

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

• Для малого и среднего бизнеса — инструменты корпоративного уровня без сложной настройки. Гибкое управление правами, контролируемый доступ для внешних подрядчиков, отказоустойчивость. ИТ-специалисты экономят время на рутинных задачах, компания готова к масштабированию.
• Для крупного бизнеса и корпораций — гранулярная ролевая модель доступа, интеграция с AD/LDAP/SSO, делегирование управления по отделам без потери прозрачности. Масштабируемость для сотен и тысяч пользователей.
• Для государственных организаций — соблюдение требований регуляторов, детальный аудит всех действий с паролями, отказоустойчивость и репликация для непрерывной работы критически важных систем.
• Для ИТ-компаний — интеграция с CI/CD через сервисные аккаунты, безопасное хранение API-ключей и токенов, гибкое управление доступом для распределённых команд. Автоматизация DevOps-процессов без компромиссов в безопасности.

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

Принципиальные отличия от стандартной версии

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

• Корпоративная аутентификация и синхронизация — единый вход через SAML SSO, автоматическое сопоставление групп из службы каталогов с группами в Пассворке. Исключает ручное управление учётными записями и обеспечивает мгновенный отзыв доступа при блокировке или увольнении сотрудника.
• Гибкое администрирование — неограниченное количество настраиваемых типов сейфов с автоматическим назначением прав, разграничение полномочий администраторов через систему ролей.
• Масштабируемость и отказоустойчивость — настройка репликации для непрерывной работы даже при сбоях оборудования, неограниченное количество ярлыков для организации больших объёмов данных.
• Расширенная автоматизация — сервисные аккаунты для интеграции с CI/CD, системами мониторинга и внутренними инструментами. Доступ через API без создания полноценных пользовательских учётных записей.

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

Настраиваемые типы сейфов

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

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

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

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

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

Сравнение: до и после внедрения типов сейфов

Результат

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

Аутентификация через единый вход (SSO)

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

Преимущества

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

Результат

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

Сопоставление групп из LDAP с группами Пассворка

Пассворк синхронизирует пользователей и группы из Active Directory или любого LDAP-совместимого каталога. Автоматическая синхронизация исключает дублирование учётных записей и позволяет управлять доступом централизованно через привычные инструменты корпоративной инфраструктуры.

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

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

Сценарий применения

В компании 100+ сотрудников, текучесть кадров, несколько отделов. Вручную управлять учётными записями в каждой системе неэффективно и рискованно. Интеграция с AD даёт единую точку управления доступом — все изменения в оргструктуре автоматически отражаются в Пассворке.

Результат

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

Сравнение со стандартной версией

Гибкая ролевая модель и детальная настройка прав доступа

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

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

Сценарий использования

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

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

Сравнение: до и после внедрения системы ролей

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

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

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

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

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

Результат

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

Настройка репликации и отказоустойчивое решение

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

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

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

Результат

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

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

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

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

Сценарий использования

У компании есть общий пароль для тестовых серверов, которым пользуются три команды: DevOps, QA и тестировщики. Чтобы не создавать копии и не синхронизировать изменения вручную, администратор может добавить ярлыки на один исходный пароль в сейфах каждой команды.

Результат

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

Оптимизация бюджета

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

Подписку можно приобрести сразу на 2–3 и более лет по специальной цене. Организация получает доступ ко всем обновлениям и новым функциям в течение всего периода без дополнительных закупочных процедур. Это защищает от роста цен и избавляет от повторного прохождения тендеров и согласований.

Сценарии использования расширенной версии

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

ИТ-отдел крупной компании: централизация и порядок

Распределённая компания: управление доступом в филиалах

Банк: разделение обязанностей и принцип минимальных привилегий

Холдинг: изоляция доступа между юрлицами

DevOps и SRE: управление секретами в CI/CD

Следующий шаг: протестируйте расширенную версию

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

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

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

Готовы сделать первый шаг к централизованному управлению доступами? Протестируйте расширенную версию Пассворка в своей инфраструктуре без ограничений по функциональности и времени → passwork.ru

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

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

Расширенная версия включает все функции базовой и добавляет инструменты для корпоративного использования: интеграцию с Active Directory и LDAP, единый вход через SSO (SAML, OIDC), полнофункциональный API, сервисные аккаунты для автоматизации, расширенный журнал аудита, гибкую ролевую модель с типами сейфов и приоритетную поддержку. Базовая версия подходит для небольших команд, расширенная — для компаний с развитой ИТ-инфраструктурой и повышенными требованиями к безопасности.

Что такое сервисные аккаунты и зачем они нужны?

Сервисные аккаунты — специальный тип учётных записей для интеграций и автоматизации. Они работают через API без мастер-пароля, не имеют доступа к веб-интерфейсу, но могут получать пароли из Пассворка по настраиваемым правам. Это безопасный способ дать CI/CD-системам, скриптам, мониторингу и другим инструментам доступ к секретам без создания полноценных пользовательских учётных записей. Все действия сервисных аккаунтов детально логируются.

Что такое типы сейфов и зачем они нужны?

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

Можно ли установить Пассворк на собственный сервер?

Да, Пассворк поддерживает локальное развёртывание на физических или виртуальных серверах под управлением Linux или Windows Server. Можно установить в облаке или в полностью закрытом контуре без доступа в интернет. Это обеспечивает полный контроль над данными и соответствие требованиям ФЗ-152 и других регуляторов. Документация по установке доступна на сайте Пассворк.

Как работает интеграция с Active Directory?

Пассворк синхронизирует пользователей и группы из Active Directory или любого LDAP-совместимого каталога автоматически. Администратор настраивает подключение один раз — дальше система сама создаёт учётные записи, назначает пользователей в группы и обновляет данные при изменениях в AD. Если сотрудник уволен и его учётная запись деактивирована в AD, доступ к Пассворку блокируется автоматически, без участия администратора.

Что такое репликация и зачем она нужна?

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

Есть ли API у расширенной версии?

Да, полнофункциональный REST API для программного доступа к паролям есть в обеих версиях Пассворка. Через API можно получать секреты, создавать и редактировать записи, управлять доступом, работать с сейфами и журналом аудита. API используется для интеграции с CI/CD-системами, скриптами, внутренними сервисами. Для автоматизации рекомендуется использовать сервисные аккаунты — специальный тип учётных записей с аутентификацией через токен.

Есть ли пробный период у Пассворка?

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

Можно ли купить подписку на несколько лет?

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

Криптография в России: ГОСТ-алгоритмы, СКЗИ и требования в 2026 году | Пассворк

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

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

Главные киберугрозы апреля 2026: базовые ошибки и миллионы потерь

Взлом Vercel на $2 млн через AI-ассистента, утечка данных Vimeo и Rockstar Games через скомпрометированного подрядчика Anodot, фишинг с официального домена Apple — рассмотрим механику атак через цепочку поставок и покажем, как базовые ошибки в управлении доступом приводят к критическим инцидентам.

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Атака на цепочку поставок: взлом Bitwarden CLI, Shai-Hulud и выводы

Зачем атаковать защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний? Разбираем три резонансных инцидента 2026 года: компрометацию Bitwarden CLI через GitHub Actions, вредонос в Axios и утечку OAuth-токенов через Vercel. Что их объединяет и как защитить CI/CD.

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

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

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

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

28,65 миллиона секретов утекли в публичные репозитории GitHub за один год. API-ключи, токены доступа, пароли к базам данных — всё в открытом доступе. Рост на 34% год к году, но это лишь видимая часть проблемы.

64% секретов, обнаруженных в 2022 году, всё ещё действуют в 2026-м — спустя четыре года после утечки. Каждый день в публичные репозитории попадает 78 000 новых учётных данных. Большинство останутся действующими годами. Некоторые уже используются атакующими прямо сейчас.

GitGuardian просканировали 1,94 миллиарда коммитов и зафиксировал критическую закономерность: утечки растут быстрее числа участников/разработчиков (+152% против +98% с 2021 года), а новые векторы (ИИ-ассистенты, MCP-конфигурации, внутренние репозитории) генерируют уязвимости со скоростью, которую команды не успевают обрабатывать. Обнаружение перестало работать как мера защиты.

В этом материале — полный разбор отчёта The State of Secrets Sprawl 2026, статистика по типам утечек, реальные кейсы атак и пошаговая стратегия защиты.

Главное

• 28,65 млн новых утечек секретов за год — рост на 34%. Утечки растут быстрее числа разработчиков: +152% против +98% с 2021 года. 64% секретов 2022 года всё ещё действуют в 2026-м — спустя четыре года.
• ИИ-инструменты ускоряют утечки в 5 раз. Утечки секретов ИИ-сервисов выросли на 81,5%. Коммиты с участием Claude Code содержали секреты в два раза чаще обычных (3,2% против 1,5%).
• 24 000 секретов в конфигурациях протокола контекста модели (MCP) — новый вектор утечек. 8,8% действующие. Большая часть официальных гайдов нормализует хардкод секретов в конфигурациях.
• Внутренние репозитории — в 6 раз опаснее публичных. 32,2% внутренних репозиториев содержат секреты против 5,6% публичных. Приватность — не мера защиты.
• 28% утечек происходят вне кода — в Slack, Jira, Confluence. Они на 13% чаще критические (56,7% против 43,7%). Сканирование только репозиториев покрывает ~72% поверхности атаки.
• 80 000 секретов в открытых экземплярах GitLab и Docker, 10 000 действующих. Частота утечек из собственной инфраструктуры в 3–4 раза выше, чем из публичного GitHub.
• Рабочие станции — хранилища секретов. На 6 943 скомпрометированных машинах найдено 33 185 уникальных секретов. Каждый действующий секрет копируется в среднем 8 раз.
• 46% критических секретов пропускаются при подходе «проверяем только то, что можем проверить». Универсальные секреты (пароли, ключи, токены) составляют 35% критических инцидентов, но игнорируются из-за невозможности автопроверки.
• Устранение отстаёт от обнаружения. Секреты остаются действующими годами, потому что ротация — комплексный процесс, который большинство организаций не автоматизировали.

Что такое расползание секретов и почему это критично

Расползание секретов (распространение секретов, secrets sprawl) — неконтролируемое распространение учётных данных (секретов) в кодовой базе, конфигурационных файлах, чатах и других системах организации.

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

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

Масштаб проблемы: в 2025 году GitGuardian обнаружил 28,65 миллиона новых секретов в публичных коммитах GitHub — это утечки за один год, а не накопленный итог. С 2021 года объём вырос с 11 до 29 миллионов, увеличившись в 2,6 раза за пять лет. При этом число активных разработчиков за тот же период выросло лишь вдвое — утечки опережают рост экосистемы на 30%.

Секреты в публичных коммитах GitHub (2021–2025)

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

1. Скорость роста опережает рост числа участников. С 2021 года утечки секретов выросли на 152%, в то время как число разработчиков увеличилось на 98%. Проблема усугубляется непропорционально.
2. Секреты остаются рабочими годами. 64% секретов, обнаруженных и подтверждённых как валидные в 2022 году, всё ещё не отозваны в 2026-м — спустя четыре года после утечки.
3. Каждый секрет — потенциальная точка входа. Один утёкший API-ключ может предоставить доступ к продуктовой базе данных, CI/CD или облачной инфраструктуре. Для атакующего достаточно одного рабочего секрета.

Главные цифры 2025 года: масштаб проблемы

Данные отчёта GitGuardian за 2025 год показывают устойчивый рост по всем ключевым метрикам:

Рост числа утечек (+33,9%) опережает рост числа разработчиков (+33,2%), но существенно отстаёт от роста объёма кода (+42,7%). Это указывает на то, что объём кода — главный драйвер утечек, а не просто увеличение числа людей, пишущих код.

С 2019 года число активных участников на GitHub утроилось (с 7,6 млн до 22,8 млн), а объём публичных коммитов вырос почти в четыре раза (с 514 млн до 1,94 млрд). При этом количество обнаруженных секретов росло ещё быстрее: с 2021 по 2025 год утечки увеличились на 152%, в то время как активность — на 98%.

Как ИИ ускоряет утечки секретов

2025 год стал переломным для индустрии: ИИ-инструменты для разработки перешли из категории экспериментов в повседневную практику. По данным GitHub Octoverse 2025, 80% новичков начинают использовать GitHub Copilot (ИИ-ассистент для написания кода) в первую же неделю. Это изменило не только скорость написания кода, но и природу утечек секретов.

ИИ-стек как новая поверхность атаки

По данным GitGuardian 1,275 миллиона секретов, связанных с ИИ-сервисами, было обнаружено в 2025 году — рост на 81,5% по сравнению с 2024-м. Это самый быстрорастущий сегмент среди всех типов утечек.

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

Критическая закономерность: инфраструктура вокруг больших языковых моделей LLM (системы контекстного поиска, управление запросами, векторные базы данных, мониторинг) «течёт» в пять раз быстрее, чем ключи от самих моделей (OpenAI, Anthropic, Google AI).

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

• Интерфейсы поиска (Retrieval APIs) для подачи контекста моделям (Brave Search +1 255%, Firecrawl +796%, Perplexity +657%)
• Оркестрация для многошаговых ИИ-процессов (LangChain +108%)
• Мониторинг и эксперименты (Weights & Biases +114%)
• Векторизация и поиск (Jina +334%)
• Базы данных для хранения векторов и состояний (Supabase +992%)

Каждый слой добавляет новые учётные данные. Каждый API-ключ — новый вектор утечки.

Пример: Supabase, популярная база данных для ИИ-проектов, показала рост утечек на 992% год к году и вошла в топ-20 самых «текущих» сервисов с 248 600+ обнаруженными секретами. В 2024 году рост составлял 97% — в 2025-м он ускорился в десять раз.

Claude Code: кейс-стади ИИ-ассистента

Anthropic Claude Code — ИИ-ассистент, который может не только предлагать код, но и напрямую создавать коммиты с атрибуцией через механизм «Co-Authored-By». Это позволило GitGuardian впервые точно измерить влияние конкретного ИИ-инструмента на утечки секретов.

Ключевые данные:

• Рост использования: с 22 коммитов в январе 2025 до 2,16 миллиона в декабре (×98 000)
• Доля в общем объёме: 0,4% всех публичных коммитов
• Доля в утечках: 0,9% всех обнаруженных секретов
• Частота утечек: коммиты с участием Claude Code содержали секрет в 3,2% случаев против 1,5% для обычных коммитов — в два раза чаще

Динамика в течение года: первая половина 2025 года показала наиболее выраженный всплеск. В августе частота утечек достигла пика — 31 секрет на 1 000 коммитов, что в 2,4 раза выше базового уровня. После выхода Claude Sonnet 4.5 в конце сентября показатель начал снижаться и к декабрю достиг 13 секретов на 1 000 коммитов — практически сравнявшись с уровнем обычной разработки.

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

Размер коммитов: с апреля 2025 года коммиты, созданные с помощью Claude Code, в среднем содержали в два раза больше строк кода, чем обычные коммиты. Большие коммиты означают больше возможностей для утечки секретов в одном review и одном merge. К концу года разница сгладилась, что также указывает на улучшение работы модели.

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

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

MCP-конфигурации: 24 000 секретов в первый год

В начале 2025 года Model Context Protocol (MCP) стал де-факто стандартом интеграции LLM с корпоративными системами. MCP — открытый протокол для подключения больших языковых моделей к внешним инструментам, базам данных и API. По мере того как сторонние сервисы спешили предоставить доступ через этот новый канал, конфигурационные файлы MCP быстро превратились в точку высокой концентрации захардкоженных секретов.

Масштаб проблемы:

• 24 008 уникальных секретов обнаружено в MCP-конфигурациях за 2025 год
• 2 117 из них (8,8%) оставались действующими на момент обнаружения
• Пик утечек пришёлся на август 2025 — 4 209 секретов за месяц

Топ-5 типов валидных секретов в MCP-конфигурациях:

Официальные гайды — часть проблемы: документация популярных MCP-серверов часто нормализует размещение учётных данных непосредственно в конфигурационных файлах. Примеры из руководств по быстрому старту показывают API-ключи, передаваемые как аргументы командной строки внутри конфигурации MCP-сервера (например, --figma-api-key=YOUR-KEY), или хранящиеся в поле env внутри того же JSON-файла, который попадает в систему контроля версий.

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

Риски MCP-секретов:

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

Лучшие практики для MCP-конфигураций:

• Никогда не храните секреты в конфигурационных файлах MCP. Используйте переменные окружения, управляемые через выделенный менеджер секретов, а не встроенные значения в JSON или аргументах командной строки.
• Клиенты, а не серверы, должны владеть секретами. MCP-серверы должны запрашивать учётные данные у клиентов во время выполнения, а не встраивать их в серверную конфигурацию.
• Исключите конфигурационные файлы из системы контроля версий. Добавьте директории с конфигурацией MCP в .gitignore и трактуйте их как конфиденциальные артефакты.
• Используйте MCP-серверы только по защищённым каналам. Убедитесь, что удалённые серверы доступны через TLS.
• Сканируйте перед отправкой в репозиторий. Инструменты вроде ggshield могут обнаруживать секреты в конфигурациях MCP до того, как они попадут в систему контроля версий.
• Обязательное участие человека для критичных действий. Требуйте ручного подтверждения перед любым действием MCP, затрагивающим производственные системы, базы данных или конвейеры развёртывания.

Внутренние системы: слепая зона безопасности

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

Внутренние репозитории: в 6 раз больше утечек, чем в публичных

32,2% внутренних репозиториев содержат хотя бы один захардкоженный секрет против 5,6% публичных.

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

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

Что хранится во внутренних репозиториях

Внутренние репозитории, как правило, содержат самые критичные учётные данные:

• CI/CD-токены для интеграций и развёртывания
• Ключи облачных платформ с широкими привилегиями
• Учётные данные баз данных для продуктовых сред
• Токены внутренних инструментов для мониторинга, журналирования, управления секретами

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

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

Утечки за пределами кода: Slack, Jira, Confluence

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

28% инцидентов в 2025 году произошли полностью вне кода, в том, что GitGuardian называет «Other Data Sources» (другие источники данных, ODS). Большинство инцидентов (68%) по-прежнему приходится на код в системах контроля версий (таких как Git). Однако пересечение секретов, найденных и в системах контроля версий, и в других источниках данных, удивительно мало: всего 4%.

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

Сканирование только кода упустит значимую часть утечек. Секреты из других источников данных (ODS) опаснее: секреты, переданные через Slack, Jira, Confluence и подобные инструменты, чаще получают рейтинг критической или высокой опасности по сравнению с секретами, найденными только в коде.

Распределение по уровню опасности (2025):

Секреты из ODS на 13 процентных пунктов чаще классифицируются как критические (56,7% против 43,7%).

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

GitLab и Docker: 80 000 секретов в открытом доступе

Исследование GitGuardian в 2025 году выявило, что тысячи развёрнутых на собственной инфраструктуре экземпляров GitLab и реестров Docker оставались доступными в интернете без надлежащей аутентификации. Эти непреднамеренно публично открытые ресурсы были проанализированы на предмет секретов, что привело к обнаружению 80 000 учётных данных. 10 000 из них оказались действующими — то есть немедленно пригодными для использования злоумышленниками.

Распределение:

GitLab-репозитории содержали больший общий объём секретов (57 000), но меньший процент валидных (12%). Напротив, Docker-образы содержали меньше секретов в абсолютных числах (23 000), но 15% из них оказались рабочими.

Находки в Docker особенно тревожны, поскольку, в отличие от экземпляров GitLab, образы Docker предназначены для распространения и обычно передаются между множеством кластеров и узлов, что усиливает опасность.

Близость к продуктовой среде = выше вероятность действующего секрета

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

Примеры по типам секретов:

Разрыв особенно широк для секретов систем контроля версий: 40% действующих в контейнерах Docker против всего 2% в GitLab — и для учётных данных хранилищ данных: 32% против 4% соответственно.

Эффект вложенной экспозиции

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

Дополнительные находки

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

• Ссылки на внутренние узлы баз данных и закрытые инфраструктурные шаблоны
• Уведомления о конфиденциальности и защите персональных данных внутри кода
• Значительный объём персональных данных, включая более 300 000 адресов электронной почты, из которых 2 000 имели государственные домены (.gov)

Частота утечек

GitGuardian обнаружили секреты в 12% просканированных GitLab-репозиториев и 18% просканированных Docker-образов. Эти проценты отражают уровень экспозиции на уровне отдельных активов внутри уже обнаруженных экземпляров GitLab и реестров Docker, развёрнутых на собственной инфраструктуре.

Примерно 18% Docker-реестров стали недоступными всего через несколько недель после обнаружения сканированием. Однако в нескольких случаях учётные данные, которые были открыты, оставались валидными даже после того, как публичный доступ был отозван.

При объединении с другими находками это показывает, что частота утечек из Docker и GitLab, развёрнутых на собственной инфраструктуре, в 3–4 раза выше по сравнению с публичными хранилищами GitHub. Это означает: захардкоженные секреты в закрытых ресурсах — это недооценённый риск безопасности для слишком многих команд.

64% секретов 2022 года до сих пор действуют

Каждый год GitGuardian анализирует новые данные об утечках, но также повторно проверяет предыдущие находки, чтобы выявить закономерности во времени. В отчёте State of Secrets Sprawl 2025 было показано, что почти 70% учётных данных, подтверждённых как действующие в 2022 году, всё ещё оставались действующими по состоянию на январь 2025 года.

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

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

Почему секреты не ротируются

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

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

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

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

Инфраструктура разработки: новый вектор

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

Кейс Shai-Hulud: атака через компрометацию npm-пакетов

В августе 2025 года злоумышленники внедрили вредоносный код в популярные npm-пакеты. Код выполнялся автоматически при установке и систематически сканировал машины разработчиков:

• Собирал файлы окружения (.env, .bashrc, .zshrc)
• Извлекал конфигурационные файлы приложений
• Сканировал кэши сред разработки и результаты сборок
• Отправлял найденные секреты на управляющий сервер

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

Статистика компрометации

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

Распределение секретов

• 44% скомпрометированных машин содержали более 10 секретов
• 5% машин несли более 100 секретов

Типы обнаруженных учётных данных

Токены GitHub доминировали в проверенном наборе:

• 581 персональный токен доступа
• 386 токен OAuth
• 104 детализированный токен доступа
• 101 токен GitLab

Каждый из этих токенов обеспечивает доступ к репозиториям, позволяет манипулировать CI/CD-процессами или открывает путь для бокового перемещения по цепочке поставок.

CI/CD-агенты как точка концентрации риска

59% скомпрометированных машин оказались CI/CD-агентами, а не личными рабочими станциями. Это означает, что атака затронула не только индивидуальных разработчиков, но и общую инфраструктуру сборки — узлы с повышенными привилегиями и доступом к продуктовым средам.

Реальная плотность секретов выше

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

Что делать: от обнаружения секретов к управлению

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

Данные показывают, что разрыв расширяется:

• Коммиты, созданные совместно с Claude Code, утекают в два раза чаще базового уровня
• Утечки инфраструктуры больших языковых моделей растут в пять раз быстрее, чем у основных поставщиков
• Только конфигурации протокола контекста модели обнажили более 24 000 секретов в первый год

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

1. Какие секреты существуют в вашей среде?
2. Кто ими владеет?
3. К чему они имеют доступ?

Если вы не можете ответить на все три, ваше внедрение искусственного интеллекта опережает вашу позицию безопасности.

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

1. Централизовать хранение секретов. Единый источник правды. Исключить «самодельные» хранения. Когда команды могут надёжно извлекать секреты из одного источника, они перестают изобретать собственные фрагментированные стратегии хранения — основной драйвер распространения секретов.
2. Автоматизировать ротацию. Сократить окно эксплуатации. Если секрет должен существовать, он не должен жить вечно. Регулярная замена действующих секретов сокращает окно атаки и заставляет команды трактовать учётные данные как актив с жизненным циклом, а не как разовую настройку.
3. Сделать безопасный путь удобнее захардкоженных ключей. Устранить файлы окружения и скопированные токены. Разработчики будут продолжать встраивать секреты в код, потому что это работает и позволяет выпустить функциональность. Единственный устойчивый подход — сделать создание, хранение и вызов действующих секретов проще и привлекательнее, чем захардкодить ключи.
4. Сканировать на рабочей станции (до коммита). Инструменты вроде ggshield и расширения для сред разработки не допускают секрет до репозитория. Раннее сканирование предотвращает инциденты. Современные инструменты помогают командам остановить утечку до того, как секрет попадёт в репозиторий навсегда.
5. Распространить мониторинг за пределы кода. Slack, Jira, Confluence, реестры Docker. 28% инцидентов происходят вне кода, и они на 13% чаще критические. Сканирование только репозиториев покрывает ~72% поверхности.
6. Внедрить приоритизацию на основе рисков. Обогащение контекстом и оценка рисков вместо подхода «только проверка». 46% критических секретов пропускаются при подходе «только проверка». Необходимо понимать, что каждый секрет разблокирует, оценивать привилегии и область действия, обрабатывать длинный хвост и приоритизировать на основе фактического влияния на бизнес.

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

Ключевые выводы

2025 год стал переломным для разработки ПО. ИИ-ассистенты превратили разработку из узкопрофессионального занятия в массовую практику менее чем за 12 месяцев. Стек инструментов ИИ с десятками новых сервисов и токенов стал нормой. Это привело к рекордному числу утечек секретов — 28,65 миллиона на одном только публичном GitHub, рост на 34% год к году.

Пять главных выводов

1. ИИ ускоряет расползание секретов. Рост утечек секретов ИИ на 81,5%, коммиты Claude Code с удвоенной частотой утечек, более 24 000 секретов в конфигурациях — всё это симптомы одной проблемы: команды создают новые токены, ключи и учётные записи сервисов быстрее, чем успевают выстроить процессы управления ими. Модели улучшаются, но ответственность за безопасность остаётся на разработчике и организационных процессах.
2. Внутренние системы — главная зона риска. Внутренние репозитории в шесть раз чаще содержат секреты, чем публичные. 28% инцидентов происходят вне кода и они на 13% чаще критические. Собственные экземпляры GitLab и Docker показывают частоту утечек в 3–4 раза выше, чем публичный GitHub. Приватность — не мера защиты.
3. Устранение отстаёт от обнаружения. 64% секретов 2022 года всё ещё действуют в 2026-м. Обнаружение бесполезно без замкнутого цикла отзыва и ротации. Секреты встроены в системы сборки, переменные непрерывной интеграции, контейнеры. Их ротация — комплексный процесс, который большинство организаций не автоматизировали.
4. Подход «только проверка» — ложная безопасность. 46% критических секретов пропускаются при подходе «только проверка». Универсальные секреты (пароли, приватные ключи, пользовательские токены) составляют 35% критических инцидентов, но массово игнорируются. Необходим переход к приоритизации на основе рисков: обогащение контекстом, оценка рисков и полное покрытие.
5. Переход к управлению машинными идентичностями — стратегическая необходимость. Цель — не только находить утёкшие строки, но непрерывно доказывать, какие машинные идентичности существуют, кто ими владеет и к чему они имеют доступ. Это начинается с централизации секретов, автоматизации ротации, улучшения опыта разработчиков.

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

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

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

Что такое захардкоженные секреты и почему они опасны?

Захардкоженные секреты — это учётные данные (API-ключи, токены, пароли, приватные ключи), встроенные непосредственно в исходный код или конфигурационные файлы. Когда такой код попадает в систему контроля версий, секрет становится частью истории репозитория навсегда — даже после удаления из текущей версии. Один утёкший секрет может открыть доступ к продуктовой базе данных, облачной инфраструктуре или CI/CD.

Почему утечки секретов растут быстрее числа разработчиков?

С 2021 года утечки секретов выросли на 152%, в то время как число разработчиков увеличилось на 98%. Главный драйвер — рост объёма кода (+42,7% за год) и количества интегрируемых сервисов. ИИ-инструменты ускоряют разработку, но каждый новый сервис требует новых токенов и ключей. Команды создают учётные данные быстрее, чем успевают выстроить процессы управления ими.

Как ИИ-ассистенты влияют на утечки секретов?

Коммиты с участием Claude Code содержали секреты в 3,2% случаев против 1,5% для обычных коммитов — в два раза чаще. Утечки секретов ИИ-сервисов выросли на 81,5% за год. Инфраструктура вокруг больших языковых моделей (системы поиска, векторные базы, оркестрация) «течёт» в пять раз быстрее, чем ключи от самих моделей. Проблема не в моделях, а в скорости создания новых интеграций без зрелых практик безопасности.

Почему внутренние репозитории опаснее публичных?

32,2% внутренних репозиториев содержат захардкоженные секреты против 5,6% публичных — в шесть раз больше. Команды менее осторожны внутри закрытого периметра, предполагая, что приватность защищает. Но внутренние репозитории содержат самые критичные учётные данные: CI/CD-токены, ключи облачных платформ с широкими привилегиями, доступы к базам данных. Один утёкший секрет становится быстрым путём для горизонтального перемещения по инфраструктуре.

Почему секреты остаются действующими годами после обнаружения?

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

Что такое подход «только проверка» и почему он не работает?

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

Где ещё утекают секреты, кроме кода?

28% инцидентов в 2025 году произошли вне кода — в Slack, Jira, Confluence. Секреты из этих источников на 13% чаще получают рейтинг критической опасности (56,7% против 43,7% для кода). Учётные данные передаются в чатах во время срочного устранения неполадок или реагирования на инциденты. Сканирование только репозиториев покрывает ~72% поверхности атаки — четверть уязвимостей остаётся невидимой.

Что такое управление машинными идентичностями (NHI)?

Машинные идентичности (Non-Human Identities, NHI) — это любые механизмы аутентификации для автоматических систем: API-токены, ключи доступа, учётные записи сервисов, сертификаты. С развитием ИИ-разработки их количество взрывообразно растёт. Управление NHI означает непрерывно доказывать, какие машинные идентичности существуют, кто ими владеет и к чему они имеют доступ. Это начинается с централизации секретов, автоматизации ротации и постепенного перехода к краткосрочным учётным данным на основе идентичности.

Как защитить конфигурации протокола контекста модели (MCP)?

За 2025 год в MCP-конфигурациях обнаружено 24 008 секретов, 8,8% действующих. Лучшие практики: никогда не храните секреты в конфигурационных файлах — используйте переменные окружения через менеджер секретов; клиенты, а не серверы, должны владеть секретами; исключите конфигурационные файлы из системы контроля версий; сканируйте перед отправкой в репозиторий; требуйте ручного подтверждения перед действиями MCP, затрагивающими продуктовые системы.

С чего начать защиту от утечек секретов?

Первый шаг — централизовать хранение секретов в едином защищённом хранилище. Это исключает «самодельные» стратегии хранения — основной драйвер распространения секретов. Затем: автоматизируйте ротацию критичных учётных данных; внедрите сканирование на рабочих станциях до коммита; распространите мониторинг на Slack, Jira, Confluence, Docker-реестры; перейдите от подхода «только проверка» к приоритизации на основе рисков; начните миграцию на аутентификацию на основе идентичности для машинных идентичностей.

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

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

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

Атака на цепочку поставок: взлом Bitwarden CLI, Shai-Hulud и выводы

Зачем атаковать защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний? Разбираем три резонансных инцидента 2026 года: компрометацию Bitwarden CLI через GitHub Actions, вредонос в Axios и утечку OAuth-токенов через Vercel. Что их объединяет и как защитить CI/CD.

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

Главные киберугрозы апреля 2026: базовые ошибки и миллионы потерь

Взлом Vercel на $2 млн через AI-ассистента, утечка данных Vimeo и Rockstar Games через скомпрометированного подрядчика Anodot, фишинг с официального домена Apple — рассмотрим механику атак через цепочку поставок и покажем, как базовые ошибки в управлении доступом приводят к критическим инцидентам.

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

18 апреля на ВТБ Арене в Москве прошёл один из крупнейших бизнес-форумов года — АМОКОНФ. Более 60 000 участников собрались, чтобы услышать ведущих спикеров, обсудить тренды в продажах и автоматизации, и найти инструменты для масштабирования своего бизнеса. Пассворк выступил партнёром форума — не просто как участник, а как компания, которая помогает бизнесу расти безопасно в условиях растущей сложности инфраструктуры.

О конференции: масштаб и формат

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

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

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

Центральной темой АМОКОНФ стал искусственный интеллект как инструмент упрощения рутины и масштабирования. Спикеры обсуждали ключевые вызовы:

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

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

Почему Пассворк на АМОКОНФ

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

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

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

Роль Пассворка в экосистеме цифровой трансформации

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

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

• Централизованное управление доступами — все пароли, API-ключи, токены и сертификаты в одном месте
• Полный контроль и аудит — администратор видит все действия, все изменения, всю историю
• Интеграция с инфраструктурой — поддержка AD/LDAP, SSO, SIEM и других систем
• Быстрое развёртывание — решение работает как на собственных серверах, так и в облаке

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

Итоги: безопасность как часть трансформации

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

Компании, которые сейчас инвестируют в управление доступами, получают два конкретных преимущества:

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

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

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

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

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

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

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

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

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

Атака на цепочку поставок: взлом Bitwarden CLI, Shai-Hulud и выводы

Зачем атаковать защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний? Разбираем три резонансных инцидента 2026 года: компрометацию Bitwarden CLI через GitHub Actions, вредонос в Axios и утечку OAuth-токенов через Vercel. Что их объединяет и как защитить CI/CD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы собрали самые значимые инциденты месяца с разбором того, что пошло не так и как этого можно было избежать.

Главная угроза апреля

Атаки через цепочку поставок стали основным вектором компрометации в апреле. Злоумышленники компрометируют доверенных подрядчиков и через них получают доступ к инфраструктуре жертв. Взлом аналитического сервиса Anodot открыл доступ к данным Vimeo и Rockstar Games, скомпрометированный AI-инструмент Context.ai привёл к утечке на $2 млн в Vercel, а «обновление для 1С» от имени интегратора уничтожило инфраструктуру организации за две недели.

Взлом Vercel на $2 млн: как AI-ассистент слил продуктовые ключи

В апреле 2026 года Vercel подтвердили серьёзный инцидент безопасности. Злоумышленники получили несанкционированный доступ к внутренним системам компании через скомпрометированный AI-инструмент Context.ai, который использовал один из сотрудников.

«Наше расследование показало, что инцидент произошёл из-за небольшого стороннего AI-инструмента, чьё OAuth-приложение для Google Workspace стало объектом масштабной компрометации, потенциально затронувшей сотни его пользователей в различных организациях» — официальное заявление Vercel

Vercel — облачная платформа для хостинга и развёртывания веб-приложений, созданная разработчиками фреймворка Next.js. Компания обслуживает тысячи компаний по всему миру, предоставляя инфраструктуру для автоматического развёртывания сайтов с глобальной CDN.

Механика атаки

Атака развивалась по классической схеме каскадной компрометации. Сотрудник Vercel подключил AI Office Suite от Context.ai к своему корпоративному аккаунту Google Workspace, предоставив приложению полные права: доступ к почте, диску и другим корпоративным данным. Когда Context.ai была взломана, злоумышленники получили контроль над OAuth-токеном этого сотрудника и через него — доступ к внутренним системам Vercel.

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

Масштаб и последствия

Группировка ShinyHunters взяла на себя ответственность за атаку, выставив украденные данные на продажу за $2 млн. Vercel описала злоумышленников как «высокоорганизованных», отметив их «операционную скорость и детальное понимание систем Vercel».

Компания сообщила, что скомпрометирована ограниченная группа клиентов, с которыми связались напрямую, рекомендовав немедленно ротировать учётные данные. Vercel продолжает расследование с привлечением Mandiant (подразделение Google Cloud по кибербезопасности) и других специалистов, а также уведомила правоохранительные органы.

Цепочка компрометации

Расследование Hudson Rock выявило, что корни атаки уходят ещё глубже. В феврале 2026 года устройство сотрудника Context.ai было скомпрометировано инфостилером Lumma Stealer — вредоносом, извлекающим сохранённые пароли, токены и cookies из браузеров. Вероятно, именно через эту компрометацию злоумышленники получили первоначальный доступ к инфраструктуре Context.ai, а затем использовали OAuth-токены клиентов сервиса для атак на их компании.

«Vercel не является клиентом Context, но как минимум один сотрудник Vercel зарегистрировался в AI Office Suite, используя корпоративный аккаунт, и предоставил права "Allow All"», — сообщение Context.ai.

Что пошло не так

Инцидент демонстрирует несколько критических проблем в управлении доступом:

• Широкие права для AI-инструментов. OAuth-токен с правами «Allow All» дал AI-ассистенту полный доступ к корпоративному Google Workspace, включая почту с потенциально чувствительными данными.
• Отсутствие контроля подключаемых приложений. Сотрудник самостоятельно подключил стороннее приложение к корпоративному аккаунту без согласования с отделом безопасности.
• Каскадная компрометация. Взлом одного звена (Context.ai) автоматически скомпрометировал всех, кто предоставил сервису широкие права доступа.
• Инфостилер как точка входа. Заражение Context.ai инфостилером Lumma в феврале стало первым звеном в цепи, приведшей к взлому Vercel в апреле.

Выводы для бизнеса

Инцидент с Vercel показывает, как AI-инструменты становятся новым вектором атак на корпоративную инфраструктуру. Сотрудники подключают «умных помощников» для повышения продуктивности, не осознавая, что предоставляют им доступ к критичным корпоративным данным. Когда такой инструмент компрометируется, злоумышленники автоматически получают доступ ко всем подключённым аккаунтам.

Утечка данных Vimeo: последствия взлома Anodot

Группировка ShinyHunters взломала аналитический сервис Anodot, специализирующийся на обнаружении аномалий в данных. Через скомпрометированного подрядчика злоумышленники получили доступ к данным десятков крупных клиентов, включая видеоплатформу Vimeo.

«Мы установили, что в результате взлома Anodot злоумышленник получил доступ к определённым данным пользователей и клиентов Vimeo. Наши предварительные данные показывают, что скомпрометированные базы данных в основном содержат технические данные, названия видео и метаданные, а в некоторых случаях — адреса электронной почты клиентов», — официальное заявление Vimeo (27 апреля, 2026)

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

Угрозы и требования

ShinyHunters не ограничились кражей данных. Группировка потребовала выкуп от Vimeo, угрожая опубликовать украденную информацию к 30 апреля 2026 года. Помимо угроз публикации, злоумышленники предупредили, что платформа должна ожидать «ряд неприятных цифровых проблем» — вероятно, намекая на DDoS-атаки или другие деструктивные действия.

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

Помимо Vimeo, в сети появились упоминания о компрометации данных Rockstar Games из облака Snowflake.

«Мы можем подтвердить, что ограниченный объём несущественной корпоративной информации был получен в результате утечки данных у стороннего поставщика», — официальное сообщение Rockstar Games

Что пошло не так

Инцидент демонстрирует классические проблемы безопасности цепочки поставок:

• Широкие права доступа подрядчика. Anodot имела токены для доступа к облачным хранилищам клиентов (Snowflake, BigQuery) без достаточной сегментации и ограничения привилегий.
• Отсутствие мониторинга доступа подрядчиков. Компании не отслеживали, какие данные и когда запрашивает Anodot, что позволило злоумышленникам незаметно извлекать информацию.
• Хранение токенов аутентификации. Компрометация Anodot автоматически скомпрометировала всех клиентов, чьи токены хранились в системах подрядчика.
• Недостаточная сегментация данных. Один токен давал доступ к множеству баз данных без дополнительной аутентификации или ограничений.

Выводы для бизнеса

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

Практические рекомендации

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

Фишинг с официального адреса Apple

В апреле пользователи Apple начали получать подозрительные уведомления безопасности, которые выглядели абсолютно легитимно. Причина: хакеры научились эксплуатировать систему уведомлений Apple, отправляя фишинговые письма с официального адреса appleid@id.apple.com, которые проходят все проверки подлинности и обходят спам-фильтры.

Письма выглядят как стандартные уведомления безопасности Apple о том, что информация в учётной записи была обновлена. Однако внутри сообщения скрывается фишинговая приманка: пользователю сообщают, что он якобы купил iPhone за $899 через PayPal, и предлагают позвонить по указанному номеру для отмены транзакции.

Механика атаки

Атака эксплуатирует автоматическую систему уведомлений Apple.

• Шаг 1: Подготовка. Злоумышленник регистрирует новый аккаунт Apple и в поля «Имя» и «Фамилия» вместо реального имени вписывает фишинговый текст. Имя — 889 USD IPhone Purchase Via, фамилия — Pay-Pal to Cancel [номер телефона].

• Шаг 2: Триггер уведомления. Злоумышленник изменяет адрес доставки в настройках своего аккаунта. Apple автоматически отправляет уведомление безопасности на имейл, привязанный к этому аккаунту.
• Шаг 3: Внедрение фишинга. Apple формирует уведомление по шаблону: «Уважаемый [Имя] [Фамилия], следующие изменения были внесены в вашу учётную запись...»
• Шаг 4: Массовая рассылка. Злоумышленник настраивает переадресацию или использует список рассылки, чтобы это письмо было отправлено тысячам жертв. Поскольку письмо реально отправлено серверами Apple, оно проходит все проверки подлинности.

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

Что пошло не так

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

Реакция Apple

На момент публикации (5 мая 2026 года) Apple не предоставила официального комментария по поводу этого инцидента и не подтвердила, что уязвимость в системе уведомлений была устранена. Эксплуатация механизма отправки фишинговых писем через легитимную инфраструктуру Apple остаётся возможной.

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

Атака на цепочку поставок: взлом Bitwarden CLI через npm

22 апреля 2026 года в npm-репозиторий был загружен вредоносный пакет @bitwarden/cli версии 2026.4.0, выдающий себя за официальный инструмент командной строки менеджера паролей Bitwarden. Пакет был скачан 334 раза до момента обнаружения — у легитимной версии свыше 250 000 скачиваний в месяц.

«Команда безопасности Bitwarden выявила и локализовала вредоносный пакет, который был распространён через канал доставки npm для @bitwarden/cli@2026.4.0 с 17:57 до 19:30 (по восточному времени) 22 апреля 2026 года и связан с более широким инцидентом в цепочке поставок Checkmarx», — официальное заявление Bitwarden

Атака является частью масштабной кампании, активной с сентября 2025 года и резко эскалировавшей в 2026-м. Злоумышленники компрометируют npm-пакеты, Docker Hub образы, GitHub Actions и расширения VS Code.

Вредоносный код получил кодовое имя «Shai-Hulud: The Third Coming» — строка встроена непосредственно в пакет, что указывает на связь с предыдущими волнами атак под этим названием.

Почему это важно

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

Что пошло не так

• Отсутствие код-ревью при публикации: npm не проверяет содержимое пакетов перед публикацией. Злоумышленник смог загрузить вредоносный код под легитимным именем @bitwarden/cli.
• Широкие права npm-токенов: Разработчики часто используют долгоживущие токены с избыточными правами на публикацию, что позволяет вредоносу распространяться автоматически.
• Доверие к CI/CD окружению: GitHub Actions workflows часто имеют доступ ко всем секретам проекта без сегментации, что делает их привлекательной целью.

Статус инцидента

На момент публикации (5 мая 2026 года) вредоносная версия @bitwarden/cli@2026.4.0 удалена из npm-репозитория. Bitwarden подтвердила, что их официальная инфраструктура не была скомпрометирована — атака затронула только npm-пакет, опубликованный злоумышленниками под легитимным именем.

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

Zero Click атака на Windows: кража паролей без вашего участия

Microsoft подтвердила активную эксплуатацию уязвимости CVE-2026-32202 в Windows Shell, позволяющей злоумышленникам похищать NTLM-хэши учётных данных пользователей без каких-либо действий со стороны жертвы. Агентство CISA включило уязвимость в каталог Known Exploited Vulnerabilities и установило крайний срок установки патча — 12 мая 2026 года.

Атака относится к типу zero-click — жертве не нужно открывать файл, кликать на ссылку или запускать макрос. Достаточно, чтобы специально сформированный LNK-файл (ярлык Windows) попал на диск — система автоматически обработает его и отправит хэш пароля злоумышленнику.

Механика атаки

Уязвимость CVE-2026-32202 — следствие неполного исправления предыдущей уязвимости CVE-2026-21510, которую Microsoft закрыла в феврале 2026 года после атак APT28 (Fancy Bear) на европейские оборонные организации.

• Шаг 1: Злоумышленник отправляет ZIP-архив с вредоносным LNK-файлом через имейл, Teams или SharePoint. Архив обходит проверку Mark-of-the-Web.
• Шаг 2: Когда LNK-файл попадает на диск, Windows Shell автоматически разбирает его. Внутри LNK злоумышленник размещает UNC-путь на свой сервер.
• Шаг 3: Windows автоматически устанавливает SMB-соединение и отправляет Net-NTLMv2 хеш текущего пользователя — без ведома пользователя и запроса на подтверждение.
• Шаг 4: Злоумышленник перехватывает хеш и либо взламывает пароль офлайн, либо перенаправляет аутентификацию на другой сервер в корпоративной сети.

Что пошло не так

• Неполное исправление: Microsoft закрыла предыдущую уязвимость, но не устранила корневую причину — автоматическую аутентификацию по UNC-путям в LNK-файлах.
• Устаревший протокол NTLM: Протокол 1990-х годов, передающий хеши паролей по сети.
• Отсутствие подписи SMB: Большинство организаций не включают обязательную подпись SMB, что позволяет NTLM Relay.
• Плоская сеть: Отсутствие сегментации позволяет латеральное движение по всей инфраструктуре.

Статус

Microsoft выпустила апрельский патч с исправлением уязвимости. Уязвимость затрагивала Windows 10, 11 и Server 2019/2022/2025.

Атака через подрядчика: как «обновление 1С» уничтожило инфраструктуру за две недели

Команда Solar 4RAYS опубликовала обзор инцидента с участием ранее неизвестной группировки вымогателей, атаковавшей спортивную организацию через скомпрометированного подрядчика — крупного интегратора ПО. От имени подрядчика злоумышленники прислали «обновление для 1С», которое оказалось бэкдором. За две недели хакеры получили полный контроль над инфраструктурой и развернули шифровальщик HardBit v4.2.

Инцидент расследовала команда Solar 4RAYS. Поскольку информации о географическом происхождении группировки нет, эксперты присвоили ей кодовое имя NGC8211 по собственной таксономии. Это первая зафиксированная атака данной группировки.

Почему это важно

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

Механика атаки

• Шаг 1: Злоумышленники скомпрометировали инфраструктуру интегратора ПО, обслуживающего спортивную организацию.
• Шаг 2: От имени подрядчика отправили «обновление для 1С». Поскольку письмо пришло с легитимного адреса интегратора, сотрудники установили файл без проверок. Бэкдор обеспечил постоянный удалённый доступ.
• Шаг 3: Две недели хакеры изучали инфраструктуру: картировали сеть, собирали учётные данные, повышали привилегии. Критичную роль сыграли слабые RDP-пароли — злоумышленники провели атаку перебором (брутфорс) на службу удалённого рабочего стола и получили доступ к серверам. Отсутствие сегментации сети позволило свободно перемещаться между системами.
• Шаг 4: Развернули шифровальщик HardBit v4.2 с защитой паролем и режимом Wiper (безвозвратное уничтожение файлов). Зашифровали критичные данные и потребовали выкуп.

Итог

Атака показывает, что доверие к подрядчикам без верификации — критичная уязвимость. Злоумышленники эксплуатируют организационные процессы: отсутствие проверки обновлений, слабые RDP-пароли и отсутствие сегментации. Защита требует верификации файлов через независимый канал, усиления парольной политики (16+ символов, MFA), сегментации инфраструктуры и детального аудита действий подрядчиков.

Исследование: 53% уязвимостей российских компаний — критические

Компания ScanFactory представила аналитический отчёт по результатам оценки защищённости внешнего периметра 125 российских организаций. Исследование охватило период с 2022 по 2025 год и включило анализ 246 коммерческих проектов из 18 отраслей экономики: от финансов и ритейла до промышленности и госсектора.

Ключевые выводы

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

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

Более 70% уязвимостей — типовые ошибки со стороны ИТ-разработки и эксплуатации:

• Небезопасная конфигурация систем и сервисов
• Отсутствие валидации и санитизации входных данных
• Использование устаревших компонентов с публично известными уязвимостями
• Игнорирование обновлений безопасности и патчей
• Нарушение принципов безопасной разработки (Secure Development Lifecycle)

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

Почему это критично

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

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

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

Это создаёт огромную поверхность атаки. Злоумышленники используют автоматизированное сканирование для массового поиска «низко висящих фруктов» — систем с типовыми уязвимостями, которые можно взломать за минуты.

Новая угроза: атакующий ИИ

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

Итог

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

Выводы

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

Три главных вывода:

1. Пароли в браузерах — первая цель инфостилеров. Встроенные менеджеры паролей браузеров хранят данные в локальной базе, защищённой только системной аутентификацией. Инфостилеры извлекают их автоматически при заражении устройства. Именно через Lumma Stealer, укравший пароли из браузера сотрудника Context.ai, началась цепочка, приведшая к взлому Vercel на $2 млн.
2. Уникальные пароли предотвращают эффект домино. Взлом одного сервиса не должен открывать доступ ко всем остальным. Компрометация Anodot автоматически скомпрометировала десятки клиентов, чьи токены хранились в системах подрядчика. Если бы каждый сервис использовал уникальные учётные данные, масштаб утечки был бы минимальным.
3. Верификация подрядчиков критична. Отсутствие проверки обновлений через независимый канал превращает доверенных партнёров в точку входа. «Обновление для 1С» от легитимного интегратора уничтожило инфраструктуру спортивной организации за две недели.

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

Пассворк закрывает все три проблемы: хранит пароли в зашифрованном виде, генерирует уникальные пароли для каждого сервиса, интегрируется с Active Directory и даёт ИТ-отделу полный контроль над доступом. Протестируйте бесплатно коробочную версию на ваших серверах или облачную версию с запуском за 5 минут.

Атака на цепочку поставок: взлом Bitwarden CLI, Shai-Hulud и выводы

Зачем атаковать защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний? Разбираем три резонансных инцидента 2026 года: компрометацию Bitwarden CLI через GitHub Actions, вредонос в Axios и утечку OAuth-токенов через Vercel. Что их объединяет и как защитить CI/CD.

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

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

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

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

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

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

Зачем атаковать хорошо защищённую корпоративную сеть, если можно взломать npm-пакет с миллионами скачиваний в неделю и незаметно проникнуть в тысячи таких сетей?

22 апреля 2026 года именно это и произошло. Стилер учётных данных был встроен в пакет с 250 000 загрузок в месяц. Он запускался в момент установки без какого-либо взаимодействия с пользователем, и автоматически подтягивался CI-раннерами в десятках пайплайнов. К тому моменту, когда пакет удалили, хосты уже были скомпрометированы. По сути, плановое обновление зависимости.

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

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

Главное

• Одна точка входа, неограниченный радиус поражения. Злоумышленник атакует не периметр организации, а доверенный компонент инфраструктуры с максимальным охватом. Вредоносный код распространяется через официальные каналы доставки.
• Доверие становится вектором атаки. Жертва устанавливает артефакт из авторитетного источника с валидной подписью. Для систем контроля доступа и мониторинга это неотличимо от легитимной операции.
• Компрометация происходит в доверенном контексте. Вредонос выполняется с полными правами разработчика или CI/CD-раннера. Традиционные средства защиты, настроенные на внешние аномалии, его не детектируют.
• Масштаб угрозы растёт экспоненциально. Один вредоносный релиз в популярном репозитории заражает тысячи организаций за минуты. В 2025 году 31% организаций столкнулись с атаками на цепочку поставок. В реестрах пакетов выявлено 454 600+ новых вредоносных артефактов — рост на 75% год к году.
• Защита требует архитектурного подхода, а не только процессных мер. Контроль зависимостей (SBOM, SCA), целостность артефактов, zero-trust для CI/CD, управление OAuth-интеграциями и централизованное управление секретами должны работать как единая система.

Что такое атака на цепочку поставок

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

Логика выбора цели проста: злоумышленник ищет не самую ценную организацию, а наиболее уязвимое звено с максимальным охватом. В сентябре 2025 года атака Shai-Hulud заразила популярные npm-пакеты — chalk, debug, ansi-styles и другие транзитивные зависимости, встроенные практически в каждый JavaScript-проект. Суммарная аудитория: 2,6 млрд загрузок в неделю (Хакер, 2025).

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

Резонансные случаи

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

Типичные векторы атак на цепочку поставок

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

• Компрометация сборочной среды. Вредоносный код внедряется на этапе сборки или в CI/CD-конвейер: до того, как продукт подписан и доставлен пользователям. Заражение остаётся невидимым — финальный артефакт выглядит легитимно.
• Вредоносные обновления. Злоумышленник получает контроль над механизмом доставки обновлений и распространяет заражённую версию через официальный канал. Пользователи устанавливают обновление сами, доверяя привычному источнику.
• Инъекции в зависимости. Вредоносный код встраивается в открытые библиотеки или пакеты — через тайпсквоттинг, подмену зависимостей или прямую компрометацию репозитория. Заражение наследуют все проекты, использующие пакет.
• Социальная инженерия против мейнтейнеров. Атакующий месяцами выстраивает доверие внутри open-source-сообщества, получает права на проект и внедряет бэкдор через легитимный коммит. Именно так была скомпрометирована XZ Utils.
• Эксплуатация уязвимостей в стороннем ПО. Уязвимость в широко используемом инструменте — файловом менеджере, библиотеке, платформе — становится точкой входа сразу для всех его пользователей. Патч выходит после того, как атака уже состоялась.
• Компрометация сторонних сервисов и вендоров. Атакующий взламывает не саму организацию, а подрядчика или SaaS-провайдера с легитимным доступом к её данным или инфраструктуре.
• Подделка и кража сертификатов подписи кода. Вредоносный файл подписывается валидным сертификатом — украденным или выданным на скомпрометированный аккаунт. Защитные механизмы пропускают его как доверенный.

Почему это опаснее обычных векторов атак

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

Опасность атак на цепочки поставок кроется в нескольких ключевых факторах:

• Доверие. Жертва устанавливает официальный пакет из проверенного источника. Вредоносный код приходит с той же подписью, с того же реестра, через тот же процесс, что и легитимное обновление. Для системы безопасности это выглядит как штатная операция.
• Масштаб. Традиционная атака компрометирует одну цель. Взломанный пакет компрометирует всех, кто его использует, одновременно. Один вредоносный релиз в популярном репозитории способен заразить тысячи организаций за минуты.
• Скрытность. Вредоносный код выполняется в доверенном контексте. Стандартные средства защиты настроены на аномалии извне. Угрозу, пришедшую изнутри доверенного процесса, они пропускают.
• Автоматизация против вас. CI/CD-пайплайны созданы для скорости: они подтягивают зависимости и деплоят без остановок. Именно эта автоматизация превращает один взломанный пакет в угрозу для всей инфраструктуры.

Масштаб угрозы в 2025–2026 годах

По данным Лаборатории Касперского, атаки на цепочки поставок стали самой частой киберугрозой для бизнеса в 2025 году: с ними столкнулись 31% компаний по всему миру и 35% в России. Цифры Sonatype объясняют почему: за тот же год в реестрах npm, PyPI, Maven Central, NuGet и Hugging Face выявлено более 454 600 новых вредоносных пакетов. Совокупный объём заблокированного вредоносного ПО превысил 1,23 млн пакетов — рост на 75% год к году.

Главной мишенью атак остаётся npm. Именно здесь в 2025 году появился Shai-Hulud — первый самовоспроизводящийся червь для экосистемы пакетов, названный в честь гигантских песчаных червей из «Дюны». После компрометации учётной записи мейнтейнера червь автоматически заражал все пакеты под его управлением через postinstall-хук и распространялся дальше по той же схеме. За время кампании было скомпрометировано более 700 GitHub-репозиториев.

3 самых громких атаки на цепочку поставок в 2025–2026 годах

Период с марта по апрель 2026 года стал беспрецедентным по концентрации атак на цепочки поставок ПО. Аналитики Trend Micro зафиксировали, что злоумышленники одновременно и скоординированно атаковали сразу несколько уровней инфраструктуры: CI/CD-системы, реестры пакетов, OAuth-интеграции и платформы деплоя, каждый из которых раньше считался отдельным вектором риска.

Checkmarx и взлом Bitwarden CLI (апрель 2026)

22 апреля 2026 года в реестр npm была опубликована вредоносная версия Bitwarden CLI (@bitwarden/cli@2026.4.0). Пакет скачивают более 250 000 раз в месяц — это сделало его ценной мишенью. Bitwarden не взламывали напрямую: злоумышленники скомпрометировали сторонний GitHub Action в CI/CD-пайплайне компании, получили доступ к секретам воркфлоу, в том числе к npm-токену, и с его помощью опубликовали вредоносный пакет.

«Команда безопасности Bitwarden выявила и локализовала вредоносный пакет, который был распространён через канал доставки npm для @bitwarden/cli@2026.4.0 с 17:57 до 19:30 (по восточному времени) 22 апреля 2026 года и связан с более широким инцидентом в цепочке поставок Checkmarx», — официальное заявление Bitwarden

Пакет оставался доступен около 1,5 часов — за это время его скачали 334 раза. Строка «Shai-Hulud: The Third Coming» (Shai-Hulud: Третье пришествие), встроенная в код, подтвердила: это третья итерация организованной кампании, а не случайная атака (OX Security, 2026).

Механика вредоносного кода

Вредоносный код был встроен в bw1.js и запускался через хук preinstall в package.json: сначала выполнялся bw_setup.js, устанавливавший среду выполнения Bun, затем основная нагрузка. Никакого взаимодействия с пользователем не требовалось. Последовательность действий:

1. Проверка локали. Вредонос проверял, настроен ли на машине русский язык. Если да, то немедленно завершал работу. Стандартный приём самозащиты, косвенно указывающий на русскоязычного актора угрозы.
2. Кража учётных данных. Целенаправленно собирались токены GitHub и npm, содержимое директорий .ssh, файлы .env, история командной оболочки, переменные окружения GitHub Actions, учётные данные AWS, GCP и Azure, информация о GitHub Runner.
3. Атака на AI-инструменты. Конфигурационные файлы Claude, Kiro, Cursor, Codex CLI и Aider были явно включены в список целей. Это явно отражает, насколько глубоко подобные инструменты встроились в рабочие процессы разработчиков и сколько чувствительного контекста они хранят локально.
4. Зашифрованная эксфильтрация через GitHub. Все похищенные данные шифровались с помощью AES-256-GCM с асимметричным ключом — расшифровать их может только сам злоумышленник, располагающий приватным ключом. Данные загружались в новый публичный репозиторий GitHub, созданный на аккаунте жертвы, в файлы формата results-TIMESTAMP-ID.json. Резервный канал эксфильтрации вёл на audit.checkmarx[.]cx — домен, имитирующий легитимную платформу Checkmarx. Использование GitHub в роли C2-сервера — осознанный выбор: трафик на github.com крайне редко блокируется средствами защиты и не указывает на инфраструктуру злоумышленника.
5. Самораспространение. Именно это превращает Shai-Hulud из стилера в червя. При обнаружении валидных npm-токенов вредонос скачивал один из npm-пакетов жертвы, внедрял в него вредоносный код и публиковал новую версию, автоматически распространяя заражение на пользователей этого пакета.
6. Распространение по пайплайнам. При обнаружении GitHub-токенов вредонос внедрял вредоносные Actions-воркфлоу в доступные репозитории, извлекал CI/CD-секреты и распространял компрометацию на все пайплайны, доступные токену разработчика.

«После взломов Trivy и Checkmarx эта атака бьёт по ещё одному инструменту безопасности, глубоко встроенному в рабочие процессы разработчиков и CI-пайплайны — туда, где доступ к API-токенам, ключам и другим секретам является обычной практикой», — Endor Labs, 2026

@bitwarden/cli@2026.4.0 — один из наиболее технически сложных вредоносных пакетов в истории npm. Он совмещает сборщик учётных данных из шести типов секретных хранилищ, самовоспроизводящегося червя, перезаражающего все пакеты, доступные токену жертвы, C2-канал на базе GitHub-коммитов с RSA-подписью команд, зашифрованную эксфильтрацию, устойчивую к изъятию репозитория, персистентность через shell RC и модуль целенаправленной атаки на AI-ассистентов для разработки (Endor Labs, 2026).

Инцидент Checkmarx: 23 марта 2026 года

Эта кампания началась задолго до апреля. Согласно официальному сообщению Checkmarx, 23 марта 2026 года около 05:53 по московскому времени были опубликованы вредоносные версии двух плагинов OpenVSX — они оставались доступны до 18:41. Параллельно были скомпрометированы два GitHub Actions-воркфлоу: ast-github-action и kics-github-action. Организации, загрузившие эти артефакты в указанный промежуток времени и запустившие их, оказались под угрозой.

Инцидент с Bitwarden CLI воспроизвёл тот же вектор атаки через GitHub Actions, подтверждая, что речь идёт об активной, развивающейся кампании, а не об изолированном случае.

Архитектурный урок

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

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

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

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

Компрометация пакетов Axios (март 2026)

31 марта 2026 года были выпущены две вредоносные версии Axios — одного из самых популярных HTTP-клиентов для JavaScript с более чем 100 миллионами скачиваний в неделю. Атаку раскрыла и атрибутировала команда Microsoft Threat Intelligence.

Механика атаки

Злоумышленники не трогали исходный код Axios. Вместо этого они внедрили вредоносный код через зависимость — фейковый пакет plain-crypto-js@4.2.1. При установке Axios этот пакет автоматически выполнял post-install-скрипт: подключался к C2-серверу hxxp://sfrclak[.]com:8000 и загружал троян удалённого доступа (RAT). Под удар попали Windows, macOS и Linux — каждая платформа получала свою версию вредоноса.

Схема была выстроена в несколько шагов. Сначала опубликовали «чистый» plain-crypto-js@4.2.0 — чтобы сформировать историю публикаций и снизить подозрения. Затем вышел 4.2.1 с вредоносным хуком. После этого были выпущены axios@1.14.1 и axios@0.30.4 с единственным изменением в package.json — добавлением зависимости от plain-crypto-js@^4.2.1. Исходный код Axios при этом остался нетронутым.

Атаку приписывают северокорейской группировке Sapphire Sleet, специализирующейся на краже криптовалюты и корпоративном шпионаже.

Почему это важно

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

Утечка OAuth-токенов через Vercel и Context.ai (февраль–апрель 2026)

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

Цепочка компрометации

В феврале 2026 года сотрудник небольшого ИИ-стартапа Context.ai загрузил скрипты для Roblox, заражённые стилером Lumma Stealer. Вредонос похитил корпоративные учётные данные и OAuth-токены Google Workspace. Через эти токены атакующие в марте получили доступ к AWS-среде Context.ai и эксфильтровали OAuth-токены пользователей — в том числе токен сотрудника Vercel.

Дальше сработала цепочка доверия. Через скомпрометированный OAuth-токен атакующие вошли в Google Workspace аккаунт сотрудника Vercel, оттуда — во внутренние системы компании. Итог: доступ к переменным окружения клиентских проектов, не помеченным как «sensitive».

Что делает этот инцидент показательным

Три структурных урока, которые здесь видны особенно отчётливо.

• OAuth-токены — слепое пятно большинства команд безопасности. Они не требуют пароля, переживают его смену и редко проходят аудит после первоначальной авторизации. Один скомпрометированный вендор открывает доступ ко всем его интеграциям — автоматически, без дополнительных действий атакующего.
• Клиенты Vercel не могли предотвратить атаку на своём уровне. Они не имели никакого отношения к Context.ai. Их данные оказались под угрозой исключительно из-за решений третьей стороны.
• Скорость атаки нарастает. От заражения Lumma Stealer до эксфильтрации данных клиентов Vercel прошло около двух месяцев. Как отметил CEO Vercel Гильермо Рауш, необычная скорость продвижения атакующих объясняется использованием ИИ-инструментов для ускорения операций.

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

Как защититься от атак на цепочку поставок

Защита требует контроля на каждом уровне: от выбора зависимостей до управления секретами в CI/CD.

Уровень 1: Контроль зависимостей

• Фиксируйте версии и проверяйте хеши. Плавающие диапазоны версий в продуктовых пайплайнах — это открытая дверь для автоматического подтягивания вредоносной версии. Фиксируйте точные версии и сверяйте контрольные суммы с эталонным состоянием. Это не защитит от компрометации аккаунта мейнтейнера, но исключит незаметное обновление на заражённый пакет.
• Формируйте и поддерживайте SBOM. Software Bill of Materials — полный реестр каждого компонента вашего ПО, включая транзитивные зависимости. Когда появляется информация об уязвимости или вредоносном пакете (как с Axios или Bitwarden CLI), вы мгновенно определяете, затронуты ли вы.
• Запускайте SCA непрерывно. Статические одноразовые сканирования недостаточны. Инструменты Software Composition Analysis должны работать на каждом пулл-реквесте и при каждом обновлении зависимостей, выявляя новые пакеты, нестандартные preinstall-хуки и неожиданные сетевые вызовы в скриптах пакетов.

Уровень 2: Целостность артефактов

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

Уровень 3: Защита CI/CD-инфраструктуры

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

• Применяйте модель нулевого доверия (zero trust) к CI/CD-воркфлоу. GitHub Actions должны работать с минимально необходимыми правами. Используйте эфемерные токены, ограниченные отдельными задачами, — не долгоживущие персональные токены доступа. Аудируйте файлы воркфлоу на предмет ссылок на сторонние Actions и фиксируйте их на конкретные коммит (SHA), а не на изменяемые теги (как это произошло с Checkmarx и Bitwarden CLI).
• Контролируйте аномальный исходящий трафик. Вредонос в Bitwarden CLI устанавливал соединение с audit.checkmarx[.]cx. Мониторинг исходящего трафика CI-раннеров на сетевом уровне зафиксировал бы это. Составьте белый список ожидаемых исходящих адресов для сборочных сред и настройте алерты на любые отклонения.
• Ротируйте секреты CI/CD регулярно и сразу после любого инцидента. Относитесь к секретам в CI/CD-средах как к краткосрочным учётным данным. Любой токен, API-ключ или SSH-ключ, который мог быть скомпрометирован, должен быть заменён немедленно. Выстроенный процесс управления секретами превращает эту операцию в штатную процедуру, а не в аварийную импровизацию.

Уровень 4: Защита периметра разработчика

• Включите конфигурации AI-инструментов в периметр защиты. Кампания 2026 года явно целилась в конфигурационные файлы Claude, Cursor, Aider и аналогичных инструментов. Эти файлы нередко содержат API-ключи и контекст о кодовой базе. Относитесь к ним как к чувствительным артефактам и включайте в область применения инструментов сканирования секретов.
• Аудируйте OAuth-приложения. Инцидент с Vercel показал: доверенные сторонние OAuth-приложения создают цепочки доверия, которые обходят традиционные средства защиты. Проведите аудит всех OAuth-приложений. Отзовите доступ у неиспользуемых приложений. Ограничьте области видимости (scopes) до минимально необходимых.

Централизованное управление секретами — основа всего

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

Заключение

Атаки на цепочку поставок в 2026 году — это новая норма. Взлом Bitwarden CLI показал, что инструменты безопасности сами становятся вектором атаки. Axios продемонстрировал уязвимость транзитивных зависимостей — тех, о которых разработчики даже не подозревают. Vercel доказал, что один скомпрометированный OAuth-вендор открывает путь к тысячам клиентов.

Что объединяет все три инцидента? Не сложность атак. Не новые уязвимости. Секреты в незащищённых средах.

Переменные окружения CI/CD с npm-токенами и GitHub PAT. OAuth-токены без ротации. Конфиги AI-инструментов с API-ключами. Они лежат открыто — и именно они становятся главным призом для атакующих.

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

Нужна многоуровневая защита и архитектурное ограничение. Контроль зависимостей (SBOM, SCA), целостность артефактов (подписанные сборки), zero-trust для CI/CD-пайплайнов, аудит OAuth-приложений, централизованное управление секретами. И главное: система, где компрометация одного секрета не открывает доступ ко всему остальному.

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

FAQ: атаки на цепочку поставок

Чем атака на цепочку поставок отличается от обычной кибератаки?

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

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

Немедленно ротируйте все секреты, доступные в среде, где был установлен пакет: SSH-ключи, токены, API-ключи, переменные окружения CI/CD. Изолируйте затронутые системы, проведите форензику на предмет эксфильтрации данных и проверьте GitHub-репозитории вашей организации на наличие посторонних публичных форков.

Как защитить CI/CD от атак на цепочку поставок?

Используйте точные версии GitHub Actions по SHA-хешу, а не по тегу — это исключает подмену при обновлении. Используйте OIDC-токены вместо долгосрочных секретов. Ограничьте права Actions по принципу минимальных привилегий. Мониторьте аномальное поведение в пайплайнах: неожиданные сетевые соединения, создание новых файлов в нестандартных директориях.

Что такое транзитивная зависимость и почему она опасна?

Транзитивная зависимость — это пакет, который вы не устанавливаете напрямую, но он подтягивается как зависимость вашей зависимости. В атаке на Axios вредоносный код был спрятан в plain-crypto-js — пакете, о котором разработчики не знали. Проверка только прямых зависимостей не защищает от этого вектора: необходим полный SCA-аудит дерева зависимостей.

Почему OAuth-токены — опасный вектор атаки?

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

Что такое Shai-Hulud и почему это важно?

Shai-Hulud — первый в истории самовоспроизводящийся npm-червь, зафиксированный Sonatype в 2025 году. В отличие от обычного вредоносного пакета, он способен автономно распространяться через экосистему зависимостей: заражённый пакет реплицирует себя в npm-проекты жертвы. Вариант этого червя был использован в атаке на @bitwarden/cli в апреле 2026 года.

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

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

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

Приказы ФСТЭК и ФСБ №117: в чём разница и как выполнить требования

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

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

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

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

Группа «Черкизово» — крупнейший производитель мясной продукции в России с полным производственным циклом. На предприятиях холдинга работает более 40 000 сотрудников в 20 регионах страны, от Калининградской области до Алтая: животноводческие комплексы, мясоперерабатывающие заводы, комбикормовые предприятия и логистические центры.

Цифровизация и технологическая надёжность — стратегические приоритеты холдинга. Группа «Черкизово» последовательно внедряет современные ИТ-решения для управления производством, логистикой и инфраструктурой, а также активно участвует в отраслевых мероприятиях по цифровой трансформации агропромышленного комплекса. Продукция компании регулярно получает награды и отраслевые премии.

Подразделение технических систем безопасности (ТСБ) Группы «Черкизово» отвечает за видеонаблюдение и системы контроля и управления физическим доступом, в том числе серверную инфраструктуру и сетевое оборудование этих систем.

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

Задача: систематизировать управление паролями

Учитывая масштабы Группы «Черкизово» и большое количество различных технических средств, применяемых для обеспечения физической безопасности объектов компании, подразделению ТСБ потребовался единый инструмент для управления учётными данными. Компания присутствует в десятках регионов — централизованное и удобное хранение паролей стало логичным шагом.

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

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

Внедрение менеджера паролей: простота и скорость

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

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

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

Настройка сейфов для распределённой инфраструктуры

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

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

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

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

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

Результат: моментальный доступ к данным и снижение рисков

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

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

В течение нескольких лет Пассворк был частью ежедневной работы команды ТСБ — инструментом, который помогал удерживать баланс между строгим контролем и удобством совместной работы региональных сотрудников.

«Функционал Пассворка помогал нам решать наши задачи. Цена приемлемая, и техподдержка работает оперативно, доводя дело до конца»

Готовы повысить уровень безопасности? Команда ТСБ Группы «Черкизово» развернула Пассворк за один день и получила оперативный доступ к учётным данным в любое время. Протестируйте бесплатно в своей инфраструктуре

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это означает

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое карта импортозамещения от ComNews

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

Аудитория проекта — ИТ-директоры, CISO, архитекторы безопасности и руководители компаний, которые принимают решения о переходе на отечественные решения и построении защищённой инфраструктуры.

Для каждого продукта на карте указаны:

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

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

Рынок информационной безопасности растёт

По итогам 2025 года российский рынок кибербезопасности вырос с 16,5 млрд рублей в 2010 году до 374 млрд рублей в 2025. Для сравнения: мировой рынок информационной безопасности (ИБ) за тот же период рос медленнее — темпы роста в 2025 году составили 12,2%. К 2030 году Центр стратегических разработок (ЦСР) прогнозирует рост российского рынка до 968 млрд рублей со среднегодовым темпом прироста около 21%.

При этом задача импортозамещения ещё не закрыта. Доля иностранных решений в совокупных затратах российских компаний на ИБ снизилась до 7%. Однако в установленной базе средств защиты иностранные продукты по ряду классов ПО продолжают занимать 10–20%, а в сегменте сетевой безопасности эта доля доходит до 40–50% (данные консалтинговой компании Б1, исследование «Рынок информационной безопасности России»).

Более того, по оценкам Usergate, более 50% компаний продолжают использовать иностранные решения в сфере ИБ, в том числе приобретая их через серые схемы (CNews, 2026). Это означает, что переход продолжается, и инструменты для навигации по отечественному рынку становятся всё более востребованными.

Пассворк — стратегический партнёр проекта

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

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

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

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

• Данные остаются внутри периметра. Локальное развёртывание на серверах компании — без зависимости от внешних облаков и зарубежных сервисов.
• Соответствие требованиям регуляторов. Архитектура нулевого знания, лицензии ФСБ и ФСТЭК. Продукт включён в реестр отечественного ПО Минцифры и сертифицирован ФСТЭК России по 4-му уровню доверия.
• Интеграция в текущую инфраструктуру. Поддержка Active Directory, LDAP, SSO, SIEM и API — не создаёт отдельный контур, а встраивается в существующую систему.
• Контроль в реальном времени. Централизованное хранение паролей и секретов, ролевая модель, детальный журнал аудита, мгновенный отзыв доступов при увольнении сотрудников.
• Снижение человеческого фактора. Устраняет хаотичное хранение паролей — один из основных векторов атак на корпоративную инфраструктуру.

Заключение

Аналитическая карта ComNews показывает, что рынок информационной безопасности в России перешёл к системному импортозамещению. У компаний появился инструмент, который позволяет быстро ориентироваться в отечественных решениях, сравнивать их и принимать обоснованные решения без потери функциональности и уровня защиты.

«Полный переход на российские продукты в ближайшие 3–5 лет — это вопрос выживания бизнеса. Использование нелицензионного софта, особенно в критической информационной инфраструктуре (КИИ) и АСУ ТП, может привести к остановке производства. Перспективы перехода позитивные: отечественные вендоры уже предлагают зрелые альтернативы в большинстве сегментов, и отказ от серых схем произойдёт естественным путем по мере усложнения интеграции и роста доверия к российским разработкам», — Илья Гарах, технический директор ООО «Пассворк»

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

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

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

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

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

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

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

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

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

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

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