Fonctionnalités
Chaque fonctionnalité a été conçue dans un seul but : un audit log infalsifiable et conforme, sur lequel vous pouvez vous appuyer.
Chaînage cryptographique par hachage
Chaque événement d'audit est lié cryptographiquement au précédent via SHA-256. Le hash est calculé à partir du hash précédent, du canonical_payload et d'un timestamp à la milliseconde. Si une entrée est modifiée, supprimée ou réordonnée, la chaîne se rompt immédiatement.
- Hash SHA-256 de previous_hash + canonical_payload + timestamp
- Chaînes indépendantes par tenant, avec bloc genesis propre à chacune
- Des timestamps à la milliseconde qui empêchent les attaques par rejeu
- Une API de vérification de chaîne pour prouver l'intégrité aux auditeurs
Block #3
prev d7e1c4
hash 9b4f2a
Block #4
prev 9b4f2a
hash f1c8e3
Block #5
prev f1c8e3
hash a02d71
Stockage immuable WORM
Les audit logs sont écrits sur S3 avec Object Lock en mode compliance. Une fois écrits, personne ne peut les modifier ou les supprimer, pas même les administrateurs d'AuditRails. Les durées de conservation sont imposées par la couche de stockage elle-même, conformément aux exigences réglementaires les plus strictes.
- S3 Object Lock en mode COMPLIANCE
- Durée de conservation configurable de 6 mois à 10 ans, selon les frameworks de conformité activés
- Écritures groupées pour optimiser les coûts sans sacrifier la durabilité
- Métadonnées de chaîne intégrées à chaque lot de stockage pour la vérification
No one, including AuditRails admins, can shorten, edit, or delete a locked object before its retention window ends.
Recherche en temps réel
Propulsée par ClickHouse, notre couche de stockage à chaud indexe chaque champ pour une recherche instantanée. Filtrez par action, acteur, ressource, période ou tout champ de métadonnées. Recherche plein texte avec pagination intégrée.
- Analytique propulsée par ClickHouse avec élagage de partitions
- Filtrage par action, actor_id, ressource, période et métadonnées
- Recherche plein texte ILIKE sur tous les champs
- Requêtes plein texte rapides sur des millions d'événements
Multi-tenancy
Chaque API key est associée à un tenant. Chaque requête en base de données, chaque chemin S3 et chaque clé de cache impose l'isolation des tenants. Il est impossible d'accéder aux données d'un autre tenant, l'isolation est garantie au niveau de l'infrastructure, pas seulement de l'application.
- Association API key → tenant_id sur chaque requête
- ClickHouse partitionné par tenant_id pour l'isolation des requêtes
- Chemins S3 cloisonnés par tenant_id
- Filtrage par tenant au niveau des lignes PostgreSQL sur toutes les requêtes
Tenant A
isolated
Tenant B
isolated
Tenant C
isolated
Dashboard de conformité
Un dashboard conçu spécifiquement pour la gestion des audit logs. Visualisez les volumes d'événements, recherchez dans les logs, vérifiez l'intégrité de la chaîne et exportez des rapports. Le contrôle d'accès par rôle permet de donner à vos auditeurs un accès en lecture seule sans exposer les opérations sensibles.
- Vue d'ensemble avec graphiques de volume d'événements et actions les plus fréquentes
- Navigation dans la chaîne : parcourez la hash chain en avant et en arrière
- Export CSV pour la transmission aux auditeurs
- Contrôle d'accès par rôle : rôles Admin, Membre et Auditeur
Role-based access
Export
5 SDKs natifs
Nous proposons des SDKs natifs pour les langages et frameworks les plus utilisés. Chaque SDK gère le batching, les retries et la gestion des erreurs, pour que vous puissiez vous concentrer sur ce qu'il faut logger, pas sur la façon de le logger.
- Node.js / TypeScript, @auditrails/node
- Python, auditrails (synchrone + asynchrone)
- Go, auditrails-go (batching par goroutines, support du context)
- Java, auditrails-java (builder pattern, AutoCloseable)
- PHP, auditrails-php (client HTTP PSR-18, paquet Composer)
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' });Enrichissement automatique
Chaque événement est enrichi côté serveur avant son stockage. L'adresse IP source, la géolocalisation, les noms d'action normalisés et des timestamps précis sont ajoutés automatiquement. Vous envoyez le minimum, nous complétons le reste.
- ULID généré côté serveur pour chaque entrée de log
- Capture de l'IP source et résolution géo-IP (pays, ville)
- Normalisation des noms d'action (minuscules, séparées par des points)
- Timestamps serveur à la précision de la milliseconde
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"
}Fiabilité et durabilité
Le pipeline d'ingestion est conçu pour la durabilité. Les événements transitent via SQS avec des dead-letter queues, la déduplication empêche les doubles traitements, et des stratégies de retry échelonnées garantissent que chaque événement atteint le stockage.
- File SQS avec dead-letter queue pour les messages en échec
- Déduplication basée sur Redis avec un TTL de 24 heures
- Retry agressif (5x) pour les écritures en stockage froid, 3x pour le stockage à chaud
- Dégradation contrôlée : fail-open sur les erreurs de chemins non critiques
Prêt à le voir en action ?
Démarrez votre essai gratuit de 90 jours. Aucune carte bancaire requise.