NexTool Solutions

Vaultwarden é uma reimplementação leve e open source do servidor Bitwarden, escrita em Rust. Ele fala o mesmo protocolo dos clientes oficiais do Bitwarden (extensão de navegador, apps mobile, desktop e CLI), mas roda inteiramente na sua infraestrutura - sem depender da nuvem de terceiros. Na NexTool, ele é a peça que usamos para guardar os segredos da operação de service desk: senhas de servidores, tokens de API, credenciais de acesso a ambientes de clientes e cofres compartilhados por equipe, sempre ao lado do GLPI que já sustentamos.

Por que self-hosted para gestão de segredos de operação

Times de suporte e infraestrutura acumulam um problema silencioso: dezenas de credenciais críticas espalhadas em planilhas, no Bitwarden pessoal de cada técnico, em anotações de chamado ou - pior - em texto plano dentro do próprio ticket. Vaultwarden resolve isso com um cofre central, com controle de organizações, coleções e compartilhamento por grupo, mantendo os dados dentro do seu perímetro. Para um cliente B2B que exige soberania de dados (LGPD, contratos com cláusula de residência), self-hosted não é preferência estética: é requisito.

O consumo é modesto. Por ser Rust e SQLite por padrão, o container costuma rodar em ~128-256 MB de RAM para times pequenos e médios, o que permite colocá-lo no mesmo host que já hospeda o GLPI, atrás do mesmo reverse proxy, sem provisionar máquina nova.

Artefato: docker-compose enxuto com hardening

Este é o esqueleto que usamos como ponto de partida. Note que os signups vêm desativados (só convite via SMTP), a porta é publicada apenas em 127.0.0.1 (quem expõe é o reverse proxy com TLS) e o ADMIN_TOKEN é um hash argon2, nunca a senha crua:

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: "vault@suaempresa.com"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "vault@suaempresa.com"
      SMTP_PASSWORD: "${SMTP_PASSWORD}"
    volumes:
      - ./vw-data:/data     # volume persistente (SQLite + anexos)
    ports:
      - "127.0.0.1:8080:80" 

O hash do painel administrativo é gerado com o próprio binário, e o valor em texto plano nunca toca o arquivo:

# 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

A escolha não é ideológica. Ela depende de quem carrega o esforço operacional e de quão sensível é o dado:

Para quem não quer carregar patch, backup e TLS, o Bitwarden Cloud é honestamente a resposta certa. Para quem já tem equipe de sustentação (a NexTool, por exemplo, quando assume o ambiente do cliente), o self-hosted paga a conta.

Passo a passo de implantação segura

O roteiro que executamos ao subir um Vaultwarden de produção:

1. Reverse proxy com HTTPS. Publicamos o serviço só em 127.0.0.1 e colocamos um reverse proxy (o mesmo que serve o GLPI) com certificado válido na frente. Vaultwarden exige HTTPS para os clientes funcionarem.
2. Desativar signups. SIGNUPS_ALLOWED=false fecha o cadastro aberto; ninguém cria conta sozinho. O acesso é sempre por convite.
3. ADMIN_TOKEN como hash argon2. Geramos o hash com o binário e guardamos apenas ele. O painel /admin passa a exigir esse token, e a senha em texto plano nunca fica no arquivo.
4. SMTP para convites e alertas. Configuramos SMTP_* para que os convites de organização e a redefinição saiam por e-mail autenticado do domínio.
5. Backup testado. Não basta copiar o SQLite quente. Usamos sqlite3 .backup (consistente com o banco em uso) mais os anexos e a chave RSA, e restauramos em ambiente separado periodicamente.
6. Atualização. A imagem latest muda rápido; fixamos versão em produção e subimos com janela e backup fresco antes.

# 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

Como operamos na sustentação de clientes GLPI

Na sustentação de ambientes de clientes GLPI, usamos o Vaultwarden como cofre de operação: cada cliente vira uma organização, com coleções separadas por natureza (acessos de servidor, credenciais de API, contas de portal), e a equipe recebe acesso por grupo, não por senha avulsa. O erro comum que já vimos - inclusive antes de padronizar isso - foi deixar o ADMIN_TOKEN em texto plano no compose e commitá-lo por engano; por isso ele hoje é sempre hash argon2 e o .env fica fora do versionamento. A outra decisão que tomamos foi colocar o Vaultwarden atrás do mesmo reverse proxy do GLPI, no mesmo host, reaproveitando TLS, monitoramento e a rotina de backup. E o backup a gente aprendeu a fazer direito: cp do db.sqlite3 quente pode capturar o banco no meio de uma escrita e gerar restore corrompido - o sqlite3 .backup resolve isso, e sem a chave rsa_key junto o cofre simplesmente não abre depois. São detalhes que só aparecem quando você opera, não quando você lê o README.

Perguntas frequentes

Se você sustenta um ambiente GLPI e quer centralizar os segredos da operação com apoio de quem já faz isso, veja nossos serviços de infraestrutura e cloud ou fale com a equipe.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.