Sicurezza
Non dovete crederci sulla parola. Questa pagina spiega come AuditRails protegge i vostri dati e come verificare in autonomia la nostra affermazione principale.
Modello di minaccia
Ogni affermazione di questa pagina è utile solo se se ne conoscono anche i limiti. Segue ciò contro cui AuditRails è progettato per proteggere, e ciò che esplicitamente non copre.
Contro cosa ci proteggiamo
La manomissione a posteriori di un evento registrato: qualsiasi modifica a un evento memorizzato interrompe la catena di hash da quel punto in poi, e il nostro verificatore open source può dimostrarlo in modo indipendente, senza doversi affidare alla nostra infrastruttura. La cancellazione o la scadenza anticipata dei dati di audit: S3 Object Lock in modalità Compliance lo impedisce a chiunque, noi compresi. La lettura dei dati di un tenant da parte di un altro: ogni query, percorso di storage e chiave di cache è vincolata a un tenant già a livello di query.
Contro cosa non ci proteggiamo
Concateniamo gli eventi tramite hash; non li firmiamo con chiavi asimmetriche specifiche per cliente, quindi per progettazione non esiste un'infrastruttura di chiavi di firma da gestire o ruotare. Una API key compromessa è limitata ai dati di quel tenant, non può raggiungere quelli di nessun altro, ma può agire all'interno del proprio tenant finché non viene revocata. E non gestiamo un WAF o un livello di filtro L7 dedicato davanti alla nostra infrastruttura; ci affidiamo alla mitigazione DDoS integrata di Hetzner a livello di rete, insieme al nostro rate limiting per tenant.
Architettura
L'SDK invia gli eventi alla nostra API di ingest, scritta in Go, che autentica la richiesta e la pubblica su una coda (AWS SQS). Un worker legge la coda, calcola la catena di hash crittografica e scrive in tre posizioni: S3 (Object Lock, la fonte di verità durevole), ClickHouse (cache di query a caldo, 90 giorni) e Cassandra (archivio freddo illimitato che alimenta export e report oltre la finestra di ClickHouse). La dashboard legge da questi archivi, mai direttamente dalla vostra applicazione.
SDK
Node, Python, Go, PHP
API di ingest
Valida, arricchisce, accoda
Catena di hash + WORM
S3 Object Lock, ClickHouse, Cassandra
Dashboard
Ricerca, verifica, esportazione, conformità
Crittografia
In transito
Tutto il traffico pubblico, l'SDK, la dashboard e questo sito, è servito tramite TLS con certificati rinnovati automaticamente. Non esiste alcun percorso non cifrato tra l'SDK e la nostra API di ingest.
A riposo
La copia durevole dei vostri audit log su S3 è cifrata a riposo con AWS KMS (SSE-KMS).
Lavori in corso
Il nostro livello di base dati self-hosted (PostgreSQL, ClickHouse, Cassandra, Redis) non ha ancora la cifratura a livello di disco configurata. Il lavoro è in corso e preferiamo dirlo qui, apertamente, piuttosto che lasciarlo emergere in sede di due diligence.
Storage immutabile (WORM)
Gli audit log vengono scritti su S3 con Object Lock in modalità Compliance, non in modalità Governance. Questa distinzione è importante: in modalità Compliance, nessuno, inclusi gli amministratori di AuditRails e l'account root di AWS stesso, può accorciare un blocco di conservazione o eliminare un log prima della sua scadenza. La finestra di conservazione predefinita è di sette anni.
Nessuno, nemmeno gli amministratori di AuditRails, può accorciare, modificare o cancellare un oggetto bloccato prima della scadenza della sua finestra di conservazione.
Verifica indipendente
Pubblichiamo uno strumento a riga di comando open source che ricalcola in modo indipendente la catena di hash del vostro registro di audit e conferma che non sia stata manomessa. Non richiama la nostra API e non si affida alla nostra infrastruttura: si affida soltanto alla matematica.
Il verificatore su GitHub →Gestione di chiavi e segreti
Chiavi API
Non conserviamo mai le vostre chiavi API in chiaro. Viene memorizzato soltanto un hash SHA-256; la chiave in chiaro è mostrata esattamente una volta, al momento della creazione.
Segreti dell'infrastruttura
Le credenziali del database, le chiavi del fornitore di pagamenti e altri segreti dell'infrastruttura sono crittografati a riposo con age/sops, e decrittografati solo in uno storage effimero in memoria al momento del deploy, mai scritti in chiaro su disco persistente.
Isolamento multi-tenant
Ogni chiave API corrisponde esattamente a un tenant. Ogni query al database, ogni percorso S3 e ogni chiave di cache applica l'isolamento dei tenant a livello della query stessa, non come convenzione a livello applicativo. Non esiste alcun percorso di codice che possa restituire i dati di un'organizzazione a un'altra.
Tenant A
isolato
Tenant B
isolato
Tenant C
isolato
La nostra posizione di conformità
Ci stiamo preparando attivamente per un audit SOC 2 Type II. Non abbiamo ancora avviato il processo di audit formale, e preferiamo dirlo chiaramente piuttosto che lasciarti indovinare.
Subresponsabili
Infrastrutture e servizi di terze parti da cui dipendiamo:
AWS
Amazon Web Services, solo S3 (storage WORM degli audit log) e SQS (accodamento).
Hetzner
Hetzner, hosting dei nostri server applicativi e database.
Stripe
Stripe, elaborazione dei pagamenti.
Resend
Resend, email transazionali.
Sentry
Sentry, tracciamento degli errori.
Plausible
Plausible, analytics del sito senza cookie, solo su questo sito.
MaxMind
MaxMind, arricchimento geo-IP per gli eventi registrati.
Cloudflare Turnstile
Cloudflare Turnstile, protezione anti-bot sui nostri moduli pubblici di contatto e registrazione.
Let's Encrypt
Let's Encrypt, certificati TLS.
Segnala una vulnerabilità
Chi individua una vulnerabilità di sicurezza è pregato di segnalarcela in modo responsabile, anziché aprire una issue pubblica su GitHub.
security@auditrails.ioConfermiamo la ricezione di ogni segnalazione entro 24 ore. Per le vulnerabilità critiche (CVSS 9.0+), puntiamo a rispondere entro 4 ore e a rilasciare una correzione entro 24 ore.
Questo copre la dashboard di AuditRails, l'API di ingestion, il worker di elaborazione, tutti gli SDK ufficiali, e la nostra configurazione dell'infrastruttura.
Questo indirizzo serve a segnalare vulnerabilità nei nostri sistemi. Per informazioni sul nostro impegno di notifica in caso di violazione dei dati personali (48 ore), il riferimento è il nostro DPA.
Backup e ripristino
Eseguiamo backup notturni di PostgreSQL e Cassandra verso una posizione di storage separata e dedicata. Il ripristino non è solo scriptato, è testato: la nostra prova più recente (25/08/2026) ha ripristinato entrambi i database dal backup confermando una corrispondenza esatta del numero di righe rispetto ai dati live.