Dit artikel is alleen in het Engels beschikbaar.
The cloud did not invent new classes of mistake; it made a small set of old ones faster to make, easier to miss, and larger in blast radius. A bucket one setting away from public, a role with more permission than it needs, a metadata service that hands out credentials to anything that asks: these appear in almost every cloud review. Here are the recurring ones and the fix for each, across the three major providers.
Public storage that was meant to be private
Object storage is the most common source of exposed data in the cloud. A bucket is made for internal use, a permission is loosened during a rushed deployment, and the contents become readable to anyone who knows the name. An assessment enumerates the target’s storage and checks each one for anonymous or overly broad access.
The fix is to block public access at the account level, so a single bucket cannot be made public by accident, and to keep sensitive data encrypted. Every provider now offers an account-wide switch for exactly this. The same review should cover snapshots, machine images, and managed databases, which carry the same data and are often forgotten.
Identity and access that is too broad
The second recurring finding is permission wider than the task requires. A service account is granted a broad policy because it was quick, and it keeps that permission long after the reason has gone. When one component is compromised, the attacker inherits everything that identity can do.
The single most valuable habit in cloud security is least privilege, granted narrowly and reviewed often.
A review reads the policies and looks for wildcards, admin roles attached to workloads, and permissions that no longer match the job. The fix is to grant the minimum a task needs, prefer short-lived credentials over long-lived keys, and remove unused permission on a regular review.
The instance metadata service
Every cloud instance can reach a metadata service that describes it and, in many configurations, hands out temporary credentials for the identity attached to it. Combined with a server-side request forgery flaw in an application on that instance, it turns a single web weakness into stolen cloud credentials.
The fix is to require the hardened, session-based version of the metadata service so a simple request cannot retrieve a credential, and to fix the underlying request-forgery flaw rather than relying on the metadata control alone.
Logging that is not there when it is needed
A cloud environment produces a complete audit trail, but only if it is turned on and kept. A recurring finding is that the provider’s audit log is disabled, is not retained, or is not sent anywhere a defender would look, leaving an incident that cannot be reconstructed. The fix is to enable the organisation-wide audit trail across all regions and accounts, protect it from deletion, and route it into the same monitoring as the rest of the estate.
The same idea across three providers
The mistakes are the same. The names differ. This table maps each recurring finding to where the setting lives, so a team can check their own environment.
| Recurring finding | AWS | Azure | GCP |
|---|---|---|---|
| Public object storage | S3 Block Public Access | Storage account public access | Public access prevention |
| Broad identity permission | IAM policies and roles | Entra ID roles and RBAC | IAM roles and bindings |
| Credential-bearing metadata | IMDSv2 required | Instance Metadata Service | Metadata server, block legacy |
| Missing audit trail | CloudTrail across regions | Azure Monitor and activity logs | Cloud Audit Logs |
| Open management access | Security groups | Network security groups | VPC firewall rules |
Closing
None of these needs a novel exploit; they are defaults left in place, permissions left too wide, and logs left off. That is what makes them common, and also what makes them fixable with a checklist and a regular review rather than a rebuild.
A corrected setting can also drift back, so cloud fixes need to be confirmed as well as applied. Pentrox includes retesting as standard and keeps every finding and retest result in one place. The Pentrox Portal page shows how that record is kept.
