About

The infrastructure implements a defense-in-depth strategy designed so that no single control is solely responsible for protecting any critical asset. Each layer provides an independent security boundary that reduces the impact of misconfigurations, software vulnerabilities, or credential compromise, so that in the event one control fails multiple safeguards remain in place to protect confidentiality, integrity, and availability.

Key layers include:

Network Layer

• Segmented public, service-plane, and control-plane networks
• A web application firewall providing incoming traffic inspection
• Cloud firewall policies applied at the perimeter
• Host-level firewalls defining east–west communication boundaries
• SSH ingress is allowed only within the private network

Identity & Access Layer

• Centralized authentication through the identity provider
• MFA enforced for administrative access
• Limited number of privileged accounts; admin and service accounts are vaulted

Application Layer

• Each service runs on dedicated hosts or isolated containers
• Reverse proxies enforce TLS, origin checking, and client validation
• Mutual TLS established between internal components

Data Layer

• Encrypted transmission (HTTPS, mTLS, key-based SSH)
• Encryption at rest and in transit
• Encrypted object-storage backups, with an encrypted offline copy kept outside the environment

The infrastructure follows a Zero Trust architecture model appropriate for a small, highly controlled environment. Zero Trust minimizes implicit trust between components and mitigates the risk of compromise of one host from cascading to the rest of the environment.

Zero Trust is implemented with the following principles:

Never Trust, Always Verify

• No internal traffic is implicitly trusted, even when originating from known hosts
• All authentication flows (user and service) require validation at each request
• Internal services are reachable only behind the web application firewall unless explicitly intended for public access

Service Isolation

• Workloads reside on separate hosts with restricted east–west access
• Application-to-application communication is permitted only through explicit firewall rules
• Critical services like the identity provider, password manager, and file storage are placed on their own servers and protected with stricter access controls than non-critical systems, and separated from user-facing application workloads

Verification Before Access

• TLS termination and certificate validation performed at the web application firewall
• Mutual TLS required for trusted internal connections
• SSH access is key-based and allowed only through the private network via the control-plane jump host
• VPN access to the private network requires a valid key pair from a device preconfigured as an authorized peer

Contextual Risk-Based Decisions

• Web application firewall anomaly detection and learning-mode tuning continuously reassess suspicious patterns and blocks potential threats automatically
• Brute-force protection guards authentication attempts on every host
• Alerts are configured based on automated log examination to provide oversight

The least privilege principle is applied so that accounts, services, and systems have only the access necessary to perform their required functions and nothing more. Least privilege reduces the attack surface and risk of privilege escalation.

Least Privilege is applied to the following access types:

User Access

• Administrative access restricted to specific authorized administrators who have been granted a VPN peer key and restricted sudo access on the hosts
• No shared admin credentials
• Application-specific permissions are defined individually and minimally scoped

Host Access

• Root login disabled over SSH
• SSH key authentication required; no password logins permitted
• Each host’s firewall allows SSH only from the private network

Service Access

• Each containerized service operates with minimal privileges and isolated volumes
• Service accounts in the identity provider have scoped roles and minimum privileges to perform application logins or API actions
• Internally issued certificates follow strict usage (server auth or client auth)
• Dynamic, short-lived credentials issued from the secrets vault are preferred over long-lived static secrets where supported

All data in the ecosystem is encrypted both at rest and in transit. Only the minimum data required for a service to operate is stored, and no data is intentionally shared with any external party. Logs and backups receive the same protections as primary data.