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

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

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

Главное о менеджере паролей для госсектора за 5 минут

• Менеджер паролей для госсектора — это СЗИ (средство защиты информации) или общесистемное ПО для централизованного управления учётными данными в ГИС, ИСПДн и на объектах КИИ.
• Ключевое отличие от корпоративного решения — не в функционале, а в контуре применения: дополнительная нормативная база (152-ФЗ, 187-ФЗ, приказы ФСТЭК), требования к развёртыванию и криптографии.
• Выбор продукта начинается не со сравнения рейтингов, а с проверки допуска: сертификация ФСТЭК, запись в реестре отечественного ПО и соответствие модели развёртывания классу защищённости системы.
• Требования делятся на 8 групп — от нормативной применимости и размещения данных до контроля доступа, аудита и пользовательского опыта. Конкретный набор фиксирует проектная документация на систему.
• Для значимых объектов КИИ развёртывание на собственной инфраструктуре часто становится обязательным условием, а не опцией.
• Пассворк — менеджер паролей и сертифицированное ФСТЭК СЗИ (№ 5063, 4-й уровень доверия), включён в реестр отечественного ПО (№ 6147).
• Внедрение проходит пять фаз: аудит и подготовка, выбор и закупка, пилотное внедрение, полное развёртывание, аттестация и передача в эксплуатацию.

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

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

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

• Нормативная база. Корпоративный менеджер паролей подчиняется внутренним политикам компании и, опционально, отраслевым стандартам. Решение для госсектора дополнительно подпадает под 152-ФЗ, 187-ФЗ и приказы ФСТЭК.
• Требования к развёртыванию. В коммерческом секторе облачное размещение — норма. Для значимых объектов КИИ и систем высокого класса защищённости развёртывание на собственной инфраструктуре часто становится обязательным условием, а не опцией.
• Криптография. Корпоративному решению достаточно индустриального стандарта (AES-256). Для систем определённого класса защищённости проектная документация может требовать поддержку ГОСТ-алгоритмов.
• Сертификация и импортозамещение. Для госсектора сертификат соответствия ФСТЭК России и запись в реестре отечественного ПО — обязательные условия допуска к закупке, а при работе с ГИС и КИИ использование иностранного ПО дополнительно ограничивают указы Президента №166 и №250.

Какие требования предъявляют к менеджеру паролей в госсекторе

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

Группа 1. Нормативная и закупочная применимость

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

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

Группа 2. Размещение и контроль данных

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

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

Группа 3. Безопасность хранения

Группа охватывает шифрование данных, управление ключами и то, как система защищает основное хранилище.

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

Группа 4. Аутентификация и контроль доступа

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

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

Группа 5. Интеграции и администрирование

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

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

Группа 6. Аудит, SIEM и отчётность

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

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

Группа 7. Работа с паролями и общими секретами

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

Группа 8. Клиенты и пользовательский опыт

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

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

Как Пассворк закрывает эти требования

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

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

Нормативная база и сертификация

Размещение и изоляция данных

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

Шифрование и защита хранилища

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

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

Роли, группы и политики сейфов

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

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

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

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

Сертификаты совместимости с российскими ОС

Пассворк официально совместим с ведущими российскими операционными системами и инфраструктурными решениями. Менеджер паролей стабильно работает на Astra Linux, РЕД ОС, Альт Сервер, SelectOS, ОС «МСВСфера» и других отечественных дистрибутивах. Совместимость подтверждена двусторонними сертификатами с разработчиками платформ.

Для государственной организации, которая строит инфраструктуру на отечественном стеке (например, Astra Linux с MultiDirectory и Pangolin DB) это означает готовое, проверенное совместно с разработчиками решение.

Аутентификация и авторизация

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

Интеграции с инфраструктурой

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

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

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

Журнал действий и интеграция с SIEM

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

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

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

Управление паролями и общими секретами

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

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

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

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

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

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

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

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

Сводная таблица: требование госсектора → ответ Пассворка

Пошаговый план внедрения менеджера паролей в госорганизации

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

Фаза 1. Аудит и подготовка

1. Инвентаризация учётных записей и парольных практик.
2. Определение перечня систем, попадающих под КИИ, ГИС или ИСПДн.
3. Формирование требований к СЗИ на основе класса защищённости.
4. Назначение ответственных: офицер безопасности и администратор.

Фаза 2. Выбор и проверка

5. Проверка реестра отечественного ПО и реестра сертифицированных СЗИ ФСТЭК.
6. Запрос коммерческого предложения с учётом 44-ФЗ или 223-ФЗ.
7. Проверка сертификата ФСТЭК на сайте регулятора.
8. Тестирование пилотной установки на тестовом контуре.

Фаза 3. Пилотное внедрение

9. Развёртывание на тестовой среде в изолированном контуре.
10. Интеграция с LDAP/AD, настройка SSO для пилотной группы.
11. Импорт существующих паролей в защищённое хранилище.
12. Пилот на группе 10–20 пользователей, сбор обратной связи.

Фаза 4. Полное развёртывание

13. Развёртывание в продуктивной среде на всей инфраструктуре.
14. Настройка ролевой модели (RBAC) по принципу наименьших привилегий.
15. Настройка политик паролей: сложность, срок действия, история переиспользования.
16. Массовое подключение пользователей, обучение сотрудников и администраторов.

Фаза 5. Аттестация и мониторинг

17. Аттестационные испытания, если требуются по проектной документации.
18. Настройка регулярного аудита, интеграции с SIEM и оповещений.
19. Формирование регламента аварийного восстановления.
20. Передача в эксплуатацию с регламентом ежеквартального аудита политик и прав доступа.

Заключение

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

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

Готовы повысить уровень безопасности? Пассворк — сертифицированное ФСТЭК средство защиты информации. Пассворк закрывает все пункты требований из этой статьи: от локализации данных до интеграции с SIEM и российскими ОС. Разверните Пассворк в тестовом контуре и проведите пилотное внедрение бесплатно.

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

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

Только если облачная инфраструктура аттестована по требованиям ФСТЭК и принадлежит российскому провайдеру. Для значимых объектов КИИ допустимо исключительно развёртывание на собственной архитектуре.

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

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

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

Проверка выполняется на официальном сайте reestr.digital.gov.ru по названию продукта или ИНН правообладателя. В выписке из реестра указан регистрационный номер записи, класс программного обеспечения и дата включения — эти данные стоит запросить у поставщика как отдельный артефакт для ТЗ.

Что такое СЗИ?

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

Что такое КИИ?

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

Чем ролевая модель доступа отличается от группового управления правами?

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

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

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

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

Сертификация ФСТЭК: что это, кому нужна и как пройти

Разбираем систему сертификации ФСТЭК: кто обязан применять сертифицированные СЗИ, как устроена процедура от заявки до выдачи сертификата, чем отличаются уровни доверия УД-6 — УД-4 и какие обязательства возникают после получения сертификата.

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

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

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

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

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

Проблема не в дисциплине или лени. Инструктажи по информационной безопасности (ИБ) объясняют, что делать, но не снимают конфликт между удобством и безопасностью, который сотрудник переживает десятки раз за рабочий день. В 2026 году к этому конфликту добавился новый источник: нейросети и теневые ИИ (Shadow AI), которыми сотрудники пользуются в обход правил безопасности.

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

Несоблюдение основ ИБ становится дороже с каждым годом. Регулирование ужесточилось: приказ ФСТЭК России № 117 и оборотные штрафы за утечки персональных данных подняли цену ошибки — и для компании, и для конкретного человека. Атаки изменились и правило «не открывай подозрительные письма» стало недостаточным. Разберём, какие знания и привычки сотрудникам нужны в 2026 году, чтобы не стать точкой входа для инцидента.

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

• Информационная безопасность сотрудника — это не документ с политикой, а повседневные действия: уникальный пароль для каждого сервиса, двухфакторная аутентификация, проверка отправителя письма, блокировка экрана при отходе от рабочего места.
• Три угрозы определяют ландшафт атак 2026 года: фишинг-конвейеры (готовые наборы для массовых рассылок), дипфейки и компрометация учётных данных через переиспользование паролей.
• Теневой ИИ (Shadow AI) — использование сотрудниками нейросетей и чат-ботов без согласования с ИТ-отделом стало новым каналом утечки: данные, вставленные в промпт, покидают контур компании и не отслеживаются DLP и SIEM-системами.
• Регулирование ужесточилось: приказ ФСТЭК №117 обязывает операторов обучать персонал основам кибербезопасности и правилам работы с информацией, а за утечки персональных данных введены оборотные штрафы.
• Разовый годовой инструктаж не работает: знания без повторения забываются быстрее, чем компания успевает столкнуться с реальной атакой. Рабочий формат — короткие тренировки раз в месяц и регулярные напоминания об угрозах.
• Наказание даёт обратный эффект — сотрудники начинают скрывать ошибки. Цель проверки — закрепить привычку сообщать о подозрениях, а не найти виноватого.
• 14 правил цифровой гигиены — менеджер паролей, двухфакторная аутентификация, проверка отправителя, блокировка экрана и запрет на загрузку рабочих данных в публичные нейросети — закрывают большинство векторов атак.

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

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

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

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

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

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

Три главные угрозы 2026 года, которые касаются каждого сотрудника

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

Фишинг-конвейеры (PhaaS): почему «не переходи по ссылкам» уже не работает

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

Фишинговые письма грамотно имитируют внутреннюю переписку, используют реальные имена коллег и контекст текущих проектов.

Россия при этом входит в число самых атакуемых стран в мире: в период с июля 2024-го по сентябрь 2025 года на Россию пришлось около 14-16% всех глобальных атак, по данным отчёта Positive Technologies CODE RED 2026.

Социальная инженерия 2.0: дипфейки и таргетированные атаки

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

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

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

Компрометация учётных данных: пароли по-прежнему главный ключ

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

Ущерб от действий злоумышленников в ИТ-сфере за 2025–2026 годы превысил 600 млрд рублей, по данным F6. Компрометация учётных данных редко становится финальной целью атаки — чаще это первый шаг для горизонтального перемещения по инфраструктуре компании.

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

Shadow AI и Shadow IT: угроза, которую создают сами сотрудники

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

Сравнение Shadow IT и Shadow AI

80% сотрудников используют несанкционированные ИИ-инструменты в работе (Kiberboloid, 2026). Проблема не ограничивается рядовыми сотрудниками: 68% руководителей по безопасности, включая директоров по информационной безопасности, признаются, что сами используют несанкционированный ИИ в ежедневной работе. В России тенденция мягче: 26% сотрудников регулярно используют ИИ-инструменты в работе, 35% — периодически, по данным опроса hh.ru.

Эксперты ГК «Солар» называют Shadow AI «вторым Shadow IT»: в нейросеть сотрудник загружает данные из корпоративных систем — от общедоступной информации о компании до чертежей с расчётами и закрытых финансовых показателей. Встречаются случаи, когда сотрудники государственных структур загружают в публичные чат-боты чувствительные оперативные данные.

Почему это опасно:

• Потеря контроля над данными. Информация, загруженная в публичную нейросеть, обрабатывается на внешних, чаще иностранных серверах — компания не знает, где и как долго она там хранится.
• Риск дообучения и целевого поиска. Загруженные данные потенциально используются для дообучения модели, а в отдельных случаях становятся целью намеренного поиска злоумышленниками.
• Слепая зона для DLP и SIEM. Shadow AI не отслеживают системы предотвращения утечек данных (DLP) и управления событиями безопасности (SIEM) — они изначально не рассчитаны на мониторинг трафика к ИИ-сервисам.
• Потенциальное нарушение 152-ФЗ. Персональные данные клиентов или сотрудников в промпте потенциально создают высокий риск нарушения статьи 19 Федерального закона № 152-ФЗ «О персональных данных», даже без факта внешней утечки.
• Отсутствие аудиторского следа. Использование личного аккаунта в чат-боте не логируется корпоративными системами — при расследовании инцидента невозможно установить, какие данные и когда туда попали.
• Незащищённая интеллектуальная собственность. Фрагменты собственного кода или разработок компании, вставленные в промпт, потенциально становятся частью обучающего набора модели с неясным статусом прав.
  

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

Что изменилось в регулировании: ФСТЭК, штрафы и ответственность

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

С 1 марта 2026 года вступают в силу новые требования приказа ФСТЭК России №117 от 11.04.2025 к защите информации в государственных информационных системах. Документ требует, чтобы не менее 30% сотрудников подразделения ИБ имели профильное образование. Обязательное обучение персонала касается государственных органов, органов местного самоуправления, государственных унитарных предприятий и бюджетных учреждений.

В мае 2025 года в статью 13.11 КоАП РФ добавлены новые поправки. Размер штрафа для компании зависит от объёма утечки:

• От 3 до 5 млн рублей за утечку данных 1000–10 000 человек
• От 5 до 10 млн рублей при утечке данных более 10 000 человек
• От 10 до 15 млн рублей при утечке более 100 000 записей
• От 15 до 20 млн рублей за утечку биометрических данных

За повторную утечку персональных данных любой категории компания платит оборотный штраф в размере 1–3% годовой выручки, но не менее 20 млн рублей (для отдельных категорий данных — не менее 25 млн рублей). За тот же год Роскомнадзор зафиксировал 103 утечки данных, в результате которых пострадали около 50 млн записей о россиянах — для сравнения, в 2024 году было 135 утечек и 710 млн записей, по данным ТАСС.

Ответственность не ограничивается компанией. Административная ответственность по статье 13.11 КоАП РФ применяется независимо от умысла — по факту утечки или неправомерной обработки данных отвечает организация. Уголовная ответственность по статье 137 УК РФ «Нарушение неприкосновенности частной жизни» наступает только при доказанном прямом или косвенном умысле причинить вред человеку.

Сотрудника, который разгласил персональные данные коллег или клиентов, работодатель может уволить по подпункту «в» пункта 6 части 1 статьи 81 Трудового кодекса РФ:

«Разглашения охраняемой законом тайны (государственной, коммерческой, служебной и иной), ставшей известной работнику в связи с исполнением им трудовых обязанностей, в том числе разглашения персональных данных другого работника», — Статья 81 ТК РФ

Это отдельное основание для расторжения трудового договора, не требующее предварительных дисциплинарных взысканий. Требования 152-ФЗ (Федеральный закон «О персональных данных») к оператору персональных данных теперь подкреплены финансовыми и личными последствиями, а не только предписаниями регулятора.

14 правил цифровой гигиены сотрудника

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

1. Используйте менеджер паролей, а не память или блокнот

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

Как делать правильно:

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

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

2. Включите двухфакторную аутентификацию везде, где это доступно

Двухфакторная аутентификация (2FA/MFA) делает бесполезным украденный пароль без физического доступа к устройству сотрудника. По данным ФСТЭК России, 69% проверенных организаций не используют двухфакторную аутентификацию для привилегированных пользователей — именно там, где цена компрометации выше всего.

Не все методы 2FA одинаково надёжны. SMS-коды перехватывают через дублирование SIM-карты и социальную инженерию у оператора связи, а приложения-аутентификаторы уязвимы к фишингу в реальном времени.

Как делать правильно:

• Включите двухфакторную аутентификацию на рабочей почте, в CRM (1С, Битрикс24), таск-трекерах и любых системах с доступом к конфиденциальным данным.
• В качестве второго фактора минимально должны быть приложения-аутентификаторы, а не SMS-коды.
• Там, где сервис поддерживает ключи доступа (passkeys) — переходите на них. Ключ доступа привязан к конкретному домену и не работает на поддельном сайте, поэтому украсть его через фишинговую страницу невозможно.
• Для самых критичных учётных записей используйте аппаратные ключи безопасности. Это самый защищённый вариант второго фактора: закрытый ключ физически не покидает устройство и не может быть перехвачен удалённо, даже если компьютер сотрудника заражён.

3. Проверяйте адрес отправителя и подлинность собеседника в мессенджерах

Фишинговые-конвейеры (Phishing-as-a-Service) копируют стиль и логотипы компаний, но домен отправителя почти всегда выдаёт подделку при внимательной проверке. Фишинг остаётся основным способом первичной компрометации корпоративных сетей.

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

Как делать правильно:

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

4. Разделяйте личное и рабочее в браузере

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

Как делать правильно:

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

5. Не подключайтесь к рабочим сервисам через публичный Wi-Fi

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

Как делать правильно:

• При работе вне офиса раздавайте интернет с мобильного телефона вместо подключения к открытому Wi-Fi.
• Если подключение к публичной сети необходимо, используйте только корпоративный VPN.

6. Блокируйте экран при отходе от рабочего места

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

Как делать правильно:

• Блокируйте экран комбинацией Win + L на Windows или Cmd + Ctrl + Q на macOS каждый раз, когда встаёте из-за стола (даже на пару минут).
• Если работаете с ноутбуком вне офиса блокируйте экран при любом отвлечении, не только при полном уходе с места. В общественных местах посторонний человек может просто взглянуть на открытый экран рядом и увидеть переписку, документы или пароли, которые вы вводите.
• Настройте автоматическую блокировку экрана после короткого периода неактивности (1–2 минуты) как страховку на случай, если забыли заблокировать вручную.

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

Личные каналы связи не подпадают под корпоративный контроль систем предотвращения утечек данных (DLP, Data Loss Prevention) и мониторинга событий безопасности (SIEM, Security Information and Event Management). По данным InfoWatch, в России сотрудники с доступом к данным компании втрое чаще, чем в мире, используют мессенджеры для несанкционированной передачи данных — 13,2% инцидентов против 5% в мире.

Как делать правильно:

• Ведите рабочую переписку только в корпоративных каналах, которые контролирует ИТ-отдел.
• Не пересылайте рабочие документы и учётные данные в личные чаты — даже «на минутку» или «для себя».

8. Проверяйте права доступа при отправке файлов через облачные диски

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

Как делать правильно:

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

9. Не подключайте к рабочему компьютеру неизвестные USB-устройства

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

Как делать правильно:

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

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

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

Как делать правильно:

• Устанавливайте обновления операционной системы, браузера и рабочих приложений сразу после уведомления, особенно если оно помечено как критическое или касается безопасности.
• Не отключайте автоматические обновления на рабочем устройстве самостоятельно. Если обновление мешает работе — сообщите в ИТ-отдел, а не блокируйте процесс через настройки.
• Если в компании работает централизованное управление обновлениями (patch management), не устанавливайте несогласованные версии ПО и не откладывайте присланные обновления по собственной инициативе.

11. Контролируйте демонстрацию экрана на созвонах

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

Как делать правильно:

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

12. Не храните рабочие файлы на личных устройствах

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

Как делать правильно:

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

13. Сообщайте о подозрительной активности, даже если это ложная тревога

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

Как делать правильно:

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

14. Не загружайте рабочие данные в публичные нейросети

Несанкционированное использование ИИ-сервисов с рабочими данными (Shadow AI) — быстрорастущий канал утечки. Объём конфиденциальной информации российских компаний, которую сотрудники загружали в общедоступные нейросети вроде ChatGPT и Google Gemini, вырос за 2025 год в 30 раз.

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

Как делать правильно:

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

Правило можно расширить и до общей темы теневого ИТ (Shadow IT): тот же принцип касается любых неавторизованных сервисов, которые сотрудник подключает сам, без ведома ИТ-отдела. Каждый такой сервис — точка, которую не видит ни DLP-система, ни SIEM-мониторинг, ни администратор.

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

Как компании выстроить обучение, которое будет работать

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

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

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

За 2025 год в России зафиксировано 739 инцидентов утечки данных, в результате которых скомпрометированы 1,34 млрд записей персональных данных — подсчитали в InfoWatch. Почти половина (47%) киберинцидентов в 2025 году привела к нарушению основной деятельности компаний, по данным Positive Technologies. Ущерб от одного часа простоя из-за действий хакеров варьируется от 9,6 млн рублей в ритейле до 21,7 млн рублей в ИТ и телекоммуникациях, по оценке BI.ZONE.

Техническая брешь, которую не закроет тренинг

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

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

Опоры осведомлённости об инофрмационной безопасности

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

1. Короткие тренировки вместо годовых инструктажей. Занятие на 5–10 минут раз в месяц запоминается лучше, чем восьмичасовой курс раз в год. Формат может быть простым: короткое видео с разбором реального письма, которое прислали мошенники сотруднику компании на прошлой неделе, тест из пары вопросов с объяснением ответа. Такие занятия не отрывают от работы и запоминаются за счёт повторения, а не объёма материала.
2. Регулярные напоминания о новых угрозах и базовых правилах. Раз в две недели — короткое сообщение в рабочем чате: новая схема обмана, о которой стоит знать, или напоминание простого правила («не открывайте вложения от неизвестных отправителей», «проверяйте номер счёта перед переводом»). Такие сообщения занимают минуту на прочтение, но держат тему в поле внимания сотрудников между тренировками.
3. Проверочные фишинговые письма — без наказания за ошибку. Компания периодически отправляет сотрудникам безопасные тестовые письма, имитирующие реальную атаку, чтобы проверить, кто на них откликнется. Сотрудник, который кликнул на такое письмо, должен увидеть разбор (что выдало подделку), а не выговор от руководителя.

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

Что делать, если в компании нет ИБ-отдела

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

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

Заключение

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

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

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

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

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

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

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

Сотрудник — последняя линия обороны компании: 95,6% утечек данных в России происходят по вине персонала, по данным InfoWatch (2025). Обучение снижает число случайных ошибок (переход по фишинговой ссылке, ввод пароля на поддельном сайте), которые технические средства защиты не всегда способны предотвратить без соответствующей привычки у самого сотрудника.

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

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

Как часто нужно проводить обучение сотрудников информационной безопасности?

Оптимальный формат — короткие занятия по 10–20 минут раз в месяц вместо одного объёмного курса в год, дополненные регулярными напоминаниями о новых угрозах раз в одну-две недели. Регулярность закрепляет привычку лучше, чем объём материала: знания без повторения забываются быстрее, чем компания успевает столкнуться с реальной атакой.

Можно ли использовать один пароль для всех рабочих сервисов?

Нет. Один пароль для нескольких сервисов означает, что взлом самого незначительного из них открывает доступ ко всем остальным через переиспользование учётных данных. По данным Контур.Эгида (2025), так поступают 30% сотрудников — это одна из главных причин массовых компрометаций.

Что делать, если я перешёл по подозрительной ссылке?

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

Кто отвечает за информационную безопасность — ИТ-отдел или каждый сотрудник?

Формально ответственность закреплена за ИТ-отделом и службой безопасности: они настраивают системы защиты и контролируют их работу. Фактически безопасность зависит от каждого сотрудника, потому что 95,6% утечек в России происходят из-за действий персонала — умышленных или случайных (InfoWatch, 2025). Технические средства защиты не работают без базовых привычек пользователей.

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

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

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

7 способов взлома соцсетей: как воруют аккаунты в 2026 году

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

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

Импортозамещение КИИ в 2026: сроки, требования и план перехода

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

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

За три года в мире скомпрометировано более 100 миллиардов записей персональных данных, из них 4,5 миллиарда — в России. Такую статистику приводит экспертно-аналитический центр InfoWatch в своём исследовании «Отчет об утечках информации в мире за три года». Персональные данные фигурируют в 74% всех утечек и именно они питают взломы аккаунтов ВКонтакте, Одноклассников и других социальных сетей: украденные логины и пароли моментально оседают в базах для автоматического перебора.

Число сообщений о взломах аккаунтов в соцсетях выросло на 123,1% в период с марта 2024 по февраль 2025 года — динамика, которую фиксирует исследование аналитического агенства ПрессИндекс.

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

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

• Масштаб угрозы огромен. За три года в мире скомпрометировано более 100 млрд записей. 39% россиян уже сталкивались со взломом аккаунтов в соцсетях как прямым следствием утечки — и это только те, кто об этом узнал.
• Фишинг остаётся главным вектором. Поддельные страницы авторизации, SMS-рассылки, боты в мессенджерах — всё это доступно как готовый сервис за несколько тысяч рублей. Порог входа для атакующего минимален.
• Повторяющиеся пароли делают одну утечку катастрофой. 77% россиян используют не более семи паролей на все сервисы. Одна скомпрометированная пара логин/пароль автоматически проверяется на десятках других платформ.
• SMS-коды не защищают от SIM-своппинга. Перехватив номер телефона через оператора связи, атакующий получает все одноразовые коды и полный контроль над аккаунтами, привязанными к этому номеру.
• Инфостилеры обходят двухфакторную аутентификацию. Вредоносное ПО крадёт не пароль, а активный сессионный cookie прямо из браузера. Сервер видит валидный токен и не запрашивает повторную аутентификацию.
• Механизм «Забыли пароль?» — самостоятельный вектор атаки. Ответы на контрольные вопросы собираются из открытых профилей за 15–20 минут. Взломанная почта открывает доступ ко всем привязанным сервисам сразу.
• Украденный аккаунт — начало монетизации. Доступ продаётся и затем используется для мошенничества по контактам жертвы, фишинга, шантажа и проверки тех же паролей на банковских приложениях.

Фишинг: почему ссылка всё ещё главное оружие

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

Как работает фишинговая атака

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

Раньше подготовка такой атаки требовала технических знаний: нужно было самостоятельно создать копию страницы, настроить перехват данных, организовать рассылку. Сейчас всё это продаётся в готовом виде. Фишинг как услуга (Phishing-as-a-Service, PhaaS) — наборы инструментов с теневых форумов, которые включают поддельные страницы авторизации под конкретные сервисы, Telegram-боты для автоматического сбора и сортировки украденных данных, панели управления с аналитикой успешных входов.

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

Актуальные методы фишинга в 2026 году

• Почтовый фишинг — массовые рассылки с поддельными уведомлениями от имени соцсетей, банков или госсервисов: «Ваш аккаунт заблокирован», «Подтвердите вход», «Обнаружена подозрительная активность». Письмо визуально копирует оформление оригинала (логотип, шрифты и структуру). Ссылка ведёт на поддельную страницу авторизации.
• SMS-фишинг (smishing, смишинг) — вредоносные ссылки через SMS с имитацией уведомлений от банков, операторов связи или госпорталов. Расчёт на то, что короткое SMS воспринимается как системное сообщение, а не как потенциальная угроза.
• Фишинг в мессенджерах — атаки через Telegram, личные сообщения ВКонтакте, Одноклассники и другие платформы. Особенно опасны боты, имитирующие официальную техподдержку: они отвечают связно, выдерживают диалог и запрашивают код подтверждения под убедительным предлогом.
• Голосовой фишинг (vishing, вишинг) — звонки от имени «службы безопасности банка» или «технической поддержки» с требованием назвать код из SMS или подтвердить операцию.
• Фишинг через QR-коды (quoshing, квишинг) — поддельные QR-коды на распечатанных объявлениях, в письмах или документах. Пользователь сканирует код и попадает на страницу сбора учётных данных.
• ИИ-фишинг — автоматическая генерация персонализированных сообщений на основе данных из открытых профилей жертвы: имени, круга общения, недавних публикаций, места работы. Сообщение выглядит как написанное живым человеком, который знает контекст.

Подстановка учётных данных: когда ваш пароль уже украден

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

Данные для атак подстановкой накапливается стремительно: отчёт SpyCloud (март 2026) показал, что в 2025 году в базах утечек накоплено 5,3 млрд пар логин/пароль — рост на 65% год к году. Каждая такая пара потенциально используется в атаках на подстановку учётных данных. Если ваш электронный адрес есть хотя бы в одной из этих баз, атакующим остаётся только автоматически проверить пароль для входа в социальные сети.

Как работает подстановка учётных данных

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

Почему это работает

По данным DLBI, каждый третий россиянин (30%) использует не более трёх паролей для всех своих сервисов. Ещё 47% обходятся четырьмя-семью комбинациями. Более уникальные пароли (от восьми) создают только 23% пользователей.

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

Брутфорс: когда пароль слишком прост

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

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

Как работает брутфорс

Скорость атаки зависит от двух факторов: вычислительной мощности и метода.

1. Сбор для точки входа. Атакующий определяет цель: логин, электронный адрес или номер телефона.
2. Выбор метода перебора. В зависимости от сложности пароля и имеющихся данных о жертве атакующий выбирает стратегию: от перебора популярных словарных комбинаций до полного перебора всех возможных символов.
3. Запуск автоматизированного перебора. Специализированные инструменты отправляют запросы на авторизацию с подменой пароля при каждой попытке.
4. Обход ограничений. Запросы распределяются по прокси-серверам и ботнетам, чтобы не превышать пороговые значения блокировки. Между попытками добавляются случайные задержки (имитация действий живого пользователя).
5. Фиксация результата. Успешный вход автоматически логируется. Аккаунт уходит в продажу или используется для дальнейших взломов.

6 основных методов брутфорса

• Простой брутфорс (полный перебор, Brute Force) — последовательный перебор всех возможных комбинаций символов в заданном пространстве поиска: aaaa, aaab, aaac. Метод не использует предположений о структуре пароля и гарантирует результат при достаточных ресурсах, но сложность растёт экспоненциально с длиной пароля.
• Атака по словарю (Dictionary Attack) — перебор по заранее подготовленному списку вероятных кандидатов: реальных паролей из утечек, распространённых слов, предсказуемых последовательностей. Алгоритм проверяет не aaaa0001, а p@rol12, qwerty, admin123 — то, что люди действительно используют. Популярный словарь rockyou.txt содержит 14 млн записей.
• Распыление паролей (Password Spraying) — один пароль последовательно проверяется против большого числа учётных записей. Логика обратная классическому брутфорсу: не множество паролей против одного аккаунта, а один пароль против тысяч аккаунтов.
• Гибридная атака (Hybrid Attack) — метод взлома паролей, сочетающий словарный перебор с автоматическими мутациями базовых слов. Алгоритм не перебирает все возможные комбинации, а воспроизводит предсказуемые человеческие шаблоны: добавляет цифры в конец (admin2026), заменяет буквы символами (@dmin), вставляет спецсимволы (Admin!), меняет регистр (ADMIN, Admin).
• Атака по радужным таблицам (Rainbow Table Attack) — офлайн-взлом хешей на основе предвычисленных таблиц соответствий «пароль → хеш». При получении хеша из утечки атакующий не вычисляет его заново, а ищет совпадение в готовой таблице.
• Распределённый брутфорс через ботнет — атака распределяется между тысячами скомпрометированных устройств. Каждый узел отправляет минимальное число запросов — достаточно малое, чтобы не вызвать блокировку, но в совокупности обеспечивающее высокую скорость перебора.
• ИИ-брутфорс (AI-Assisted Brute Force) — модели машинного обучения, обученные на миллиардах реальных паролей из утечек, предсказывают наиболее вероятные кандидаты для конкретного пользователя или организации и начинают атаку с них — вместо последовательного перебора всех комбинаций.

Социальная инженерия и SIM-своппинг: когда взламывают не пароль, а человека

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

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

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

Как работает атака через социальную инженерию

Типовой сценарий для пользователей социальных сетей — атака через доверие:

1. Сбор данных. Атакующий изучает профиль жертвы: имя, фото, круг общения, место работы, упомянутые события. Всё это доступно в открытых профилях ВКонтакте, Одноклассниках, Telegram-каналах.
2. Создание легенды. Злоумышленник пишет от имени знакомого, службы поддержки или официального аккаунта сервиса. Сообщение содержит правдоподобный предлог: «Ваш аккаунт пытались взломать, подтвердите личность», «Вы выиграли приз, введите код из SMS».
3. Получение кода. Жертву просят назвать код из SMS или пуш-уведомления якобы для «подтверждения» или «защиты» аккаунта. Этот код и есть одноразовый токен двухфакторной аутентификации (2FA). Как только он передан — атакующий входит в аккаунт.
4. Захват аккаунта. Злоумышленник меняет пароль и привязанный номер телефона. Жертва теряет доступ к профилю и нередко обнаруживает это только тогда, когда знакомые сообщают о подозрительных сообщениях от её имени.

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

SIM-своппинг: перехват номера как ключа ко всем SMS-кодам

SIM-своппинг (SIM-swap) — переоформление номера телефона жертвы на SIM-карту атакующего через оператора связи: злоумышленник убеждает поддержку, что именно он является владельцем номера, и добивается переноса номера на свою SIM-карту или eSIM. После этого все входящие SMS (коды 2FA от ВКонтакте, мессенджеров, банковских приложений, Госуслуг) поступают злоумышленнику.

Важно отличать SIM-своппинг от схожих атак:

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

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

Пять сценариев SIM-своппинга

1. Звонок в колл-центр («растерянный клиент»). Самый распространённый вариант. Злоумышленник звонит в поддержку оператора под видом клиента, потерявшего SIM-карту. Убедительная легенда плюс заранее собранные персональные данные жертвы (ФИО, дата рождения, паспортные данные из утечек или открытых профилей ВКонтакте) позволяют пройти проверку и получить перевыпуск номера. Сотрудник колл-центра не видит собеседника и вынужден доверять его словам.
2. Визит в салон связи с поддельными документами. Атакующий приходит в офис оператора лично с распечатанной или поддельной доверенностью либо с документами, данные которых совпадают с данными жертвы из купленной базы. Физическое присутствие создаёт иллюзию легитимности. Этот сценарий требует большей подготовки, но даёт более высокий процент успеха у операторов с жёсткими требованиями к удалённой идентификации.
3. Взлом личного кабинета оператора. Личный кабинет на сайте оператора зачастую защищён слабее банковского приложения. Получив доступ через подобранный или утёкший пароль, атакующий самостоятельно инициирует перевыпуск eSIM.
4. Инсайдер у оператора. Один из наиболее опасных и труднообнаруживаемых сценариев. Злоумышленник платит сотруднику оператора связи за выполнение перевыпуска SIM «изнутри» — без каких-либо проверок и документов. Жертва не получает никаких предупреждений: операция выглядит как штатная.
5. Перенос номера к другому оператору. Атакующий инициирует перенос номера жертвы к другому оператору. Для этого достаточно знать код переноса, который можно получить через поддержку или личный кабинет. После переноса номер оказывается у нового «владельца» на SIM другого оператора, и прежний оператор уже ничего не контролирует.

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

Инфостилеры и перехват сессий

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

Именно поэтому сессионный токен сегодня ценится в даркнете выше пары логин/пароль: он открывает доступ к аккаунту мгновенно и полностью обходит двухфакторную аутентификацию (2FA). По данным отчёта Positive Technologies, вредоносное ПО остаётся одним из двух ключевых методов атак на российские организации наряду с социальной инженерией и сохранит эту позицию в 2026 году.

Как это работает: от заражения до доступа без пароля

1. Заражение устройства. Пользователь скачивает файл из фишингового письма, устанавливает поддельное расширение для браузера, переходит по рекламной ссылке в поисковике, ведущей на фейковую страницу загрузки популярного ПО, или открывает пиратский контент. Вредоносный код запускается в фоне без видимых признаков заражения.
2. Сканирование браузера. Инфостилер обращается к локальному хранилищу браузера: базе данных cookies, сохранённым паролям, данным автозаполнения, сессионным токенам. Chromium-браузеры (Chrome, Edge, Яндекс.Браузер) хранят эти данные в предсказуемых директориях — инфостилер знает, где искать.
3. Передача данных на сервер управления. Собранные данные упаковываются и отправляются на C2-сервер (Command & Control — сервер управления и контроля) атакующего. Весь процесс, от заражения до передачи, занимает секунды.
4. Импорт cookies в браузер атакующего. Злоумышленник загружает перехваченные файлы cookies в свой браузер с помощью специализированных инструментов. С точки зрения сервера — это тот же пользователь, с тем же устройством, с той же активной сессией.
5. Полный доступ без пароля и без 2FA. Сервер видит валидный сессионный токен и не запрашивает ни пароль, ни код подтверждения. Аутентификация уже прошла — повторная проверка не нужна. Атакующий получает доступ к аккаунту ВКонтакте, Одноклассниках, Госуслугам, почте или банковскому личному кабинету.

Почему инфостилеры обходят 2FA

Двухфакторная аутентификация защищает момент входа. Сессионный cookie — это доказательство того, что вход уже состоялся. Сервер не знает, что токен украден: он видит корректный идентификатор сессии и считает пользователя авторизованным. Это фундаментальное ограничение SMS-2FA и приложений-аутентификаторов: они защищают процесс входа, но не защищают активную сессию после него.

Наиболее распространённые инфостилеры

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

По данным SpyCloud, в 2025 году зафиксировано 13,2 млн новых заражений инфостилерами, в результате которых украдено 642,4 млн учётных записей и 8,6 млрд сессионных cookies. При этом 40% заражений произошли на устройствах с активными антивирусными решениями — инфостилеры целенаправленно разрабатываются с учётом обхода EDR-систем (Endpoint Detection and Response — средств обнаружения и реагирования на угрозы на конечных точках).

Поддельные приложения и публичный Wi-Fi: атака через экосистему

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

Поддельные приложения: как это работает

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

Схема типична: в Telegram-канале с десятками тысяч подписчиков появляется реклама: «Telegram Premium без подписки», «ВКонтакте без рекламы», «Подписка на год». Ссылка ведёт на установочный файл — модифицированное приложение с встроенным инфостилером или RAT (Remote Access Trojan, троян удалённого доступа).

Атака разворачивается в четыре последовательных шага:

1. Распространение через доверенный канал. Реклама размещается в тематических Telegram-каналах с реальной аудиторией о технологиях, лайфхаках, бесплатном ПО. Подписчики доверяют каналу, поэтому снижают бдительность.
2. Установка вне официального магазина. Пользователь скачивает установочный файл напрямую в обход Google Play, App Store или RuStore. Система предупреждает об установке из неизвестного источника, но большинство игнорирует это предупреждение.
3. Запрос избыточных разрешений. При установке приложение запрашивает доступ к SMS, контактам, файловой системе, микрофону. Пользователь принимает всё — он ждёт обещанных функций.
4. Фоновая работа вредоносного кода. Приложение функционирует как заявлено — реклама действительно исчезает или появляются дополнительные функции. Параллельно встроенный стилер или RAT собирает данные и передаёт их на сервер атакующего.

Пять признаков поддельного приложения:

1. Распространяется вне официальных магазинов
2. Запрашивает разрешения, не связанные с функциями приложения (доступ к SMS у «улучшенного» мессенджера)
3. Источник — реклама в мессенджерах или сторонние сайты
4. Обещает функции, которых нет в официальной версии
5. Имя разработчика не совпадает с официальным

MITM-атака через публичный Wi-Fi

MITM-атака (Man-in-the-Middle, человек посередине) — перехват трафика между устройством пользователя и точкой доступа. Злоумышленник встраивается в канал связи и получает возможность читать, изменять или перенаправлять передаваемые данные.

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

• SSL-stripping. Атакующий принудительно понижает соединение с HTTPS до HTTP. Браузер пользователя общается с сервером атакующего по незащищённому каналу, тот — с целевым сайтом по HTTPS. Пользователь видит сайт, но не замечает отсутствия замка в адресной строке.
• Поддельная точка доступа. Злоумышленник создаёт Wi-Fi-сеть с названием, идентичным легитимной: «Airport_Free», «Hotel_WiFi», «CoffeeHouse_Guest». Устройство подключается автоматически, если уже подключалось к сети с таким именем раньше. Весь трафик проходит через оборудование атакующего.
• Перехват незашифрованных запросов. Часть мобильных приложений и браузерных версий социальных сетей отправляет вспомогательные запросы без шифрования — аналитику, метаданные, служебные токены. Этого достаточно, чтобы восстановить активную сессию.

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

Восстановление пароля как вектор атаки: эксплуатация «забыли пароль»

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

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

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

1. OSINT-сбор данных. Атакующий изучает открытые профили жертвы: ВКонтакте, Одноклассники, мессенджеры. Фотографии с подписями, посты о питомцах, упоминания родственников, геотеги с мест учёбы и работы — всё это источники ответов на контрольные вопросы. Сбор не требует технических навыков.
2. Перехват письма для сброса. Если контрольные вопросы не используются, атакующий сначала компрометирует почтовый ящик жертвы через фишинг или подстановку учётных данных из утечек. Получив доступ к электронной почте, он инициирует сброс паролей на всех привязанных сервисах: социальных сетях, маркетплейсах, стриминговых платформах.
3. Эксплуатация слабых механизмов восстановления. Часть сервисов позволяет восстановить доступ через SMS на привязанный номер. Это делает данный вектор прямым продолжением SIM-своппинга: перехватив номер жертвы, атакующий получает не только коды 2FA, но и полный контроль над механизмом сброса паролей на всех привязанных аккаунтах.
4. Захват аккаунта. Новый пароль установлен атакующим. Жертва теряет доступ и зачастую не сразу понимает, что произошло: уведомление о смене пароля приходит на почту или номер, которые уже контролирует злоумышленник.

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

Что происходит с украденным аккаунтом: экономика перепродажи

Взлом аккаунта — всего лишь начало цепочки монетизации. За каждой скомпрометированной учётной записью стоит отлаженный рынок с чёткими ценами, специализацией участников и вторичным использованием данных. По данным исследования F6 (май 2025 года), украденные аккаунты в теневом интернете продаются от $10 за штуку — это самая дешёвая позиция на хакерских форумах.

Шаг 1. Первичный сбор.

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

Шаг 2. Продажа на теневых рынках.

Базы продаются оптом или поштучно на форумах в дарквебе и Telegram-каналах.

Шаг 3. Вторичное использование.

Купленный аккаунт используется для:

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

7 мер защиты, которые работают в 2026 году

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

Заключение

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

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

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

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

Часто задаваемые вопросы о взломе аккаунтов в соцсетях

Как чаще всего взламывают аккаунты в соцсетях в 2025–2026 годах?

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

Помогает ли двухфакторная аутентификация защитить аккаунт?

Да, но степень защиты зависит от метода. SMS-коды уязвимы для SIM-своппинга: перехватив номер жертвы, атакующий получает все одноразовые коды. Надёжнее — приложения-аутентификаторы (TOTP, одноразовые коды на основе времени) или ключи доступа (passkey). Инфостилеры, ворующие сессионные файлы cookies из браузера, обходят любой второй фактор — они крадут уже готовый результат аутентификации.

Что такое подстановка учётных данных и чем она отличается от брутфорса?

Подстановка учётных данных (credential stuffing) использует реальные пары логин+пароль из утёкших баз и автоматически проверяет их на других сервисах — расчёт на то, что пользователь повторяет одни и те же пароли. Брутфорс (атака полным перебором) перебирает все возможные комбинации символов без опоры на известные данные. Подстановка быстрее и эффективнее при массовых атаках. Брутфорс применяется против конкретных аккаунтов с короткими или простыми паролями.

Может ли инфостилер обойти двухфакторную аутентификацию?

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

Как злоумышленники зарабатывают на украденных аккаунтах?

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

Что такое SIM-swap и как от него защититься?

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

Как восстановление пароля превращается в вектор атаки?

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

Как понять, что аккаунт уже взломан?

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

Опасно ли подключаться к публичному Wi-Fi?

Публичные сети создают условия для атаки типа «человек посередине» (MITM, Man-in-the-Middle) — перехвата трафика между вашим устройством и точкой доступа. Злоумышленник может создать поддельную сеть с названием, идентичным легитимной («Airport_Free», «Hotel_WiFi»), и перехватить сессионные данные. Для важных действий избегайте публичных сетей или используйте мобильный интернет.

Что такое фишинг как услуга и почему атаки стали массовыми?

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

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

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

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

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

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

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

Авторизация и аутентификация: в чем разница и почему это важно

Идентификация, аутентификация, авторизация — в чём разница и почему это важно для безопасности. Рассмотрим термины, модели доступа RBAC и ABAC, MFA, Passkeys и Zero Trust с примерами.

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

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

По данным ежегодного отчёта F6 «Аналитика и прогнозы 2025–2026», количество атак шифровальщиков в 2025 году выросло на 15%, а каждый седьмой инцидент в среднем и крупном бизнесе завершился не выкупом, а уничтожением инфраструктуры — вдвое чаще, чем годом ранее. Рекордный запрошенный выкуп достиг 500 млн рублей. За этими цифрами стоят типовые архитектурные просчёты: открытые пути к резервным копиям, пароли в общем доступе, домен без сегментации.

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

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

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

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

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

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

Архитектурные принципы защиты

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

• Физическая и логическая изоляция. Системы критического сегмента не должны входить в домен Active Directory (AD). Это исключает целый класс атак на доменные службы.
• Выделенная административная станция. Управление критическими системами осуществляется только с отдельной рабочей станции, не входящей в домен и не используемой в повседневной работе.
• Отсутствие учётных данных в операционной инфраструктуре. Аутентификационные данные от систем критического сегмента не хранятся и не передаются через основную доменную инфраструктуру.

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

Почему защиты периметра недостаточно

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

Типичная цепочка продвижения атакующего внутри сети выглядит так:

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

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

Рекомендации по безопасной конфигурации ИТ-инфрастуктуры критического сегмента

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

Изоляция от доменной инфраструктуры

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

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

Не размещайте сервисы управления средствами защиты информации (СЗИ), резервным копированием, хранилища секретов и аутентификационных данных (корпоративные менеджеры паролей, системы аутентификации) и их базы данных на серверах, входящих в домен Active Directory.

Почему это работает

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

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

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

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

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

Почему это работает

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

Сетевая изоляция и протоколы

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

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

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

Почему это работает

Закрытые порты и запрет устаревших протоколов устраняют downgrade-атаки и сокращают возможности нелегитимного взаимодействия с системами, уменьшая  поверхность атаки на них. Ограничение исходящего трафика блокирует установку C2-каналов (command-and-control) и эксфильтрацию данных, даже если злоумышленник уже получил доступ к хосту.

Принцип минимальных привилегий

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

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

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

Почему это работает

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

Аутентификация: блокировка и MFA

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

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

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

Почему это работает

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

Шифрование дисков

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

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

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

Почему это работает

Зашифрованный диск, извлечённый из сервера или скопированный как файл ВМ, бесполезен без ключа. Это закрывает вектор физического доступа и кражи носителей.

Виртуализация: обособленный гипервизор

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

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

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

Почему это работает

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

Обновления и встроенные механизмы безопасности

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

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

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

Почему это работает

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

Мониторинг и SIEM

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

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

Настройте централизованный сбор и анализ событий безопасности критического сегмента в SIEM-системе.

Почему это работает

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

Защита критически важных устройств ИТ-инфраструктуры

Харденинг как стратегия сдерживания

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

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

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

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

Что такое харденинг ИТ-инфраструктуры?

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

Какие системы являются критически важным сегментом инфраструктуры?

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

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

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

Как настроить харденинг критического сегмента без простоя?

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

Нужно ли выводить критические системы из домена Active Directory?

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

Как проверить настройки перед внедрением в рабочую среду?

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

Какие ошибки чаще всего допускают при харденинге инфраструктуры?

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

Импортозамещение КИИ в 2026: сроки, требования и план перехода

С 2025 года часть запретов на иностранное ПО и СЗИ уже действует. Базовый дедлайн перехода — 2028 год, штрафы за нарушение сроков готовятся. Разбираем требования, сроки и план действий на 2026 год.

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

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

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

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

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

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

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

У ИБ-отдела особый класс секретов: доступы к SIEM, EDR, SOAR, аварийные учётные записи, SSH-ключи критичной инфраструктуры. Их чувствительность определяется не только содержимым, но и тем, что они раскрывают — архитектуру защиты и внутреннюю структуру безопасности.

Хранить такие секреты можно двумя способами:

• Для большинства компаний достаточно логической изоляции: одна инсталляция Пассворка с типами сейфов, ролями, MFA, LDAP/SSO и аудитом. Секреты разделены по назначению и владельцам, доступ разграничен через права и группы.
• Физическая изоляция (отдельный экземпляр Пассворка для ИБ-контура) нужна там, где данные должны быть скрыты от администраторов общего контура не только на уровне прав, но и на уровне самого факта существования: названий сейфов, структуры папок и журналов активности.

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

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

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

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

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

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

Какие секреты требуют особого режима хранения

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

Один экземпляр Пассворка с типами сейфов: когда этого достаточно

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

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

Модель типов сейфов

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

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

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

Роли и группы позволяют разграничить доступ подразделений без ручной настройки каждого пользователя. Интеграция с AD/LDAP упрощает добавление новых пользователей и отзыв доступов: сотрудник уходит — доступ отзывается через синхронизацию с каталогом. SAML SSO снижает трение при ежедневной работе. MFA и журнал действий обеспечивают контроль.

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

Два независимых экземпляра Пассворка: когда нужна физическая изоляция

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

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

Что даёт физическая изоляция

• Устойчивость к ошибкам. Ошибка в правах доступа в общем корпоративном контуре не раскрывает ИБ-секреты. Контуры физически разделены: некорректная настройка в одном не затрагивает другой.
• Закрытые метаданные. Администраторы общего контура не видят структуру ИБ-сейфов: ни названий, ни папок, ни активности. ИТ-администратор бизнес-экземпляра Пассворка не знает, какие системы и инструменты находятся под управлением ИБ-команды.
• Независимые администраторы. ИБ управляет своим экземпляром самостоятельно без пересечения с ИТ-администраторами общего контура. Каждая команда настраивает свой экземпляр независимо и не имеет прав в чужом контуре.
• Независимые политики. ИБ применяет собственные настройки: более жёсткие требования к MFA, короткий таймаут сессии, запрет офлайн-доступа, ограничения на экспорт, отдельные правила API-доступа — без компромиссов с требованиями бизнес-подразделений.
• Чистый журнал. ИБ-инсталляция фиксирует только события ИБ-команды без фонового шума от финансов, продаж и подрядчиков. Это упрощает расследования и сокращает время на анализ.
• Прозрачность для аудита. Контур проще описывать в документах модели угроз, при прохождении сертификации и внешних аудитов — в том числе по требованиям ФСТЭК и для объектов КИИ. Разделение контуров часто является требованием регулятора.

Когда ИБ-контур требует закрытой сети

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

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

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

Сравнение двух моделей

Локальный ИБ-инстанс и облако для бизнеса

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

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

Разделение доступов

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

Отдельный DevOps/SRE-контур: чем он отличается от ИБ-контура

DevOps-контур изолируется по другим причинам, чем ИБ-контур. ИБ-секреты требуют изоляции из-за конфиденциальности, независимого администрирования и требований к аудиту расследований. DevOps-секреты — из-за автоматизации, высокой частоты ротации, машинного потребления через API, CLI и SDK, а также большого числа интеграций с CI/CD-пайплайнами.

В одном инстансе можно создать тип сейфов «DevOps/CI-CD» и назначить команду разработчиков его администраторами. Отдельная DevOps-инсталляция оправдана при большом объёме машинных секретов, высокой частоте ротации и независимой команде разработки, которая должна управлять своим контуром без зависимости от общих администраторов.

Пассворк поддерживает API-first подход, CLI и SDK для работы с секретами, включая сценарии миграции, аудита и CI/CD-интеграций. Подробнее — в разделе документации «Пассворк как менеджер секретов».

Сравнение сценариев

Как выбрать архитектуру: один или два контура

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

Критерии выбора архитектуры хранения секретов

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

Как внедрить выбранную модель

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

1. Классифицировать секреты. Разделить данные на категории: обычные, ИБ-критичные, инфраструктурные, DevOps, аварийные. После этого понятно, какие данные требуют какого уровня изоляции.
2. Определить владельцев. Назначить ответственного бизнес- или технического владельца для каждого типа. У каждой категории секретов появляется ответственный.
3. Оценить чувствительность метаданных. Проверить, где опасны даже названия систем, папок и сейфов. Это покажет, где логической изоляции недостаточно.
4. Определить допустимых администраторов. Решить, кто может управлять контуром и кто не должен иметь технической видимости. Результат: понятная модель доверия и границы администрирования.
5. Выбрать модель. Одна инсталляция, две локальные, локальный ИБ-контур плюс облачный бизнес-контур или отдельный контур разработки. Архитектурное решение принято и обосновано.
6. Спроектировать типы сейфов. Создать целевую структуру сейфов, ролей, групп и правил создания. Итог: схема, которую можно реализовать и задокументировать.
7. Настроить интеграции. LDAP/SSO, MFA, API/CLI/SDK, SIEM, резервное копирование и мониторинг. Каждая интеграция получает чёткие границы и ответственного.
8. Ввести регулярную проверку прав. Проверять права, администраторов, журналы и структуру сейфов после изменений в командах и инфраструктуре.

Правильная архитектура начинается с классификации

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

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

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

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

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

Нужна ли ИБ-отделу отдельная инсталляция Пассворка?

Отдельный инстанс необходим, если ИБ-отдел хранит секреты, которые не должны быть видны администраторам общего контура даже на уровне структуры: доступы к SIEM, EDR, SOAR, сканерам, аварийные доступы, SSH-ключи, API-токены и сервисные пароли. Если таких требований нет, достаточно одной инсталляции с типами сейфов, ролями, MFA и аудитом.

Когда достаточно одной инсталляции Пассворка?

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

Чем физическое разделение лучше настройки прав доступа?

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

Что такое типы сейфов в Пассворке?

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

Может ли администратор общего инстанса видеть ИБ-сейфы?

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

Как разделить личные, командные и инфраструктурные пароли?

Начните с классификации секретов, определите владельцев и создайте типы сейфов: личные, командные, ИТ, ИБ, DevOps, проектные и сервисные аккаунты. Для каждого типа задайте администраторов, права, MFA, аудит и даты аудита.

Как организовать аудит действий ИБ-команды?

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

Какие секреты нельзя хранить в общих сейфах?

В общих сейфах не стоит хранить аварийные учётные записи, root/admin-доступы, токены EDR/SIEM/SOAR, SSH-ключи критичной инфраструктуры, API-ключи облаков и секреты, раскрытие метаданных которых может навредить безопасности.

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

Триггеры перехода: апрет на видимость ИБ-метаданных ИТ-администраторами, требование независимого аудита ИБ-действий, регуляторные требования (ФСТЭК, КИИ), необходимость применения более жестких политик безопасности (MFA, сессии, экспорт) или выделение изолированного DevOps/SRE-контура.

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

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

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

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

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

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

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

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

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

20 мая 2026 года исследователи из PhishU описали технику, которую назвали VaultJacking. Один перехваченный шестизначный ПИН-код и злоумышленник получает доступ ко всему синхронизированному хранилищу менеджера паролей Google: учётным данным, ключам доступа (passkey), сохранённым паролям от банков, почты, корпоративных систем. Ко всем сразу.

Для бизнеса это означает следующее: если сотрудник хранит рабочие пароли в Google-аккаунте — это готовая потенциальная точка входа в вашу корпоративную инфраструктуру.

Что такое VaultJacking простыми словами

VaultJacking (от англ. vault — хранилище, сейф и jacking/hijacking — угон, захват) — фишинговая техника, при которой злоумышленник перехватывает ПИН-код от менеджера паролей Google и использует его для доступа к синхронизированному хранилищу паролей и ключам доступа (passkeys). Атака реализована исследователями PhishU в формате PoC (proof-of-concept, демонстрация и проверка концепции) — полная цепочка атаки воспроизведена и задокументирована.

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

Ключевые факты

• Атака нацелена не на отдельный сайт, а на слой синхронизации Google Password Manager, то есть на всё хранилище сразу.
• Один перехваченный PIN-код открывает доступ ко всем паролям и ключам доступа (passkey, стандарт WebAuthn), сохранённым в аккаунте Google.
• Ключи доступа защищают вход на конкретный сайт, но не закрывают риск компрометации самого хранилища — это разные уровни модели угроз.
• Рабочие пароли в личном браузерном профиле сотрудника — неуправляемый актив: компания не видит их, не контролирует и не может отозвать.
• Меры защиты существуют и применимы без специальных технических знаний.

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

Как работает атака на менеджер паролей Google

Чтобы понять, почему VaultJacking работает, нужно разобраться в архитектуре Google Password Manager. Каждый аккаунт Google имеет «домен безопасности» (security domain). Устройства, присоединившиеся к этому домену, получают доступ ко всем синхронизированным паролям и ключам доступа. Ключ к расшифровке хранилища называется Security Domain Secret (SDS) — облачный сервис Google выдаёт его любому устройству, которое корректно прошло процедуру присоединения к домену. Эта процедура требует двух вещей: входа в Google-аккаунт и ввода ПИН-кода от менеджера паролей Google.

Важно понимать масштаб: пакет синхронизации (sync-payload) включает не только пароли, но и приватные байты ключей доступа. Начиная с Chrome 359, они записываются в локальную базу данных SQLite и синхронизируются вместе со всем хранилищем, включая ключи, изначально созданные на аппаратном устройстве. VaultJacking восстанавливает их в том числе.

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

Цепочка атаки: модель четырёх шагов VaultJacking

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

Шаг 1. Фишинговая страница

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

Шаг 2. Перехват ПИН-кода и регистрация скрытого ключа

Сразу после ввода пароля пользователю показывают модальное окно с запросом ПИН-кода от Google Password Manager. Окно стилизовано под стандартный интерфейс Google.

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

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

Шаг 3. Присоединение к домену безопасности

Атакующий использует перехваченные сессионные куки и ПИН-код для присоединения собственного устройства к домену безопасности (security domain) аккаунта Google.

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

После успешной аутентификации атакующий вводит перехваченный ПИН-код — облачный сервис Google выдаёт Security Domain Secret (SDS, секретный ключ домена безопасности). Единственный сигнал для жертвы — письмо на почту «новый вход на Windows», идентичное тому, что Google отправляет при любом новом входе в Chrome. Никаких пуш-уведомлений на мобильные устройства, никаких запросов на других запущенных копиях браузера. Если атакующий перехватил почтовый ящик в ходе той же AiTM-сессии — письмо подавляется прежде, чем пользователь его увидит.

Шаг 4. Расшифровка хранилища

Получив SDS, устройство атакующего расшифровывает всё синхронизированное хранилище целиком: пароли, ключи доступа (passkeys), сохранённые данные форм. Никаких дополнительных запросов к пользователю, никаких ограничений по количеству попыток (rate limit).

Пакет синхронизации (sync-payload) включает приватные байты всех ключей доступа — в том числе тех, что изначально создавались на аппаратных аутентификаторах. Начиная с Chrome 359, эти байты записываются в локальную базу данных SQLite браузера и передаются вместе с остальными данными синхронизации. Аппаратная защита работает на уровне создания ключа, но не на уровне синхронизации хранилища.

Результат: каскадная компрометация

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

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

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

Почему ПИН может стать проблемой

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

С точки зрения модели безопасности Google, ПИН-код — это единственный короткий секрет, который управляет доступом к Security Domain Secret. Именно он позволяет новому устройству расшифровать всё синхронизированный хранилище. Шесть цифр защищают всё, что пользователь когда-либо сохранил в Google Password Manager.

Проблема усугубляется тремя факторами:

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

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

Защищают ли ключи доступа от VaultJacking

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

Однако VaultJacking атакует другой уровень: не вход на конкретный сайт, а синхронизацию хранилища, где ключи доступа хранятся и управляются. Если атакующий получил доступ к Security Domain Secret, он получает и все синхронизированные ключи.

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

Чем VaultJacking опасен для бизнеса

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

Российские данные подтверждают масштаб угрозы. По данным Лаборатории Касперского, в 2025 году система «Антифишинг» предотвратила 554 002 207 попыток перехода по фишинговым ссылкам. По данным Yandex B2B Tech, 54% кибератак в 2025 году начинались с использования слитых или скомпрометированных паролей, а в облачных инфраструктурах было зафиксировано 25 тысяч попыток взлома (Anti-Malware.ru, 2025). ГК «Солар» в отчёте Solar JSOC за 2025 год зафиксировала более 1,16 млн событий ИБ и свыше 33 тысяч подтверждённых инцидентов — среди которых кража учётных данных выделена как отдельная подкатегория несанкционированного доступа.

Особую роль здесь играет феномен «теневого ИТ» (Shadow IT) в управлении паролями: сотрудники используют личные браузерные профили для рабочих задач не из злого умысла, а из удобства. У компании при этом нет ни видимости, ни контроля над тем, какие рабочие секреты там хранятся.

Матрица корпоративных рисков браузерного хранилища

Как защититься пользователю

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

Превентивные меры

• Проверяйте домен и контекст перед вводом ПИН-кода. Запрос ПИН-кода от менеджера паролей Google на сторонних сайтах — тревожный сигнал.
• Никогда не вводите ПИН на страницах, открытых по ссылке из письма или мессенджера.
• Включите двухфакторную аутентификацию (2FA) для аккаунта Google с аппаратным ключом или приложением-аутентификатором, не по SMS.
• Регулярно проверяйте список устройств в настройках Google-аккаунта: раздел Безопасность → Ваши устройства. Незнакомое устройство — повод немедленно отозвать доступ.
• Включите уведомления о новых входах в аккаунт.

Разграничение личного и рабочего

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

Что делать, если ПИН уже введён на подозрительном сайте

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

Что должны сделать компании

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

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

• Политика хранения рабочих паролей. Запрет хранения рабочих учётных данных в личных браузерных профилях фиксируется в регламенте ИБ.
• Корпоративный менеджер паролей. Рабочие секреты отделяются от личного браузерного профиля и хранятся в управляемой инфраструктуре.
• Ролевая модель доступа. Сотрудник видит только те секреты, которые нужны для работы — принцип минимальных привилегий.
• Журналирование и аудит. ИБ-команда получает полную видимость действий с паролями: кто, когда, что изменил или скопировал.
• Интеграция с AD/LDAP и SSO. Упрощается управление жизненным циклом учётных записей: приём, перевод, увольнение.
• Отзыв доступа при увольнении. Администратор удаляет учётную запись один раз — доступ отзывается из всех хранилищ автоматически.
• Интеграция с SIEM (система управления событиями безопасности). События по паролям становятся частью мониторинга ИБ и коррелируются с другими инцидентами.

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

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

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

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

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

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

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

Пассворк поддерживает хранение данных на сервере заказчика, шифрование по AES-256, интеграцию с Active Directory / LDAP, авторизацию через SSO, ролевую модель, журнал действий, интеграцию с SIEM-системами, API и CLI для DevOps-задач.

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

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

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

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

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

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

Что такое VaultJacking?

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

Правда ли, что можно украсть все пароли из Google Password Manager за одну атаку?

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

VaultJacking — это уязвимость Google или фишинговая техника?

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

Почему ключи доступа (passkey) не решают проблему полностью?

Ключи доступа защищают вход на конкретный сайт: WebAuthn-привязка к домену не позволяет передать учётные данные на поддельный сайт. Однако VaultJacking атакует уровень синхронизации хранилища, где ключи доступа хранятся и управляются. Компрометация Security Domain Secret даёт доступ к самим ключам.

Нужно ли исключить использование менеджера паролей Google?

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

Что делать, если я ввёл ПИН-код на подозрительном сайте?

Действуйте немедленно: смените пароль Google-аккаунта, проверьте и удалите незнакомые устройства и ключи доступа в настройках безопасности, отзовите активные сессии, смените пароли от критичных сервисов. Если в хранилище были рабочие учётные данные — уведомите ИБ-команду.

Как компания может снизить риск VaultJacking?

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

Как Пассворк защищает от VaultJacking?

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

По данным Verizon DBIR 2025, компрометация учётных данных и фишинг остаются ведущими векторами атак. Kaspersky фиксирует рост атак, связанных с кражей паролей, на 21% с 2023 по 2024 год и особо отмечает, что браузеры часто становятся источником утечек сохранённых учётных данных.

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

По данным РКН, с января по май 2025 года в России зафиксировано 30 утечек персональных данных и более 38 млн скомпрометированных записей. С 30 мая 2025 года в России действуют повышенные штрафы за нарушения в сфере персональных данных: согласно поправкам, введённым Федеральным законом № 420-ФЗ, за неуведомление об утечке компаниям и ИП грозит штраф от 1 до 3 млн рублей, а за повторную утечку — оборотный штраф в размере 1–3% годовой выручки (КонсультантПлюс).

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

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

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

Почему это важно для бизнеса

• Централизованное хранение. Все пароли и секреты находятся в одном защищённом хранилище — снижение рисков их случайного раскрытия.
• Контроль доступа через роли. Администратор назначает каждому сотруднику роль, и тот видит только те пароли, которые нужны для работы. Права выдаются точечно, а не по принципу «дадим всем, чтобы не спрашивали».
• Контроль доступа. Можно точно определить, кто и к чему имеет доступ, и выдавать права по необходимости — уменьшение вероятности злоупотреблений и ошибок.
• Аудит действий. Все обращения к паролям фиксируются: видно, кто, когда и какой доступ использовал — упрощение контроля и расследования инцидентов.
• Управление подрядчиками и внешними исполнителями. Фрилансер, агентство или интегратор получают доступ только к тем ресурсам, которые нужны для конкретной задачи через отдельную группу с ограниченными правами. Когда работа завершена, доступ отзывается в один клик.
• Быстрая смена и отзыв доступов. Пароли можно оперативно менять и отзывать при увольнении сотрудников или подозрении на компрометацию.
• Интеграция с инфраструктурой. Пароли и секреты можно использовать в сервисах и системах без их хранения в открытом виде — через безопасные механизмы доступа.

В итоге компания имеет управляемую систему доступа.

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

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

Что он даёт на практике:

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

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

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

Какие функции менеджера паролей обязательны для малого бизнеса

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

Минимальный набор

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

С чего начать: аудит доступов перед внедрением

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

Чек-лист аудита доступов

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

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

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

Таблица выбора решения по сценарию

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

• Локальная версия устанавливается на серверы компании и работает без постоянного интернет-соединения. Подходит, когда данные должны оставаться внутри инфраструктуры — например, при требованиях регуляторов или политике импортозамещения.
• Пассворк Облако — облачная версия на базе Яндекс Облака. Не требует собственного сервера и администрирования инфраструктуры: достаточно зарегистрироваться и начать работу. Функциональность идентична локальной версии.

Оба варианта шифруют данные по алгоритму AES-256 и построены по принципу архитектуры нулевого разглашения с шифрованием на клиенте. Продукт включён в реестр отечественного ПО.

Как внедрить менеджер паролей за 1–2 недели

Внедрение не требует отдельного ИБ-проекта. Достаточно последовательно пройти восемь шагов — от аудита до регламента. Начинать стоит с критичных доступов, а не с полной миграции сразу.

1. День 1–2. Аудит критичных сервисов. Составьте список: почта, банк, CRM, сайт, маркетплейсы, рекламные кабинеты, бухгалтерия, финансы. Для каждого — владелец, текущие пользователи, где хранится пароль, включена ли двухфакторная аутентификация. Результат: список доступов, владельцев и рисков.
2. День 3. Выбор решения и назначение администратора. Определите модель: облако или локальная установка. Назначьте одного ответственного — он будет управлять структурой хранилищ и правами. Результат: понятна модель и есть ответственный.
3. День 4. Структура хранилищ и групп. Создайте папки по отделам или функциям: финансы, продажи, маркетинг, ИТ, подрядчики. Настройте роли: «администратор», «руководитель», «сотрудник», «подрядчик». Результат: доступы разделены по отделам и критичности.
4. День 5–6. Перенос критичных паролей. Начните с самых важных аккаунтов. Сгенерируйте новые уникальные пароли для каждого сервиса — не переносите старые слабые пароли как есть. Результат: критичные учётные записи защищены первыми.
5. День 7. Включение MFA. Активируйте двухфакторную аутентификацию (2FA/MFA) для администраторов и критичных сервисов. Украденный пароль без второго фактора теряет ценность для атакующего. Результат: украденный пароль сам по себе становится менее опасным.
6. День 8–10. Перенос остальных доступов. Переносите рабочие пароли поэтапно. Параллельно удаляйте пароли из таблиц, чатов и браузеров. Результат: хаотичные каналы хранения закрываются.
7. День 11–12. Обучение сотрудников. Проведите короткий инструктаж: как пользоваться хранилищем, почему нельзя пересылать пароли в чатах, что делать при подозрении на компрометацию. Результат: команда понимает правила работы.
8. День 13–14. Утверждение регламента. Зафиксируйте порядок выдачи и отзыва доступов, правила для подрядчиков и процедуру офбординга. Результат: процесс становится повторяемым.

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

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

Правила работы сотрудников: парольная политика

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

Шаблон парольной политики для малого бизнеса (8 правил)

1. Уникальность. Для каждого сервиса — отдельный пароль, сгенерированный менеджером паролей.
2. Запрет пересылки. Пароли нельзя отправлять в мессенджерах, по почте и в личных заметках.
3. Многофакторная аутентификация. Для почты, банка, финансов, администраторских аккаунтов и самого менеджера паролей — обязательна 2FA/MFA.
4. Владельцы. У каждого критичного доступа есть ответственный: руководитель или назначенный сотрудник.
5. Подрядчики. Подрядчики получают минимально необходимый и временный доступ — через отдельную группу.
6. Увольнение. В день увольнения доступы отзываются, критичные пароли меняются, журнал проверяется.
7. Ревизия. Раз в месяц — проверка пользователей и групп: кто есть, кого уже не должно быть.
8. Инциденты. Потеря устройства, подозрение на фишинг или раскрытие пароля — немедленно сообщается ответственному.

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

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

Чек-лист офбординга «6 шагов»

Ошибки при внедрении менеджера паролей

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

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

Вывод: первый шаг к управляемой защите данных

Менеджер паролей не делает бизнес неуязвимым — он закрывает один из самых частых и управляемых источников риска: хаотичное обращение с учётными данными. Positive Technologies прогнозирует рост успешных кибератак в России на 20–45% по итогам 2025 года и ещё на 30–35% в 2026-м. Ждать инцидента, чтобы навести порядок в доступах, — дорогостоящая стратегия.

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

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

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

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

Нужен ли менеджер паролей компании из 5 человек?

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

Можно ли хранить рабочие пароли в браузере?

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

Что важнее: сложный пароль или двухфакторная аутентификация?

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

Облачный менеджер паролей безопасен?

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

Когда нужен локальный менеджер паролей?

Локальный вариант стоит рассматривать при строгих требованиях к инфраструктуре, наличии ИТ-администратора, необходимости интеграции с AD/LDAP или внутренней политике хранения данных на собственных серверах. Также актуален при требованиях импортозамещения и работе с государственными заказчиками.

Как перенести пароли из Excel?

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

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

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

Менеджер паролей заменяет политику информационной безопасности?

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

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

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

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

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

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

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

28 млн утечек секретов: отчёт GitGuardian 2026, статистика и примеры атак | Пассворк

28,65 млн новых утечек секретов в 2025 году — рост на 34%. Разбор отчёта GitGuardian: как ИИ ускоряет утечки в 5 раз, почему 64% секретов остаются действующими годами и что делать. Реальные примеры атак и стратегия защиты.

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ФСТЭК

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До инцидента

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

Изолируйте поражённые системы от сети, не выключая питание. Зафиксируйте время и симптомы инцидента. Смените пароли привилегированных учётных записей с незатронутого устройства. Уведомьте ответственную команду по резервному каналу связи. Не трогайте подозрительные файлы до начала форензики.

Как понять, что атака завершена и можно восстанавливаться?

Убедитесь, что все точки закрепления атакующего найдены и удалены, уязвимость, через которую произошло проникновение, закрыта, скомпрометированные учётные записи заблокированы или сброшены, а мониторинг не фиксирует новой подозрительной активности. Восстанавливайте только из бэкапа, созданного до момента компрометации.

Нужно ли уведомлять регуляторов при кибератаке?

Зависит от типа инцидента и статуса организации. Субъекты КИИ обязаны уведомить ФСБ (через НКЦКИ) в течение 24 часов по 187-ФЗ. При утечке персональных данных — уведомить Роскомнадзор в течение 24 часов с момента обнаружения (152-ФЗ, статья 21). Рекомендуется заранее подготовить шаблоны уведомлений и согласовать их с юристом.

Что такое ГосСОПКА и кто обязан туда сообщать?

ГосСОПКА — Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак. Уведомлять НКЦКИ обязаны субъекты критической информационной инфраструктуры: организации из сфер энергетики, финансов, здравоохранения, транспорта и ряда других.

Как восстановить системы после атаки шифровальщика?

Восстановление начинается только после полной очистки инфраструктуры от ВПО и закрытия уязвимости, через которую произошло проникновение. Разворачивайте системы из резервных копий с верифицированной датой, предшествующей компрометации. Поэтапный ввод в эксплуатацию с усиленным мониторингом — минимум 30 дней после восстановления.

Нужно ли сообщать клиентам о взломе?

Да — особенно если затронуты их персональные данные. Это требование закона и вопрос репутации: по данным Сбербанка, каждая четвёртая атакованная компания понесла существенные репутационные потери (ВЭФ-2025). Сообщение от компании должно выйти раньше, чем информация появится из других источников.

Как защититься от атак через подрядчиков?

Для каждого подрядчика создавайте отдельную учётную запись, без общих логинов. Доступ выдавайте только к тем системам, которые нужны для конкретной задачи, и только на период её выполнения. Все действия подрядчика фиксируйте в журнале. Как только работы завершены, доступ отзывается немедленно.

Хэширование паролей: соль, перец и выбор алгоритма

Шифрование, хэширование, соль и перец — в чём разница, как каждый метод защищает пароли и почему выбор архитектуры хранения определяет, станет ли утечка базы данных инцидентом или катастрофой.

Блог ПассворкаАнастасия Лебедева

Приказ ФСТЭК № 117: разбор изменений, Кзи и штрафов

С 1 марта 2026 года Приказ ФСТЭК № 17 утратил силу. Его заменил Приказ № 117 с числовыми метриками КЗИ и ПЗИ, жёсткими сроками устранения уязвимостей и расширенной зоной ответственности. В статье рассмотрим, что изменилось и как подготовиться.

Блог ПассворкаИлья Шелыгин

Киберугрозы марта 2026: инциденты, штрафы и защита данных

Первые оборотные штрафы за утечки. Zero-click уязвимость в Telegram. Каскадная атака через Trivy. Шифровальщик в европейском порту. Новые требования ФСТЭК и КИИ. В статье — разбор ключевых инцидентов, изменений в законодательстве и конкретных шагов по защите корпоративных доступов.

Блог ПассворкаАнастасия Лебедева