Security Model & Best Practices
Learn how AllSafeX secures privileged credentials, isolates administrative networks, and enforces enterprise defense-in-depth policies.
Zero-Trust Architecture
AllSafeX operates under the assumption that internal networks may be compromised. By placing AllSafeX as a mandatory bastion between engineers and infrastructure:
- Target servers only accept connections originating from the AllSafeX host IP address.
- Target root credentials are never shared with human engineers.
- Every session is recorded, signed, and audited.
Role-Based Access Control
AllSafeX defines clear operational boundaries across four default roles:
| Role | Permissions & Capabilities |
|---|---|
| Administrator | Full control: user management, asset catalog, policy creation, and system configuration. |
| Auditor | Read-only access to audit logs, session recordings, and compliance reports. Cannot access target assets. |
| Operator | Can connect to authorized target servers via SSH/RDP. Cannot alter policies or view vaulted credentials. |
| Viewer | Read-only visibility into asset lists and system status dashboards. |
Encryption at Rest & in Transit
- In Transit: All HTTP traffic is protected by TLS 1.3. SSH traffic uses modern ciphers (
chacha20-poly1305@openssh.com,aes256-gcm@openssh.com). - At Rest: Stored private keys, system passwords, and secrets are encrypted in PostgreSQL using AES-256-CBC with keys derived from
SECRET_KEY.
Production Hardening Checklist
- Restrict PostgreSQL & Redis: Ensure ports 5432 and 6379 are bound exclusively to the internal Docker network (never bind to
0.0.0.0). - Enable UFW / iptables: Allow inbound traffic only on ports 80, 443, and 2222.
- Enforce HTTPS with Let's Encrypt / TLS: Replace default self-signed certificates with verified domain certificates.
- Rotate Bootstrap Tokens: Clear or rotate
BOOTSTRAP_TOKENafter initial microservice pairing.