AuditRailsAuditRails

Funktionen

Jede Funktion verfolgt ein Ziel: fälschungssichere, compliance-fähige Audit Logs, denen Sie vertrauen können.

Kryptografisches Hash Chaining

Jedes Audit-Ereignis wird mittels SHA-256 kryptografisch mit dem vorherigen verknüpft. Der Hash wird aus dem vorherigen Hash, der kanonischen Payload und einem timestamp mit Millisekundengenauigkeit berechnet. Wird ein Eintrag geändert, gelöscht oder in der Reihenfolge vertauscht, bricht die Chain sofort ab.

  • SHA-256-Hash aus previous_hash + canonical_payload + timestamp
  • Separate Hash Chains pro Tenant mit unabhängigen Genesis-Blocks
  • Millisekundengenaue timestamps verhindern Replay-Angriffe
  • Chain-Verifizierungs-API zum Nachweis der Integrität gegenüber Auditoren

Block #3

prev d7e1c4

hash 9b4f2a

Block #4

prev 9b4f2a

hash f1c8e3

Block #5

prev f1c8e3

hash a02d71

Unveränderlicher WORM-Speicher

Audit Logs werden mit Object Lock im Compliance-Modus in S3 geschrieben. Einmal geschrieben, kann niemand sie mehr ändern oder löschen, nicht einmal AuditRails-Administratoren. Aufbewahrungsfristen werden direkt von der Speicherebene selbst erzwungen und erfüllen damit die strengsten regulatorischen Anforderungen.

  • S3 Object Lock im COMPLIANCE-Modus
  • Konfigurierbare Aufbewahrung von 6 Monaten bis zu 10 Jahren, abhängig von Ihren aktiven Compliance-Frameworks
  • Gebündelte Schreibvorgänge für Kosteneffizienz ohne Einbußen bei der Dauerhaftigkeit
  • In jedem Storage-Batch eingebettete Chain-Metadaten zur Verifizierung
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

Jeder API key ist einem Tenant zugeordnet. Jede Datenbankabfrage, jeder S3-Pfad und jeder Cache-Key erzwingt die Tenant-Isolation. Es gibt keine Möglichkeit, auf die Daten eines anderen Tenants zuzugreifen, sie wird auf Infrastrukturebene erzwungen, nicht nur auf Anwendungsebene.

  • Zuordnung von API key zu tenant_id bei jedem Request
  • ClickHouse nach tenant_id partitioniert für Query-Isolation
  • S3-Pfade mit Namespace nach tenant_id
  • PostgreSQL Row-Level-Filterung nach Tenant bei allen Queries

Tenant A

isolated

Tenant B

isolated

Tenant C

isolated

Compliance Dashboard

Ein speziell entwickeltes Dashboard für die Verwaltung von Audit Logs. Sehen Sie Event-Volumen ein, durchsuchen Sie Logs, verifizieren Sie die Chain-Integrität und exportieren Sie Reports. Rollenbasierter Zugriff ermöglicht es Ihnen, Auditoren einen Lesezugriff zu gewähren, ohne sensible Vorgänge offenzulegen.

  • Übersicht mit Event-Volumen-Charts und Top-Aktionen
  • Chain-Navigation: Vorwärts und rückwärts durch die Hash Chain navigieren
  • CSV-Export für die Übergabe an Auditoren
  • Rollenbasierter Zugriff: Admin-, Member- und Auditor-Rollen

Role-based access

AdminMemberAuditor

Export

CSV

5 native SDKs

Wir bieten native SDKs für die gängigsten Sprachen und Frameworks. Jedes SDK übernimmt Batching, Retries und Error Handling, damit Sie sich auf das Was der Protokollierung konzentrieren können, nicht auf das Wie.

  • Node.js / TypeScript, @auditrails/node
  • Python, auditrails (synchron + asynchron)
  • Go, auditrails-go (Goroutine-Batching, Context-Unterstützung)
  • Java, auditrails-java (Builder Pattern, AutoCloseable)
  • PHP, auditrails-php (PSR-18-HTTP-Client, Composer-Paket)
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' });

Automatische Anreicherung

Jedes Event wird vor der Speicherung mit serverseitigen Daten angereichert. Source IP, Geolocation, normalisierte Aktionsnamen und präzise timestamps werden automatisch hinzugefügt. Sie senden das Minimum, wir ergänzen den Rest.

  • Serverseitig generierte ULID für jeden Log-Eintrag
  • Erfassung der Source IP und Geo-IP-Auflösung (Land, Stadt)
  • Normalisierung von Aktionsnamen (Kleinschreibung, durch Punkte getrennt)
  • Server-timestamps mit Millisekundengenauigkeit

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"
}

Zuverlässigkeit und Dauerhaftigkeit

Die Ingestion-Pipeline ist auf Dauerhaftigkeit ausgelegt. Events durchlaufen SQS mit Dead-Letter-Queues, Deduplication verhindert doppelte Verarbeitung, und gestufte Retry-Strategien stellen sicher, dass jedes Event den Storage erreicht.

  • SQS-Queue mit Dead-Letter-Queue für fehlgeschlagene Messages
  • Redis-basierte Deduplication mit 24-Stunden-TTL
  • Aggressive Retries (5x) für Cold-Storage-Writes, 3x für Hot Storage
  • Graceful Degradation: Fail-Open bei Fehlern in nicht kritischen Pfaden
SQS queue
Dedup (24h TTL)
Retry (5x cold / 3x hot)
S3 + ClickHouse

Bereit, es in Aktion zu sehen?

Starten Sie Ihre 60-tägige kostenlose Testphase. Keine Kreditkarte erforderlich.