14 Security Hardening

This chapter lists what TraxrGRC enforces by itself and what you, as the operator, must do. Work through the operator checklist before go-live and again after each major change.

14.1 What the product enforces

14.2 Operator checklist

14.2.1 TLS and the network

• Serve the instance over HTTPS only, through the bundled Caddy or your own proxy.
• Give the instance a host name of its own. HSTS applies to the host name on every port and to every name below it, for a year; anything else served on that name must also use HTTPS. The header deliberately omits preload; submitting the domain to browser preload lists is the domain owner's decision.
• Leave WEB_BIND at 127.0.0.1 unless a proxy on another host needs it, and then firewall port 3000 to that proxy. A client that reaches port 3000 directly can choose the address recorded for it in throttling and the audit log.
• With your own proxy, overwrite or append X-Forwarded-For and set TRUSTED_PROXY_HOPS to match; apply the body size limits.
• Allow inbound traffic to ports 80 and 443 only. Never publish the database port.
• Restrict outbound traffic from the server to the services the instance uses (SMTP, LDAP, ACME, Docker Hub and npm during builds).

14.2.2 Secrets

• .env has mode 600 and is owned by the account that runs Docker.
• AUTH_SECRET, POSTGRES_PASSWORD, APP_DB_PASSWORD and the optional keys were generated with openssl rand, are unique to this instance, and are stored in the password vault.
• INITIAL_ADMIN_PASSWORD is removed from .env and from the migrate container.
• Shell access to the server, membership of the docker group and the database owner's password are limited to the people who operate the instance. Any of them can bypass every control in the application, including the audit log's protections.

14.2.3 Rotating AUTH_SECRET

Rotate AUTH_SECRET if it may have been exposed.

The consequences:

Server backups made with deploy/backup.sh are unaffected. To rotate:

1. Generate the new value: openssl rand -base64 32.
2. Replace AUTH_SECRET in .env and in the vault.
3. Apply it: docker compose --profile tls up -d.
4. Sign in and re-enter the integration secrets if needed; send a test email.

SETTINGS_ENCRYPTION_KEY and BACKUP_SIGNING_KEY are rotated the same way, with the effects in their own rows above.

14.2.4 Backups

• deploy/backup.sh runs nightly and its failures are alerted.
• Backups are copied off the server and encrypted with age, with the private key kept off the server.
• Access to the off-site copies is as restricted as access to the application's data.
• A restore drill has passed within the last quarter.

14.2.5 Accounts and access

• Every person has their own account; no shared accounts.
• Administrators are few. Everyone else gets rights through groups and roles at the lowest level that works (own before all, read before update). See Users, Groups and Roles.
• At least two break-glass administrators exist, with passwords in the vault, and their sign-ins are reviewed (each one emails a security alert to every administrator).
• Two-step verification is required under Settings → Sessions for password and LDAP sign-in, or SSO only is on if your identity provider enforces MFA.
• Session length and idle timeout under Settings → Sessions match your policy.
• API tokens have the narrowest scopes and a maximum lifetime set under Settings → Sessions; unused tokens are revoked. See API Access and Integrations.
• Local passwords, where used, follow your password policy. The product requires at least 8 characters for a local password, whether set by an administrator or changed by its owner on My profile.
• Separation of duties stays on unless you have a documented reason to relax it.

14.2.6 Monitoring

• SMTP works, so administrators receive security alerts.
• /api/health is monitored externally.
• The audit chain is verified daily and the chain head copied off the server.
• Audit log retention is set to your record-keeping requirement (365 days minimum). See Audit Log and Evidence Integrity.

14.2.7 Keeping up to date

• Upgrade to new releases promptly with deploy/update.sh; security fixes arrive only in releases.

• Keep the host operating system and Docker Engine patched.

• The postgres:18-alpine and caddy:2.11-alpine images are named by tag, so docker compose pull followed by docker compose --profile tls up -d picks up their patch releases. If your change process requires pinned images, pin them by digest in docker-compose.override.yml:

  docker pull caddy:2.11-alpine
  docker image inspect --format '{{index .RepoDigests 0}}' caddy:2.11-alpine
  

  Then set the service's image: to caddy:2.11-alpine@sha256:.... A pinned image never changes until you change the digest, so you then take on applying its security fixes yourself.

14.3 Known limits

These are properties of the design that the operator controls compensate for:

• Anyone with the database owner's password or root on the server can disable the audit triggers and rewrite entries along with their hashes. Copying the chain head off the server after each verification detects such a rewrite.
• The application role can add audit entries, so a compromised application process could add false entries, though it cannot change or remove existing ones.
• An unsigned snapshot (from before snapshot signing) can still be restored after an administrator confirms it; the restore is recorded as unsigned.
• Upload links for AI assistants carry their token in the URL path; they expire after 15 minutes.