# Cloud Security Across AWS, Azure, and GCP

> **Intro:** Multi-cloud security is not three unrelated checklists. The control surfaces repeat: identity, network, logging, encryption, service exposure, and guardrails. What changes is the naming, the defaults, and the places where teams most often get misled.
>
> **What this page includes**
>
> * a cross-cloud threat and hardening model
> * common attacker paths
> * top cloud misconfiguration themes
> * vendor-native security capabilities

## The common attacker pattern

Across AWS, Azure, and GCP, cloud compromises usually follow a familiar sequence:

1. **Obtain a foothold**\
   leaked credential, token, access key, service account secret, CI variable, or exposed workload.
2. **Enumerate aggressively**\
   list projects, subscriptions, accounts, IAM bindings, roles, buckets, secrets, functions, and network objects.
3. **Escalate privilege**\
   abuse overbroad IAM, managed identities, workload identities, assumable roles, or token issuance.
4. **Expand access**\
   move to higher-value subscriptions, accounts, projects, or CI/CD systems.
5. **Access data or alter workload behavior**\
   exfiltrate storage, tamper with builds, deploy persistence, or weaken logging.
6. **Reduce visibility**\
   disable findings, tamper with logs, or hide inside normal automation.

## The control planes that matter most

| Control plane | AWS                                            | Azure                                            | GCP                                                                  |
| ------------- | ---------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------- |
| Identity      | IAM, IAM Identity Center, STS, Access Analyzer | Entra ID, Azure RBAC, Managed Identities, PIM    | Cloud IAM, Workforce / Workload Identity Federation, Org Policy      |
| Posture       | Security Hub, GuardDuty, Config, Inspector     | Defender for Cloud, Azure Policy                 | Security Command Center, Event Threat Detection, Organization Policy |
| Logging       | CloudTrail, CloudWatch, VPC Flow Logs          | Activity Log, Azure Monitor, NSG Flow Logs       | Cloud Audit Logs, Cloud Logging, VPC Flow Logs                       |
| Network       | VPC, SGs, NACLs, Network Firewall, PrivateLink | VNets, NSGs, UDRs, Private Link                  | VPC, firewall rules, Cloud Armor, VPC Service Controls               |
| Data          | KMS, S3 controls, Macie                        | Key Vault, Storage controls, encryption settings | Cloud KMS, Secret Manager, CMEK, DLP                                 |

## Top 15 multi-cloud misconfiguration themes

1. No enforced MFA for privileged identities
2. Long-lived credentials instead of federation or short-lived credentials
3. Overbroad admin roles at subscription, project, or account scope
4. Public storage exposure
5. Inadequate service-to-service identity boundaries
6. Missing or weak logging retention
7. Broad inbound network rules
8. Open egress with no meaningful data perimeter strategy
9. Weak secret handling in CI/CD and automation
10. No approval or review path for IAM changes
11. Security tooling enabled only in part of the estate
12. Production and non-production identity boundaries mixed together
13. No ownership tagging or poor resource inventory
14. Disabled or ignored findings from native cloud security products
15. Build systems able to deploy broadly without clear environment guardrails

## How hackers typically think

Attackers do not care whether a control lives in a UI, Terraform, or an API. They care about:

* what identity they can get
* what they can list
* what they can assume or impersonate
* where sensitive data lives
* whether anyone will notice

That is why **identity**, **visibility**, and **guardrails** matter more than point-in-time “hardening scans.”

## A cloud hardening plan that works

### Phase 1 — Inventory and ownership

* organization, account, subscription, and project map
* clear owners
* service criticality
* default logging and security readers for the security team

### Phase 2 — Identity foundation

* federated login
* minimize standing privilege
* administrative separation
* policy guardrails for high-risk actions

### Phase 3 — Visibility

* central findings aggregation
* centralized audit logs
* baseline detections for suspicious identity, storage, and network changes

### Phase 4 — Network and data exposure

* restrict public exposure
* use private access paths where possible
* reduce egress
* classify sensitive storage and data flows

### Phase 5 — Delivery and drift control

* infrastructure as code
* policy checks in CI
* exception governance
* release evidence for sensitive environments

## Common attacker tool categories

Do not treat this as a shopping list. Treat it as a reminder of what defenders should expect to see in investigations and simulations.

* **Cloud CLIs and SDKs** used with stolen credentials
* **Terraform and policy tooling** used to understand infrastructure structure
* **Kubernetes and container utilities** used once workload access is obtained
* **Recon automation** that inventories IAM, storage, networking, and public endpoints
* **Secret extraction and repo mining tools** used against CI/CD and developer workflows

The practical lesson is simple: if an attacker can authenticate, they can often use the same normal admin tooling your teams use every day.

## Vendor-native security features to know

### AWS

* Security Hub
* GuardDuty
* Inspector
* IAM Access Analyzer
* Config
* Macie
* Organizations and SCPs

### Azure

* Microsoft Defender for Cloud
* Azure Policy
* Entra ID and PIM
* Key Vault
* NSGs and Private Link
* Management Groups

### GCP

* Security Command Center
* Cloud IAM
* Organization Policy
* Cloud Audit Logs
* VPC Service Controls
* Secret Manager and Cloud KMS

## Cross-links

* [AWS IAM and Role Design](/cloud-kubernetes-and-infrastructure-security/index/aws-iam-and-role-design.md)
* [AWS Security Baseline and Top Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index/aws-security-baseline-and-top-misconfigurations.md)
* [Azure Security Baseline and Top Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index/azure-security-baseline-and-top-misconfigurations.md)
* [GCP Security Baseline and Top Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index/gcp-security-baseline-and-top-misconfigurations.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index/cloud-security-across-aws-azure-and-gcp.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.