Files
certctl/migrations/000018_audit_events_worm.up.sql
T
Shankar 90f0cab204 fix(bundle-6): Audit Integrity + Privacy — 3 audit findings closed
Closes Audit-2026-04-25 H-008 (High), M-017 (Medium), M-022 (Medium).
Hardens audit-trail tamper-resistance + minimizes PII leakage in one
cohesive change, with both controls applying automatically and no
operator action required at install time.

What changed
- internal/service/audit_redact.go (NEW) — RedactDetailsForAudit:
    * credentialKeys deny-list (api_key, password, *_pem, eab_secret, ...)
    * piiKeys deny-list (email, phone, ssn, name, address, ip_address, ...)
    * case-insensitive key match; recurses into nested maps + arrays
    * mutation-free; surfaces redacted_keys array for operator visibility
    * nil/empty input → nil out (preserves pre-Bundle-6 behaviour)
- internal/service/audit.go — RecordEvent now routes details through
  RedactDetailsForAudit BEFORE marshaling. No call-site changes required.
- internal/service/audit_redact_test.go (NEW) — full coverage:
    * credential keys (~30 entries)
    * PII keys (~20 entries)
    * nested maps + arrays
    * case-insensitivity
    * mutation-free invariant
    * JSON round-trip (catches type-assertion regressions)
    * scalar pass-through (no panic on int/bool/nil)
- migrations/000018_audit_events_worm.up.sql (NEW) — DB-level WORM:
    * BEFORE UPDATE OR DELETE trigger raises check_violation with
      diagnostic citing the rationale + compliance-superuser hint
    * REVOKE UPDATE,DELETE ON audit_events FROM certctl (defence-in-depth)
    * REVOKE wrapped in pg_roles existence check so test fixtures
      without the certctl role stay idempotent
- migrations/000018_audit_events_worm.down.sql (NEW) — clean teardown
  for dev resets; not for production use.
- internal/repository/postgres/audit_worm_test.go (NEW, testcontainers,
  -short gated) — INSERT succeeds; UPDATE + DELETE fail with
  check_violation; second INSERT after blocked modification still
  succeeds (no trigger-state corruption).
- docs/compliance.md — new section "Audit-Trail Integrity & Privacy
  (Bundle 6)" with verification psql snippet, compliance-superuser
  pattern (NOT auto-created), redactor before/after example, and a
  maintenance note for adding new credential keys.

Compliance mapping
- H-008 (CWE-532 Insertion of Sensitive Information into Log File)
- M-017 (HIPAA Technical Safeguards §164.312(b) — audit controls)
- M-022 (GDPR Art. 32 — data minimization)

Threat model: TB-3 (audit log tampering), TB-1 (operator/orchestrator).

Verification
- go vet ./...                                → clean
- go build ./...                              → clean
- go test -short -count=1 ./...               → all packages pass
- go test -count=1 -run TestRedactDetailsForAudit ./internal/service/...
                                              → all pass
- (testcontainers, gated by -short) audit_worm_test.go pins WORM contract
- npx tsc --noEmit (web)                      → clean (no frontend changes)
- python3 yaml.safe_load(api/openapi.yaml)    → 89 paths

Backward compatibility
- Trigger applies forward only — existing rows unchanged.
- nil/empty details from RecordEvent callers → nil out (preserves prior
  behaviour for the many existing call sites that pass nil).
- Compliance superusers (provisioned out-of-band) bypass the trigger.

Bundle 6 of the 2026-04-25 comprehensive audit.
2026-04-26 00:26:44 +00:00

41 lines
1.7 KiB
PL/PgSQL

-- Bundle-6 / Audit M-017 / HIPAA §164.312(b) (audit controls):
--
-- audit_events is append-only at the database layer. The application
-- role cannot UPDATE or DELETE rows. Compliance superusers (legal hold,
-- retention purges) use a separate role provisioned out-of-band that
-- bypasses this trigger; see docs/compliance.md for the operator
-- pattern.
--
-- Pre-Bundle-6 enforcement was app-layer only (no DELETE/UPDATE method
-- on AuditService). A buggy migration script, a manual psql session, or
-- an attacker with the app role's DB credentials could rewrite history.
-- This trigger is the load-bearing defence; the REVOKE below is
-- defence-in-depth.
CREATE OR REPLACE FUNCTION audit_events_block_modification()
RETURNS TRIGGER AS $$
BEGIN
RAISE EXCEPTION 'audit_events is append-only (Bundle-6 / M-017 / HIPAA §164.312(b))'
USING ERRCODE = 'check_violation',
HINT = 'Use a compliance superuser role for legitimate retention operations.';
END;
$$ LANGUAGE plpgsql;
DROP TRIGGER IF EXISTS audit_events_worm_trigger ON audit_events;
CREATE TRIGGER audit_events_worm_trigger
BEFORE UPDATE OR DELETE ON audit_events
FOR EACH ROW
EXECUTE FUNCTION audit_events_block_modification();
-- Defence-in-depth: revoke UPDATE + DELETE from the app role too.
-- The role is conventionally `certctl` (matches docker-compose POSTGRES_USER
-- and Helm values.yaml postgresql.username). If the role doesn't exist
-- (test fixtures, single-superuser setups), the DO block is a no-op so
-- the migration stays idempotent across all environments.
DO $$
BEGIN
IF EXISTS (SELECT 1 FROM pg_roles WHERE rolname = 'certctl') THEN
REVOKE UPDATE, DELETE ON audit_events FROM certctl;
END IF;
END $$;