PS Product SecurityKnowledge Base

☁️ 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