Questo documento descrive l'architettura tecnica di Diligenx, le misure di sicurezza adottate e il ciclo di vita dei dati. È destinato a CISO, responsabili compliance e team IT dei clienti che valutano l'adozione del servizio.
1. Architettura del servizio
Diligenx è una piattaforma SaaS multi-tenant cloud-native, composta da quattro componenti principali.
- Frontend Next.js 15 servito da Vercel (rete edge globale). Tutte le pagine richiedono autenticazione lato server via middleware, eccezion fatta per la landing e le pagine informative pubbliche.
- Backend FastAPI su Railway. Espone le API REST, orchestra la pipeline di analisi multi-agente, gestisce autenticazione JWT.
- Database PostgreSQL su Railway con estensione pgvector per la ricerca semantica. Contiene metadati di utenti, deal e documenti, embedding vettoriali e output strutturato delle analisi.
- Storage Cloudflare R2 in jurisdiction europea per i file originali caricati dagli utenti.
2. Autenticazione e autorizzazione
- Hash password: bcrypt con cost factor 12, nessuna password in chiaro è mai memorizzata o loggata.
- Sessioni: JWT firmati HS256, durata 7 giorni, memorizzati come cookie SameSite=Lax con flag Secure su HTTPS.
- Autorizzazione: ogni endpoint API richiede un token valido e applica filtri di proprietà (
owner_id,workspace_id,deal_id) su ogni query. La risorsa richiesta deve appartenere al chiamante.
3. Isolamento multi-tenant
Diligenx è un SaaS multi-tenant con isolamento logico (modello "pooled tenancy"): tutti i clienti condividono la stessa istanza di database e bucket, separati a livello applicativo tramite chiavi di proprietà su ogni query e prefissi di nomi oggetto su R2 (deals/{deal_id}/...).
È inoltre in roadmap l'attivazione di PostgreSQL Row-Level Security come secondo strato di difesa: il codice è già pronto, l'attivazione richiede la rotazione del ruolo di connessione del backend a un ruolo non-superuser.
4. Cifratura
- In transito: TLS 1.3 su tutti i path (browser→Vercel, Vercel→Railway, Railway→R2, Railway→Anthropic, Railway→OpenAI). Certificati gestiti dai rispettivi provider.
- At rest: cifratura applicata di default dai provider di storage (Cloudflare R2: AES-256; Railway PostgreSQL: cifratura a livello disco). Le chiavi sono gestite dai provider.
5. Ciclo di vita dei dati
| Categoria | Dove vive | Retention |
|---|---|---|
| File originali (PDF/DOCX) | Cloudflare R2 (EU) | Finché l'utente non li cancella. Auto-pulizia configurabile in roadmap. |
| Testo estratto e chunk vettoriali | PostgreSQL (Railway) | Cancellati in cascade alla cancellazione del documento. |
| Output strutturato (clausole, red flag, report) | PostgreSQL (Railway) | Cancellati in cascade alla cancellazione del deal. |
| Backup database | Railway (snapshot quotidiani) | 7 giorni rolling. |
| Log applicativi | Railway / Vercel | 30 giorni. |
6. Uso dei modelli AI
- Diligenx invia il contenuto dei documenti ad Anthropic Claude per l'analisi e ad OpenAI per il calcolo degli embedding semantici.
- Entrambi i fornitori operano sulle loro API in modalità no-training: i contenuti inviati non vengono utilizzati per addestrare i loro modelli.
- Anthropic e OpenAI conservano gli input per periodi limitati (30 giorni per Anthropic, 30 giorni per OpenAI) ai soli fini di monitoraggio abusi, oltre i quali i dati sono cancellati.
7. Subprocessor
L'elenco aggiornato dei subprocessor è disponibile nel Data Processing Agreement. Le modifiche sono comunicate ai clienti con preavviso di 30 giorni.
8. Gestione delle vulnerabilità
- Dipendenze: Renovate / Dependabot monitorano le dipendenze frontend e backend; aggiornamenti di sicurezza applicati entro 7 giorni dalla pubblicazione della CVE.
- Penetration test: pianificato annualmente da società terza specializzata (in attesa di esecuzione).
- Vulnerability disclosure: segnalazioni a security@diligenx.example; risposta entro 5 giorni lavorativi.
9. Incident response
- Detection tramite alert su metriche di sistema e log.
- Triage entro 4 ore dall'allertamento per incidenti di sicurezza.
- Notifica ai clienti impattati senza ingiustificato ritardo e comunque entro 72 ore dalla scoperta, conforme all'art. 33 GDPR.
- Post-mortem pubblico per incidenti che impattano il servizio.
10. Disponibilità e backup
- Backup PostgreSQL automatici quotidiani, conservati 7 giorni.
- R2 fornisce 11×9 di durability sui file.
- RTO target: 4 ore in caso di disaster recovery completo. RPO target: 24 ore.
11. Conformità in evoluzione
Diligenx è una società in fase early-stage. Le seguenti certificazioni sono in roadmap ma non ancora ottenute:
- SOC 2 Type 1 — pianificato Q4.
- Penetration test annuale — pianificato Q3.
- ISO 27001 — orizzonte 18-24 mesi.
12. Contatti
Domande tecniche o di security: security@diligenx.example. Per richieste di compliance / audit: privacy@diligenx.example.