Свой менеджер паролей вместо подписки: расчёт на офис в 40 человек

MAATRIX

Когда в компании 40 человек, вопрос менеджера паролей рано или поздно упирается в счёт от провайдера: команда растёт, растут и ежемесячные списания за корпоративный тариф. Кто-то в этот момент открывает GitHub, находит open-source решение вроде Vaultwarden и думает: «А зачем платить, если можно поднять на своём сервере?» Разберём это решение честно — с методикой расчёта тарифов, реальной стоимостью своего сервера и администрирования, и главное — с трезвым взглядом на то, что self-hosted менеджер паролей означает лично вашу ответственность за самое чувствительное хранилище в компании.

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

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

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

• Минимальное число мест. Многие тарифы продаются не поштучно, а блоками — например, «от 10 мест» с фиксированной стоимостью блока, и переход в следующий блок случается сразу на весь диапазон, а не плавно на одного человека.
• Годовая vs помесячная оплата. Годовой контракт обычно даёт скидку 15-20% к номинальной месячной цене, но требует оплаты вперёд — для российской компании это отдельный вопрос, потому что многие зарубежные сервисы не принимают карты РФ и оплату приходится вести через посредников или крипту.
• Уровни тарифа. Базовый (хранилище + автозаполнение), командный (общие сейфы, роли), корпоративный (SSO/SCIM-интеграция, детальные security-отчёты, приоритетная поддержка). Переход с базового на корпоративный часто удваивает цену за пользователя, а не добавляет фиксированную наценку.
• Надбавки за функции безопасности. Мониторинг утечек по доменам, отчёты о слабых/переиспользуемых паролях, принудительная ротация — у части провайдеров это входит в тариф, у части продаётся отдельно.

Формула итоговой стоимости в месяц для команды из N человек выглядит примерно так:

Стоимость = N × P × (уровень тарифа) + фикс.надбавки (SSO, отчёты, поддержка)

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

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

Что нужно поднять для self-hosted менеджера паролей

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

Для 40 человек хватает скромного VPS: 1-2 vCPU, 2-4 ГБ RAM, 20-40 ГБ SSD — сама база данных с паролями весит немного, нагрузку создают в основном синхронизации клиентов, а не объём данных. Мы разворачивали похожие сервисы под похожую нагрузку — детали именно для Vaultwarden и частые ошибки при установке разобраны в отдельном пошаговом гайде по установке Vaultwarden на VPS.

Минимальный набор компонентов:

# docker-compose.yml — упрощённый пример
services:
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "false"      # только приглашения админом
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      SMTP_HOST: "smtp.example.com" # для приглашений и 2FA-писем
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8080:80"
# + обратный прокси (Caddy/Nginx) с TLS перед ним — без него клиенты не подключатся

Обязательные, а не опциональные пункты для продакшена:

• TLS обязателен. Клиенты Bitwarden просто откажутся синхронизироваться по HTTP — это не рекомендация, а жёсткое требование протокола.
• Отключить самостоятельную регистрацию (SIGNUPS_ALLOWED=false) сразу после того, как завели администратора и пригласили первых людей — иначе сервер открыт для регистрации кем угодно, кто узнает адрес.
• Резервное копирование папки данных — это единственная копия всех паролей компании, и её нужно бэкапить не реже раза в сутки, желательно на отдельное хранилище вне того же сервера.
• Двухфакторная аутентификация для всех аккаунтов — Vaultwarden поддерживает TOTP и WebAuthn, и включать её нужно централизованно через политику организации, а не полагаться на добрую волю сотрудников.

Сравнение самого Vaultwarden с официальным Bitwarden как продуктом — отдельная тема, она подробно разобрана в статье Vaultwarden против Bitwarden: что выгоднее и когда, если нужно решить именно между self-hosted вариантами.

Стоимость своего сервера и администрирования

Здесь считать сложнее, чем кажется, потому что «просто арендовать VPS» — это только часть стоимости владения.

Прямые расходы на инфраструктуру:

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

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

• регулярных обновлений образа и ОС (уязвимости в компонентах, на которых стоит сервис с паролями всей компании, — не то, что можно откладывать);
• контроля бэкапов — не просто их наличия, а периодической проверки, что из бэкапа реально можно восстановиться;
• разбора инцидентов — забытый пароль администратора, сбой синхронизации у части клиентов, истёкший TLS-сертификат;
• мониторинга подозрительной активности — попыток брутфорса на форму входа, аномальных обращений к admin-панели.

Если считать это в часах администратора в месяц, для сервиса с 40 пользователями реалистичная оценка — от 1 до 3 часов в месяц в спокойном режиме, и заметно больше в месяц миграции или инцидента. Дальше вопрос — чей это час: штатного сисадмина, у которого и так есть другие задачи, или внешнего подрядчика с почасовой оплатой. Методика перевода часов админа в деньги и точка, где выгоднее доплатить за managed-решение, разобрана в статье «Сколько стоит час админа и когда дешевле доплатить» — тот же принцип применим и здесь.

Итоговая формула стоимости владения self-hosted решением:

Стоимость = цена VPS + цена бэкап-хранилища + (часы админа в месяц × ставка часа)

Ключевой честный момент: если вписать сюда реальную рыночную ставку часа квалифицированного администратора, а не «ноль, потому что это же я сам между делом», картина может измениться radikально не в пользу self-hosted — особенно если этот человек мог бы в те же часы делать что-то, что прямо приносит компании деньги.

Расчёт для офиса в 40 человек: иллюстративный пример

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

Предположим (только для примера):

• облачная подписка командного тарифа — P = 350 ₽ за пользователя в месяц;
• VPS под Vaultwarden — 900 ₽ в месяц;
• хранилище под бэкапы — 150 ₽ в месяц;
• администрирование — 2 часа в месяц по ставке 2000 ₽/час.

Облако:

40 × 350 ₽ = 14 000 ₽/мес → 168 000 ₽/год

Self-hosted:

900 + 150 + (2 × 2000) = 5 050 ₽/мес → 60 600 ₽/год

В этом условном примере self-hosted выглядит почти в 2,8 раза дешевле — и именно такие цифры чаще всего показывают в статьях «сколько мы сэкономили». Но у этого расчёта есть слепая зона: он не учитывает риск инцидента. Если сервер с паролями компании скомпрометируют, а восстановление и разбор займут 20-40 часов работы команды плюс репутационные издержки (уведомление клиентов, партнёров, возможные регуляторные обязательства) — экономия в 107 000 ₽/год исчезает за один плохой месяц.

Точка перелома, где self-hosted перестаёт быть выгодным даже без учёта рисков, обычно наступает не из-за числа пользователей (40 человек — всё ещё «дёшево» по вычислительным ресурсам), а из-за роста требований к комплаенсу: как только компании нужен SSO с корпоративным IdP, детальный аудит-лог для проверяющих или SOC2-подобная отчётность — держать это своими силами становится дороже, чем платить за корпоративный тариф, который эти функции уже включает.

Безопасность: где заканчивается ответственность провайдера и начинается ваша

Это самая важная часть статьи, и здесь честность важнее красивой экономии.

Когда вы платите за облачный менеджер паролей, вы платите не только за софт — вы покупаете чужую специализацию в защите именно этого типа данных. У серьёзного провайдера есть команда, которая занимается только этим: аудит инфраструктуры, bug bounty, мониторинг аномалий 24/7, процедуры реагирования на инциденты, обычно независимые security-аудиты и сертификации. Это не гарантия отсутствия инцидентов — утечки случались и у крупных менеджеров паролей, — но это профессиональная защита как основной продукт, а не побочная задача.

Когда вы разворачиваете Vaultwarden на своём сервере, вся эта защита становится вашей личной задачей — и это касается не только настройки, но и постоянного сопровождения:

• Обновления безопасности. Уязвимость в самом Vaultwarden, в Docker, в ядре ОС, в TLS-библиотеке — вы должны узнать о ней и закрыть её сами, оперативно. У облачного провайдера это процесс, работающий на потоке; у вас — то, о чём должен вспомнить конкретный человек.
• Защита сервера от компрометации. Правильный firewall, закрытые порты, SSH-доступ только по ключу, доступ к admin-панели Vaultwarden ограничен по IP или VPN — каждая из этих настроек по отдельности несложная, но пропуск любой одной превращает сервер с паролями всей компании в открытую цель.
• Мониторинг и обнаружение атак. У вас, скорее всего, нет SOC и нет автоматизированного анализа аномалий — попытку брутфорса или медленную разведку злоумышленника вы, вероятно, заметите постфактум, если вообще заметите.
• Bus factor. Если человек, который поднимал и понимает инфраструктуру, уходит из компании, а документация неполная — сервер с паролями остаётся в состоянии «работает, но никто толком не знает как» — это операционный риск, а не гипотетический.
• Юридическая ответственность за инцидент. При утечке паролей из облачного сервиса есть к кому предъявить претензии по контракту (SLA, страхование ответственности провайдера). При утечке со своего сервера отвечает перед сотрудниками и клиентами компания — целиком и без посредника.

Это не аргумент «self-hosted — всегда плохая идея». Это аргумент за то, что решение принимается не только по строке в Excel с суммой экономии. Если в компании есть человек, который реально разбирается в защите Linux-серверов, готов регулярно этим заниматься и понимает цену ошибки — self-hosted вариант рабочий и используется многими техническими командами. Если такого человека нет, а Vaultwarden ставит и забывает единственный админ, у которого это тридцатая задача в очереди, — экономия на бумаге компенсируется реальным риском, невидимым в ежемесячном счёте.

Честный компромисс: некоторые облачные провайдеры дают community/free-тарифы с ограничениями по числу мест или функций — иногда их хватает небольшой команде и они снимают часть рисков self-hosted почти бесплатно. Стоит проверить, укладывается ли компания в такие лимиты, прежде чем сразу разворачивать свой сервер.

Когда self-hosted оправдан, а когда нет

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

Self-hosted обычно оправдан, если:

• в команде уже есть человек с опытом администрирования Linux-серверов и практикой безопасности, который будет заниматься этим на регулярной основе, а не разово;
• компания уже держит другую инфраструктуру на своих серверах (VPN, почту, CI/CD) — значит, процессы обновления, мониторинга и бэкапов уже выстроены и добавить ещё один сервис — предельная стоимость, а не создание процесса с нуля;
• есть требования по локализации или суверенитету данных, которые сложно закрыть облачным сервисом с серверами в другой юрисдикции;
• команда готова инвестировать время в написание внутреннего регламента (кто имеет доступ, как ротируются мастер-пароли, как выглядит процедура при увольнении сотрудника).

Облачная подписка обычно предпочтительнее, если:

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

Практичный средний путь для команды в 40 человек — тестовый период: поднять Vaultwarden параллельно действующей подписке на небольшую группу (например, ИТ-отдел), пройти с ним хотя бы один цикл обновлений и один имитированный инцидент восстановления из бэкапа, и только после этого переводить всю компанию. Это добавляет месяц-два к переходу, но снимает большую часть рисков «мы не проверяли, а сервер оказался не готов».

Частые вопросы