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

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

Главное

1. Масштаб. По данным Positive Technologies, в 2025 году социальная инженерия применялась в 60% успешных атак на российские организации. В 80% таких атак использовалась электронная почта. Вредоносное ПО встречалось в 71% атак. Методы работают в связке: сотрудник открывает вход, дальше в ход идут ВПО и уязвимости внутренней сети.
2. Почему периметр не помогает. Сотрудник, который сам ввёл пароль или подтвердил вход, выглядит для средств защиты как легитимный пользователь.
3. Порог входа снизился. Первый шаг можно купить: медианная цена фишингового решения выросла со 125 до 500 долларов, а 13% объявлений на теневых форумах связаны с перехватом 2FA и OTP. ИИ делает персонализированные атаки дешёвыми.
4. Пять триггеров. Авторитет, срочность, страх, доверие и любопытство отключают проверку запроса. Срочность сопровождает почти все остальные, поэтому главный рубеж защиты — пауза и проверка по независимому каналу.
5. Одиннадцать векторов. Фишинг, вишинг и голосовые дипфейки, квишинг, претекстинг, смишинг, бейтинг, ClickFix, scareware, quid pro quo, компрометация деловой переписки (BEC) и многоканальные атаки. Для каждого в статье разобраны механика, признаки и защита.
6. Что работает. Четыре правила для сотрудников (обратный звонок, запрет на передачу паролей, пауза для нетиповых платежей, регулярные учения), аппаратные ключи FIDO2/WebAuthn вместо SMS-кодов, принцип наименьших привилегий и контроль физического доступа. Разовый тренинг поведение не меняет.
7. Если атака уже произошла. Счёт идёт на минуты: смените пароли, завершите активные сессии, проверьте журнал действий и сообщите в службу ИБ.

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

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

Человек открывает вход в инфраструктуру

Социальная инженерия — один из основных векторов атак на российские компании и один из самых частых методов получения первоначального доступа. По данным Positive Technologies, в 2025 году социальная инженерия применялась в 60% успешных атак на российские организации. Вредоносное ПО встречалось в 71% атак (годом ранее 56%).

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

Фишинг как услуга

В 2026 году первый шаг не требует от атакующего высокой квалификации: его можно купить. Рынок PhaaS (Phishing-as-a-Service, фишинг как услуга) в 2025 году перешёл от наборов страниц к готовым «конвейерам». По данным Positive Technologies, 13% объявлений на теневых форумах за 2024–2025 годы связаны с перехватом 2FA и OTP. Фишинговые наборы нацелены на защиту, которую организации считают надёжной. Медианная цена фишингового решения за год выросла со 125 до 500 долларов.

ИИ делает социальную инженерию массовой и точной

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

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

Почему люди поддаются социальной инженерии

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

Авторитет

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

Пример: письмо или звонок от «руководителя», Федерального казначейства, ФСБ, ИБ-отдела или внутренней ИТ-поддержки.

Срочность

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

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

Страх

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

Пример: угроза штрафа, увольнения, утечки личных данных.

Доверие

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

Пример: письмо от «коллеги», звонок от «знакомого».

Любопытство

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

Пример: флешка, найденная на парковке, QR-код с обещанием подарка.

Последний рубеж против социальной инженерии

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

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

Одиннадцать векторов атак 2025–2026 года: от квишинга до ClickFix

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

1. Фишинг и целевые письма

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

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

Как проходит атака

1. Разведка. Атакующий собирает адреса и детали о сотрудниках из открытых источников, соцсетей, профессиональных площадок и утечек: должности, руководителей, подрядчиков, используемые сервисы.
2. Приманка. Выбирает тему, которую не проигнорируют: премия, счёт на оплату, уведомление от корпоративного сервиса, смена пароля.
3. Маскировка. Подделывает адрес отправителя или регистрирует домен, отличающийся от настоящего одним символом.
4. Пробная рассылка. Отправляет письмо со ссылкой или вложением небольшой группе сотрудников. Малый объём не вызывает срабатывания массовых фильтров.
5. Распространение. Если один получатель открывает вложение или вводит данные на фальшивой странице, атакующий получает доступ к его ящику и рассылает письмо коллегам от его имени. Охват растёт без усилий, а доверие к такому письму выше.

Как распознать фишинг

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

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

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

Для компании: почтовый шлюз с фильтрацией вложений и ссылок, DMARC, SPF и DKIM на собственном домене, корпоративный менеджер паролей с проверкой домена при автозаполнении. Если вложение или ссылку всё же открыли — EDR/XDR на рабочих станциях для блокировки подозрительной активности и безопасный DNS или веб-фильтр, который не пропустит переход на свежезарегистрированный или уже заблокированный домен. Плюс кнопка «сообщить о фишинге» и разбор сообщений службой ИБ.

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

2. Вишинг и голосовые дипфейки

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

Как проходит атака через вишинг

1. Сбор образца. Атакующий находит голос руководителя: публичное выступление, запись вебинара или созвона, видео в соцсети, интервью для СМИ.
2. Клонирование. Нейросеть воспроизводит голос. Для видеосвязи имитируется и лицо.
3. Выбор цели. Звонок идёт сотруднику, который может инициировать платёж или выдать доступ.
4. Давление. Атакующий создаёт срочность: сделка закрывается сегодня, платёж нужен до конца дня, обсуждать это с коллегами нельзя.

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

Как распознать вишинг

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

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

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

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

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

3. Квишинг (QR-фишинг)

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

Масштаб квишинга

По данным отчёта APWG, за 12 месяцев со второго квартала 2024 по третий квартал 2025 года Mimecast выявила более 3 млн уникальных вредоносных кодов. Это глобальная выборка по клиентам всего лишь одного почтового провайдера. Но она показывает, что приём стал массовым.

Как проходит атака квишингом

1. Создание кода. Злоумышленник генерирует QR-код со ссылкой на поддельную страницу корпоративного входа: почты, VPN, портала сотрудников.
2. Размещение. Код попадает в письмо «от ИТ-отдела» или в офисное пространство: на плакат в переговорной, листовку на ресепшене, наклейку поверх настоящего кода.
3. Сканирование. Сотрудник наводит камеру телефона и открывает ссылку, не видя адреса заранее. Телефон часто находится вне корпоративного контура, поэтому почтовый шлюз и прокси содержимое кода не проверяют.
4. Ввод данных. Поддельная страница копирует настоящую, и сотрудник вводит логин и пароль от рабочей учётной записи.
5. Захват доступа. Злоумышленник получает учётные данные и входит в корпоративные сервисы от имени сотрудника.

Защита от квишинга

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

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

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

4. Претекстинг (pretext)

Претекстинг (от англ. pretext — предлог, легенда) — атака по заранее придуманной легенде. Злоумышленник собирает реальные сведения о жертве, выдаёт себя за сотрудника управляющей компании, банка, Федерального казначейства или ИТ-поддержки и шаг за шагом подводит её к нужному действию.

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

Отличие претекстинга от вишинга

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

Как проходит атака через претекстинг

1. Сбор данных. Злоумышленник собирает сведения о сотруднике и его рабочем окружении из утечек персональных данных, сайта компании, соцсетей и других открытых источников (OSINT).
2. Легенда. Выбирает роль, которой сотрудник привык подчиняться: ИТ-поддержка, служба безопасности, бухгалтерия, подрядчик, банк-партнёр.
3. Подтверждение личности. Называет реальные детали: имя руководителя, номер заявки, название внутренней системы, недавнюю командировку.
4. Целевое действие. Подводит сотрудника к шагу: назвать код из SMS, сбросить пароль, перейти по ссылке, установить «программу удалённой поддержки».

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

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

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

Защита от претекстинга

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

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

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

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

5. Смишинг (SMS phishing)

Смишинг (от англ. smishing, SMS phishing) — фишинг через SMS и мессенджеры. Злоумышленник пишет от имени банка, Госуслуг, поликлиники или службы доставки и просит перейти по ссылке или продиктовать код подтверждения. В коротком сообщении проверить отправителя сложнее, чем в письме, а адрес сайта на телефоне виден хуже.

Как проходит атака через смишинг

1. Сбор контактов. Злоумышленник находит рабочие или личные номера сотрудников в утечках и открытых источниках.
2. Рассылка. Отправляет SMS или сообщение в мессенджере от имени знакомого сотрудникам отправителя: ИТ-поддержки, кадровой службы, банка-партнёра, службы доставки.
3. Рабочий повод. Просит подтвердить обычное действие: смену пароля, обновление учётной записи, график отпусков, получение посылки на адрес офиса.
4. Выманивание данных. Получает код подтверждения или логин и пароль на фальшивой странице. Если сотрудник входит с личного телефона, корпоративные фильтры эту ссылку не проверят.
5. Давление. Создаёт угрозу: учётную запись заблокируют, доступ отключат, зарплату не начислят.

Как распознать смишинг

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

Защита от смишинга

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

Для компании: для чувствительных учётных записей использовать аппаратные ключи (FIDO2/YubiKey) вместо SMS-кода — физический ключ нельзя продиктовать по телефону. Научить сотрудников не игнорировать уведомления о входе с нового устройства.

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

6. Бейтинг (baiting)

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

Как проходит атака через бейтинг в компании

1. Подготовка приманки. Злоумышленник готовит носитель с вредоносной нагрузкой. Более продвинутый вариант: устройство, которое не хранит файл, а эмулирует клавиатуру и само вводит команды при подключении.
2. Размещение. Оставляет приманку там, где её найдёт сотрудник: на парковке, в переговорной, в лифте, у ресепшена. Либо отправляет носитель по почте на адрес офиса. QR-код наклеивает поверх настоящего на баннере, информационном стенде или в меню кафе возле офиса.
3. Действие сотрудника. Сотрудник из любопытства подключает носитель к рабочему компьютеру или сканирует код.
4. Закрепление. Нагрузка запускается, и атакующий получает точку входа во внутреннюю сеть.

Как распознать бейтинг

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

Защита от бейтинга

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

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

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

7. ClickFix

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

По данным ESET, число атак через ClickFix выросло на 517% в 2025 году. В отчёте говорится, что на эту технику пришлось почти 8% всех заблокированных атак в первом полугодии 2025 года. Российский аналог такой точности пока не публиковался, но BI.ZONE Threat Intelligence фиксировали весной и летом 2025 года не менее 30 атакованных этим способом российских компаний.

План атаки

1. Доставка. Сотрудник попадает на страницу через поисковую выдачу, рекламу, письмо или взломанный легитимный сайт. Иногда ссылка приходит в мессенджере под видом рабочего документа.
2. Предлог. Страница показывает то, что выглядит штатно: «Подтвердите, что вы не робот», «Ошибка отображения документа», «Требуется обновление браузера».
3. Подготовка команды. Пока сотрудник читает инструкцию, скрипт страницы тайно помещает вредоносную команду в буфер обмена. Видимый текст безобиден, например: «Нажмите кнопку подтверждения».
4. Инструкция. Страница просит выполнить три простых действия: нажать Win+R (окно «Выполнить» в Windows) или открыть терминал, вставить содержимое буфера (Ctrl+V) и нажать Enter. Для macOS и Linux есть аналогичные варианты с терминалом.
5. Запуск. Команда обычно обращается к PowerShell, mshta или другой встроенной утилите, скачивает загрузчик с внешнего сервера и запускает его. Процесс запускает сам сотрудник, поэтому для системы это выглядит как легитимное действие.
6. Закрепление. Загрузчик устанавливает основную нагрузку: программу для кражи паролей и сессий браузера, средство удалённого доступа или шифровальщик. Дальше злоумышленник действует внутри сети с правами этого сотрудника. Если на рабочем компьютере сохранены пароли в браузере или открыты сессии корпоративных сервисов, они попадают к атакующему первыми.

Как распознать

• Сайт требует вставить команду в терминал, PowerShell или окно «Выполнить».
• Проверка «на робота» просит нажать сочетание клавиш вместо выбора картинок.
• Инструкия просит ничего не менять в тексте команды.

Защита

Для сотрудника: никогда не выполнять команды по инструкции со страницы сайта — ни один легитимный сайт не потребует от пользователя нажать Win+R.

Для компании: ограничить запуск PowerShell и окна «Выполнить» для обычных пользователей, отслеживать подозрительные цепочки запуска процессов через EDR, включить сценарий в тренинги. Отключить сочетание клавиш Win + R через групповые политики (GPO).

Последний рубеж: режим ограниченного языка PowerShell (Constrained Language Mode) или полный запрет powershell.exe для обычных пользователей через AppLocker — эта мера останавливает вредоносный код, даже если сотрудник уже скопировал и выполнил команду.

8. Запугивающее ПО (Scareware)

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

Как происходит атака

1. Появление окна. Сотрудник открывает сайт или рекламу, и поверх страницы появляется окно: «Обнаружено 17 вирусов». Ту же картину может показать взломанный легитимный сайт или всплывающее уведомление браузера.
2. Имитация. Окно копирует антивирус или системное уведомление, мигает и не закрывается. Названия и логотипы часто напоминают корпоративные средства защиты, поэтому сотрудник принимает его за сообщение от ИТ-отдела.
3. Требование. Окно предлагает нажать «Устранить сейчас» или позвонить в «поддержку». Номер ведёт к оператору, который просит установить программу удалённого доступа или оплатить «лечение».
4. Добровольная установка. Сотрудник сам загружает вредоносное ПО на рабочий компьютер, стремясь быстрее устранить несуществующую угрозу. Страх и срочность отключают проверку: он не звонит в ИТ-отдел и не сверяется с политикой безопасности.

Как распознать

• Предупреждение появляется в браузере, а не в ОС или антивирусе.
• Окно не закрывается обычным способом, звучит сигнал, указан телефон.
• Требует срочно установить программу или позвонить в «поддержку».

Защита

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

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

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

9. «Услуга за услугу» (quid pro quo)

«Услуга за услугу» (quid pro quo) — атака, в которой злоумышленник сам предлагает помощь и просит взамен пароль, код подтверждения или установку программы удалённого доступа. Обычно он выдаёт себя за сотрудника ИТ-поддержки, подрядчика или оператора связи.

Чем quid pro quo отличается от других атак

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

План атаки

1. Разведка. Злоумышленник собирает названия отделов, фамилии сотрудников, используемые программы и номера внутренних телефонов.
2. Обзвон. Звонит по списку и называется ИТ-поддержкой или подрядчиком. Ищет того, у кого что-то «сбоит».
3. Предложение помощи. «Мы видим ошибку на вашей учётной записи», «Нужно обновить клиент», «Ускорим подключение».
4. Запрос. Просит назвать пароль, продиктовать код из SMS или приложения, установить программу удалённого управления либо перейти по ссылке.
5. Закрепление. Получив доступ, злоумышленник создаёт собственную учётную запись, выгружает данные из браузера, оставляет программу удалённого доступа.

Как распознать

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

Защита

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

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

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

10. Компрометация деловой переписки (BEC)

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

Пример атаки

Компания F6 проанализировала атаки киберпреступной группы Hive0117: с начала 2026 года они разослали фальшивые счета и накладные более чем 3000 компаниям в России, Беларуси, Казахстане и Узбекистане. Около 400 атак оказались успешными, а средняя сумма ущерба с одной компании выросла до 10 млн рублей.

План атаки

1. Разведка. Злоумышленник выбирает цель в финансовом отделе, закупках или бухгалтерии. Изучает структуру компании, подрядчиков и график платежей.
2. Доступ. Получает настоящий почтовый ящик (через фишинг, подбор пароля, утечку) или регистрирует домен-двойник.
3. Легенда. Встраивается в реальную переписку или пишет от имени руководителя. Содержание рутинное: смена реквизитов, срочная оплата счёта.
4. Результат. Сотрудник проводит платёж на счёт злоумышленника или отправляет конфиденциальные данные.

Основные сценарии

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

Как распознать

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

Защита

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

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

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

11. Многоканальные атаки (комбинированный фишинг)

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

План атаки

1. Первый канал. Злоумышленник начинает с того, который проще всего преодолеть: письмо, SMS или мессенджер.
2. Второй канал. Подключает звонок «в продолжение письма», сообщение «от коллеги» или видеозвонок.
3. Взаимные ссылки. Письмо предупреждает о звонке, звонок опирается на письмо.
4. Результат. Жертва решает, что запрос подтверждён независимо, и выполняет его.

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

Как распознать

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

Защита

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

Для компании: регулярные симуляции межканальных сценариев, где нужно явно показать разницу между «ответить в том же чате» и «позвонить по номеру из внутреннего справочника»; регламент платежей и подписаний с проверкой только по самостоятельно найденному контакту; архитектура Zero Trust — непрерывная проверка устройства, геолокации и поведения, микросегментация сети.

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

Как бизнесу выстроить защиту от социальной инженерии

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

Четыре правила для сотрудников

1. Подтверждение обратным звонком. Любой запрос пароля, доступа или платежа подтверждают звонком. Номер берут из корпоративного справочника, а не у звонившего.
2. Запрет на передачу паролей. Пароль не называют по телефону и не отправляют в чате. Исключений нет, даже если звонящий представился службой безопасности или ИТ-поддержкой.
3. Пауза для нетиповых платежей. Операция сверх обычной суммы или в адрес нового получателя проходит через отсрочку и подтверждение двумя независимыми сотрудниками, даже если «горит срочно». Один звонок «от директора» не должен запускать платёж.
4. Регулярные учения вместо разовой проверки. Сценарии различаются по отделам: бухгалтерия и секретариат сталкиваются с разными легендами, поэтому тренировать их нужно по-разному. Помимо писем, в фишинг-симуляции включают QR-коды, SMS и звонки. Результаты нужны для разбора ошибок, а не для наказания.

Технические меры, которые ограничивают ущерб

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

• Устойчивая к фишингу многофакторная аутентификация. Двухфакторная защита обязательна для почты, VPN, CRM и критичных сервисов. Коды из SMS и приложений перехватываются на фишинговой странице, поэтому для привилегированных учётных записей используйте аппаратные ключи FIDO2/WebAuthn.
• Фильтрация почты. Шлюз блокирует письма с поддельным адресом отправителя и опасными вложениями. QR-коды на личном телефоне, SMS, звонки и страницы ClickFix он не видит, поэтому фильтр дополняет остальные меры, но не заменяет их.
• Принцип наименьших привилегий. Сотрудник получает доступ только к данным и системам, которые нужны ему для работы. Скомпрометированная учётная запись бухгалтера не должна открывать сейфы администраторов. Права удобнее выдавать через группы: так их проще пересматривать и быстро отзывать.
• Контроль физического доступа. Посторонних не пускают в офис без сопровождения. Найденные флешки сотрудники сдают в службу ИБ и не подключают.

Что делать, если атака уже произошла

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

Первые шаги: немедленно

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

Куда обращаться

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

Очистка устройства

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

Заключение

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

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

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

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

Чем социальная инженерия отличается от фишинга?

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

Кто такой социальный инженер?

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

Что делать, если я уже назвал пароль или код по телефону?

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

Помогает ли антивирус против социальной инженерии?

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

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

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

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

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

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

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

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

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

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

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

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

Главное

1. Кража данных компании — это несанкционированный доступ к клиентской базе, финансовой отчётности, коммерческой тайне и персональным данным. Потери несут компания, клиенты и сотрудники. Личный пароль от соцсети сюда не относится.
2. Точка входа. Чаще всего это учётная запись одного сотрудника. Цепочка выглядит так: пароль → доступ → данные.
3. Масштаб. По данным F6, за 2025 год и первую половину 2026 года в открытый доступ попало почти вдвое больше баз с данными российских компаний, чем суммарно из Латинской Америки, Ближнего Востока и Африки, Азиатско-Тихоокеанского региона и других стран СНГ.
4. Доля атак через учётные данные. По данным Solar 4RAYS и BI.ZONE, в России она выросла с 19% (2023) до 33–37%.
5. Три пути компрометации пароля. Человеческий фактор (фишинг, повторное использование пароля), технические каналы (инфостилеры, утечки у подрядчиков) и процессные дыры (доступ уволенных, общие пароли администраторов).
6. Ответственность. Компания как оператор отвечает по ст. 13.11 КоАП РФ, злоумышленник — по УК РФ. Эти процессы идут параллельно. О выявленном инциденте оператор уведомляет Роскомнадзор в течение 24 часов, результаты расследования передаёт в течение 72 часов (ст. 21 № 152-ФЗ).
7. Что делать. Закрепить парольную политику настройкой, включить двухфакторную аутентификацию, проверять пароли заранее, отзывать доступ при увольнении и хранить пароли централизованно. Дисциплина отдельных сотрудников на всю компанию не масштабируется.

Что такое кража данных компании

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

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

Злоумышленнику грозит уголовная ответственность: ст. 272 УК РФ (неправомерный доступ к компьютерной информации) или ст. 183 УК РФ (коммерческая тайна). Компания отвечает по другим нормам. Как оператор персональных данных она может получить штраф по ст. 13.11 КоАП РФ. Эту ответственность разберём ниже.

Масштаб в России

По данным F6, за 2025 и первую половину 2026 года в открытом доступе появилось 326 баз данных российских компаний — почти вдвое больше, чем суммарно из Латинской Америки, стран Ближнего Востока и Африки, Азиатско-Тихоокеанского региона и других государств СНГ. В утечках данных российских компаний содержалось около 1,175 млрд строк с данными пользователей. По данным отчёта InfoWatch об утечках, в 2023–2025 годах в России скомпрометировано 4,5 млрд записей персональных данных.

Официальная статистика Роскомнадзора скромнее отраслевых оценок. В 2024 году регулятору официально сообщили об утечках только 200 компаний — почти вдвое меньше, чем годом ранее, при среднем ущербе 41 млн рублей на инцидент (Коммерсантъ). В первом полугодии 2025 года Роскомнадзор зафиксировал лишь 35 случаев и чуть более 39 млн скомпрометированных записей, а по их итогам завели всего шесть протоколов по ст. 13.11 КоАП РФ (ТАСС).

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

Два свежих случая

Tez Tour, сентябрь 2026 года. Группировка DataSuckers заявила об атаке на туроператора. По данным Хакера, 15 сентября она изменила главную страницу сайта и написала, что «скачала и уничтожила» 395,5 млн записей: бронирования, заказы туров, бронирования отелей и около 252 млн финансовых транзакций. Группировка также заявила о краже паспортов, данных банковских карт, телефонов и адресов клиентов, о перезаписи дисков и удалении резервных копий.

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

Додо Пицца, конец сентября 2026 года. Сеть пиццерий сообщила клиентам о кибератаке на свою ИТ-систему и возможной утечке персональных данных. По данным CNews от 29 сентября 2026 года, компания опубликовала уведомление в официальном паблике в Telegram. В нём говорилось, что атака произошла «вчера и сегодня». Под угрозой данные клиентов, которые пользуются приложением и заказывают еду на дом: имена, даты рождения, номера телефонов, адреса электронной почты и адреса доставки.

При чём здесь пароль сотрудника: цепочка от логина до утечки данных

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

Цепочка компрометации: пароль → доступ → данные

Атака идёт в три шага. Каждый из них закрывается отдельными мерами.

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

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

Что говорят данные России и мира

По данным Solar 4RAYS (ГК «Солар») и BI.ZONE, доля успешных атак на российские компании, начавшихся с компрометации учётных данных сотрудников, за три года выросла с 19% до 33–37%. Для сравнения — аналогичный показатель по миру, по данным IBM X-Force:

По методологии BI.ZONE, построенной на другой выборке (почти 700 000 корпоративных аккаунтов), 2024 год выглядит мягче — 27% против 37% у Solar 4RAYS. Российские показатели растут быстрее мировых, но и мировой уровень остаётся высоким: компрометация учётных данных третий год подряд входит в число главных причин атак и у IBM X-Force, и в российских отчётах.

Почему «обычные» аккаунты опаснее, чем кажется

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

Кража данных, кража пароля и взлом пароля — разные вещи

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

У этого разграничения есть практический смысл. Меры защиты для каждого звена свои:

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

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

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

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

Человеческий фактор

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

• Фишинг. Письмо ведёт на поддельную форму входа. Сотрудник вводит логин и пароль и не замечает разницы в адресе отправителя или в домене ссылки. Данные уходят напрямую атакующему.
• Повторное использование пароля. Пароль утекает с форума, из интернет-магазина или сервиса доставки, а затем подходит к корпоративной почте. По данным BI.ZONE, 9% сотрудников регистрируются на внешних сервисах рабочей почтой, и каждый пятый из них ставит тот же пароль, что и на работе.

Технические каналы

Эти каналы работают без прямого участия сотрудника.

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

Процессные дыры

Здесь вина лежит на самой компании.

• Доступ уволенных сотрудников. Учётная запись остаётся рабочей неделями, иногда месяцами. Особенно часто так бывает, когда права выдавали точечно, разными администраторами и в разное время, и полного перечня нет ни у кого.
• Общие и дефолтные пароли администраторов. По данным BI.ZONE, 35% инцидентов высокой критичности в российских компаниях связаны с небезопасной парольной политикой администраторов.

Все три направления закрываются только вместе и только выстроенным процессом.

Что теряет компания, когда уходит один пароль

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

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

Сколько кража данных стоит компании: штрафы и ответственность

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

Оборотный штраф: как его считают

Оборотный штраф вводит ч. 15 ст. 13.11 КоАП РФ. Для юридического лица сумма зависит от выручки за предыдущий год и от того, первое это нарушение или повторное.

Две ответственности за один инцидент

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

• Компания как оператор отвечает по КоАП РФ административно, штрафом. Это не зависит от того, нашли ли того, кто стоял за атакой.
• Тот, кто использовал данные, отвечает по ст. 272.1 УК РФ. Она устанавливает уголовную ответственность за незаконное использование, передачу, сбор и хранение персональных данных.

Уведомление Роскомнадзора

Статья 21 Федерального закона № 152-ФЗ обязывает оператора уведомить Роскомнадзор об инциденте. Первичное уведомление отправляют в течение 24 часов, результаты внутреннего расследования — в течение 72 часов. Нарушение сроков рассматривается отдельно от самой утечки.

Несколько строк настроек доступа могут стоить компании миллионов. Попробуйте Пассворк бесплатно

Что делать, чтобы пароль сотрудника не стал причиной утечки

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

Пять мер закрывают большую часть цепочки компрометации:

1. Формализованная парольная политика. Минимальная длина, требования к сложности и срок действия пароля — не рекомендация в корпоративной памятке, а настройка, которую нельзя обойти при сохранении записи.
2. Двухфакторная аутентификация. Отдельный фактор подтверждения резко снижает цену утечки одного пароля. Остальные меры она при этом не заменяет: инфостилеры умеют воровать уже активную сессию, обходя повторный ввод кода при следующем входе.
3. Мониторинг и аудит использования паролей. Регулярная проверка на слабые, устаревшие и потенциально скомпрометированные пароли проводится заранее. Расследование уже случившегося инцидента для этого ждать не нужно.
4. Немедленная деактивация доступа при увольнении или смене роли. Учётная запись без присмотра — открытая дверь, которую никто не закрыл после того, как человек ушёл из компании или сменил отдел.
5. Централизованное хранение и ротация паролей вместо таблиц, стикеров на мониторах и переписки в мессенджерах, где пароль живёт неограниченное время и доступен всем, кто получил ссылку на файл, даже спустя годы после смены пароля.

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

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

Каждая из пяти мер выше получает конкретную настройку. Правила не зависят от памяти сотрудников, а права и история действий видны администратору в одном месте.

• Хранение. Пароли уходят из таблиц и личных заметок в сейфы с контролем доступа.
• Политики паролей. Администратор задаёт требования к длине и сложности, и генератор создаёт пароли по этим правилам. Слабый пароль не попадёт в запись, если сотрудник не придумывает его сам.
• Права. Роли и группы определяют, кто и к каким записям имеет доступ. Не нужно вручную отслеживать права каждого сотрудника в десятке систем.
• Аудит. Журнал фиксирует, кто и когда работал с записью. Он пригодится при расследовании инцидента и помогает подтвердить меры защиты при проверке по 152-ФЗ.
• Проверка паролей. Панель безопасности показывает слабые и повторяющиеся пароли до инцидента.
• Второй фактор. Поддержка биометрии, ключей доступа и аппаратных ключей. Для подтверждения входа есть отдельное приложение Пассворк 2ФА.
• Увольнение. Доступ к сейфам отключается централизованно. Не нужно обходить десятки систем, в которых человек успел получить права за годы работы.

Привычки пользователей: как закрыть человеческий фактор

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

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

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

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

Заключение

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

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

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

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

Кража данных и кража пароля — это одно и то же?

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

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

Да. Данные утекают через инсайдера с легитимным доступом, уязвимость в приложении, незащищённый API или ошибку в настройках облачного хранилища. Пароль сотрудника — самая частая точка первоначального доступа, но далеко не единственная: по данным Solar 4RAYS и BI.ZONE, компрометация учётных данных стоит за 33–37% успешных атак на российские компании.

Кто отвечает за утечку — сотрудник, чей пароль украли, или компания?

За утечку персональных данных как оператор отвечает компания — по ч. 15 ст. 13.11 КоАП РФ, независимо от того, что непосредственной причиной стал пароль одного сотрудника. Отдельно по ст. 272.1 УК РФ отвечает тот, кто незаконно использовал, передал, собрал или хранил эти данные: похититель, не оператор.

Как быстро нужно уведомить Роскомнадзор об утечке?

Согласно ст. 21 Федерального закона № 152-ФЗ, оператор обязан направить в Роскомнадзор первичное уведомление в течение 24 часов с момента обнаружения утечки и результаты внутреннего расследования инцидента в течение 72 часов. Нарушение этих сроков рассматривается отдельно от самого факта компрометации данных и не освобождает от штрафа по ст. 13.11 КоАП РФ.

Помогает ли двухфакторная аутентификация, если пароль уже скомпрометирован?

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

1. Требования. Положение Банка России № 757-П распространяется на всех субъектов страхового дела: страховые организации, страховых брокеров и общества взаимного страхования (ОВС). Уровень защиты зависит от суммы активов за последние шесть месяцев: свыше 20 млрд руб. — стандартный, остальные — минимальный.
2. Три риска. Агентская сеть (агенты, брокеры, подрядчики работают вне периметра), данные о здоровье в ДМС и страховании жизни (ст. 10 152-ФЗ), передача данных в АИС страхования.
3. Что нужно от менеджера паролей. Временный доступ для внешних пользователей, ролевая модель и типы сейфов, журнал аудита с экспортом в SIEM, клиентское шифрование zero-knowledge, сервисные аккаунты и API, офлайн-доступ.
4. Как Пассворк отвечает этим требованиям. Одно решение для паролей сотрудников и секретов интеграций, с общей ролевой моделью и журналом аудита. Сертификат ФСТЭК (4-й уровень доверия), запись в реестре российского ПО.

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

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

Рост виден в цифрах. В 2025 году число утечек из страховых компаний выросло примерно на 40% по сравнению с 2024 годом: по минимальным оценкам, речь идёт о 10–15 случаях среди крупнейших страховщиков, и это без учёта инцидентов, которые не стали публичными. По предварительным оценкам ГК InfoWatch, персональные данные присутствовали в 100% утечек из страховых организаций за 2025 год.

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

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

Кто из страховых организаций обязан защищать информацию по 757-П и что это значит на практике

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

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

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

Что требует закон и что требует положение

Закон РФ № 4015-1 «Об организации страхового дела в Российской Федерации» обязывает страховщиков обеспечивать сохранность, конфиденциальность и целостность информации, используемой в страховой деятельности. Положение № 757-П детализирует эту обязанность: задаёт технические требования и уровни защиты.

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

Оценка соответствия и ответственность

Оценку соответствия проводят ежегодно, не позднее 10-го рабочего дня календарного года. За нарушения предусмотрена ответственность по ст. 13.12 КоАП РФ: штраф от 10 000 до 30 000 руб., приостановка деятельности на срок до трёх месяцев, изъятие несертифицированных средств защиты информации.

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

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

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

Три типовых риска внешнего доступа

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

Почему парольной политики недостаточно

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

Как устроить внешний доступ

1. Временная или одноразовая ссылка на запись. Она действует ограниченное время или ограниченное число раз.
2. Групповые права вместо персональных. Доступ привязан к роли и группе, а не к человеку.
3. Отзыв доступа одним действием. При завершении сотрудничества права снимаются сразу во всех местах.
4. Журнал аудита. Каждое обращение к записи фиксируется, и ИБ-служба видит, кто и когда с ней работал.

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

Данные о здоровье клиентов в ДМС и страховании жизни: повышенные требования к доступу

Сведения о состоянии здоровья относятся к специальной категории персональных данных. Для их обработки ст. 10 Федерального закона № 152-ФЗ «О персональных данных» устанавливает повышенные требования к защите и отдельное согласие субъекта. Поэтому доступ к таким данным в страховой компании нужно ограничивать строже, чем к остальной клиентской базе.

Почему это касается ДМС и страхования жизни

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

Доступ к такой базе должен быть уже, чем к обычной клиентской CRM. Сотрудник, который оформляет полисы ОСАГО или КАСКО, не должен видеть медицинскую историю клиента по ДМС.

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

Как это реализовать

1. Отдельный сейф. Данные ДМС и страхования жизни хранятся в собственном сейфе, а не в общем разделе с клиентскими записями.
2. Отдельный администратор. У сейфа свой администратор, который управляет составом доступа.
3. Доступ по роли. Права получают только сотрудники, которым работа с такими данными нужна по должности.
4. Клиентское шифрование нулевого знания (zero-knowledge). Данные шифруются на устройстве сотрудника, и сервер не может их прочитать.

Передача данных в АИС страхования: ещё одна точка, которую нужно защищать

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

Масштаб системы

Объём данных в АИС страхования в 2025 году вырос в 1,3 раза и составил 84,6 млн договоров. Система хранит сведения о более чем 120 млн полисов ОСАГО, 30 млн договоров КАСКО и ДСАГО и 20 млн договоров страхования жилья (CNews).

Как устроено хранение таких данных

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

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

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

Как защитить

Такую интеграцию защищают сервисные учётные записи с тремя свойствами:

• Собственные права. Доступ ограничен задачами интеграции.
• История использования. Журнал показывает, кто и когда получал учётные данные.
• Ротация без остановки интеграции. Ключ меняют централизованно, а система подхватывает новое значение.

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

Менеджеру паролей для страховой компании нужны шесть функций: временный доступ для внешних пользователей, ролевая модель с типами сейфов, журнал аудита с экспортом в SIEM, клиентское шифрование zero-knowledge, сервисные аккаунты с API и офлайн-доступ.

Шесть обязательных функций

Какие риски закрывают эти функции

• Агентская сеть. Временный и одноразовый доступ.
• Данные о здоровье. Типы сейфов с обязательными администраторами и ролевая модель.
• Интеграция с АИС страхования. Сервисные аккаунты и API.

Журнал аудита и шифрование нужны любой компании, независимо от размера. ГОСТ Р 57580.1 предъявляет требования к защите информации и при минимальном, и при стандартном уровне защиты.

Журнал аудита и SIEM на оценке соответствия

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

Офлайн-доступ для розничной сети

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

С чего начать внедрение

Порядок действий описан в пошаговом руководстве по внедрению менеджера паролей: от аудита текущего состояния паролей до распределения ролей и подключения интеграций.

Как Пассворк закрывает три сценария страховой компании

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

Доступ агентов и подрядчиков

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

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

Данные о здоровье в ДМС и страховании жизни

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

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

Интеграция и передача данных регулятору

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

Офлайн-доступ

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

Сертификация

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

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

Три риска определяют выбор менеджера паролей для страховой компании

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

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

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

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

Вопросы о менеджере паролей для страховых организаций

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

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

Чем требования к страховым брокерам отличаются от требований к самим страховым организациям?

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

Нужно ли по-другому защищать данные о здоровье клиентов в ДМС?

Да. Статья 10 Федерального закона № 152-ФЗ относит сведения о состоянии здоровья к специальной категории персональных данных с повышенными требованиями к защите и отдельным согласием на обработку. В ДМС и страховании жизни эти данные хранятся как часть страхового случая. На практике это означает разграничение доступа по типам сейфов и ролям вместо общего доступа всех сотрудников к базе ДМС.

Как передать доступ агенту без риска, что пароль останется у него после увольнения?

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

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

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

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

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

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

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

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

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

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

В 2025 году объём корпоративных данных, которые сотрудники отправляют в публичные нейросети, вырос в 30 раз — такие данные приводят аналитики ГК «Солар» по результатам анализа трафика 150 российских организаций. У 60% этих компаний нет формализованной политики работы с ИИ-сервисами, поэтому поток остаётся практически неконтролируемым. Сотрудники копируют документы, код и рабочую переписку в чат нейросети, чтобы сэкономить время, и почти никто не задумывается, куда уходят эти данные.

Для ИБ-отдела это слепая зона: CASB, DLP и сетевые фильтры видят устройства и каналы связи, но не содержимое, которое сотрудник вводит в окно чата. С автономными ИИ-агентами, которые сами подключаются к почте, CRM и репозиториям, эта слепая зона становится ещё шире.

В статье разберём, как теневой ИИ устроен, какие громкие инциденты он уже вызвал (от Samsung и Amazon в 2023 году до утечек через ИИ-агентов в 2026-м) и какие меры реально помогают взять его под контроль.

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

1. Большинство сотрудников уже используют ИИ в работе. Официально это разрешено далеко не во всех компаниях, поэтому значительная часть остаётся вне поля зрения ИБ.
2. Классические CASB, DLP и сетевые фильтры теневой ИИ не видят. Утечка идёт через содержимое промпта, а не через неучтённое устройство или заблокированный канал.
3. Агентный теневой ИИ опаснее чата. Автономный ИИ-агент с доступом к почте, CRM или репозиторию открывает всю связанную систему, а не отдельный промпт с чувствительными данными.
4. Опасным ИИ-агента делают три условия одновременно: доступ к закрытым данным, работа с непроверенным внешним контентом и возможность отправить результат наружу. Уберите любое из трёх, и риск заметно снижается.
5. Хроника инцидентов 2023–2026 годов показывает рост масштаба. Путь идёт от одного сотрудника и одного чата до массовой утечки через ИИ-агентов и первого официального раскрытия такого инцидента перед регулятором рынка ценных бумаг.
6. Самый опасный канал утечки — пароли, API-ключи и токены. Они открывают доступ к самой системе, а значит, утечка секрета превращается в потенциальное проникновение в инфраструктуру.
7. Штраф за утечку персональных данных в России доходит до 500 млн ₽ при повторном нарушении. Оборот уже украденных данных подпадает под уголовную статью.
8. Полный запрет не работает: сотрудники переходят на личные устройства. Работает связка из трёх мер: политика, технический контроль канала и легальная альтернатива, которая не уступает по скорости.

Что такое теневой ИИ и чем он отличается от теневых ИТ

Теневой ИИ (Shadow AI) — так называют ситуацию, когда сотрудники применяют генеративный ИИ и большие языковые модели (large language model, LLM) для рабочих задач без одобрения ИТ- или ИБ-отдела: через личные аккаунты в публичных сервисах, в обход корпоративных политик.

По данным опроса «Пачки», ИИ используют 88% сотрудников российских компаний, и только 24% ответили, что ИИ внедрён в компании официально — разрыв в 64 пункта показывает, что бизнес в среднем не видит и не контролирует основную часть этой активности.

Термин часто путают с теневыми ИТ (shadow IT), но разница принципиальная, и от неё зависит, кто и как отвечает за риск. Теневые ИТ — это неучтённое оборудование и софт: личный ноутбук в рабочей сети, самовольно поставленное приложение, забытый облачный диск с рабочими файлами. Риск здесь в самом факте существования канала, который никто не видит и не проверяет.

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

Есть и третий вариант, который в таблицу не попал: теневой агентный ИИ (Agentic Shadow AI). Это автономные ИИ-агенты, которых сотрудники подключают к рабочим системам без ведома ИТ и ИБ. Агент не только получает текст от человека, но и сам обращается к почте, репозиториям, облачным хранилищам и внешним API по выданным ему токенам и ключам. Утечка в этом случае идёт уже не через промпт, а через действия агента. Поэтому его риски мы разберём отдельно, ниже в статье.

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

• CASB (брокер безопасности облачного доступа) выявляет несогласованные SaaS-сервисы и ограничивает передачу данных в них.
• NGFW (межсетевой экран) и SWG (защищённый веб-шлюз) фильтруют трафик на уровне сети.
• MDM, EMM и UEM (системы управления мобильными устройствами) задают конфигурацию устройств и блокируют установку стороннего софта.
• NAC (контроль доступа к сети) не пускает в сеть неучтённое оборудование.

Это преимущественно задача ИТ-отдела: контроль устройств, трафика и приложений.

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

Громкие инциденты теневого ИИ: от одного сотрудника до сотен организаций

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

2023: начало. Компании впервые сталкиваются с ChatGPT

В 2023 году корпорации увидели, что сотрудники уже работают с публичными нейросетями, а контроля над этим нет.

• Samsung. Инженеры загрузили в ChatGPT исходный код. После этого компания запретила генеративный ИИ на рабочих устройствах (Anti-Malware.ru).
• Amazon. Юристы предупредили сотрудников в корпоративном чате не делиться конфиденциальной информацией с ChatGPT. Ответы бота «близко совпадали» с внутренними материалами компании (Habr).
• Apple. Компания ограничила использование ChatGPT и ИИ-ассистента для кода из-за риска утечки данных (Fortune).
• JPMorgan. Ограничили доступ сотрудников к ChatGPT как часть стандартного контроля стороннего ПО (CNN).
• Verizon. Закрыла доступ к ChatGPT с корпоративных систем, сославшись на риск потери контроля над данными клиентов (Verizon Newsroom).

Реакция: запрет. Уже тогда он казался временной мерой.

Июнь–август 2025: чужие диалоги с ИИ оказались в открытом доступе

Утечки перестают зависеть от одного сотрудника. В июне 2025 года лента Discover в приложении Meta AI (Meta признана экстремистской, деятельность запрещена в РФ) показывала личные запросы пользователей: медицинские вопросы, юридические письма, домашние адреса. Многие не знали, что их переписка стала публичной (eWeek).

В июле–августе та же история повторилась с функцией «поделиться» в ChatGPT и Grok. Google проиндексировал общие ссылки на диалоги, и часть переписки стала доступна через обычный поиск. OpenAI отключила функцию в течение суток после огласки. Это были легальные функции ИИ-инструментов, не взлом: утечка данных возникла из-за механики работы сервисов и того, что пользователи не понимали их настроек (eWeek, Fortune).

Январь 2026: служебные документы загружены в публичный ChatGPT руководителем ведомства

И.о. директора американского Агентства по кибербезопасности и безопасности инфраструктуры (CISA) загрузил в публичную версию ChatGPT документы с пометкой «для служебного пользования». Даже в ведомстве, которое отвечает за кибербезопасность страны, правило «не нести рабочие данные в публичные ИИ» не удержалось на уровне руководства (3DNews, Anti-Malware.ru).

Май 2026: утечка через теневой ИИ стала поводом для раскрытия перед регулятором

Сотрудник американского банка CB Financial Services загрузил в неодобренное ИИ-приложение имена, номера социального страхования и даты рождения клиентов. Он делал это с личного устройства и личного аккаунта, пока готовил макет презентации. При этом у банка уже был одобренный ИИ-инструмент.

Банк узнал об инциденте 5 мая, признал его существенным 7 мая и 11 мая подал форму 8-K (отчёт о существенном событии, который публичные компании в США обязаны подавать в Комиссию по ценным бумагам и биржам, SEC, в течение четырёх рабочих дней) по пункту 1.05 — он как раз отведён под инциденты кибербезопасности. Это первый такой отчёт, где существенный инцидент прямо отнесён на теневой ИИ.

Утечка запустила три обязательства сразу: раскрытие информации регулятору рынка ценных бумаг, уведомление банковского надзорного органа в течение 36 часов и уведомление клиентов по американскому закону о защите финансовой тайны. Действовавшие в банке DLP-политики не сработали: загрузка шла через авторизованный браузерный канал (American Banker).

Июль 2026: Россия. Суд признал законным увольнение за выгрузку отчётов в DeepSeek

Директор по продажам инженерной компании «Энергопроф» загрузила в DeepSeek внутренние отчёты с данными о зарплатах и бюджетных планах. Бабушкинский районный суд Москвы признал её увольнение законным, квалифицировав это как разглашение коммерческой тайны. Загрузка в нейросеть была одним из оснований увольнения, но не единственным (Право.ру, Коммерсантъ).

Сентябрь 2026: ИИ-агенты сами выложили 13 000 внутренних скриншотов в открытый GitHub

Разработчики просили ИИ-агентов проверить исправление интерфейса. Агент не мог прикрепить скриншот к закрытому pull request (запросу на слияние изменений в общий код). Загрузить картинку в такой запрос можно только через браузер, а агент работал из командной строки и такого доступа не имел. Чтобы показать скриншот рецензентам, агент сам создавал публичный репозиторий и выкладывал данные туда. Нашлось более 13 000 изображений из 900+ репозиториев в 343 организациях по всему миру, среди них несколько компаний из американского рейтинга Fortune 500.

Среди утёкшего: биллинговые записи коммунальной компании, консоль казначейства и экран вывода средств финансовой компании, 1000+ скриншотов нерелизных функций ИТ-вендора. Агент работал на ноутбуке сотрудника вне корпоративной структуры GitHub, поэтому служба безопасности ничего не видела (Help Net Security).

Что показывает хронология

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

Это общий тренд. По данным Verizon DBIR 2026, 67% пользователей входят в ИИ-сервисы с корпоративных устройств через личные аккаунты, а теневой ИИ стал третьим по частоте ненамеренным внутренним действием, и его доля выросла вчетверо за год.

В России ситуация та же: по данным Солара, почти 40% обращений к публичным ИИ-сервисам содержали конфиденциальную информацию (из анализа 12 000 взаимодействий). Из них 41% пришлось на исходный код и конфигурации, 30% на персональные и финансовые сведения, 18% на интеллектуальную собственность и 11% на пароли, токены и API-ключи. На команды разработки пришлось 43% таких событий. Отдельное исследование УЦСБ и «Солара» показало, что 42,4% из 102 опрошенных компаний подозревали утечки через ИИ, а 8,1% уже столкнулись с реальными инцидентами.

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

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

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

Умысел на утечку данных в этой картине почти не встречается. По данным SearchInform (2025), 66% инцидентов утечки происходят из-за ошибок и незнания базовых правил кибергигиены, а не намеренных действий. Сотрудник в момент вставки текста в промпт не думает о периметре компании и о том, где эти данные окажутся дальше. Он решает конкретную рабочую задачу самым быстрым из доступных ему способов.

Как данные утекают в нейросети: векторы утечки

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

Чат-окно веб-интерфейса

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

Загрузка файлов для анализа

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

Браузерные плагины с доступом к странице

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

OAuth-доступ и ИИ-боты на звонках

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

Агенты и плагины с доступом к рабочим инструментам

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

Неучтённые API-интеграции

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

Обучение модели на пользовательском вводе

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

Опасность растёт с числом комбинаций

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

Агентный ИИ против чат-интерфейса: разный масштаб утечки

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

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

Три условия, при которых ИИ-агент становится опасен

Разработчик Саймон Уиллисон предложил модель для оценки риска конкретного агента, которую в индустрии называют «смертельной триадой» (Lethal Trifecta). Агент опасен, если одновременно совмещает:

1. Доступ к закрытым данным — агент может читать секреты, внутренние документы, переписку или базы данных.
2. Непроверенный внешний контент — агент обрабатывает веб-страницы, письма, тикеты: текст, который не контролирует владелец агента.
3. Отправка данных наружу — у агента есть способ передать результат во внешний мир: запрос, письмо, публикация, вызов API.

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

Как разворачивается атака через ИИ-агента

1. Злоумышленник прячет вредоносную инструкцию в источнике, которому агент доверяет: публичной веб-странице, входящем письме, тикете в поддержку. Это непрямая промпт-инъекция (indirect prompt injection): команда приходит не от пользователя агента, а через контент, который агент обрабатывает как часть обычной задачи.
2. Агент читает этот контент: суммирует письмо, разбирает тикет, ищет информацию на странице.
3. Модель обрабатывает текст наравне с настоящими инструкциями и выполняет скрытую команду как часть задания.
4. Команда предписывает агенту прочитать закрытые данные и передать их наружу: добавить в исходящий запрос, вставить в URL, вызвать внешний API.

Масштаб проблемы индустрия признала официально: в рейтинге OWASP Top 10 for LLM Applications за 2026 год категория «избыточная автономность» (excessive agency) поднялась с восьмого места на третье, а промпт-инъекция третий год подряд занимает первое.

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

Утечка учётных данных и секретов через ИИ

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

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

В промпт не должны попадать:

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

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

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

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

Правовые и финансовые риски: 152-ФЗ, 420-ФЗ и ст. 272.1 УК РФ

Утечка персональных данных через нейросеть подпадает под те же нормы, что и любая другая утечка данных, а штрафы за неё за последний год выросли на порядок. Данные, введённые сотрудником в публичную модель, размещённую за пределами РФ, дополнительно попадают в контур трансграничной передачи данных по Федеральному закону № 152-ФЗ «О персональных данных».

С 30.05.2025 по Федеральному закону № 420-ФЗ штраф за утечку персональных данных по ст. 13.11 КоАП РФ достигает 15 млн ₽ за первое нарушение и до 500 млн ₽ оборотного штрафа при повторном. Оборотный штраф считается не от суммы причинённого ущерба, а от выручки компании целиком, что делает повторное нарушение риском совершенно иного масштаба, чем первое.

Отдельно действует уголовная ответственность за незаконный оборот уже похищенных персональных данных. С 11.12.2024 по ст. 272.1 УК РФ она достигает 10 лет лишения свободы. Норма касается оборота уже скомпрометированных данных, а не самого факта утечки, поэтому важно различать: утечка сама по себе, как правило, административное нарушение оператора, а оборот уже украденного (продажа или передача третьим лицам) — отдельный уголовный состав.

Масштаб проблемы виден и в статистике регулятора: за 2025 год Роскомнадзор зафиксировал 118 случаев компрометации баз персональных данных, свыше 52 млн записей. Теневой ИИ не единственный источник этой статистики, но пополняет её особенно трудно отслеживаемым каналом: утечка через промпт не оставляет файла, который можно найти при внутреннем расследовании инцидента.

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

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

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

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

Проблема не зависит от страны. По данным IBM Cost of a Data Breach Report (2026), международного исследования утечек данных, теневой ИИ стал фактором в 43% случаев из выборки: это больше чем вдвое по сравнению с годом ранее, а свыше двух третей организаций до сих пор не имеют процесса управления этим риском.

Рабочая альтернатива запрету строится на трёх элементах одновременно:

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

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

Три этапа контроля теневого ИИ: план 30/60/90 дней

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

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

По данным исследования SearchInform, обучение сотрудников считают самой эффективной мерой 81% опрошенных компаний, и оно входит в каждый этап.

Этап 1 (0–30 дней): видимость и правила

Первый этап не требует бюджета на новые системы. Узнать, какие нейросети сотрудники уже используют, можно и без специализированных инструментов: отфильтруйте логи прокси или файрвола по доменам популярных ИИ-сервисов (chat.openai.com, claude.ai, gemini.google.com и подобным) — это сразу покажет, кто и как часто к ним обращается.

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

Собрав эту картину, опишите правила простым языком. Объясняйте их на конкретных примерах: что нельзя вставлять в промпт (пароли, ключи API, персональные данные, фрагменты исходного кода). Общие слова про «безопасность данных» не работают.

Этап 2 (30–60 дней): технический контроль

Мониторинг сетевого трафика и CASB-шлюзы (Cloud Access Security Broker, посредник между пользователями и облачными сервисами) нужно настроить на публичные ИИ-сервисы, а не только на почту и флешки. Семантический анализ промптов и контроль буфера обмена показывают, какие данные и в каком объёме уходят наружу через браузер.

Отдельно: контроль секретов

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

Этап 3 (60–90 дней): санкционированная альтернатива

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

Можно ли запускать этапы параллельно

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

Теневой ИИ нельзя запретить, но можно сделать управляемым

Полный запрет нейросетей проигрывает с самого начала: сотрудники всё равно найдут способ решить рабочую задачу быстрее, если корпоративного инструмента для этого попросту нет. Запрет решает отчётность перед аудитом, но не повышает безопасность, а разница между этими двумя задачами и есть то, что отличает компанию, пережившую инцидент без последствий, от компании, которая попала в заголовки СМИ вместе с CB Financial Services или инженерной компанией из Бабушкинского суда.

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

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

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

Что такое теневой ИИ простыми словами?

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

Чем теневой ИИ отличается от теневых ИТ?

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

Чем утечка через ИИ-агента отличается от утечки через чат-бота?

Чат передаёт только то, что сотрудник ввёл вручную, и утечка ограничена объёмом одного промпта или файла. Агент с доступом к CRM, почте или репозиторию действует от имени всей системы: одно скомпрометированное или слишком широкое подключение открывает доступ ко всей связанной базе, а не к одному документу — такую утечку почти не видят DLP и CASB, настроенные на трафик браузера.

Какой штраф грозит за утечку персональных данных через нейросеть?

С 30.05.2025 по ст. 13.11 КоАП РФ (420-ФЗ) штраф достигает 15 млн ₽ за первое нарушение и до 500 млн ₽ оборотного штрафа при повторном. За незаконный оборот уже похищенных данных с 11.12.2024 действует уголовная ответственность по ст. 272.1 УК РФ, до 10 лет лишения свободы.

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

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

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

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

Используются ли мои данные из ChatGPT для обучения модели?

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

Как узнать, что сотрудники используют ИИ в обход политики?

Отправная точка — логи прокси или файрвола, отфильтрованные по доменам популярных ИИ-сервисов, и аудит браузерных расширений на рабочих устройствах: подробнее эти способы разобраны в разделе «Этап 1» плана 30/60/90 дней выше. Журнал аудита в хранилище паролей дополняет эту картину: он фиксирует, кто обращался к учётным данным незадолго до подозрительной сетевой активности, и помогает сузить круг при расследовании конкретного инцидента.

Программы-вымогатели (ransomware): статистика атак и защита

В 2025 году шифровальщики атаковали российские компании на 15% чаще, а рекордный разовый выкуп достиг 500 млн рублей. Разбираем механику, векторы и план защиты от ransomware.

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

Почему опасно хранить пароли в браузере: риски, статистика и защита

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

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

Постквантовая криптография: угрозы и стандарты — 2026

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

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

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

Политики паролей

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

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

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

Как настроить и что проверяет политика паролей

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

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

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

Кто может настраивать политики паролей

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

Ограничение на создание паролей

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

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

Как это работает на практике

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

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

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

Главное о политиках паролей

• Что это? Политика задаёт требования к длине, типам символов и сроку действия пароля. Её можно назначить отдельной записи, сейфу или папке.
• Где настраивается? В новом разделе организации Политики паролей. Доступ к разделу определяет отдельное право роли.
• Кому доступна? права на доступ к разделу политик определяется настройками ролей (блок Общие).
• Можно ли создать пароль не по политике? Зависит от того, что выбрано в Управлении сейфами — если переключатель «Создание записей, не соответствующих политике паролей» выключен, пароль, который не проходит по политике, сохранить нельзя.
• Какая политика будет выбрана по умолчанию после обновления? При обновлении до Пассворк 7.8 всем существующим записям автоматически назначается Базовая политика.
• Какие различие в версиях Пассворка? В Стандартной версии Пассворка доступна только Базовая политика. Создавать собственные политики можно в Расширенной версии.
• Что попадает в Панель безопасности? Запись, не соответствующая политике, попадает в категорию «слабые» или «старые» в панели безопасности, а название политики в её карточке подсвечивается красным.

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

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

1. Разные требования для критичных и второстепенных сейфов

• Ситуация: один сейф хранит доступы к инфраструктуре и базам данных, а другой хранит пароли от внутренних сервисов с низким риском, например корпоративной вики.
• Решение: администратор создаёт отдельную политику для сейфа с более строгими требованиями (например, минимальная длина 16 символов и срок действия 60 дней) и оставляет для остальных сейфов политику по умолчанию «Базовая».
• Польза: критичные системы получают повышенные требования к паролям, а сотрудники, которые работают с менее чувствительными данными, не сталкиваются с избыточными ограничениями.

2. Политика для сейфа с общими аккаунтами в соцсетях

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

3. Подготовка к проверке соответствия

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

Улучшенный веб-интерфейс

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

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

Избранные сейфы и папки

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

Новый тип поля «Скрытый текст» в карточке записи

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

Новые угрозы в Панели безопасности

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

Системная тема интерфейса

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

Другие изменения в релизе

Улучшения

• Добавили отображение пути к записи в результатах поиска и в разделах Недавние, Избранное и Офлайн
• Изменили шрифт в парольных полях, чтобы исключить неоднозначность при чтении символов
• Добавили автоматическую генерацию названия записи на основе URL
• Добавили возможность создавать пользователей сверх лимита лицензии в статусе «Ожидает подтверждения»
• Добавили фильтр по времени последней активности пользователей в разделе управления пользователями
• Добавили передачу типа сейфа в ArcSight syslog
• Визуальные улучшения и исправления интерфейса

Исправления

• Исправили ошибку, при которой могли не отображаться настройки LDAP до перезагрузки страницы
• Исправили ошибку, при которой могла не отображаться форма регистрации после завершения установки
• Исправили ошибку, при которой не отображались предыдущий и новый уровни доступа в деталях событий сброса доступа к директории
• Исправили ошибку, при которой сбрасывались выбранные чекбоксы при поиске или фильтрации в модальных окнах доступа
• Исправили ошибку, при которой могла быть некорректной сортировка списка сессий по дате последнего использования
• Исправили ошибку, при которой мог некорректно завершаться анализ в панели безопасности
• Исправили ошибку, при которой мог не отображаться информационный баннер для неавторизованных пользователей
• Исправили ошибку, при которой могли дублироваться поля в ArcSight syslog
• Исправили ошибку, при которой в некоторых случаях было невозможно скопировать данные в директорию с доступом «Редактирование»

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

• Добавили механизм запуска внешних приложений на основании правил из внешнего JSON-файла (подробнее в документации)
• Добавили возможность предустановки адреса хоста через CLI-аргументы и параметры инсталлятора
• Исправили ошибку дублирования папки приложения при установке через MSI-инсталлятор на Windows
• Исправили ошибку, при которой полное закрытие приложения на macOS происходило только со второй попытки

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

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

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

Релиз Пассворк 7.7: управляемый офлайн-доступ

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

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

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

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

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

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

Программа-вымогатель (ransomware) — не просто вирус. За последние пять лет они превратились в индустрию с разделением труда, арендой вредоносного ПО и рынком готового доступа в корпоративную инфраструктуру. Технический порог входа в этот «бизнес» обнулился: инструменты арендуются, а доступ покупается.

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

Главное о программах-вымогателях за 30 секунд

Ransomware — это индустрия: аренда вредоносного ПО (RaaS), рынок готового доступа (IAB) и профессиональные переговорщики. Защита строится на нескольких уровнях, а наименее закрытый из них — учётные данные.

1. Технический порог входа исчез — разработчик RaaS берёт 20–30% выкупа, а доступ в корпоративную сеть покупается у брокеров первоначального доступа (IAB) как готовый лот.
2. Число инцидентов с шифровальщиками в России выросло на 15%. Рекордный задокументированный выкуп — 500 млн рублей, типичные требования к малому и среднему бизнесу — от 240 тыс. до 4 млн рублей.
3. 15% атак — диверсионные: данные уничтожаются, ключа дешифровки нет изначально.
4. Основные векторы входа — вредоносный файл, который запускает сам сотрудник (66% инцидентов), и эксплуатация уязвимостей: её доля во втором полугодии 2025 года выросла с 5% до 31%. Чаще всего это N-day, когда патч уже вышел, но не установлен.
5. Три из ключевых векторов работают через компрометацию учётных данных.
6. У защитников есть окно для реакции — между проникновением и запуском шифрования проходит от 3 до 5 суток. При работающем мониторинге атакующего можно остановить.

Что такое программа-вымогатель

Программа-вымогатель (ransomware) — класс вредоносного ПО, который шифрует файлы или блокирует доступ к системе, а затем требует выкуп за восстановление. Первый задокументированный случай — PC Cyborg (также известный как AIDS Trojan) в 1989 году, распространявшийся на дискетах.

Взрывной рост атак начался в 2013 году: CryptoLocker применял RSA-2048 для шифрования и Bitcoin как анонимный канал оплаты. За 100 дней было заражено около 250 000 систем, собрано порядка $3 млн выкупа. Атакующие впервые доказали, что модель масштабируется.

Поворотная точка — WannaCry в мае 2017 года. Атака использовала эксплойт EternalBlue (инструмент АНБ США, утёкший через группу Shadow Brokers) и распространялась автоматически по локальным сетям без каких-либо действий пользователя. За трое суток: 230 000 систем в 150 странах, остановленные конвейеры Renault и Nissan, более 19 000 отменённых медицинских приёмов в больницах NHS Великобритании. Ущерб оценивается в $4–8 млрд.

Месяц спустя — NotPetya. Технически это вайпер под маскировкой шифровальщика: ключа дешифровки не существовало. Заражение распространялось через налоговый клиент M.E.Doc, поразив Maersk (~$300 млн ущерба), Merck (~$870 млн) и FedEx. Совокупный ущерб Белый дом оценил в более чем $10 млрд. NotPetya показал: часть атак создаётся не ради выкупа — ради уничтожения.

В конце 2019 года группировка Maze первой применила двойное вымогательство: данные похищались до шифрования. Если жертва восстанавливалась из резервных копий — её всё равно шантажировали публикацией файлов. Тактика стала отраслевым стандартом.

К 2026 году число атак вышло на новый максимум. Только в августе зафиксировано 1 073 инцидента — рост на 12% к июлю. В тройке наиболее активных группировок: Qilin (164 атрибуции), The Gentlemen (116) и Cl0p (89). Среди задокументированных жертв — Boston Dynamics и Manchester Airport Group (Infosecurity Magazine, август 2026).

Сегодня программа-вымогатель — уже не просто вирус-шифровальщик. Ransomware превратился в отрасль с разделением труда. Модель «вымогательское ПО как услуга» (Ransomware-as-a-Service, RaaS) позволяет арендовать вредоносное ПО без технической подготовки: разработчик берёт 20–30% выкупа, партнёр-атакующий — остальное. Появился отдельный рынок брокеров первоначального доступа (Initial Access Brokers, IAB) — посредников, продающих готовый доступ в корпоративные сети. Переговоры с жертвой ведут профессиональные команды.

Эволюция крупнейших инцидентов

Масштаб угрозы в России в 2025 году

В 2025 году атаки шифровальщиков на российские компании выросли на 15% к предыдущему году — данные F6 («Киберугрозы в России», 2025). Рост умеренный на фоне +44% в 2024-м, но статистика скрывает качественный сдвиг: выкупы стали крупнее, а 15% атак обходятся без ключа дешифровки вовсе.

Статистика атак (F6, 2025)

• +15% — рост числа инцидентов с шифровальщиками за 2025 год.
• 500 млн рублей (50 BTC) — рекордный выкуп, зафиксированный в инциденте CyberSec's.
• 240 тыс. — 4 млн рублей — типичный диапазон требований для МСБ.
• 15% атак — диверсионные: данные зашифрованы без ключа, восстановление невозможно даже после оплаты.

Наиболее уязвимые отрасли

По данным F6, производство, торговля и логистика формируют тройку лидеров:

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

Как работает программа-вымогатель: механика атаки

Этап 1: первоначальный доступ

Атакующий проникает в сеть через один из стандартных векторов:

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

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

Этап 2: закрепление и разведка

Получив точку входа, вредонос закрепляется в системе и начинает перемещаться вглубь сети. Для этого используются легитимные инструменты Windows: PsExec, WMI, PowerShell. Такой подход называют Living off the Land (LOTL, «жить за счёт ресурсов жертвы»): с точки зрения систем мониторинга это выглядит как обычная административная активность, а не атака. Параллельно атакующий выявляет ценные данные и системы резервного копирования — они будут зашифрованы или уничтожены первыми, чтобы лишить жертву возможности восстановиться без выкупа.

Этап 3: шифрование или кража данных

Файлы шифруются быстрым симметричным алгоритмом (AES-256 или ChaCha20). Ключ шифрования, в свою очередь, защищается публичным ключом атакующего (RSA или X25519) — это означает, что расшифровать файлы можно только с помощью закрытого ключа, который хранится исключительно у атакующей стороны. Параллельно или вместо шифрования данные выгружаются в инфраструктуру группировки для двойного вымогательства.

Этап 4: требование выкупа и переговоры

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

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

Отдельная разновидность — wiper-атака (от англ. wipe, «стереть»): вредонос не шифрует данные с целью получить выкуп, а уничтожает их безвозвратно. В 15% подобных инцидентов ключа расшифрования не существует изначально, цель атаки — разрушение инфраструктуры, а не деньги.

Векторы заражения: как ransomware попадает в сеть

По данным F6, ключевые векторы первоначального доступа:

Загрузка вредоносного ПО

Самый распространённый вектор — 66% инцидентов. Отправная точка почти всегда одна: пользователь сам запускает вредоносный файл — поддельное обновление ПО, пиратский инсталлятор, вложение из мессенджера или скрипт с фишингового сайта. Файл выступает дроппером: скачивает и разворачивает основной модуль атаки с командно-контрольного сервера (C2). Типичная цепочка: сотрудник → пиратский Word → Cobalt Strike beacon (инструмент скрытого удалённого управления) → шифровальщик.

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

Во втором полугодии 2025 года доля этого вектора выросла с 5% до 31% — быстрее всех остальных. Причина: массовые незакрытые уязвимости в VPN-шлюзах, продуктах для удалённого доступа и веб-приложениях, доступных из интернета. Группировки применяют два типа: zero-day (патча ещё не существует) и N-day (патч уже выпущен, но не установлен). Второй случай — более распространённый: большинство взломов происходит через уязвимости, для которых обновление было доступно неделями или месяцами.

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

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

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

Три пути: кража паролей стилерами (вредоносное ПО, которое незаметно собирает сохранённые пароли из браузеров и приложений), перебор слабых учётных записей на открытых RDP/VPN, подстановка учётных данных — автоматическая проверка пар логин–пароль из утечек сторонних сервисов на корпоративных ресурсах жертвы. Брутфорс остаётся одним из самых массовых векторов входа в инфраструктуру: слабый пароль — готовая точка входа.

Initial Access Brokers: рынок готового доступа

Брокеры первоначального доступа (IAB) — специализированные посредники, которые взламывают организации и выставляют полученный доступ на продажу в закрытых даркнет-форумах. Группировка-вымогатель покупает готовый лот с параметрами: тип доступа (VPN, RDP, веб-панель), отрасль жертвы, уровень привилегий, страна. Цена лота — от нескольких сотен до десятков тысяч долларов. Фактически это аутсорсинг первого этапа атаки: группировке не нужно самостоятельно взламывать периметр — достаточно выбрать жертву и купить готовый вход.

Виды программ-вымогателей

• Шифровальщик (encrypting ransomware) — классический тип. Вредонос шифрует файлы жертвы: они остаются на диске, но открыть их без ключа невозможно. Операционная система при этом продолжает работать.
• Блокировщик экрана (locker ransomware) — файлы не шифруются, но рабочий стол полностью заблокирован. В корпоративном секторе встречается редко. Основная цель — домашние пользователи.
• Двойное вымогательство (double extortion) — шифрование сочетается с предварительной кражей данных. Если жертва восстановила системы из резервных копий и отказалась платить, данные публикуются на сайте утечек в даркнете (Leak-сайте). Большинство крупных группировок работает именно по этой модели.
• Тройное вымогательство (triple extortion) — расширение предыдущей схемы: к шифрованию и угрозе публикации добавляется DDoS-атака на инфраструктуру жертвы или прямые угрозы её клиентам и деловым партнёрам.
• Вымогательство через угрозу утечки (leakware / doxware) — атакующие похищают данные, после чего предъявляют жертве доказательства кражи и требуют выкуп: заплатишь — данные уничтожим, откажешься — опубликуем. Шифрования нет: системы продолжают работать в штатном режиме, и у жертвы нет очевидного сигнала о произошедшем. Именно в этом ловушка — атаку можно обнаружить только по аномальному трафику, а не по заблокированным файлам. Тренд 2026 года: атаки без шифрования обходят системы защиты конечных точек (EDR — Endpoint Detection and Response), ориентированные на детектирование шифровальщиков (Securelist, 2026).
• Вайперы (wipers, от англ. wipe — «стереть») — маскируются под шифровальщики, но ключа расшифровки не существует в принципе. Цель — уничтожение данных и инфраструктуры. Применяются в диверсионных атаках — те самые 15% по данным F6.
• Программы-вымогатели как услуга (RaaS — Ransomware-as-a-Service) — не технический тип вредоноса, а бизнес-модель. Разработчик создаёт платформу и сдаёт её в аренду партнёрам-операторам, которые проводят атаки и делятся выкупом. Именно поэтому уровень технической подготовки атакующего перестал иметь значение.

Как защититься от программ-вымогателей (ransomware)

Атаку шифровальщика останавливают на нескольких этапах. Каждый уровень сужает пространство для атакующего.

Уровень конечных точек (endpoint)

• Система обнаружения угроз на конечных точках (EDR) с поведенческим анализом обнаруживает атаки с использованием легитимных инструментов системы и пресекает шифрование файлов до завершения атаки.
• Управление обновлениями (patch management). Критические патчи — в течение 72 часов после выхода. Рост доли эксплойтов с 5% до 31% за полгода — прямое следствие незакрытых уязвимостей.
• Ограничение запуска программ. Запрет исполнения файлов из временных папок (%AppData%, %Temp%) и сетевых директорий.

Уровень сети

• Сегментация. Серверы автоматизированных систем управления технологическими процессами (АСУ ТП), системы резервного копирования и платёжная инфраструктура — в отдельных виртуальных сетях с явными правилами трафика.
• Запрет протокола удалённого рабочего стола наружу (RDP — Remote Desktop Protocol). Если удалённый доступ нужен — только через защищённый туннель (VPN) с многофакторной аутентификацией (MFA). Открытый порт 3389 — приглашение к перебору паролей (брутфорсу).
• Мониторинг сетевого трафика (NDR/NTA — Network Detection and Response / Network Traffic Analysis). Аномальные запросы к системе доменных имён (DNS), нетипичный трафик к внешним IP, горизонтальное перемещение по сети через протокол доступа к сетевым папкам (SMB) — видны на уровне сети раньше, чем на рабочих станциях.

Уровень учётных данных и доступа (identity)

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

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

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

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

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

• Правило 3-2-1: три копии данных, на двух разных типах носителей, одна из которых полностью отключена от сети. Физически изолированную копию или копию в неизменяемом хранилище нельзя ни зашифровать, ни удалить извне.
• Изоляция хранилища. Хранилище резервных копий не должно быть доступно с рабочих станций и с сервера управления корпоративной сетью (контроллера домена): атакующий, захвативший контроллер домена, автоматически получает доступ ко всему, что к нему подключено.
• Регулярный тест восстановления. Нетестированная резервная копия — это не защита. Только реальная проверка восстановления данных подтверждает, что копия рабочая.

Осведомлённость сотрудников

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

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

Threat Intelligence и мониторинг

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

Среднее время от момента проникновения до активации шифровальщика — от 3 до 5 суток. Это и есть окно для реагирования: при работающем мониторинге команда безопасности может обнаружить атакующего и остановить его до того, как он нажмёт «зашифровать». Без мониторинга это окно проходит незаметно.

Что делать, если атака уже произошла: чеклист реагирования

Первые действия при обнаружении активного шифровальщика:

• Изолировать поражённые системы от сети — физически или через VLAN-запрет. Не ждать завершения анализа.
• Не перезагружать хосты — перезагрузка уничтожает криминалистические данные в оперативной памяти: активные процессы, сетевые соединения, фрагменты ключей шифрования.
• Уведомить команду реагирования и руководство — у инцидента должен быть ответственный немедленно.
• Задокументировать индикаторы компрометации (IOC) — хеши файлов, имена процессов, IP-адреса C2, следы LOTL-инструментов.
• Оценить охват и определить семейство вредоноса — какие хосты затронуты, к какой группировке и семейству программ-вымогателей относится атака: от этого зависит, есть ли публичный дешифратор (см. nomoreransom.org).
• Восстановление из изолированных бэкапов — только после полного удаления вредоноса с поражённых хостов, иначе повторное шифрование.
• Разбор инцидента (post-incident review) — определить вектор доступа, найти корневую причину, закрыть в течение 30 дней.
• Уведомить регулятора — для субъектов КИИ уведомление ФСБ и НКЦКИ обязательно по статье 9 Федерального закона № 187-ФЗ «О безопасности критической информационной инфраструктуры»; для операторов персональных данных — ФСТЭК и Роскомнадзор по требованиям 152-ФЗ.

Вывод

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

Защита строится на архитектуре — предотвратить первоначальный доступ, ограничить распространение, обеспечить восстановление. Ни один уровень не работает в одиночку. Бэкап без сетевой изоляции зашифруют первым. EDR без патч-менеджмента не закроет уязвимость VPN-шлюза. Управление доступом без MFA оставит открытым брутфорс RDP.

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

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

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

Что такое программа-вымогатель простыми словами?

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

Как ransomware попадает на компьютер?

Основной вектор в России — загрузка вредоносного ПО (66% инцидентов): поддельные обновления, пиратское ПО, вложения в письмах. К концу 2025 года доля эксплойтов уязвимостей выросла с 5% до 31% (F6, 2025). Брутфорс RDP и кража паролей — ещё два распространённых пути первоначального доступа.

Поможет ли антивирус защититься от шифровальщика?

Антивирус на основе сигнатур защищает от известных семейств шифровальщиков. Современные шифровальщики используют LOTL-тактику — легитимные инструменты Windows, которые сигнатурный антивирус не блокирует. Необходим EDR с поведенческим анализом, дополненный сегментацией сети и изолированными бэкапами.

Что такое двойное вымогательство?

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

Как быстро происходит шифрование после заражения?

Среднее время от первоначального доступа до активации шифровальщика — от 3 до 5 суток. Это окно для обнаружения и реагирования. SIEM с правилами корреляции по аномалиям LOTL позволяет зафиксировать атаку до шифрования.

Что такое RaaS?

Ransomware-as-a-Service (RaaS) — модель, при которой разработчик предоставляет вредоносное ПО и инфраструктуру аффилиатам-партнёрам. Партнёр проводит атаку, разработчик получает 20–30% выкупа. Это позволяет атаковать людям без технической подготовки и масштабирует число операций.

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

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

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

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

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

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

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

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

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

Российские компании Пассворк и МУЛЬТИФАКТОР протестировали и подтвердили совместимость менеджера паролей Пассворк и системы двухфакторной аутентификации и контроля доступа MULTIFACTOR.

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

Что это даёт заказчику

Компании, в которых сотрудники пользуются несколькими корпоративными сервисами, обычно накапливают разные механизмы входа. Эту проблему помогает решить MULTIFACTOR с SSO. Single Sign-On (SSO) — технология, которая позволяет пользователю пройти аутентификацию один раз и получить доступ ко всем подключённым сервисам.

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

О Пассворке

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

О MULTIFACTOR

MULTIFACTOR — система двухфакторной аутентификации и контроля доступа для всех видов удалённых подключений: RDP, VPN, VDI, SSH и других. Это инструмент для надёжной 2FA-аутентификации пользователей при доступе к любым корпоративным ресурсам с поддержкой технологии единого входа (SSO). Решение включено в реестр российского ПО под № 7046, имеет сертификат ФСТЭК № 5039.

Комментарии сторон

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

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

О компании Пассворк

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

О компании МУЛЬТИФАКТОР

МУЛЬТИФАКТОР — российский разработчик ИБ- и ИТ-решений. Создаёт продукты для безопасной и стабильной работы ИТ-инфраструктуры бизнеса. Компания является лицензиатом ФСТЭК и соответствует требованиям международного стандарта PCI DSS.

Продукты компании:

• MULTIFACTOR — комплексная система двухфакторной аутентификации и контроля доступа (включена в реестр российского ПО под № 7046, сертифицирована ФСТЭК России)
• MULTIDIRECTORY — служба каталогов (включена в реестр российского ПО под № 28333)
• MULTIPUSHED — инструмент для отправки пуш-сообщений на любые устройства и ОС
• MULTISTATUS — геораспределённый облачный сервис для веб-мониторинга и контроля сетевого периметра

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

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

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

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

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

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

Пассворк совместим c JaCarta Management System 4LX

Компании Пассворк и Аладдин подтвердили совместимость своих продуктов: менеджера паролей Пассворк и корпоративной системы централизованного управления JaCarta Management System 4LX для Linux (JMS4LX).

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

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

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

Главное о выборе российского менеджера паролей за 30 секунд

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

1. Юридической обязанности нет, деловой риск есть — компаниям вне госсектора переход на российское решение не обязателен по закону, но зависимость от зарубежного продукта способна обернуться блокировкой доступа или остановкой обновлений без переходного периода.
2. Технические критерии обязательны в любом случае — RBAC, SSO, синхронизация с LDAP/AD, журнал аудита с выгрузкой в SIEM и клиентское шифрование нужны независимо от происхождения продукта.
3. Есть сигналы неготового решения — «российское» только в маркетинге без номера в реестре и сертификата, один общий ключ шифрования на всю компанию, плоская модель доступа «админ/пользователь», отсутствие журнала аудита или варианта развёртывания на своём сервере.
4. Перед покупкой стоит пройти чек-лист из 12 вопросов по пяти темам: реестр, шифрование, развёртывание, доступ, юрисдикция вендора. Ответы нужно сверять напрямую с реестром Минцифры и сертификатом ФСТЭК.
5. Пассворк закрывает оба слоя проверки — сертификат ФСТЭК № 5063, запись в реестре российского ПО № 6147, развёртывание на своём сервере или в облаке, интеграцию с LDAP/AD и SSO, браузерные расширения, мобильные и десктопные приложения, управление паролями и техническими секретами через REST API, CLI и Python SDK.

Почему бизнесу, а не только госсектору, стоит выбирать российское решение

Указ Президента РФ № 250 обязывает конкретный список организаций использовать сертифицированные и локализованные средства защиты информации: субъекты критической информационной инфраструктуры (КИИ), органы власти, государственные корпорации и системообразующие предприятия. Компании вне этого списка ничего не нарушают, оставаясь на зарубежном решении. Но у выбора инструмента для паролей есть деловая сторона, не связанная с юридической обязанностью.

• Первый аргумент — цена ошибки в парольной гигиене от статуса компании не зависит. По данным Информзащиты за 2026 год, украденные учётные данные используются как минимум на одном этапе более чем в 80% кибератак, а атаки, построенные на компрометации личности (краже, подборе или повторном использовании паролей, социальной инженерии), обеспечивают 65% первичных проникновений в инфраструктуру.
• Второй аргумент — требование о локализации персональных данных касается почти любой компании. Статья 18 часть 5 Федерального закона № 152-ФЗ «О персональных данных» обязывает хранить базы с персональными данными граждан РФ на серверах в России. Если в сейфах менеджера паролей хранятся логины, привязанные к конкретным сотрудникам или клиентам, эти записи подпадают под определение персональных данных.
• Третий аргумент — зависимость от зарубежного вендора. Такой сервис работает по правилам чужой юрисдикции: вендор может заблокировать учётную запись компании по собственному решению, а санкции — ограничить доступ независимо от его воли. Лицензия может прекратиться, а обновления и техподдержка остановиться без переходного периода. Для системы, которая хранит доступы ко всей инфраструктуре компании, это операционный риск того же порядка, что и утечка.
• Четвёртый аргумент — зависимость от иностранных законодательств. Американский CLOUD Act разрешает властям США требовать у любой компании под юрисдикцией США данные с серверов в любой точке мира. Закон FISA Section 702 даёт спецслужбам США основания для доступа к данным иностранных пользователей через американских провайдеров. В Евросоюзе NIS2 ужесточила требования к отчётности, а GDPR регулирует передачу данных за пределы ЕС. Российская компания на зарубежном сервисе зависит от требований этих норм, даже не находясь в их юрисдикции напрямую.
• Пятый аргумент — вклад в развитие российского рынка средств защиты информации. Деньги, которые компания платит российскому вендору, идут на доработку конкретного инструмента, которым пользуется компания. Чем больше клиентов у российских вендоров средств защиты информации, тем быстрее эти продукты закрывают функциональные разрывы с зарубежными аналогами, и тем меньше поводов у отрасли зависеть от решений, которые в любой момент могут перестать работать в России.

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

Что на самом деле делает менеджер паролей «российским»

Русскоязычный интерфейс и офис в Москве ничего не говорят о статусе продукта перед законом и перед регулятором. Чек-лист из 4 признаков российского менеджера паролей закрывает вопрос без догадок:

1. Запись в реестре российского ПО
2. Сертификация и лицензия
3. Локализация данных
4. Независимость от иностранной юрисдикции

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

Запись в реестре отечественного ПО

Единый реестр российского ПО ведёт Минцифры России на reestr.digital.gov.ru. Запись в реестре подтверждает происхождение кода и прав на него и даёт право на участие в закупках по 44-ФЗ и 223-ФЗ, где предусмотрены приоритеты для отечественного софта. Продукт, который позиционирует себя как российский, но не имеет записи в реестре, либо не прошёл эту проверку, либо не проходил её вовсе.

Сертификация ФСТЭК или лицензия ФСБ

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

Локализация и резидентность данных

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

Юрисдикция вендора и поддержки

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

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

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

Безопасность и архитектура хранения

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

Контроль, аудит и соответствие требованиям

Удобство использования и кроссплатформенность

Чек-лист вопросов вендору перед покупкой

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

Реестр и сертификация

• Под каким номером продукт числится в реестре российского ПО и как проверить эту запись самостоятельно на reestr.digital.gov.ru?
• Есть ли действующий сертификат ФСТЭК на продукт как средство защиты информации и для какого класса защищённости он выдан?

Шифрование и архитектура

• Кто владеет лицензией ФСБ на криптографию: сам вендор или сторонний подрядчик, чьё участие в проекте может прекратиться без предупреждения?
• Работает ли шифрование по модели zero-knowledge и может ли администратор сервера технически прочитать пароль пользователя?
• У каждого сейфа собственный независимый ключ шифрования, или вся организация зашифрована одним общим ключом? Разница решает, как далеко дойдёт скомпрометированная учётная запись.

Развёртывание и совместимость

• Где физически размещаются данные при облачном варианте, и есть ли коробочная установка на сервере заказчика для изолированного контура?
• С какими российскими ОС, СУБД и службами каталогов продукт совместим официально?
• Что происходит с доступом сотрудника при его увольнении: блокировка происходит автоматически через синхронизацию с LDAP или требует ручного действия администратора?

Доступ и аудит

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

Поддержка и юрисдикция

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

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

Когда менеджер паролей не готов для вашего бизнеса

Несколько сигналов говорят, что решение не готово к использованию в компании:

• «Российское» только в маркетинге. Название на кириллице, домен .ru и фраза «отечественная разработка» на сайте вендора не заменяют запись в реестре и сертификат. Если вендор не может назвать номер записи в реестре Минцифры или ссылается на «сертификацию в процессе оформления» — перед вами обещание, а не готовое решение.
• Юридический риск блокировки не проговорён. Вендор уходит от вопроса про юрисдикцию разработчика и структуру владения компанией. При смене санкционного режима заказчик узнает ответ на собственном опыте — в момент, когда изменить что-то уже нельзя.
• Нулевое знание (zero knowledge) заявлено, но не объяснено технически. На вопрос «где генерируются ключи шифрования» вендор отвечает общей фразой из презентации, а не архитектурной схемой с указанием, на каком устройстве создаётся ключ и куда он передаётся.
• Один ключ шифрования на всю организацию. Если компрометация одной учётной записи открывает доступ не к одному сейфу, а к зашифрованным данным всей компании — архитектура изначально не ограничивает ущерб от кражи пароля.
• Нет разграничения прав ниже уровня «администратор / пользователь». Для команды больше 15–20 человек плоская модель доступа снимает саму пользу от менеджера паролей: рано или поздно кто-то получит доступ к сейфу, который ему не нужен для работы.
• Нет журнала аудита или выгрузки в SIEM. Без истории действий расследование инцидента с учётной записью превращается в опрос сотрудников по памяти — без единого проверяемого факта, кто и когда открывал запись.
• Нет варианта размещения на своём сервере. Если вендор предлагает только облако без возможности развернуть систему в изолированном контуре, компания зависит от чужой инфраструктуры.
• Нет синхронизации с LDAP или Active Directory. Увольнение сотрудника требует, чтобы администратор вручную отозвал доступ в каждом сейфе. На практике это поле забывают, и доступ остаётся активным месяцами.

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

Строгость критериев из предыдущих разделов стоит адаптировать под контекст компании: не всем нужен один и тот же уровень проверки.

Малый и средний бизнес

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

Крупный бизнес

От нескольких сотен пользователей критичны SSO, синхронизация с LDAP/Active Directory, детальная ролевая модель по подразделениям и экспорт журнала аудита в SIEM. Здесь имеет смысл пройти весь чек-лист вопросов вендору целиком и запросить документы напрямую: сертификат и выписку из реестра. Для компании с несколькими юридическими лицами или распределённой географией добавляется ещё один вопрос: поддерживает ли решение разграничение сейфов и прав между филиалами без потери централизованного аудита.

Регулируемая, но не критическая инфраструктура

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

Пассворк: как российский менеджер паролей закрывает эти критерии

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

Совместимость с российской инфраструктурой

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

Совместимость подтверждена с Astra Linux, РЕД ОС, Альт Сервер, SelectOS, МСВСфера, службой каталогов MultiDirectory, СУБД Pangolin DB и другими решениями на странице сертификатов. Список обновляется — сверяйте его перед принятием решения, а не по памяти из статьи.

Шифрование: два независимых слоя

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

Размещение — на выбор заказчика

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

Доступ и аудит

Синхронизация с LDAP и Active Directory снимает ручное отключение доступа при увольнении сотрудника. SSO работает через SAML 2.0. Журнал аудита фиксирует действия пользователей и поддерживает выгрузку в SIEM-системы для расследования инцидентов. Панель безопасности помогает выявить риски компрометации.

Гранулярная ролевая модель: роли и группы

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

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

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

Удобство работы

Для повседневной работы есть браузерные расширения (Chrome, Firefox, Edge, Яндекс Браузер) с автозаполнением и мобильные приложения для двухфакторной аутентификации в Play Market, App Store и RuStore. Также есть нативное десктопное приложение на Windows, macOS и Linux с поддержкой биометрии и ключей доступа.

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

Пассворк закрывает две задачи одним решением: сотрудники работают с паролями через привычный интерфейс, а разработчики и DevOps-инженеры управляют техническими секретами (API-ключами, токенами облачных провайдеров, сертификатами, строками подключения к БД, SSH-ключами) через REST API, CLI-утилиту и Python SDK.

Простота масштабирования

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

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

Для бизнеса без обязательной аттестации достаточно четырёх шагов:

1. Аудит текущего состояния. Соберите список мест, где сейчас лежат пароли (Excel, заметки, чаты, память сотрудников), и кто имеет к ним доступ. Без этого шага миграция превращается в перенос хаоса в новый инструмент.
2. Пилот на одной команде. Разверните решение для отдела с наибольшей плотностью критичных доступов, обычно ИТ или DevOps, и проверьте на практике SSO, синхронизацию с LDAP и удобство ежедневной работы, прежде чем тиражировать на компанию.
3. Миграция и раскатка. Перенесите пароли остальных отделов, настройте ролевую модель и группы под оргструктуру, обучите сотрудников базовым сценариям: создание записи, шеринг доступа, отзыв прав при увольнении.
4. Аудит после внедрения. Через один-два месяца проверьте, действительно ли пароли переехали из Excel и чатов в менеджер, а не продолжают жить параллельно.

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

Заключение

«Российское» применительно к менеджеру паролей — это четыре проверяемых признака: запись в реестре, сертификация и лицензии, локализация данных, независимость от иностранной юрисдикции. Язык интерфейса и название компании на кириллице к статусу отношения не имеют. Выбирать решение стоит по этому чек-листу вместе с обычными техническими критериями: RBAC, SSO, LDAP, аудитом, стандартами шифрования.

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

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

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

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

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

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

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

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

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

Проверьте номер записи, который называет вендор, напрямую в едином реестре российского ПО на reestr.digital.gov.ru, по названию компании или продукта. Запись в реестре и сертификация ФСТЭК — разные документы, и оба нужно проверять отдельно.

Чем плох Excel или KeePass для хранения рабочих паролей в компании?

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

Зачем нужен менеджер паролей для бизнеса, если есть KeePass?

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

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

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

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

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

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

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

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

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

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

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

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

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

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

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

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

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

Шаг 1. Инвентаризация учётных записей

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

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

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

С привилегированными и сервисными учётными записями сложнее: часто данных просто нет, потому что их не заводили по единому процессу. По данным BI.ZONE, почти 40% таких записей используют одинаковые или похожие пароли, а больше половины никогда не истекают. На одного ИТ-специалиста в среднем приходится 3–7 привилегированных учётных записей, и часто он сам не может назвать их точное число без выгрузки.

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

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

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

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

Шаг 2. Проверка качества и уникальности паролей

На этом шаге парольного аудита проверяется, соответствуют ли реальные пароли принятому стандарту длины, сложности и уникальности.

Оцените среднюю и минимальную длину паролей

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

Не считайте спецсимволы признаком надёжности

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

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

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

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

Сопоставьте пароли между учётными записями

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

Если дефолтные и повторяющиеся пароли — не единичные случаи, а массовое явление

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

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

Шаг 3. Аудит парольной политики и настроек блокировки

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

Проверьте минимальную длину и требования к алфавиту пароля

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

Проверьте глубину истории паролей

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

Проверьте порог блокировки учётной записи и время автоматической разблокировки

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

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

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

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

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

Шаг 4. Проверка многофакторной аутентификации

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

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

Чек-лист проверки MFA:

• Включена ли MFA для всех привилегированных учётных записей без исключений
• Есть ли обходные пути входа без второго фактора: старые интеграции, сервисные API, устаревшие протоколы
• Какой метод MFA используется: SMS-код, приложение-аутентификатор или аппаратный ключ
• Покрывает ли MFA доступ к самим системам управления паролями и секретами, а не только к рабочей почте

Оцените метод MFA на устойчивость к фишингу

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

Проверьте, защищена ли MFA сама система управления паролями и секретами

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

Сверьте, как MFA сочетается с единым входом (SSO)

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

Шаг 5. Проверка журнала аудита и подозрительной активности

Журнал аудита фиксирует, кто и когда входил в систему. Без его регулярного просмотра администратор узнаёт о компрометации только после инцидента, а не до него.

На что смотреть в первую очередь:

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

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

Команда зрелого уровня не проверяет журналы вручную каждый раз, а настраивает экспорт логов в SIEM или Syslog и получает уведомления по заданным правилам.

Шаг 6. Приоритизация находок и отчёт

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

Шкала критичности находок (3 уровня)

Разнесите каждую находку по трём уровням. От этого зависит срок реагирования, а не от того, на каком шаге чек-листа она обнаружена:

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

Минимальная структура отчёта

Готовый отчёт отвечает на пять вопросов, и каждый прямо опирается на данные, собранные на шагах 1–5:

1. Дата и охват аудита. Какие системы и учётные записи проверены — тот же периметр, что вы зафиксировали на шаге 1.
2. Сводка по категориям. Сколько обычных, привилегированных и сервисных учётных записей проверено и сколько находок пришлось на каждую категорию — разбивка наследует категории из шага 1.
3. Находки по уровню приоритета. Таблица выше, но с конкретными системами и учётными записями, а не абстрактными формулировками вида «пароли недостаточно сложные».
4. Рекомендации и сроки. Что сделать, до какой даты и кто отвечает — для «Критично» и «Важно» это конкретный исполнитель, не абстрактный «ИБ-отдел».
5. Дата следующего аудита. Плановая дата для обычных учётных записей и отдельная, более частая — для привилегированных и сервисных, в соответствии с циклами из раздела «Зачем и когда проводить аудит».

Как Пассворк закрывает находки аудита

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

Привилегированные и сервисные учётные записи

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

Качество и уникальность паролей

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

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

Пассворк поддерживает TOTP, ключи доступа (passkeys/WebAuthn) и приложение «Пассворк 2ФА». Администратор может настроить обязательную MFA для конкретных ролей — в первую очередь для тех, у кого доступ к привилегированным сейфам.

Права доступа и их пересмотр

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

Журнал использования прав

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

Что делать с найденными «мёртвыми аккаунтами» — учётными записями без владельца?

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

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

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

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

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

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

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

Управление паролями в компании: система, угрозы, внедрение

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

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

В 2025 году ФСТЭК проверила более 700 значимых объектов КИИ и выявила свыше 1 200 нарушений в части обеспечения информационной безопасности. Направлено более 2 000 требований об устранении недочётов и составлено 603 протокола об административных правонарушениях.

Показательна и другая цифра: по данным, озвученным начальником управления ФСТЭК Еленой Торбенко на «Инфофоруме 2026», лишь 35% проверенных объектов КИИ соответствуют минимальному базовому уровню безопасности. Там же она сообщила, что в этом году ФСТЭК увеличит количество проверок.

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

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

В то же время регулирование стало сложнее. 58-ФЗ, типовые отраслевые объекты, обновлённые формы категорирования, проект постановления Минцифры со сроками 2028–2036 годов — всё это появилось за последние два года. Требования различаются в зависимости от статуса организации, категории объекта и вида актива: ПО, СЗИ (средства защиты информации) или ПАК (программно-аппаратный комплекс). Часть запретов уже действует с 2025 года.

Главное

• Часть запретов уже действует. С 01.01.2025 иностранные СЗИ запрещены на всех ЗОКИИ, иностранное ПО — на ЗОКИИ госорганов и госкомпаний. Это действующие нормы.
• Проектируемый базовый дедлайн — 01.01.2028. К этой дате доля российского ПО на всех ЗОКИИ должна составить 100%. Срок содержится в проекте постановления, находящемся в Правительстве, и пока не утверждён окончательно.
• Специальные сроки 2031 и 2036 годов — не массовая отсрочка. Они обсуждаются только для участников особо значимых проектов и отдельных категорий ЗОКИИ. Рассчитывать на них без документальных оснований не следует.
• Штрафы за нарушение сроков готовятся. В июне 2026 года Минцифры подтвердило намерение сформировать нормативную базу для серьёзных финансовых санкций. Действующей нормой они пока не являются, но при планировании этот риск уже нужно учитывать.
• Регулирование усложнилось. 58-ФЗ, типовые отраслевые объекты, обновлённые формы категорирования — всё это появилось за последние два года. Требования различаются в зависимости от статуса организации, категории объекта и вида актива: ПО, СЗИ или ПАК.
• 2026 год — время подготовки, а не ожидания. Лишь 35% проверенных объектов КИИ соответствуют базовому уровню безопасности. ФСТЭК увеличивает число проверок. Компании, которые начнут аудит и ревизию категорирования сейчас, к дедлайну подойдут с готовым планом.

Что изменилось в импортозамещении КИИ к 2026 году

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

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

С 1 сентября 2025 вступил в силу 58-ФЗ и изменил архитектуру регулирования. Он существенно расширил полномочия Правительства РФ и создал нормативную основу для системного перехода на российское ПО и программно-аппаратные комплексы (ПАК) на значимых объектах КИИ. Правительство получило право устанавливать:

• перечни типовых отраслевых объектов КИИ;
• отраслевые особенности категорирования;
• порядок и сроки перехода на российское ПО и ПАК;
• требования к ПАК для ЗОКИИ;
• порядок мониторинга исполнения этих обязанностей.

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

В мае 2026 года Минцифры представило проект постановления о сроках перехода ЗОКИИ на российское ПО с диапазоном 2028–2036 годов. По состоянию на сентябрь 2026 года проект находится в Правительстве и не утверждён окончательно.

2026 год — не период ожидания дедлайна 2028 года. Уже сейчас нужно уточнить состав объектов КИИ, провести аудит иностранного ПО и СЗИ, проверить наличие российских аналогов и подготовить согласованные дорожные карты перехода.

Кого касаются требования: субъект КИИ, объект КИИ, ЗОКИИ и типовые отраслевые объекты

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

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

Отдельный инструмент — типовые отраслевые объекты КИИ: перечни типов ИС, ИТКС и АСУ, утверждаемые Правительством РФ по отраслям. Они служат ориентиром для выявления объектов, подлежащих категорированию, — первый такой перечень утверждён распоряжением № 360-р от 26.02.2026.

Отрасли, на которые распространяется 187-ФЗ

Согласно Федеральному закону от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», к субъектам КИИ относятся организации в сферах:

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

Три категории значимости

Три категории значимости (первая, вторая и третья) определяют объём требований к системе обеспечения информационной безопасности (СОИБ). Первая категория соответствует наиболее критичным объектам и предполагает максимально жёсткие требования; третья — минимальные. Если объект КИИ не соответствует ни одному из критериев значимости, категория ему не присваивается.

Категорию объекту присваивают сами субъекты КИИ на основании оценки по пяти критериям, закреплённым в ст. 7 № 187-ФЗ:

Результаты категорирования субъект КИИ направляет в ФСТЭК России в течение 10 дней после принятия решения. Регулятор в течение 30 дней проверяет правильность присвоения категории.

Сроки перехода на российское ПО, СЗИ и ПАК

Проектируемый базовый срок перехода значимых объектов КИИ на российское ПО — 1 января 2028 года. По состоянию на сентябрь 2026 года этот срок содержится в проекте постановления, находящемся в Правительстве, и должен применяться после утверждения соответствующего акта. К этой дате доля российского программного обеспечения на ЗОКИИ должна составлять 100%.

Для отдельных сценариев в публикациях о проекте фигурируют специальные сроки — 1 января 2031 года и 1 января 2036 года. Обсуждаются следующие сценарии: участие в особо значимых проектах (ОЗП) с началом замещения до 01.09.2026, отсутствие российских аналогов, заключение контрактов ОЗП в 2026–2028 годах, а также отдельные условия для объектов КИИ второй и третьей категорий. До утверждения постановления эти условия следует считать проектируемыми и проверять по финальной редакции акта.

Матрица сроков: от 2022 до 2036 года (актуально на сентябрь 2026)

Ответственность за нарушение сроков: что известно на сетябрь 2026 года

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

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

Сроки по видам активов

Нормативная база: какие документы учитывать

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

Карта нормативных актов

• 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» — базовый закон. Вводит понятия субъекта КИИ, объекта КИИ, значимого объекта КИИ, устанавливает требования к безопасности и взаимодействию с ГосСОПКА (государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации).
• 58-ФЗ от 07.04.2025 — поправки к 187-ФЗ, вступившие в силу 01.09.2025. Расширяют полномочия Правительства: устанавливать типовые отраслевые объекты, отраслевые особенности категорирования, порядок и сроки перехода на российское ПО и ПАК, требования к ПАК, порядок мониторинга. Исключают ИП из числа субъектов КИИ. Обязывают субъектов КИИ использовать на ЗОКИИ ПО из реестра российского ПО Минцифры.
• Указ Президента РФ № 166 от 30.03.2022 (в ред. от 07.04.2025) — ограничивает закупки иностранного ПО для ЗОКИИ без согласования. С 01.01.2025 устанавливает запрет использования иностранного ПО на ЗОКИИ, принадлежащих госорганам и государственным организациям.
• Указ Президента РФ № 250 — обязывает всех владельцев ЗОКИИ перейти на российские СЗИ. С 01.01.2025 использование иностранных СЗИ на ЗОКИИ запрещено.
• Постановление Правительства РФ № 402 от 13.04.2026 — утверждает отраслевые особенности категорирования объектов КИИ в сфере связи. Вступило в силу 01.09.2026. Один из шести отраслевых актов 2026 года, реализующих полномочия Правительства по 58-ФЗ.
• Постановление Правительства РФ № 796 от 27.06.2026 — утверждает отраслевые особенности категорирования объектов КИИ в оборонной промышленности.
• Приказ ФСТЭК России № 117 — с 01.03.2026 обновляет требования защиты информации для государственных информационных систем (ГИС) и иных систем государственных органов, ГУПов и учреждений. Актуален для организаций, у которых объекты КИИ одновременно являются ГИС.
• Приказ ФСТЭК России № 247 от 11.07.2025 — обновляет форму направления сведений о результатах категорирования объектов КИИ. С 01.09.2025 форма дополнена полем о наименовании типового отраслевого объекта КИИ, доменным именем и внешним сетевым адресом.
• Постановление Правительства РФ № 127 — устанавливает показатели критериев значимости объектов КИИ и порядок категорирования.
• Постановление Правительства РФ № 1478 — определяет требования к системам безопасности значимых объектов КИИ.
• Распоряжение Правительства РФ № 360-р от 26.02.2026 — утверждает перечень типовых отраслевых объектов КИИ. Триггер для ревизии состава объектов у субъектов КИИ.

Как категорирование связано с импортозамещением

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

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

Распоряжение Правительства № 360-р от 26.02.2026 утвердило первый такой перечень. Для субъектов КИИ это означает необходимость сверить собственный реестр объектов с типовым перечнем: не исключено, что часть систем, ранее не признававшихся объектами КИИ, теперь попадает в периметр регулирования.

Почему актуализация категорирования критична в 2026 году

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

Реестр ЗОКИИ также получил новый формат регистрационного номера: XXXXXX/Х/XX/Х, где зашифрованы порядковый номер, федеральный округ, сфера деятельности и тип объекта (ИС, АСУ или ИТКС). Сведения из реестра ежемесячно передаются государственным органам, уполномоченным на реализацию государственной политики в соответствующей сфере.

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

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

Аналогичные постановления для оставшихся отраслей (энергетика, транспорт, здравоохранение) ожидаются в 2026–2027 годах по мере реализации полномочий Правительства по 58-ФЗ. Субъектам КИИ из этих отраслей стоит отслеживать появление отраслевых актов и закладывать время на ревизию категорирования.

Что именно нужно заменить: ПО, СЗИ, ПАК и управление доступом

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

Три класса активов и логика их замены

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

Реестр российского ПО: как проверять

Единый реестр российского ПО ведёт Минцифры России. При проверке продукта важно убедиться:

• что продукт включён в реестр и запись актуальна;
• что класс ПО в реестре соответствует функции, для которой оно применяется на ЗОКИИ;
• что для СЗИ дополнительно получен действующий сертификат ФСТЭК или ФСБ;
• что продукт функционально совместим с существующей инфраструктурой объекта.

План действий на 2026 год

В 2026 году компании должны провести ревизию объектов, уточнить категорирование, определить состав иностранного ПО/СЗИ/ПАК, проверить наличие российских аналогов и подготовить согласованный план перехода. Это минимальный набор действий, без которого старт миграции в 2027 году окажется неуправляемым. Ниже — Дорожная карта импортозамещения КИИ:

Этап 1

1. Ревизия объектов КИИ. Сверьте реестр объектов организации с распоряжением Правительства № 360-р (перечень типовых отраслевых объектов КИИ). Проверьте, не появились ли системы, которые теперь подпадают под определение типового отраслевого объекта КИИ, но ранее не были включены в реестр.
2. Актуализация сведений о категорировании. Обновите форму направления сведений во ФСТЭК с учётом Приказа № 247: добавьте наименование типового отраслевого объекта, доменные имена и внешние сетевые адреса. Если категорирование проводилось до 01.09.2025 — проверьте, нужен ли пересмотр категорирования и актуализация сведений во ФСТЭК.
3. Инвентаризация иностранного ПО, СЗИ и ПАК. Составьте полный реестр иностранного программного обеспечения, средств защиты и программно-аппаратных комплексов на каждом ЗОКИИ. Зафиксируйте: вендор, версия, функция, наличие или отсутствие поддержки, наличие российского аналога.
4. Назначение ответственных. Определите должностное лицо, ответственное за организацию перехода. Для федеральных органов власти и госкорпораций это требование закреплено в предложениях Минцифры: ответственный — не ниже заместителя руководителя.

Этап 2

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

Этап 3

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

Импортозамещение КИИ — это управляемый проект

Переход на российское ПО, СЗИ и ПАК на значимых объектах КИИ — многоэтапная программа, которая требует корректного определения объектов, инвентаризации активов, проверки аналогов и поэтапной миграции с контролем доступа и документированным планом отката.

Компании, которые начнут с ревизии категорирования и аудита иностранного ПО в 2026 году, к дедлайну 2028 года подойдут с готовым планом.

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

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

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

Кого касается импортозамещение КИИ в 2026 году?

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

До какого срока нужно перейти на российское ПО на значимых объектах КИИ?

Базовый срок — 1 января 2028 года: к этой дате доля российского ПО на ЗОКИИ должна составлять 100%. Для отдельных сценариев Минцифры предложило сроки 1 января 2031 года и 1 января 2036 года. По состоянию на сентябрь 2026 года эти сроки содержатся в проекте постановления Правительства и не являются окончательно утверждёнными нормами. Рассчитывать на них без документально подтверждённых оснований не следует.

Чем отличается субъект КИИ от значимого объекта КИИ?

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

Что такое типовые отраслевые объекты КИИ и зачем они нужны?

Типовые отраслевые объекты КИИ — перечни типов ИС, ИТКС и АСУ по отраслям, утверждаемые Правительством РФ на основании 58-ФЗ. Они служат ориентиром для выявления объектов, подлежащих категорированию, и унифицируют подход к субъектам одной отрасли. Первый перечень утверждён распоряжением № 360-р от 26.02.2026. Субъектам КИИ необходимо сверить свой реестр объектов с этим перечнем.

Достаточно ли включения продукта в реестр российского ПО для использования на ЗОКИИ?

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

Чем доверенный ПАК отличается от российского ПО?

Российское ПО — программный продукт, соответствующий критериям отечественного происхождения и включённый в реестр Минцифры. Доверенный ПАК — связка программного и аппаратного компонентов, отвечающая отдельным требованиям доверенности, которые устанавливает Правительство РФ по 58-ФЗ. Сроки и порядок перехода на ПО и ПАК различаются: проектируемый базовый ориентир для ПАК — 01.01.2030, для ПО — 01.01.2028. Оба срока содержатся в проектируемых актах и подлежат уточнению после их утверждения.

Что нужно сделать субъекту КИИ в 2026 году?

Провести ревизию реестра объектов с учётом типовых отраслевых перечней, актуализировать сведения о категорировании во ФСТЭК, составить реестр иностранного ПО/СЗИ/ПАК, проверить российские аналоги и их совместимость, запустить пилоты, подготовить дорожную карту, назначить ответственного и описать права доступа подрядчиков.

Как связаны импортозамещение и управление доступом?

Импортозамещение меняет состав ПО и СЗИ, но не устраняет угрозы, связанные со слабыми паролями, общими учётными записями и неуправляемым привилегированным доступом. По данным проверок ФСТЭК (2025), при проверке более 700 ЗОКИИ выявлено свыше 1 200 нарушений в части информационной безопасности. Контроль идентификации, аутентификации и прав доступа должен быть частью проекта миграции, а не отдельной задачей.

Можно ли отложить импортозамещение КИИ?

В публикациях о проекте обсуждаются специальные сроки для нескольких сценариев: участие в особо значимых проектах с началом замещения до 01.09.2026, отсутствие российских аналогов, заключение контрактов ОЗП в 2026–2028 годах, а также отдельные условия для объектов КИИ второй и третьей категорий. Окончательный перечень условий зависит от утверждённой редакции постановления. Ни один из этих сценариев не действует автоматически.

Какие ошибки чаще всего допускают при импортозамещении КИИ?

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

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

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

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

Кейс-стади: ВкусВилл и Пассворк

ИТ-команда ВкусВилла искала инструмент для централизованного хранения секретов с LDAP-интеграцией и надёжным резервированием. Рассказываем, как выбирали, внедряли и как это устроено сейчас.

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

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

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

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