AuditRailsAuditRails

Funzionalità

Ogni funzionalità è progettata per un solo obiettivo: audit logging a prova di manomissione e pronto per la compliance, di cui potersi fidare.

Hash Chaining Crittografico

Ogni evento di audit è collegato crittograficamente al precedente tramite SHA-256. L'hash viene calcolato a partire dall'hash precedente, dal canonical_payload e da un timestamp con precisione al millisecondo. Se una voce viene modificata, eliminata o riordinata, la chain si interrompe immediatamente.

  • Hash SHA-256 di previous_hash + canonical_payload + timestamp
  • Chain indipendenti per ogni tenant, ciascuna con il proprio blocco genesis
  • Timestamp con precisione al millisecondo per prevenire attacchi di replay
  • API di verifica della chain per dimostrare l'integrità agli auditor

Block #3

prev d7e1c4

hash 9b4f2a

Block #4

prev 9b4f2a

hash f1c8e3

Block #5

prev f1c8e3

hash a02d71

Storage Immutabile WORM

Gli audit log vengono scritti su S3 con Object Lock in modalità compliance. Una volta scritti, nessuno può modificarli o eliminarli, nemmeno gli amministratori di AuditRails. I periodi di retention sono applicati direttamente dal livello di storage, soddisfacendo i requisiti normativi più rigorosi.

  • S3 Object Lock in modalità COMPLIANCE
  • Retention configurabile da 6 mesi fino a 10 anni, in base ai framework di compliance attivi
  • Scritture raggruppate in batch per ottimizzare i costi senza compromettere la durabilità
  • Metadati della chain incorporati in ogni batch di storage per la verifica
WrittenLocked (COMPLIANCE mode)6 months – 10 years

No one, including AuditRails admins, can shorten, edit, or delete a locked object before its retention window ends.

Multi-tenancy

Ogni API key è associata a un tenant. Ogni query al database, percorso S3 e chiave di cache applica l'isolamento tra tenant. Non è in alcun modo possibile accedere ai dati di un altro tenant, l'isolamento è garantito a livello di infrastruttura, non solo a livello applicativo.

  • Mapping tra API key e tenant_id su ogni richiesta
  • ClickHouse partizionato per tenant_id per l'isolamento delle query
  • Percorsi S3 organizzati per namespace in base al tenant_id
  • Filtro a livello di riga su tenant_id in PostgreSQL per tutte le query

Tenant A

isolated

Tenant B

isolated

Tenant C

isolated

Dashboard di Compliance

Una dashboard progettata appositamente per la gestione degli audit log. Visualizza i volumi degli eventi, cerca nei log, verifica l'integrità della chain ed esporta report. L'accesso basato sui ruoli consente di dare agli auditor un accesso in sola lettura senza esporre le operazioni sensibili.

  • Panoramica con grafici sui volumi degli eventi e le azioni principali
  • Navigazione della chain: scorri avanti e indietro lungo la hash chain
  • Esportazione in CSV per la consegna agli auditor
  • Accesso basato sui ruoli: ruoli Admin, Member e Auditor

Role-based access

AdminMemberAuditor

Export

CSV

5 SDK Nativi

Offriamo SDK nativi per i linguaggi e i framework più diffusi. Ogni SDK gestisce batching, retry e gestione degli errori, così puoi concentrarti su cosa registrare, non su come farlo.

  • Node.js / TypeScript, @auditrails/node
  • Python, auditrails (sincrono + asincrono)
  • Go, auditrails-go (batching tramite goroutine, supporto context)
  • Java, auditrails-java (pattern builder, AutoCloseable)
  • PHP, auditrails-php (client HTTP PSR-18, pacchetto Composer)
Node.jsPythonGoJavaPHP
import { AuditRails } from '@auditrails/node';

const client = new AuditRails({ apiKey: process.env.AUDITRAILS_KEY });
await client.log({ action: 'user.created', actor_id: 'admin@acme.io' });

Arricchimento Automatico

Ogni evento viene arricchito con dati lato server prima dello storage. IP di origine, geolocalizzazione, nomi delle azioni normalizzati e timestamp precisi vengono aggiunti automaticamente. Tu invii il minimo indispensabile, noi completiamo il resto.

  • ULID generato dal server per ogni voce di log
  • Rilevamento dell'IP di origine e risoluzione geo-IP (paese, città)
  • Normalizzazione dei nomi delle azioni (minuscolo, separato da punti)
  • Timestamp del server con precisione al millisecondo

You send

{
  "action": "user.created",
  "actor_id": "admin@acme.io"
}

We store

{
  "action": "user.created",
  "actor_id": "admin@acme.io",
  "log_id": "01J8X...",
  "ip": "203.0.113.42",
  "geo": "DE",
  "ts": "...482Z"
}

Affidabilità e Durabilità

La pipeline di ingestion è progettata per la durabilità. Gli eventi transitano attraverso SQS con dead-letter queue, la deduplicazione previene l'elaborazione doppia e strategie di retry a più livelli garantiscono che ogni evento raggiunga lo storage.

  • Coda SQS con dead-letter queue per i messaggi non elaborati
  • Deduplicazione basata su Redis con TTL di 24 ore
  • Retry aggressivo (5x) per le scritture su cold storage, 3x per lo storage a caldo
  • Degradazione controllata: fail-open sugli errori non critici del percorso di elaborazione
SQS queue
Dedup (24h TTL)
Retry (5x cold / 3x hot)
S3 + ClickHouse

Pronto a vederlo in azione?

Inizia la tua prova gratuita di 90 giorni. Nessuna carta di credito richiesta.

Inizia la Prova GratuitaVedi i Prezzi