File management via web su storage S3-compatibile (MinIO, Ceph, o S3 AWS/Cloudflare R2). Policy granulari per-utente-per-cartella (ReBAC), versioning automatico, audit log immutabile, 2FA obbligatoria, crittografia at-rest + in-transit. API REST per integrazione con applicazioni custom. Ricerca full-text opzionale su contenuto documenti indicizzati. GDPR-compliant per costruzione.
01Perché non una semplice cartella condivisa
La cartella di rete SMB funziona finché è piccola, finché chi la gestisce è ancora in azienda, finché nessuno chiede "chi ha visto questo documento il mese scorso?". Nella pratica, le cartelle condivise accumulano per anni documenti duplicati, versioni contraddittorie, permessi dimenticati su utenti che non esistono più.
Il momento in cui serve un DMS vero è quando il contenuto smette di essere solo "file" e diventa materiale sensibile: contratti firmati, cartelle cliniche, dossier legali, documentazione soggetta a retention obbligatoria. Lì servono cinque cose che SMB non ti dà nativamente: tracciabilità di chi ha toccato cosa, versioning automatico sulle modifiche, compliance dimostrabile in caso di ispezione, ricerca sul contenuto (non solo sul nome file), accesso remoto controllato senza VPN aperta a tutti.
Aggiungi l'audit trail completo — chi ha scaricato cosa da quale IP, in che momento — e hai passato la soglia oltre la quale la cartella di rete non è più un'opzione. È questo il terreno per cui abbiamo costruito il DMS.
02Architettura
L'impianto è volutamente classico, nessuna magia. Tre strati ben separati:
- Frontend web: interfaccia React per upload, navigazione, download, gestione permessi. Responsive, utilizzabile da desktop e mobile senza app native da installare.
- Application layer: API REST (Django + DRF) che gestisce autenticazione, policy, versioning, audit, indicizzazione. Metadata e relazioni stanno in PostgreSQL. Job asincroni (conversioni, indicizzazione, notifiche) su Celery + Redis.
- Storage layer: i file veri non toccano mai il database. Stanno su bucket S3-compatibile — tipicamente MinIO on-prem o Ceph su cluster Proxmox per installazioni cliente, oppure S3 AWS / Cloudflare R2 per scenari cloud o ibridi. L'applicazione parla un unico dialetto S3, il backend cambia senza toccare la logica applicativa.
La ricerca full-text sul contenuto dei documenti è un modulo opzionale: Elasticsearch (o OpenSearch) che indicizza in background il testo estratto da PDF, Office, immagini scansionate via OCR. Si attiva solo dove serve davvero — non è gratis in risorse e complessità operativa.
03Policy granulari
I permessi sono il punto in cui la maggior parte dei DMS "semplici" crollano. Il nostro modello è ReBAC (relationship-based access control): non esiste un ruolo globale che vale per tutto, esistono relazioni tra utenti e risorse. Una cartella può essere pubblica nel tenant, privata al proprietario, condivisa con un elenco specifico di utenti, ruoli o gruppi.
Le cose che un amministratore può configurare per ogni cartella o singolo documento:
- Chi può vedere (solo esistenza), leggere, scaricare, modificare, cancellare.
- Scadenza dell'accesso — un consulente esterno vede la cartella "Progetto X" per 90 giorni, poi viene revocato in automatico.
- Download con watermark dinamico (nome utente, timestamp, IP) sui PDF scaricati — utile per contenzioso e NDA.
- Eredità dei permessi dalla cartella padre con override esplicito: il modello è sempre ispezionabile ("perché questo utente vede questa cartella?") tramite permission inspector.
04Versioning e history
Ogni modifica a un documento genera automaticamente una nuova versione, senza che l'utente debba pensarci. La vecchia versione resta accessibile, con possibilità di restore puntuale a qualsiasi punto nel tempo. Per file di testo (markdown, xml, json, sorgenti) viene mostrato anche il diff tra versioni.
La politica di retention è configurabile per cartella: "tieni tutte le versioni per sempre" per documenti legali, "tieni le ultime 10 versioni e 12 mesi" per lavoro in corso. Le versioni più vecchie possono essere spostate su storage S3 a classe più economica (cold storage) per ridurre i costi senza perdere l'obbligo di conservazione.
05Audit log immutabile
Ogni evento che tocca un documento viene scritto su un log dedicato: visualizzazione, download, upload, rinomina, cancellazione, modifica permessi. Per ogni voce viene registrato chi (utente autenticato), cosa (documento e azione), quando (timestamp UTC con precisione al secondo), da dove (IP, user agent, sessione).
Il log è scritto su storage append-only (WORM — Write Once Read Many) sfruttando le object lock policy di S3: una volta scritto, l'evento non è modificabile nemmeno da un amministratore del DMS. È questa la differenza tra "log diagnostico" e "prova giudizialmente opponibile". Opzionalmente, ogni blocco di log può essere firmato digitalmente o ancorato su timestamping esterno per rafforzare la catena di custodia.
06Integrazioni tipiche
Un DMS isolato ha vita breve. Le integrazioni che montiamo di default o su richiesta:
- SSO — autenticazione via Active Directory, LDAP, SAML 2.0 o OIDC. Gli utenti accedono con le stesse credenziali aziendali, la 2FA è applicata centralmente dall'identity provider.
- Webhook su eventi (upload, cancellazione, modifica permessi) verso sistemi esterni — CRM, ERP, protocollo informatico, notifiche.
- API REST pubblica per caricamento massivo, integrazione con applicazioni custom, automazioni. Token per-applicazione con scope limitato.
- Drag & drop desktop client — piccolo agent che sincronizza una cartella locale con una cartella del DMS, per utenti che non vogliono passare dalla web app.
07Deploy e adozione
Tre modelli di deploy, scelti in base a dove devono stare i dati: cloud PSA (su nostra infrastruttura virtualizzata Proxmox presso i nostri data center), on-prem cliente (installato sui server del cliente, manutenzione nostra via accesso sicuro), ibrido (applicazione su cloud PSA, storage S3 del cliente su propria infrastruttura — utile quando i dati non possono uscire dal perimetro).
Il setup tipico per una nuova installazione è nell'ordine di una settimana: provisioning infrastruttura, configurazione SSO, definizione dei primi ruoli e gruppi, import della struttura di cartelle esistente. La migrazione dai cartelloni SMB/NAS avviene con script dedicati che preservano la gerarchia, i timestamp originali e — dove ricostruibili — i permessi NTFS/POSIX mappati sulle policy ReBAC del DMS. L'adozione richiede in media 30-60 giorni di affiancamento agli utenti interni, durante i quali teniamo attive entrambe le modalità in parallelo.
| Dimensione | Cartella condivisa SMB | DMS su S3 |
|---|---|---|
| Governance | Permessi NTFS sparsi, deriva nel tempo | ReBAC centralizzato, permission inspector |
| Audit | Event log parziale, ruotato, modificabile | Log immutabile WORM, ogni evento tracciato |
| Ricerca | Solo nome file, contenuto no | Full-text su contenuto (PDF, Office, OCR) |
| Compliance | Difficile dimostrare retention e tracciabilità | GDPR-compliant per costruzione, retention per-policy |
| Accesso remoto | VPN aperta, tutto o niente | HTTPS + 2FA, scope per utente e per cartella |
| Versioning | Shadow copy host-side, recovery manuale | Versioning automatico, restore granulare, diff |