SOC2-CC6-ACCESS-BOUNDARY
Logical and Physical Access Boundary Controls
What this control does
Network and infrastructure controls that enforce boundaries between public-facing systems, internal networks, and restricted production environments.
Implementation guidance
Segment production, staging, and development into separate VPCs/networks. Apply security groups or firewall rules to restrict inter-segment traffic. No direct internet access to production databases. Document the network architecture and review after any infrastructure changes.
Requirements satisfied
Why it matters
Weak access boundaries allow attackers who compromise a public web server to move laterally into production databases, internal systems, and restricted environments. Network segmentation enforces "zero trust" principles by ensuring that breach of one system doesn't automatically grant access to all others, containing incidents and limiting blast radius.
Evidence to collect
- Network architecture diagram showing production, staging, and development VPCs/subnets with labeled security group rules or firewall policies between them
- Security group or firewall rule set for production environment (e.g., AWS Security Groups export or Azure NSG rules) showing explicit DENY rules for unauthorized ingress
- Change management log or ticket for the most recent infrastructure change, showing documented network topology updates and approval
- Output of network connectivity test (e.g., `traceroute`, security scanning tool report, or AWS VPC Flow Logs) confirming blocked unauthorized routes between segments
Testing procedure
Auditor requests the network architecture diagram and compares it against deployed security group/firewall rules to confirm production, staging, and development are in separate network segments. Auditor then attempts or simulates cross-segment access (e.g., production database from a staging instance) and verifies the connection is denied. Finally, auditor reviews the last three infrastructure changes to confirm network topology documentation was updated and changes followed approval workflow.
Common gotchas
Teams often create separate VPCs but leave overly permissive rules (e.g., security groups with 0.0.0.0/0 ingress or "allow all" between segments during troubleshooting) and forget to restrict them after. Another common mistake is documenting the network architecture once and never updating it after infrastructure changes, making the diagram a liability instead of a control.