Cloud penetration testing

Every major cloud provider describes security as shared. AWS frames it as the provider being responsible for security of the cloud and the customer for security in the cloud. In practice: the provider secures the data centers, hardware and core services; you secure how you configure them, who can access them, and what you put inside them.

A cloud penetration test focuses on your side of that line. It does not try to break the provider's own infrastructure, which every provider forbids and which is not your risk to manage. It asks whether the way your team set things up gives an attacker a way in.

The split shifts with the service type. With managed databases or serverless functions the provider takes on more, but identity and data permissions always stay with you.

Yes, within published rules, and none of the three largest providers currently require approval for standard testing of your own resources:

• AWS publishes a list of services customers may test without prior approval. It prohibits activities such as denial-of-service, flooding, DNS zone walking against Route 53 and subdomain or bucket takeover, and asks for advance notice of certain simulated events like red team exercises.
• Microsoft Azure has not required pre-approval since 2017, but testers must follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement, which ban denial-of-service and testing tenants you do not own.
• Google Cloud states customers do not need to contact Google before testing their own projects, provided they follow its Acceptable Use Policy and Terms of Service and affect only their own projects.

These policies change, so the test plan cites the current version at the time of scoping.

Cloud tests are usually a mix of two angles. An outside-in pass looks at what is exposed to the internet. An assumed-breach pass starts from a set of limited credentials (for example, the permissions a single developer or a single compromised workload would have) and tries to escalate. The second angle is where most impactful cloud findings come from, because it reveals how far one leaked key would go.

1. List the accounts, subscriptions or projects in scope, and which are production.
2. Provide a read-only auditing role so configuration can be reviewed across all regions.
3. Provide one or more low-privilege starting identities for the assumed-breach pass.
4. Agree what must not be changed or deleted, and which actions need a call first.

Configuration tools list hundreds of warnings; most teams cannot tell which ten matter. A cloud penetration test turns that list into attack paths: this role can update that function, which runs as an identity that can read the customer database. In Brexa's Prove stage an operator walks the path and records each step. Fixes then target the link that breaks the chain most cheaply, often a single overly broad policy following the principle of least privilege. Verify replays the path afterwards to confirm it no longer works.