Skip to main content

Security Architecture & Compliance Design Targets

Source: Marc Mercer (SRE Lead) — sre-iac repository, Rev 1.0, 2026-02-24

Important

This environment is NOT currently certified or audited against SOC 2 or HIPAA frameworks. The controls described here represent design targets that will be formally validated through third-party audit when production PHI processing begins. No real PHI is processed in the staging environment — all patient data is synthetic, generated by Synthea.

Compliance Design Targets

Anshin Health's infrastructure is intentionally designed to align with:

  • SOC 2 Type II — Security, Availability, and Confidentiality trust service criteria
  • HIPAA Security Rule — Administrative, Physical, and Technical safeguards (45 CFR Part 164)

This ensures security controls, access patterns, and operational procedures established in staging can be carried forward to production environments that handle PHI without requiring architectural redesign.

Data Classification

ClassificationDescriptionExamplesHandling
PHIProtected Health InformationPatient records, diagnosis, treatmentNOT present in this environment. All patient data is synthetic (Synthea).
ConfidentialBusiness-sensitiveAPI keys, credentials, certificates, encryption keysAES-256 encrypted at rest (Ansible Vault / Infisical). TLS 1.2+ in transit. Access restricted.
InternalNon-public business dataArchitecture docs, config files, source code, runbooksVersion-controlled in git. Access controlled via FreeIPA. Not exposed externally.
PublicExternally shareableMarketing materials, public API docsStandard handling. No special controls.

Access Control Architecture

Centralized Identity — FreeIPA

CapabilityImplementation
Directory ServicesLDAP (port 389 internal, 636 SSL)
AuthenticationKerberos (realm: ANSHINHEALTH.NET)
Certificate AuthorityIntegrated FreeIPA CA for internal certificates
DNSAuthoritative for anshinhealth.net internal zone
RedundancyActive-active replication (dc-01, dc-02)

Service integration: GitLab CE (LDAP via gitlab-binder), Grafana (LDAP via FreeIPA, dc-01:636 SSL), SSH (centralized key management + SSHFP DNS), all LXC containers (automated domain enrollment at provisioning time).

Role-Based Access Control (Least Privilege)

Infrastructure automation:

  • enroll/automation.anshinhealth.net — Enrollment Administrator only. Can enroll hosts and manage DNS records. Cannot create users or modify security policies.
  • terraform-prov@pve — Proxmox API account. Limited to container management. No storage, networking, or user administration.

Application service accounts:

  • gitlab-binder — LDAP bind for GitLab and Grafana. Read-only directory access.
  • Per-service Kerberos principals for host authentication.

Human access: Individual FreeIPA user accounts with role-based group membership. No shared administrative accounts.

SSH Security

ControlImplementation
AuthenticationKey-based only. Password authentication disabled.
Host VerificationSSHFP records in FreeIPA DNS for all hosts — prevents MITM.
Key TypesRSA, ECDSA, Ed25519 supported. SSHFP records maintained for all types.
Key InjectionSSH public keys injected at container provisioning via Terraform.
Access RestrictionPort 22 restricted to management networks via firewall rules.

VPN Access

NetBird VPN (nb-01, 10.10.96.21) provides secure remote access. All management interfaces (Proxmox, monitoring dashboards) are VPN-only. VPN does NOT provide access to MGMT VLAN (100) — that requires physical workstation.

Encryption

At Rest

Data TypeMethodStatus
Infrastructure credentialsAnsible Vault (AES-256)Implemented
Application secretsInfisical (AES-256-GCM)Implemented
Certificate private keysAnsible Vault (AES-256)Implemented
Block storage (Ceph)Ceph dm-crypt/LUKSPlanned (OpenStack environment)
Database storageNot yet encrypted at filesystem levelGap — planned with Ceph migration

Ansible Vault practices: Single vault password file (.vault_pass) excluded from git. All sensitive data encrypted before commit. No persistent storage of decrypted credentials. Vault password never logged.

Infisical practices: Self-hosted at infisical.svcs.anshinhealth.net. AES-256-GCM. Kubernetes Secrets Operator CRD for automated injection.

Critical Infisical Note

The Infisical ENCRYPTION_KEY is a single point of failure. Loss of this key results in permanent loss of all stored secrets. Backup procedures are essential.

In Transit

Connection TypeProtocolStatus
External HTTPSTLS 1.2+Implemented
Internal service communicationTLS 1.2+Partial (some internal services use plaintext)
LDAPLDAPS (TLS 1.2, port 636)Implemented
KerberosAES-256Implemented
VPN tunnelWireGuard/NetBirdImplemented
SSHOpenSSHImplemented

Certificate Management

AttributeValue
Certificate AuthorityZeroSSL (public, via ACME)
Validation MethodDNS-01 challenge via Route53
Certificate TypeECDSA (Elliptic Curve)
Validity Period90 days
Automationacme.sh with automated renewal
Renewal Threshold30 days before expiration

Certificate domains: *.anshinhealth.net, *.apps.anshinhealth.net, *.svcs.anshinhealth.net

Certificate lifecycle:

  1. DNS challenge tokens created in Route53
  2. ZeroSSL validates domain ownership via DNS
  3. ECDSA certificates generated (90-day validity)
  4. Private keys and renewal state encrypted with Ansible Vault
  5. Certificates deployed to reverse proxy (keys: 600, certs: 644, owned by caddy service user)
  6. Automated renewal triggers at 30 days before expiration

Network Security

Split-Horizon DNS

DNS ZoneProviderPurpose
Internal (anshinhealth.net)FreeIPA (dc-01, dc-02)Direct service resolution. Automatic discovery. LDAP/Kerberos integration.
External (anshinhealth.net)Route53 / CloudflarePublic records pointing to reverse proxy only. Internal IPs never directly resolvable from internet.

Firewall Zones

ZonePurposeKey Policy
UNTRUSTInternet-facing trafficDefault deny inbound. Only established/related connections permitted.
DMZPublic-facing servicesWAF, rate limiting, SSL termination. Limited access to TRUST zone.
TRUSTInternal production servicesInter-service communication permitted. No direct internet access.
HOMESTEADBryan's isolated networkWireGuard-only access. Completely separate from TRUST, MGMT, STORAGE.
MGMTManagement interfacesNEVER routed. Physical/direct-connect workstations only. Not available over VPN.
STORAGEStorage networkNEVER routed. Dedicated to Ceph traffic. No access from any other zone.

Service Firewall Rules

ServicePermitted PortsAccess Restriction
Domain controllers53, 88, 389/636Internal only
Reverse proxy80, 443External (80 redirects to HTTPS)
SSH22Management networks only
Kubernetes API6443Internal and VPN only
PostgreSQL5432Internal only, restricted to application hosts

Credential Management

Infrastructure Credentials (Ansible Vault)

CredentialPurposeScope
AWS access keysRoute53 DNS for cert validationLimited-scope IAM (Route53 only, no EC2/S3)
Kerberos principal/passwordFreeIPA enrollment automationEnrollment Administrator role only
Proxmox API tokenTerraform container provisioningContainer management only
ACME accountZeroSSL certificate issuanceCertificate lifecycle management
Docker Hub credentialsContainer image pullsRead-only registry access

Application Credentials (Infisical)

ProjectEnvironmentPathSecrets
anshin-infrastructureprod/monitoringgrafana-admin-user, grafana-admin-password, zoho-cliq-webhook-url

TSIG Keys (DNS Dynamic Update)

TSIG keys authenticate RFC2136 dynamic DNS updates from external-dns to FreeIPA. Key generated and stored in FreeIPA. Distributed to external-dns via Kubernetes Secret. Zone-scoped permissions (ipa-dns-grant.py manages zone delegation).

SOC 2 Control Mapping (Design Targets)

SOC 2 CriteriaControlImplementationStatus
CC6.1 — Logical AccessRBAC restricting access to authorized usersFreeIPA RBAC + group-based access. Keystone project isolation planned.✅ Implemented (FreeIPA) / Planned (Keystone)
CC6.2 — AuthenticationStrong authenticationKerberos, SSH key-based access, SSHFP DNS verification. MFA planned.✅ Implemented / Gap (MFA)
CC6.3 — Access RemovalTimely access removalFreeIPA account disable/delete propagates to all integrated services.✅ Implemented
CC6.6 — System BoundariesControls at boundariesFirewall zones, reverse proxy, VPN-only management access.✅ Implemented
CC6.7 — Data TransmissionEncryption in transitTLS 1.2+ external, LDAPS, Kerberos AES-256, WireGuard VPN.✅ Implemented
CC6.8 — Unauthorized SoftwarePrevent unauthorized softwareStandardized AlmaLinux 9 template, IaC-provisioned containers, no ad-hoc installs.✅ Implemented
CC7.1 — System MonitoringMonitoring for anomaliesPrometheus, AlertManager, Blackbox Exporter, Grafana.✅ Implemented
CC7.2 — Anomaly DetectionDetect anomalous activityCentralized log aggregation (Loki) planned.⚠️ Gap
CC7.3 — Security IncidentsIncident responseCertificate and auth incident procedures documented. Formal IR plan not established.⚠️ Partial
CC8.1 — Change ManagementAuthorization of changesGit-based IaC, revision-tracked docs, Terraform plan/apply workflow.✅ Implemented
CC9.1 — Risk MitigationRisk managementNetwork segmentation, encryption, access controls, monitoring. Formal risk assessment not conducted.⚠️ Partial

Document Control

RevDateAuthorDescription
1.02026-02-24Marc MercerInitial release