Understanding Why Read-Only AWS Access Is Essential

At Tenendo, we often hear the question:

Why do you need read-only access to our AWS environment? We never had to provide this for on-premise segmentation testing.

The answer lies in the nature of modern cloud controls. Segmentation in AWS involves not only network settings but also IAM policies, resource sharing, security groups, Lambda permissions, and Kubernetes namespaces—factors that are invisible from an external scan or test. Without internal read-only access, critical violations can be missed, leading to failed PCI DSS assessments or exposure to lateral movement threats.

This article outlines the 10 most common segmentation violations in AWS that demonstrate why read-only access is not just useful—it’s essential.

Ten Common Segmentation Violations in AWS

1. Shared VLANs and Subnets

  • Inadequate isolation between PCI and non-PCI workloads within the same VPC
  • Overlapping CIDR ranges
  • Overly permissive security groups

2. Misconfigured IAM Roles and Policies

  • Cross-account access with excessive permissions
  • Shared roles between scoped and non-scoped environments
  • Lack of IAM boundaries for PCI segmentation

3. Unsegmented AWS Accounts

  • Shared users or roles across accounts
  • Ineffective Service Control Policies (SCPs)
  • Missing account-level isolation

4. Overly Permissive S3 Bucket Policies

  • Publicly accessible PCI-related data
  • Weak or missing bucket policies
  • Insecure cross-account access

5. Cross-Account Resource Sharing

  • VPC peering or Transit Gateway connections between scoped and non-scoped accounts
  • Misconfigured PrivateLink usage
  • Unmonitored inter-account data flows

6. Insecure Security Groups and NACLs

  • Use of 0.0.0.0/0 CIDRs
  • Lack of port-level control
  • NACLs not enforcing isolation

7. Lambda and Serverless Segmentation Gaps

  • Lambda functions with overly broad permissions
  • Shared VPC use between PCI and non-PCI Lambdas
  • Open API Gateway access

8. Weak Kubernetes (EKS/ECS) Segmentation

  • Shared namespaces for PCI and non-PCI workloads
  • Absent or weak pod security/network policies
  • No enforcement of workload isolation

9. Unrestricted Database Access

  • Publicly accessible RDS instances
  • Missing PrivateLink or Endpoint restrictions
  • Improper use of AWS Secrets Manager

10. VPC Peering and Transit Gateway Misconfiguration

  • No route segmentation
  • Lack of firewall filtering
  • Peering between PCI and non-PCI environments

Why Read-Only AWS Access Matters

To validate segmentation controls effectively, auditors or testing partners need visibility into internal AWS configurations. External testing alone cannot uncover overly permissive IAM policies, cross-account role assumptions, or missing security group boundaries.

Read-only CLI/Console access enables verification of:

  • IAM roles and trust policies
  • VPC peering and Transit Gateway routes
  • S3 bucket policies and logging
  • EKS namespace isolation and network policies
  • Lambda execution policies
  • RDS accessibility and encryption settings

This aligns with the PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures (Sept 2024), which emphasizes that cloud segmentation requires internal inspection of logical controls—not just perimeter testing.

Final Thoughts

Cloud segmentation testing isn’t just about what attackers can see—it’s about what your configurations silently allow. Read-only AWS access doesn’t pose a risk when handled responsibly, but it is the only reliable way to validate cloud segmentation in line with PCI DSS requirements.

At Tenendo, we help organisations ensure their AWS environments are properly segmented and compliant—because in the cloud, visibility is security.

More about the Practical Approach in the article.