Audit Log Integrity

The Audit Log Integrity page lets operators and GRC teams verify that the audit event chain has not been tampered with. mipo protects the audit log with a SHA-256 hash chain: each event records both its own hash and the hash of the previous event. The verification endpoint walks every event in order, recomputes each hash, and confirms the chain is unbroken. Use this endpoint on a schedule — monthly or before each compliance review — to produce evidence that the audit log is intact.

Fields & Columns

Name Description
rowsChecked Total number of audit events included in the verification pass. Events predating the hash chain (before the chain feature was introduced) are skipped.
violations Array of broken links. Each entry includes: id (the row where the break was detected), kind (row_hash_mismatch or prev_hash_mismatch), expected, and actual hash values.
ok Boolean — true means the full chain is intact with no violations.

How To

Verify audit log integrity

  1. Call GET /api/audit/verify with a valid session cookie (requires audit:view scope).
  2. Inspect the response: { rowsChecked, violations, ok }.
  3. If ok is true, the entire chain is intact — save the response as evidence.
  4. If ok is false, the violations array identifies which row IDs broke the chain and how (row_hash_mismatch or prev_hash_mismatch).

Schedule periodic integrity checks

  1. Use a cron job or monitoring system to call GET /api/audit/verify on a recurring schedule.
  2. Alert if ok is false or if the HTTP status is not 200.
  3. Store the JSON response alongside the alert for forensic reference.
  4. A mismatch that appears immediately after a database restore is expected — a restore replaces the chain with the backup snapshot. If no restore occurred, investigate immediately.

Gotchas

  1. A broken chain after a database restore is expected and does not indicate tampering — the restored chain reflects the backup point in time. If no restore occurred, a broken chain requires immediate investigation.
  2. The verifier walks the entire audit table in a single pass. On very large audit logs this may take several seconds; it does not paginate.
  3. Only audit events that have hash columns populated are checked. Rows created before the hash chain feature was introduced are silently skipped — they are not counted as violations.
  4. The endpoint requires the audit:view scope. Unauthenticated callers receive a 401; callers without the scope receive a 403.
  5. The verification endpoint is read-only and cannot repair a broken chain. If violations are found, do not modify the database — preserve the state for forensic analysis.

API Calls (1)

Method Path Description
GET /api/audit/verify Walk the entire audit event chain, recompute SHA-256 hashes, and return a pass/fail report with any broken-link indexes

Related Pages

  • Changes — The Changes log is the audit trail that this endpoint verifies
  • Views — View access records are also part of the audit log protected by the hash chain