Slide 23 · MIT 05
Environment separation — dev, staging, and QA must not be internet-accessible.
Non-production environments belong on a private network. If they need external access, that access is explicit and monitored — not accidental.
The rule
Development, staging, and QA environments must not be reachable from the public internet. This is a network control, not a configuration suggestion. Default posture: non-production environments have no public IP and are only accessible through VPN, bastion host, or direct network access. Any exception (demo access, vendor integration) requires explicit authorization, is time-limited, and is logged.
🖧️
Private network by default
Non-production environments deploy to a private network (VPC, VLAN) with no internet gateway or no public IP assignment. All access is through VPN or internal network. This is enforced at the infrastructure level — not a configuration that developers can override without a change process.
💾
Synthetic or anonymized test data only
Staging environments must use synthetic data or properly anonymized copies of production data. Never copy production PII/PHI to staging without anonymization. If staging needs realistic data for testing, invest in data masking tools. The risk of a staging breach is significantly lower if the data cannot be used to harm real users.
📋
Audit cloud environments for accidental exposure
Cloud accounts accumulate environments over time. Run periodic audits: list all instances/services with public IPs, all load balancers with public listeners, all DNS records pointing to cloud resources. Flag any non-production environment with external accessibility for immediate review. Tools: AWS Trusted Advisor, GCP Security Command Center, Azure Security Center.
💼 Business takeaway
Ask your infrastructure team whether any staging, development, or QA environment is accessible from the internet — and whether it contains real user data. Both conditions together are a breach waiting to happen.