Системы хранения паролей: типы, архитектура и критерии выбора в 2026 году

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

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

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

Прямой ответ на главный вопрос статьи: класс решения выбирают по тому, кто и как получает доступ к секретам. Для одного человека достаточно локального файла или облачного тарифа на одного пользователя. Для команды нужны общий сервер, роли и журнал. Для организации добавляются требования ИБ: разграничение прав, ротация секретов, выгрузка событий в SIEM и контроль доступа к инфраструктурным учётным записям. Четыре класса решений (локальные, облачные, self-hosted и PAM) закрывают эти сценарии с разной ценой и разной степенью контроля.

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

Модель доверия отвечает на вопрос, кому вы передаёте возможность расшифровать данные. Вариантов три: только себе (локальный файл), вендору сервиса (облако) и своей инфраструктуре (self-hosted). PAM-системы добавляют четвёртый: своей инфраструктуре плюс вендору ПО, который поставляет ротацию и запись сессий. Модель доверия определяет, что произойдёт при компрометации стороны. В облачной схеме вендор видит зашифрованные блобы и метаданные, но управляет доступностью сервиса. В self-hosted всё зависит от ваших бэкапов, обновлений и настройки TLS.

Шифрование хранилища паролей описывают двумя слоями. Первый слой, шифр данных: AES-256-CBC, AES-256-GCM или ChaCha20-Poly1305. Второй слой, вывод ключа из мастер-пароля: Argon2id, scrypt или PBKDF2-HMAC-SHA256 с большим числом итераций. В формате KDBX 4 доступны AES-256 и ChaCha20, а ключ выводится через Argon2d или Argon2id с настраиваемыми параметрами памяти и числа итераций. Ключевой вопрос практики: где именно выполняется шифрование. В клиентских менеджерах секрет шифруется на устройстве пользователя, сервер хранит блоб и прочитать его не может. Как устроены клиентская, серверная и гибридная модели и где хранить ключи, разобрано в материале о шифровании данных при передаче и хранении.

Синхронизация паролей между устройствами бывает четырёх видов: через облако вендора, через собственный сервер, через файл в облачном диске (Nextcloud, Syncthing) и через Git. У файловой синхронизации есть особенность: база KDBX меняется целиком, поэтому конфликт версий превращается в копию с пометкой conflicted copy. При двух активных устройствах конфликты появляются еженедельно, а ручное слияние занимает время и легко приводит к потере части записей.

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

Классификация решений: локальные, облачные, self-hosted и PAM

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

Локальные хранилища: KeePass и KeePassXC

Архитектура проста: один зашифрованный файл базы KDBX и мастер-пароль. Дополнительно подключают ключевой файл, аппаратный токен (YubiKey в режиме challenge-response) и второй фактор. KeePassXC - кроссплатформенный форк KeePass с нативными сборками под Windows, Linux и macOS, расширением KeePassXC-Browser для автозаполнения, поддержкой TOTP и очисткой буфера обмена по таймауту.

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

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

Облачные сервисы: Bitwarden и 1Password

Клиент шифрует секрет, сервер получает зашифрованный блоб и метаданные. Мастер-пароль и производный ключ остаются на устройстве. Bitwarden развивается с открытым кодом, поддерживает браузерные расширения, CLI, TOTP, отчёты о слабых и повторно используемых паролях, а также командные тарифы и SSO в старших планах. 1Password использует закрытый код и схему с Secret Key: дополнительный секрет, который не вводится руками и не хранится в облаке рядом с мастер-паролем.

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

Ориентиры по цене на 2026 год: Bitwarden Teams около 4 долларов за пользователя в месяц при годовой оплате, Enterprise около 6, 1Password Business около 8. Прайс меняется, сверяйтесь на дату закупки.

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

Self-hosted платформы: Vaultwarden, Passbolt, Bitwarden self-hosted

Vaultwarden - реализация серверного API Bitwarden на Rust. Официальные клиенты Bitwarden подключаются к нему по URL, включая мобильные приложения и браузерные расширения. Потребление памяти на 10-20 пользователей измеряется сотнями мегабайт, база данных поддерживает SQLite, PostgreSQL и MariaDB, есть административная панель и организации для общих коллекций.

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

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

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

Корпоративные PAM-системы: управление привилегированным доступом

PAM расшифровывается как privileged access management, управление привилегированным доступом. Такие системы работают не с личными паролями сотрудников, а с инфраструктурными учётными записями: root на серверах, администраторы СУБД, сервисные аккаунты, API-ключи. Типовые функции: ротация секретов по расписанию, выдача доступа по запросу на ограниченное время, запись сессий SSH и RDP, интеграция с Active Directory и LDAP, полный журнал обращений к каждому секрету.

Примеры: Teleport, HashiCorp Vault с модулем управления секретами, CyberArk, Delinea, BeyondTrust. Разница между ними проявляется на уровне интеграций и модели развёртывания; сравнение Vault, AWS Secrets Manager и Azure Key Vault для production приведено в отдельном разборе хранилищ секретов.

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

Сравнение решений по ключевым критериям: таблица и пояснения

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

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

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

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

Стоимость владения складывается из подписки и трудозатрат. Подписка на 20 пользователей в облаке обойдётся примерно в 1000-1600 долларов в год. Self-hosted при том же числе людей стоит дешевле по лицензиям, но требует 4-8 часов работы администратора в месяц на обновления, бэкапы и разбор инцидентов. PAM считают не по числу пользователей, а по числу управляемых ресурсов, и проект развёртывания занимает недели.

Как читать таблицу под свой сценарий

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

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

Корпоративный сценарий. На первый план выходят аудит, интеграция с SSO и каталогами, ротация секретов и соответствие внутренним требованиям ИБ. Стоимость уходит на второе место, потому что цена инцидента выше цены лицензий. Здесь обычно нужны два класса сразу: self-hosted менеджер паролей для сотрудников и PAM для инфраструктурных учётных записей.

Архитектура self-hosted хранилища: из чего состоит и что учесть

Типовой self-hosted контур включает reverse proxy с TLS (Nginx, Caddy, Traefik), сервер приложения, базу данных, хранилище бэкапов, систему мониторинга и клиенты. Поток данных выглядит так: клиент шифрует секрет, отправляет зашифрованный блоб на сервер, сервер сохраняет его в базе, при запросе клиент скачивает блоб и расшифровывает локально. Мастер-пароль и производный ключ на сервер не попадают.

Практические рекомендации для такого контура:

• Разворачивать приложение в Docker или Docker Compose, чтобы обновление сводилось к смене тега образа и перезапуску контейнера.
• Использовать PostgreSQL вместо SQLite, когда в системе больше 10 активных пользователей или включены организации с общими коллекциями.
• Обязательно закрывать сервис TLS с автоматическим продлением сертификата и включать HSTS. Без TLS мастер-пароль и токены сессий идут по сети открытым текстом.
• Настроить ежедневный бэкап тома с данными и дампа базы, хранить копии отдельно от сервера. Для выбора места под копии полезен разбор того, как устроены разные типы хранилищ, в обзоре систем хранения данных.
• Раз в квартал проверять восстановление из бэкапа на отдельной машине, а не только факт создания архива.
• Мониторить доступность эндпоинта и свободное место на диске, потому что переполненный раздел останавливает запись новых секретов.

Bitwarden self-hosted требует заметно больше ресурсов, чем Vaultwarden: несколько контейнеров и отдельная СУБД, поэтому для небольшой команды выгоднее лёгкий вариант. Типовая ошибка начинающих: развернуть сервер без TLS и бэкапов, а через месяц потерять базу при сбое диска.

Vaultwarden настройка: минимальный рабочий контур

Минимальный контур собирается из одного контейнера, reverse proxy и тома с данными. Критичные переменные окружения при запуске: DOMAIN с полным адресом по HTTPS, ADMIN_TOKEN для доступа к административной панели, SIGNUPS_ALLOWED в значении false после создания учётных записей, SMTP для приглашений и восстановления, DATABASE_URL при переходе на PostgreSQL. Отдельно стоит задать лимит на размер вложений и включить WebSocket в reverse proxy, иначе синхронизация между устройствами работает с задержкой.

Административную панель закрывают по IP или VPN и не публикуют в интернет, а ADMIN_TOKEN делают длинной случайной строкой: это фактически второй мастер-ключ сервера. Под Vaultwarden достаточно виртуального сервера с 2 vCPU и 2 GB RAM, такой конфигурации хватает на команду из 10 человек; подойдёт, например, облачный сервер у Timeweb Cloud, где ресурсы меняются по мере роста команды.

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

Passbolt и Bitwarden self-hosted: когда выбирать их

Vaultwarden удобен лёгкостью и совместимостью с клиентами Bitwarden, но часть корпоративных функций в нём отсутствует или появляется с задержкой. Passbolt выбирают, когда нужна строгая командная модель на OpenPGP, группы, роли и журнал из коробки. Bitwarden self-hosted берут, если требуется официальная поддержка, полный набор функций и готовность содержать более тяжёлую инфраструктуру.

Простое правило выбора: 5-20 человек, ограниченный бюджет и важен размер сервера, берём Vaultwarden; нужна строгая модель доступа и аудит без доработок, берём Passbolt; нужна поддержка вендора и соответствие формальным требованиям, берём Bitwarden self-hosted.

Безопасность и аудит в корпоративной среде

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

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

Разница между PAM и менеджером паролей в корпоративной среде видна на примере. Компания разворачивает Passbolt для командных паролей: доступ к базе данных, панелям подрядчиков, токенам CI. Отдельно ставит Teleport или Vault для доступа к серверам: администратор не знает root-пароль, получает доступ на 2 часа по заявке, все команды записываются, а пароль ротируется после завершения сессии. Менеджер паролей без PAM не закроет требование ротации и не запишет сессию, PAM без менеджера паролей неудобен для повседневной работы сотрудников.

Что должно попадать в журнал аудита

Полезный журнал содержит конкретные события, а не факт «пользователь был активен»:

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

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

Чек-лист критериев для быстрого отсева неподходящих решений

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

1. Кто пользователи: один человек, команда или организация с несколькими отделами. Один пользователь отсекает PAM как избыточный, организация отсекает локальный файл.
2. Нужна ли синхронизация между устройствами. Ответ «нет» оставляет локальное хранилище, ответ «да, автоматически» требует облака или self-hosted сервера.
3. Нужен ли аудит доступа. Если да, локальные хранилища выбывают сразу.
4. Есть ли запрет на передачу секретов внешнему вендору. Если да, остаются self-hosted и PAM.
5. Есть ли собственный сервер и готовность его обслуживать. Без этого self-hosted превращается в источник инцидентов, и разумнее взять облако.
6. Нужна ли интеграция с SSO и каталогами (LDAP, Active Directory). Это требование отсекает бесплатные тарифы и часть self-hosted платформ без доработок.
7. Какой бюджет на пользователя в месяц. Облако стоит от 4 до 8 долларов за человека, self-hosted заменяет подписку стоимостью сервера и времени администратора.
8. Нужна ли ротация секретов по расписанию. Для сервисных учётных записей и API-ключей это требование ведёт к PAM.
9. Нужны ли поддержка и SLA. Если да, открытые сборки без вендорской поддержки выбывают.
10. Какой уровень сложности развёртывания приемлем. Облако занимает час, Vaultwarden - день, Bitwarden self-hosted или PAM - недели.

Пример прохода по чек-листу: команда 15 человек, свой сервер есть, аудит нужен, бюджет ограничен, SSO не требуется, ротация сервисных аккаунтов не стоит в требованиях. Ответы оставляют два кандидата: Vaultwarden и Passbolt. Между ними выбор идёт по наличию строгой модели доступа: если группы и журнал нужны из коробки, берут Passbolt, если важнее лёгкость и совместимость с клиентами Bitwarden, берут Vaultwarden.

Типичные ошибки при внедрении и как их избежать

• Нет бэкапов хранилища. Последствие: потеря всех секретов при сбое диска или неудачном обновлении. Решение: ежедневный бэкап тома и дампа базы, отдельное место хранения, ежеквартальная проверка восстановления.
• Слабый мастер-пароль или его потеря. Последствие: расшифровать базу невозможно ничем, восстановление не предусмотрено. Решение: политика длины мастер-пароля, менеджер для его хранения отдельно от основной базы, аварийный доступ в опечатанном конверте для второго администратора.
• Отсутствие TLS. Последствие: перехват мастер-пароля, токенов сессий и содержимого запросов в локальной сети. Решение: обязательный TLS с автоматическим продлением, редирект с HTTP, HSTS.
• Открытая административная панель. Последствие: компрометация сервера через подбор ADMIN_TOKEN или уязвимость в панели. Решение: доступ только по VPN или по списку IP, длинный случайный токен, отдельный администратор без повседневных задач.
• Игнорирование обновлений. Последствие: известные уязвимости остаются открытыми месяцами. Решение: фиксированная процедура обновления раз в месяц, подписка на уведомления о CVE для используемых версий, тестовый контур перед продом.
• Аудит не включён с первого дня. Последствие: при инциденте нельзя установить, кто читал секрет до появления журналирования. Решение: включить журналирование и выгрузку в SIEM до миграции пользователей.
• Один администратор и никакой документации. Последствие: уход специалиста останавливает обслуживание хранилища. Решение: записанный порядок бэкапа, восстановления и обновления, доступ к серверу у двух человек.

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

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

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

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