«Петрович-Тех» — аккредитованная ИТ-компания и основной цифровой партнёр СТД «Петрович», одного из крупнейших DIY-ритейлеров России. Интернет-магазин «Петровича» входит в топ крупнейших в стране и ежемесячно обслуживает более шести миллионов посетителей.

«Петрович» работает на рынке с 1995 года в сегментах B2C и B2B: от розничных покупателей до крупных девелоперов. Компания закрывает полный цикл: продажи, хранение, кредитование и сопровождение проектов любого масштаба. Такой охват требует зрелой и устойчивой цифровой инфраструктуры.

«Петрович-Тех» основана в 2022 году на базе ИТ-департамента «Петровича». Сегодня это 300+ специалистов в 14 отделах: высоконагруженные системы электронной коммерции, микросервисная архитектура, машинное обучение и анализ данных, автоматизация процессов и поддержка всей ИТ-инфраструктуры бизнеса.

Задача: выстроить управляемую модель доступа

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

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

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

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

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

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

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

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

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

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

Сотрудников знакомили с Пассворком постепенно: провели внутреннюю презентацию и объяснили, как работать с новой системой.

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

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

Внутренняя политика: цифровая грамотность как часть ИБ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 2025 году Россия заняла второе место в мире по количеству ставших известными утечек данных. Глобально количество утечек из банков и финансовых организаций сократилось на 44,7%, однако в России выросло в 1,5 раза. По данным отчёта InfoWatch, эта тревожная тенденция подчёркивает, что отечественный финансовый сектор остаётся приоритетной целью для киберпреступников.

Разница видна и в природе инцидентов. В мире на внутренних нарушителей приходится 4,5% утечек в финансовом секторе — в России эта доля почти втрое выше и составляет около 16%. Схожая картина по содержимому утекших данных: более 13% утечек в мире и около 10% в России содержат аутентификационную информацию: логины, пароли и ключи доступа.

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

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

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

Главное об управлении секретами в финансовом секторе

• В 2025 году Россия заняла второе место в мире по числу известных утечек данных: количество инцидентов в финансовом секторе выросло в 1,5 раза, тогда как глобально сократилось на 44,7%.
• В российском финансовом секторе на внутренних нарушителей приходится около 16% утечек — почти втрое больше среднемирового показателя (4,5%), что делает контроль доступа сотрудников критичным.
• Управление секретами контролирует машинные учётные данные: API-ключи, токены, сертификаты, — тогда как менеджер паролей отвечает за доступ сотрудников к ресурсам. Финансовым организациям нужны оба контура.
• Инфраструктура банка объединяет десятки систем (процессинг, CRM, платёжные шлюзы), и каждая связь защищена отдельным ключом. Один забытый API-ключ платёжного шлюза способен открыть доступ к базе транзакций целиком.
• Неконтролируемое распространение секретов — бесконтрольное распространение секретов по репозиториям, конфигурациям и мессенджерам — превращает забытый ключ в системный риск: 64% секретов, утёкших в 2022 году, остаются действующими в 2026-м.
• Радиус поражения одного скомпрометированного ключа в банковской инфраструктуре может охватить всю цепочку обработки транзакций — от проверки баланса до персональных данных клиентов.
• С 30 мая 2025 года повторное нарушение в обработке персональных данных грозит штрафом до 3% годовой выручки — до 500 млн рублей, что делает управление секретами не только вопросом безопасности, но и финансовым риском.

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

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

Разница в архитектуре:

• Менеджер паролей встраивается в рабочий процесс человека: браузерное расширение, мобильное приложение, единое хранилище для команды.
• Система управления секретами встраивается в инфраструктуру: API, CI/CD-пайплайн, оркестратор контейнеров. Она должна выдавать секрет сервису за миллисекунды, без участия человека, и автоматически менять его по расписанию.

Сравнение менеджера паролей и системы управления секретами:

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

Пассворк объединяет управление паролями сотрудников и машинными секретами в одной экосистеме — с общим журналом аудита, едиными правами доступа и API для интеграции с CI/CD. Пассворк включён в реестр отчественного ПО и сертифицирован ФСТЭК. Протестировать можно бесплатно.

Почему финансовый сектор — главная мишень

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

Отраслевая аналитика детализирует, откуда берутся эти уязвимости:

• Рост утечек. В 2025 году число утечек данных из российских финансовых организаций достигло 44 — против 29 годом ранее. Рост на 52% за год (InfoWatch).
• Охота за данными. Каждый пятый инцидент в финансовом секторе — попытка получить доступ к конфиденциальной информации.
• Кража учётных данных. 15% инцидентов — прямая компрометация логинов и паролей сотрудников.
• Инструмент атак. Стилеры — вредоносное программное обеспечение (ВПО) для кражи паролей и токенов из браузеров и приложений — используются в 41% всех атак с применением ВПО на кредитно-финансовую отрасль (Солар, отчёт о кибератаках на кредитно-финансовую отрасль).

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

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

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

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

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

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

Масштаб проблемы подтверждают международные данные. По данным отчёта GitGuardian State of Secrets Sprawl (2025), более 90% секретов, случайно опубликованных в публичных репозиториях, остаются валидными и пригодными для использования спустя 5 дней после утечки. Это означает, что даже обнаруженная утечка секрета не гарантирует его немедленной нейтрализации, если процесс отзыва не автоматизирован.

Мировая статистика утечек секретов: отчёт GitGuardian за 2026 год

Для финансовой организации неконтролируемое распространение секретов (secrets sprawl) означает, что каждый репозиторий, каждый CI/CD-пайплайн и каждая переменная окружения — потенциальная точка утечки, независимо от того, насколько защищён периметр. Централизованное хранилище — единственный способ вернуть контроль над рассредоточенными данными.

Жизненный цикл секрета: где возникают уязвимости

Жизненный цикл секрета — это последовательность из семи этапов, от генерации до уничтожения, на каждом из которых секрет может быть скомпрометирован. Понимание этой последовательности показывает, что защита секрета — это процесс, требующий контроля на каждой стадии, а не только в момент хранения. Такой подход к классификации этапов описывает, в частности, OWASP Secrets Management Cheat Sheet.

7 этапов жизненного цикла секрета:

• Генерация. Создание секрета с достаточной энтропией. Слабый или предсказуемый ключ компрометируется ещё до первого использования.
• Хранение. Размещение в централизованном зашифрованном хранилище, а не в открытом файле или переменной окружения без контроля доступа.
• Распределение. Передача секрета сервису или сотруднику только через защищённый канал: API вызов, а не сообщение в мессенджере.
• Контроль доступа. Привязка к идентичности рабочей нагрузки: сервис получает секрет на ограниченное время и только в контексте конкретного окружения (под, контейнер, задача в конвейере).
• Ротация. Плановая или экстренная смена секрета по расписанию либо сразу после подозрения на компрометацию.
• Отзыв. Немедленная инвалидация скомпрометированного секрета без ожидания планового цикла ротации.
• Уничтожение. Безвозвратное удаление секрета после истечения срока действия или завершения его использования.

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

Финансовая организация в условиях кадрового дефицита на рынке ИТ (за 2025 год штат ИТ-специалистов в России вырос на 15,4%, но нехватка кадров всё ещё оценивается в миллионах) активно привлекает подрядчиков и внешних разработчиков. Без автоматизации ротации отзыв доступа при завершении контракта требует ручной проверки всех систем, в которых подрядчик мог оставить след.

Радиус поражения: что происходит, когда один секрет скомпрометирован

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

Рассмотрим типичный сценарий:

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

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

• Принцип минимальных привилегий. Каждый сервис получает доступ только к тем ресурсам, которые нужны для его конкретной функции, а не ко всей базе данных.
• Регулярная ротация секретов. Короткий срок жизни ключа сокращает окно для атаки. API-токены сервисных аккаунтов в Пассворке можно ротировать через пары access- и refresh-токенов.
• Изоляция секретов друг от друга. Компрометация одного секрета не открывает доступ к остальным. В Пассворке каждый пароль и сейф получают собственный ключ шифрования, вложенные друг в друга по цепочке: ключ пароля → ключ сейфа → приватный ключ пользователя.
• Точечный отзыв без цепной реакции. Администратор аннулирует конкретный секрет, не трогая остальные учётные данные. Сервисные аккаунты Пассворка поддерживают несколько API-токенов — можно отозвать один, не нарушив работу остальных пайплайнов.
• Журнал доступа. Аномалия видна сразу, а не через неделю в постмортеме. Журнал действий Пассворка фиксирует каждое обращение к сейфам и паролям, с экспортом в SIEM для встраивания в существующий мониторинг.

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

Регуляторные требования РФ: что обязан выполнить финансовый сектор

Регулятор в лице Центрального банка и ФСТЭК России предъявляет к финансовым организациям конкретные требования по контролю доступа к учётным данным, которые напрямую касаются управления секретами. Основные документы — ГОСТ Р 57580.1-2017, Положение ЦБ РФ № 851-П и Приказ ФСТЭК России № 21, каждый из которых регулирует свой аспект защиты.

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

Что требует каждый документ

ГОСТ Р 57580.1-2017 обязывает выстраивать защиту по одному из трёх уровней (минимальному, стандартному или усиленному) в зависимости от значимости системы. Контроль доступа к учётным данным входит в базовый набор мер для каждого уровня без исключений.

Положение ЦБ РФ № 851-П действует с 29 марта 2025 года — оно заменило ранее действовавшее Положение № 683-П и усилило требования к защите банковской информации, включая порядок применения сертифицированных средств криптографической защиты (СКЗИ).

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

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

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

Финансовые последствия несоблюдения

С 30 мая 2025 года в России действуют оборотные штрафы за нарушения в сфере обработки персональных данных. За повторное нарушение штраф для юридических лиц составляет от 1 до 3% годовой выручки — не менее 20 млн и не более 500 млн рублей.

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

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

• Централизуйте хранение. Замените файлы .env, таблицы Excel и заметки на единое зашифрованное хранилище секретов с контролем доступа. Это первый шаг, который сразу закрывает большую часть проблемы неконтролируемого распространения секретов.
• Автоматизируйте ротацию. Настройте плановую смену секретов по расписанию и немедленную ротацию при подозрении на компрометацию — без ручного вмешательства администратора в каждом отдельном случае.
• Внедрите принцип минимальных привилегий. Каждый сервис и каждый сотрудник должны видеть только те секреты, которые нужны для их конкретной задачи, — это напрямую ограничивает радиус поражения при инциденте.
• Ведите полный аудит. Фиксируйте, кто, когда и откуда обращался к каждому секрету. Журнал аудита — то, что превращает расследование инцидента из недель в часы.
• Интегрируйте управление секретами в DevSecOps. Секреты не должны попадать в код и конфигурации CI/CD — используйте API для их динамической выдачи прямо в момент сборки или деплоя.

Для финансовых организаций, эти пять практик реализует Пассворк — система, включённая в реестр отечественного ПО (№ 6147) и сертифицированная ФСТЭК России. Открытый полнофункциональный API позволяет встроить хранилище в CI/CD-пайплайн и получать секреты программно, без ручной передачи ключей между разработчиками.

Заключение

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

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

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

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

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

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

Частые вопросы об управлении секретами в финансовом секторе

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

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

Что такое неконтролируемое распространение секретов (secrets sprawl)?

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

Какие этапы жизненного цикла секрета наиболее уязвимы?

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

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

По данным отчёта GitGuardian State of Secrets Sprawl (2025), более 90% секретов, случайно опубликованных в публичных репозиториях, остаются валидными спустя пять дней после утечки. Без автоматического отзыва обнаружение инцидента не гарантирует нейтрализации риска — ключ продолжает работать, пока его не аннулируют вручную.

Что произойдёт, если один API-ключ банка будет скомпрометирован?

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

Нужно ли управление секретами небольшим финтех-компаниям?

Да. По данным InfoWatch (2026), рост утечек в 2025 году произошёл в том числе в небольших МФО и страховых компаниях. Злоумышленники нередко атакуют менее защищённые организации как промежуточную точку входа для последующей атаки на более крупных партнёров или клиентов.

Соответствует ли Пассворк требованиям российских регуляторов для финансового сектора?

Да. Пассворк включён в реестр отечественного ПО (№ 6147) и сертифицирован ФСТЭК России, что упрощает соответствие требованиям Приказа № 21 и Положения ЦБ РФ № 851-П. Продукт объединяет пароли сотрудников и машинные секреты в едином хранилище с журналом аудита и API для интеграции с CI/CD.

Интерактивная схема API: сравнение версий и готовые примеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое схема разделения секрета Шамира

Схема разделения секрета Шамира — это криптографический метод, при котором секрет (например, ключ шифрования) делится на $ N $ частей (долей) с порогом $ M $: любые $ M $ долей полностью восстанавливают секрет, а $ M − 1 $ долей не дают о нём вообще никакой информации, даже частичной. Метод предложил криптограф Ади Шамир в 1979 году в работе «How to Share a Secret» (Communications of the ACM).

Кому это нужно и зачем

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

Ниже каждая роль разобрана отдельно — с конкретными сценариями и ограничениями, которые важно знать заранее.

Главное преимущество: сегментация вместо единого ключа на всё

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

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

Что такое политика доступа к сейфам

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

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

Один контур восстановления, несколько или совсем без него

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

Практические сценарии

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

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

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

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

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

Для администраторов: понятная процедура вместо ручного разбора

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

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

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

1. Держатели расшифровывают свои доли личным RSA-ключом и передают их оператору.
2. Оператор собирает нужное количество долей и восстанавливает ключ учётной записи восстановления.
3. Через CLI Пассворка этой учётной записи выдаётся доступ уровня «Администратор» к нужному сейфу.
4. Восстановленный ключ и промежуточные файлы сразу удаляются.

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

Для ИБ-специалистов: контролируемый резервный контур

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

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

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

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

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

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

Чего ждать не стоит

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

• Нет визуального конструктора в интерфейсе. Настроить порог, раздать доли и провести восстановление можно только командами через CLI Пассворка — мастера в веб-интерфейсе для этого не предусмотрено. Понадобится сотрудник с навыками работы в командной строке.
• Кворум восстановления не отображается в продукте. Кто из держателей участвовал и когда — фиксируется во внешнем журнале, который ведёт оператор, а не в Журнале событий Пассворка.
• Замена одного держателя — это пересборка всего контура. Если один из держателей скомпрометирован или уволился, компания создаёт новую учётную запись восстановления и раздаёт новые доли всем держателям заново — точечно заменить одну долю нельзя.

С чего начать

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

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

Заключение

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

Вопросы о пороговом восстановлении

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

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

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

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

Что будет, если один из держателей потеряет свою долю?

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

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

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

Если скомпрометирован один контур восстановления, под угрозой все данные?

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

Видно ли восстановление доступа в Журнале событий?

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

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

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

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

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

Главное о менеджере паролей для госсектора за 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 — это потеря контроля над всей защитной инфраструктурой. Разбираем, когда достаточно одной инсталляции Пассворка, а когда нужен физически изолированный ИБ-контур.

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

21 июля 2026 года Минцифры вынесло на общественное обсуждение проект Доктрины развития системы противодействия правонарушениям, совершаемым с использованием информационно-коммуникационных технологий (ИКТ).

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

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

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

Главное о Доктрине Минцифры за 5 минут

• 21 июля 2026 года Минцифры вынесло на общественное обсуждение проект Доктрины развития системы противодействия ИКТ-правонарушениям — рамочный документ до 2035 года.
• Документ продолжает серию решений 2024–2026 годов: Концепции противодействия (декабрь 2024), законов «Антифрод» и «Антифрод 2.0», запуска ГИС «Антифрод» в марте 2026 года.
• Реализация разбита на три этапа: 2027–2028 — создание нормативной базы, 2029–2030 — внедрение механизмов, 2031–2035 — их развитие и донастройка.
• Центральный элемент архитектуры — Платформа, единая среда для обмена обезличенными сигналами о мошенниках между банками, операторами связи, цифровыми платформами и государством.
• Доктрина закладывает три сценария развития: базовый (достройка текущих механизмов), целевой (координация через жизненный цикл правонарушения) и опережающий — с переходом на криптографический цифровой токен вместо централизованных баз персональных данных.
• Для бизнеса документ вводит конкретные обязанности: плановый антифрод-аудит, оценку фрод-потенциала информационных систем и отраслевые стандарты защиты данных — особенно для высокорисковых отраслей.
• Отдельное направление — платформа согласий на базе ЕСИА: единая точка выдачи, хранения и отзыва согласий на обработку персональных данных.
• Документ пока в статусе проекта — Минцифры прямо указывает, что меры могут измениться по итогам общественного обсуждения.

Что такое Доктрина Минцифры и зачем она понадобилась

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

Документ опирается на пять действующих правовых актов:

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

«Несмотря на то, что по итогам 2025 года количество ИКТ-преступлений по отношению к 2024 году снизилось на 11,8 % (с 765,4 тыс. до 675,4 тыс.), обозначенная проблема остается актуальной, в том числе потому, что инструменты мошенников постоянно совершенствуются».

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

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

Как объяснил Российской газете заместитель Председателя Правительства Российской Федерации Дмитрий Григоренко:

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

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

Хронология: как государство выстраивало антифрод-систему

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

Три этапа реализации Доктрины Минцифры

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

• Этап I (2027–2028 годы). Организационно-подготовительные мероприятия: разработка и принятие нормативных правовых актов для реализации ключевых направлений Доктрины, апробация потенциальными участниками создаваемых технологий, утверждение методик расчёта целевых показателей и возможная корректировка сроков и масштаба отдельных мероприятий по итогам.
• Этап II (2029–2030 годы). Создание организационных и технологических основ для реализации задач Доктрины, поэтапное внедрение механизмов противодействия правонарушениям, совершаемым с использованием ИКТ.
• Этап III (2031–2035 годы). Развитие созданных механизмов и формирование предложений по их дальнейшему совершенствованию в рамках системы противодействия.

Доктрина продолжает курс, заложенный в Концепции государственной системы противодействия противоправным деяниям (распоряжение Правительства РФ № 4154-р), и в плане мероприятий по её реализации (распоряжение Правительства РФ № 2207-р).

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

Центральный элемент Доктрины: Платформа (ГИС)

С 1 марта 2026 года создана государственная информационная система противодействия правонарушениям с использованием ИКТ (в Доктрине указана, как «Платформа»). Согласно статье 1 Федерального закона № 41-ФЗ, она призвана обеспечить оперативное предоставление всем участникам взаимодействия (правоохранительным органам, уполномоченным органам исполнительной власти, Банку России, финансовым организациям, операторам связи и цифровым платформам) информации о попытках мошенничества для их блокировки и предотвращения.

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

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

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

«Задачи оперативного противодействия мошенничеству, совершаемому с использованием ИКТ, распределяются между участниками взаимодействия в рамках сценариев противодействия правонарушениям» (раздел II Доктрины Минцифры).

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

Основные термины Доктрины Минцифры

Доктрина вводит новую терминологию для описания антифрод-контура — от «антифрод-мер» и «цифрового следа» до «фрод-потенциала» и «механизма обратного отслеживания». Важнейшие из них:

Три термина стоит выделить отдельно:

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

Шесть системных вызовов, которые Доктрина Минцифры ставит в основу архитектуры

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

Непрерывный процесс развития

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

«Необходимость совершенствования нормативно-правового и кадрового обеспечения для эффективного и оперативного выявления, раскрытия и расследования преступлений, совершаемых с использованием ИКТ» (здесь и далее — раздел II Доктрины Минцифры).

Унификация

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

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

Фрагментация информационного пространства

Банки, операторы и платформы работают автономно, поэтому нужен переход «от автономной работы к согласованным действиям».

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

Временной разрыв реагирования

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

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

Централизация как риск

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

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

Избыточность персональных данных

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

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

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

Девять направлений реализации Доктрины Минцифры

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

1. Повышение эффективности правоохранительной и контрольной деятельности

Направление сосредоточено на инструментах и полномочиях правоохранительных органов для расследования ИКТ-преступлений.

• Создать и оснастить специализированные подразделения по ИКТ-правонарушениям современными техническими средствами
• Внедрить автоматизированные инструменты межведомственного взаимодействия, включая искусственный интеллект
• Совершенствовать меры для эффективного устранения обстоятельств, способствующие ИКТ-правонарушениям
• Усилить контрольно-надзорную деятельность за участниками цифровой среды
• Совершенствовать методы и способы выявления лиц, обеспечивающих техническую и финансовую инфраструктуру организованной преступности
• Криминализировать администрирование ресурсов (в том числе теневых), созданных для организации противоправной деятельности
• Усилить ответственность за посягательства на детей в сети Интернет, рассмотреть создание реестра нарушителей
• Совершенствовать КоАП РФ как первоочередное направление борьбы с преступностью в сфере ИКТ

2. Развитие кадрового потенциала и научное обеспечение противодействия

Направление закрывает дефицит квалифицированных специалистов для работы в антифрод-подразделениях.

• Разработать программы обучения для сотрудников антифрод-органов с привлечением экспертов из ИТ-компаний, банков, операторов связи и цифровых платформ
• Открыть в вузах профильные направления: информационная безопасность в юриспруденции, компьютерное право, цифровая криминалистика
• Внести специальность «антифрод-специалист» в Общероссийский классификатор специальностей по образованию, запустить национальную программу подготовки таких специалистов
• Обучать студентов и сотрудников органов власти, финансовых и иных организаций, задействованных в противодействии ИКТ-правонарушениям
• Обеспечить правоохранительные и надзорные органы штатными и материально-техническими ресурсами, закрепить в их структуре специализированные подразделения
• Развивать научно-исследовательские работы по методикам противодействия с участием Российской академии наук (РАН) и профильных ИТ-организаций

3. Развитие государственно-частного взаимодействия

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

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

4. Технологическое развитие и инфраструктура

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

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

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

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

5. Профилактика и взаимодействие с гражданами

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

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

6. Финансовое взаимодействие и возмещение ущерба

Направление регулирует распределение финансовой ответственности между банками, отправителями и получателями при мошеннических переводах

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

7. Обеспечение достоверности и защиты данных

Направление касается точности и защищённости данных в государственных информационных системах (ГИС) и Единой системе идентификации и аутентификации (ЕСИА).

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

8. Защита персональных данных

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

• Создать на базе ЕСИА платформу согласий — единый механизм выдачи, хранения и отзыва согласий на обработку персональных данных, определённых статьёй 9 Федерального закона № 152-ФЗ «О персональных данных»
• Сформировать правовые условия для сокращения случаев, когда операторы обрабатывают персональные данные на основании согласия
• Внедрить механизмы идентификации граждан организациями без передачи им персональных данных (в случаях, которые определит Правительство Российской Федерации)

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

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

9. Международное взаимодействие

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

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

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

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

1. Базовый сценарий

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

То есть: достраиваем то, что уже работает.

2. Целевой сценарий

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

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

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

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

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

3. Опережающий сценарий: цифровой токен

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

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

Доктрина фиксирует пять обязательных свойств ЦТ:

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

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

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

Что мешает реализации: пробелы нормативной базы

Раздел VI Доктрины прямо перечисляет семь неурегулированных вопросов действующего законодательства:

1. Нет механизма «обратного взыскания». Отсутствие правового механизма для реализации сервисов «обратного взыскания» похищенных средств
2. Нет критериев эффективности. Не формализовано, по каким показателям оценивать работу субъектов цифровой среды в борьбе с ИКТ-правонарушениями.
3. Нет адресной ответственности за данные. Участники информационного обмена не несут прямой ответственности за полноту, достоверность и скорость передачи данных.
4. Не проработана подготовка кадров. Комплексного регулирования по обучению профильных специалистов и системной профилактике правонарушений пока не существует.
5. Слабая база для этапа расследования — включает две проблемы сразу:
   • неэффективные механизмы борьбы с администрированием теневых цифровых ресурсов в анонимных сетях;
   • недоработанное регулирование процедур с цифровой валютой — изъятия, конфискации, обращения в доход государства, а также отсутствие однозначных оснований для квалификации операций с цифровой валютой как легализации (отмывания) преступных доходов.
6. Нет основы для государственно-частного взаимодействия. Не закреплено, как привлекать экспертов ИТ-компаний, ИБ-отрасли и банков к обучающим, экспертным и методическим мероприятиям.
7. Не определён формат правового просвещения. Особенности деятельности по правовому информированию населения в части противодействия ИКТ-правонарушениям не закреплены.

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

Кто и как реализует Доктрину Минцифры

За реализацию Доктрины отвечает Минцифры. Оно координирует работу МВД, ФСБ, Следственного комитета, Роскомнадзора, Генпрокуратуры, Банка России, регионов, а также банков, операторов связи и цифровых платформ.

Как устроена система на практике:

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

Что это значит для бизнеса

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

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

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

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

Часто задаваемые вопросы о Доктрине Минцифры по антифроду

Когда Доктрина Минцифры вступит в силу?

Доктрина — проект, опубликованный 21 июля 2026 года для общественного обсуждения. После утверждения указом президента она станет рамочным документом на период до 2035 года. Первый этап реализации — нормативная база и апробация технологий — запланирован на 2027–2028 годы.

Что такое антифрод-система?

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

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

Платформа — государственная информационная система, запущенная 1 марта 2026 года на основании Федерального закона № 41-ФЗ. Она синхронизирует антифрод-системы банков, операторов связи, цифровых платформ и госорганов через обмен обезличенными сигналами об атрибутах мошенников, а не персональными данными граждан.

Что такое цифровой токен и заменит ли он паспорт?

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

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

Доктрина Минцифры предполагает плановый антифрод-аудит и отраслевые стандарты в первую очередь для высокорисковых отраслей — финансов, связи, крупных цифровых платформ. Конкретный перечень отраслей и порядок аудита пока не закреплены нормативно и должны появиться на первом этапе Доктрины в 2027–2028 годах.

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

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

Придётся ли компаниям менять процессы работы с согласиями на обработку персональных данных?

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

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

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

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

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

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

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

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

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

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

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

Главное

• Полноценный справочник по API Пассворка. Инструмент поддерживает поиск, отображает дерево схем и сравнивает версии API.
• Актуальные данные. Схема всегда содержит спецификации последних версий Пассворка с полным списком доступных путей и операций.
• Сравнение версий. Схема показывает удалённые и добавленные эндпоинты, изменения в структуре запросов и правки в документации.
• Каталог по разделам с поиском. Операции сгруппированы по частям API: сейфы, папки, записи, пользователи, LDAP и другие разделы.
• Готовые примеры кода. Значения из формы ввода сразу появляются в примере кода.
• История изменений по каждой операции. Вкладка История показывает, что менялось у выбранной параметра и пути между версиями API.
• Экспорт схемы для ИИ. Всю схему можно скопировать в формате JSON целиком для передачи ИИ-агенту или инструменту генерации кода.

Кому это нужно и зачем

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

Интерактивная схема помогает быстро найти ответы на рабочие вопросы по API:

1. Какой метод и путь использовать для конкретной задачи.
2. Какие поля передавать в теле запроса и что вернется в ответе.
3. Как сохранить совместимость текущих скриптов при обновлении Пассворка.
4. Как сформировать готовый код запроса для cURL, Python или консольной утилиты.
5. В каком формате придут данные: строгая JSON-модель, XML-документ или бинарный файл.
6. Как развивался конкретный метод и какие новые пути появились в свежем релизе.
7. Где взять машиночитаемую спецификацию для передачи контекста нейросетям или генерации кода.

Инструмент решает эти задачи без разворачивания тестового стенда и копирования тысяч строк JSON в редактор кода.

Возможности интерактивной схемы

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

Сравнение версий API Пассворка

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

Пример использования: вы планируете обновить Пассворк с версии 7.5 на 7.7. В методе POST /v1/vaults/create изменилось обязательное поле. Без предварительного сравнения схем интеграция сломается, и запросы начнут возвращать ошибку 422. Функция сравнения покажет это изменение заранее, без отправки реальных запросов к серверу.

Каталог операций

Слева на странице схемы расположен список операций с группировкой по тегам и строкой поиска. Пути отображаются кратко — префикс /v1 скрыт для удобства чтения. В верхней панели доступно переключение версий спецификации от 7.3.0 до 7.7.0.

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

Описание операции

В центре экрана находится документация выбранной операции:

• параметры пути, запроса и заголовков
• раскрываемое дерево структуры данных для тела запроса и ответов
• пример ответа

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

Готовые примеры кода

Справа расположена форма ввода параметров и панель генерации примеров для cURL, Python и CLI Пассворка.

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

История версий

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

Параметры для генерации примеров

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

Экспорт спецификации

В верхней панели доступна ссылка на исходный JSON-файл и кнопка копирования спецификации. Это удобно для передачи контекста в нейросети или автоматической генерации API-клиентов.

Порядок работы

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

Ограничения инструмента

Интерактивная схема работает как справочник и генератор примеров. Она не заменяет полноценный API-клиент.

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

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

Для настройки автоматизации изучите руководства по консольной утилите и управлению секретами.

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

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

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

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

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

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

Пассворк 7.6: сервисные аккаунты

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

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

Браузерные хранилища паролей — приоритетная цель инфостилеров: вредоносных программ, извлекающих учётные данные прямо из памяти процесса или локального хранилища браузера. По данным отчёта Flashpoint, в 2025 году инфостилеры заразили более 11,1 млн устройств и украли 3,3 млрд учётных записей, сессионных cookie-файлов и токенов.

Украденные учётные данные попадают на теневые форумы и перепродаются. Пароли и логины, похищенный сегодня, могут использоваться для атаки на компанию месяцы спустя. Итог такой цепочки: взлом корпоративной системы и остановка всего бизнеса — именно так завершались 75% успешных атак на российские компании в 2025–2026 годах, по данным Positive Technologies.

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

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

• Архитектурная уязвимость. Браузер хранит пароли и ключ для их расшифровки в одной папке на компьютере. Вредоносной программе не нужно взламывать шифрование — достаточно скопировать оба файла и открыть их тем же способом, что и сам браузер.
• Разница между браузерами непринципиальна. Chrome, Edge, Firefox и Safari защищены по-разному, но у всех ключ и данные находятся в общем контуре — устраняет это только изоляция хранилища паролей от остальной системы.
• Пароли не изолированы от остальных данных аккаунта. В одном хранилище браузера лежат история, карты, автозаполнение и пароли — доступ к профилю открывает всё сразу, а не только пароли.
• Защита браузера рано или поздно обходится. Даже механизмы вроде App-Bound Encryption в Chrome, привязывающие расшифровку к конкретному процессу, уже обходят инфостилеры типа VoidStealer через отладку процесса.
• ИИ снижает порог входа в киберпреступность. Исследователи зафиксировали случаи, когда рабочий код инфостилера создавался через обход ограничений языковой модели (LLM) без единой строки, написанной вручную.
• Защита паролей завязана на безопасность самого устройства. Браузер показывает сохранённые пароли после проверки входа в систему. Если устройство украдено, оставлено разблокированным или пароль системы слабый, доступ к паролям получить не сложнее, чем открыть вкладку настроек.
• Рабочая альтернатива — специализированный менеджер паролей. Архитектура нулевого знания изолирует пароли от остальной инфраструктуры устройства и делает саму технику атаки инфостилеров бесполезной.

Что такое браузерный менеджер паролей

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

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

Функция работает одинаково во всех основных браузерах, хотя реализация шифрования и синхронизации отличается:

• Chrome и Edge — сохранённые пароли привязаны к Google- или Microsoft-аккаунту, синхронизируются через облако вендора, шифруются с использованием системного хранилища учётных данных операционной системы.
• Firefox — данные шифруются локально, синхронизация происходит через аккаунт Firefox, опциональна дополнительная защита через Primary Password (мастер-пароль, который пользователь задаёт отдельно и должен вводить для доступа к сохранённым паролям браузера).
• Safari — пароли хранятся в iCloud Keychain с привязкой к Apple ID, шифрование использует аппаратную изоляцию на устройствах Apple.

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

Как браузеры хранят пароли

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

Почему архитектура устроена именно так

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

Гонка между защитой и обходом

Разработчики постоянно пытаются усилить защиту, но злоумышленники сразу находят способ её обойти. Например, Chrome добавил App-Bound Encryption — механизм, привязывающий расшифровку данных к конкретному процессу приложения на Windows. В ответ появился инфостилер VoidStealer, который обходит защиту менеджера паролей Google через отладку процесса Chrome: вредонос подключается к браузеру как debugger и извлекает ключ расшифровки напрямую, без повышения привилегий в системе.

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

Как это реализовано в разных браузерах

Итог одинаков для всех браузеров: хранение пароля и ключа шифрования в одном месте — системная уязвимость. Разница между Chrome, Edge, Firefox и Safari в том, насколько сложно эту уязвимость эксплуатировать, а не в том, устранена ли она в принципе.

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

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

Риски для персонального использования

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

Риски для бизнеса

1. Нет функции безопасного обмена паролями внутри команды. Чтобы поделиться доступом с коллегой, приходится отправлять пароль через почту или мессенджер открытым текстом.
2. Отсутствие административного контроля. ИТ- и ИБ-специалистам практически невозможно централизованно управлять паролями, разбросанными по личным браузерам сотрудников — нет эффективного способа быстро выдать или отозвать доступ при приёме и увольнении. Администратор не видит, кто и к каким сервисам имеет доступ, и не может обеспечить единую парольную политику.
3. Слабые защитные механизмы. Браузерные хранилища обычно не поддерживают многофакторную аутентификацию (MFA) и гибкую настройку прав доступа для разных ролей в команде — того минимума, который ожидают от инструмента для работы с корпоративными учётными данными.
4. Пароли — первая цель при заражении рабочего компьютера. Если на устройстве сотрудника окажется вирус, незашифрованные или слабо защищённые пароли из браузера — первое, за чем придёт вредоносное ПО. Для бизнеса это означает риск не одного аккаунта, а всей цепочки связанных с ним сервисов.
5. Нет журнала аудита. Компаниям для проверок безопасности и соответствия внутренним политикам нужны отчёты о том, кто и когда заходил в тот или иной сервис. Браузерный менеджер паролей такой возможности не даёт вообще.

Почему инфостилеры — главная угроза 2025–2026

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

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

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

По данным итогового отчёта Flashpoint за 2025 год, инфостилеры заразили более 11,1 млн устройств и украли 3,3 млрд учётных записей, сессионных cookie-файлов и токенов. Рост числа краж на 800% в первой половине 2025 года вылился в устойчивую тенденцию на весь 2025 год.

Проблему усугубляет поведение пользователей: 54% паролей, попавших в утечки в 2025 году, уже встречались в более ранних базах утечек (Лаборатория Касперского, 2025). Это говорит о массовом повторном использовании одних и тех же комбинаций на разных сервисах — один похищенный пароль открывает доступ сразу к нескольким аккаунтам жертвы.

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

Кража cookies обходит пароль и MFA

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

Признаки заражения

Заподозрить взлом аккаунта можно по нескольким сигналам:

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

Как инфостилер похищает данные из браузера

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

Шаг 1. Заражение устройства

Инфостилер попадает на устройство через один из типовых векторов:

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

Шаг 2. Доступ к профилю браузера

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

Шаг 3. Извлечение и расшифровка паролей

Инфостилер копирует базу паролей и файл с ключом шифрования, которые лежат рядом в одной папке (в Chrome — Login Data и Local State, в Firefox — logins.json и key4.db), и расшифровывает пароли, повторяя операцию, которую обычно выполняет сам браузер. Раз ключ и данные не разделены, взламывать ничего не нужно — достаточно скопировать файлы.

Шаг 4. Что ещё забирает инфостилер

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

Шаг 5. Отправка данных злоумышленнику

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

Шаг 6. Как злоумышленники используют украденные данные

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

Новый вектор: ИИ-инфостилеры атакуют браузерные хранилища

ИИ-инфостилер — вредоносная программа, код которой частично или полностью сгенерирован LLM через обход встроенных ограничений (LLM-джейлбрейк). В 2025 годe исследователи Cato Networks продемонстрировали, что такой код успешно компрометирует менеджер паролей Google в браузере Chrome.

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

Альтернатива браузерным менеджерам паролей

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

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

Разница в самой архитектуре защиты данных:

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

Как отказаться от хранения паролей в браузере

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

1. Экспортируйте пароли из браузера. Chrome, Firefox и Edge позволяют выгрузить сохранённые пароли в CSV-файл через настройки встроенного менеджера паролей — раздел Пароли → Экспорт паролей.
2. Импортируйте пароли в специализированный менеджер паролей. Большинство менеджеров паролей принимают CSV-файл напрямую и распределяют записи по папкам за один шаг. На этом этапе стоит сразу проверить дубликаты и слабые пароли.
3. Удалите пароли и CSV-файл из браузера. Очистите сохранённые пароли в настройках браузера и удалите экспортированный CSV-файл, включая копию в Корзине или облачном хранилище синхронизации. Пока файл существует хотя бы в одном месте, риск утечки не закрыт.
4. Настройте многофакторную аутентификацию. Включите MFA для самого менеджера паролей и для ключевых корпоративных сервисов. Это не отменяет риск кражи cookie-файлов, описанный выше, но закрывает основной сценарий: вход по украденному паролю без знания второго фактора.

На что обращать внимание при выборе менеджера паролей для бизнеса

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

Удобство для сотрудников

• Автозаполнение. Менеджер паролей должен подставлять логин и пароль в поля на сайтах без ручного копирования и вставки.
• Генератор паролей. Встроенный генератор создаёт случайные комбинации из спецсимволов, букв разного регистра и цифр — такие пароли невозможно подобрать по словарю или угадать по шаблону.
• Синхронизация между устройствами. Изменение пароля на одном устройстве должно отражаться на всех остальных.
• Поддержка всех платформ. Один и тот же менеджер паролей должен одинаково работать на Windows, macOS, Linux, Android и iOS.

Устойчивость к взлому

• Архитектура нулевого знания (Zero Knowledge). Никто, включая саму компанию-разработчика менеджера паролей, не может получить доступ к паролям пользователя в открытом виде. Шифрование и расшифровка происходят локально, на устройстве пользователя, а не на сервере.
• Надёжное шифрование. За хранением паролей должны стоять проверенные криптографические алгоритмы, которые гарантируют, чторасшифровать данные способен только владелец мастер-пароля. Отсутствие открытой информации об алгоритме шифрования — повод насторожиться.
• Многофакторная аутентификация (MFA). Вход в само хранилище паролей должен требовать не только мастер-пароль, но и дополнительный фактор — одноразовый код или аппаратный токен.

Контроль для администраторов

• Единый вход (SSO — Single Sign-On). Поддержка SSO позволяет сотрудникам заходить в менеджер паролей той же учётной записью, что и в остальные корпоративные сервисы — без отдельного пароля именно для хранилища.
• Инструменты администратора. Безопасная передача паролей внутри команды, мониторинг использования учётных данных и оповещения о подозрительной активности — обязательный набор для эффективного управления доступом в компании любого размера.

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

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

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

Заключение

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

Частые вопросы о безопасности паролей в браузере

Безопасно ли хранить пароли в браузере?

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

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

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

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

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

Защищает ли двухфакторная аутентификация от кражи cookie-файлов?

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

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

Да. Менеджер паролей Google в Chrome, а также Firefox и Edge поддерживают экспорт сохранённых паролей в CSV-файл через настройки менеджера паролей браузера. Файл импортируется в большинство менеджеров паролей за один шаг. После успешного импорта CSV-файл и пароли в браузере нужно удалить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Без такой системы ошибка одного сотрудника масштабируется до инцидента уровня всей компании. Эксперты Solar AURA ГК «Солар» изучили ИТ-инфраструктуру 10 российских компаний из рейтинга РБК 500 и нашли в теневых источниках в среднем более 600 уникальных корпоративных учётных записей на одну организацию. Больше половины из них с паролями в открытом виде. При этом признаки прямой компрометации инфраструктуры обнаружились лишь в 4% случаев: в основном речь идёт о том, что сотрудники использовали корпоративную почту и пароль на внешних интернет-ресурсах.

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

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

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

Что такое управление паролями и почему это не только про «сложный пароль»

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

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

Базовая система управления паролями должна отвечать минимум на пять вопросов:

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

Каждый вопрос закрывается набором механик:

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

Почему пароли — это проблема (и при чём здесь 30% россиян)

Слабые и повторно используемые пароли остаются главной точкой входа для атак на российские компании. По данным анализа утечек за 2025 год, 30% россиян используют всего 1–3 пароля для всех своих сервисов — личных и рабочих одновременно. Пароль, скомпрометированный на стороннем сервисе, с высокой вероятностью откроет доступ и к корпоративной системе.

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

• Слабое звено ИТ-инфраструктуры. Исследование Solar и DSEC называет слабые пароли и их повторное использование устойчивой практикой, которая сохраняется независимо от размера бизнеса. По данным за 2026 год, 47% респондентов используют один и тот же пароль для разных учётных записей — утечка из одного сервиса открывает злоумышленнику доступ к почте, соцсетям и корпоративным аккаунтам одновременно.
• Россия — в тройке самых атакуемых стран. По итогам 2025 года Россия вошла в тройку стран, наиболее подверженных кибератакам — такую оценку даёт Positive Technologies в отчёте за 2026 год. Компрометация учётных данных — один из основных векторов, наравне с фишингом.

Почему менеджер паролей — критический элемент безопасности компании

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

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

Менеджер паролей меняет экономику этого выбора — правильное поведение становится быстрее и проще неправильного:

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

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

Как централизованное управление паролями помогает бизнесу

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

Шесть конкретных задач, которые снимает централизация управления учётными данными с плеч ИТ-отдела и бизнеса в целом:

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

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

Какие киберугрозы снижает управление паролями

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

По данным Positive Technologies за первое полугодие 2025 года, в успешных атаках на организации шифровальщики использовались в 49% случаев, средства удалённого управления — в 33%, шпионское программное обеспечение — в 22%. Компрометация учётных данных остаётся типовым первым шагом атаки, который предшествует развёртыванию вредоносного ПО.

Как менеджер паролей шифрует, хранит и выдаёт учётные данные

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

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

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

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

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

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

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

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

Правила создания паролей: генератор, политика и контроль слабых мест

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

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

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

Кто создаёт и меняет пароли: владение записью и история версий

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

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

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

Где хранятся пароли: архитектура и структура хранилища

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

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

Организация хранилища построена в три уровня:

Тип сейфа определяет, кто получает к нему доступ и на каких условиях:

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

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

Как передаётся доступ: обмен без раскрытия значения пароля

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

1. Прямая передача. Пароль отправляется конкретному пользователю через раздел «Входящие» — получатель видит запись в своём интерфейсе. Удобно для передачи одной записи, когда постоянный доступ к целому сейфу не требуется.
2. Одноразовые ссылки. Ограниченный по времени доступ для получателя вне организации: подрядчика, аудитора, временного специалиста. Учётная запись в Пассворке не требуется, а ссылка перестаёт работать после истечения срока или использования.
3. Ярлыки. Ссылка на один и тот же пароль в разных сейфах без дублирования данных. Если пароль обновится в оригинальной карточке, все ярлыки на неё покажут актуальное значение.
4. Добавление в сейф или папку. Когда сотруднику нужен постоянный доступ не к одной записи, а ко всему набору паролей для работы, можно добавить его в общий или корпоративный сейф или папку. Пользователь получает доступ ко всем учётным данным внутри сразу, а при обновлении паролей в сейфе видит актуальные значения без повторной выдачи доступа.
5. Добавление в сейф, папку или группу. Когда сотруднику нужен постоянный доступ не к одной записи, а ко всему набору паролей, его добавляют в общий или корпоративный сейф — либо в группу, которая даёт доступ ко всем привязанным к ней сейфам сразу.

Кто и когда получал доступ: журнал аудита и интеграция с SIEM

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

Журнал не остаётся закрытым внутри интерфейса. Логи экспортируются в Syslog, Windows Event Viewer или напрямую в SIEM-систему — это позволяет службе безопасности видеть события Пассворка в общей картине мониторинга инфраструктуры, а не переключаться между разными консолями.

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

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

Ролевая модель и интеграции

Пять вопросов закрывают базовый уровень. Зрелая система идёт дальше — здесь в дело вступает ролевая модель доступа (RBAC, Role-Based Access Control, управление доступом на основе ролей), которая распределяет права через группы пользователей и настраиваемые роли.

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

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

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

• TOTP (Time-based One-Time Password) — одноразовые коды, совместимые с любым приложением-аутентификатором, работают без подключения к интернету.
• Собственное приложение Пассворк 2ФА — пуш-уведомления для подтверждения входа.
• Ключи доступа (Passkeys) — вход через Face ID, Touch ID, Windows Hello без ввода пароля.
• Биометрия — распознавание лица или отпечатка пальца как часть аутентификации через WebAuthn на поддерживаемых устройствах.
• Физические ключи безопасности — аппаратные токены через протокол WebAuthn.
• SSO через SAML — единый вход с поддержкой Yandex Identity Hub, ADFS, Okta, Azure AD, Keycloak, Google и других провайдеров идентификации.
• LDAP/AD-аутентификация — вход через доменную учётную запись Active Directory с синхронизацией групп.

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

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

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

1. Включите многофакторную аутентификацию для доступа к самому менеджеру паролей — это защищает хранилище даже при компрометации основного пароля пользователя.
2. Проверяйте панель безопасности не реже раза в месяц — устаревшие и слабые пароли накапливаются незаметно, если никто не смотрит на отчёт.
3. Используйте безопасный обмен вместо копирования пароля в чат — привычка пересылать доступ текстом формируется быстро и ломается только явным правилом.
4. Назначайте владельца для каждой общей записи — без ответственного пароль команды никто не обновляет вовремя.
5. Пересматривайте права доступа при смене роли сотрудника, а не только при увольнении — повышение или перевод в другой отдел часто оставляет старые права нетронутыми.
6. Синхронизируйте группы с Active Directory, если это возможно — это исключает ручную рассинхронизацию между системой учёта сотрудников и правами в менеджере паролей.
7. Установите браузерное расширение для автозаполнения на рабочие устройства сотрудников — оно вставляет пароль напрямую в поле ввода, минуя буфер обмена, и делает это только на легитимном домене, привязанном к записи. Расширение не предложит автозаполнение на фишинговой странице с похожим, но не совпадающим адресом.
8. Обучите сотрудников пользоваться поиском и тегами, а не создавать личные заметки в обход системы — удобство определяет, будет ли инструмент реально использоваться.

Пошаговый план внедрения: от аудита до масштабирования

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

1. Аудит текущего состояния. Выяснить, где сейчас хранятся корпоративные пароли (в файлах, чатах, головах сотрудников) и сколько учётных записей уже фигурирует в открытых утечках.
2. Выбор решения. Сопоставить критерии из предыдущего раздела с реальными требованиями компании — регуляторными, инфраструктурными, бюджетными.
3. Пилотный запуск. Внедрить решение в одном отделе — например, в команде из 5–10 человек. Это тестовая среда для выявления проблем настройки до перехода на всю компанию.
4. Настройка парольной политики. Определить требования к длине и сложности паролей, частоте смены, правилам для общих учётных записей.
5. Обучение сотрудников. Объяснить не только «как пользоваться», но и «почему это важно для компании» — сопротивление чаще возникает из непонимания, а не из вредности.
6. Полное развёртывание. Перенос всех отделов, интеграция с корпоративной системой идентификации через SSO и LDAP/AD.
7. Регулярный пересмотр. Пересматривать парольную политику и права доступа не реже раза в год или после каждого крупного изменения в штате.

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

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

Заключение

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

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

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

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

Что такое управление паролями?

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

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

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

В чём разница между облачным и локальным менеджером паролей?

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

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

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

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

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

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

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

Можно ли использовать менеджер паролей без интеграции с Active Directory?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как работает офлайн-доступ

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

1. Формирование списка. Пользователь отмечает нужные записи иконкой офлайна. Отмеченные записи попадают в общий список в разделе Офлайн, который синхронизируется между всеми устройствами пользователя. На этом этапе данные не сохраняются локально.
2. Сохранение на устройство. Пользователь открывает десктопное или мобильное приложение, переходит в раздел Офлайн и нажимает Включить на этом устройстве. Зашифрованные данные скачиваются в локальный кеш.

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

Безопасность и администрирование

Администраторам доступны гибкие ролевые настройки офлайн-доступа:

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

Аудит и контроль

Скачивание данных в локальный кеш фиксируется в Журнале событий и Панели безопасности:

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

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

Все офлайн-записи в сейфах и папках можно просмотреть в окне дополнительного доступа к директории.

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

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

Работа при потере связи

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

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

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

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

Главное об офлайне

• Где работает. Функция доступна в Расширенной версии Пассворка в мобильном и десктопном приложениях. Включать её нужно отдельно на каждом устройстве.
• Какие данные доступны. Без сети можно открыть только те пароли, которые вы заранее добавили в офлайн-список и синхронизировали.
• Только чтение. В автономном режиме записи можно только просматривать. Чтобы создать, изменить или удалить пароль, потребуется подключение к серверу.
• Настройки ролей. Администратор задает правила для пользователей: сколько записей разрешено сохранить на устройство и как долго они живут без синхронизации.

Сценарии использования офлайн-доступа

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

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

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

2. Защита от перебоев с интернетом

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

3. Аварийное восстановление

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

4. Выездные инженеры на удалённых объектах

• Ситуация: Инженеры обслуживают подстанции или серверные в регионах, где нет связи.
• Решение: Перед выездом сотрудник сохраняет в офлайн только нужные для работы пароли.
• Польза: Администратор ограничивает лимит записей (например, до 15) и срок жизни кеша (например, 24 часа). Если телефон или ноутбук сотрудника будет утерян, данные сотрутся. Все просмотры фиксируются локально и отправляются в Журнал событий при первом выходе в сеть.

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

• Добавили возможность отключать прикрепление файлов к записям на уровне организации
• Добавили столбец URL-адреса в разделах Недавние, Избранные и в результатах поиска
• Добавили столбец с родительской директорией в списке папок в результатах поиска
• Добавили консольную команду для обновления серверного ключа шифрования
• Добавили автоматическую активацию поисковой строки при вводе символов с клавиатуры
• Добавили серверное шифрование секрета 2ФА
• Заблокировали добавление ключей доступа и ключей безопасности WebAuthn при использовании Пассворка по IP-адресу или без HTTPS
• Добавили обязательную проверку протокола HTTPS для полей Login URL и Logout URL в настройках SSO
• Добавили блокировку пользовательских запросов на время обновления системы
• Добавили проверку наличия кеша перед обработкой веб-запросов

Исправления

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

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

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

Мобильное приложение 1.2.0

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

Подробнее об офлайн-доступе — в технической документации.
Вся информация о версиях Пассворка — в истории обновлений.

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

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

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

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

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

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

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

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

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