AuditRailsAuditRails

Funzionalità

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

Concatenamento crittografico degli hash

Ogni evento di audit è collegato crittograficamente al precedente tramite SHA-256. L'hash è calcolato a partire dall'hash precedente, dal canonical_payload e da un riferimento temporale con precisione al millisecondo. Se una voce viene modificata, eliminata o riordinata, la catena 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 catena, 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 conservazione sono applicati direttamente dal livello di storage, soddisfacendo i requisiti normativi più rigorosi.

  • S3 Object Lock in modalità COMPLIANCE
  • Conservazione 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 catena incorporati in ogni batch di storage, per la verifica
ScrittoBloccato (modalità COMPLIANCE)da 6 mesi a 10 anni

Nessuno, nemmeno gli amministratori di AuditRails, può accorciare, modificare o cancellare un oggetto bloccato prima della scadenza della sua finestra di conservazione.

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

isolato

Tenant B

isolato

Tenant C

isolato

Dashboard di conformità

Una dashboard progettata appositamente per la gestione degli audit log: volumi degli eventi, ricerca nei log, verifica dell'integrità della catena ed esportazione dei report. L'accesso basato sui ruoli è integrato.

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

Accesso basato sui ruoli

AmministratoreMembroAuditor

Esportazione

CSV

4 SDK nativi

Offriamo SDK nativi per i linguaggi e i framework più diffusi. Ogni SDK gestisce batching, tentativi e gestione degli errori, così l'attenzione resta su che cosa registrare, non su come farlo.

  • Node.js / TypeScript, @auditrails/node
  • Python, auditrails (sincrono + asincrono)
  • Go, auditrails-go (batching tramite goroutine, supporto context)
  • PHP, auditrails-php (client HTTP PSR-18, pacchetto Composer)
Node.jsPythonGoPHP
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 è arricchito con dati lato server prima della scrittura. IP di origine, geolocalizzazione, nomi delle azioni normalizzati e riferimenti temporali precisi sono aggiunti automaticamente. Voi inviate 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
  • Tentativi ripetuti in modo aggressivo: 5 per le scritture su storage a freddo, 3 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?

Attivate la prova gratuita di 30 giorni. Nessuna carta di credito richiesta.

Attivate la prova gratuitaPrezzi