openskills.info
Course Preview

Cloud Penetration Testing

Cloud penetration testing evaluates the security of workloads, configurations, and identities deployed on cloud platforms. It applies offensive techniques to find misconfigurations, overprivileged roles, exposed services, and lateral movement paths specific to cloud environments.

itOffensive security and application security

Cloud Penetration Testing

A cloud penetration test is an authorized attempt to prove how an attacker could reach valuable cloud resources. It tests more than open ports and web pages. It also tests identities, permissions, provider APIs, managed services, storage, and the paths between them.

Keep one mental model in mind: authorization defines the boundary; identity and provider APIs define the attack paths.

Cloud changes the shape of a penetration test. You still plan, discover, validate, report, and support remediation. You also work inside infrastructure shared with a provider and other customers. A technically possible action may be outside your authorization or the provider's rules.

Start with authorization

Written authorization is the first control in every engagement. It identifies who owns the target and who may test it. It also records the dates, contacts, objectives, permitted techniques, excluded systems, and stop conditions.

Provider permission does not replace customer permission. Microsoft, for example, allows testing against Azure resources you own or have explicit authorization to test. Google requires tests to affect only your projects. AWS distinguishes permitted customer resources from AWS infrastructure and services that customers may not assess.

Provider rules also differ. Azure and Google generally do not require prior notification for covered customer resources, subject to their rules. AWS permits testing of listed services without prior approval, while some services or activities require coordination. Provider policies can change, so verify them for every engagement.

Treat denial-of-service activity as excluded unless a specific, approved process says otherwise. Ordinary vulnerability validation rarely requires it. Establish a stop procedure for unexpected service impact, access to another tenant, sensitive data exposure, or evidence of an unrelated active compromise.

Map the cloud boundary

A useful scope map has four connected surfaces:

  1. Public workload surface — websites, application programming interfaces, load balancers, virtual machines, and exposed service endpoints.
  2. Cloud control plane — consoles and provider APIs that create, configure, and delete resources.
  3. Identity plane — human accounts, workload identities, roles, policies, federation, credentials, and sessions.
  4. Data plane — stored data and the operations that read, write, share, copy, or delete it.

Continue the course

This section is part of the paid course.

See pricing to subscribe, or log in if you already have access.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources

  • https://csrc.nist.gov/pubs/sp/800/115/final
  • https://aws.amazon.com/security/penetration-testing/
  • https://learn.microsoft.com/en-us/azure/security/fundamentals/pen-testing
  • https://support.google.com/cloud/answer/6262505?hl=en
  • https://cloud.google.com/terms/aup
  • https://attack.mitre.org/techniques/T1078/004/
  • https://attack.mitre.org/techniques/T1098/
  • https://attack.mitre.org/techniques/T1537/