Security Overview
Posture#
Abrq DIP is built for environments where the data cannot leave. Three commitments shape every security decision in the platform:
- Self-hosted, fully offline-capable. The platform runs entirely inside your network. There is no phone-home: license checks read a local file, telemetry export is opt-in (blank OTLP endpoint means no exporter), and air-gapped installs are a first-class deployment path.
- Deny by default. Every API mutation requires an authenticated identity and an explicit permission. Unknown capabilities are denied, missing project context is denied, and outbound network egress to internal address ranges is blocked unless you allowlist a host by exact name.
- Nothing sensitive in plaintext. Every stored credential — connector passwords, SMTP passwords, SSO and LDAP configuration, AI provider keys, notification targets — is encrypted at rest under an operator-held master key. Secrets are write-only through the API and are decrypted only at the moment of use.
The layers#
Security in Abrq DIP is layered; each layer is independent and documented on its own page:
| Layer | What it does | Page |
|---|---|---|
| Transport guards | HTTPS enforcement in production, HSTS, security headers, explicit CORS | Transport & egress |
| Authentication | Password auth with bcrypt, short-lived JWTs with rotating refresh tokens, API tokens, SSO/LDAP | Authentication |
| Authorization | Global roles (admin/editor/viewer) plus per-project, environment-aware RBAC | Roles & permissions |
| Secrets at rest | Fernet encryption of every stored secret, with a documented key-rotation ritual | Secrets & encryption |
| Audit | Append-only, hash-chained audit log with tamper detection and SIEM forwarding | Audit log |
| Egress protection | SSRF guards on all outbound connections, webhook rate limiting, minimal exposed surface | Transport & egress |
Where enforcement lives#
- All authorization decisions flow through a single backend chokepoint; every mutating ETL route is covered by an enforcement meta-test, so a new endpoint cannot ship unguarded.
- Permission denials return a structured 403 envelope and are themselves written to the audit log — a denied attempt is evidence, not silence.
- The audit chain can be verified three ways — an admin API call, a daily scheduled check, and an offline script — so tampering is detectable even in air-gapped deployments.
Note. Security-relevant configuration (master key, JWT secret, CORS origins, SSRF toggles) is set through environment variables. See environment variables for the full inventory and deployment for how each install path supplies them.