Март 2026 года стал насыщенным периодом для специалистов по информационной безопасности. Первые реальные оборотные штрафы за утечки персональных данных. Критическая уязвимость в мессенджере с CVSS 9.8. Вирус-шифровальщик, переведший крупный европейский порт на бумажный документооборот. Новые требования ФСТЭК и КИИ, вступившие в силу.

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

Главные угрозы марта: мессенджеры и IoT

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

0-day в Telegram: почему мессенджеры — худшее место для паролей

В конце марта специалист по информационной безопасности Майкл Деплант (проект Zero Day Initiative) зарегистрировал уязвимость ZDI-CAN-30207 в Telegram с оценкой CVSS 9.8, которая впоследствии была скорректирована до CVSS 7.0.

Уязвимость передана вендору по процедуре ответственного раскрытия: Telegram официально уведомлён 26 марта 2026 года и получил срок до 24 июля 2026 года на выпуск исправления. Если к дедлайну патч не выйдет — технические детали будут опубликованы в открытом доступе вне зависимости от позиции компании. Это стандартная практика ZDI: она создаёт давление на вендора и защищает пользователей от бесконечного замалчивания проблемы.

Telegram существование уязвимости отрицает:

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

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

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

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

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

Атака на CI/CD через Trivy

В марте 2026 года группировка TeamPCP провела масштабную атаку на цепочку поставок, отправной точкой которой стал популярный сканер уязвимостей Trivy от Aqua Security. Атака оказалась каскадной: скомпрометировав один инструмент, злоумышленники последовательно проникли в экосистему смежных проектов. Инцидент получил идентификатор CVE-2026-33634 с оценкой 9,4 балла по шкале CVSS.

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

1. Trivy — точка входа
19 марта TeamPCP воспользовалась некорректно настроенным GitHub Actions workflow в репозитории Trivy. Злоумышленники похитили CI/CD-секреты, удалили доверенные теги и подменили бинарные файлы начиная с версии v0.69.4. В скомпрометированные артефакты был встроен инфостилер, собирающий переменные окружения, облачные токены и SSH-ключи прямо в процессе сборки.

2. Checkmarx — расширение плацдарма
23 марта, используя уже похищенные CI/CD-секреты, TeamPCP скомпрометировала GitHub Actions двух репозиториев Checkmarx: ast-github-action и kics-github-action. Любой репозиторий, вызывавший эти воркфлоу в период атаки, незаметно для себя выполнял вредоносный код и передавал секреты, переменные окружения и токены.

3. LiteLLM — удар по AI-инфраструктуре
24 марта атака достигла LiteLLM — популярного LLM API-прокси с ~97 млн загрузок. Злоумышленники скомпрометировали GitHub-аккаунт сооснователя проекта Криша Дхолакиа и опубликовали отравленные PyPI-пакеты версий 1.82.7 и 1.82.8.

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

Атака наглядно демонстрирует принцип домино в цепочке поставок: инструменты безопасности — Trivy и Checkmarx — сами стали вектором атаки. Доверие к CI/CD-инфраструктуре оказалось использовано против тех, кто на неё полагался.

IoT-уязвимости и шифровальщики

Параллельно произошли ещё два примечательных инцидента:

Уязвимость в ZenCount

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

Атака на порт Виго

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

Новые регуляторные требования

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

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

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

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

Поправки в ФЗ-187 (КИИ)

С 1 марта вступили в силу поправки: субъектом критической информационной инфраструктуры может быть только российское юридическое лицо под контролем граждан РФ. Формируются новые реестры доверенного программного обеспечения. Для значимых объектов КИИ ориентир по завершению перехода — 1 января 2028 года с возможностью продления до 2030 года.

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

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

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

Законопроект о регулировании ИИ

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

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

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

1. Уберите пароли из небезопасных ресурсов

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

2. Внедрите ролевую модель доступа

Стажёр не должен иметь права администратора. Уволенный сотрудник должен терять все доступы в ту же минуту, когда его учётная запись блокируется. Менеджер паролей, интегрированный с Active Directory и LDAP, позволяет автоматизировать выдачу и отзыв прав на основе ролей (RBAC) — без ручных операций и человеческого фактора.

3. Переходите на локальное развёртывание

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

4. Контролируйте доступы подрядчиков

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

5. Проведите аудит текущих доступов

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

Выводы

Март 2026 года обозначил несколько устойчивых тенденций. Штрафы за утечки перешли из теории в практику — прецеденты созданы. Регуляторные требования ужесточились сразу по нескольким направлениям: КИИ, ГИС, ИИ. Векторы атак расширились: под ударом оказались мессенджеры, инструменты DevOps и IoT-устройства.

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

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

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

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

Менеджер паролей для медицины: защита данных и 152-ФЗ

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

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

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

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

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

Вступление

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

Но именно эти действия делают пароль предсказуемым: паттерны замены символов давно включены в словари для брутфорса, и «сложный» P@rr01! взламывается за секунды.

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

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

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

Главное

• Пароли взламывают не перебором — их берут из утечек. Злоумышленники проверяют старые базы по новым целям автоматически: одна скомпрометированная учётная запись открывает доступ ко всем сервисам, где используется тот же пароль.
• Длина важнее сложности. Случайная фраза из четырёх слов обладает большей энтропией, чем короткий пароль со спецсимволами.
• Повторное использование паролей — главная уязвимость корпоративных систем. По данным DSEC (ГК «Солар»), в 73% российских компаний сотрудники используют пароли по умолчанию или один пароль для разных учётных записей.
• Менять пароль по расписанию бессмысленно. NIST SP 800-63B прямо запрещает принудительную ротацию: она приводит к предсказуемым вариантам вида Parol2024 → Parol2025. Смена оправдана только при подтверждённой компрометации.
• Второй фактор закрывает риски, которые пароль не закрывает. МФА защищает от фишинга и утечек баз данных даже если пароль уже известен атакующему.

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

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

Миф 1: пароль нужно менять каждые 90 дней

Принудительная ротация паролей каждые 30, 60 или 90 дней — одна из самых живучих корпоративных политик. И одна из самых вредных.

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

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

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

Миф 2: сложный пароль лучше длинного

Пароль P@$$w0rd! выглядит сложным: заглавные буквы, цифры, спецсимволы. На практике он взламывается за секунды, потому что подстановка символов (a → @, o → 0) давно включена в словари для брутфорса, метода взлома систем путём автоматизированного перебора всех возможных комбинаций символов. Атакующие знают эти паттерны лучше, чем сами пользователи.

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

Миф 3: браузер надёжно хранит пароли

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

Актуальные стандарты безопасности

Актуальные стандарты безопасности — NIST (Национальный институт стандартов и технологий США) и OWASP (Open Web Application Security Project). Это два главных ориентира в области парольной безопасности. Их рекомендации лежат в основе корпоративных политик и требований регуляторов по всему миру.

Требования NIST

В августе 2025 года NIST опубликовал четвёртую редакцию стандарта SP 800-63B. Это наиболее значительное обновление за последние годы — стандарт полностью переосмыслил подход к парольным политикам. Ключевые нормативные требования:

Длина:

• Минимум 15 символов для однофакторной аутентификации
• Минимум 8 символов при включённой многофакторной аутентификации (MFA)

Состав и ограничения:

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

Смена паролей:

• Периодическая принудительная смена запрещена
• Смена обязательна только при подтверждённой компрометации

Рекомендации OWASP

OWASP синхронизирован с NIST и дополняет его практическими требованиями для разработчиков и администраторов:

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

Старые vs. новые требования к паролям:

5 главных правил создания надёжного пароля

Надёжный пароль — длинный, случайный и уникальный для каждого сервиса. Его сложно подобрать автоматически и незачем запоминать: для этого существует менеджер паролей. Ниже практический минимум по стандартам NIST и OWASP, адаптированный для реальной работы с паролями.

1. Используйте парольные фразы

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

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

Хорошие примеры парольных фраз:

• stol-nebo-reka-kirpich-2025
• gora-oblako-veter-more
• Krasny-Fonar-Ulitsa-Drozd

Предсказуемые фразы:

• iloveyou2025 — словарная фраза
• privet-mir — слишком короткая и простая
• password-qwerty — очевидная комбинация

2. Длина важнее сложности

Минимум по NIST — 15 символов для однофакторной аутентификации. Это нижняя граница, а не цель. Парольная фраза из 25–30 символов обеспечивает большую защиту, чем 10-символьный «сложный» пароль.

Время перебора паролей по Hive Systems:

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

3. Уникальный пароль для каждого сервиса

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

По данным компании «Вебмониторэкс», в первом полугодии 2025 года около половины всех веб-атак на российские госорганизации составляли именно попытки подбора учётных данных. Госсектор оказался единственной отраслью, где этот тип атак стабильно занимает первое место среди всех веб-угроз.

Правило: один сервис — один уникальный пароль. Без исключений.

4. Никакой личной информации

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

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

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

5. Двухфакторная аутентификация

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

Приоритет методов двухфакторной аутентификации:

1. Аппаратный ключ (FIDO2/WebAuthn). Максимальная защита, устойчив к фишингу.
2. TOTP-приложение (Google Authenticator, Яндекс.Ключ, Пассворк 2ФА и аналоги). Надёжно, не зависит от сети.
3. Пуш-уведомление в приложении. Удобно, но более уязвимо.
4. SMS-код. Наименее надёжный вариант, уязвим для SIM-свопинга, но лучше, чем ничего.

NIST относит SMS к ограниченно допустимым методам аутентификации и рекомендует переход на TOTP или FIDO2 для систем, обрабатывающих чувствительные данные.

Примеры надёжных и слабых паролей

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

Почему генератор паролей надёжнее человека?

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

Каждый символ выбирается независимо из заданного набора — без какой-либо логики, которую можно предугадать или воспроизвести. Результат: пароль вида xK9#mQ2@vL5$nR8!pT3 обладает максимальной энтропией для своей длины и не встречается ни в одном словаре для брутфорса. Запоминать его не нужно — менеджер паролей подставит его автоматически.

Менеджер паролей

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

Главное возражение против надёжных паролей: «я не смогу это запомнить». Это справедливо, если пытаться держать в голове xK9#mQ2@vL5$nR8!pT3. Менеджер паролей снимает эту проблему: вы запоминаете один мастер-пароль — надёжный, длинный, уникальный. Остальное он берёт на себя.

Что даёт корпоративный менеджер паролей:

• Генерация криптографически случайных паролей нужной длины и состава
• Хранение неограниченного числа уникальных паролей
• Автозаполнение на сайтах и в приложениях
• Предупреждение об использовании одного пароля на нескольких сервисах

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

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

Ключевые возможности:

• Локальное развёртывание — все данные хранятся на серверах компании, без передачи третьим сторонам
• Ролевое управление доступом — гибкое разграничение прав: кто видит, кто редактирует, кто передаёт пароли
• Полный журнал аудита — каждое действие с паролем фиксируется: кто открыл, скопировал, изменил и когда
• Интеграция с Active Directory и LDAP — централизованное управление пользователями без дублирования учётных записей
• Шифрование AES-256 — данные зашифрованы на уровне хранилища, расшифровка происходит только на стороне клиента

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

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

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

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

Тест: как вы на самом деле создаёте пароли?

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

Заключение

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

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

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

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

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

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

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

Надёжный пароль — длинный, случайный и уникальный для каждого сервиса. Минимальная длина — 15 символов при однофакторной аутентификации, 8 символов при включённом МФА. Случайная парольная фраза из четырёх слов надёжнее короткого пароля со спецсимволами: длина важнее состава.

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

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

Чем парольная фраза лучше сложного пароля?

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

Где хранить уникальные пароли, если их много?

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

Насколько безопасна двухфакторная аутентификация через SMS?

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

Как должна выглядеть современная корпоративная парольная политика?

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

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

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

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

Двухфакторная аутентификация для бизнеса: внедрение и защита

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

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

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

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

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

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

Путаница между ними дороже, чем кажется. Размытые границы в терминологии ведут к размытым границам в архитектуре, а это уже уязвимости. По классификации OWASP Top 10, нарушение контроля доступа (Broken Access Control) занимает первое место среди угроз для веб-приложений.

Разберём каждый из терминов с примерами.

Главное

• Идентификация, аутентификация и авторизация — три независимых процесса, каждый из которых решает свою задачу.
• Идентификация устанавливает личность («Кто ты?») — логин, имейл, номер телефона. Это не секрет и не даёт никаких гарантий безопасности.
• Аутентификация верифицирует подлинность («Докажи, что это ты») через факторы: знание (пароль), владение (токен) или свойство (биометрия).
• Авторизация определяет права доступа («Что тебе разрешено?») после успешной аутентификации. RBAC назначает права через роли, ABAC — через атрибуты и контекст запроса (время, IP, устройство).
• Ключи доступа (Passkeys) — главный тренд 2025–2026 годов. Беспарольная аутентификация на базе FIDO2/WebAuthn устраняет фишинг, утечки с серверов и человеческий фактор. Приватный ключ не покидает устройство, вход подтверждается биометрией.
• Zero Trust отменяет концепцию доверенного периметра. Каждый запрос проходит верификацию независимо от источника. Непрерывная проверка, минимум привилегий и контекстная оценка риска — основа архитектуры нулевого доверия.

Идентификация, аутентификация, авторизация

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

Шаг 1. Идентификация: «Кто ты?»

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

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

Шаг 2. Аутентификация: «Докажи, что это ты»

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

Классификация факторов аутентификации:

• Знание (knowledge) — секрет, известный только пользователю: пароль, ПИН-код, ответ на контрольный вопрос.
• Владение (possession) — физический или цифровой объект, которым располагает пользователь: TOTP-приложение, аппаратный токен, SIM-карта для SMS-кода.
• Свойство (inherence) — биометрические характеристики: отпечаток пальца, геометрия лица (Face ID), сетчатка глаза.

Использование нескольких факторов одновременно — основа двухфакторной (2FA) и многофакторной аутентификации (MFA). Компрометация одного фактора не даёт злоумышленнику доступа, пока остальные не скомпрометированы.

Шаг 3. Авторизация: «Что тебе разрешено?»

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

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

В чём главная разница?

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

Виды аутентификации: от паролей до биометрии

Однофакторная аутентификация (1FA)

Метод проверки личности, при котором пользователь подтверждает доступ единственным способом — как правило, паролем.

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

Двухфакторная аутентификация (2FA)

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

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

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

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

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

Методы второго фактора — от слабого к надёжному:

• SMS-коды — самый распространённый и наименее надёжный метод. Одноразовый код передаётся через сотовую сеть, которая уязвима к SIM-свопингу (злоумышленник переоформляет номер на свою SIM-карту) и SS7-атакам (перехват трафика на уровне протокола сигнализации). Допустим как временное решение или для низкорисковых сценариев. Для критичных систем — неприемлем.
• Email OTP — одноразовый код отправляется на почту. По надёжности сопоставим с SMS: безопасность фактора целиком зависит от защищённости почтового ящика. Если почта скомпрометирована, второй фактор не работает.
• Push-уведомления — запрос подтверждения поступает на зарегистрированное доверенное устройство. Пользователь видит контекст запроса: время, геолокацию, устройство инициатора. Это позволяет распознать подозрительный запрос и отклонить его. Уязвимость — усталость: злоумышленник отправляет серию запросов подряд в расчёте на то, что пользователь подтвердит один из них машинально.
• TOTP-приложения — генерируют одноразовые коды локально на устройстве. Код действителен 30 секунд и не передаётся через сеть при генерации. Не зависят от сотовой связи, устойчивы к SIM-свопингу и SS7-атакам. Уязвимость остаётся одна: код можно перехватить в реальном времени через фишинговый сайт-прокси, если пользователь не проверяет домен.
• Биометрия — отпечаток пальца, распознавание лица. Используется преимущественно как локальный фактор на устройстве — верификация происходит на стороне устройства, данные не передаются по сети. Надёжность ограничена качеством реализации на конкретной платформе.
• Ключи доступа (Passkey, FIDO2 без аппаратного токена) — криптографические ключи хранятся в защищённом хранилище устройства: TPM или Secure Enclave. Работает по той же логике, что и аппаратный FIDO2-ключ, но без отдельного физического токена. Устойчив к фишингу за счёт привязки к домену, поддерживается всеми современными платформами.
• Аппаратные FIDO2-ключи — физические устройства с криптографическим подтверждением на борту. Удалённая компрометация технически невозможна — злоумышленнику нужен физический доступ к устройству. Считаются эталоном надёжности второго фактора.

Тренд 2025 года: беспарольная аутентификация и ключи доступа (Passkeys)

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

Главный структурный сдвиг в аутентификации — переход к полностью беспарольным схемам. Технология Passkeys на базе стандарта FIDO2/WebAuthn позволяет аутентифицироваться с помощью биометрии устройства без ввода пароля.

Механизм: при регистрации генерируется асимметричная криптографическая пара ключей. Приватный ключ хранится в защищённом анклаве устройства (Secure Enclave на Apple, TPM на Windows) и никогда не покидает его. Публичный ключ передаётся на сервер. При входе сервер отправляет запрос, устройство подписывает его приватным ключом после биометрического подтверждения пользователя.

Принципиальные преимущества перед паролями:

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

Apple, Google и Microsoft внедрили поддержку Passkeys в свои платформы. Почти все крупные сервисы уже предлагают вход через ключи доступа в качестве основного метода.

Как работает авторизация в ИТ-системах

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

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

Ролевая модель (Role-Based Access Control) — наиболее распространённая модель в корпоративных системах. Права назначаются не конкретному субъекту, а роли; субъект наследует права через членство в роли. Это упрощает администрирование: изменение прав роли мгновенно распространяется на всех её носителей.

Типовая иерархия ролей:

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

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

Атрибутная модель (ABAC)

ABAC (Attribute-Based Access Control) — модель управления доступом, в которой решение об авторизации принимается на основе набора атрибутов: характеристик пользователя, ресурса, выполняемого действия и контекста запроса (время, местоположение, устройство).

Атрибутная модель принимает решение об авторизации на основе набора атрибутов: характеристик субъекта, объекта, действия и окружения. Это позволяет реализовывать контекстно-зависимые политики.

OAuth 2.0 и делегирование авторизации

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

Сценарий «Войти через Google»:

1. Клиентское приложение перенаправляет пользователя на сервер авторизации.
2. Сервер проверяет личность пользователя и запрашивает согласие на передачу конкретных прав доступа.
3. После подтверждения выдаётся токен доступа — временный, ограниченный по правам и сроку действия.
4. Клиентское приложение использует токен для запросов к серверу ресурсов; пароль пользователя в процессе не фигурирует.

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

Zero Trust: непрерывная верификация как архитектурный принцип

Концепция Zero Trust («никогда не доверяй, всегда проверяй») отказывается от модели периметровой безопасности, при которой субъект внутри сети считается доверенным по умолчанию. В Zero Trust каждый запрос к ресурсу проходит полный цикл верификации независимо от его источника.

Ключевые принципы:

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

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

Ошибки, которые стоят дорого

Тест: идентификация, аутентификация, авторизация

Заключение

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

Практические выводы, которые стоит зафиксировать:

• MFA — минимальный стандарт для критичных систем. SMS-коды допустимы как временное решение, аппаратные FIDO2-ключи — как эталон.
• Принцип наименьших привилегий должен быть встроен в архитектуру, а не настраиваться вручную для каждого пользователя. Права по умолчанию — минимальные, расширение — явное и обоснованное.
• Аутентификация и авторизация — разные слои. Смешивать их логику в одном компоненте — источник IDOR и других уязвимостей контроля доступа.
• Passkeys устраняют целый класс атак — фишинг, утечки с серверов, повторное использование паролей на уровне протокола, а не пользовательской дисциплины.
• Zero Trust — не концепция будущего, а рабочий архитектурный принцип для распределённых инфраструктур. Каждый запрос верифицируется с учётом контекста — независимо от того, откуда он пришёл.

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

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

В чём принципиальная разница между аутентификацией и авторизацией?

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

Что такое двухфакторная аутентификация и почему её нельзя игнорировать?

2FA требует подтверждения личности двумя независимыми факторами из разных категорий: например, паролем (знание) и TOTP-кодом (владение). Компрометация одного фактора не даёт доступа без второго. По данным Microsoft, 2FA блокирует более 99,9% атак с использованием скомпрометированных учётных данных. Для критичных систем рекомендуется MFA с аппаратным токеном в качестве одного из факторов.

Что такое ключи доступа (Passkeys) и чем они архитектурно лучше паролей?

Passkeys реализуют беспарольную аутентификацию на основе FIDO2/WebAuthn. При регистрации генерируется асимметричная ключевая пара: приватный ключ хранится в защищённом анклаве устройства, публичный — на сервере. Вход подтверждается биометрией. Passkeys устойчивы к фишингу (ключ привязан к origin-домену), не могут быть украдены с сервера и исключают человеческий фактор при создании учётных данных.

Что такое Zero Trust и как он меняет подход к аутентификации и авторизации?

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

Чем SSO отличается от стандартного входа и какие риски он несёт?

SSO (Single Sign-On) позволяет пройти аутентификацию один раз через поставщика удостоверений и получить доступ ко всем связанным сервисам без повторного ввода учётных данных. Это снижает парольную усталость и централизует аутентификацию. Оборотная сторона: компрометация поставщика удостоверений открывает доступ ко всем подключённым системам одновременно. Поэтому SSO-провайдер должен быть защищён MFA и строгими политиками доступа.

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

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

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

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

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

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

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

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

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

Вступление

Фишинг превратился из массового спама в точечное оружие. Большие языковые модели (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 странах мира.

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

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

Многофакторная аутентификация сработала именно так, как должна. Просто атака была направлена не на неё.

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

Пароль давно перестал быть достаточной защитой — это факт, с которым согласны и регуляторы, и страховщики, и команды реагирования на инциденты. Но и базовый 2FA через SMS-сообщения уже не спасает: современные атаки типа «Злоумышленник посередине» (AiTM) перехватывают сессионные токены прямо в момент аутентификации, обходя любой одноразовый код.

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

Главное

• Двухфакторная аутентификация работает — но только если выбран правильный метод. Большинство корпоративных взломов происходят не потому, что второй фактор обошли технически, а потому что использовали метод, уязвимый к фишингу или перехвату сессии.
• SMS-коды устарели. Три независимых вектора атаки — перехват через уязвимости протокола SS7, подмена SIM-карты и фишинг в реальном времени — делают SMS архитектурно ненадёжным вторым фактором.
• TOTP и push-уведомления — переходный вариант, не финальный. Приложения-аутентификаторы лучше SMS, но уязвимы к атакам «злоумышленник посередине»: код перехватывается в реальном времени и действителен достаточно долго для атаки.
• Единственные методы, устойчивые к фишингу на уровне протокола, — аппаратные токены и ключи доступа. Для привилегированных учётных записей — аппаратные токены (Рутокен, JaCarta), для рядовых сотрудников — ключи доступа.
• Резервные процедуры обязательны. Регламент восстановления доступа при утере устройства или компрометации фактора должен быть прописан заранее — с верификацией личности, временным доступом с ограниченными правами и обязательным аудитом.

Что такое 2FA и MFA: в чём разница для бизнеса?

Двухфакторная аутентификация (2FA) — метод проверки личности, при котором пользователь подтверждает вход двумя независимыми способами: как правило, паролем и одноразовым кодом.

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

Три классических фактора аутентификации:

• Знание — то, что пользователь знает: пароль, ПИН-код, секретный вопрос. Знание можно выманить фишингом, подобрать брутфорсом, купить в утечке или перехватить через инфостилер. Именно поэтому пароль в одиночку давно не считается достаточной защитой.
• Владение — то, чем пользователь физически располагает: смартфон с приложением-аутентификатором, аппаратный токен (FIDO2/YubiKey), смарт-карта. Этот фактор существенно сложнее скомпрометировать удалённо.
• Свойство — биометрические характеристики пользователя: отпечаток пальца, распознавание лица, голос. Фактор удобен — его невозможно забыть или потерять. Но у него есть принципиальное ограничение: биометрию нельзя сменить после компрометации. Поэтому биометрия надёжна как дополнительный фактор, но не как единственный.

Современные системы двухфакторной аутентификации всё чаще дополняются SSO (Single Sign-On) и безпарольными методами (Passwordless). Сотрудник проходит строгую аутентификацию один раз — и получает доступ ко всем корпоративным системам без ввода паролей. Это снижает нагрузку на Helpdesk и устраняет главный источник уязвимостей — человека, который придумывает «удобные» пароли.

Почему SMS-коды больше не работают?

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

• Атаки на протокол SS7. SMS передаются через инфраструктуру телефонных сетей — Signaling System 7 (Система сигнализации №7). Уязвимости этого протокола известны с 2014 года, задокументированы исследователями и активно эксплуатируются в целевых атаках. Злоумышленник с доступом к SS7 перехватывает сообщения без физического контакта с устройством жертвы — удалённо, незаметно, без каких-либо следов на стороне пользователя.
• SIM-свопинг. Злоумышленник убеждает оператора связи перевыпустить SIM-карту на своё имя — используя данные из утечек или социальную инженерию. После этого все SMS с кодами приходят атакующему. Российские операторы внедрили уведомления о смене SIM, но это реактивная мера: к моменту, когда жертва получает уведомление, атака уже состоялась.
• Фишинг в реальном времени. Поддельная страница входа запрашивает SMS-код и немедленно передаёт его на настоящий сайт — пока код ещё действителен. Для рядового сотрудника такая страница визуально неотличима от оригинала. Никакой технической защиты от этого сценария у SMS нет: код не привязан к домену, устройству или сессии.

Все три вектора объединяет одно: SMS-код существует в открытой среде, которую пользователь не контролирует. Это архитектурное ограничение протокола.

Как хакеры обходят MFA в 2025–2026 годах?

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

Три вектора, которые определяют ландшафт атак в 2025–2026 годах:

• Злоумышленник посередине (AiTM, Adversary-in-the-Middle). Злоумышленник разворачивает прокси-сервер между пользователем и легитимным сайтом. Жертва вводит логин, пароль и код MFA — всё это в реальном времени передаётся на настоящий ресурс. Сервер возвращает валидную сессионную куку, которую атакующий перехватывает и использует самостоятельно. Второй фактор отработал корректно — сессия скомпрометирована.
• Усталость от MFA (атака на подтверждение push-уведомлений). Злоумышленник, располагая логином и паролем, отправляет непрерывный поток push-запросов на смартфон жертвы. Десятки уведомлений подряд — ночью, в рабочее время, во время совещания. Часть пользователей в какой-то момент нажимает «Подтвердить» — чтобы остановить поток или по невнимательности.
• Перехват сессии через программы-похитители данных (инфостилеры). Инфостилер — вредоносная программа, которая извлекает сохранённые сессионные куки из браузера уже после того, как пользователь прошёл аутентификацию. Украденная кука позволяет войти в систему без повторного ввода пароля и второго фактора — сессия считается активной и доверенной. Этот вектор не требует взаимодействия с жертвой в реальном времени.

Надёжные методы аутентификации: от TOTP до FIDO2

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

Приложения-аутентификаторы (TOTP)

Одноразовый пароль на основе времени (TOTP, Time-based One-Time Password) — метод генерации шестизначного кода каждые 30 секунд на основе общего секрета (seed), известного устройству и серверу. Алгоритм стандартизирован в RFC 6238. Приложения типа Пассворк 2ФА и Яндекс.Ключ работают офлайн и не зависят от оператора связи.

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

Push-уведомления с числовым совпадением

Push-аутентификация с числовым совпадением (Number Matching) — улучшенная версия push-подтверждения: вместо кнопки «Разрешить / Отклонить» пользователь видит число на экране входа и вводит его вручную в мобильном приложении. Автоматическое подтверждение становится невозможным — случайное нажатие или нажатие под давлением потока уведомлений исключено.

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

Числовое совпадение (Number Matching) — минимальный стандарт для push-аутентификации в 2026 году. Без него push-уведомления остаются уязвимыми к атаке на усталость от двухфакторной аутентификации.

Аппаратные ключи (USB-токены)

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

• Плюсы: высокая надёжность, защита от удалённых атак, соответствие требованиям ФСТЭК для привилегированного доступа. Рутокен и JaCarta сертифицированы по российским стандартам.
• Минусы: стоимость от 2 000 до 8 000 руб. за устройство, необходимость физического управления парком токенов, неудобство для мобильных и удалённых сотрудников.

MFA, устойчивая к фишингу: FIDO2 и ключи доступа

FIDO2 — открытый стандарт аутентификации альянса FIDO, основанный на криптографии с открытым ключом и привязке к домену. Ключи доступа (Passkeys) — пользовательская реализация FIDO2, встроенная в операционные системы и браузеры: закрытый ключ хранится в защищённом хранилище устройства — доверенном анклаве или модуле TPM, — а подтверждение входа выполняется через биометрию или ПИН-код.

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

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

Сравнение методов MFA

Регуляторные требования: ФСТЭК №117 и обязательный MFA

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

Ключевые изменения, которые напрямую касаются аутентификации:

• Обязательная строгая аутентификация для удалённого доступа. Подключение к корпоративным ресурсам извне, а также доступ с мобильных устройств теперь безальтернативно требуют строгой аутентификации (по ГОСТ Р 58833-2020, с использованием криптографических протоколов, например, аппаратных токенов с УКЭП).
• Многофакторная аутентификация для привилегированного доступа. Для учетных записей с расширенными правами (администраторы, DevOps, DBA) также требуется строгая аутентификация. Однако регулятор делает важное практическое уточнение: если её реализация технически невозможна, допускается использование усиленной многофакторной аутентификации.
• Непрерывный мониторинг и журналирование. Вводятся жесткие требования к журналированию событий аутентификации и обязательной интеграции с системами мониторинга (SIEM) и ГосСОПКА в режиме 24/7.

Параллельные требования для КИИ и коммерческого сектора:

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

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

Пошаговый план внедрения MFA в компании

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

Шаг 1. Аудит и инвентаризация

Составьте карту критичных систем с приоритизацией по риску:

• Высокий приоритет: почта, системы удалённого доступа, облачные сервисы (корпоративные порталы), привилегированные учётные записи.
• Средний приоритет: CRM, ERP, финансовые системы, HR-платформы.
• Базовый приоритет: внутренние инструменты с ограниченным доступом к данным.

Для каждой системы определите: поддерживает ли она FIDO2/SAML, какие методы MFA совместимы, есть ли API для интеграции.

Шаг 2. Сегментация пользователей и выбор методов

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

• Администраторы и привилегированные пользователи → аппаратные токены (Рутокен, JaCarta) или FIDO2-ключи.
• Рядовые сотрудники → TOTP-приложение или ключи доступа (Passkeys). Push-уведомления с сопостовлением цифр (Number Matching) — как переходный вариант.
• Внешние подрядчики → временные TOTP-токены с ограниченным сроком действия и минимальными правами доступа.

Шаг 3. Пилотный запуск

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

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

Шаг 4. Обучение сотрудников

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

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

Шаг 5. Резервные пути доступа

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

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

Сценарии потери доступа и порядок действий

Заключение

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

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

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

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

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

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

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

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

Главное

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

Шифрование и хэширование: в чём принципиальная разница

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

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

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

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

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

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

OWASP формулирует это прямо: пароли должны хэшироваться, а не шифроваться — за редкими исключениями, когда приложение вынуждено передавать пароль во внешнюю систему, не поддерживающую современные методы аутентификации (OWASP Password Storage Cheat Sheet).

Как работает хэш-функция

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

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

Свойства хэш-функции

• Детерминированность. Одинаковый вход — всегда одинаковый выход. Это позволяет проверять пароль при входе: система хэширует введённый пароль и сравнивает с хранимым хэшем.
• Необратимость. Из хэша нельзя получить исходный пароль — только перебором вариантов.
• Эффект лавины. Минимальное изменение входных данных кардинально меняет хэш. Пароль password и Password дают совершенно разные хэши — никакой корреляции.
• Устойчивость к коллизиям. Два разных входа не должны давать одинаковый хэш. MD5 и SHA-1 эту устойчивость утратили — это одна из причин их непригодности.

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

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

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

Что такое соль и как она защищает пароли

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

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

Зачем нужна соль

1. Нейтрализация радужных таблиц. Хакер не может использовать готовые базы предвычисленных хэшей. Поскольку соль уникальна для каждого пользователя, хакеру придется вычислять радужную таблицу заново для каждой отдельной учётной записи, что делает атаку вычислительно нецелесообразной.
2. Скрытие одинаковых паролей. Соль гарантирует уникальность выходного хэша. Даже если у 100 сотрудников пароль Password123, в базе данных будут храниться 100 совершенно разных хэш-строк. Это не позволяет злоумышленнику выявлять группы пользователей со слабыми или стандартными паролями по совпадению хэшей.

Как правильно генерировать соль

• Минимум 128 бит (16 байт) длины
• Генерировать через криптографически стойкий генератор случайных чисел (CSPRNG) — os.urandom() в Python, random_bytes() в PHP, SecureRandom в Java
• Уникальная для каждого пользователя и каждой смены пароля

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

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

Для этого сценария существует отдельный механизм защиты.

Что такое перец и чем он отличается от соли

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

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

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

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

Как Пассворк защищает пароли: архитектура шифрования

Zero Knowledge: сервер не знает ничего

Архитектура Пассворка реализует принцип Zero Knowledge: сервер хранит только зашифрованные данные и зашифрованные ключи. Расшифровать их без мастер-пароля пользователя невозможно — в том числе администраторам сервера и техническим специалистам компании.

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

Двухуровневая защита

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

• Клиентское шифрование (CSE) выполняется до отправки данных на сервер. Алгоритм — AES-256-CBC. Ключи генерируются из мастер-пароля через PBKDF2 с 300 000 итерациями и SHA-256. Этот уровень обеспечивает Zero Knowledge: даже при полной компрометации сервера данные остаются нечитаемыми.
• Серверное шифрование работает всегда — независимо от того, включено ли клиентское. Алгоритм — AES-256-CFB. Данные шифруются перед записью в базу данных. Серверный ключ (256 бит) хранится отдельно от БД и ротируется по расписанию.

Иерархия ключей

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

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

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

Как Пассворк реализует эти принципы на практике

Пассворк построен на архитектуре Zero Knowledge с клиентским шифрованием. Система спроектирована так, что утечка данных невозможна даже при полной компрометации сервера.

• Сервер не знает мастер-пароль. Пассворк не хранит его ни в открытом виде, ни в виде хэша. Мастер-пароль никогда не покидает устройство пользователя.
• Ключ генерируется локально. При вводе мастер-пароля он не передаётся по сети. Непосредственно на устройстве — в браузере или приложении — запускается PBKDF2 с сотнями тысяч итерациями. Результат: криптографический ключ, который существует только в памяти клиента.
• Шифрование до отправки. Полученный ключ шифрует все данные сейфа по стандарту AES-256 прямо на устройстве. На сервер уходит уже зашифрованный криптоконтейнер.
• Второй уровень защиты. Серверное шифрование AES-256-CFB работает независимо и постоянно — даже если клиентское шифрование отключено. Резервные копии и дамп базы данных содержат только шифротекст.

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

Заключение

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

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

Здесь серверные меры должны дополняться инструментами управления на стороне клиента.

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

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

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

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

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

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

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

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

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

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

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

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

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

По оценкам отраслевых исследований, ущерб от утечек данных в России измеряется миллионами рублей, и более чем в трети случаев вместе с ними компрометируется коммерческая тайна. При этом 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 на сетевом диске. Файл доступен всем, у кого есть доступ к папке. Версионирования нет — непонятно, кто и когда менял пароль. При увольнении сотрудника файл остаётся у него в кэше или на личном устройстве.
• Доступы передают в чате. Пароль уходит в мессенджер или корпоративную почту — и остаётся там навсегда. История переписки не шифруется, не удаляется и доступна всем участникам чата.
• Облачные доступы в памяти администратора. Если сотрудник уходит или уходит на больничный — доступ к сервису теряется вместе с ним. Никакой передачи, никакой документации.
• Нет контроля и аудита. Невозможно ответить на базовые вопросы: кто заходил в систему, когда и с какого устройства. При инциденте расследование начинается с нуля.

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

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

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

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

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

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

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

Приказ ФСТЭК России № 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-интерфейс решает аналогичную задачу для операционных сценариев. Администратор может автоматизировать ротацию паролей, массовое обновление записей или экспорт данных через командную строку — без необходимости открывать веб-интерфейс. Это особенно важно для команд, работающих в серверных средах без графического интерфейса.

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

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

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

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

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

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

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

Шаг 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 коррелирует это с аналогичными попытками в других корпоративных системах.

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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