Компания Пассворк и российский разработчик высокотехнологичных enterprise-решений Nexign («Нэксайн») подписали официальный сертификат совместимости менеджера паролей Пассворк и СУБД Nexign Nord.

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

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

Nexign Nord: СУБД для высоконагруженных систем

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

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

СУБД Nexign Nord обеспечивает импортозамещение Oracle Database, Microsoft SQL Server и предоставляется с технической поддержкой различных уровней. Продукт включён в Единый реестр российского программного обеспечения (реестровая запись №14734) и сертифицирован ФСТЭК России по 4-му уровню доверия.

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

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

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

Подтверждённая совместимость как основа для развития

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

«Сертификат совместимости с Nexign Nord — важный шаг для Пассворка. Nexign входит в число ведущих российских разработчиков enterprise-решений, и подтверждённая совместимость говорит о том, что наш продукт отвечает высоким корпоративным стандартам надёжности и безопасности», — Андрей Пьянков, генеральный директор ООО «Пассворк».

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

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

Пассворк регулярно тестирует совместимость с отечественными ИТ-продуктами и операционными системами. Посмотреть все актуальные сертификаты совместимости можно на этой странице.

О компании Nexign

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

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

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

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

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

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

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

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

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

ГОСТ-шифрование для разработчиков: алгоритмы, СКЗИ и интеграция 2026

ГОСТ-стек хорошо специфицирован — сложность в интеграции. Разбираем четыре актуальных стандарта с OID-ами, механику шифрования изнутри, типичные точки отказа в nginx, Docker и браузерах, классы СКЗИ и границы лицензирования ФСБ и ФСТЭК.

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

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

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

Главное

• Длина важнее состава. Надёжный пароль — длинный, случайный и уникальный для каждого сервиса. 16 случайных символов надёжнее, чем 8 с @ в конце.
• Онлайн-генератор безопасен только при локальной генерации. Пароль должен создаваться в браузере и не передаваться на сервер. Случайные сайты без информации о владельце — риск.
• Языковые модели не подходят для генерации паролей. Они предсказывают вероятные последовательности, а не создают криптографически случайные данные.
• Сильный пароль нужно проверять по базам утечек. Он мог быть скомпрометирован раньше, чем вы его придумали.
• Генератор создаёт, менеджер паролей хранит. Без хранилища сгенерированная комбинация окажется в заметках или таблице, что сводит на нет её преимущества.

Что такое генератор паролей

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

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

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

Как работает генератор паролей

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

1. Пользователь задаёт параметры. Длина пароля, типы символов (буквы, цифры, спецсимволы), исключения (например, символы 0, O, l, 1, которые легко перепутать).
2. Генератор обращается к источнику случайности. Надёжные реализации используют CSPRNG (криптографически стойкий генератор псевдослучайных чисел). Он опирается на энтропию операционной системы: случайные события — движение мыши, сетевые пакеты, прерывания процессора. Слабые реализации используют обычный PRNG (генератор псевдослучайных чисел), который инициализируется предсказуемым значением — например, временем запуска.
3. Алгоритм собирает комбинацию. Случайные значения отображаются на допустимые символы из выбранного набора. Если задано условие «обязательное наличие цифр и спецсимволов», алгоритм гарантирует их наличие.
4. Инструмент показывает пароль пользователю. Готовая комбинация отображается на экране. Пользователь может скопировать её или сразу использовать — в зависимости от того, куда встроен генератор.
5. Пользователь сохраняет пароль. Сгенерированный пароль нужно немедленно сохранить в менеджере паролей. Хранение в буфере обмена, заметках или таблицах сводит на нет преимущества сильной комбинации.

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

Какой пароль считается надёжным

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

Три реальных критерия надёжности:

• Длина. Каждый дополнительный символ экспоненциально увеличивает число возможных комбинаций. Пароль из 16 случайных символов перебрать значительно сложнее, чем из 8, даже если оба содержат спецсимволы.
• Случайность. Пароль не должен содержать словарных слов, имён, дат и шаблонов вида P@r0l. Такие комбинации первыми проверяются при атаках подстановкой (credential stuffing) и распылением паролей (password spraying).
• Уникальность. Один пароль — один сервис. Повторное использование превращает утечку одного ресурса в компрометацию всех остальных.

Дополнительный критерий — отсутствие в базах утечек. Даже длинный случайный пароль может оказаться скомпрометированным, если он уже фигурировал в утечках данных. Сервис Have I Been Pwned Pwned Passwords позволяет проверить пароль по базе известных утечек без передачи самого пароля в открытом виде.

Минимальная рекомендуемая длина для большинства сервисов — 12–16 символов. Для мастер-пароля менеджера паролей или доступа к критичным системам — от 20 символов.

Генератор и проверка надёжности

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

Кнопка Проверить сверяет пароль с базой известных утечек Have I Been Pwned: браузер отправляет только первые пять символов SHA-1-хеша — пароль в открытом виде никуда не передаётся, не сохраняется и не покидает ваш браузер.

Почему нельзя генерировать пароли с помощью ИИ

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

Это не теоретическое предположение. В 2025 году Kaspersky провёл тест популярных LLM на качество генерируемых паролей. Результат: 88% паролей DeepSeek, 87% паролей Llama и 33% паролей ChatGPT оказались недостаточно надёжными. В части паролей отсутствовали спецсимволы или цифры, несмотря на явные инструкции их включить.

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

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

Где используются генераторы паролей

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

• Менеджеры паролей — основной и наиболее безопасный контекст. Генератор встроен в хранилище: пароль создаётся и сразу сохраняется в зашифрованном виде, не проходя через буфер обмена или заметки.
• Браузеры — Chrome, Firefox, Safari предлагают встроенную генерацию при заполнении форм регистрации. Удобно для личного использования, но в корпоративном сценарии создаёт проблему: пароли хранятся в браузерном хранилище без централизованного контроля и аудита.
• Корпоративные системы управления доступом — PAM-решения (privileged access management) и системы управления идентификацией генерируют пароли для привилегированных учётных записей, сервисных аккаунтов и технических пользователей. Здесь генерация часто автоматизирована и не требует участия человека.
• Онлайн-генераторы — отдельные веб-инструменты без привязки к хранилищу. Подходят для разовых задач при условии, что генерация происходит локально в браузере. Главный риск — неизвестно, логирует ли сервис созданные комбинации.
• Инструменты разработчика и DevOps — CLI-утилиты, скрипты и менеджеры секретов генерируют пароли, токены и ключи API в автоматизированных пайплайнах.

Как безопасно пользоваться генератором паролей

Алгоритм «Безопасное использование генератора паролей» (8 шагов):

1. Выберите доверенный генератор. Встроенный в менеджер паролей, корпоративное решение или инструмент известного вендора с открытым кодом. Избегайте случайных сайтов без информации о владельце.
2. Установите длину от 16 символов и выше. Если сервис ограничивает длину, используйте максимально допустимую. Для критичных систем — от 20 символов.
3. Включите разные категории символов. Строчные и заглавные буквы, цифры, спецсимволы, если сервис поддерживает. Если совместимость ограничена, приоритет — длина, а не состав.
4. Создавайте отдельный пароль для каждого сервиса. Один пароль — один ресурс. Без исключений для «неважных» аккаунтов: именно они чаще всего становятся точкой входа.
5. Сразу сохраняйте пароль в менеджере паролей. Не копируйте в заметки, не отправляйте в мессенджер, не записывайте в таблицу. Менеджер паролей — единственное место хранения.
6. Включайте MFA для критичных учётных записей. Двухфакторная аутентификация (2FA) снижает риск компрометации, даже если пароль утёк.
7. Проверяйте старые пароли через механизмы аудита. Сервис Have I Been Pwned позволяет проверить пароль по базе утечек без передачи его в открытом виде. Корпоративные менеджеры паролей делают это автоматически для всего хранилища.
8. Меняйте пароль после инцидента или подозрения на компрометацию. Плановая смена паролей по расписанию без признаков компрометации — менее приоритетная мера, чем уникальность и длина. Приоритет — реакция на конкретный инцидент или сигнал из базы утечек.

Частые ошибки при создании паролей

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

Пароль создан. Что дальше?

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

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

В Пассворке генерация паролей встроена в единый контур: настраиваемый генератор, зашифрованное хранилище, аудит, 2FA, SSO и интеграции с AD/LDAP. Протестируйте Пассворк бесплатно

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

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

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

Для чего нужен генератор паролей?

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

Как работает генератор паролей?

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

Безопасно ли использовать онлайн-генератор паролей?

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

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

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

Что лучше: пароль или парольная фраза?

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

Можно ли использовать ИИ для генерации паролей?

Не стоит использовать языковую модель как основной инструмент генерации секретов. По данным Kaspersky (2025), значительная доля паролей, созданных популярными LLM в тесте — 88% у DeepSeek, 87% у Llama и 33% у ChatGPT — оказалась недостаточно надёжной. Языковые модели предсказывают вероятные последовательности, а не создают криптографически случайные данные.

Где хранить сгенерированные пароли?

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

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

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

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

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

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

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

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

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

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

ВкусВилл — розничная сеть натуральных продуктов, основанная в 2009 году. Сегодня это порядка 2200 магазинов в 156 городах России, 9,3 млн покупателей и свыше 4200 наименований под собственным брендом. В основе подхода компании — тесная работа с локальными поставщиками, быстрое обновление ассортимента и постоянные эксперименты с форматами. ВкусВилл одним из первых в российском ритейле начал внедрять искусственный интеллект и кассы самообслуживания собственной разработки.

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

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

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

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

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

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

Выбор: тестирование и аргументы

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

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

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

Внедрение: защищённый периметр

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

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

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

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

Как устроена работа с Пассворком

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

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

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

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

Структура и удобство

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

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

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

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

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

Надёжность решения

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

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

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

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

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

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

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

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

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

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

ГОСТ-шифрование для разработчиков: алгоритмы, СКЗИ и интеграция 2026

ГОСТ-стек хорошо специфицирован — сложность в интеграции. Разбираем четыре актуальных стандарта с OID-ами, механику шифрования изнутри, типичные точки отказа в nginx, Docker и браузерах, классы СКЗИ и границы лицензирования ФСБ и ФСТЭК.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое VaultJacking?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

• Актуальный ГОСТ-стек — четыре стандарта. «Кузнечик» и «Магма» — шифрование, «Стрибог» — хеширование, ГОСТ Р 34.10-2012 — подпись и согласование ключей, ГОСТ Р 34.13-2015 — режимы работы включая CTR-ACPKM. Всё остальное — устаревшие версии или режимы этих четырёх.
• Асимметричная криптография в ГОСТ данные не шифрует. ГОСТ Р 34.10-2012 формирует подпись и вырабатывает общий ключ по VKO. Шифрование данных — всегда симметричное, «Кузнечиком».
• «Магма» — не для шифрования данных. 64-битный блок создаёт риск атаки SWEET32 при объёме ~32 ГБ на ключ. Область применения — имитовставка и Key Wrap внутри CMS.
• openssl-gost-engine и КриптоПро — для разных задач. openssl-gost-engine не является сертифицированным СКЗИ. Для аттестованных систем и работы с КЭП нужен сертифицированный стек.
• Класс СКЗИ определяет модель угроз, а не администратор. Установить ПО с сертификатом КС2 без выполнения организационных требований этого класса — значит классу не соответствовать.
• Лицензия ФСБ нужна при работе с клиентами. Использовать КриптоПро для внутренних нужд можно без лицензии. Встроить СКЗИ в продукт для клиентов или обслуживать СКЗИ у клиентов — лицензируемая деятельность по ПП РФ № 313.
• ГОСТ затрагивает весь стек. Меняются TLS-профиль, форматы сертификатов, хранение ключей, клиентские приложения. Жизненный цикл КЭП требует отдельных процессов — сертификат действует год.
• Постквантовая миграция потребует переработки крипто-слоя. Российские постквантовые стандарты ожидаются в 2026–2027 годах. Проектируйте крипто-слой с абстракцией над алгоритмом — иначе миграция затронет всю кодовую базу.

Что такое ГОСТ-алгоритмы

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

В отличие от международных стандартов NIST (AES, SHA) и RSA, ГОСТ-алгоритмы построены на независимых математических основаниях и прошли отдельный криптоанализ. Для государственных информационных систем, объектов критической инфраструктуры и организаций под надзором ФСБ и ФСТЭК применение ГОСТ-криптографии является нормативным требованием.

Ключевые отличия от западных стандартов

Как устроены ГОСТ-алгоритмы: четыре стандарта и их OID-ы

OID (Object Identifier) — числовой идентификатор вида 1.2.643.7.1.1.5.2, который криптобиблиотеки и сертификаты используют для обозначения алгоритма. Когда OpenSSL встречает в сертификате незнакомый OID, он не может его обработать — отсюда unknown signature algorithm при вызове openssl verify без ГОСТ-движка. OID-ы нужно знать, когда разбираешь совместимость или отлаживаешь парсинг.

Весь актуальный ГОСТ-стек строится на четырёх стандартах — остальное либо устаревшие версии, либо режимы работы этих четырёх.

ГОСТ Р 34.12-2015: «Кузнечик» и «Магма»

ГОСТ Р 34.12-2015 — национальный стандарт Российской Федерации, устанавливающий алгоритмы двух блочных симметричных шифров: «Кузнечик» с размером блока 128 бит и «Магма» с размером блока 64 бита. Стандарт фиксирует математические конструкции, параметры и допустимые режимы работы, чтобы реализации от разных производителей СКЗИ давали идентичный результат и могли взаимодействовать без потери криптографической стойкости.

Кузнечик (RFC 7801, OID 1.2.643.7.1.1.5.2) — основной шифр для защиты данных. 128-битный блок, 256-битный ключ, SP-сеть (Substitution-Permutation) с 10 раундами.

Архитектура та же, что у AES: нелинейная замена байт плюс линейное перемешивание на каждом раунде. Принципиальное отличие от AES — отсутствие аппаратного ускорения на массовых процессорах. AES-NI встроен в каждый Intel/AMD с 2010 года, для «Кузнечика» аналог есть только в специализированных СКЗИ. На больших объёмах данных разрыв в производительности становится заметным.

Магма (RFC 8891, OID 1.2.643.7.1.1.5.1) — ГГОСТ 28147-89 с зафиксированными таблицами подстановок. 64-битный блок, 256-битный ключ, 32 раунда.

Размер блока определяет границу безопасного применения. При шифровании порядка 2³² блоков одним ключом (~32 ГБ) вероятность того, что два разных блока открытого текста дадут одинаковый шифртекст, становится статистически значимой (парадокс дней рождений и атака «дней рождений»). Наблюдатель, накапливающий зашифрованный трафик, может использовать эти совпадения для восстановления данных (атака SWEET32).

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

ГОСТ Р 34.11-2012 «Стрибог»: хеширование

ГОСТ Р 34.11-2012 «Стрибог» (RFC 6986) — хеш-функция. OID 256-битного варианта — 1.2.643.7.1.1.2.2, 512-битного — 1.2.643.7.1.1.2.3. В 2018 году «Стрибог» вошёл в ISO/IEC 10118-3 — это единственный российский криптографический алгоритм с международной стандартизацией на уровне ISO.

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

ГОСТ Р 34.10-2012: электронная подпись и выработка ключа

ГОСТ Р 34.10-2012 (RFC 7091) — алгоритм электронной подписи на эллиптических кривых, используемый во всех российских криптографических профилях. OID 256-битного варианта — 1.2.643.7.1.1.1.1, 512-битного — 1.2.643.7.1.1.1.2.

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

Ключевое архитектурное отличие от RSA: асимметричная криптография в российской модели данные не шифрует. Она решает две задачи — формирование подписи и выработка общего ключа по протоколу VKO (Выработка Ключа Общего). VKO — российский аналог Diffie-Hellman: обе стороны обмениваются открытыми частями и независимо вычисляют один и тот же секрет, не передавая его по каналу. Шифрование данных всегда симметричное — «Кузнечиком».

CTR-ACPKM: механизм без западного аналога

ГОСТ Р 34.13-2015 вводит режим CTR-ACPKM (OID 1.2.643.7.1.1.4.2 для «Кузнечика», 1.2.643.7.1.1.4.3 для «Магмы»). Он решает проблему, которую стандартный CTR не решает.

CTR шифрует последовательный счётчик и накладывает результат на данные по XOR. Чем дольше работает один ключ, тем больше статистики накапливает наблюдатель — и тем выше риск атаки. ACPKM (Acyclic Pseudo-random Key Modification) периодически перегенерирует внутренние раундовые ключи прямо в процессе шифрования. Для прикладного кода это невидимо: ключ в API не меняется, поведение интерфейса не меняется. Меняется только внутреннее состояние шифра.

Прямого аналога в западных стандартах нет. Конкретные лимиты данных на ключ и обязательность ACPKM определяет профиль протокола: PKCS#5/PBES2 — RFC 9337, TLS 1.2 — RFC 9189, TLS 1.3 — RFC 9367.

Как работает ГОСТ-шифрование изнутри

ГОСТ использует гибридную схему. Стороны вырабатывают общий симметричный ключ по открытому каналу через протокол VKO — российский аналог Diffie-Hellman на эллиптических кривых. Данные шифруются этим симметричным ключом («Кузнечиком»), но не напрямую: сначала симметричный ключ упаковывается в отдельный зашифрованный контейнер — Key Wrap. Получатель сначала распаковывает ключ, затем расшифровывает данные.

Всё это происходит внутри формата CMS (Cryptographic Message Syntax) — стандартной ASN.1-структуры для зашифрованных и подписанных сообщений (RFC 5652). CMS — это то, что СКЗИ фактически передаёт при шифровании файлов и почты: не просто шифртекст, а контейнер, в котором упакованы зашифрованный ключ, параметры алгоритма и сами данные.

Схема шифрования в формате ГОСТ

Отправитель:

1. Генерирует эфемерную пару ключей (ec_ephemeral_priv, ec_ephemeral_pub). «Эфемерная» — одноразовая: создаётся для одного сообщения и уничтожается после использования. При реальном уничтожении это даёт прямую секретность (forward secrecy): если завтра утечёт основной ключ, вчерашние сообщения расшифровать не получится.
2. Генерирует случайный CEK (Content Encryption Key, 256 бит) — симметричный ключ для шифрования данных.
3. Генерирует UKM (User Keying Material, 8 байт) — случайная соль, которая делает каждое соединение уникальным даже при одинаковых ключах.
4. Вырабатывает общий секрет по протоколу VKO: Z = VKO(ec_ephemeral_priv, recipient_pub_key, UKM). Обе стороны независимо вычисляют одну и ту же точку на эллиптической кривой, не передавая секрет по каналу.
5. Выводит ключ шифрования ключа через KDF: KEK = HKDF-Стрибог(Z, UKM, ...) KDF (функция выработки ключа) превращает сырой общий секрет Z в ключ нужной длины. KEK (Key Encryption Key) используется для шифрования CEK.
6. Упаковывает CEK: WrappedCEK = Магма-CBC-MAC(CEK) + Магма-ECB(CEK) на KEK CEK шифруется на KEK алгоритмом «Магма» с добавлением имитовставки для контроля целостности.
7. Шифрует данные: CipherText = Кузнечик-CTR(CEK, IV, plaintext)
8. Формирует и отправляет CMS EnvelopedData: {ec_ephemeral_pub, UKM, WrappedCEK, IV, CipherText}
9. ec_ephemeral_priv уничтожается.

Получатель:

1. Вычисляет тот же общий секрет: Z = VKO(recipient_priv_key, ec_ephemeral_pub, UKM)
2. Выводит тот же KEK через KDF.
3. Распаковывает CEK (Key Unwrap): проверяет имитовставку, расшифровывает CEK на KEK.
4. Расшифровывает данные на CEK.

Три момента, которые часто упускают

• VKO — это не просто ECDH. В стандартном ECDH стороны перемножают ключи. В VKO дополнительно учитываются UKM и идентификатор алгоритма — это влияет на итоговый общий секрет. КриптоПро и ViPNet исторически интерпретировали некоторые детали по-разному, отсюда проблемы совместимости при межсистемном взаимодействии.
• Key Wrap через «Магму» обязателен по стандарту — даже если основные данные шифруются «Кузнечиком». Старый ГОСТ Key Wrap описан в RFC 4357; для сценариев с PBES2/PBKDF2 — RFC 9337.
• UKM должен быть настоящим случайным материалом из ГПСЧ СКЗИ (аппаратный или программный генератор псевдослучайных чисел, сертифицированный ФСБ). Детерминированное значение или нули в UKM — схема формально работает, но теряет часть защитных свойств.

openssl-gost-engine: что работает, что нет

Для разработки и несертифицированных сценариев подходит openssl-gost-engine. Но здесь есть контекст, который обычно упускают в инструкциях.

ENGINE API устарел

OpenSSL поддерживает два способа подключить сторонние алгоритмы:

• Engine API — динамически загружаемый .so-файл, регистрирующий реализации через устаревший внутренний интерфейс
• Provider API — более изолированная архитектура, представленная в OpenSSL 3.0

OpenSSL 3.0 пометил Engine API как deprecated. gost-engine по-прежнему использует именно его — миграция на Provider API идёт (issue #496), но неспешно. В OpenSSL 4.0 ENGINE API уберут. Пока работает, но это нужно учитывать при планировании.

Поддержка по дистрибутивам

Сборка (Debian 12 / Ubuntu 24.04)

# CMake >= 3.18 обязателен для OpenSSL 3.x
sudo apt install cmake libssl-dev git

git clone https://github.com/gost-engine/engine gost-engine
cd gost-engine
git submodule update --init
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
cmake --build . --config Release
sudo cmake --install .

Путь к .so непредсказуем — всегда проверяйте:

find /usr /lib /usr/local -name "gost.so" 2>/dev/null

Настройка openssl.cnf

Добавьте в начало файла:

openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/gost.so
default_algorithms = ALL

CRYPT_PARAMS, встречающийся в старых инструкциях — устаревший параметр для ГОСТ 28147-89, сейчас не нужен.

# Проверка что движок живой
openssl engine -t gost

# Актуальные имена cipher suites (они менялись между версиями движка)
openssl ciphers | tr ':' '\n' | grep -i gost
# GOST2012-KUZNYECHIK-KUZNYECHIKOMAC, GOST2012-MAGMA-MAGMAOMAC, ...

Ключи и подпись

# paramset:A — параметры эллиптической кривой (конкретная кривая из стандарта).
# ГОСТ определяет несколько предопределённых наборов (A, B, C и ещё несколько),
# paramset:A — стандартный выбор для большинства задач.
openssl genpkey -algorithm gost2012_256 \
  -pkeyopt paramset:A \
  -out gost_private.pem

# Самоподписанный сертификат для тестов
openssl req -x509 -newkey gost2012_256 \
  -pkeyopt paramset:A \
  -nodes -keyout key.pem -out cert.pem \
  -md_gost12_256 \
  -subj "/C=RU/CN=test"

# Подпись и проверка
openssl dgst -md_gost12_256 -sign gost_private.pem \
  -out signature.bin document.pdf

openssl dgst -md_gost12_256 -verify gost_public.pem \
  -signature signature.bin document.pdf

Python: PyGOST

from pygost.gost3412_2015 import GOST3412Grasshopper
from pygost.gost34112012 import GOST34112012256

h = GOST34112012256(b"hello, gost")
print(h.hexdigest())

key = bytes(range(32))
cipher = GOST3412Grasshopper(key)
encrypted = cipher.encrypt(bytes(16))

API менялся между версиями 6.x и 7.x — проверяйте документацию при обновлении.

КриптоПро и сертифицированный стек

Когда нужна сертификация ФСБ — openssl-gost-engine не подходит. Нужны коммерческие средства криптографической защиты информации (СКЗИ): сертифицированные криптобиблиотеки и HSM-устройства.

КриптоПро CSP 5.0 — стандарт. Под Windows работает через CryptoAPI, под Linux — через собственный демон cprocspd. Есть версии для Astra Linux, Альт, РЕД ОС.

Конфигурация OpenSSL для КриптоПро:

[openssl_init]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /opt/cprocsp/lib/amd64/cp_gost.so
default_algorithms = ALL

Хранение ключей

Ключи хранятся в /var/opt/cprocsp/keys/<username>/. Ключевой контейнер — это директория из шести файлов, а не один файл:

container_name.000/
├── header.key
├── masks.key
├── masks2.key
├── name.key
├── primary.key
└── primary2.key

ViPNet CSP — альтернатива от ИнфоТеКС. На уровне PKCS#11 и CryptoAPI совместим с КриптоПро, но детали VKO реализованы немного иначе. При межсистемном взаимодействии (КриптоПро на одной стороне, ViPNet на другой) — проверяйте матрицу совместимости на tc26.ru перед выбором архитектуры. Там публикуются протоколы испытаний. Известен случай, когда Континент TLS Client 2 не распознавал КриптоПро CSP 5 как провайдера.

Где ломается интеграция

nginx и ГОСТ TLS

Долгое время ГОСТ-криптография в TLS была ограничена версией 1.2: RFC 9189 определяет наборы шифров (cipher suites) и механизмы согласования ключей именно для этого протокола. В 2022 году вышел RFC 9367, распространивший поддержку ГОСТ на TLS 1.3.

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

КриптоПро CSP 5.0 R2 поставляет патченный nginx (cpnginx):

ssl_certificate     /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;

ssl_protocols TLSv1.2;
ssl_ciphers GOST2012-KUZNYECHIK-KUZNYECHIKOMAC:GOST2012-MAGMA-MAGMAOMAC:LEGACY-GOST2012-GOST8912-GOST8912;
ssl_prefer_server_ciphers on;

Проблема с кешем сессий. Общий кеш TLS-сессий между воркерами не работает. Каждый воркер держит свой кеш — при балансировке между ними происходит полный handshake. Директива ssl_session_cache shared:SSL:10m; работает не так, как ожидается. Решения: включить ssl_session_tickets on; или вынести TLS-терминацию на выделенный шлюз (NGate, С-Терра, Континент TLS).

Второй вариант — поставить ГОСТ-шлюз перед обычным nginx. Он терминирует ГОСТ TLS, дальше идёт обычный HTTPS. Заодно решает проблему с session cache и убирает из nginx зависимость от СКЗИ.

Браузеры

Chromium и Firefox ГОСТ не поддерживают. Для пользовательского доступа к ГОСТ-сайтам нужен Яндекс Браузер или Chromium-GOST — open-source форк, есть Linux-сборки.

Важно разделять две разные задачи: ГОСТ TLS (защита соединения) и подпись документов в браузере. Для второго нужно расширение КриптоПро ЭЦП Browser Plugin — отдельный компонент, никак не связанный с TLS.

Docker

КриптоПро в контейнере требует конкретных флагов, без которых cprocspd не стартует:

docker run -d \
  --privileged \
  --security-opt seccomp=unconfined \
  --tmpfs /run \
  --tmpfs /run/lock \
  -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
  my-cryptopro-image

--tmpfs /run и --tmpfs /run/lock обязательны — без них cprocspd не создаёт lock-файлы. Ключи монтируются через volume:

volumes:
  - /var/opt/cprocsp/keys:/var/opt/cprocsp/keys:ro

Лицензия привязана к физическому хосту, а не к контейнеру. Пересоздание контейнера повторной активации не требует — смена хоста требует. Тестовая лицензия активируется автоматически на 3 месяца.

Если сертификация не нужна, проще использовать openssl-gost-engine в контейнере — без лицензионных ограничений. В репозитории gost-engine есть готовые Dockerfile для Debian и Alpine.

Сертификаты

ГОСТ-сертификаты формально являются X.509, но без ГОСТ-движка их не прочитать:

Signature Algorithm: GOST R 34.11-2012 with GOST R 34.10-2012 (256 bit)
  OID: 1.2.643.7.1.1.3.2
Public Key Algorithm: GOST R 34.10-2012 (256 bit)
  OID: 1.2.643.7.1.1.1.1
  Parameters: GOST R 34.10-2012 256-bit ParamSet A
    OID: 1.2.643.7.1.2.1.1.1

openssl verify без движка выдаст unknown signature algorithm. Это ошибка среды, не сертификата.

Классы СКЗИ: КС1, КС2, КС3

ФСБ устанавливает шесть классов защиты СКЗИ — КС1, КС2, КС3, КВ1, КВ2, КА1. Шкала идёт от минимальных программных требований до защиты от атак спецслужб с физическим доступом к оборудованию. Для большинства коммерческих задач актуальны первые три.

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

КЭП и форматы подписей

Квалифицированная электронная подпись (КЭП) по Федеральному закону № 63-ФЗ «Об электронной подписи» — строго регламентированная конструкция: алгоритм ГОСТ Р 34.10-2012, сертифицированное СКЗИ, сертификат от аккредитованного удостоверяющего центра (УЦ). С 2022 года КЭП юридических лиц выдаёт УЦ ФНС России.

Форматы подписей:

• CAdES (Advanced Electronic Signatures поверх CMS) — основной стандарт для государственных систем, СМЭВ, ФНС и большинства регуляторных интеграций.
• XAdES — то же самое для XML-документов.
• PAdES — подпись встраивается непосредственно в PDF-файл, без отдельного файла подписи.

Реализовывать эти форматы с нуля не нужно — существуют готовые решения. КриптоПро PDF и Office Signature закрывают задачи подписания документов. КриптоПро CAdES BES/T используется для интеграции со СМЭВ. КриптоПро DSS обеспечивает серверную подпись через REST API — актуально для систем, где подписание происходит на стороне сервера без участия пользователя.

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

Постквантовый горизонт

ГОСТ Р 34.10-2012 уязвим к алгоритму Шора — как RSA и ECDSA. Квантовый компьютер достаточной мощности появится не раньше 2030–2035 годов по оптимистичным оценкам. Однако уже сейчас актуальна стратегия «harvest now, decrypt later»: противник перехватывает и сохраняет зашифрованный трафик сегодня, чтобы расшифровать его после появления нужных вычислительных мощностей. Для данных с горизонтом конфиденциальности 15+ лет это риск, который требует проработки уже на этапе проектирования.

Симметричные алгоритмы устойчивее. Алгоритм Гровера снижает стойкость симметричных шифров вдвое по экспоненте: 256-битный ключ «Кузнечика» деградирует до ~128-битной эффективной стойкости — уровня, который по-прежнему считается достаточным.

В российском контуре постквантовую стандартизацию ведёт технический комитет ТК 26. Компания «Криптонит» опубликовала реализацию постквантовой схемы «Шиповник» на основе кодовой криптографии. Выход российских стандартов ожидается в 2026–2027 годах.

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

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

1. ГОСТ затрагивает весь стек, а не один компонент. Хранение ключей, форматы сертификатов, TLS-профиль, форматы подписей, клиентские приложения, reverse proxy — всё это меняется. Большинство систем мониторинга не понимают ГОСТ TLS и просто не видят соединения.
2. интетические бенчмарки вводят в заблуждение. Реальная производительность складывается из TLS handshake + десериализация CMS + VKO + Key Unwrap + расшифровка. На бенчмарке вы измеряете только расшифровку.
3. Жизненный цикл ключей остаётся без внимания. Сертификат КЭП действует год. У ключевых носителей тоже есть срок. Нужны процессы: кто инициирует перевыпуск, кто едет в УЦ, как обновляется в системе, что происходит в переходный период.
4. openssl-gost-engine берут там, где нужна сертификация. Он технически корректен, но не является сертифицированным СКЗИ — это разные требования, и их нельзя смешивать.
5. Придумывают собственную схему поверх стандарта. «Мы берём Кузнечик, но упаковку ключей сделали по-своему» — ломает безопасность (нестандартные схемы не проходили криптоанализ), совместимость и юридическую легитимность.

Лицензии ФСБ и ФСТЭК

Граница лицензирования неочевидна — не потому что её прячут, а потому что она действительно нетривиальна.

Основной документ — Постановление Правительства РФ № 313 от 16.04.2012 (редакция от 28.08.2023). В приложении — 28 видов лицензируемой деятельности: разработка СКЗИ, производство, распространение, монтаж и настройка на объектах клиентов, техническое обслуживание для третьих лиц, услуги в области шифрования.

ПП № 313 прямо исключает из лицензирования техническое обслуживание СКЗИ для обеспечения собственных нужд юридического лица. Использовать КриптоПро для собственного ЭДО, VPN между офисами, внутреннего инструмента — можно без лицензии. Как только вы начинаете делать это для клиентов — устанавливать, настраивать, обслуживать, продавать встроенную защищённую систему — нужна лицензия.

Если вы разрабатываете приложение, интегрируете в него КриптоПро CSP через API и передаёте это приложение клиентам — вы распространяете «защищённую с использованием шифровальных средств информационную систему» по смыслу п. 2 Постановления Правительства № 313. Это требует лицензии ФСБ на разработку и распространение СКЗИ — даже если само СКЗИ клиент приобретает напрямую у КриптоПро.

Разграничение регуляторов

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

Два основных вида лицензий ФСТЭК:

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

Требования к получению обеих лицензий:

• не менее 3 штатных сотрудников с профильным образованием в области информационной безопасности;
• аттестованное помещение;
• аттестованные автоматизированные рабочие места (АРМ) разработчиков;
• выездная проверка ФСТЭК.

Ответственность

• Ст. 13.13 КоАП («Незаконная деятельность в области защиты информации»): граждане — 500–1 000 руб., должностные лица — 4 000–5 000 руб., юрлица — 30 000–40 000 руб. с возможной конфискацией средств защиты информации. Суммы по ч. 1 выглядят небольшими, но конфискация СКЗИ и оборудования означает остановку деятельности.
• Ст. 14.1 КоАП: ч. 2 (деятельность без лицензии) — штраф для юрлиц 40 000–50 000 руб.; ч. 3 (грубое нарушение лицензионных требований при наличии лицензии) — штраф до 200 000 руб. или административное приостановление деятельности до 90 суток.
• Ст. 171 УК наступает при совокупности условий: предпринимательская деятельность без лицензии и либо причинение крупного ущерба (от 2 250 000 руб.), либо извлечение дохода в крупном размере (от 2 250 000 руб.). Ч. 1 — штраф до 300 000 руб. или арест до 6 месяцев. Ч. 2 (организованная группа или особо крупный размер — от 9 000 000 руб.) — до 5 лет лишения свободы.

Заключение

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

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

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

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

Чем openssl-gost-engine отличается от КриптоПро CSP?

openssl-gost-engine — открытая реализация ГОСТ-алгоритмов для OpenSSL, подходящая для разработки и тестирования. КриптоПро CSP — коммерческое СКЗИ с сертификатом ФСБ. Для систем, требующих аттестации или работы с квалифицированной электронной подписью, openssl-gost-engine не подходит: наличие корректной реализации алгоритма и наличие сертификата — разные требования.

Почему «Магму» нельзя использовать для шифрования больших объёмов данных?

64-битный блок «Магмы» создаёт birthday bound: при шифровании ~32 ГБ одним ключом вероятность коллизии двух блоков становится статистически значимой. Это основа атаки SWEET32. «Магма» предназначена для операций с заведомо малыми объёмами — имитовставки и Key Wrap внутри CMS. Для шифрования данных используется «Кузнечик» с 128-битным блоком.

Нужна ли лицензия ФСБ, если КриптоПро встроен в продукт для клиентов?

Да. Встраивая СКЗИ в продукт и передавая его клиентам, вы распространяете «защищённую с использованием шифровальных средств информационную систему» по смыслу п. 2 Постановления Правительства РФ № 313 от 16.04.2012. Лицензия требуется даже если клиент приобретает СКЗИ у КриптоПро напрямую — факт встраивания и распространения уже образует лицензируемую деятельность.

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

Ключевой контейнер КриптоПро — это директория из шести файлов (header.key, masks.key, masks2.key, name.key, primary.key, primary2.key), а не один файл. При переносе копируется вся директория целиком из /var/opt/cprocsp/keys/<username>/. Перенос отдельных файлов не работает — контейнер станет нечитаемым.

Что такое forward secrecy в контексте ГОСТ CMS и зачем уничтожать эфемерный ключ?

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

Что изменится при переходе на постквантовые стандарты?

ГОСТ Р 34.10-2012 уязвим к алгоритму Шора — как RSA и ECDSA. Российские постквантовые стандарты ожидаются в 2026–2027 годах. «Кузнечик» с 256-битным ключом под алгоритмом Гровера деградирует до ~128-битной стойкости — этого по-прежнему достаточно. Главный практический вывод: проектируйте крипто-слой с абстракцией над алгоритмом — захардкоженные вызовы VKO с конкретными параметрами кривой превратят миграцию в болезненный рефакторинг всей кодовой базы.

Как работает ГОСТ TLS и какие браузеры его поддерживают?

ГОСТ TLS 1.2 стандартизирован в RFC 9189, TLS 1.3 — в RFC 9367 (2022). На практике большинство сертифицированных СКЗИ в 2026 году работают с TLS 1.2. Chromium и Firefox ГОСТ не поддерживают. Для пользовательского доступа к ГОСТ-сайтам подходят Яндекс Браузер или Chromium-GOST. Подпись документов в браузере — отдельная задача, требующая КриптоПро ЭЦП Browser Plugin, не связанного с TLS.

Чем ТЗКИ отличается от СЗКИ и когда нужна каждая лицензия ФСТЭК?

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

Криптография в России: ГОСТ-алгоритмы, СКЗИ и требования в 2026 году

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

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

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

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

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

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

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

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

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

О конференции

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

Программа: что обсуждали на GetNet 2026

В этом году программа охватила множество прикладных тем — ниже лишь часть из них:

• NGFW. Разбор того, почему заявленные характеристики межсетевых экранов расходятся с реальной производительностью в боевых режимах. Отдельный блок — практический разбор остановленной атаки как способ проверить, что NGFW действительно защищает, а не просто фильтрует трафик по правилам.
• Масштабирование инфраструктуры. Типовые технические и бизнес-проблемы при резком росте нагрузки: где закладываются будущие кризисы и как их предотвратить до того, как они проявятся в продакшене.
• Превентивный мониторинг — как «слепые зоны» по CPU, памяти, дискам и сетевым каналам превращаются в каскадные сбои. Инструменты: Zabbix, Prometheus, Grafana, ELK, Loki, Ansible.
• Автоматизация конфигураций — как привести RouterOS к целевому состоянию через annet без лишних команд и ручной сверки с эталоном.
• Автоматизация настройки VLAN — инструменты MVRP, dot1x и интерфейс-листы на оборудовании MikroTik: нюансы, риски и границы применимости.
• Внутренние уязвимости в eCommerce — реальные кейсы: утечки через уязвимый браузер в контакт-центре, открытые репозитории с сертификатами, секреты в CI/CD-пайплайнах. Периметровая защита эти угрозы не закрывает.
• Тестирование отечественного оборудования — 5-шаговая методология: от одиночного устройства до комплексной проверки отказоустойчивости. Принцип — перенести риски с продакшена в лабораторию до закупки.
• Отказоустойчивые сети для среднего бизнеса — практические архитектуры высокой доступности при ограниченном бюджете и без выделенных сетевых специалистов.

Пассворк на GetNet

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

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

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

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

Пассворк в документации Яндекс Облака: настройка SSO через Yandex Identity Hub

Яндекс Облако опубликовало пошаговое руководство по настройке SSO для Пассворка через Yandex Identity Hub. Разбираем, что такое Identity Hub, как устроена интеграция и что это даёт бизнесу.

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

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

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

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

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

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

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

Яндекс Облако опубликовали пошаговое руководство по настройке единого входа (SSO) для Пассворка через Yandex Identity Hub. Руководство размещено среди практических гайдов в одном ряду с другими корпоративными инструментами платформы.

Что такое Yandex Identity Hub

Yandex Identity Hub — облачный сервис Яндекса для централизованного управления доступом сотрудников к корпоративным приложениям. Поддерживает протоколы SAML 2.0 и OIDC, встроенную многофакторную аутентификацию (MFA) через Webauthn/FIDO2 и TOTP. Российская альтернатива зарубежным провайдерам идентификации (IdP): Okta, Azure AD и аналогам.

Из ключевых возможностей:

• Быстрый старт — SaaS-модель не требует внедрения и поддержки собственной инфраструктуры.
• Централизованное управление доступом — единая точка управления пользователями и аутентификацией во всех корпоративных сервисах. Пользователи, группы и атрибуты синхронизируются с Active Directory автоматически.
• Продвинутые технологии аутентификации — поддержка SAML, OIDC, встроенная MFA: Webauthn/FIDO2, TOTP, SMS.
• Портал самообслуживания — сотрудники самостоятельно меняют пароль и управляют своими MFA-факторами без обращения в ИТ-поддержку.
• Журнал аудита — просмотр событий аутентификации с фильтрацией, интеграция с SIEM-системами.
• Брендирование — страницы входа и ошибок оформляются в соответствии с корпоративным брендбуком.
• Экономия ресурсов ИТ и ИБ — снижение нагрузки на внутренние команды за счёт централизованного управления и механизмов самообслуживания.

Сервис соответствует требованиям Федерального закона № 152-ФЗ «О персональных данных», ГОСТ Р 57580, стандарту PCI DSS и ISO. SLA — 99,99%, что соответствует одному из самых высоких уровней доступности на российском рынке.

Identity Hub тесно интегрирован с экосистемой Яндекса: Яндекс 360 и Яндекс Браузер для организаций. Для компаний, уже работающих в Яндекс Облаке, сервис доступен без дополнительных вендоров.

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

Руководство Яндекс Облака описывает полный цикл настройки интеграции с Пассворком: от создания SAML-приложения в Yandex Identity Hub до проверки корректной работы единого входа.

Структура руководства включает четыре этапа:

1. Создание SAML-приложения в Yandex Identity Hub и сохранение настроек провайдера идентификации.
2. Настройка интеграции на стороне Пассворка — ввод метаданных IdP, настройка SAML-параметров.
3. Настройка SAML-приложения на стороне Yandex Identity Hub — сопоставление атрибутов пользователей.
4. Добавление пользователей в приложение и проверка работы SSO.

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

Как работает SSO между Yandex Identity Hub и Пассворком

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

В связке Yandex Identity Hub и Пассворка процесс выглядит так:

1. Сотрудник открывает Пассворк и нажимает «Войти через SSO».
2. Пассворк перенаправляет запрос в Yandex Identity Hub.
3. Identity Hub проверяет учётные данные и формирует SAML-утверждение (assertion) с подписью.
4. Пассворк проверяет подпись и аутентифицирует пользователя.

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

Почему это важно

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

Компании, которые уже используют Пассворк и Yandex Identity Hub, могут настроить SSO самостоятельно. Те, кто только выбирает инструменты, получают предсказуемость: совместимость подтверждена, а не проверяется опытным путём.

Хотите проверить, как Пассворк впишется в вашу инфраструктуру аутентификации? Пассворк поддерживает SSO через SAML 2.0 и OAuth/OIDC и работает с Yandex Identity Hub, Azure AD, Keycloak, Blitz Identity Provider и другими корпоративными IdP. Протестировать можно бесплатно

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

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

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

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

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

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

Криптография в России: ГОСТ-алгоритмы, СКЗИ и требования в 2026 году

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

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

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

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

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

Главное

• KeePass — инструмент для индивидуального использования. Шифрует базу паролей алгоритмом AES-256, работает без подписки и без зависимости от стороннего сервиса. Формат .kdbx поддерживается на всех платформах, инструмент проверен сообществом за более чем двадцать лет.
• KeePass хранит пароли, но не управляет доступами. Файл базы не ведёт журнал просмотров, не разграничивает права между сотрудниками и не даёт механизма быстрого отзыва доступа при увольнении.
• Корпоративный менеджер паролей решает управленческие задачи. Централизованный контроль прав, аудит действий, интеграция с AD/LDAP/SSO, соответствие требованиям ИБ — всё это выходит за рамки того, что файловое хранилище может обеспечить архитектурно.
• Граница применимости KeePass — размер и сложность команды. Один специалист или малая техническая команда с высокой дисциплиной: KeePass справляется. Несколько отделов, подрядчики, удалённые сотрудники, требования аудита: нужен корпоративный инструмент.

Что KeePass действительно делает хорошо

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

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

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

Где начинаются проблемы

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

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

• Кто видит пароли и какие? Если база общая, все видят всё.
• Кто и когда смотрел или менял пароль? Без логов и аудита это неизвестно.
• Как отозвать доступ уволенного сотрудника? Нужно вручную проверять, к каким файлам у него был доступ.
• Как передать пароль подрядчику, не создав постоянной копии? Через мессенджер (с неконтролируемым следом).
• Как доказать соблюдение парольной политики при аудите? Без логов — никак.
• Как управлять доступами при росте команды? Ручное администрирование не масштабируется.

Это не недостатки KeePass как инструмента шифрования. Это граница применимости файлового хранилища в управленческом контексте.

По данным Solar 4RAYS, 37% успешных кибератак на российские компании в 2024 году начинались с компрометации учётных данных — почти вдвое больше, чем годом ранее. По данным опроса «Гарда» (TAdviser, 2026), 29% российских компаний в 2025 году столкнулись с более чем десятью атаками на инфраструктуру. Учётные данные сотрудников — одна из главных точек входа, и контроль над ними напрямую влияет на устойчивость компании к атакам.

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

Главное различие — не в шифровании (оба решения его обеспечивают), а в модели управления доступом.

Семь задач бизнеса, которые KeePass обычно не закрывает «из коробки»

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

1. Централизованная выдача прав

Новый сотрудник выходит на работу. Ему нужен доступ к двенадцати сервисам.

2. Аудит действий

ИБ-отдел запрашивает: кто работал с паролем от продуктивной базы данных в прошлый вторник?

3. Безопасный отзыв доступов

Сотрудник увольняется. Какие пароли он видел? Какие надо ротировать?

4. Временный доступ подрядчикам

Подрядчик подключается на две недели для аудита инфраструктуры. Ему нужен доступ к трём сервисам.

5. Интеграция с AD/LDAP/SSO

В компании уже работает Active Directory (AD). Пользователи и группы синхронизированы.

6. Контроль качества паролей

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

7. Отчётность для ИБ и руководства

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

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

Аудит и регуляторные требования

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

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

Что требуют российские регуляторы:

• 152-ФЗ «О персональных данных» — оператор обязан применять организационные и технические меры защиты персональных данных, включая контроль доступа и регистрацию событий безопасности.
• Приказ ФСТЭК России № 21, п. 8 — для информационных систем персональных данных установлены требования к идентификации, аутентификации и управлению учётными записями, включая журналирование действий пользователей.
• 187-ФЗ «О безопасности критической информационной инфраструктуры» — субъекты КИИ (критической информационной инфраструктуры) обязаны реагировать на компьютерные инциденты и вести регистрацию событий безопасности, в том числе связанных с доступом к защищаемым ресурсам.
• Приказ ФСТЭК России № 239 — для субъектов КИИ устанавливает требования к системам безопасности значимых объектов, включая управление учётными записями, контроль доступа и регистрацию событий (меры ИАФ и РСБ).
• Приказ ФСТЭК России № 117  — устанавливает требования к управлению учётными записями, контролю доступа и регистрации событий безопасности. Вводит числовые метрики защищённости (КЗИ и ПЗИ) и жёсткие сроки устранения уязвимостей.

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

Когда KeePass всё ещё достаточно

Честный ответ: KeePass остаётся разумным выбором в конкретных условиях.

KeePass подходит, если:

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

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

Матрица зрелости парольного процесса: когда KeePass достаточно, а когда уже нет

Вопрос «KeePass или корпоративный менеджер» зависит от сложности организации. Ниже — Матрица зрелости парольного процесса для оценки текущей ситуации.

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

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

Пора переходить, если:

• в компании больше 10–20 пользователей с общими доступами;
• появились подрядчики или внешние команды;
• сотрудники работают удалённо и синхронизируют базу через облако;
• пароли передают в мессенджерах или по электронной почте;
• при увольнении сотрудника непонятно, к каким паролям у него был доступ;
• ИБ-отдел или руководство запрашивает журналы действий;
• в инфраструктуре используется AD, LDAP или SSO;
• компания работает в регулируемой отрасли или готовится к сертификации;
• требуется локальное решение или российское ПО из реестра.

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

При оценке корпоративного менеджера паролей проверьте следующие возможности:

1. Локальная и облачная модель — данные должны храниться там, где требует политика компании.
2. Шифрование — AES-256 или ГОСТ для организаций с соответствующими требованиями.
3. MFA (многофакторная аутентификация) — включая аппаратные ключи и биометрию.
4. Интеграция с AD/LDAP — синхронизация пользователей и групп без ручного администрирования.
5. Единый вход (SSO) — единая точка аутентификации через SAML или аналогичный протокол.
6. Ролевая модель и группы — разграничение доступа на уровне записей, папок и сейфов.
7. Журнал аудита — полная история действий с фильтрацией и экспортом.
8. Импорт из KeePass — поддержка формата .kdbx или CSV для миграции без потерь.
9. Панель безопасности — отображение слабых, устаревших и скомпрометированных паролей.
10. API и CLI — для интеграции с DevOps-процессами и автоматизации.
11. Интеграция с SIEM — передача событий в систему мониторинга безопасности.
12. Российская юрисдикция и реестр ПО — для госсектора и регулируемых отраслей.

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

Как Пассворк закрывает эти задачи

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

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

• Ролевая модель и группы. Новый сотрудник добавляется в группу и автоматически получает доступ ко всем нужным сейфам. При увольнении — один шаг, и все доступы отозваны.
• Интеграция с AD/LDAP и SSO. Пользователи и группы синхронизируются с корпоративным каталогом. Расширенная версия поддерживает SAML SSO и сопоставление групп LDAP с группами в Пассворке.
• Журнал аудита. Каждое действие фиксируется: просмотр, копирование, изменение, удаление — с временной меткой и именем пользователя. История изменений паролей доступна для проверки.
• Панель безопасности. Система показывает устаревшие, слабые и скомпрометированные пароли — администратор видит проблемы до того, как они стали инцидентами.
• API, CLI и интеграция с SIEM. Для DevOps-команд — CLI-утилита и полнофункциональный API. Для ИБ-отдела — интеграция с SIEM-системами.
• Двухфакторная аутентификация. Второй фактор для защиты данных: TOPT, биометрия, ключи доступа и аппаратные ключи безопасности.
• Шифрование. Поддержка AES-256 и ГОСТ-шифрования.
• Импорт из KeePass. Миграция с KeePass поддерживается через импорт в форматах JSON и CSV — без потери данных.

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

Парольная безопасность как управленческая задача

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

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

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

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

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

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

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

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

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

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

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

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

Когда пора переходить с KeePass на корпоративный менеджер?

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

Поддерживает ли Пассворк импорт из KeePass?

Пассворк поддерживает импорт данных в форматах JSON и CSV. Это позволяет перенести базу KeePass в Пассворк без потери записей.

Соответствует ли KeePass требованиям 152-ФЗ и ФСТЭК?

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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