V1 [SEC] Audit logging for administrative operations

[austin-barrington]

Context

HyperbyteDB has no audit trail. When auth is enabled, there is no record of:

• Who created or dropped a database
• Who created or dropped a user
• Who changed a retention policy
• Who ran DELETE queries
• Who created or dropped continuous queries or materialized views
• Failed authentication attempts

For production deployments — especially those with compliance requirements (SOC2, PCI-DSS, HIPAA) — an audit log is essential.

Deliverables

• Add an audit logging system that records security-relevant events to a separate log stream (or structured log at info level with an audit marker).

• Events to log:

  Event	Data
  auth.login.success	username, source IP
  auth.login.failure	username (if provided), source IP, reason
  ddl.create_database	db name, user
  ddl.drop_database	db name, user
  ddl.create_user	username, admin flag, user
  ddl.drop_user	username, user
  ddl.grant	target, privilege, user, grantor
  ddl.revoke	target, privilege, user, revoker
  ddl.create_retention_policy	db, rp name, user
  ddl.alter_retention_policy	db, rp name, user
  ddl.create_continuous_query	name, db, user
  ddl.drop_continuous_query	name, db, user
  ddl.create_materialized_view	name, db, user
  ddl.drop_materialized_view	name, db, user
  data.delete	measurement, db, user
  admin.chdb_query	query (redacted), user

• Use structured logging with event and actor fields for compatibility with SIEM tools.

• Do NOT log sensitive data (passwords, tokens, full query bodies).

• When auth is disabled, log actor: "anonymous" or omit actor.

Configuration

Add tracking of audit events to the config:

Key	Type	Default	Description
audit.enabled	boolean	true	Enable audit event logging
audit.log_failed_logins	boolean	true	Log failed auth attempts separately

References

• docs/user-guide/authentication.md — existing auth docs
• docs/user-guide/administration.md — logging section (structured JSON output)

Priority

P1 — Compliance, security baseline