Self-hosted менеджер паролей: что это на самом деле требует

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

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

Что на самом деле меняет self-hosting

Будьте здесь точны, потому что именно тут расходятся ожидания:

	Облако вендора	Self-hosted
Кто может прочитать ваше хранилище	Никто, если есть нулевое разглашение	Никто, если есть нулевое разглашение
Кто может удалить ваше хранилище	Вендор	Вы
Кто видит метаданные	Вендор	Вы
Кого можно принудить выдать данные	Вендор в его юрисдикции	Вы в вашей
Ответственность за время безотказности	Вендор	Вы
TLS, патчи, бэкапы	Вендор	Вы
Стоимость	Подписка	Сервер + ваше время

Заявление о конфиденциальности не меняется. Меняется контроль над плоскостью хранения и то, кто находится в цепочке доверия. Self-hosting убирает третью сторону; криптографию он не добавляет.

Когда это стоит того

• Вы уже запускаете сервисы и у вас есть NAS, домашняя лаборатория или небольшой VPS.
• Ваша модель угроз включает «провайдер скомпрометирован или принуждён».
• Вы находитесь в юрисдикции, где чужие услуги хранения данных — это риск.
• Вам нужны общие коллекции для команды на инфраструктуре, которую вы проверяете сами.
• Вы из тех, кому нравится пятиминутный Docker Compose и cron-задача.

Когда это не стоит того

• Вы никогда не запускали reverse proxy и сначала пришлось бы разобраться с TLS, DNS и правилами файрвола.
• Никто не будет вспоминать про патчи. Непропатченный сервер — это риск, а не выигрыш в безопасности.
• Вы единственный пользователь на одном устройстве. Тогда вообще пропустите сервер и используйте локальное хранилище.
• Вам нужна гарантированная доступность для бизнес-критичной системы без плана резервирования.

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

Настройка за пять минут

OpenKey Server — это приложение на FastAPI с PostgreSQL, поставляемое как стек Docker Compose.

cd openkey_server
cp .env.example .env
openssl rand -hex 32      # paste this into JWT_SECRET in .env
docker compose up --build -d

Затем убедитесь, что всё работает:

URL	Назначение
http://localhost:8000	Базовый API
http://localhost:8000/docs	Документация OpenAPI
http://localhost:8000/health	Проверка состояния

Миграции схемы выполняются автоматически при старте. Подключите клиент через Settings → Data → Self-hosted server, затем выполните Register на первом устройстве и Login на остальных. Все подробности: настройка сервера.

Чек-лист усиления защиты

Это часть, которую пропускают, и именно она решает, помог ли self-hosting. По руководству по безопасности:

Обязательно

1. Уникальный JWT_SECRET длиной не менее 32 символов. Значения-заглушки отклоняются при старте. Сгенерируйте свой, не копируйте пример.
2. HTTPS с действительным сертификатом. Клиенты используют системный TLS-стек без пининга сертификатов, поэтому URL с опечаткой в http:// или плохой сертификат открывают возможность man-in-the-middle при входе и синхронизации. Завершайте TLS на Caddy, nginx или вашем балансировщике.
3. Явный allow-list для CORS_ORIGINS. Никогда *. Если используете браузерное расширение, добавьте его origin'ы chrome-extension:// и moz-extension:// явно.
4. Postgres и сырой порт API остаются приватными. Открывайте только reverse proxy.
5. HSTS на прокси, чтобы браузеры никогда не откатывались на HTTP после первого визита.

Настоятельно рекомендуется

6. Лимиты частоты на reverse proxy. Встроенный ограничитель API хранится в памяти и действует на каждый процесс воркера, поэтому при нескольких воркерах или репликах эффективный лимит умножается. Добавьте limit_req в nginx или лимиты частоты на периметре в Caddy.
7. Выставляйте TRUST_PROXY_HEADERS=true, только если прокси перезаписывает X-Forwarded-For и вы доверяете этому пути. Иначе ваши лимиты по IP применяются к прокси, а не к пользователю.
8. Учитывайте перечисление email. POST /auth/prelogin и POST /auth/lookup-public-key возвращают 404 для неизвестных адресов, что помогает легитимным клиентам, но позволяет кому-то выяснить, какие адреса зарегистрированы. Строгие лимиты частоты, TLS и, опционально, VPN или allow-list IP для особо чувствительных развёртываний.
9. Делайте бэкап Postgres и проверяйте восстановление. Сервер менеджера паролей, который ни разу не восстанавливался из бэкапа, — это гипотеза.
10. Следите за /health и за логами API; поднимайте тревогу, если он перестал отвечать.

Что self-hosted сервер синхронизации может и чего не может

Он может	Он не может
Аутентифицировать вас по вашему auth_hash	Прочитать ваш мастер-пароль
Хранить непрозрачный шифротекст записей, вложений, организаций и доступов	Расшифровать имена коллекций или содержимое записей
Удалить или удержать ваши данные	Восстановить забытый мастер-пароль
Видеть метаданные: email, размеры шифротекста, тайминги	Собрать ваше хранилище из базы данных
Быть ограниченным частотой, пропатченным или перезапущенным вами	Пережить то, что вы забудете мастер-пароль

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

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

• Last-write-wins по revision каждого элемента, а не CRDT. Параллельные правки на двух устройствах могут перезаписать друг друга. Когда это важно, правьте на одном устройстве за раз.
• Удаления синхронизируются как надгробья, пока остальные устройства не догонят, поэтому удаление не действует мгновенно везде.
• Nearby LAN-синхронизация использует то же правило LWW между сопряжёнными устройствами со связанными хранилищами.
• Ни то, ни другое не является бэкапом. Держите хотя бы один зашифрованный локальный бэкап (.okbak в OpenKey).

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

Операционная безопасность оператора

• Запускайте сервер на хосте, который вы патчите по расписанию. Непропатченный хост хуже, чем хостинг у вендора.
• Держите JWT_SECRET в менеджере секретов или хотя бы в файле с правами 600, а не в истории командной строки.
• Хранение логов — это риск: логи синхронизации могут раскрывать тайминги и размеры. Ротируйте их и ограничивайте объём.
• Делайте бэкап базы данных, а не только тома, и проверяйте восстановление ежеквартально.
• Никогда не открывайте API в недоверенной сети без TLS.
• Если нужны гарантии доступности, поставьте второй хост за балансировщик и примите, что разрешение конфликтов синхронизации всё равно работает по правилу last-write-wins.

Как OpenKey делает сервер бесполезным для атакующего

• Клиенты выводят мастер-ключ с помощью Argon2id из email, мастер-пароля и соли.
• При входе отправляется auth_hash, доказывающий знание, но не раскрывающий пароль.
• Ключ хранилища шифрует имена коллекций и содержимое записей с помощью AES-256-GCM. Сервер хранит только обёрнутый ключ хранилища.
• Access JWT короткоживущие; refresh-токены хешируются в покое и ротируются при использовании.
• Вложения синхронизируются как шифротекст, до 20 MB каждый.

Украденный дамп postgres отдаёт атакующему соли, параметры KDF, обёрнутые ключи и блобы. Чтобы его взломать, нужно атаковать Argon2id, и даже после этого у атакующего остаётся шифротекст, который он не прочитает без ключа. Это весь аргумент безопасности, и он держится именно потому, что мастер-пароль никогда не покидал клиента.

Что говорят поисковые данные

Self-hosting — небольшой, но реальный кластер, и группируется он скорее вокруг фразы «open source», чем вокруг «self-hosted». Google Trends (по всему миру, последние 12 месяцев), сравнение этих терминов между собой:

Запрос	Относительный интерес в кластере
passbolt	100
open source password manager	55
password manager self hosted	13
self-hosted password manager	4
keepass alternative	1

Следствие: «open source» — фраза, к которой люди тянутся, а «self-hosted» — фраза, на которой они оказываются потом, то есть поиск начинается как предпочтение и превращается в реализацию. Связанные запросы по «open source password manager» указывают в ту же сторону: KeePass — 100, «open source password manager self hosted» — 84, Passbolt — 78. Две из трёх верхних строк — это названия, которые люди сравнивают, а не описания функции.

Рядом с основным термином эти числа всё равно невелики. «Self-hosted password manager» — ниша внутри ниши, и честный вывод в том, что большинство ищущих эту фразу — технические пользователи, которые уже знают, чего хотят.

Метод: Google Trends, по всему миру, последние 12 месяцев, данные за сентябрь 2026. Значения — нормализованный относительный интерес (0–100), а не объёмы поиска.

Версия за пять минут

Self-hosting меняет в цепочке доверия провайдера на вас. Он не добавляет криптографию — он добавляет в ваш список TLS, бэкапы, патчи и лимиты частоты. Если вы уже запускаете сервисы: стек Compose, уникальный JWT_SECRET, HTTPS с действительным сертификатом, явный CORS_ORIGINS и проверенные бэкапы. Если нет — используйте локальное зашифрованное хранилище и Nearby LAN-синхронизацию, и в любом случае держите хотя бы один зашифрованный офлайн-бэкап.

Следующие шаги

• Зачем self-host своё хранилище паролей — аргументы за
• Синхронизация с нулевым разглашением — протокол
• Настройка сервера — установка, настройка, усиление защиты в продакшене
• Безопасность — модель угроз и чек-лист оператора