Cloud Configuration Security Reviews: What Needs to Be Assessed

When operating infrastructure in Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP), security is governed by the Shared Responsibility Model. The cloud service provider guarantees security OF the cloud: the physical security of data centres, hardware supply chains, power redundant facilities, and core virtualization hypervisors.

The customer remains responsible for security IN the cloud: Identity and Access Management (IAM) permissions, data storage bucket access policies, network ingress rules, encryption key lifecycles, and application configurations. The exact boundary shifts across service tiers: in Infrastructure as a Service (IaaS), customers configure and patch the operating system and virtual firewalls; in Platform as a Service (PaaS), the provider manages the operating system while the customer controls database access and application logic; in Software as a Service (SaaS), the provider operates the full application stack, leaving the customer responsible for user access, identity federation, and data protection settings.

According to cloud security research from major analyst firms (including Gartner and the Cloud Security Alliance), the overwhelming majority of cloud security compromises originate from customer configuration errors, excessive identity permissions, and unhardened storage policies within tenant environments, rather than architectural flaws in the underlying hypervisor or provider physical infrastructure.

A Cloud Configuration Security Review is a deep-dive audit of your cloud management control plane. Rather than merely scanning for operating system vulnerabilities on individual virtual machines, reviewers inspect the APIs, IAM trust relationships, and architectural policies that govern your entire cloud estate.

In cloud environments, IAM permissions represent the true security boundary. A single compromised identity with over-privileged rights can lead to total tenant takeover. Reviewers evaluate:

• Wildcard Permissions and Privilege Escalation Paths: Detecting identities granted wildcard permissions. Reviewers specifically examine dangerous permission pairings—such as granting an unprivileged user permission to pass roles combined with permission to launch compute workloads. An attacker with these rights can launch an instance with an administrator role attached and capture administrative cloud tokens.

• Cross-Account Trust Relationships: Reviewing assume-role trust policies that allow third-party SaaS vendors or external partner accounts into your environment. Reviewers verify that trust policies enforce a mandatory, unpredictable external identifier condition to prevent Confused Deputy vulnerabilities.

• Root and Global Admin Hygiene: Verifying that AWS root accounts or Azure Global Admin accounts possess hardware MFA, lack active programmatic API access keys, and are monitored for emergency breakout logins.

Inadvertent data exposure through public cloud storage remains one of the leading causes of enterprise data leakage. A structured cloud review examines:

• Public Access Block Enforcement: Confirming that AWS S3 Block Public Access is enforced at the organization level, Azure Blob public access is explicitly disabled at the subscription level, and Google Cloud Storage buckets enforce uniform bucket-level access.

• Cryptographic Key Management (KMS): Auditing whether database snapshots, disk volumes, and object buckets utilize customer-managed keys (CMKs) with annual automated key rotation enabled, rather than relying on default provider keys that grant broad internal service access.

• Backup Immutability: Ensuring production database backups and storage archives cannot be immediately modified or deleted if an administrative identity is compromised. This requires configuring S3 Object Lock in Compliance mode or Azure Immutable Blob Storage with legal hold protection.

In cloud platforms like AWS, workloads such as virtual compute instances or serverless functions require permissions to interact with other cloud services. To enable this securely, administrators grant users the ability to pass an IAM role to the workload using role-passing permissions.

However, when an administrator grants an engineer permission to launch compute workloads combined with unconstrained permission to pass any role across the environment, an immediate administrative escalation vector is created:

• The Escalation Path: An engineer with standard development permissions initiates the launch of a new virtual machine or lambda function, explicitly attaching the existing corporate Administrator IAM role to the new workload. Once the workload boots, the user connects to it and queries the internal Instance Metadata Service (IMDS). The metadata service immediately returns temporary cloud security tokens bearing full administrative permissions. Without ever modifying their own user policy, the developer has escalated their privileges to complete cloud administrator.

• Scoped Role Constraints: Never use wildcard resources in role-passing statements. The policy must explicitly list the exact Amazon Resource Names (ARNs) of standard workload roles that the developer is authorized to pass.

• Service Condition Enforcement: Implement policy condition keys (such as requiring that roles can only be passed strictly to the compute service) to guarantee that roles intended for workloads cannot be attached to unauthorized services.

• Permission Boundaries: Attach IAM Permission Boundaries to developer roles and workload roles, defining a maximum ceiling of allowable permissions that cannot be exceeded regardless of what policies are attached.

Cloud network boundaries require strict segregation across ingress, egress, and internal routing:

• Overly Permissive Security Groups: Probing for security group rules permitting universal internet ingress (`0.0.0.0/0`) to remote administration ports (SSH 22, RDP 3389) or database listeners (PostgreSQL 5432, MySQL 3306, Redis 6379).

• Instance Metadata Service (IMDSv1 vs IMDSv2): On virtual machines, the metadata service serves temporary IAM role credentials. Legacy IMDSv1 is vulnerable to Server-Side Request Forgery (SSRF) attacks, allowing an attacker who exploits an SSRF flaw in a web application to steal the instance’s IAM credentials. A cloud review verifies that IMDSv2 (which requires session-oriented token headers) is enforced across all workloads.

Comprehensive telemetry is required to detect and investigate potential cloud security incidents:

• Centralized Multi-Region Logging: Verifying that AWS CloudTrail, Azure Activity Log, and GCP Cloud Audit Logs are activated across all regions, centralized into an isolated security account, and protected with file integrity monitoring.

• Service Control Policies (SCPs): In AWS Organizations or Azure Management Groups, SCPs establish non-negotiable guardrails that cannot be disabled by individual account administrators—such as prohibiting the disabling of CloudTrail, blocking the creation of internet gateways in private VPCs, or restricting resource deployments to authorized geographic regions.