NexTool Solutions

Vaultwarden è una reimplementazione leggera e open source del server Bitwarden, scritta in Rust. Parla lo stesso protocollo dei client ufficiali Bitwarden (estensione del browser, app mobile, desktop e CLI), ma gira interamente sulla tua infrastruttura - senza dipendere dal cloud di terzi. In NexTool è il tassello che usiamo per custodire i segreti dell'operatività del service desk: password dei server, token API, credenziali di accesso agli ambienti dei clienti e cassaforti condivise per team, sempre accanto al GLPI che già manteniamo.

Perché self-hosted per gestire i segreti operativi

I team di supporto e infrastruttura accumulano un problema silenzioso: decine di credenziali critiche sparse in fogli di calcolo, nel Bitwarden personale di ogni tecnico, nelle note dei ticket o - peggio - in chiaro dentro il ticket stesso. Vaultwarden lo risolve con una cassaforte centrale, con organizzazioni, raccolte e condivisione per gruppo, mantenendo i dati dentro il tuo perimetro. Per un cliente B2B che richiede sovranità dei dati (GDPR, contratti con clausola di residenza), il self-hosting non è una preferenza estetica: è un requisito.

Il consumo è modesto. Essendo Rust e SQLite di default, il container di solito gira con ~128-256 MB di RAM per team piccoli e medi, il che consente di collocarlo sullo stesso host che già esegue GLPI, dietro lo stesso reverse proxy, senza fornire una macchina nuova.

Artefatto: un docker-compose snello con hardening

Questo è lo scheletro che usiamo come punto di partenza. Nota che le registrazioni sono disattivate (solo su invito via SMTP), la porta è pubblicata solo su 127.0.0.1 (è il reverse proxy a esporre in TLS) e ADMIN_TOKEN è un hash argon2, mai la password in chiaro:

version: "3.8"
services:
  vaultwarden:              # reimplementazione Rust di Bitwarden
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:            # variabili di 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 + allegati)
    ports:
      - "127.0.0.1:8080:80" 

L'hash del pannello di amministrazione si genera con il binario stesso, e il valore in chiaro non tocca mai il file:

# genera l hash argon2 di 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 contro Bitwarden Cloud

La scelta non è ideologica. Dipende da chi si fa carico dello sforzo operativo e da quanto è sensibile il dato:

Per chi non vuole farsi carico di patch, backup e TLS, Bitwarden Cloud è onestamente la risposta giusta. Per chi ha già un team di manutenzione (NexTool, ad esempio, quando prendiamo in carico l'ambiente del cliente), il self-hosting conviene.

Distribuzione sicura passo per passo

La routine che eseguiamo per mettere in piedi un Vaultwarden di produzione:

1. Reverse proxy con HTTPS. Pubblichiamo il servizio solo su 127.0.0.1 e mettiamo davanti un reverse proxy (lo stesso che serve GLPI) con certificato valido. Vaultwarden richiede HTTPS perché i client funzionino.
2. Disattivare le registrazioni. SIGNUPS_ALLOWED=false chiude la registrazione aperta; nessuno crea un account da solo. L'accesso è sempre su invito.
3. ADMIN_TOKEN come hash argon2. Generiamo l'hash con il binario e conserviamo solo quello. Il pannello /admin richiede quindi questo token, e la password in chiaro non resta mai nel file.
4. SMTP per inviti e avvisi. Configuriamo SMTP_* affinché gli inviti di organizzazione e i reset partano da un indirizzo autenticato del dominio.
5. Backup testato. Copiare il SQLite a caldo non basta. Usiamo sqlite3 .backup (coerente con il database in uso) più gli allegati e la chiave RSA, e ripristiniamo periodicamente in un ambiente separato.
6. Aggiornamento. L'immagine latest cambia in fretta; fissiamo la versione in produzione e aggiorniamo in una finestra, con un backup fresco prima.

# backup coerente del database (mai cp del file a caldo)
sqlite3 /srv/vaultwarden/vw-data/db.sqlite3 \
  ".backup '/backup/vaultwarden-$(date +%F).sqlite3'"

# allegati + chiave RSA (senza di essi la cassaforte non si apre)
tar czf /backup/vw-attachments-$(date +%F).tgz \
  -C /srv/vaultwarden/vw-data attachments rsa_key config.json

Come lo gestiamo nella manutenzione di clienti GLPI

Nel mantenere ambienti GLPI dei clienti, usiamo Vaultwarden come cassaforte operativa: ogni cliente diventa un'organizzazione, con raccolte separate per natura (accessi server, credenziali API, account di portale), e il team riceve accesso per gruppo, non per password sciolta. L'errore comune che abbiamo visto - anche prima di standardizzare questo - è stato lasciare ADMIN_TOKEN in chiaro nel compose e committarlo per sbaglio; per questo oggi è sempre un hash argon2 e il .env resta fuori dal versionamento. L'altra decisione presa è stata mettere Vaultwarden dietro lo stesso reverse proxy di GLPI, sullo stesso host, riutilizzando TLS, monitoraggio e routine di backup. E il backup abbiamo imparato a farlo bene: un cp del db.sqlite3 a caldo può catturare il database a metà di una scrittura e produrre un ripristino corrotto - sqlite3 .backup lo risolve, e senza la chiave rsa_key la cassaforte semplicemente non si apre dopo. Sono dettagli che emergono solo quando operi, non quando leggi il README.

Domande frequenti

Se mantieni un ambiente GLPI e vuoi centralizzare i segreti operativi con l'aiuto di chi già lo fa, guarda i nostri servizi di infrastruttura e cloud oppure parla con il team.

Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team Nextool Solutions.