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

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 — рассмотрим механику атак через цепочку поставок и покажем, как базовые ошибки в управлении доступом приводят к критическим инцидентам.

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

Зачем атаковать хорошо защищённую корпоративную сеть, если можно взломать 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 году и даём конкретный чек-лист защиты.

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Киберугрозы марта 2026: инциденты, штрафы и защита данных

Первые оборотные штрафы за утечки. Zero-click уязвимость в Telegram. Каскадная атака через Trivy. Шифровальщик в европейском порту. Новые требования ФСТЭК и КИИ. В статье — разбор ключевых инцидентов, изменений в законодательстве и конкретных шагов по защите корпоративных доступов.

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

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

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

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

Введение

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

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

Когда атака всё-таки обнаружена, у команды нет времени разбираться, кто за что отвечает. Есть только план — или его отсутствие.

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

Главное

• Среднее время присутствия злоумышленника в сети российской компании — 42 дня. За это время атакующий успевает повысить привилегии, скопировать данные и установить бэкдоры.
• Первые минуты инцидента определяют масштаб ущерба. Минимальное зафиксированное время от первоначального проникновения до полного шифрования инфраструктуры составляет 12,5 минуты.
• Реагирование — это последовательность, а не импровизация. Подготовка → обнаружение → сдерживание → форензика → устранение → восстановление → разбор. Пропуск или перестановка шагов уничтожает улики и открывает путь для повторного проникновения.
• Форензика начинается до любых изменений в системе. Дамп оперативной памяти — в первую очередь. Каждый артефакт документируется по цепочке хранения: кто собрал, когда, на каком носителе.
• Восстановление — только из чистого бэкапа, только после закрытия уязвимости. Восстановление из заражённой резервной копии или через незакрытый вектор атаки — прямой путь к повторному инциденту.
• Уведомление регуляторов — обязанность с жёсткими сроками. При утечке персональных данных — РКН в течение 24 часов (152-ФЗ). Субъекты КИИ — НКЦКИ в течение 3–24 часов (187-ФЗ, Приказ ФСБ № 546). Нарушение сроков — самостоятельный состав правонарушения.
• Компрометация учётных данных — сквозной риск на каждом этапе. Слабые пароли открывают первоначальный доступ, общие логины распространяют компрометацию, незакрытые учётки уволенных сотрудников становятся точкой повторного входа. Централизованное управление паролями закрывает этот риск системно.
• Разбор инцидента обязателен. Разбор — единственный способ превратить инцидент в данные для улучшения защиты. Без разбора компания платит дважды.

Почему скорость реакции решает всё

В 2025 году число киберинцидентов в России выросло на 42% — до 22 тысяч за год. Более 50% компаний в 2025 году столкнулись с кибератаками (CNews, 2026, ТАСС, 2025). По словам зампреда правления Сбербанка Станислава Кузнецова, озвученным на ВЭФ-2025, совокупный ущерб экономике за первые восемь месяцев 2025 года мог составить около 1,5 трлн рублей (Интерфакс, 2025).

"По нашей оценке, в 2025 году уже было атаковано не менее 53% российских компаний, при этом 8 из 10 столкнулись с серьезными последствиями, четверть этих компаний признала, что они понесли существенные репутационные риски, еще одна четверть призналась в больших финансовых потерях. Ну и 48% признались, что у них были простои, из бизнес, сайты, деятельность приостановились" — зампред правления Сбербанка Станислав Кузнецов

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

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

Как атакуют: векторы, которые нужно знать

В 2025 году 64% успешных атак на организации заканчивались утечкой конфиденциальных данных (Positive Technologies, 2026). Понять, откуда пришла атака, — значит понять, где была брешь. Большинство инцидентов начинаются с одного из пяти векторов.

Фишинг и социальная инженерия

Самый массовый вектор. 80% целевых атак начинаются с электронного письма, в 70% случаев почта — канал доставки вредоносного ПО (Positive Technologies, 2026).

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

Отдельная тенденция — phishing-as-a-service (PhaaS): готовые панели управления атаками, шаблоны писем и механизмы обхода почтовых фильтров доступны на теневых площадках. Порог входа для злоумышленника снизился до минимума.

Компрометация учётных данных

Второй по частоте вектор. Атакующий не взламывает систему, он входит в неё с валидными учётными данными. Источники скомпрометированных паролей:

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

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

Эксплуатация уязвимостей

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

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

Атаки через подрядчиков

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

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

Вредоносное ПО: шифровальщики и инфостилеры

Вредоносное ПО применялось в большинстве успешных атак на организации в 2025 году (Positive Technologies, январь 2025). Два наиболее распространённых класса:

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

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

Векторы кибератак и меры защиты

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

Сколько времени злоумышленник остаётся в сети незамеченным

Среднее время обнаружения (Mean Time to Detect, MTTD) — среднее время между моментом проникновения и его обнаружением. Чем выше этот показатель, тем глубже атакующий укоренился в инфраструктуре до того, как его заметили.

Среднее время обнаружения для российских компаний составляет 42 дня. За это время злоумышленник, как правило, успевает:

• изучить топологию сети и определить пути к критичным системам
• повысить привилегии до уровня администратора домена
• скопировать или проиндексировать ценные данные
• установить бэкдоры для повторного доступа после «устранения» инцидента

При этом минимальное зафиксированное время от первоначального проникновения до полного шифрования инфраструктуры составляет 12,5 минуты (BI.ZONE, 2025). Это исключает любые паузы на согласование действий: у команды реагирования нет времени на обсуждение — только на исполнение заранее отработанного плана.

Второй ключевой показатель — среднее время восстановления (Mean Time to Respond/Recover, MTTR): время от обнаружения до полного восстановления операционной деятельности. Сокращение среднего времени восстановления — главная измеримая цель любого плана реагирования на инциденты (Incident Response Plan, IRP).

На практике среднее время восстановления складывается из нескольких последовательных этапов:

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

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

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

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

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

Пошаговый план реагирования на кибератаку

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

Шаг 1. Подготовка — действия до инцидента

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

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

Шаг 2. Обнаружение и идентификация

Признаки компрометации (Indicators of Compromise, IoC) — артефакты, указывающие на то, что система была скомпрометирована. Это могут быть сетевые аномалии, подозрительные процессы, изменения в файловой системе или нетипичная активность учётных записей.

Сетевые аномалии

• Исходящий трафик на нетипичные адреса или в нетипичное время — особенно ночью и в выходные
• Резкий рост объёма передаваемых данных без видимой причины (возможная эксфильтрация)
• Соединения с известными вредоносными IP или доменами
• DNS-запросы к случайно выглядящим доменам — признак DGA-активности (генерация доменов вредоносным ПО)
• Нетипичные протоколы или порты: например, RDP наружу, SMB во внешнюю сеть

Подозрительные процессы и активность на хостах

• Неизвестные процессы с высоким потреблением CPU или памяти, особенно запущенные от имени системных учётных записей
• Процессы, запущенные из нетипичных директорий: %TEMP%, %AppData%, корень диска
• Отключение или остановка антивирусных агентов, EDR, служб логирования
• Появление новых задач в планировщике или служб с неизвестными именами

Изменения в файловой системе

• Появление новых исполняемых файлов в системных директориях или директориях пользователей
• Массовое переименование или изменение расширений файлов — прямой признак работы шифровальщика
• Изменение системных файлов с неожиданными временными метками
• Появление файлов с именами типа README_DECRYPT.txt, HOW_TO_RESTORE.html — записки с требованием выкупа
• Удаление теневых копий (vssadmin delete shadows) — стандартный шаг шифровальщика

Аномалии в учётных записях

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

Признаки в журналах событий

• Очистка журналов безопасности Windows (Event ID 1102) или системных логов — злоумышленники заметают следы
• Массовый экспорт данных из корпоративных систем: почта, файловые хранилища, базы данных
• Обращения к файлам с паролями, конфигурационным файлам, ключам SSH — целенаправленный сбор учётных данных

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

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

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

Шаг 3. Сдерживание

Цель этого шага — остановить распространение угрозы и минимизировать ущерб, не уничтожив улики. Сдерживание всегда предшествует устранению: пока периметр не стабилизирован, любые попытки «вылечить» систему бессмысленны.

Краткосрочное сдерживание — немедленные действия

• Изолируйте поражённые хосты на уровне сети: отключите сетевой кабель или заблокируйте порты на коммутаторе
• Заблокируйте скомпрометированные учётные записи. Если установить конкретные аккаунты невозможно — временно заблокируйте все привилегированные учётные записи и переиздайте их с новыми паролями
• Отзовите активные сессии и токены доступа на поражённых системах
• Заблокируйте на межсетевом экране IP-адреса и домены, замеченные в атаке
• Отключите или ограничьте внешние подключения: RDP, открытые порты — всё, что может служить каналом управления для злоумышленника

Среднесрочное сдерживание — стабилизация периметра

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

Что фиксировать на этом шаге

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

Шаг 4. Сбор доказательств (форензика)

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

Что собирать и в каком порядке

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

• Дамп оперативной памяти — в первую очередь. Содержит активные процессы, сетевые соединения, расшифрованные ключи, фрагменты вредоносного кода.
• Сетевые логи — активные соединения, таблицы маршрутизации. Необходимо снимать до изоляции хоста от сети, так как после отключения активные сессии будут разорваны
• Образ диска — побитовая копия (работайте только с копией)
• Журналы событий — Windows Event Log (Security, System, Application), syslog, auth.log. Экспортируйте целиком, не фильтруйте на месте
• Логи SIEM и EDR — выгрузите за период, охватывающий предполагаемое время проникновения с запасом минимум в две недели

Цепочка хранения доказательств

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

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

Что проверить дополнительно

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

Шаг 5. Устранение угрозы

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

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

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

Шаг 6. Восстановление систем

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

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

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

Безопасное развёртывание из бэкапов

Перед восстановлением ответьте на три вопроса:

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

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

1. Инфраструктурные сервисы (AD, DNS, DHCP)
2. Системы резервного копирования и мониторинга
3. Критичные бизнес-приложения (ERP, CRM, финансовые системы)
4. Рабочие места пользователей
5. Некритичные сервисы

Технические меры при восстановлении

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

Мониторинг после восстановления

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

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

• Все входы в систему, особенно в нерабочее время
• Сетевые соединения с внешними адресами
• Изменения в файловой системе в критичных директориях
• Попытки обращения к ранее выявленным C2-адресам (даже заблокированным — это сигнал о повторной активности)
• Активность сервисных учётных записей

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

Шаг 7. Извлечённые уроки

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

Разбор инцидента

Разбор инцидента (Post-Incident Review, PIR) — обязательная встреча команды, которая работала над инцидентом. Следует провести встречу в течение 24-72 часов (но не позднее 7 дней) после закрытия инцидента, пока детали свежи в памяти.

Структура разбора инцидента

1. Хронология. Восстановите полную цепочку событий: проникновение → закрепление → горизонтальное перемещение → финальный ущерб. Покажет, где были слепые пятна в мониторинге.
2. Анализ атаки. Где атакующий мог быть остановлен, но не был? Какие средства защиты сработали, какие нет?
3. Оценка реагирования. Насколько быстро обнаружили инцидент и провели изоляцию? Какие решения оказались верными, какие нет? Где регламент не работал или отсутствовал?
4. Финансовый ущерб. Зафиксируйте прямые и косвенные потери — это основа для обоснования бюджета на ИБ.

Корректировка политик безопасности

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

Типичные направления корректировок после инцидента

• Управление доступом: ревизия привилегированных учётных записей, внедрение принципа минимальных привилегий, ограничение доступа подрядчиков по времени и периметру.
• Мониторинг: расширение покрытия SIEM, добавление источников логов, которые оказались «слепыми зонами».
• Бэкапы: проверка соответствия правилу 3-2-1, тестирование восстановления.
• Обучение персонала: фишинг остаётся основным вектором кибератак.
• Парольная политика: часто в пострадавших компаниях сотрудники использовали одинаковые пароли для разных сервисов.

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

Матрица этапов реагирования

Уведомление регуляторов: требования 2025–2026 годов

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

Роскомнадзор (утечка персональных данных)

С 30 мая 2025 года действуют новые штрафы за утечку персональных данных и непредставление уведомления в РКН. Порядок уведомления:

1. В течение двадцати четырех часов о произошедшем инциденте, о предполагаемых причинах, повлекших нарушение прав субъектов персональных данных, и предполагаемом вреде, нанесенном правам субъектов персональных данных, о принятых мерах по устранению последствий соответствующего инцидента, а также предоставить сведения о лице, уполномоченном оператором на взаимодействие с уполномоченным органом по защите прав субъектов персональных данных, по вопросам, связанным с выявленным инцидентом;
2. В течение семидесяти двух часов о результатах внутреннего расследования выявленного инцидента, а также предоставить сведения о лицах, действия которых стали причиной выявленного инцидента (при наличии).

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

ГосСОПКА / НКЦКИ (субъекты КИИ)

Для субъектов критической информационной инфраструктуры обязательна передача информации об инцидентах в ГосСОПКА через НКЦКИ:

С 30 января 2026 года вступил в силу Приказ ФСБ России № 546, утверждающий новый порядок обмена информацией о кибератаках для субъектов КИИ. Документ уточняет форматы и каналы передачи данных в НКЦКИ.

ФСТЭК

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

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

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

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

Принципы кризисных коммуникаций

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

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

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

Скомпрометированные учётные данные — главный вектор атак. По данным исследования Positive Technologies за 2026 год, кража учётных данных составила 19% от всех инцидентов 2025 года, а доля атак с утечкой конфиденциальной информации достигла 64%. Слабая парольная политика открывает дверь для следующей атаки — даже после полного восстановления инфраструктуры.

Управление паролями и доступом

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

Защита от фишинга

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

Мониторинг и обнаружение

• SIEM с настроенными правилами корреляции для раннего обнаружения аномалий
• EDR на всех конечных точках
• Регулярный аудит учётных записей и прав доступа

Резервное копирование

• Правило 3-2-1: три копии, два разных носителя, одна — офлайн
• Регулярная проверка восстановления из бэкапов — не реже раза в квартал

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

Как Пассворк помогает при реагировании на инциденты

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

До инцидента

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

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

Во время инцидента

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

После инцидента

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

Заключение

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

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

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

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

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

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

Что делать в первые минуты после обнаружения кибератаки?

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

Как понять, что атака завершена и можно восстанавливаться?

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

Нужно ли уведомлять регуляторов при кибератаке?

Зависит от типа инцидента и статуса организации. Субъекты КИИ обязаны уведомить ФСБ (через НКЦКИ) в течение 24 часов по 187-ФЗ. При утечке персональных данных — уведомить Роскомнадзор в течение 24 часов с момента обнаружения (152-ФЗ, статья 21). Рекомендуется заранее подготовить шаблоны уведомлений и согласовать их с юристом.

Что такое ГосСОПКА и кто обязан туда сообщать?

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

Как восстановить системы после атаки шифровальщика?

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

Нужно ли сообщать клиентам о взломе?

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

Как защититься от атак через подрядчиков?

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

Хэширование паролей: соль, перец и выбор алгоритма

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

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

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

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

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

Киберугрозы марта 2026: инциденты, штрафы и защита данных

Первые оборотные штрафы за утечки. Zero-click уязвимость в Telegram. Каскадная атака через Trivy. Шифровальщик в европейском порту. Новые требования ФСТЭК и КИИ. В статье — разбор ключевых инцидентов, изменений в законодательстве и конкретных шагов по защите корпоративных доступов.

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

Вступление

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

По данным исследования Hoxhunt 2025 года, ИИ на 24% эффективнее людей в создании фишинговых писем. Для достижения таких результатов нейросети анализируют цифровой след жертвы: профили и комментарии в социальных сетях, коммиты на GitHub. На основе этих данных скрипт пишет письмо, которое выглядит как легитимный запрос от внутреннего заказчика или подрядчика.

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

Главное

• ИИ сделал фишинг точечным оружием. Языковые модели анализируют цифровой след жертвы и генерируют письма без ошибок, в корпоративном стиле, адресованные конкретному человеку.
• Атака идёт по нескольким каналам одновременно. Письмо, звонок, мессенджер работают в связке: каждый следующий вектор усиливает доверие к предыдущему и снижает критическое мышление.
• Голос и лицо больше не доказывают личность. Для клонирования голоса достаточно 3–5 секунд аудио. Дипфейк-маска накладывается в реальном времени прямо в видеоконференции.
• Внутреннее доверие — вектор распространения. Письмо, пересланное коллегой в рабочий чат, воспринимается как легитимное. Горизонтальные связи внутри команды многократно расширяют охват атаки.
• Надёжная верификация — независимый канал. Любой неожиданный запрос, связанный с деньгами или доступами, подтверждается по отдельному, заранее известному каналу связи.
• Технический барьер работает там, где человек ошибается. Менеджер паролей не подставит учётные данные на поддельный сайт, даже если сотрудник не заметил подмены URL.

Ключевые векторы ИИ-атак на корпоративный периметр

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

Компрометация корпоративной электронной почты (BEC, Business Email Compromise) — целевая атака, при которой злоумышленники выдают себя за доверенных лиц (руководителей, партнёров, коллег), чтобы обманом вынудить сотрудника перевести деньги, раскрыть данные или выполнить вредоносное действие.

Почему BEC называют «многоканальной» атакой

Современные BEC-атаки редко ограничиваются одним письмом. Злоумышленники комбинируют несколько векторов воздействия одновременно:

• Имейл-спуфинг — подделка заголовков письма, чтобы адрес отправителя выглядел легитимно
• Похожие домены (Lookalike) — регистрация домена, визуально похожего на корпоративный (например, passw0rk.ru вместо passwork.ru)
• Социальная инженерия — давление через срочность, авторитет руководителя, имитацию знакомого контекста
• Телефонные звонки и мессенджеры — звонок «от директора» до или после письма снижает критическое мышление жертвы.

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

Чем BEC отличается от обычного фишинга

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

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

1. ИИ-фишинг: генерация писем и анализ контекста

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

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

2. Вишинг (Vishing): голосовые клоны руководителей

Вишинг (voice phishing) — телефонное мошенничество с использованием синтезированного голоса. Злоумышленник имитирует голос реального человека — руководителя, коллеги или партнёра — чтобы в телефонном разговоре получить доступ к данным или санкционировать финансовую операцию.

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

3. Дипфейк-видеоконференции: подделка лиц в реальном времени

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

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

Как сотрудники масштабируют атаку

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

Кейс Arup: дипфейк-звонок стоил компании $25.6 млн

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

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

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

Этот инцидент доказал: визуальная и голосовая верификация скомпрометирована.

Кейс StopPhish: 688 скомпрометированных пользователей

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

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

Как распознать ИИ-угрозу: чек-лист для сотрудников

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

Признаки текстовых ИИ-атак

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

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

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

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

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

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

• Реакция на перебивание. Живой человек собьётся, если его резко перебить. Голосовой бот либо продолжит говорить поверх вашего голоса с той же интонацией, либо ответит с неестественной задержкой (время на обработку вашего ответа нейросетью).

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

Маркеры видео-дипфейков

При видеозвонках алгоритмы генеративно-состязательных сетей (GAN) накладывают маску в реальном времени. Они уязвимы к динамическим изменениям:

• Маска на лице. Ранее популярный совет «попросить провести рукой перед лицом» больше не работает — современные нейросети научились обрабатывать частичное перекрытие. Чтобы алгоритм потерял трекинг и маска исказилась, нужно попросить собеседника закрыть руками значительную часть лица (например, оба глаза одновременно) или поднести к лицу полупрозрачный предмет (например, стакан с водой).
• Аномалии профиля. Попросите человека повернуться на 90 градусов. Большинство дипфейк-моделей плохо генерируют лицо сбоку, выдавая размытые края в области ушей и линии роста волос.

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

Алгоритм защиты: что делать сотруднику

Знания маркеров недостаточно, нужен жесткий протокол действий при малейших подозрениях.

Удобная точка отсчёта — четырёхшаговая модель Тревога → Пауза → Проверка → Действие:

• Тревога — зафиксируй эмоциональный триггер. Тебя торопят, пугают, льстят или интригуют? Само это ощущение — уже сигнал тревоги.
• Пауза  — намеренно сделай паузу перед любым действием. Срочность — инструмент манипуляции; легитимный запрос подождёт 60 секунд.
• Проверка  — подтверди запрос по независимому каналу. Не отвечай на подозрительное письмо — позвони отправителю по известному номеру.
• Действие — выполняй запрос только после верификации. Если проверить невозможно — эскалируй в службу безопасности.

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

На практике модель дополняется тремя конкретными техниками.

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

Как обучать персонал

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

1. Микрообучение на реальных инцидентах

Откажитесь от академичного подхода. Внедрите еженедельные спринты: один навык, один модуль на 3–5 минут.

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

2. Адаптивные симуляции атак

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

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

3. Культура нулевого наказания

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

• Поощряйте репорты. Сотрудник, который совершил ошибку, но немедленно сообщил о ней в службу информационной безопасности, должен быть поощрён, а не наказан. Он сэкономил компании миллионы на ликвидации последствий утечки.
• Упростите процесс связи. В почтовом клиенте и мессенджере должна быть одна заметная кнопка «Сообщить о подозрительном сообщении». В один клик письмо должно отправляться в отдел ИБ.

4. Централизованное управление паролями

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

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

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

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

Заключение

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

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

• Внедрить культуру «нулевого доверия». Любой неожиданный или подозрительный запрос, особенно связанный с финансами или доступами, должен верифицироваться через альтернативный, заранее оговорённый канал связи (например, звонок по мобильному номеру).
• Сместить фокус с обучения на архитектуру. Необходимо исходить из того, что человеческая ошибка неизбежна. Главной задачей становится построение ИБ-периметра, который технически минимизирует последствия одного неверного клика, а не пытается полностью их исключить.
• Автоматизировать проверку подлинности. Ключевая роль отводится инструментам, которые забирают у человека функцию верификации. Системы централизованного управления учётными данными, блокирующие ввод пароля на поддельных сайтах на уровне протокола, становятся базовым элементом защиты, страхующим от ошибок восприятия.

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

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

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

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

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

СберТех и Пассворк обеспечат защиту критичных данных российского бизнеса

Провели двустороннее тестирование и подписали сертификат совместимости, подтверждающий корректную и стабильную работу менеджера паролей Пассворк и СУБД Platform V Pangolin DB в единой инфраструктуре.

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

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

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

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

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

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

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

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

Зачем бизнесу ИБ-стратегия

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

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

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

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

1. Синхронизация с бизнес-целями и бизнес-процессами

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

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

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

2. Обоснование и оптимизация бюджета

В 2025 году 56% российских корпораций увеличили бюджет на кибербезопасность на 20–40%. Компании часто покупают дорогие решения, которые дублируют функции друг друга или закрывают неактуальные риски, оставляя пробелы в базовой защите.

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

3. Регуляторные требования и ответственность

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

• Указ Президента № 250 (в ред. Указа №500 от 13.06.2024). С 1 января 2025 года госорганам, госкорпорациям и субъектам КИИ запрещено использовать средства защиты информации из недружественных стран, а также пользоваться ИБ-сервисами организаций из таких стран.
• 187-ФЗ «О безопасности КИИ». С сентября 2025 года требования к объектам критической информационной инфраструктуры включают обязательный поэтапный переход на программно-аппаратные комплексы (ПАК) и российское ПО. Процесс категорирования и мониторинга становится более строгим
• Оборотные штрафы. Федеральный закон №420-ФЗ внёс поправки в КоАП РФ: за повторную утечку персональных данных предусмотрен оборотный штраф от 1% до 3% годовой выручки, но не менее 20 млн и не более 500 млн рублей.

Для бизнеса это означает, что ИБ становится не только вопросом защиты, но и финансовой ответственности.

Уровень зрелости информационной безопасности в России

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

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

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

4 этапа разработки стратегии ИБ

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

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

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

Что нужно учесть

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

• Теневые ИТ (Shadow IT). Сервисы и облака, которые сотрудники используют без ведома ИТ-отдела.
• Устаревшие системы. Заброшенные серверы, тестовые среды, временные решения, которые работают годами.
• Доступы. Кто имеет административные права, какие есть учётные записи у подрядчиков, как выдаются и отзываются доступы.
• Учётные записи и идентичности. Дублирующиеся аккаунты, неактивные пользователи, общие пароли.
• Критичность активов. Какие системы действительно важны для бизнеса и требуют приоритетной защиты.
• Точки входа. Удалённые доступы, API, веб-интерфейсы — всё, через что можно попасть внутрь.

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

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

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

Этап 2. Оценка рисков и моделирование угроз

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

Что делаем на практике

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

1. Идентификация угроз. Формируем перечень возможных сценариев:

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

2. Привязка к активам. Каждую угрозу важно связать с конкретными активами из этапа 1:

• какой системе угрожает риск
• какие данные могут пострадать
• какой бизнес-процесс будет затронут

3. Оценка вероятности и ущерба. Используются два подхода:

• качественный: высокий / средний / низкий
• количественный: в деньгах (потери от простоя, штрафы, недополученная выручка)

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

4. Сценарный анализ. Что конкретно произойдёт, если риск реализуется? Проанализируйте гипотетические ситуации, например: компрометация учётной записи → доступ к сервисам или почте → перемещение по сети → получение прав администратора → доступ к критическим системам или данным. Такие цепочки помогают понять, где именно нужно усиливать защиту.

5. Принятие рисков. Определяем, какие потери бизнес готов принять:

• простой сайта на 1 час — допустимо
• остановка производства или логистики — критично

6. Приоритизация рисков. Формируем список приоритетов:

• какие риски нужно закрывать в первую очередь
• где достаточно снизить вероятность
• где риск можно принять

Результат этапа: собраны конкретные риски с приоритетами, привязанные к бизнес-ущербу, а не к абстрактным угрозам.

Этап 3. Целевое состояние

Каким должен быть уровень ИБ через 2–3 года? Цель должна быть реалистичной и соответствовать масштабу и задачам бизнеса. Избыточные меры безопасности могут замедлять процессы и создавать лишние затраты, поэтому важно найти баланс.

Метрики целевого состояния

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

Операционная эффективность:

• MTTD — сокращение времени обнаружения инцидента с 48 до 4 часов
• MTTR — сокращение времени реагирования с 10 до 1 часа

Контроль инфраструктуры:

• 100% критичных активов охвачены мониторингом
• 90–100% доступов централизованно управляются

Управление учётными записями:

• нет аккаунтов уволенных сотрудников
• все администраторские права задокументированы
• ревизии проводятся по регламенту

Осведомлённость персонала:

• 95–100% сотрудников прошли обучение по ИБ
• доля кликов в фишинговых симуляциях — не более 5%

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

Нормативная база

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

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

Этап 4. Дорожная карта

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

0–6 месяцев: критические риски

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

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

6–18 месяцев: системное развитие

• Что делаем: внедряем SIEM/SOC, сегментируем сеть, подключаем DLP, формализуем процессы реагирования на инциденты.
• Результат: появляется прозрачность — компания видит атаки и может на них реагировать.

18–36 месяцев: зрелая ИБ

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

Быстрые меры — без ожидания стратегии

Снизить риски можно уже сейчас, не дожидаясь завершения всех этапов:

• включить MFA для всех критичных доступов
• провести аудит администраторских прав
• отключить неиспользуемые учётные записи
• централизовать хранение паролей

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

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

Инхаус или аутсорс

Кто должен писать стратегию ИБ — зависит от ресурсов и зрелости компании.

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

Рекомендация: при выборе подрядчика запросите лицензии ФСТЭК (для работы с ТЗКИ) и кейсы с клиентами из вашей отрасли.

Типичные ошибки

Большинство инцидентов происходит из-за базовых ошибок в процессах и управлении доступами:

Безопасность только на словах

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

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

Инструменты вместо процессов

Компания внедряет дорогие решения (SIEM, DLP, EDR), но не выстраивает процессы и не назначает ответственных — в итоге инструменты работают впустую.

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

Разрыв между ИБ и ИТ

ИБ и ИТ работают разрозненно: безопасность блокирует, ИТ ищет обходные пути.

Что делать: выстраивать единый контур управления. Практика DevSecOps помогает встроить безопасность в процессы разработки и эксплуатации.

Игнорирование человеческого фактора

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

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

Отсутствие метрик

Без измерений невозможно понять, работает ли ИБ. Часто ориентируются на количество атак, что не отражает реальной эффективности.

Что делать: внедрять прикладные метрики — MTTD, MTTR, доля покрытых активов, время закрытия уязвимостей, процент актуальных доступов. Метрики должны быть связаны с бизнес-рисками.

Заключение

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

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

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

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

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

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

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

СберТех и Пассворк обеспечат защиту критичных данных российского бизнеса

Провели двустороннее тестирование и подписали сертификат совместимости, подтверждающий корректную и стабильную работу менеджера паролей Пассворк и СУБД Platform V Pangolin DB в единой инфраструктуре.

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

Кибератаки 2025: статистика, векторы атак и главные уязвимости

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

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

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

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

Но брутфорс уже далеко не главная угроза и вектор атаки. В 2025 году инфостилеры похитили 1,8 млрд учётных данных c 5.8 млрд устройств, что на 800% больше чем в 2024. Ни один из этих инцидентов не потребовал от атакующего взломать хотя бы один пароль.

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

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

Что такое взлом паролей

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

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

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

Эволюция угроз: от перебора к краже

Брутфорс образца 2010-х уступил место индустриальным схемам кражи. Сегодня работает модель «вредоносное ПО как услуга» (Malware-as-a-Service, MaaS). Злоумышленник арендует готовый инфостилер, разворачивает фишинговую кампанию и получает тысячи свежих учётных данных без единой строки собственного кода.

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

Результат: в 2025 году вредоносное ПО применялось в 71% атак на организации, социальная инженерия — в 51% (данные Positive Technologies).

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

Топ-11 способов взлома и кражи паролей в 2026 году

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

Инфостилеры — главная угроза 2026 года

Инфостилер — вредоносная программа, созданная для одной цели: собрать учётные данные и другую чувствительную информацию с заражённого устройства и передать их атакующему. Наиболее активные семейства в 2025–2026 годах: Lumma Stealer, StealC V2, Acreed, Vidar.

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

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

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

Меры противодействия

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

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

Как помогает Пассворк

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

Подстановка учётных данных

Подстановка учётных данных (Credential Stuffing) — автоматизированная атака, при которой пары логин/пароль из утечек проверяются против других сервисов. Расчёт на человеческую привычку использовать один и тот же пароль везде.

Схема проста. Злоумышленник покупает на теневом рынке свежую базу скомпрометированных учётных записей (например, 10 миллионов пар логин/пароль со взломанного интернет-магазина). Загружает её в специализированный инструмент (OpenBullet, SilverBullet или аналог) и запускает автоматическую проверку против целевых сервисов: корпоративной почты, банковских кабинетов, облачных хранилищ. Инструмент имитирует поведение реального пользователя, обходит капчу и распределяет запросы через прокси-сети, чтобы не попасть под блокировку по IP. Тысячи проверок в час без участия человека.

Конверсия невысокая, но объём это компенсирует. Даже 0,5% успешных входов из базы в 10 млн — это 50 000 взломанных аккаунтов. Часть уходит на продажу, часть используется для дальнейшего проникновения в корпоративную инфраструктуру.

Меры противодействия

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

Как помогает Пассворк

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

AiTM-фишинг и обход многофакторной аутентификации (MFA)

Злоумышленник посередине (Adversary-in-the-Middle, AiTM) — атака, при которой злоумышленник размещает прокси-сервер между жертвой и легитимным сервисом, перехватывая не только учётные данные, но и сессионные токены уже после успешной аутентификации. Именно это делает AiTM опасным даже при включённой двухфакторной аутентификации. AiTM — это усовершенствованная форма атаки «Человек посередине» (Man-in-the-middle, MITM).

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

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

1. Жертва получает фишинговое письмо со ссылкой на убедительную копию страницы входа — например, в корпоративный портал на базе 1С:Предприятие или Битрикс24
2. Ссылка ведёт на прокси-сервер злоумышленника, который в реальном времени транслирует все запросы на легитимный сервер
3. Жертва видит привычный интерфейс и вводит логин, пароль и код из приложения-аутентификатора
4. Прокси перехватывает все данные и передаёт их на легитимный сервер
5. Легитимный сервер выдаёт сессионный токен — прокси его перехватывает
6. Злоумышленник использует токен для входа: без пароля, без MFA-кода, с уже аутентифицированной сессией

Меры противодействия

Единственная надёжная защита от AiTM — аппаратные ключи FIDO2 или ключи доступа (passkeys), криптографически привязанные к конкретному домену. Дополнительно — обучение сотрудников распознавать фишинговые письма и политика проверки URL-адресов перед вводом учётных данных.

ИИ-брутфорс и PassGAN

PassGAN (Password Generative Adversarial Network) — генеративно-состязательная сеть, обученная на реальных утечках паролей. Принципиальное отличие от классического брутфорса: она не перебирает все возможные комбинации подряд, а генерирует вероятные пароли, воспроизводя паттерны человеческого мышления.

Люди предсказуемы при создании паролей: мы заменяем a на @, o на 0, e на 3, добавляем ! или 123 в конце, используем имена, даты рождения, названия любимых спортивных команд. PassGAN обучена распознавать и воспроизводить именно эти паттерны — быстрее и точнее любого статичного словаря.

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

Меры противодействия

Минимальная длина пароля — 15 символов со случайным набором символов без предсказуемой структуры (рекомендация NIST SP 800-63B). Чем выше энтропия пароля, тем больше вариантов перебирает атакующий.

Проверьте надёжность своих паролей

Как помогает Пассворк

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

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

Уязвимость паролей, сгенерированных LLM

Парадокс 2026 года: люди просят ChatGPT, Gemini или Claude придумать «надёжный пароль» — и получают предсказуемый результат. Исследование Irregular Security (2025) доказало: языковые модели генерируют пароли по устойчивым, воспроизводимым шаблонам.

LLM обучены на человеческих текстах. Они знают, как люди придумывают пароли, какие слова считают случайными, какие символы добавляют для сложности. Модель воспроизводит именно эти паттерны — те самые, которые атакуют PassGAN и перебор по словарю (Dictionary Attack).

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

Меры противодействия

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

Как помогает Пассворк

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

Социальная инженерия и аудиодипфейки

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

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

В 2024–2025 годах оба инструмента стали общедоступны. Злоумышленнику достаточно 10–30 секунд аудиозаписи из публичного источника (записи вебинара, корпоративного подкаста, видео с конференции), чтобы синтезировать убедительный голос руководителя.

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

• Вишинг с клонированием голоса. Сотрудник получает звонок от «директора» или «поддержки» с просьбой срочно продиктовать временный пароль, код из SMS или данные для входа в систему. Голос звучит знакомо, интонации совпадают, контекст правдоподобен.
• Дипфейк-видеозвонок. В 2025 году зафиксированы случаи, когда злоумышленники проводили видеозвонки в Zoom с имитацией руководителей компании, убеждая сотрудников финансовых отделов провести срочные переводы или предоставить доступ к системам.
• Целевой фишинг (spear phishing) с ИИ. Языковые модели анализируют профили сотрудника в социальных сетях, его посты и корпоративные новости и генерируют письмо, неотличимое от сообщения коллеги. Такие письма открывают в разы чаще, чем шаблонный фишинг.

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

Меры противодействия

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

Как помогает Пассворк

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

SIM-свопинг (подмена SIM-карты)

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

Методы: социальная инженерия через колл-центр оператора, подкуп сотрудника, поддельные документы о потере SIM. После успешной подмены все SMS с кодами подтверждения приходят злоумышленнику. Дальнейшая схема тривиальна: «Забыли пароль?» → ввод нового пароля через SMS-код → полный доступ к аккаунту.

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

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

Меры противодействия

Замените SMS-коды на более надёжные факторы аутентификации: TOTP-приложения (Пассворк 2ФА, любой совместимый аутентификатор) или аппаратные FIDO2-ключи. Отключите восстановление доступа через SMS там, где это возможно. Для корпоративных аккаунтов руководителей и ИТ-персонала — аппаратный ключ обязателен.

Как помогает Пассворк

SIM-свопинг опасен, когда доступ к сбросу пароля можно получить через SMS. Пассворк исключает этот сценарий для корпоративных учётных записей. Менеджер паролей поддерживает многофакторную аутентификацию на основе биометрии, ключей доступа (passkeys) и физических ключей безопасности FIDO2.

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

Атака по словарю (перебор по словарю)

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

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

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

Что включает словарь 2026 года:

• Все крупные утечки последних лет — включая мега-утечку 2025 года с 16 млрд паролей. Если пароль когда-либо утекал, он уже в словаре.
• Актуальный сленг, мемы, культурные отсылки текущего года.
• Типичные корпоративные паттерны: Vpered2026!, Dobro_pozhalovat1, Admin123, Buhgalteriya2026!.
• Региональные особенности: транслитерации (parol, privet, lyubov), популярные имена (Aleksey1990, Natasha123), названия городов (Moskva2026, Spb1234)
• Вариации с заменой символов: p@rol, Pr1vet!, p@ssw0rd123.
• Комбинации из предыдущих паролей жертвы — если они утекали ранее, атакующий знает логику их составления и строит вариации на её основе.

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

Меры противодействия

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

Как помогает Пассворк

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

Распыление паролей

Распыление паролей (Password Spraying) — атака, при которой злоумышленник берёт 1–3 наиболее распространённых пароля и последовательно проверяет их против тысяч учётных записей. Там, где брутфорс бьёт в один аккаунт тысячами паролей и быстро блокируется, распыление паролей делает наоборот.

Логика проста: если в организации работают 500 человек, статистически несколько из них используют Privet1 или МесяцГод!. Атака медленная, целенаправленная — именно поэтому она не вызывает триггеров блокировки по числу попыток на один аккаунт.

Меры противодействия

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

Как помогает Пассворк

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

Перехват через публичный Wi-Fi (MitM)

Атака «человек посередине» (Man-in-the-Middle, MitM) — перехват трафика между пользователем и сервером, при котором злоумышленник незаметно встраивается в канал связи. Открытые сети в кафе, аэропортах, отелях и коворкингах остаются рабочим вектором, несмотря на широкое распространение HTTPS.

Злоумышленник разворачивает точку доступа с названием, имитирующим легитимную сеть (Airport_Free_WiFi_5G, Vkusno_Guest), и перехватывает трафик подключившихся.

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

Меры противодействия

Включите HSTS (HTTP Strict Transport Security) на корпоративных веб-ресурсах. Проведите обучение сотрудников: публичные сети — зона повышенного риска, и корпоративные задачи в них требуют дополнительных мер защиты.

Как помогает Пассворк

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

Человек в браузере

Человек в браузере (Man-in-the-Browser, MitB)— атака через вредоносное расширение браузера, которое перехватывает и модифицирует данные непосредственно внутри браузера, до их шифрования и отправки на сервер.

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

Что умеет MitB-расширение:

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

В отличие от инфостилера, MitB работает прямо внутри браузера, не требует прав администратора и часто не детектируется антивирусом — потому что с точки зрения системы это легитимное расширение с разрешёнными правами. В 2025 году зафиксированы случаи, когда вредоносные расширения проходили проверку Chrome Web Store и набирали сотни тысяч установок до обнаружения.

Меры противодействия

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

Как помогает Пассворк

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

Как защитить свои пароли в 2026 году

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

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

• Уберите пароли из браузера
• Откажитесь от SMS как второго фактора
• Не генерируйте пароли через нейросети
• Проверяйте расширения браузера
• Избегайте публичного Wi-Fi для рабочих задач

Для ИТ-команд и руководителей

• Внедрите корпоративный менеджер паролей
• Настройте мониторинг скомпрометированных учётных данных
• Введите фишинго-устойчивую MFA на основе FIDO2 и ключей доступа (passkeys)
• Ограничьте расширения браузера через групповые политик
• Проводите симулированные фишинговые тесты с разбором ошибок

Централизованное управление паролями закрывает сразу несколько векторов из этого списка.

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

Заключение

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

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

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

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

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

Кибератаки 2025: статистика, векторы атак и главные уязвимости

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

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

Внедрение менеджера паролей: пошаговое руководство

Сисадмин пересылает SSH-ключи в мессенджере. Уволенный сотрудник до сих пор получает рассылку с данными клиентов. Стажёр с правами администратора. Знакомо? Рассмотрим, как ИТ-отделу взять доступы под контроль — от первого аудита до работающей системы.

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

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

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

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

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

В 2025 году от массовых веерных рассылок злоумышленники перешли к точечным операциям по уничтожению. Около 76% атак на российские компании в 2025 году сопровождались деструктивными действиями, например, шифрованием данных и удалением информации. Атаки стали точнее и дороже. Цель сместилась от кражи данных к уничтожению инфраструктуры, что принципиально меняет логику построения защиты для компаний.

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

Главное

• Цель атак сменилась — хакеры уничтожают инфраструктуру, а не просто крадут данные. Подавляющая часть инцидентов в 2025 году включали шифрование, уничтожение данных или вывод систем из строя.
• APT-группировок стало вдвое больше — профессиональные группировки месяцами остаются незамеченными внутри сети, изучают инфраструктуру и готовят максимально разрушительный удар.
• Главные векторы входа не изменились — уязвимости в веб-приложениях (31% атак), скомпрометированные учётные данные, фишинг и атаки через подрядчиков.
• Регулирование ужесточилось — поправки к 152-ФЗ и изменения в КоАП РФ (Федеральный закон № 420-ФЗ от 30.11.2024) ввели оборотные штрафы до 3% годовой выручки (минимальная сумма такого штрафа составляет 20 млн рублей, а максимальная — 500 млн рублей). Утечка данных — прямой финансовый риск.
• Управление паролями закрывает один из самых распространённых векторов — MFA и корпоративный менеджер паролей исключают вход по украденным и повторно используемым паролям.

Как изменилось число атак

Динамика в России

Российские организации в 2025 году столкнулись с беспрецедентным давлением. Число профессиональных хакерских группировок, атакующих бизнес, выросло вдвое. Если в 2024 году фиксировались единичные APT-кампании, то к концу 2025-го выявили не менее 18 активных группировок.

Показательна динамика заражений вредоносным ПО: в октябре 2025 года среднее число срабатываний на вредоносное ПО на одну компанию достигло 99 — рост в 2,5 раза за год.

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

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

Мировой контекст

Глобальная картина подтверждает тренд. По данным 2025 Official Cybercrime Report компании Cybersecurity Ventures, совокупный ущерб от киберпреступности в 2025 году достигнет $10,5 трлн. Для сравнения, это превышает ВВП большинства стран мира.

Вредоносное ПО применялось в 71% атак на организации, социальная инженерия — в 51%. Эти векторы работают в связке, усиливая друг друга. По данным Verizon DBIR 2025, «человеческий фактор» присутствует в 60% всех утечек данных. Тем временем база уязвимостей CVE к концу 2025 года превысила 308 000 записей — только за год добавлено рекордные 48 185 новых CVE, что на 20% больше, чем в 2024 году. Темп обнаружения новых уязвимостей опережает возможности их устранения в большинстве компаний.

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

Главные уязвимости

База знаний тактик и техник хакеров MITRE выделяет три неизменные ключевые уязвимости, на которые пока не влияет развитие технологий:

1. CWE-79 (XSS). Внедрение скриптов. Используется для кражи сессий и перенаправления на фишинг.
2. CWE-89 (SQL-инъекция). Позволяет читать и менять базы данных. Автоматизируется инструментами типа sqlmap.
3. CWE-352 (CSRF). Подделка межсайтовых запросов, заставляющая браузер жертвы выполнять действия без её ведома.

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

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

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

Топ векторов атак в 2025 году

Уязвимости в веб-приложениях

Веб-приложения остаются главной точкой входа — 31% всех успешных атак начинаются здесь. Периметр компании постоянно расширяется: выходят обновления, появляются новые сервисы, API и интеграции. Безопасность не всегда успевает за скоростью разработки. Уязвимости типа XSS, SQL-инъекции и CSRF присутствуют в большинстве корпоративных приложений.

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

Скомпрометированные учётные данные

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

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

Фишинг и социальная инженерия

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

Атаки через подрядчиков

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

Утечки данных в России

В 2025 году зафиксировано 230 публичных утечек из российских компаний. В 64% успешных атак происходит утечка конфиденциальной информации:

• 19% — коммерческая тайна и финансовые данные
• 19% — учётные данные (логины, пароли, токены)
• 18% — персональные данные сотрудников и клиентов

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

Профессиональные хакерские группировки

Число APT-группировок (Advanced Persistent Threat), работающих в России, выросло более чем вдвое. Причины роста: геополитика, снижение стоимости инструментов и высокая доходность киберпреступлений.

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

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

Ситуацию осложняет ужесточение регулирования в сфере персональных данных. Поправки к Федеральному закону № 152-ФЗ «О персональных данных» и изменения в КоАП РФ, внесённые Федеральным законом № 420-ФЗ от 30 ноября 2024 года, ввели более строгую ответственность за утечки.

Как защититься от современных атак

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

Защита от эксплуатации уязвимостей

Задача: знать уязвимости в ИБ своей компании лучше атакующего.

Управление учётными данными

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

Противодействие фишингу

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

Контроль подрядчиков

Доверенные каналы чаще всего самые опасные.

Прогнозы на 2026 год

Тенденции, которые определят ландшафт угроз в ближайшем будущем:

1. ИИ-атаки станут нормой. Генеративный ИИ окончательно закрепится как стандартный инструмент для фишинга и написания кода.
2. Рост APT-активности. Геополитика продолжит стимулировать атаки на КИИ, промышленность и госсектор.
3. Регуляторное давление. Оборотные штрафы заставят бизнес инвестировать в реальную безопасность.
4. Атаки на OT/ICS. Промышленные системы всё чаще становятся целью для нанесения физического урона.
5. Патчинг — конкурентное преимущество. Регулярная установка обновлений на ПО, ОС и оборудование поможет закрывать критические CVE быстрее, чем их начнут эксплуатировать массово.

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

Заключение

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

1. Контроль. Обнаружение важнее предотвращения — нужно искать следы присутствия хакеров внутри сети.
2. Скорость реакции на инциденты. Критические уязвимости нужно закрывать немедленно и быть к этому готовым.
3. Гигиена доступов. Около 22% атак происходят с помощью паролей, это недопустимо высокий риск, который легко устраняется.

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

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

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

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

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

Пассворк запустил программу поиска уязвимостей на площадке Standoff Bug Bounty

Пассворк запустил программу поиска уязвимостей на площадке Standoff Bug Bounty — крупнейшей российской багбаунти-платформе. Теперь безопасность Пассворка проверяют более 30 000 независимых экспертов. Это важный этап нашей стратегии безопасности: мы выявляем и устраняем потенциальные уязвимости до того, как они станут проблемой. Безопасность как фундамент Согласно исследованию Positive Technologies, 36% успешных кибератак

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

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

Разбираем, как выбрать корпоративный менеджер паролей, почему локальное развёртывание безопаснее облака и как ИТ-отделу взять под контроль все доступы компании всего за 1–2 дня.

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

Ваш сисадмин пересылает SSH-ключи через мессенджер в файле «точнонепароли.txt». Ваш HR-менеджер хранит сканы паспортов сотрудников в личной почте в Яндексе. Стажёру выдали права администратора, потому что разбираться с разграничением доступа было некогда. А сотрудник, которого уволили в 2019 году, до сих пор получает еженедельную рассылку с данными клиентов, ведь его электронный адрес просто никто не удалил.

В 2025 году аналитики зафиксировали 230 публичных утечек баз данных российских организаций, а суммарный объём опубликованных данных достиг 767 млн строк — в 1,5 раза больше, чем годом ранее. Большинство инцидентов начинаются одинаково: сотрудник хранит пароль в таблице, браузере или мессенджере. Злоумышленник получает учётные данные, и дальше всё происходит по известному сценарию.

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

Риски хранения паролей в ненадёжных инструментах

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

• Пароли CRM в Excel на сетевом диске. Файл доступен всем, у кого есть доступ к папке. Версионирования нет. Непонятно, кто и когда менял пароль. Результат: бывший менеджер через полгода заходит в CRM и выгружает базу клиентов.
• Доступы передают в чате. Пароль уходит в мессенджер или корпоративную почту и остаётся там навсегда. История переписки не шифруется, не удаляется и доступна всем участникам чата. Через год канал взломали: злоумышленники получили всю историю, включая административные доступы.
• Облачные доступы в памяти администратора. Если сотрудник увольняется или уходит на больничный, доступ теряется вместе с ним. Кейс: единственный человек, знавший пароль от DNS-провайдера, уволился. Компания потеряла контроль над доменом на три дня.
• Нет контроля и аудита. Невозможно ответить: кто заходил в систему, когда и откуда. После утечки из бухгалтерской системы выяснилось, что доступ использовали пять человек с одного логина. Установить виновного оказалось невозможно.
• Пароли в браузере на рабочем ПК. Сотрудники сохраняют доступы в Chrome или Firefox без мастер-пароля. При заражении устройства вредоносным ПО все сохранённые пароли извлекаются за секунды.
• Повторное использование одного пароля. Один и тот же пароль применяют для разных систем: от корпоративной почты до панели управления сервером. Компрометация одного сервиса автоматически открывает доступ ко всем остальным.

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

Масштаб проблемы подтверждается цифрами. Учётные данные остаются одним из главных векторов атак. Около 88% инцидентов в мире в категории атак на веб-приложения связаны с использованием украденных учётных данных. Средняя стоимость утечки данных в мире составляет около $4,44 млн, включая расследование, простои систем, юридические расходы и восстановление инфраструктуры.

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

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

Регуляторный контекст 2026

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

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

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

Приказ ФСТЭК России № 117

1 марта 2026 года вступил в силу приказ ФСТЭК России № 117 от 11 апреля 2025 года. Документ пришёл на смену приказу № 17 от 11 февраля 2013 года и расширил сферу регулирования. Прежние требования распространялись на государственные информационные системы (распространение на муниципальные ИС было закреплено отдельным разъяснением ФСТЭК, а не текстом самого приказа).

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

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

С 30 мая 2025 года вступили в силу поправки, внесённые Федеральным законом № 420-ФЗ от 30 ноября 2024 года в КоАП РФ, которые существенно ужесточили ответственность за утечки персональных данных. Согласно КоАП РФ в действующей редакции, штраф за первичную утечку для юридических лиц составляет от 3 до 20 млн рублей в зависимости от масштаба инцидента и категории данных (максимум — за утечку биометрических данных); за повторную утечку предусмотрен оборотный штраф в размере от 1% до 3% годовой выручки, но не менее 20 млн рублей и не более 500 млн рублей.

С чего начать внедрение менеджера паролей

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

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

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

Шаг 1. Аудит

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

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

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

1. Инвентаризация всех корпоративных учётных записей: сервисы, серверы, SaaS-приложения, сетевое оборудование. Цель — полный реестр, без исключений.
2. Выявление «теневых» аккаунтов: личные облачные сервисы для рабочих задач, неучтённые подписки — всё, что создано без ведома ИТ-отдела. Именно здесь чаще всего обнаруживаются неожиданные цифры.
3. Подсчёт привилегированных учётных записей: admin, root, сервисные учётные записи и записи с правами доступа к критическим системам.
4. Анализ текущих практик хранения: опрос сотрудников на предмет использования таблиц, блокнотов, стикеров, браузерных менеджеров паролей, мессенджеров, личных сервисов для хранения данных.
5. Оценка количества общих паролей: один логин на несколько сотрудников (типично для Wi-Fi, принтеров, общих почтовых ящиков, соцсетей).
6. Проверка процедуры увольнения: сколько времени фактически занимает отзыв всех доступов при увольнении. Зафиксируйте реальную цифру.

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

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

• AD/LDAP-запросы. Базовый инструмент для любой организации с Active Directory или LDAP-каталогом. Даёт выгрузку всех пользователей и групп с атрибутами: дата последнего входа, статус учётной записи, членство в группах. Учётные записи без активности за последние 90 дней — первые кандидаты на деактивацию. Отдельно стоит выгрузить сервисные аккаунты: они часто не привязаны к конкретному сотруднику и выпадают из регулярных проверок.
• Анализ логов. Логи прокси-сервера и корпоративной почты позволяют обнаружить активность аккаунтов уволенных сотрудников и нетипичные паттерны доступа — например, подключения в нерабочее время или с нестандартных адресов. Это отдельный слой данных, который AD-запросы не покрывают.
• SIEM и системы мониторинга. Если в инфраструктуре уже развёрнут SIEM, он агрегирует события из множества источников и позволяет построить сводную картину по учётным записям быстрее, чем ручная выгрузка из каждой системы по отдельности.
• Опрос руководителей подразделений. Технические инструменты не видят сервисы, которые отделы подключают самостоятельно в обход ИТ. Короткий структурированный опрос с тремя вопросами: какие внешние сервисы использует отдел, кто имеет к ним доступ, где хранятся учётные данные — закрывает этот пробел. Ответы руководителей нередко становятся главным источником данных о теневых аккаунтах.
• Сканирование SaaS-активности. Корпоративные SSO-решения ведут журнал подключённых приложений.

Шаг 2. Выбор решения для хранения паролей

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

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

Локальное развёртывание или облако

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

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

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

Интеграция со службами каталогов и SSO

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

Интеграция с AD/LDAP также упрощает управление ролями. Группы из каталога напрямую интегрируются с ролями в корпоративном менеджере паролей. Изменение состава группы в AD мгновенно отражается в правах доступа.

Поддержка Single Sign-On (SSO) позволяет сотрудникам входить в менеджер паролей через корпоративную учётную запись, не создавая отдельного пароля.

Ролевая модель (RBAC)

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

Ролевая модель на основе RBAC (Role-Based Access Control) позволяет назначать права не каждому пользователю отдельно, а ролям — и затем присваивать роли пользователям.

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

Многофакторная аутентификация (MFA)

Наиболее распространённый второй фактор — TOTP (Time-based One-Time Password): одноразовый код из приложения-аутентификатора, который обновляется каждые 30 секунд. Это надёжный и удобный вариант, не требующий дополнительного оборудования. Для организаций с повышенными требованиями к безопасности предпочтительнее аппаратные ключи — FIDO2/WebAuthn-устройства, которые физически невозможно перехватить удалённо.

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

Аудит и логирование

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

API и интеграции

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

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

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

Реестр российского ПО

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

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

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

Сертификат ФСТЭК России

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

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

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

Пассворк: комплексная защита паролей и секретов

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

• Независимая проверка безопасности. Безопасность Пассворка верифицируют 30 000 независимых экспертов на платформе Standoff Bug Bounty. Это программа вознаграждения за найденные уязвимости, один из наиболее честных способов подтвердить реальный уровень защиты продукта.
• Реальные внедрения в крупном бизнесе. Среди клиентов — МТС Банк, который внедрил Пассворк для централизованного управления паролями и повышения уровня безопасности, Nexign — один из крупнейших российских разработчиков телеком-решений.
• Признание рынка. В 2025 году Пассворк стал победителем премии ComNews Awards в категории «Лучшее решение для работы с паролями в компании», в 2026 — получил «ТБ Премию 2026», эксперты признали продукт надёжным корпоративным решением для безопасного хранения и управления секретами.

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

Шаг 3. Техническое развёртывание

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

План развёртывания

1. Подготовка инфраструктуры. Выделить сервер, настроить сетевую сегментацию — хранилище паролей не должно быть доступно из интернета напрямую.
2. Установка приложения. Docker-контейнер — предпочтительный вариант: изолированная среда, простое обновление, воспроизводимая конфигурация. Нативная установка используется там, где Docker недоступен по политике безопасности.
3. Первоначальная конфигурация. Настройка подключения к базе данных, генерация мастер-ключа шифрования. Мастер-ключ хранится отдельно от базы данных, это критичное требование, которое часто игнорируют при быстром развёртывании.
4. Настройка резервного копирования. Ежедневный бэкап зашифрованного хранилища на отдельный сервер или в изолированное хранилище. Настроить нужно до миграции данных.
5. Интеграция с AD/LDAP. Синхронизация пользователей и групп. Проверить, что группы Active Directory корректно сопоставлены с ролями в менеджере паролей.

Тестирование и приёмка: проверить доступность интерфейса, корректность синхронизации с AD, успешность первого резервного копирования. Только после успешного прохождения всех проверок переходить к Шагу 4.

Шаг 4. Настройка системы

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

Структура хранилища

Хранилище паролей должно отражать реальную организационную схему компании. Базовый принцип — разделение по подразделениям и типам доступа. Типовая структура: отдельные сейфы для ИТ-инфраструктуры, финансов, кадров, маркетинга. Внутри каждого сейфа — папки по проектам, сервисам или средам (production, staging, dev).

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

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

Системные настройки

• Первое — управление сессиями. Установите таймаут автоматического выхода: 15–30 минут бездействия — разумный баланс между безопасностью и удобством. Для администраторов таймаут стоит сократить.
• Второе — ограничения по IP и устройствам. Если менеджер паролей используется только внутри корпоративной сети, ограничьте доступ на уровне сетевых политик. Это дополнительный барьер, который не требует изменений в самом приложении.
• Третье — многофакторная аутентификация. Подключите TOTP-приложение или аппаратный ключ в настройках безопасности. Сделайте многофакторную аутентификацию обязательной на уровне политики: система не должна разрешать вход без второго фактора ни одному пользователю, включая администраторов.

Роли и права доступа

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

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

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

Шаг 5. Миграция и онбординг

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

Вариант 1: первый менеджер паролей

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

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

Вариант 2: переход с другого менеджера паролей

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

Запустите параллельную работу двух систем на 1–2 недели. За это время сотрудники убедятся, что все данные перенесены корректно, — и только после этого отключайте старую систему.

Онбординг сотрудников

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

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

Канал поддержки. В первую неделю выделите отдельный канал в корпоративном мессенджере, где ИТ-специалисты смогут оперативно отвечать на вопросы. Это снижает сопротивление и формирует привычку работать с системой.

Шаг 6. Мониторинг и аудит

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

Квартальное ревью доступов

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

Интеграция с SIEM

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

• Сценарий 1 — вход в нерабочее время.
  Попытка аутентификации в хранилище в 3:00 + VPN-соединение с нетипичного IP-адреса. Каждое событие по отдельности — не критично. Вместе — сигнал для немедленного расследования.
• Сценарий 2 — массовая выгрузка перед увольнением.
  Сотрудник экспортировал значительное количество записей за 48 часов до подачи заявления об уходе. Журнал аудита фиксирует каждую операцию экспорта с временной меткой и идентификатором пользователя.
• Сценарий 3 — брутфорс мастер-пароля.
  Серия неудачных попыток входа с одного устройства за короткий промежуток времени. SIEM коррелирует это с аналогичными попытками в других корпоративных системах.

Резервное копирование

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

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

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

Заключение

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

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

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

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

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

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

Нужно ли менять все пароли перед миграцией в новое хранилище?

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

Подходит ли корпоративный менеджер паролей для госсектора и субъектов КИИ?

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

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

При настроенной интеграции с AD/LDAP деактивация учётной записи в Active Directory автоматически отзывает доступ к хранилищу. Пассворк формирует список паролей, к которым имел доступ сотрудник, — их необходимо сменить в течение 24 часов. Целевое время полного офбординга — менее четырёх часов с момента увольнения.

Насколько безопасно хранить все пароли в одном месте?

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

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

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

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

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

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

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

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

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

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

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

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

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

За восемь месяцев 2025 года кибератаки обошлись российской экономике в 1,5 трлн рублей. Каждая восьмая из десяти компаний малого и среднего бизнеса пережила минимум один киберинцидент, и по данным Positive Technologies, Россия входит в топ мировых целей: на неё приходится 14–16% всех успешных атак. В 2026 году их число может вырасти ещё на 30–35%.

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

Три года назад кибербезопасность была головной болью ИТ-отдела. Сегодня это вопрос выживания бизнеса и личной ответственности руководителя. Новое законодательство закрепляет эту ответственность: с 2025–2026 годов штрафы за утечки данных достигают 3% от годового оборота компании. В этой статье расскажем, какие угрозы актуальны прямо сейчас, что изменилось в законодательстве и как выстроить систему защиты бизнеса.

Ландшафт киберугроз 2026

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

Фишинг и социальная инженерия

Фишинг, рассылка поддельных писем и сообщений для кражи учётных данных или установки вредоносного ПО, остаётся главным способом проникновения в корпоративные системы. По данным Positive Technologies, в первом полугодии 2025 года социальная инженерия применялась в 50% успешных атак на организации, а основным каналом её распространения остаётся электронная почта — она используется в 88% случаев атак на компании с применением социальной инженерии.

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

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

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

Программы-вымогатели

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

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

Атаки на цепочки поставок

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

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

DDoS-атаки и другие актуальные угрозы

DDoS-атаки (распределённые атаки на отказ в обслуживании) в 2025–2026 годах приобрели политическую окраску. Злоумышленники формируют ботнеты из тысяч заражённых устройств и направляют лавину запросов на целевой сервер — до тех пор, пока он не перестаёт отвечать.

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

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

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

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

Законодательство и ответственность: что изменилось в 2026 году

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

Для любой российской компании, работающей с данными клиентов или сотрудников, ключевым является Федеральный закон № 152-ФЗ «О персональных данных». С 30 мая 2025 года вступил в силу Федеральный закон № 420-ФЗ, который внёс поправки в КоАП РФ и кардинально изменил экономику киберинцидентов для бизнеса.

Ключевые изменения:

• От 10 до 15 млн рублей — штраф за первичную утечку данных более 100 000 субъектов персональных данных. За утечку данных от 10 000 до 100 000 субъектов штраф составляет от 5 до 10 млн рублей, от 1 000 до 10 000 субъектов — от 3 до 5 млн рублей.
• От 1 до 3% от годового оборота — штраф за повторную утечку персональных данных любой категории. При этом закон устанавливает минимальный порог: штраф не может быть менее 20–25 млн рублей (в зависимости от вида нарушения), а его максимальный размер ограничен 500 млн рублей. Для компании с выручкой 500 млн рублей расчётный штраф составил бы 15 млн рублей, однако с учётом минимального порога реальная санкция окажется не менее 20–25 млн рублей.
• Двухэтапное уведомление Роскомнадзора: первичное сообщение о факте утечки — в течение 24 часов с момента обнаружения, расширенный отчёт с указанием причин инцидента и принятых мер — в течение 72 часов. За нарушение обязанности уведомить об утечке предусмотрен отдельный штраф — от 1 до 3 млн рублей.

Защита персональных данных перестала быть задачей ИТ-отдела. Защита персональных данных стала вопросом финансовой устойчивости компании и личной ответственности её руководителя.

Требования к безопасности КИИ

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

Принципиальные изменения:

• Риск-ориентированный подход к защите. Организации обязаны самостоятельно моделировать угрозы и подбирать меры защиты под конкретную архитектуру системы и актуальные угрозы.
• Обязательный учёт цепочек поставок. При моделировании угроз необходимо учитывать риски, связанные с подрядчиками, включая удалённый доступ внешних исполнителей.
• Усиленные требования к мониторингу. Мониторинг инцидентов и журналирование событий безопасности должны осуществляться непрерывно (включая дежурную смену 24/7), охватывать всю инфраструктуру и соответствовать ГОСТ Р 59547-2021.
• Повышение требований к управлению ИБ. Приказ формализует структуру управления кибербезопасностью и уточняет требования к ответственным подразделениям и должностным лицам. Не менее 30% сотрудников подразделения по защите информации должны иметь профильное образование в области ИБ. При этом введение прямой персональной административной ответственности руководителей организаций предусмотрено отдельным законопроектом о поправках в КоАП РФ (ст. 13.12.2), который по состоянию на начало 2026 года находился на рассмотрении в Государственной Думе.

Расширение периметра регулирования КИИ на подрядчиков

С 1 марта 2026 года также вступил в силу Федеральный закон от 31 июля 2025 года № 325-ФЗ, внёсший поправки в ФЗ-187 «О безопасности критической информационной инфраструктуры». Закон закрепил, что субъектами КИИ могут быть только российские юридические лица под контролем граждан РФ, и установил контроль за структурой собственности организаций, участвующих в обеспечении функционирования КИИ.

В совокупности с Приказом № 117 это означает, что требования по информационной безопасности де-факто распространяются и на подрядчиков владельцев объектов КИИ, включая ИТ-аутсорсеров, облачных провайдеров, разработчиков ПО и системных интеграторов. Если ваша компания обслуживает банк, больницу, транспортную компанию или энергетическое предприятие, она обязана соблюдать политику информационной безопасности заказчика и фиксировать соответствующие обязательства в договорах.

Импортозамещение в ИБ: сроки и риски

Крайний срок перехода на отечественное программное обеспечение и программно-аппаратные комплексы на значимых объектах КИИ — 1 января 2028 года. Звучит далеко, но на практике миграция корпоративных систем занимает от одного до трёх лет. Компании, которые начнут процесс в 2027 году, рискуют не успеть.

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

Российский рынок ИБ-решений активно развивается: по итогам 2025 года его объём превысил 374 млрд рублей, а по прогнозу Центра стратегических разработок, в 2026 году рынок вырастет ещё на 12% и достигнет 448 млрд рублей, а к 2030 году — 968 млрд рублей. Отечественные вендоры предлагают решения, лицензированные ФСТЭК и ФСБ, что критично для работы с государственными структурами.

Как построить систему защиты: пошаговое руководство для бизнеса

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

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

Шаг 1. Аудит и оценка рисков

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

Что включает базовый аудит:

• Инвентаризация всех информационных активов. Составьте полный реестр: серверы, рабочие станции, облачные сервисы, мобильные устройства, корпоративные учётные записи, API-интеграции с подрядчиками. Особое внимание — теневым IT: сервисам, которые сотрудники используют без ведома ИТ-отдела (личные облачные хранилища, мессенджеры для рабочей переписки, неавторизованные SaaS-инструменты).
• Анализ прав доступа. Проверьте, кто имеет доступ к каким данным и системам. Типичные проблемы: бывшие сотрудники с активными учётными записями, подрядчики с избыточными правами, технические аккаунты с неизменёнными дефолтными паролями. «Мёртвые» учётные записи — один из наиболее распространённых векторов атак: злоумышленник получает легитимный доступ без каких-либо признаков взлома.
• Оценка уязвимостей. Сканирование инфраструктуры специализированными инструментами выявляет неустановленные обновления, открытые порты, слабые конфигурации сервисов. Сканирование — не замена пентесту, но хорошая отправная точка для компаний без выделенной ИБ-команды.
• Моделирование угроз. Не все угрозы одинаково актуальны для разных отраслей. Финансовые компании чаще атакуют через фишинг и компрометацию учётных данных; производственные предприятия — через уязвимости в промышленных системах управления; ритейл — через POS-терминалы и платёжные системы. Моделирование угроз позволяет расставить приоритеты и не тратить бюджет на защиту от маловероятных сценариев.
• Тестирование на проникновение (пентест). Пентест — это контролируемая атака на вашу инфраструктуру, которую проводят специалисты с целью выявить реальные пути компрометации. В отличие от сканирования уязвимостей, пентест показывает, насколько далеко реальный атакующий может продвинуться в вашей сети. Для малого и среднего бизнеса достаточно внешнего пентеста раз в год; для компаний с критичными данными — раз в полгода или после значимых изменений инфраструктуры.

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

Шаг 2. Концепция нулевого доверия (Zero trust)

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

Что такое Zero trust

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

Ключевые принципы zero trust на практике:

• Минимальные привилегии (Least Privilege Access). Каждый сотрудник, сервисный аккаунт и приложение получают доступ строго к тем ресурсам, которые необходимы для выполнения конкретных задач — и ничего сверх этого. Принцип минимальных привилегий ограничивает радиус поражения при компрометации любой учётной записи.
• Многофакторная аутентификация. Многофакторная аутентификация (MFA). MFA обязательна для всех систем и всех пользователей без исключений — включая технические аккаунты и административные панели. Предпочтительные методы второго фактора: аппаратные ключи (FIDO2/WebAuthn) или приложения-аутентификаторы (TOTP).
• Микросегментация сети. Разделение инфраструктуры на изолированные сегменты с явными правилами взаимодействия между ними. Цель — не допустить горизонтального перемещения атакующего по сети (lateral movement).
• Непрерывный мониторинг и верификация. Аутентификация — это не одноразовое событие при входе в систему. Zero trust предполагает постоянную проверку: соответствует ли поведение пользователя его обычным паттернам, не изменилось ли состояние устройства, не появились ли признаки компрометации сессии.
• Явная верификация устройств. Доступ к корпоративным ресурсам разрешается только с устройств, соответствующих корпоративным политикам безопасности: актуальная ОС, установленные обновления, работающий антивирус, шифрование диска.

Начать можно с малого:

1. Внедрить MFA для всех корпоративных сервисов — это даёт немедленный эффект при минимальных затратах.
2. Провести ревизию прав доступа и применить принцип минимальных привилегий.
3. Сегментировать сеть хотя бы на базовом уровне: отделить гостевой Wi-Fi от корпоративного, изолировать серверный сегмент.
4. Внедрить корпоративный менеджер паролей для централизованного управления учётными данными — это фундамент контроля доступа.

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

Шаг 3. Ключевые инструменты защиты

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

Управление паролями и учётными данными

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

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

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

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

MFA уже упоминалась в контексте Zero trust, но заслуживает отдельного внимания как самостоятельный инструмент. Приоритет при выборе метода второго фактора: аппаратные ключи (Rutoken, YubiKey) → приложения-аутентификаторы (Пассворк 2ФА, Google Authenticator) → push-уведомления → СМС. Для привилегированных аккаунтов (администраторы домена, финансовые системы, облачные консоли) аппаратные ключи — стандарт.

Защита конечных точек (EDR/XDR)

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

Для малого и среднего бизнеса с ограниченным бюджетом оптимальный выбор — облачные EDR-решения с управляемым сервисом (MDR): вы получаете мониторинг и реагирование без необходимости содержать собственную команду аналитиков.

Защита электронной почты

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

Управление уязвимостями

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

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

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

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

Шаг 4. Обучение сотрудников

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

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

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

Структура программы обучения

• Базовый инструктаж при найме. Каждый новый сотрудник до получения доступа к корпоративным системам должен пройти обязательный инструктаж. Минимальное содержание: политика паролей и требования к их сложности, правила работы с корпоративной почтой и мессенджерами, запрет на использование личных устройств и облачных хранилищ для рабочих данных, порядок действий при подозрении на инцидент.
• Регулярные фишинговые симуляции. Это наиболее эффективный инструмент снижения уязвимости к социальной инженерии. Принцип прост: ИТ-отдел или внешний подрядчик отправляет сотрудникам тестовые фишинговые письма, имитирующие реальные атаки. Те, кто кликнул на ссылку или ввёл данные, получают немедленную обратную связь и короткий обучающий модуль. Ключевой момент: симуляции должны быть обучающим инструментом, а не инструментом наказания. Цель — изменить поведение, а не поймать виновных.
• Тематические тренинги по актуальным угрозам. Раз в квартал — короткий (15–20 минут) тренинг по конкретной теме: как распознать целевой фишинг (spear phishing), что делать при подозрении на заражение устройства, как безопасно работать с корпоративными данными вне офиса, как реагировать на звонки от «службы безопасности банка» или «ИТ-поддержки».
• Чёткие инструкции на случай инцидента. Каждый сотрудник должен знать ответы на три вопроса: что считается инцидентом ИБ, кому об этом сообщать и как быстро. Страх наказания за «неправильные» действия — главная причина, по которой сотрудники скрывают инциденты или тянут с сообщением. Культура «сообщи и не бойся» сокращает время обнаружения инцидента и снижает итоговый ущерб.
• Отдельные программы для привилегированных пользователей. Системные администраторы, финансовые директора, топ-менеджмент — приоритетные цели для целевых атак. Для них нужна отдельная программа обучения с акцентом на целевой фишинг, атаки на цепочку поставок и социальную инженерию .

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

Шаг 5. Реагирование на инциденты

Компании без плана реагирования на инциденты тратят на восстановление в среднем в 3–4 раза больше времени и денег, чем те, у кого такой план есть.

Что такое план реагирования на инциденты

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

Фазы реагирования на инцидент

• Фаза 1: Подготовка. Это всё, что делается до инцидента. Составление плана, определение ролей и ответственности, создание контактного листа для экстренной связи, настройка инструментов мониторинга и логирования, регулярные учения.
• Фаза 2: Обнаружение и анализ. Инцидент может быть обнаружен автоматически (SIEM-алерт, EDR-уведомление) или вручную (сотрудник заметил аномалию). Задача этой фазы — подтвердить факт инцидента, определить его тип и масштаб, зафиксировать время обнаружения.
• Фаза 3: Изоляция. Немедленное отключение скомпрометированных систем от сети до того, как вредоносное ПО распространится дальше или атакующий получит дополнительный доступ. Изоляция должна быть быстрой, но обдуманной: отключение критичных бизнес-систем в разгар рабочего дня может нанести ущерб, сопоставимый с самим инцидентом.
• Фаза 4: Устранение угрозы. Удаление вредоносного ПО, закрытие использованных уязвимостей, смена скомпрометированных учётных данных, отзыв несанкционированных доступов. Важно убедиться, что угроза полностью устранена: атакующие часто оставляют бэкдоры для повторного доступа.
• Фаза 5: Уведомление регуляторов и пострадавших. При утечке персональных данных российских граждан — уведомление Роскомнадзора в течение 24 часов с момента обнаружения инцидента (требование Федерального закона № 152-ФЗ «О персональных данных», статья 21.1, введённая поправками 2022 года). В течение 72 часов — расширенное уведомление с деталями инцидента. Несоблюдение сроков влечёт административную ответственность и репутационные риски, которые часто превышают ущерб от самого инцидента.
• Фаза 6: Восстановление. Восстановление систем из резервных копий, проверка целостности данных, поэтапный возврат к нормальной работе. Резервные копии должны существовать, регулярно проверяться и храниться по правилу 3-2-1: три копии данных, на двух разных типах носителей, одна из которых хранится офлайн и физически изолирована от основной инфраструктуры. Офлайн-копия — единственная надёжная защита от программ-вымогателей, которые целенаправленно ищут и шифруют подключённые резервные копии.
• Фаза 7: Разбор и улучшение. Обязательная фаза, которую большинство компаний пропускают из-за усталости после инцидента. Цель: установить корневую причину инцидента, оценить эффективность реагирования, выявить пробелы в плане и устранить уязвимость, которая была использована. Без этого шага компания рискует столкнуться с тем же инцидентом повторно.

Заключение

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

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

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

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

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

СберТех и Пассворк обеспечат защиту критичных данных российского бизнеса

Провели двустороннее тестирование и подписали сертификат совместимости, подтверждающий корректную и стабильную работу менеджера паролей Пассворк и СУБД Platform V Pangolin DB в единой инфраструктуре.

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

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

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

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

Менеджер паролей для медицины: защита данных и 152-ФЗ

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

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