A storage bucket is readable by anyone who finds its address. A workload running nearby has a service account with permissions far broader than its job requires. The bucket exposure looks like a configuration issue; the service account looks like an IAM issue. An attacker sees one connected route to data and onward access, while a cloud security dashboard may report two separate findings.
That gap is the practical problem with cloud architecture security. Identity, network reachability, configuration, and deployment pipelines form one system, so penetration testing needs to examine how an attacker can chain them, not just whether individual controls pass a checklist.
Table of Contents
- Why Cloud Architecture Security Breaks the Old Playbook
- The Core Concept of Identity-Based Cloud Architecture
- Secure Network and Identity Patterns Across AWS, Azure, and GCP
- The Three Attack Paths That Defeat Isolated Controls
- Hardening IaC and CI/CD Pipelines Before Deployment
- Resilience When the Security Controls Themselves Fail
- Mapping Cloud Controls to HIPAA, SOC 2, PCI-DSS, and ISO 27001
- Why Annual Pentests Are Obsolete for Cloud Architectures
Why Cloud Architecture Security Breaks the Old Playbook
A storage exposure becomes an architecture problem when an attacker can use it to reach other resources. An MSSP assessing a public bucket should check whether workloads can read sensitive objects, what permissions their identities hold, which services those identities can access, and whether the resulting activity is logged. A perimeter scan alone will miss those connections. The attack path may cross storage, workload credentials, APIs, partner integrations, and management services.
The figures in Verizon's 2025 Data Breach Investigations Report reinforce why isolated controls fall short. The report analyzed more than 22,000 security incidents, including 12,195 confirmed breaches. Credential abuse accounted for 22% of breaches as an initial-access method, while vulnerability exploitation reached 20%. Verizon also reported a 34% year-over-year increase in vulnerability exploitation, with perimeter devices and VPNs among the targets. The same report found that third-party involvement doubled from 15% to 30% of breaches. (Verizon's 2025 DBIR executive summary)
A vendor identity, managed service, or SaaS integration can connect an attacker to customer workloads, even when internal network segments appear well separated. Those relationships belong in the same security review as workload permissions and configuration. A CSPM finding may identify the exposed resource, but it does not necessarily show whether an attacker can chain that exposure into control-plane access or sensitive data.
Practical rule: Treat a cloud finding as a possible entry point, not a complete risk rating. Test what the affected identity, workload, or integration can reach next.
Perimeter controls still reduce exposure, but they cannot define trust on their own. Identity governance, phishing-resistant authentication, timely patching, scoped permissions, centralized logging, secrets management, and recurring assessment must work together. Test whether those controls break attack paths, including paths that start with valid credentials or a trusted partner connection. That is the difference between checking separate IAM, network, and configuration boxes and examining how the architecture behaves under attack.
The Core Concept of Identity-Based Cloud Architecture
Network location once offered a usable shorthand for trust: traffic inside a protected network received different treatment from traffic outside it. Cloud workloads, APIs, remote access, and managed services don't stay inside one dependable boundary. As NIST explains in its cloud-native zero-trust guidance, network location alone doesn't establish trust. Authorization should consider who or what is making a request, the resource being accessed, and relevant context. (NIST SP 800-207A)
Think of authorization as a hotel key system. A guest's key opens only the rooms and floors they're allowed to access, and it stops working when the stay ends. Cloud access should follow the same logic: a specific user or workload receives permission for a defined resource and task, for only as long as necessary. A broad credential that persists indefinitely is the equivalent of a master key with no expiry.
Build trust around identity and context
Start by assigning distinct workload identities rather than sharing credentials between applications. Use short-lived credentials where the provider supports them, and authenticate services to one another instead of assuming that internal traffic is safe. Mutual authentication helps establish both ends of a service-to-service connection, while encrypted communication protects traffic in transit.
Then make policy deny-by-default. Grant only the permissions required for a defined operation, resource, and time window. Evaluate access continuously using identity, device or workload posture, resource sensitivity, and unusual behavior, rather than treating a successful login as permanent authorization. Centralized policy enforcement can make these decisions more consistent, but teams still need to test the policy's actual effect across provider boundaries.
The operational challenge is keeping people, service identities, and permissions aligned as teams and systems change. For a practical perspective on structuring ownership and access reviews, see this guide to identity governance for IT teams.
A useful way to apply the model is to ask four questions during an assessment: Which identity is acting? What exactly can it do? What context permits the request? Can investigators attribute the action afterward? Testing IAM and workload roles for privilege escalation, checking whether network placement alone grants trust, and reviewing control-plane and data-plane logs can reveal weaknesses a perimeter scan misses.
Secure Network and Identity Patterns Across AWS, Azure, and GCP
The identity-first model is portable, but the controls and failure modes differ across cloud providers. A useful comparison focuses on the same operational questions in each environment: how workloads authenticate, how teams restrict network paths, and whether logs let responders reconstruct activity. Provider defaults don't remove the customer's responsibility to define permissions, protect credentials, and verify effective policy.
| Control Area | AWS | Azure | GCP |
|---|---|---|---|
| Workload identity | IAM roles provide workload permissions; review trust policies and role scope. | Managed identities can avoid embedded credentials; constrain their assigned roles and resource access. | Service accounts provide workload identities; avoid long-lived keys and narrow account permissions. |
| Network segmentation | VPCs and security groups constrain paths, but don't replace identity checks. | Virtual networks and network security groups shape traffic; subscription boundaries and role assignments also affect blast radius. | VPCs and firewall rules control network reachability; VPC Service Controls can add boundaries around supported services and data. |
| Logging | Centralize CloudTrail and service logs, then verify coverage and retention. | Collect activity and resource logs centrally, and confirm that relevant identity and workload events are attributable. | Centralize audit and workload logs, and check that project-level activity is visible to responders. |
A cloud pentest should validate behavior, not merely inspect whether a service is enabled. In AWS, test whether role trust relationships permit unintended assumption or privilege escalation. In Azure, examine role assignment scope across management groups, subscriptions, and resource groups, rather than assuming that a virtual network boundary limits administrative impact. In GCP, check service-account permissions and whether teams have left durable keys in source repositories, build systems, or deployment configuration.
A segmented network can still contain an untrusted workload with excessive permissions. Test both who can communicate and what each identity can do after it connects.
Logging needs the same cross-layer treatment. A network flow record may show that a connection occurred, but an incident responder also needs to identify the calling principal, the requested action, and the resource affected. Check whether audit events from identity systems, APIs, compute services, and data stores arrive in a location the customer can access and retain.
For executives aligning cloud design with operating priorities, this strategic guide for CIOs on cloud security offers a useful companion perspective. The architecture decision still comes down to the customer's actual trust relationships, not the provider's product labels.
The Three Attack Paths That Defeat Isolated Controls
A workload can pass configuration checks and still give an attacker a route to sensitive data. Trend Micro's 2025 cloud security report found that 95% of organizations had at least one cloud asset capable of lateral movement. Only 21% of respondents reported strong visibility across workloads, configurations, and data flows, and 64% identified unauthorized access as a leading cloud concern. (Trend Micro's 2025 cloud security report)
Treat identity, network reachability, and configuration as one system. Test whether a foothold in one workload can reach another identity, service, or control-plane action. This attacker's-eye view can expose paths that isolated control checks and CSPM dashboards miss.
Identity chaining across workloads
A seemingly minor service permission becomes a serious risk when a workload can assume another role, invoke an API, or read a secret used by a more privileged service. Trace the chain from the initial identity through reachable roles and resources. The key question is whether a permission completes a path to sensitive data or control-plane actions, not just whether it exceeds a baseline.
Metadata service abuse
A compromised workload may query its instance metadata service and obtain credentials for its execution role. Network restrictions and hardened metadata settings reduce exposure, but broad role permissions still leave a path to impact. Check whether each workload can reach metadata, which identity it receives, and what that identity can access across services and data stores.
CI/CD as a route into production
Build pipelines often have permission to publish artifacts, deploy infrastructure, or retrieve secrets. A compromised runner, dependency, or repository workflow can use those permissions to gain a production foothold. Trace code from commit through artifact and deployment; verify that each build identity has only the access its job requires.
Prioritize findings by exploitable blast radius. A modest permission flaw that exposes a privileged workload and sensitive data may need faster remediation than a severe issue with no reachable route to impact. The same report found that 70% of organizations used Kubernetes, and half of Kubernetes organizations had at least one cluster running an unsupported version. For Kubernetes assessments, examine service-account permissions, cluster access, workload-to-workload communication, and the deployment pipeline together.
Hardening IaC and CI/CD Pipelines Before Deployment
Infrastructure-as-code and deployment pipelines are one security discipline: templates declare the environment, and pipelines decide whether those declarations reach production. Cloud Security Alliance survey reporting found that 48% of organizations managed policy changes mostly or fully manually, while 65% experienced at least one business-critical application outage during the prior year caused by a misconfigured security policy. (Cloud Security Alliance survey reporting)
Manual changes can leave Terraform, ARM, or CloudFormation definitions out of sync with deployed policy. That drift creates uncertainty for operators and gaps for attackers. Use version-controlled policy-as-code, peer review, automated validation, drift detection, and staged rollout so teams can spot risky changes before they affect production.
Put security gates where changes happen
A useful pipeline checks both the infrastructure definition and the access the deployment identity can exercise. For example, block a pull request when a storage resource is publicly reachable without an approved exception, a management interface accepts unnecessary ingress, or a role grants broad access beyond its workload's function. Scan for secrets before build or deployment, and rotate credentials that appear in code or logs.
The pipeline should also fail when a required control is missing, not merely produce a warning that nobody owns. Put checks at pull-request review, artifact creation, and deployment. After release, compare the deployed state with approved templates and alert on drift. A staged rollout gives teams a chance to catch a bad policy in a limited environment before it reaches a customer-facing service.
Make the deployed policy testable: retain the template, review record, validation result, and evidence that the live environment matches the approved change.
For GitHub Actions-specific risks, teams can use this GitHub Actions security resource to examine workflow permissions, secrets handling, and the trust placed in third-party actions. The same review principle applies to other CI/CD platforms: constrain the runner identity, protect credentials, and make release decisions traceable.
For service providers, repeatable gates are more valuable than a one-time template scan. Run checks after meaningful infrastructure changes, compare intended and effective permissions, and retain remediation evidence that can be reviewed with the customer.
Resilience When the Security Controls Themselves Fail
Centralizing identity, logging, and security policy can simplify administration, but it also creates dependencies that may become shared failure domains. Ask what happens when the identity provider is unavailable, the logging platform is compromised, DNS fails, or a cloud control plane degrades. A design that blocks unauthorized access but also prevents responders from authenticating or investigating may leave the organization unable to contain an incident.
SANS reported that 93% of enterprises estimated downtime costs above $300,000 per hour and highlighted a lack of failover, multicloud redundancy, or offline fallbacks for critical security functions such as IAM and threat detection. (SANS analysis of cloud-era resilience) The architectural lesson isn't to duplicate every service across providers. Redundancy adds cost and operational complexity, and poorly tested failover can widen access or produce conflicting policy. The goal is to identify which security functions must survive a dependency failure and design a controlled recovery path.
Plan for degraded operations
Break-glass access should use audited local credentials or another recovery mechanism that doesn't rely solely on the failing identity provider. Keep emergency permissions narrow, protect credentials from routine use, and test that responders can retrieve and revoke them. Pre-authorized emergency policies can help teams contain an incident, but they should be documented, logged, and removed or reconciled after use.
Evidence collection needs an independent fallback. If the primary logging platform fails or is compromised, immutable records and a separate retention path can preserve evidence for investigation. Likewise, test how security telemetry can be restored after an outage, not just whether logs are normally delivered.
For a multi-tenant provider, map dependencies by customer and identify whether a single gateway, identity service, DNS provider, or control plane could affect many environments at once. A penetration test can simulate the loss of a control service and assess whether customers can still authenticate, investigate, contain, and recover. That turns resilience testing into a security exercise, not just a disaster-recovery rehearsal.
Mapping Cloud Controls to HIPAA, SOC 2, PCI-DSS, and ISO 27001
Compliance evidence is most useful when it reflects how the architecture works, not merely what a policy document says. A finding about an overprivileged workload role can map to access control, change management, and monitoring expectations at once. A public storage path may implicate data protection and configuration management. Evidence-backed penetration testing shows whether those controls interrupt a plausible attack path.
IBM's 2025 Cost of a Data Breach research reported that breaches involving data distributed across multiple environments cost an average of $5.05 million, compared with $4.01 million for breaches involving on-premises data. (IBM's 2025 Cost of a Data Breach research) The difference underscores why multi-environment architectures need consistent identity governance, configuration validation, encryption, and logging. Each additional environment creates more permissions, interfaces, and dependencies to assess.
Map evidence to control intent
For HIPAA, SOC 2, PCI-DSS, ISO 27001, CMMC, GLBA, and GDPR, the practical work is to connect a verified test result to the relevant control objective and preserve evidence of both the weakness and its remediation. A report should identify the affected resource, the path tested, what the tester could demonstrate, and whether the fix was retested. A compliance matrix can help teams organize those mappings; this guide to building a compliance matrix provides a starting point for structuring evidence by framework and control.
Recurring assessment is more useful than an annual snapshot when cloud roles, APIs, and deployments change between audit cycles. It also gives MSSPs a consistent way to show customers which controls were tested, what evidence supports the conclusion, and where remediation remains open. For organizations reviewing hosting options against payment-security needs, this resource on PCI compliance hosting for Australian SMBs offers additional context.
A control mapping shouldn't claim that a penetration test certifies an organization. It should show what was assessed, under what authorization, and how the observed evidence relates to the customer's obligations. That distinction makes reports more credible for auditors and more useful for engineering teams.
Why Annual Pentests Are Obsolete for Cloud Architectures
An annual cloud pentest is a snapshot of permissions, workloads, and exposed services that may change soon after testing. It still has value as a point-in-time assessment, but it can't stand in for recurring validation when teams deploy infrastructure and alter access continuously. The better model combines scheduled testing with targeted retests after material changes, backed by evidence that confirms whether an attack path is exploitable and whether remediation closes it.
Authorization needs the same discipline as technical scope. AWS allows testing without prior approval against a defined set of services, including EC2, WAF, NAT Gateways, Elastic Load Balancers, RDS, CloudFront, Aurora, API Gateway, AppSync, Lambda, Lambda@Edge, Lightsail, Elastic Beanstalk, ECS, Fargate, OpenSearch Service, FSx, Transit Gateway, and Global Accelerator. A test involving command-and-control infrastructure requires prior approval, and permission for one workload shouldn't be treated as permission to test every service in an account. (AWS penetration testing policy)
Azure doesn't require pre-approval for testing Azure resources, but a third-party tester still needs explicit written authorization from the resource owner. The service agreement should identify the tenant, subscriptions, resource groups, applications, APIs, and test windows, and testing must follow Microsoft's Cloud Unified Penetration Testing Rules of Engagement. (Microsoft Azure penetration testing guidance)
For MSSPs, recurring, evidence-backed assessments turn testing into an operational service: confirm the permitted scope, test identity chains and control failures, verify fixes, and map results to customer controls. This guide to continuous penetration testing offers further context on moving beyond isolated assessments.
ThreatExploit AI supports automated penetration testing across AWS, Azure, and GCP, with evidence-backed reporting and compliance mapping for security service providers. If you're building recurring cloud assessments around attack paths, authorization, and verified remediation, explore ThreatExploit AI.