NexTool Solutions

O Vaultwarden é uma reimplementação leve e open source do servidor Bitwarden, escrita em Rust. Fala o mesmo protocolo dos clientes oficiais do Bitwarden (extensão de navegador, aplicações móveis, desktop e CLI), mas corre inteiramente na sua própria infraestrutura - sem depender da cloud de terceiros. Na NexTool, é a peça que usamos para guardar os segredos da operação do service desk: palavras-passe de servidores, tokens de API, credenciais de acesso a ambientes de clientes e cofres partilhados por equipa, sempre a par do GLPI que já mantemos.

Porquê self-hosted para a gestão de segredos da operação

As equipas de suporte e infraestrutura acumulam um problema silencioso: dezenas de credenciais críticas espalhadas por folhas de cálculo, no Bitwarden pessoal de cada técnico, em notas de pedido ou - pior - em texto simples dentro do próprio pedido. O Vaultwarden resolve isto com um cofre central, com organizações, coleções e partilha por grupo, mantendo os dados dentro do seu perímetro. Para um cliente B2B que exige soberania dos dados (RGPD, contratos com cláusula de residência), o self-hosting não é uma preferência estética: é um requisito.

O consumo é modesto. Por ser Rust e SQLite por omissão, o contentor costuma correr com ~128-256 MB de RAM para equipas pequenas e médias, o que permite colocá-lo no mesmo anfitrião que já executa o GLPI, atrás do mesmo reverse proxy, sem aprovisionar uma máquina nova.

Artefacto: um docker-compose enxuto com hardening

Este é o esqueleto que usamos como ponto de partida. Repare que os registos vêm desativados (apenas por convite via SMTP), a porta é publicada só em 127.0.0.1 (quem expõe é o reverse proxy com TLS) e o ADMIN_TOKEN é um hash argon2, nunca a palavra-passe em texto simples:

version: "3.8"
services:
  vaultwarden:              # reimplementacao Rust do Bitwarden
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:            # variaveis 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 de administração é gerado com o próprio binário, e o valor em texto simples nunca toca o ficheiro:

# 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. 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 equipa de manutenção (a NexTool, por exemplo, quando assume o ambiente do cliente), o self-hosting compensa.

Passo a passo de implementação segura

O procedimento 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 à frente um reverse proxy (o mesmo que serve o GLPI) com certificado válido. O Vaultwarden exige HTTPS para os clientes funcionarem.
2. Desativar registos. SIGNUPS_ALLOWED=false fecha o registo aberto; ninguém cria uma conta sozinho. O acesso é sempre por convite.
3. ADMIN_TOKEN como hash argon2. Geramos o hash com o binário e guardamos apenas esse. O painel /admin passa a exigir esse token, e a palavra-passe em texto simples nunca fica no ficheiro.
4. SMTP para convites e alertas. Configuramos SMTP_* para que os convites de organização e as reposições saiam por correio autenticado do domínio.
5. Backup testado. Não basta copiar o SQLite a quente. Usamos sqlite3 .backup (consistente com a base em uso) mais os anexos e a chave RSA, e restauramos periodicamente num ambiente separado.
6. Atualização. A imagem latest muda depressa; fixamos a versão em produção e atualizamos com janela e backup fresco antes.

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

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

Como operamos na manutenção de clientes GLPI

Na manutenção de ambientes GLPI de clientes, usamos o Vaultwarden como cofre de operação: cada cliente torna-se uma organização, com coleções separadas por natureza (acessos de servidor, credenciais de API, contas de portal), e a equipa recebe acesso por grupo, não por palavra-passe avulsa. O erro comum que já vimos - inclusive antes de padronizar isto - foi deixar o ADMIN_TOKEN em texto simples no compose e submetê-lo por engano; por isso hoje é sempre um hash argon2 e o .env fica fora do controlo de versões. A outra decisão que tomámos foi colocar o Vaultwarden atrás do mesmo reverse proxy do GLPI, no mesmo anfitrião, reaproveitando TLS, monitorização e a rotina de backup. E o backup aprendemos a fazer bem: um cp do db.sqlite3 a quente pode capturar a base a meio de uma escrita e gerar um restauro corrompido - o sqlite3 .backup resolve isto, e sem a chave rsa_key o cofre simplesmente não abre depois. São pormenores que só aparecem quando se opera, não quando se lê o README.

Perguntas frequentes

Se mantém um ambiente GLPI e quer centralizar os segredos da operação com o apoio de quem já o faz, veja os nossos serviços de infraestrutura e cloud ou fale com a equipa.

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