Cloud Security Assessment Guide: Testing Cloud Infrastructure and Applications

Why Cloud Security Assessments Matter

The shared responsibility model is the foundation of cloud security, and it is also where most misunderstandings occur. Cloud providers (AWS, Azure, GCP) are responsible for securing the infrastructure that runs their services: physical data centres, hypervisors, and the underlying network fabric. The customer is responsible for everything they build and configure on top of that infrastructure: operating systems, applications, data, identity and access management, network configuration, and encryption. A cloud security assessment evaluates whether the customer side of that shared responsibility is being met.

Cloud misconfigurations are consistently among the top causes of data breaches. Public S3 buckets exposing sensitive data, overly permissive IAM roles allowing lateral movement, security groups with unrestricted inbound access, and unencrypted databases are all configuration errors, not software vulnerabilities in the traditional sense. They do not have CVE numbers or CVSS scores, but they can be just as damaging as any zero-day exploit. A cloud security assessment specifically targets these configuration weaknesses that traditional vulnerability scanners are not designed to detect.

The dynamic nature of cloud infrastructure makes periodic assessments insufficient on their own. Infrastructure-as-code deployments can spin up hundreds of resources in minutes, each potentially introducing new misconfigurations. Auto-scaling groups create and destroy instances continuously. Developers with cloud console access can make changes that bypass code review and change management processes. A comprehensive cloud security strategy combines periodic deep-dive assessments with continuous monitoring to catch configuration drift between assessment cycles.

Cloud Security Assessment Scope

Defining the scope of a cloud security assessment requires understanding the different service models and what falls within the customer's control at each level. The scope differs significantly depending on whether you are assessing Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS) environments, and most organisations use a combination of all three.

IaaS assessments (AWS EC2, Azure VMs, GCP Compute Engine) have the broadest scope because the customer controls almost everything above the hypervisor. This includes operating system hardening, patch management, network configuration (VPCs, security groups, NACLs), storage encryption, identity and access management, logging and monitoring, and application security. IaaS gives organisations the most flexibility but also the most responsibility, making it the most assessment-intensive service model.

PaaS assessments (AWS Lambda, Azure App Service, Google Cloud Run) have a narrower scope because the provider manages the operating system and runtime. The assessment focuses on application configuration, function permissions, API gateway security, secrets management, and the security of the code deployed to the platform. PaaS reduces the infrastructure management burden but introduces platform-specific security considerations such as function timeout exploitation, cold start information leakage, and event injection attacks.

SaaS assessments (Office 365, Salesforce, Workday) are the most limited in scope because the provider manages nearly everything. The assessment focuses on tenant configuration: authentication settings (MFA enforcement, SSO configuration), authorisation controls (role assignments, sharing settings), data loss prevention policies, integration security (OAuth grants, API tokens), and audit logging configuration. While the scope is smaller, SaaS misconfigurations can expose vast amounts of sensitive data because these platforms often contain an organisation's most valuable information.

Testing Cloud Storage Exposure

Cloud storage misconfigurations remain one of the most common and impactful findings in cloud security assessments. The ease of creating storage resources combined with complex permission models leads to frequent exposure of sensitive data. Every cloud security assessment should include a thorough review of storage configuration across all providers in scope.

For AWS S3, check bucket policies and access control lists (ACLs) for public access. AWS now blocks public access by default at the account level, but legacy buckets and accounts with the setting disabled remain vulnerable. Review bucket policies for overly broad principal statements (using wildcard "*"), check for cross-account access that may no longer be needed, and verify that server-side encryption is enabled with appropriate key management. S3 access logging and CloudTrail data access events should be enabled for buckets containing sensitive data so that unauthorised access attempts are recorded.

Azure Blob Storage introduces similar risks through container access level settings. Containers set to "Blob" or "Container" access level allow anonymous read access. Shared Access Signatures (SAS tokens) with excessive permissions or no expiry date are another common finding. Review Azure Storage account firewall rules to ensure that storage is not accessible from all networks when it should be restricted to specific VNets or IP ranges.

GCP Cloud Storage uses IAM policies and ACLs to control access. Check for the "allUsers" and "allAuthenticatedUsers" principals in bucket IAM policies, which grant public and organisation-wide access respectively. Review uniform bucket-level access settings, which simplify permissions by disabling object-level ACLs. Across all providers, use external scanning to validate that storage resources identified as internal-only are not actually accessible from the internet, as the configured permissions and actual network accessibility can diverge.

Assessing Cloud-Hosted Web Applications

Web applications hosted in cloud environments face the same application-layer vulnerabilities as those hosted on-premises, plus additional risks introduced by cloud-native architectures. Your assessment should cover both traditional web application security testing and cloud-specific concerns that affect how the application is deployed and accessed.

Dynamic Application Security Testing (DAST) is essential for cloud-hosted web applications. Authenticated scanning that crawls the application behind authentication discovers vulnerabilities that unauthenticated scans miss entirely: access control flaws, data exposure through authorised endpoints, insecure direct object references, and privilege escalation paths. For applications behind API gateways, test both the gateway configuration (authentication enforcement, rate limiting, request validation) and the backend services directly if accessible.

Serverless and containerised applications introduce specific testing considerations. Serverless functions may execute with overly broad IAM roles that allow access to resources beyond what the function needs. Container images may include known vulnerabilities in base images or installed packages. Kubernetes clusters may have misconfigured RBAC, exposed dashboards, or pods running with excessive privileges. API endpoints backed by serverless functions should be tested for event injection, where malicious input in the event source (HTTP request, queue message, storage trigger) exploits the function logic.

Cloud-native applications often rely on managed services for authentication (Cognito, Azure AD B2C, Firebase Auth), data storage (DynamoDB, Cosmos DB, Firestore), and messaging (SQS, Event Grid, Pub/Sub). Each integration point is a potential vulnerability surface. Test the configuration of these managed services: are authentication flows properly implemented, are database access controls appropriately scoped, are message queues accessible only to authorised services? The security of the application depends not just on its code but on the entire constellation of services it interacts with.

Infrastructure and Network Assessment

Cloud infrastructure assessment focuses on the network configuration, compute security, and identity management that form the foundation of the cloud environment. Unlike on-premises networks where security is often perimeter-focused, cloud networks require a defence-in-depth approach where every layer enforces its own access controls.

Start with network segmentation. Review VPC (or VNet) architecture to verify that production, staging, and development environments are properly isolated. Check security group rules for overly permissive inbound access, particularly rules allowing 0.0.0.0/0 on management ports (SSH port 22, RDP port 3389) or database ports (3306, 5432, 1433). Network ACLs provide an additional layer of control and should be reviewed for rules that contradict the security group policy. VPC flow logs should be enabled to provide network-level audit trails for incident investigation and compliance evidence.

Identity and Access Management is often the most critical area of a cloud infrastructure assessment. Review IAM policies for adherence to the principle of least privilege. Look for users and roles with administrative access that do not need it, policies using wildcard actions or resources, and access keys that have not been rotated or are attached to the root account. Check for cross-account trust relationships that may grant access to external AWS accounts. Verify that MFA is enforced for console access, especially for privileged accounts. IAM misconfigurations are the most common path from an initial foothold to full cloud account compromise.

Assess the attack surface of exposed services. Enumerate all public-facing resources: load balancers, API gateways, EC2 instances with public IPs, cloud functions with HTTP triggers, and managed services with public endpoints. For each exposed service, verify that it should be public, that it is protected by appropriate authentication, and that it is not running outdated software with known vulnerabilities. Cloud environments often have a larger public attack surface than organisations realise because resources can be made public with a single configuration change.

Cloud Compliance and Regulatory Requirements

Cloud environments must meet the same compliance requirements as on-premises infrastructure, but the implementation details differ significantly. A cloud security assessment should evaluate compliance posture against the frameworks relevant to the organisation and identify gaps that could result in audit findings or regulatory penalties.

Data residency requirements add another layer of complexity in cloud environments. Regulations like GDPR restrict where personal data can be stored and processed. Your assessment should verify that cloud resources are deployed in compliant regions, that data replication and backup policies do not copy data to restricted regions, and that the organisation has contractual protections (Data Processing Agreements) with their cloud providers. Some managed services replicate data globally by default unless explicitly configured otherwise, which can create compliance violations that are invisible without careful assessment.

Tools and Methodology for Cloud Security Testing

Effective cloud security assessment combines cloud-native security tools, third-party scanning platforms, and manual review. No single tool covers all aspects of cloud security, so a structured methodology that integrates multiple tools produces the most comprehensive results.

Cloud provider-native tools provide a starting point. AWS Security Hub, Azure Security Centre, and GCP Security Command Centre aggregate findings from multiple security services and benchmark configurations against standards like CIS Benchmarks. These tools are useful for continuous monitoring but are limited to their respective provider and may not flag all the issues a dedicated security assessment would identify. They are also controlled by the cloud account owner, which means they may be unconfigured, their findings may be suppressed, or their recommendations may be ignored.

Third-party tools like ScoutSuite, Prowler, and CloudSploit provide cross-cloud assessment capabilities with opinionated security checks that go beyond the provider's native recommendations. For web application testing of cloud-hosted applications, use external vulnerability scanning to assess the internet-facing attack surface, combined with authenticated scanning for applications behind authentication. Infrastructure-as-code scanning tools (tfsec, Checkov, KICS) analyse Terraform, CloudFormation, and Kubernetes manifests to identify security issues before deployment.

Manual review remains essential for areas where automated tools fall short. IAM policy analysis often requires human judgment to determine whether a policy is overly permissive in the context of the specific application. Architecture review identifies design-level weaknesses such as single points of failure, missing defence-in-depth layers, and trust boundary violations that automated tools cannot detect. Threat modelling for the specific cloud architecture maps out attack paths that combine multiple low-severity findings into high-impact chains. The most valuable cloud security assessments combine automated coverage with expert analysis.

Delivering Cloud Security Assessment Reports

Cloud security assessment reports must communicate findings to multiple audiences: the cloud engineering team that will implement fixes, the security team that will track remediation, and the executive leadership that will fund improvements. Each audience needs different information at different levels of detail, and your report structure should serve all three without forcing any of them to search for what they need.

Organise findings by severity and cloud service rather than by tool output. Stakeholders do not care which tool found the issue; they care how critical it is and which systems it affects. Group related findings together: all IAM issues in one section, all network configuration issues in another, all storage exposure issues in a third. For each finding, provide the affected resource (with specific identifiers like ARN, resource ID, or URL), the security impact, the recommended remediation with cloud-specific steps, and the compliance frameworks affected.

Prioritise remediation recommendations based on exploitability and impact rather than sheer volume. A report listing 200 findings of equal priority is not actionable. Identify the ten findings that represent the highest risk and call them out explicitly in the executive summary with clear business impact descriptions. Use a security platform with cloud security assessment capabilities to track remediation progress, verify fixes through rescanning, and demonstrate risk reduction over time. The initial report is only the beginning; the value comes from driving findings to resolution and verifying that fixes are effective.