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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровень сети

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое RaaS?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное о менеджере паролей для госсектора за 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: новые требования, правила и примеры

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

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

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

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

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

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

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

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

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

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