Immutable Audit Logging

The Vault maintains an immutable, append-only audit trail of every significant action taken within the platform. Once an audit event is written, it cannot be retroactively changed or removed without leaving unmistakable evidence.

Architecture

All platform components emit structured audit events that flow through a centralized pipeline into multiple independent storage tiers. The multi-sink design ensures that no single component can be tampered with to destroy evidence.

What Gets Logged

All events are timestamped with millisecond precision, attributed to an authenticated principal, and tagged with service, host, and environment metadata.

Immutability Mechanisms

The audit log is protected by multiple layers — from software restrictions to cryptographic techniques to immutable storage.

Append-Only Logging

The system provides no interface to edit or remove log entries through normal operation. Even administrators have no function to retroactively modify or purge logs. The only permitted log removal is through the controlled archival process after the retention period.

Cryptographic Hash Chaining

Every audit log record is cryptographically linked to the previous record to form a hash chain:

Record_N.hash = SHA-256(Record_N.content || Record_N.metadata)
Record_N+1.prev_hash = Record_N.hash

Any alteration of an older entry breaks the chain — the hash in the subsequent entry no longer matches. An attacker would have to modify all subsequent records and recompute every hash, which is infeasible once hashes are externally sealed.

Periodic Merkle Tree Sealing

At regular intervals, all new log entries are collected and a Merkle tree is built. The resulting Merkle root represents the entire batch — if even a single bit changes in any entry, the root hash changes.

The Merkle root is:

• Stored on a tamper-evident ledger that cryptographically verifies every write and detects modification of historical data
• Optionally anchored to a public blockchain or transparency log for external, independent verification

Write-Once Storage (WORM)

Audit logs are regularly exported to Write-Once-Read-Many compliant storage with object-lock in compliance mode:

• Once log files are written and locked, they cannot be altered or deleted until the retention period expires
• No user — not even an admin — can purge or modify the data during the lock period
• If the primary log store is compromised, the WORM archive remains intact

Digital Signatures

Each sealed batch is digitally signed by the audit service:

• Provides cryptographic proof of origin — logs came from the system, not fabricated later
• Aids non-repudiation — system components cannot deny logged actions
• Signatures are stored alongside the log data and verified during archive import

Multi-Sink Redundancy

Logs are sent to multiple independent storage sinks simultaneously. An attacker would need to compromise all sinks to destroy evidence completely.

Event Categories

Authentication and Access

User Management

Administrative Actions

Business Operations

MPC Operations

System and Security

Security Controls

Access Control

• Only authorised security personnel or auditors can view logs
• Admin access to the audit log is itself logged (who searched, what query, when)
• Role separation: the security officer manages logs, separate from IT operations
• Dual-control for sensitive operations (e.g., clearing logs beyond retention requires two authorisations)

Sensitive Data Exclusion

Audit logs never contain:

• Passwords, API keys, or authentication tokens
• Private key material or key shares
• Full credit card or bank account numbers
• Personal data beyond what is necessary for identification (user ID, email)

The principle is to log what happened and who did it, not the sensitive content itself.

Transport Security

• Log forwarding is TLS-encrypted end-to-end
• SIEM integration uses syslog over TLS or message broker with authentication
• Multiple receiver endpoints can be configured for redundancy

SIEM Integration

The system supports flexible integration with external monitoring:

Events can be filtered per destination — e.g., only high-severity events to the SOC, full stream to the archive.

Integrity Verification

Record-Level Verification

For critical database tables (transaction intents, policy rules), the system stores a hash and a digital signature alongside each record. On every read, the service verifies the hash and signature — if a mismatch is found, an integrity violation event is raised and an alert is triggered.

Archive Verification

When archived logs are re-imported for review:

1. The system verifies the archive’s checksum against the value recorded at export time
2. The digital signature on the archive is verified
3. Import only appends data — it never overwrites or rolls back existing entries
4. Any integrity failure during import is logged as a security event

Retention Policy

• Minimum retention: 3 years on external immutable media
• Retention policy changes require Admin access and are themselves audit-logged
• Archive files are digitally signed at export time
• Disposal after retention requires dual authorisation