Is workload network access restricted (private endpoints, no public S3/Storage by default, no 0.0.0.0/0 SSH/RDP)?
Demonstrate that workload network configurations enforce private connectivity, prevent public internet exposure of storage services, and block unrestricted administrative access from the internet.
Description
What this control does
This control restricts cloud workload network access by eliminating public exposure of resources through enforcement of private connectivity patterns. It mandates the use of private endpoints or private links for PaaS services, disables public internet access to object storage (S3, Azure Storage, GCS) by default, and prohibits unrestricted (0.0.0.0/0) inbound access on administrative protocols (SSH port 22, RDP port 3389). Implementation typically involves network security group rules, storage account firewalls, service endpoint policies, and infrastructure-as-code guardrails that block public access patterns at provisioning time.
Control objective
What auditing this proves
Demonstrate that workload network configurations enforce private connectivity, prevent public internet exposure of storage services, and block unrestricted administrative access from the internet.
Associated risks
Risks this control addresses
- Unauthorized actors exploiting publicly exposed SSH or RDP services through credential stuffing, brute force attacks, or exploitation of unpatched vulnerabilities
- Data exfiltration via publicly accessible object storage buckets due to misconfiguration or overly permissive bucket policies
- Lateral movement after initial compromise of publicly exposed workloads that lack network segmentation
- Exposure of sensitive data in transit when PaaS services communicate over public internet rather than private backbone networks
- Automated scanning tools discovering and cataloging publicly accessible cloud resources for targeted attacks
- Ransomware deployment through compromised administrative interfaces accessible from any internet source
- Compliance violations under data residency and protection regulations requiring private network paths for regulated data
Testing procedure
How an auditor verifies this control
- Obtain a complete inventory of all cloud workloads, including compute instances (EC2, VMs, containers), storage accounts (S3 buckets, Azure Storage accounts, GCS buckets), and PaaS services (databases, application services, message queues) across all subscriptions and regions.
- Review network security group rules, firewall policies, and access control lists for all compute instances to identify any inbound rules permitting source 0.0.0.0/0 (or ::/0 for IPv6) on TCP ports 22 or 3389.
- Query cloud configuration APIs or review infrastructure-as-code repositories to identify all storage accounts and verify the 'public network access' setting is disabled or restricted to specific virtual networks and private endpoints.
- Examine PaaS service configurations to confirm private endpoints, service endpoints, or private links are configured and that public endpoint access is disabled or restricted via IP allowlists limited to corporate egress ranges.
- Select a statistical sample of workloads stratified by environment (production, staging, development) and criticality, and perform detailed configuration review of their network access controls.
- Test external accessibility by attempting to connect to sampled SSH/RDP services from an external internet source outside the corporate network to verify blocking is effective.
- Review cloud provider security center findings, configuration compliance reports, or third-party CSPM tool outputs for violations of public access policies over the past 90 days.
- Validate that infrastructure provisioning templates, CI/CD pipelines, and policy-as-code controls (Azure Policy, AWS SCPs, GCP Organization Policies) include preventative guardrails that deny deployment of publicly accessible resources.