Как должен быть устроен надёжный менеджер паролей: архитектура и принципы безопасности
Большинство статей о менеджерах паролей останавливаются на одном и том же: «используйте AES-256 и мастер-пароль». Это правда, но неполная. За поверхностью маркетинговых формулировок скрывается несколько архитектурных решений, от которых зависит реальная безопасность. Некоторые из них очевидны, другие — нет.
В этом материале полный разбор того, как должен быть устроен надёжный корпоративный менеджер паролей изнутри: от криптографии до модели угроз, от ролевого доступа до вопроса о том, где физически хранятся данные.
Модель угроз: от чего вообще нужно защищаться
Прежде чем говорить об архитектуре, нужно договориться о модели угроз (threat model). Потому что «безопасный» — это всегда «безопасный от чего именно».
Для корпоративного менеджера паролей значимы несколько классов угроз.
Компрометация сервера. Злоумышленник получает доступ к базе данных или резервным копиям. Это может быть внешняя атака, утечка через инсайдера у вендора или юрисдикционный запрос. Надёжная архитектура делает базу бесполезной без ключей шифрования, которые на сервере не хранятся.
Перехват трафика (man-in-the-middle атака). Трафик между клиентом и сервером перехватывается на промежуточном узле. Защита — транспортное шифрование (TLS), но оно закрывает только канал, не содержимое.
Компрометация учётной записи пользователя. Пользователь использует слабый пароль, вводит его на фишинговом сайте или оставляет активную сессию на чужом устройстве. Здесь на первый план выходят политики паролей, многофакторная аутентификация (MFA) и управление сессиями.
Внутренний нарушитель (insider threat). Администратор или сотрудник с широкими правами злоупотребляет доступом. Защита — принцип минимальных привилегий (least privilege), журналирование каждого действия, персональные хранилища с отдельным ключом.
Компрометация клиентского устройства. Вредоносный код на компьютере пользователя перехватывает данные в момент ввода или отображения. Частично закрывается защитой от снятия снимков экрана (screen capture protection), автоматическим сокрытием паролей и блокировкой буфера обмена.
Ни одно архитектурное решение не закрывает все угрозы одновременно. Задача выстроить эшелонированную защиту, где компрометация одного элемента не означает компрометацию всего.
Где происходит шифрование и почему это принципиально
Это, пожалуй, самый важный архитектурный вопрос.
Два сценария:
Два сценария:
Шифрование на стороне сервера (server-side encryption). Клиент отправляет данные по зашифрованному каналу TLS, сервер расшифровывает и хранит в своей базе — в открытом виде или зашифрованном своим ключом. Вендор имеет доступ к данным. При компрометации сервера или сотрудника вендора — данные утекают.
Шифрование на стороне клиента (client-side encryption). Данные шифруются на устройстве пользователя до отправки. Сервер получает зашифрованный массив байт и не имеет ключей для его расшифровки. Вендор технически лишён доступа к содержимому — это и называется принципом нулевого знания (zero-knowledge).
Разница не теоретическая. Когда в 2022 году были взломаны серверы LastPass, злоумышленники получили зашифрованные хранилища пользователей. Зашифрованные — но полностью, включая URL, имена пользователей, метаданные. Содержимое паролей было зашифровано на стороне клиента, но всё остальное — нет. Это частичная реализация zero-knowledge, которая на практике создала серьёзные риски.
Надёжная реализация шифрует на клиенте весь объект записи целиком: пароль, логин, URL, заметки, кастомные поля, вложения. Сервер работает с непрозрачными данными, не зная их структуры.
Как мастер-пароль превращается в ключ шифрования
Это место, где криптография становится конкретной. Мастер-пароль (master password) строка, которую знает только пользователь. Но AES-256 требует ключ фиксированной длины в 256 бит. Между паролем и ключом — функция формирования ключа (Key Derivation Function, KDF).
Просто хэшировать пароль — плохая идея. SHA-256 от строки «password123» вычисляется за микросекунды. На современной видеокарте можно проверить миллиарды вариантов в секунду. Словарные атаки и атаки по радужным таблицам (rainbow table attacks) делают это тривиальным.
KDF решает эту проблему двумя механизмами.
Соль (salt) случайное значение, добавляемое к паролю перед обработкой. Соль уникальна для каждого пользователя и хранится открыто. Её смысл — гарантировать, что два пользователя с одинаковым паролем получат разные ключи и что предвычисленные радужные таблицы бесполезны.
Растяжение ключа (key stretching) искусственное замедление вычисления. KDF намеренно требует много итераций, памяти или и того, и другого. Это делает перебор вариантов вычислительно дорогим.
Два основных алгоритма в современных менеджерах паролей:
PBKDF2 (Password-Based Key Derivation Function 2) стандарт, определённый в PKCS#5. Применяет хэш-функцию (обычно SHA-256 или SHA-512) многократно — типично 100 000–600 000 итераций. Хорошо изучен, поддерживается повсеместно. Уязвимость: хорошо распараллеливается на видеокартах (GPU) и специализированных чипах (ASIC), что делает атаки перебором относительно эффективными при большом бюджете атакующего.
Argon2 победитель конкурса Password Hashing Competition 2015 года. В отличие от PBKDF2, требует не только вычислений, но и памяти. Версия Argon2id — гибрид, устойчивый как к атакам по сторонним каналам (side-channel attacks), так и к GPU-атакам. Bitwarden перешёл на Argon2 после инцидента с LastPass именно из-за этих свойств.
На практике: чем современнее KDF и чем выше параметры итераций/памяти — тем дороже атака перебором. Но есть обратная сторона: слишком высокие параметры замедляют вход на слабых устройствах. Баланс — задача разработчика.
Иерархия ключей: почему не всё шифруется одним ключом
Наивная реализация: мастер-пароль → ключ → шифруем все записи этим ключом.
Проблема возникает при смене мастер-пароля: нужно перешифровать всю базу. Или при совместном доступе к папкам: у каждого пользователя свой мастер-пароль, как они получат доступ к одним и тем же данным?
Надёжная архитектура использует иерархию ключей.
Ключ шифрования данных (Data Encryption Key, DEK) генерируется случайно при создании хранилища, им шифруются сами записи. Пользователь его никогда не видит.
Ключ шифрования ключа (Key Encryption Key, KEK) выводится из мастер-пароля через KDF. Им шифруется DEK. DEK в зашифрованном виде хранится на сервере.
При смене мастер-пароля: перешифровывается только DEK, не вся база данных. При предоставлении доступа к папке другому пользователю: DEK этой папки шифруется публичным ключом получателя — он расшифровывает его своим приватным ключом.
Для персональных хранилищ (personal vaults) механизм аналогичный, но DEK защищён ключом, не связанным с корпоративным мастер-паролем администратора. Это обеспечивает гарантию: даже системный администратор не может прочитать личные записи сотрудника.
Аутентификация: как не передать мастер-пароль на сервер
Возникает парадокс: чтобы войти в систему, нужно доказать серверу, что знаешь мастер-пароль. Но передавать сам пароль — нельзя.
Решение: передавать не пароль и не ключ шифрования, а их производное. Схема:
- Из мастер-пароля и соли вычисляется ключ шифрования (KEK).
- Из KEK вычисляется отдельный хэш — верификатор аутентификации (auth verifier). Это второй проход KDF или хэш от KEK.
- На сервер передаётся только верификатор. Сервер сравнивает его с хранимым значением.
Это гарантирует: даже если трафик перехвачен или сервер скомпрометирован, злоумышленник получает верификатор — который бесполезен для расшифровки данных, потому что это не ключ шифрования.
Многофакторная аутентификация: не дополнение, а необходимость
Мастер-пароль — единственная точка отказа. Если он скомпрометирован — компрометировано всё. Многофакторная аутентификация (Multi-Factor Authentication, MFA) добавляет второй фактор, независимый от пароля.
Три класса факторов:
Что знаешь — мастер-пароль. Уязвим к фишингу, утечкам, подбору.
Что имеешь — одноразовый код (Time-based One-Time Password, TOTP) из приложения аутентификатора, аппаратный токен (например, Рутокен, YubiKey). Физическое устройство нельзя украсть удалённо.
Кто ты — биометрия (Face ID, Touch ID). Удобна, но не везде применима в корпоративном контексте.
Важный нюанс: MFA защищает вход в менеджер паролей — но не само хранилище данных. Если злоумышленник уже имеет зашифрованную базу (например, через компрометацию бэкапа), MFA ему не мешает. Это ещё один аргумент в пользу надёжного KDF с высокими параметрами.
Ролевая модель доступа: принцип минимальных привилегий на практике
В корпоративной среде не все пользователи должны видеть все пароли. Это не только вопрос удобства — это базовый принцип безопасности: доступ только к тому, что необходимо для работы (least privilege).
Надёжная ролевая модель (Role-Based Access Control, RBAC) в менеджере паролей:
Уровни доступа к элементам. Не просто «читать» и «редактировать» — полноценная гранулярность: чтение, создание, редактирование, удаление, управление доступами. Отдельно — доступ к структуре папок без видимости содержимого (для тех, кто организует хранилище, не имея доступа к секретам внутри).
Наследование прав. Права на папку автоматически распространяются на вложенные элементы, если не переопределены явно. Это упрощает администрирование, но требует аккуратности: непреднамеренное наследование — распространённая причина избыточного доступа.
Группы пользователей. Права выдаются не каждому пользователю отдельно, а группам. При изменении роли сотрудника — меняется группа, не сотни отдельных прав.
Сервисные учётные записи. Отдельные технические пользователи для автоматизации и интеграций с минимальным набором прав, только на нужные ресурсы.
Отдельная история, что происходит при увольнении. В хорошей архитектуре это одно действие: деактивация учётной записи мгновенно отзывает все доступы. Не «надо не забыть вручную убрать из каждой папки», а атомарная операция.
Журналирование: аудит как архитектурный элемент
Безопасность — это не только предотвращение инцидентов, но и способность их расследовать. Журнал событий (audit log) — полноценный архитектурный компонент, а не опциональная функция.
Что должно фиксироваться:
- каждый просмотр (снятие маски) пароля — кто, когда, с какого устройства
- создание, изменение, удаление записей и папок
- изменение прав доступа
- попытки входа — успешные и неуспешные
- экспорт данных
- действия через API
Критично: журнал должен быть защищён от модификации самим пользователем, даже администратором. Иначе он не имеет ценности при расследовании.
Возможность экспорта в систему управления событиями безопасности (SIEM, Security Information and Event Management) важна для организаций с зрелой службой информационной безопасности. Журнал менеджера паролей становится частью общей картины событий в инфраструктуре.
On-premise против облака: архитектурные последствия выбора
Вопрос о размещении данных не только про контроль и доверие, но и про архитектурные гарантии.
Облачное решение (SaaS). Зашифрованные данные хранятся на серверах вендора. При правильно реализованном zero-knowledge вендор не может их прочитать. Но атакующий, получив доступ к инфраструктуре вендора, получает зашифрованные хранилища всех клиентов сразу. Плюс: юрисдикционные запросы, регуляторное давление, инсайдеры вендора — всё это факторы риска, которые организация не контролирует.
Решение на собственном сервере (on-premise). Зашифрованные данные находятся на инфраструктуре организации. Даже при компрометации вендора —база недоступна. Организация сама управляет бэкапами, сетевой изоляцией, обновлениями. Требует компетенций в администрировании, но обеспечивает максимальный контроль.
Для организаций с повышенными требованиями — финансового сектора, государственных структур, критической инфраструктуры — on-premise не выбор из соображений паранойи, а требование регуляторов и внутренних политик. Приказ ФСТЭК №117, требования по локализации данных, ограничения на передачу сведений за пределы периметра — всё это прямо указывает на on-premise как единственно допустимый вариант.
Что проверить при выборе: технический чеклист
Резюмируя всё выше в практический список:
Шифрование. Происходит на стороне клиента? Что именно шифруется — только пароли или весь объект записи? Какой алгоритм AES-256 или ГОСТ (для российских требований)? Есть ли выбор алгоритма при развёртывании?
Функция формирования ключа (KDF). PBKDF2 или Argon2? Какие параметры — число итераций, объём памяти? Использование соли (salt)?
Аутентификация. Мастер-пароль передаётся на сервер? Как именно реализована верификация? Поддерживается ли MFA — и какие второй факторы: TOTP, биометрия, аппаратные токены?
Ролевая модель. Есть ли гранулярные уровни доступа? Можно ли создать сервисного пользователя с минимальными правами? Как обрабатывается увольнение один клик или ручная работа?
Журналирование. Фиксируется ли каждый просмотр пароля? Защищён ли журнал от модификации? Возможен ли экспорт в SIEM?
Независимый аудит безопасности (security audit). Проводился ли аудит сторонней компанией? Публикуются ли результаты?
Размещение. On-premise или облако? Соответствует ли это требованиям вашей организации и применимого законодательства?
BearPass: как эти принципы реализованы на практике
BearPass — корпоративный менеджер паролей с on-premise размещением. Архитектурные решения продукта соответствуют описанным принципам.
Шифрование AES-256 происходит на стороне клиента. Приватный ключ защищён мастер-паролем и не передаётся на сервер — это верифицируется в техническом описании архитектуры персональных хранилищ. Персональные хранилища сотрудников защищены отдельным ключом: администратор системы не имеет к ним доступа.
Ролевая модель включает четыре уровня доступа к элементам, включая отдельный тип «Структура» для папок — позволяющий управлять иерархией хранилища без видимости содержимого. При увольнении сотрудника деактивация учётной записи происходит одним действием.
Второй фактор аутентификации (2FA) поддерживается через TOTP, биометрию (Face ID, Touch ID) и аппаратные токены Рутокен — последнее важно для организаций, работающих в рамках российских регуляторных требований.
Для DevOps-сценариев доступны API и JWT-аутентификация через внешние провайдеры OIDC (Open ID Connect) конвейеры получают временные токены вместо статических ключей.
Выбор алгоритма шифрования при развёртывании включает поддержку ГОСТ критично для ряда отраслей.
Журналирование охватывает все действия с элементами, включая просмотр паролей и операции через API.
Продукт входит в Реестр российского программного обеспечения (№15427) и подходит для организаций, работающих по 44-ФЗ и 223-ФЗ.
Если хотите проверить архитектуру на практике попробуйте BearPass бесплатно или изучите документацию, там подробно описаны технические детали каждого компонента.
