I dati restano separati
Ogni organizzazione cliente lavora nel proprio spazio dati. Audit, evidenze, utenti e impostazioni restano separati dagli altri clienti.
Il perimetro del cliente è chiaro per governance interna, DPO e audit esterni.
Controlli che sai spiegare in sede di revisione
Separazione dei dati, evidenze protette, azioni attribuibili e accessi per ruolo sono progettati per restare leggibili quando la governance chiede perché.
In parole semplici
Cosa può aspettarsi il tuo team
L’essenziale: quali dati protegge AuditReady, come vengono controllati gli accessi e perché questi controlli contano in audit e governance.
Le evidenze restano protette
I file caricati sono protetti mentre sono archiviati e si aprono solo tramite flussi applicativi controllati per utenti autorizzati.
Un file non dovrebbe diventare leggibile solo perché qualcuno raggiunge il livello di storage.
Le evidenze approvate non cambiano in silenzio
Dopo la revisione e l’approvazione, un’evidenza entra nel fascicolo di audit. Le modifiche successive vengono bloccate o rese rilevabili.
Gli audit pack restano più affidabili perché chi li esamina può basarsi su ciò che è già stato approvato.
L’accesso dipende da identità e ruolo
Gli utenti si autenticano, i ruoli sensibili verificano di nuovo l’identità e le azioni importanti sono controllate rispetto al ruolo.
Il lavoro quotidiano resta fluido, ma l’accesso segue il principio del minimo privilegio.
La raccolta esterna è controllata
Fornitori e collaboratori esterni usano link limitati, verifiche, controlli sui file e soglie di upload.
La raccolta resta tracciabile anche quando il file arriva da fuori dall’organizzazione.
I controlli seguono il ciclo di vita
Stato del tenant, moduli attivi, framework e limiti di risorse possono ridurre o bloccare l’accesso quando cambiano le condizioni.
L’accesso segue contratto e perimetro concordato, invece di restare aperto per impostazione predefinita.
Approfondimento tecnico
Controlli per IT, specialisti di sicurezza e auditor
Questa sezione nomina i meccanismi dietro alle garanzie: modello di isolamento, cifratura, firme, ruoli, rate limit e mapping normativo.
Isolamento multi-tenant
L’isolamento tenant è applicato su database, storage, cache e code di lavoro.
La risoluzione del tenant avviene prima dell’avvio della sessione web. Da quel momento query, file, cache e code operano solo nel contesto del tenant corrente. I domini marketing e di amministrazione piattaforma restano separati dai domini applicativi tenant.
Per auditor e DPO, è la garanzia più forte che i dati di compliance di un’organizzazione non siano accessibili da un’altra.
Crittografia e gestione delle chiavi
La crittografia delle evidenze usa chiavi per-file protette da una gerarchia per-tenant.
Ogni upload genera una data encryption key casuale e un IV univoco. La chiave del file è protetta da una tenant master key, sotto una gerarchia di platform master key. HTTPS è forzato in produzione e i download impediscono la cache dei contenuti decifrati.
Accedere allo storage non basta per leggere i file senza le chiavi del tenant. Questo supporta le aspettative dell’Art. 32 GDPR sulla protezione dei dati archiviati.
Platform master key (PMK)
Protegge le chiavi master dei tenant a livello piattaforma
Tenant master key (TMK)
Protegge le chiavi per-file di ogni organizzazione
Data encryption key (DEK)
Chiave AES-256 univoca per ogni file evidenza
Integrità e immutabilità delle evidenze
Le evidenze approvate vengono bloccate, così le modifiche successive sono impedite o rilevabili.
I campi critici sono sigillati dopo la creazione. Gli stati terminali di validazione bloccano ogni modifica. L’integrità dei metadati usa HMAC-SHA256 e i checksum rilevano manomissioni durante il download. Gli indici di ricerca escludono i campi crittografici sensibili.
Un’evidenza inserita in un audit pack non può essere sostituita dopo la revisione senza lasciare un segnale di controllo per gli auditor.
Registro di audit immutabile e firmato
Le azioni rilevanti sono registrate in un log append-only con controlli crittografici di integrità.
Il registro indica chi ha agito, cosa è cambiato, quando è successo e il contesto della richiesta. Ogni voce ha una firma crittografica.
- Chi — utente autenticato
- Cosa — modello, azione, diff del payload
- Quando — timestamp UTC
- Contesto — indirizzo IP e user agent
- Integrità — firma HMAC-SHA256
Un log immutabile e firmato offre agli auditor una base affidabile per la tracciabilità richiesta da NIS2 e DORA.
Identità, autenticazione e 2FA
L’autenticazione separa i contesti utente, applica 2FA dove serve e limita i tentativi ripetuti.
La registrazione autonoma è disabilitata. Utenti tenant e amministratori piattaforma si autenticano in contesti separati. La 2FA TOTP è obbligatoria per Organization Owner, Audit Manager e Contributor.
La 2FA obbligatoria sui ruoli operativi riduce l’impatto di credential stuffing, phishing e riuso delle password.
- Limite tentativi di accesso: 5 al minuto per email e IP
- Verifica 2FA: doppio rate limit per utente e IP
- Sessioni server-side con cookie HttpOnly e flag Secure
- Policy password con hash mediante algoritmi industry-standard
Autorizzazione basata su capacità
L’accesso è valutato attraverso 24 capacità di prodotto e le azioni che ciascuna consente, poi filtrato in base a moduli e framework attivi del tenant. Quattordici ruoli di sistema forniscono una base di partenza e gli amministratori possono definire ruoli personalizzati.
| Ruolo di esempio | Ambito di competenza |
|---|---|
| Organization Owner | Amministrazione tenant e tutte le capacità abilitate |
| Internal Auditor | Audit, finding, gap snapshot e export pack |
| DPO | RoPA, DPIA, DSAR, violazioni privacy e attestazioni di governance |
| CISO | Incidenti ICT, inventario, resilienza, controlli e fornitori |
| External Uploader | Solo caricamento evidenze |
Permessi come risk.treat, evidence.share, export_pack.generate o dsar.close possono essere concessi solo dove servono, sostenendo least privilege e minimizzazione degli accessi.
Condivisione e raccolta evidenze in sicurezza
I flussi con fornitori e destinatari esterni usano link controllati, verifica OTP, validazione file e rate limit anti-abuso.
- Token ad alta entropia da 64 caratteri per richieste evidenze pubbliche, senza login tradizionale.
- OTP a 6 cifre via email per acknowledgment e download; blocco dopo tentativi falliti.
- Validazione MIME doppia, sanitizzazione filename, quote upload (5 file, 25 MB ciascuno, 50 MB totali).
- URL firmati 24 ore per download autenticati; API esterna con JWT e binding al tenant.
La raccolta esterna mantiene visibile la catena di custodia, invece di creare un passaggio non governato.
Hardening dell'applicazione web
Le risposte HTTP includono security header e le richieste sensibili sono protette da controlli CSRF, HTTPS e rate limit.
- X-Content-Type-Options, X-Frame-Options DENY, Referrer-Policy, Cross-Origin-Opener-Policy
- Protezione CSRF su tutte le rotte web, inclusi i form del portale evidenze pubblico
- Normalizzazione canonical host (HTTP → HTTPS, www → apex)
- CORS fail-closed; host e proxy fidati configurabili
- Rate limit su login, 2FA, upload, download, form contatti e operazioni admin
Governance del ciclo di vita e dei moduli
Le impostazioni runtime governano stato del ciclo di vita, moduli attivi, framework e quote di risorse.
I tenant sospesi o scaduti vengono bloccati automaticamente. Moduli e framework compliance filtrano rotte e risorse del pannello. Quote storage, utenti e audit applicano i limiti del piano e restituiscono HTTP 429 al superamento.
Quando cambiano rapporto contrattuale o perimetro del piano, cambia anche l’accesso.
Allineamento normativo
Questa mappa indica dove i controlli AuditReady possono supportare il programma di compliance dell’organizzazione. La conformità formale resta responsabilità del cliente.
| Controllo | GDPR | NIS2 | DORA | AI Act |
|---|---|---|---|---|
| Isolamento database-per-tenant | Art. 32(1)(b) | Art. 21(2)(d) | Art. 9(2) | Art. 15 |
| Crittografia AES-256 a riposo | Art. 32(1)(a) | Art. 21(2)(h) | Art. 9(2)(c) | Art. 15(3) |
| Audit trail immutabile HMAC | Art. 5(2) | Art. 21(2)(j) | Art. 6(4) | Art. 12(1) |
| 2FA obbligatoria (ruoli sensibili) | Art. 32(1)(d) | Art. 21(2)(i) | Art. 9(2)(a) | Art. 15(4) |
| RBAC granulare | Art. 32(1)(b) | Art. 21(2)(i) | Art. 9(2)(a) | Art. 14(3)(c) |
Strumenti e controlli — non conformità automatica
AuditReady fornisce controlli di sicurezza per lavoro regolamentato, ma non certifica l’organizzazione e non sostituisce policy interne, risk assessment, valutazioni legali o misure operative. La conformità a GDPR, NIS2, DORA, AI Act o altri framework richiede un programma più ampio.
Parliamo di sicurezza con il nostro team
Per CXO, DPO, auditor, security e legal che devono valutare AuditReady prima dell’adozione.
- Percorso guidato su isolamento tenant e architettura di crittografia
- Verifica dei controlli di accesso, dei log di audit e dei flussi di evidenze esterne
- Allineamento con il vostro programma di compliance e i framework di riferimento
Indica framework, fase di audit o collo di bottiglia sulle evidenze.