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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ФСТЭК

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До инцидента

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О форуме

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

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

1000+ участников и более 90+ спикеров — практики, исследователи уязвимостей, специалисты по расследованию инцидентов.

Структура программы

Четыре конференционных трека выстроены по PDCA-модели (цикл Деминга-Шухарта) — последовательно, от стратегии к практике:

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

Участники обсудили текущие тенденции, реальные кейсы и конкретные шаги по укреплению защиты.

Доклад Пассворка: секреты без слепых зон

На форуме выступил технический директор Пассворка Илья Гарах с докладом «Секреты без слепых зон: как взять под контроль корпоративные пароли, доступы и аудит».

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

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

Как Пассворк решает задачу

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

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

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

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

Живой диалог

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

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

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

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

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

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

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

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

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

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

Python-коннектор 0.1.5: управление секретами в DevOps и CI/CD

Новая версия Python-коннектора 0.1.5 расширяет возможности CLI-утилиты. Мы добавили команды, которые решают ключевые задачи DevOps-инженеров и разработчиков — безопасное получение и обновление секретов в автоматизированных пайплайнах. Почему это важно Секреты, API-ключи, токены и пароли баз данных нельзя хранить в коде — это риск утечки. Ручное обновление замедляет процессы и провоцирует

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

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

Сервисные аккаунты

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

Зачем нужен сервисный аккаунт

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

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

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

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

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

Как создать API-токен

Токены создаются и отзываются в настройках конкретного сервисного аккаунта.

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

В настройках ролей появились новые права:

• Создание сервисных аккаунтов — разрешает создавать сервисные аккаунты
• Управление API-токенами — позволяет генерировать и отзывать токены
• Просмотр API-токенов — позволяет видеть созданные токены

Сохранение фильтров

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

Чтобы сохранить текущие настройки фильтров, нажмите на кнопку + в меню выбора фильтров.

Автоматическая очистка Корзины

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

По истечении срока хранения пароли, папки и ярлыки удаляются из Корзины безвозвратно.

Мобильная версия веб-интерфейса

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

Улучшения

• Улучшили работу ссылок: страница с одноразовой или истёкшей ссылкой теперь автоматически переходит в состояние «Ссылка истекла» через 30 минут после открытия или истечения без необходимости обновлять страницу
• Кнопка «Войти с ключом доступа» на странице входа теперь скрывается, если для всех ролей отключена настройка «Использование ключа доступа вместо пароля»
• Упростили подключение браузерного расширения: убрали лишние шаги с выбором пользователя и повторной аутентификацией после входа в веб-сессию
• Улучшили отображение состояние блокировки раздела «Аутентификация»
• Изменили значения по умолчанию для политик мастер-пароля и блокировки аутентификации
• Добавили недостающие всплывающие подсказки для неактивных элементов интерфейса
• Обновили отображение всплывающих подсказок для улучшения читаемости
• Внесли улучшения и исправления в интерфейс

Исправления

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

Десктопное приложение

• Добавили поддержку нестандартных портов в URL-адресе хоста
• Улучшили механизм обновления приложения и добавили автоматическую проверку актуальной версии

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

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

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

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

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

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

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

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

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

Вступление

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

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

Главное

• Кзи — показатель защищённости. Коэффициент защищённости информации, числовой показатель от 0 до 1 — рассчитывается каждые 6 месяцев и направляется в ФСТЭК.
• Пзи — оценка зрелости процессов. Раз в 2 года организация подтверждает, что защита выстроена системно, а не держится на конкретных людях.
• Сроки устранения уязвимостей. Критические — 24 часа, высокие — 7 дней. Нарушение сроков напрямую снижает Кзи.
• Расширенная зона ответственности. Под действие приказа попадают не только ГИС, но и муниципальные информационные системы и системы ГУП. Для подрядчиков с доступом к государственным и муниципальным системам требования к информационной безопасности должны быть закреплены в документах, регулирующих такой доступ (в том числе в договорах).
• Новые требования к ИИ, кадрам и разработке. Системы с компонентами искусственного интеллекта — отдельный объект оценки. Не менее 30% сотрудников подразделения ИБ обязаны иметь профильное образование. Разработка ПО — только по ГОСТ Р 56939-2024.
• Практический вывод. Действующие аттестаты по Приказу № 17 сохраняют силу до истечения срока, но разработать план перехода на новые требования нужно уже сейчас — это прямая рекомендация ФСТЭК (информационное сообщение № 240/22/1492 от 12 марта 2026 года).

Что такое Приказ ФСТЭК № 117

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

Приказ принят во исполнение Федерального закона № 149-ФЗ «Об информации, информационных технологиях и о защите информации» и распространяется на операторов ГИС федерального и регионального значения, муниципальных информационных систем, систем ГУП, а также на их подрядчиков.

Почему отменили 17-й приказ и в чём суть Приказа № 117

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

Приказ № 17 строился на качественной оценке, при которой организация получала класс защищённости: К1 (высокий, для систем с персональными данными и сведениями ограниченного доступа), К2 (средний) или К3 (низкий) — и аттестат соответствия. Класс присваивался один раз и пересматривался только при существенных изменениях в системе.

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

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

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

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

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

Отдельно стоит выделить новые обязательства в отношении подрядчиков. Если внешний исполнитель имеет доступ к ГИС или муниципальной информационной системе, оператор обязан ознакомить его с политикой защиты информации и закрепить в договоре обязанность соблюдать установленные регламенты (п. 16 и 26 Приказа № 117). Это новое требование, которое большинство организаций пока не выполняют: типовые договоры с подрядчиками таких положений не содержат.

Главные нововведения: Кзи, Пзи и жёсткие сроки устранения уязвимостей

Три ключевых изменения Приказа № 117 — числовые метрики Кзи и Пзи и обязательные сроки устранения уязвимостей. Разберём каждое из них.

Кзи — коэффициент защищённости информации

Кзи — числовой показатель от 0 до 1, рассчитываемый по методике ФСТЭК от 11 ноября 2025 года (была принята отдельно) на основе 16 критериев в 4 группах:

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

Базовый минимум Кзи равен 1. Значение ниже 1 означает наличие уязвимостей и требует разработки плана мероприятий, а критическое несоответствие наступает при Кзи ≤ 0,75.

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

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

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

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

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

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

Кратко о Кзи и Пзи

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

Сроки устранение уязвимостей

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

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

Критические уязвимости

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

Высокие уязвимости

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

Новые уязвимости из БДУ ФСТЭК

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

Средние и низкие уязвимости

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

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

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

Другие критичные изменения для бизнеса

Кадровые требования

Приказ № 117 устанавливает требования к квалификации специалистов по ИБ (п. 20): не менее 30% сотрудников подразделения кибербезопасности должны иметь профильное образование или пройти профессиональную переподготовку в области информационной безопасности.

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

Строгая аутентификация

Вводится понятие строгой аутентификации (по ГОСТ Р 58833-2020), которая становится обязательной для удалённого доступа к ИС, доступа с мобильных устройств и привилегированного доступа (администраторов). Это дополнительный аргумент в пользу внедрения специализированных решений для управления доступом.

Безопасная разработка

Приказ № 117 обязывает следовать ГОСТ Р 56939-2024 при самостоятельной разработке программного обеспечения — когда оператор или обладатель информации разрабатывает ПО для собственной ИС своими силами (п. 14, подп. «д»). Для таких организаций внедрение практик безопасной разработки становится обязательным условием аттестации системы.

Требования к системам на основе ИИ

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

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

Отдельно предусмотрены требования к работе с недостоверными ответами ИИ:

• разработать статистические критерии выявления недостоверных ответов;
• собирать и анализировать такие ответы;
• ограничивать область принимаемых решений на основе недостоверных ответов.

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

Как выглядит расчёт Кзи на практике

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

Структура Кзи: 4 группы, 16 показателей

Методика ФСТЭК делит все частные показатели на 4 группы с фиксированными весовыми коэффициентами:

Итоговый Кзи рассчитывается как сумма произведений: значение группы × её вес. Нормированное значение — Кзи = 1. Это не «отлично» — это минимально допустимый уровень.

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

Пример расчёта: условная ГИС

Группа 1 — Организация и управление (вес 0,10)

Группа 2 — Защита пользователей (вес 0,25)

Группа 3 — Защита информационных систем (вес 0,35)

Группа 4 — Мониторинг и реагирование (вес 0,30)

Итоговый Кзи

Кзи=0,070+0,175+0,228+0,195=0,668

Наш результат: 0,668 — критический уровень. Организация обязана разработать план мероприятий до следующей плановой оценки.

Что нужно исправить в первую очередь

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

Устранение всех четырёх нарушений даст расчётный Кзи ≈ 0,965. Для достижения Кзи = 1 дополнительно потребуется заключить договор на Anti-DDoS (k36).

Дополнительный риск: обнуление группы целиком

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

Для нашего примера это означает: если k32 (уязвимости на периметре) снова окажется нулевым через полгода — группа 3 с весом 0,35 полностью обнулится. Итоговый Кзи не превысит 0,65 при любых других улучшениях.

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

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

Штрафы и ответственность в 2026 году

За нарушения требований защиты информации в ГИС штраф для юридического лица по ст. 13.12 КоАП составляет от 50 000 до 100 000 рублей. Если эти нарушения привели к утечке персональных данных, дополнительно применяется ст. 13.11 КоАП — штрафы достигают 500 000–1 000 000 рублей за каждый эпизод.

Помимо штрафов, нарушения создают риски при участии в госзакупках по 44-ФЗ и 223-ФЗ. Организация с неурегулированными требованиями ИБ фактически ограничивает себе доступ к государственным контрактам.

ФСТЭК в информационном сообщении № 240/22/1492 от 12 марта 2026 года разъяснила: организации обязаны разработать планы перехода с описанием мероприятий и сроков реализации. Это официальное требование регулятора.

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

Как корпоративный менеджер паролей помогает выполнить требования Приказа № 117

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

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

k21 — Парольная политика (вес 0,30)

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

k22 — Многофакторная аутентификация привилегированных пользователей (вес 0,30)

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

k23 — Отсутствие сервисных учётных записей с паролями по умолчанию (вес 0,20)

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

k24 — Удаление учётных записей уволенных сотрудников (вес 0,20)

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

k13 — Требования ИБ в договорах с подрядчиками (вес 0,30 в группе «Организация и управление»)

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

Снижение нагрузки на ИБ-команду

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

Соответствие регуляторным требованиям

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

Заключение

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

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

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

Управление доступом, контроль учётных записей, журнал действий — Пассворк закрывает эти задачи в одном решении, развёрнутом внутри вашей инфраструктуры. Протестируйте бесплатно → passwork.ru

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

Что такое Кзи и как его считать?

Кзи — коэффициент защищённости информации, числовой показатель от 0 до 1. Рассчитывается по методике ФСТЭК на основе 16 критериев в 4 группах: организационные меры, технические меры, контроль защищённости и реагирование на инциденты. Базовый минимум — Кзи = 1 (при КЗИ ≤ 0,75 уровень считается критическим). Оценка проводится раз в 6 месяцев.

Что такое Пзи и зачем он нужен?

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

Кого касается Приказ № 117?

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

Действует ли мой аттестат по Приказу № 17?

Да, аттестаты сохраняют силу до истечения срока, но только при неизменности конфигурации системы. Любая модернизация потребует переаттестации по Приказу № 117. При этом расчёт Кзи по новой методике необходимо начать уже сейчас — это требование регулятора, зафиксированное в информационном сообщении ФСТЭК № 240/22/1492 от 12 марта 2026 года.

Какие штрафы грозят за нарушение требований?

За нарушение требований ФСТЭК (ст. 13.12 КоАП) штраф для юридического лица составляет до 100 000 рублей. Если нарушение привело к утечке персональных данных (ст. 13.11 КоАП) — до 1 000 000 рублей за каждый эпизод. Дополнительный риск: организации с неурегулированными требованиями ИБ фактически ограничивают себе доступ к государственным контрактам по 44-ФЗ и 223-ФЗ.

Что изменилось в требованиях к подрядчикам?

Приказ № 117 обязывает операторов ГИС и муниципальных информационных систем ознакомить подрядчиков с политикой защиты информации и закрепить в договоре обязанность соблюдать установленные регламенты (п. 16 и 26). Подрядчики не подпадают под действие приказа напрямую, однако оператор несёт ответственность за то, чтобы требования были зафиксированы документально и фактически соблюдались.

Что Приказ № 117 требует от организаций, использующих ИИ?

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

Как выполнить кадровые требования Приказа № 117?

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

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

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

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

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

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

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

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

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

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

Март 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-инфраструктуре оказалось использовано против тех, кто на неё полагался.

Атака на Axios NPM и взлом Еврокомиссии

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

Axios NPM: 100 миллионов загрузок в неделю и троян в зависимостях

31 марта злоумышленники опубликовали две вредоносные версии пакета axios (1.14.1 и 0.30.4) в реестре npm. Axios — один из самых популярных HTTP-клиентов для JavaScript, его скачивают около 100 миллионов раз в неделю. Google Threat Intelligence Group связала атаку с северокорейской хакерской группировкой UNC1069.

Сотни тысяч похищенных секретов потенциально могут находиться в обороте в результате этих недавних атак. В краткосрочной перспективе это способно привести к новым атакам на цепочки поставок, компрометации SaaS-сред с последующим ущербом для клиентов, атакам с использованием программ-вымогателей, вымогательству и краже криптовалюты. — Google Threat Intelligence Group

Схема атаки была многоступенчатой. Злоумышленники похитили npm-токен аккаунта jasonaayman, управлявшего репозиторием axios, и опубликовали отравленные версии напрямую через npm CLI, минуя GitHub. В package.json был добавлен вредоносный пакет plain-crypto-js как зависимость — исходный код при этом не изменился, что позволило обойти diff-анализ. При установке пакета через хук postinstall автоматически запускался дроппер SILKBELL, который разворачивал бэкдор WAVESHAPER.V2.

Бэкдор работал на Windows, macOS и Linux: собирал данные о файловой системе, запущенных процессах и похищал учётные данные для дальнейшего распространения по экосистеме. Вредоносный код оставался в реестре 2 часа 54 минуты до удаления командой npm.

Инцидент получил идентификатор CVE-2025-27152. Атака наглядно показывает, как один скомпрометированный токен открывает путь к миллионам проектов: разработчики, установившие обновление через npm install, автоматически получали бэкдор — без каких-либо подозрительных изменений в коде.

Еврокомиссия: 350 ГБ данных и атака через AWS

В конце марта группировка ShinyHunters взломала облачную инфраструктуру Еврокомиссии, получив доступ к AWS-аккаунтам, обслуживающим веб-платформу Europa.eu. Комиссия официально подтвердила инцидент.

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

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

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

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-устройства.

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

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

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

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

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

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

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

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

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

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

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

Вступление

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

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

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

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

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

Главное

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

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

Большинство советов по сложности паролей появились в начале 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 символов при включённом MFA. Случайная парольная фраза из четырёх слов надёжнее короткого пароля со спецсимволами: длина важнее состава.

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

Плановая ротация каждые 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-стратегии.

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