NexTool Solutions

Vaultwarden — лёгкая open source реализация сервера Bitwarden, написанная на Rust. Он работает по тому же протоколу, что и официальные клиенты Bitwarden (расширение браузера, мобильные приложения, desktop и CLI), но полностью размещается в вашей инфраструктуре — без зависимости от стороннего облака. В NexTool это элемент, с помощью которого мы храним секреты службы поддержки: пароли серверов, API-токены, учётные данные для доступа к средам клиентов и общие хранилища команд — всегда рядом с GLPI, который мы уже сопровождаем.

Почему self-hosted для управления рабочими секретами

У команд поддержки и инфраструктуры копится тихая проблема: десятки критичных учётных данных разбросаны по таблицам, по личным Bitwarden каждого специалиста, по заметкам в заявках или — что хуже — открытым текстом внутри самой заявки. Vaultwarden решает это с помощью центрального хранилища с управлением организациями, коллекциями и общим доступом по группам, оставляя данные внутри вашего периметра. Для B2B-клиента, который требует суверенитета данных (LGPD, договоры с условием о месте хранения), self-hosted — не вопрос вкуса, а требование.

Потребление ресурсов скромное. Поскольку это Rust и по умолчанию SQLite, контейнер для небольших и средних команд обычно работает в ~128-256 МБ ОЗУ, что позволяет разместить его на том же хосте, где уже работает GLPI, за тем же обратным прокси, без выделения новой машины.

Артефакт: компактный docker-compose с усилением защиты

Это каркас, который мы используем как отправную точку. Обратите внимание: регистрация отключена (только приглашение через SMTP), порт публикуется только на 127.0.0.1 (наружу его выставляет обратный прокси с TLS), а ADMIN_TOKEN — это хеш argon2, а не пароль в открытом виде:

version: "3.8"
services:
  vaultwarden:              # reimplementação Rust do Bitwarden
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:            # variáveis de hardening
      DOMAIN: "https://vault.suaempresa.com"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      ADMIN_TOKEN: "$argon2id$v=19$m=65540,t=3,p=4$...hash..."
      SMTP_HOST: "smtp.suaempresa.com"
      SMTP_FROM: "[email protected]"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "[email protected]"
      SMTP_PASSWORD: "${SMTP_PASSWORD}"
    volumes:
      - ./vw-data:/data     # volume persistente (SQLite + anexos)
    ports:
      - "127.0.0.1:8080:80"

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

# gera o hash argon2 do ADMIN_TOKEN
docker run --rm -it vaultwarden/server /vaultwarden hash
# Cole o hash resultante em ADMIN_TOKEN (nunca a senha em texto plano)

Vaultwarden self-hosted vs Bitwarden Cloud

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

Тем, кто не хочет заниматься патчами, резервным копированием и TLS, честно говоря, подходит Bitwarden Cloud. Тем, у кого уже есть команда сопровождения (например, NexTool, когда берёт среду клиента на сопровождение), self-hosted окупается.

Пошаговое безопасное развёртывание

Порядок действий, который мы выполняем при запуске продуктивного Vaultwarden:

1. Обратный прокси с HTTPS. Мы публикуем сервис только на 127.0.0.1 и ставим перед ним обратный прокси (тот же, что обслуживает GLPI) с действительным сертификатом. Vaultwarden требует HTTPS для работы клиентов.
2. Отключить регистрацию. SIGNUPS_ALLOWED=false закрывает открытую регистрацию; никто не создаёт учётную запись сам. Доступ — всегда по приглашению.
3. ADMIN_TOKEN как хеш argon2. Мы генерируем хеш бинарником и храним только его. Панель /admin начинает требовать этот токен, а пароль в открытом виде никогда не остаётся в файле.
4. SMTP для приглашений и оповещений. Мы настраиваем SMTP_*, чтобы приглашения в организацию и сброс пароля отправлялись с аутентифицированной почты домена.
5. Проверенное резервное копирование. Недостаточно скопировать работающий SQLite. Мы используем sqlite3 .backup (согласованный с используемой базой) плюс вложения и ключ RSA и периодически восстанавливаем копию в отдельной среде.
6. Обновление. Образ latest меняется быстро; в продуктиве мы фиксируем версию и обновляемся в окно обслуживания со свежей резервной копией.

# backup consistente do banco (nunca cp do arquivo quente)
sqlite3 /srv/vaultwarden/vw-data/db.sqlite3 \
  ".backup '/backup/vaultwarden-$(date +%F).sqlite3'"

# anexos + chave RSA (sem eles o cofre não abre)
tar czf /backup/vw-attachments-$(date +%F).tgz \
  -C /srv/vaultwarden/vw-data attachments rsa_key config.json

Как мы работаем при сопровождении клиентов GLPI

При сопровождении клиентских сред GLPI мы используем Vaultwarden как рабочее хранилище: каждый клиент становится организацией с коллекциями, разделёнными по типу (доступы к серверам, учётные данные API, учётные записи порталов), а команда получает доступ по группам, а не через разрозненные пароли. Типичная ошибка, которую мы видели — в том числе до того, как стандартизировали это, — оставить ADMIN_TOKEN в открытом виде в compose и по ошибке закоммитить его; поэтому сегодня это всегда хеш argon2, а .env не попадает под версионирование. Другое принятое нами решение — разместить Vaultwarden за тем же обратным прокси, что и GLPI, на том же хосте, переиспользуя TLS, мониторинг и процедуру резервного копирования. А резервное копирование мы научились делать правильно: cp работающего db.sqlite3 может захватить базу посреди записи и привести к повреждённому восстановлению — sqlite3 .backup решает эту проблему, а без ключа rsa_key рядом хранилище потом просто не откроется. Такие детали проявляются, только когда вы эксплуатируете систему, а не когда читаете README.

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

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

Проверено командой NexTool Solutions.