Book 4

Security Documentation

OPSQAI is designed to be operated by risk-averse teams. This book documents the controls that ship in every self-hosted install.

1. Encryption

In transit — HTTPS terminated at the reverse proxy; internal traffic on a private Docker network.
At rest — Postgres data volumes and object bucket should be on encrypted volumes (LUKS, BitLocker, cloud KMS).
Application-level — sensitive fields (SMTP passwords, provider keys, backup encryption keys) are AEAD-encrypted with OPSQAI_MASTER_KEY before they hit Postgres.

2. Authentication

Email + password with Argon2id hashing, optional Google OAuth, optional SAML/OIDC SSO. Session tokens are HTTP-only cookies bound to origin. Refresh rotation on every request. Password reset uses single-use signed tokens with a 30-minute TTL.

3. Authorization

Every tenant table has Row-Level Security enabled. Roles live in a dedicated public.user_roles table and are read through a SECURITY DEFINER function to prevent recursive policy checks. Admin server functions verify the caller's role under RLS before escalating to the service-role client.

4. License security

License tokens are Ed25519-signed. The public key is pinned in the image. Tampering invalidates the token; a missing MC does not unlock features — it only extends the last-verified state for 14 days.

5. Update signing

Every release bundle and every container image is signed with cosign. The Administrator Guide instructs operators to verify the signature before running docker compose up. Public keys are published on opsqai.de/security.

6. Backup security

Backups are encrypted with a per-instance key derived from OPSQAI_MASTER_KEY using HKDF. Restore requires the same key — losing it is unrecoverable, by design.

7. Audit logging

Every privileged action (license activation, role change, backup restore, config change, sign-in from a new device) writes a row to audit_log with actor, target, before/after diff and IP. The log is append-only and cannot be edited from the UI.

8. DR / BC

Recommended RPO 24h, RTO 4h with the default nightly backup schedule. Operators can tighten both by enabling continuous WAL archiving to S3 and standing up a warm standby — the compose file has a documented standby profile.

9. Incident response

Report suspected vulnerabilities to security@opsqai.de. Responsible disclosure policy on opsqai.de/security. Coordinated CVEs will be published in the release notes and cross-linked from the Customer Portal.