Skip to content

Hardening

Hardening is the process of reducing avoidable risk in a Xferity deployment by tightening configuration, limiting access, and treating transfer infrastructure as a security boundary.

Xferity includes hardened mode, but hardening is broader than one runtime flag.

Production hardening usually covers:

  • the host or container runtime
  • filesystem permissions for config, state, logs, audit files, and keys
  • secret bootstrap handling
  • certificate and SSH trust material storage
  • database credentials and connectivity
  • Web UI and API exposure
  • backup and retention controls

Self-hosted MFT systems hold credentials, trust anchors, business file payloads, and audit evidence.

That makes them infrastructure software with a meaningful trust boundary, not just utility tooling.

The current implementation includes a hardened mode that can reject insecure configuration patterns such as:

  • plaintext secrets in sensitive fields
  • insecure Vault TLS skip-verify settings
  • insecure Postgres SSL mode settings
  • partner definitions that disable expected TLS verification
  • UI startup without required authentication and TLS posture

This is useful because it makes insecure convenience settings fail early.

Hardening should also include procedures outside the runtime itself:

  • restrict who can read keys, certificates, and audit files
  • separate operator and administrator access where possible
  • export logs and audit records to external retention systems
  • review certificate expiry and rotation processes
  • avoid exposing UI and API surfaces without reviewed ingress controls
  1. use secret references instead of plaintext config values
  2. verify SSH host keys and TLS trust material explicitly
  3. enable hardened mode early in pre-production testing
  4. restrict filesystem and database permissions
  5. review UI authentication and TLS configuration
  6. test backup and recovery procedures