Security and Hardening
DeskDox production security should be implemented as layered controls across the network, host, container runtime, application configuration, database, storage, backup, integrations, and operations.
Core Security Position
Do not expose database, converter, worker, Docker daemon, or internal service ports publicly. The public surface should be limited to the approved DeskDox web endpoint and only the integration endpoints explicitly required by the deployment model.
Layered Security Model
| Layer | Baseline control |
|---|---|
| Network edge | FQDN, HTTPS/TLS, firewall restrictions, optional WAF or reverse proxy controls. |
| Host OS | Patched OS, restricted admin access, endpoint protection, time sync, disk monitoring. |
| Docker runtime | Approved runtime version, restricted Docker access, controlled Compose files, restart policies. |
| Application | DEBUG=false, correct public URL, rate limiting, RBAC, audit logging, maintenance controls. |
| Database | Internal-only network access, strong credentials, backup coverage, restricted admin access. |
| Storage | Durable paths, least-privilege filesystem permissions, antivirus/EDR compatibility, encryption where required. |
| Integrations | Least-privilege API keys, outbound allow-lists, credential rotation, vendor risk review. |
| Operations | Monitoring, log retention, patch cadence, backup review, escalation, change control. |
TLS and HTTPS
Production DeskDox access should use HTTPS. HTTP should be redirected to HTTPS or restricted to internal health/implementation use. TLS certificate ownership, renewal, cipher policy, and HSTS configuration must follow the customer security standard.
Secrets Management
The following values must be treated as secrets:
JWT_SECRET_KEYPOSTGRES_PASSWORDDATABASE_URLwhen it contains credentialsBACKUP_ENCRYPTION_KEY- SMTP passwords or tokens
- WhatsApp access tokens and app secrets
- OpenAI/Azure/OpenAI-compatible API keys
- License or activation secrets where applicable
Environment files must be access-restricted. Secrets should not be pasted into tickets, screenshots, handover documents, or unsecured chat channels. Rotation procedures should be agreed for long-lived production deployments.
Database Isolation
PostgreSQL must remain internal-only. Remote database access, if required for DBA operations, must use a controlled administrative path such as VPN, bastion, restricted firewall rule, or approved database management plane. Public internet exposure of port 5432 is not acceptable.
Least Privilege Access
Least privilege applies to:
- Host administrators.
- Docker operators.
- DeskDox application administrators.
- Database administrators.
- Backup operators.
- Integration credential owners.
Application admin accounts should be named accounts where possible. Shared administrator accounts should be avoided or governed through a privileged-access process.
Auditability
Production readiness validation should confirm that representative login, document, sharing, admin, and workflow events are visible in audit/history views. Audit retention expectations must be reviewed because long retention windows affect database growth and reporting performance.
Admin Account Control
Initial administrator credentials must be rotated or transferred through an approved secure process after installation. Dormant, test, and implementation accounts should be disabled or removed before production handover.
Public Link Controls
Public document links, file requests, document email links, and password reset links depend on correct public URL configuration and token controls. Customers should review link expiry, recipient expectations, external access policy, and audit requirements before enabling public-facing document workflows.
Backup Encryption
Backups should be encrypted when handled by DeskDox backup tooling or stored outside protected infrastructure. The BACKUP_ENCRYPTION_KEY must be stored separately from the backup archive. Losing the key may make encrypted backups unrecoverable; exposing the key may compromise backup confidentiality.
Filesystem Permissions
Document storage, preview data, index data, backup paths, licensing files, and environment files should be restricted to the required service or administrator identities. On Windows, endpoint security exclusions must prevent file locking and quarantine without disabling monitoring. On Linux, SELinux/AppArmor policy interactions must be reviewed where enforcement is enabled.
Container Hardening
Production hardening should include:
- Use only approved image tags.
- Avoid uncontrolled
latestusage unless deliberately used during a temporary implementation phase. - Restrict Docker socket exposure to components that genuinely require it.
- Monitor container restarts and health status.
- Keep host Docker runtime patched.
- Prevent public access to Docker APIs.
Patching and Upgrade Cadence
Customer change management should define:
- OS patch window.
- Docker/runtime patch window.
- DeskDox application upgrade window.
- Backup taken before upgrades.
- Rollback or restore plan.
- Post-upgrade smoke test and handover note update.
Logging and Monitoring
Monitor application health, container state, CPU, RAM, disk, database availability, backup success, preview/index worker behavior, email failures, and integration errors. Logs should be retained according to customer policy and reviewed for sensitive data exposure.
Security Readiness Checks
Before go-live:
- HTTPS is active on the production URL.
- Placeholder secrets have been replaced.
- Internal service ports are not publicly reachable.
- Admin accounts are controlled.
- Backup encryption key handling is documented.
- Audit logging has been validated.
- Security owner and residual risk notes are recorded where applicable.