Cloud Security Testing: How to Test Your Cloud Infrastructure for Vulnerabilities

Your cloud environment is configured. Workloads are running. Applications serve traffic. Data flows between services. Everything works.

But does it work securely? Is the IAM role attached to your Lambda function scoped to only the permissions it needs, or does it have full S3 access across every bucket in the account? Is your RDS instance actually private, or did someone enable public accessibility during troubleshooting and forget to revert it? Is your security group allowing SSH only from the office VPN, or does it allow SSH from 0.0.0.0/0 because a developer needed temporary access six months ago?

Cloud environments accumulate misconfigurations the way old houses accumulate extension cords. Each one made sense at the time. Together, they create the conditions for a breach. The Capital One attack exploited an overprivileged IAM role through an SSRF vulnerability. The attacker didn't need to find a zero-day. They needed a misconfigured cloud environment, which is the default state of most cloud deployments.

Cloud security testing evaluates whether your cloud infrastructure actually resists attack. Not whether your architecture diagram looks correct. Not whether your policies are documented. Whether the actual running configuration of your AWS, Azure, and GCP environments prevents the misconfigurations, excessive permissions, and exposed services that attackers exploit.

This guide covers what cloud security testing involves, the shared responsibility model defining what you must secure versus what your provider secures, what gets tested across every cloud service category, common cloud vulnerabilities, testing methodology, how CSPM and cloud penetration testing complement each other, multi-cloud considerations, and best practices for securing your cloud infrastructure.

The Shared Responsibility Model: What You Must Test

Before testing anything, understand what's yours to secure. Every cloud provider operates under a shared responsibility model where the provider secures the infrastructure (physical data centres, hypervisors, global network) and you secure everything you configure on top of it.

What the Cloud Provider Secures

Physical security of data centres. Hardware maintenance and replacement. Hypervisor patching. Global network infrastructure. Base service availability.

What You Must Secure (and Test)

Identity and access. IAM policies, roles, users, groups, service accounts, MFA enforcement, cross-account access, federation configuration.

Network configuration. Security groups, NACLs, VPC design, subnet configuration, routing, VPN/Direct Connect, load balancer settings.

Data protection. Encryption at rest and in transit, key management, storage access policies, backup configuration, data lifecycle.

Compute configuration. Instance hardening, AMI/image security, container configuration, serverless function permissions, auto-scaling security.

Application security. Code running on cloud infrastructure remains your responsibility. Web applications, APIs, and backend services need security testing regardless of where they're hosted.

Logging and monitoring. CloudTrail, Azure Monitor, GCP Audit Logging configuration, log retention, alerting, and incident response.

Cloud security testing validates that your side of the shared responsibility model is correctly implemented. Misunderstanding the boundary is itself a cloud security risk: organisations assuming the provider handles something they actually don't.

What Gets Tested in Cloud Security Testing

Identity and Access Management (IAM)

IAM is the most critical cloud security testing area because overprivileged access is the most commonly exploited cloud vulnerability.

What testing covers:

• IAM policies follow least privilege (no wildcard * permissions on production resources)
• No IAM users with administrative access used for daily operations
• MFA enforced on all human accounts and console access
• Root/owner account secured with MFA and not used for routine tasks
• Service accounts scoped to minimum required permissions
• Access keys rotated within 90 days and unused keys disabled
• Cross-account access requires explicit trust policies with conditions
• IAM roles attached to compute resources are scoped to required services only
• Permission boundaries applied where appropriate
• Identity federation (SSO/SAML) configured securely
• Dormant accounts and roles identified and removed
• IAM policy conditions restrict access by IP, time, or MFA where appropriate

Why IAM matters most: In the Capital One breach, the attacker used SSRF to obtain temporary credentials from an overprivileged IAM role. Those credentials provided access to S3 buckets containing 106 million customer records. The IAM role needed access to one specific bucket. It had access to everything.

Storage Security

Cloud storage misconfigurations have caused more public data exposures than any other cloud vulnerability category.

What testing covers:

AWS S3:

• No publicly accessible buckets containing sensitive data
• S3 Block Public Access enabled at account level
• Bucket policies don't grant cross-account access without justification
• Server-side encryption enabled (SSE-S3, SSE-KMS, or SSE-C)
• Access logging enabled on sensitive buckets
• Versioning enabled for critical data
• Object-level ACLs reviewed (no unintended public objects)

Azure Blob Storage:

• Containers not set to public access
• Storage account network rules restrict access appropriately
• Azure Storage encryption enabled
• Shared access signatures (SAS) scoped and time-limited
• Storage account access keys rotated and protected

GCP Cloud Storage:

• Buckets not publicly accessible
• Uniform bucket-level access enabled
• Customer-managed encryption keys where required
• Access logging enabled

Network Security

Cloud networking complexity creates frequent misconfiguration leading to unintended exposure.

What testing covers:

• Security groups don't allow unrestricted inbound access (0.0.0.0/0) on management ports (SSH 22, RDP 3389)
• Security groups don't allow unrestricted inbound on database ports (3306, 5432, 1433, 27017)
• Default VPC not used for production workloads
• VPC flow logging enabled for network traffic visibility
• Network segmentation separates tiers (web, application, database)
• Private subnets used for resources that don't need internet access
• NAT gateways configured for outbound-only internet access from private subnets
• VPN/Direct Connect properly configured and secured
• Load balancers enforce HTTPS with modern TLS
• Web Application Firewalls configured for internet-facing applications

Compute Security

Compute resources (instances, containers, serverless) require configuration hardening beyond cloud defaults.

What testing covers:

Instances (EC2, Azure VMs, GCE):

• IMDSv2 enforced on all AWS instances (preventing SSRF credential theft)
• Instances not running with overprivileged IAM roles
• Public IP addresses only on instances requiring internet access
• Base images (AMIs/VM images) hardened and updated
• SSH key management following security practices (no shared keys)

Containers (ECS, EKS, AKS, GKE):

• Container images scanned for vulnerabilities before deployment
• No containers running as root unless required
• Container registries secured with authentication
• Kubernetes RBAC properly configured
• Pod security standards enforced
• Secrets not hardcoded in container images or environment variables

Serverless (Lambda, Azure Functions, Cloud Functions):

• Function permissions scoped to minimum required access
• Environment variables don't contain secrets (use secrets manager)
• Function timeout and memory limits configured
• VPC configuration appropriate for functions accessing internal resources
• Function URLs secured with authentication

Database Security

Cloud databases require explicit security configuration that cloud providers don't enforce by default.

What testing covers:

• Database instances not publicly accessible
• Database authentication using IAM where supported (not just password-based)
• Encryption at rest enabled
• Encryption in transit enforced
• Automated backups configured and tested
• Database security groups restrict access to application tier only
• Database audit logging enabled
• Parameter groups hardened (no insecure defaults)

Logging and Monitoring

Security testing validates that the logging infrastructure needed to detect and investigate incidents is operational.

What testing covers:

• CloudTrail/Azure Monitor/GCP Audit Logging enabled across all regions
• Multi-region trail configured (not just primary region)
• Log file integrity validation enabled
• Logs forwarded to centralised SIEM
• Alerting configured for critical events (root login, IAM changes, security group modifications)
• Log retention meets compliance requirements
• GuardDuty/Azure Defender/SCC threat detection enabled

Common Cloud Security Vulnerabilities

Overprivileged IAM Roles

Severity: High to CriticalPrevalence: Found in 80%+ of cloud security assessments

The most common and highest-impact cloud vulnerability. IAM roles granting far more permissions than the attached resource needs. Lambda functions with full S3 access. EC2 instances with administrative IAM permissions. Service accounts that can read every secret in Secrets Manager.

Risk: Any vulnerability in the attached resource (SSRF, RCE, compromised credentials) enables the attacker to abuse all permissions the role grants. Overprivileged roles amplify the impact of every other vulnerability.

Publicly Accessible Storage

Severity: High to CriticalPrevalence: Declining due to default-private settings, but still found regularly

S3 buckets, Azure Blob containers, or GCP Cloud Storage configured for public access, intentionally or accidentally. May contain customer data, internal documents, database backups, application credentials, or source code.

Risk: Direct data exposure to the internet. No authentication required. Automated scanning tools discover public buckets within hours of misconfiguration.

Unrestricted Security Groups

Severity: Medium to HighPrevalence: Found in majority of cloud assessments

Security groups allowing inbound traffic from any IP (0.0.0.0/0) on management ports (SSH, RDP), database ports, or application ports. Often created for troubleshooting and never reverted.

Risk: Internet-exposed services are actively scanned. Open SSH with password authentication is brute-forced within minutes. Exposed databases are targeted by ransomware automated campaigns.

Missing Encryption

Severity: MediumPrevalence: Common, especially on non-production resources

Storage, databases, and EBS volumes without encryption at rest. Data in transit without TLS enforcement. Encryption keys managed without rotation.

Risk: Data accessible to anyone who gains storage-level access (through misconfiguration, IAM abuse, or backup exposure) without encryption barriers.

Disabled Logging

Severity: Medium to HighPrevalence: Common in non-primary regions and newer accounts

CloudTrail disabled, limited to single region, or not forwarding to SIEM. VPC flow logs not enabled. Database audit logging not configured. Without logging, breaches go undetected and uninvestigable.

Risk: Attackers operate without detection. Incident response lacks data. Forensic investigation is impossible. Compliance requirements for audit trails are unmet.

IMDSv1 on AWS Instances

Severity: HighPrevalence: Common on older instances and legacy configurations

AWS Instance Metadata Service version 1 allows any process on the instance to retrieve IAM credentials through a simple HTTP GET request to 169.254.169.254. SSRF vulnerabilities on the instance enable external attackers to retrieve these credentials.

Risk: Combined with SSRF, IMDSv1 enables credential theft providing authenticated access to AWS services with the instance role's permissions. This was the Capital One breach vector.

Kubernetes Misconfigurations

Severity: HighPrevalence: Growing with Kubernetes adoption

Kubernetes dashboard publicly accessible. RBAC overprivileged. Pod security policies not enforced. Secrets stored unencrypted in etcd. Container images running as root.

Risk: Kubernetes misconfiguration enables container escape, cluster takeover, and access to all workloads and secrets in the cluster.

Cloud Security Testing Methodology

Phase 1: Scope and Configuration Review

Multi-account inventory. Identify all cloud accounts, subscriptions, and projects. Many organisations have more accounts than they realise: development, staging, sandbox, acquired company accounts.

Architecture review. Analyse VPC design, subnet layout, security group rules, IAM structure, and service interconnections. Understand intended architecture before testing actual configuration.

Compliance alignment. Identify applicable frameworks driving testing requirements (PCI DSS, SOC 2, ISO 27001, HIPAA).

Phase 2: Automated Security Assessment

CSPM scanning. Cloud Security Posture Management tools evaluate configurations against CIS Benchmarks, cloud provider best practices, and compliance frameworks. CSPM provides broad coverage identifying misconfigurations across all resources.

Cloud-native security tools. AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center provide platform-specific assessment.

Vulnerability scanning. Infrastructure vulnerability scanners assess OS patches, service vulnerabilities, and configuration weaknesses on compute resources.

Phase 3: Manual Cloud Penetration Testing

Automated scanning identifies misconfigurations. Manual cloud penetration testing validates which misconfigurations are exploitable and demonstrates business impact.

IAM exploitation testing. Testers attempt to escalate privileges through overprivileged roles, misconfigured policies, and trust relationship abuse. Testing demonstrates whether IAM findings from CSPM actually enable an attacker to access sensitive resources.

Cross-service attack paths. Testers chain findings across cloud services: using an overprivileged Lambda function to access S3, using S3 credentials to reach RDS, using database access to exfiltrate customer data. Individual misconfigurations become critical attack paths.

Application-layer testing. Cloud-hosted web applications and APIs require application-level security testing alongside infrastructure assessment. SSRF in a cloud-hosted application becomes a cloud infrastructure attack vector when it reaches metadata services.

Container and Kubernetes testing. Container escape testing, RBAC exploitation, secret extraction, and pod-to-pod lateral movement validation for containerised workloads.

For detailed exploitation methodology, see platform-specific guides for AWS, Azure, and GCP.

Phase 4: Reporting and Remediation

Findings with cloud-specific remediation. Each finding includes the specific AWS CLI commands, Azure PowerShell, or GCP gcloud commands needed to implement the fix. Not generic "reduce permissions" but specific IAM policy modifications.

Compliance mapping. Findings mapped to PCI DSS, SOC 2, ISO 27001, HIPAA, and NIST CSF.

Attack path documentation. Chained findings presented as complete attack narratives demonstrating how individual misconfigurations combine into data breach scenarios.

For reporting standards, see our penetration testing reports guide.

CSPM vs Cloud Penetration Testing: You Need Both

CSPM without pentesting: You know what's misconfigured but not what's genuinely dangerous. Remediation based on estimated risk.

Pentesting without CSPM: You validate specific items but lack continuous monitoring. Configuration drift goes undetected between tests.

Both together: CSPM provides continuous visibility. Pentesting validates which findings matter. CSPM catches new misconfigurations immediately. Pentesting proves impact that drives remediation urgency.

See our detailed CSPM guide for tool selection and implementation.

Multi-Cloud Security Testing

Organisations operating across AWS, Azure, and GCP face compounded cloud security testing challenges.

Multi-Cloud Risks

Inconsistent security policies. IAM works differently across providers. Security groups vs NSGs vs firewall rules have different syntax and behaviour. Encryption options and defaults vary. Consistent security posture across providers requires provider-specific expertise.

Cross-cloud attack paths. Shared credentials, federated identity, or network connectivity between clouds create attack paths spanning providers. Compromising one cloud environment may enable pivot to another.

Visibility gaps. Each provider has its own logging, monitoring, and security tools. Multi-cloud organisations need unified visibility or deliberate correlation across provider-specific tools.

Multi-Cloud Testing Approach

Test each cloud provider using platform-specific methodology and expertise. Evaluate cross-cloud connectivity for unintended access paths. Validate identity federation security across providers. Ensure consistent security policies despite different platform implementations. Use multi-cloud CSPM tools for unified posture management.

Cloud Security Testing for Compliance

PCI DSS

PCI DSS requirements applicable to cloud-hosted cardholder data environments include Requirement 1 (network security controls: security groups, NACLs), Requirement 2 (secure configurations: cloud service hardening), Requirement 3 (data protection: encryption, key management), Requirement 10 (logging: CloudTrail, audit logs), and Requirement 11 (testing: vulnerability scanning and penetration testing). Cloud security testing validates these requirements for cloud-hosted payment infrastructure.

SOC 2

SOC 2 Trust Services Criteria CC6 (access controls: IAM, network security) and CC7 (system operations: monitoring, logging) directly map to cloud security testing areas. Cloud security assessment provides evidence of control effectiveness.

ISO 27001

ISO 27001 Annex A controls A.8.9 (Configuration Management), A.8.20 (Networks Security), and A.8.24 (Use of Cryptography) align with cloud security testing. CSPM and cloud penetration testing provide evidence for ISO 27001 certification.

HIPAA

HIPAA Security Rule technical safeguards for cloud-hosted ePHI systems require access controls (IAM), audit controls (logging), and transmission security (encryption). Cloud security testing validates these safeguards.

For comprehensive compliance mapping, see our penetration testing compliance guide.

Cloud Security Best Practices

1. Enforce Least Privilege IAM

Every IAM role, user, and service account should have minimum permissions required. Use IAM Access Analyzer (AWS), Azure AD access reviews, and GCP IAM Recommender to identify excessive permissions. Audit IAM regularly. Remove unused permissions aggressively.

2. Enable and Monitor Logging Everywhere

CloudTrail in every region. VPC flow logs on every VPC. Database audit logging on every database. Forward everything to centralised SIEM. Alert on critical events: root login, IAM changes, security group modifications, public resource creation.

3. Encrypt Everything

Enable encryption at rest on all storage, databases, and volumes. Enforce encryption in transit. Use customer-managed keys (CMK) for sensitive data. Rotate keys regularly. Enable S3 default encryption at account level.

4. Block Public by Default

Enable S3 Block Public Access at account level. Default security groups to deny all inbound. Require explicit approval process for any resource needing public internet access. Treat public accessibility as an exception requiring justification, not a default.

5. Enforce IMDSv2 on AWS

Mandate IMDSv2 for all EC2 instances preventing SSRF-based credential theft. Configure new instances to require IMDSv2. Migrate existing instances from IMDSv1. This single control eliminates the Capital One breach vector.

6. Test Regularly

Annual cloud security assessment minimum. CSPM for continuous configuration monitoring. Quarterly or semi-annual cloud penetration testing for exploitation validation. Continuous testing for environments with rapid change velocity.

7. Infrastructure as Code Security

Scan Terraform, CloudFormation, and ARM templates for misconfigurations before deployment. Catch security issues in infrastructure definitions rather than in running environments. Shift cloud security left.

8. Segment Cloud Networks

Design VPCs with multiple subnets separating web, application, and data tiers. Use security groups and NACLs to restrict traffic between tiers. Private subnets for databases and internal services. Public subnets only for internet-facing load balancers.

When to Conduct Cloud Security Testing

Annually at minimum for compliance with PCI DSS, SOC 2, ISO 27001, and other frameworks.

After cloud migrations moving workloads from on-premises to cloud or between cloud providers.

After major architecture changes including new VPC designs, Kubernetes cluster deployments, serverless migrations, or multi-account restructuring.

After security incidents involving cloud infrastructure compromise.

When adding new cloud services introducing new AWS, Azure, or GCP services into the environment.

Before production launch of cloud-hosted applications processing sensitive data.

Continuously through CSPM for ongoing configuration monitoring between periodic penetration tests.

For frequency guidance, see our guide on how often to do penetration testing.

How AppSecure Tests Cloud Infrastructure

AppSecure provides comprehensive cloud security testing combining automated assessment with expert manual penetration testing.

Platform-Specific Expertise

Dedicated testing methodology for AWS, Azure, and GCP. Each platform's unique IAM model, service architecture, and attack vectors require provider-specific exploitation expertise.

IAM Exploitation and Attack Path Validation

Testers exploit overprivileged roles, chain misconfigurations across services, and demonstrate complete attack paths from initial misconfiguration to data access. Zero false positives ensure every finding represents genuine, exploitable cloud risk.

Beyond Infrastructure

Cloud security testing includes cloud-hosted web applications, APIs, mobile backends, and network infrastructure. Application security assessment covers every layer from infrastructure configuration to application code.

Compliance Mapping

Reports map findings to PCI DSS, SOC 2, ISO 27001, HIPAA, and NIST CSF. One cloud security assessment, multiple compliance frameworks addressed.

3-Week Delivery

Standard cloud security testing engagements deliver within three weeks. 90-day remediation support includes cloud-specific fix guidance and complimentary retesting. Continuous penetration testing and PTaaS maintain ongoing validation.

Ready for cloud security testing that proves what's exploitable?

Contact AppSecure:

• Schedule Cloud Security Testing
• Cloud Penetration Testing Guide
• Application Security Assessment

Frequently Asked Questions

1. What is cloud security testing?

Cloud security testing evaluates whether cloud infrastructure configurations across AWS, Azure, and GCP resist attack. Testing covers IAM policies and permissions, storage access controls, network security configurations, compute hardening, database security, logging and monitoring, and encryption implementation. Cloud security testing validates your side of the shared responsibility model: the configurations you control that cloud providers don't secure for you.

2. What is the shared responsibility model?

The shared responsibility model defines the security boundary between cloud provider and customer. The provider secures underlying infrastructure (physical data centres, hypervisors, global network). You secure everything you configure: IAM, network settings, storage access, encryption, application code, and monitoring. Cloud security testing validates your configuration responsibilities. Misunderstanding the boundary is itself a common cloud security risk.

3. What are the most common cloud security vulnerabilities?

The most common cloud security vulnerabilities include overprivileged IAM roles (found in 80%+ of assessments), publicly accessible storage, unrestricted security groups allowing inbound access from any IP, missing encryption at rest and in transit, disabled logging preventing incident detection, IMDSv1 on AWS instances enabling SSRF-based credential theft, and Kubernetes misconfigurations. Overprivileged IAM is consistently the highest-impact finding because it amplifies every other vulnerability.

4. How does cloud security testing differ from traditional security testing?

Cloud security testing addresses cloud-specific concerns: IAM policy evaluation, cloud storage configuration, security group analysis, metadata service protection, container and serverless security, and multi-cloud attack paths. Traditional security testing focuses on network infrastructure, operating systems, and application vulnerabilities. Cloud environments require both: cloud-specific configuration testing plus traditional application and network testing for workloads running in the cloud. The shared responsibility model means you must test what you configure, not just what you deploy.

5. What is the difference between CSPM and cloud penetration testing?

CSPM continuously monitors cloud configurations against security benchmarks, detecting misconfigurations automatically. Cloud penetration testing involves expert testers manually exploiting misconfigurations to prove which ones are genuinely dangerous and demonstrate business impact. CSPM tells you what's misconfigured. Penetration testing proves what's exploitable. Organisations need both: CSPM for continuous monitoring and pentesting for periodic validation.

6. How often should cloud security testing be conducted?

CSPM should run continuously for configuration monitoring. Cloud penetration testing should occur annually at minimum for compliance. Additional testing after cloud migrations, major architecture changes, new service adoption, and security incidents. Organisations with dynamic cloud environments benefit from quarterly cloud pentesting or continuous testing through PTaaS. The rapid pace of cloud configuration changes means annual-only testing creates significant exposure windows.

7. ,Which compliance frameworks require cloud security testing?

PCI DSS requires security testing for cloud-hosted cardholder data environments (Requirements 1, 2, 3, 10, 11). SOC 2 requires evidence of cloud access control and operational security (CC6, CC7). ISO 27001 requires configuration management and network security assessment (A.8.9, A.8.20). HIPAA requires technical safeguards for cloud-hosted ePHI. NIST CSF and FedRAMP require cloud security assessment for federal cloud services.

8. What tools are used for cloud security testing?

Cloud-native tools include AWS Security Hub, Microsoft Defender for Cloud, and GCP Security Command Center. Third-party CSPM tools include Wiz, Prisma Cloud, and Orca Security. Infrastructure scanning uses ScoutSuite and Prowler. Penetration testing uses platform-specific exploitation tools (Pacu for AWS, ROADtools for Azure, GCPBucketBrute for GCP) alongside standard security testing tools. Manual expert testing provides the exploitation validation automated tools cannot.

9. How do I prepare for cloud security testing?

Provision read-only IAM access for the testing team across all in-scope cloud accounts. Document cloud architecture including VPC design, account structure, and service inventory. Identify compliance frameworks the assessment must address. Provide documentation for cloud-hosted applications. Inform cloud operations and monitoring teams. Establish testing windows and emergency contacts. Review and address obvious issues (public storage, unused root access keys) before the assessment.

10. What is multi-cloud security testing?

Multi-cloud security testing evaluates security across organisations using multiple cloud providers (AWS, Azure, GCP). Testing addresses provider-specific misconfigurations on each platform, inconsistent security policies across providers, cross-cloud attack paths through shared credentials or network connectivity, identity federation security across providers, and unified visibility gaps. Multi-cloud testing requires expertise across all platforms being used, not just one.