Post cover image

November 2, 2026

Cloud Infrastructure Security in AWS, GCP and Azure: What to Automate and What to Check by Hand

A practical guide to securing the three major clouds: the risks they share, the services that differ, the open-source tools that scan them…

By Vigneshkumaroffsec

9 min read

A practical guide to securing the three major clouds: the risks they share, the services that differ, the open-source tools that scan them, and the manual review no tool can replace.

By Vignesh Kumar | Security Researcher

In May 2023, Toyota disclosed that a misconfigured cloud environment had exposed vehicle location data of about 2.15 million customers in Japan. The setting had been wrong since 2013, so the data had been open for almost ten years.

A year later, in 2024, attackers used stolen passwords to log in to the Snowflake accounts of around 165 organizations. The accounts did not have multi-factor authentication. The credentials had been collected earlier by infostealer malware on employees' and contractors' computers.

Neither incident required breaking the cloud provider. One was a setting nobody checked. The other was a login nobody protected.

That is what most cloud breaches look like. The cloud provider secures the hardware and the platform. Everything you configure is your job.

This article explains what to secure in AWS, GCP and Azure, which tools automate the checks, and which parts still need a person to look closely.

The Shared Responsibility Model

Every cloud provider uses the same idea, called the shared responsibility model.

The provider secures the cloud itself: data centers, hardware, the hypervisor, and the managed services' underlying platform.

You secure what you put in the cloud:

  • Who can log in, and what they can do.
  • Which resources are exposed to the internet.
  • How your data is stored, encrypted and shared.
  • What is logged, and whether anyone reads it.
  • The operating systems and applications you run on virtual machines.

The more managed a service is, the less you own. A serverless function needs less patching than a virtual machine, but its permissions are still yours.

The Same Problems in Every Cloud

The service names differ, but the risks are almost identical across AWS, GCP and Azure:

  • Identity: admin accounts without MFA, overly broad roles, and long-lived keys.
  • Network: databases, SSH, RDP or admin panels open to the internet.
  • Data: public storage buckets, unencrypted disks, and snapshots shared too widely.
  • Logging: audit logs turned off, kept too briefly, or never reviewed.
  • Compute: unpatched virtual machines and weak instance metadata settings.
  • Secrets: keys stored in code, environment variables, or startup scripts.

A useful habit is to learn the same control in all three clouds. Here is how the main ones map.

Identity

  • AWS: IAM users, roles and policies, plus IAM Identity Center for single sign-on.
  • GCP: Cloud IAM, with roles bound to users, groups and service accounts at the organization, folder or project level.
  • Azure: Microsoft Entra ID for identities, and Azure RBAC for access to resources.

Network

  • AWS: VPCs, security groups, network ACLs.
  • GCP: VPC networks and firewall rules, which apply across the whole network.
  • Azure: virtual networks and network security groups (NSGs).

Audit logs

  • AWS: CloudTrail.
  • GCP: Cloud Audit Logs.
  • Azure: the Activity Log, plus Entra ID sign-in and audit logs.

Built-in security services

  • AWS: Security Hub, GuardDuty, IAM Access Analyzer, and AWS Config.
  • GCP: Security Command Center, and Policy Intelligence for IAM recommendations.
  • Azure: Microsoft Defender for Cloud, and Azure Policy.

Organization-wide guardrails

  • AWS: Service Control Policies in AWS Organizations.
  • GCP: Organization Policy constraints.
  • Azure: Azure Policy assigned at the management group level.

Guardrails matter because they apply even when someone has admin rights in an account. They are your last line of defense against a mistake.

Part 1: Automated Assessment

Automated tools check hundreds of settings in minutes. Run them first, so your manual time goes to what they can't judge.

Prowler

Prowler is an open-source tool that checks AWS, Azure, GCP and Kubernetes against frameworks like the CIS Benchmarks, as well as standards such as ISO 27001 and PCI DSS.

pip install prowler
prowler aws --severity critical high
prowler gcp --project-ids my-project-id
prowler azure --az-cli-auth

It produces HTML, CSV and JSON reports, and can send findings to AWS Security Hub.

ScoutSuite

ScoutSuite from NCC Group collects your configuration and builds an offline HTML report, grouped by service:

scout aws
scout gcp --user-account
scout azure --cli

The report is useful for exploring a new environment, because it shows the configuration around each finding, not just the finding itself.

Steampipe

Steampipe lets you query cloud APIs with SQL. That makes it ideal for questions no scanner asks:

select name, region
from aws_s3_bucket
where bucket_policy_is_public;

There are plugins for AWS, GCP and Azure, so you can write the same kind of query for each cloud. Powerpipe, from the same team, adds ready-made compliance benchmarks on top.

Attack path tools

Configuration scanners check settings one at a time. Attack path tools look at how they connect:

  • PMapper models AWS IAM as a graph and shows which users and roles can escalate to admin.
  • Cartography, from Lyft, maps cloud assets and their relationships into a graph database.
  • CloudFox, from Bishop Fox, helps authorized testers find exploitable paths in AWS and Azure environments.

A single role with iam:PassRole and lambda:CreateFunction can be a path to admin. Configuration scanners often miss that. Graph tools find it.

Turn on the built-in services

The native services are worth enabling in every account or project:

  • AWS: GuardDuty for threat detection, Security Hub for findings, and IAM Access Analyzer for resources shared outside your organization.
  • GCP: Security Command Center for misconfigurations and threats.
  • Azure: Defender for Cloud for posture management and workload protection.

They don't replace an assessment, but they keep watching between assessments.

Automatic remediation with Cloud Custodian

Cloud Custodian turns security rules into YAML policies that can find and fix problems automatically. This policy removes any security group rule that opens SSH to the internet:

policies:
  - name: sg-remove-public-ssh
    resource: aws.security-group
    filters:
      - type: ingress
        Ports: [22]
        Cidr:
          value: "0.0.0.0/0"
    actions:
      - type: remove-permissions
        ingress: matched

Custodian supports AWS, GCP and Azure. Start with policies that only report, and switch to automatic fixes once you trust them.

Run it continuously

A single scan is a snapshot. Clouds change daily.

Schedule Prowler or ScoutSuite to run weekly, store the results, and compare them. A new public bucket or a new admin user should show up within days, not at the next annual audit.

Part 2: Manual Review

Tools tell you what is misconfigured. People decide what is dangerous.

Here is what to check by hand, in order of impact.

1. Identity: start here, always

Identity is the new perimeter. Most cloud incidents start with a stolen credential or an over-privileged role.

Check who has the highest level of access:

# AWS: users, their MFA status and key age
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d
# GCP: who has Owner on a project
gcloud projects get-iam-policy my-project-id --flatten="bindings[].members" --filter="bindings.role:roles/owner" --format="table(bindings.members)"
# Azure: who has Owner
az role assignment list --all --query "[?roleDefinitionName=='Owner'].{who:principalName, scope:scope}" -o table

Look for:

  • The AWS root user without MFA, or with access keys.
  • Admin accounts without MFA in any cloud.
  • Access keys older than 90 days, or keys that have never been used.
  • GCP service account keys. Most workloads can use attached service accounts or workload identity instead.
  • Human users with direct permissions instead of group or SSO roles.
  • Cross-account trust that is wider than needed, such as an AWS role that trusts an entire external account.
  • CI/CD pipelines using stored keys instead of OIDC federation.

Ask one question for every powerful identity: if this credential leaked today, what could someone do with it?

2. Network exposure

List everything open to the internet:

# AWS: security groups with any rule open to the world
aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0 --query "SecurityGroups[].{id:GroupId,name:GroupName}" -o table
# GCP: firewall rules open to the world
gcloud compute firewall-rules list --filter="sourceRanges:0.0.0.0/0 AND direction:INGRESS"
# Azure: NSG rules allowing any source
az network nsg list --query "[].securityRules[?sourceAddressPrefix=='*' && access=='Allow'].{nsg:id, port:destinationPortRange}" -o table

Look for:

  • SSH (22), RDP (3389), and database ports open to 0.0.0.0/0.
  • Admin panels, Kubernetes API servers, and monitoring dashboards reachable from the internet.
  • Load balancers and public IPs that nobody can explain.
  • Storage and database services that could use private endpoints but don't.

Use a bastion-free option where you can: AWS Systems Manager Session Manager, GCP Identity-Aware Proxy, or Azure Bastion.

3. Data and storage

# GCP: find any resource shared with allUsers or allAuthenticatedUsers
gcloud asset search-all-iam-policies --scope=organizations/ORG_ID --query="policy:(allUsers OR allAuthenticatedUsers)"
# Azure: storage accounts that allow public blob access
az storage account list --query "[?allowBlobPublicAccess].name" -o table

Look for:

  • Public buckets, blobs, or objects, especially ones that aren't meant to host a website.
  • Snapshots, disk images, and database backups shared publicly or with unknown accounts.
  • Databases without encryption at rest or without TLS enforced.
  • Encryption keys with overly broad access, or without rotation.
  • Sensitive data in the wrong place, such as customer exports in a temporary bucket.

Turn on account-level blocks so mistakes can't happen: S3 Block Public Access at the account level, GCP public access prevention through an organization policy, and disabled anonymous blob access in Azure.

4. Logging and detection

Look for:

  • AWS CloudTrail enabled in all regions, with log file validation, stored in a separate account.
  • GCP Data Access audit logs turned on for sensitive services. They are off by default for most services.
  • Azure Activity Logs and Entra ID sign-in logs exported to a Log Analytics workspace or SIEM.
  • Log retention long enough for an investigation. Many breaches are discovered months later.
  • Alerts for high-risk events: root logins, new admin users, disabled logging, and changes to guardrails.

Logs that nobody reads are only useful after the damage is done. Make sure at least the critical alerts reach a person.

5. Compute and workloads

Look for:

  • AWS instances that still allow IMDSv1. IMDSv2 protects the metadata service against SSRF attacks.
  • Virtual machines running old operating systems or missing patches.
  • Secrets in user data, startup scripts, or environment variables.
  • Functions and containers running with broad roles.
  • Default service accounts in GCP with the Editor role attached to workloads.
# AWS: instances where IMDSv2 is not required
aws ec2 describe-instances --query "Reservations[].Instances[?MetadataOptions.HttpTokens=='optional'].InstanceId" -o text

6. Guardrails and organization structure

Look for:

  • Production separated from development at the account, project or subscription level.
  • Organization-wide policies that block the most dangerous actions, such as disabling CloudTrail or creating service account keys.
  • Restricted regions, if your company only operates in a few.
  • A break-glass admin account with strong protection and alerting.

These controls are hard to see with a scanner, because they only matter when something else has already gone wrong.

Automated vs Manual: Who Does What

Let the tools handle:

  • Hundreds of configuration checks across every account and region.
  • CIS and compliance mapping.
  • Continuous monitoring and drift detection.
  • Automatic fixes for clear-cut problems.

Keep people on:

  • Deciding whether a finding matters in context.
  • IAM relationships, trust policies, and escalation paths.
  • Whether an exposure is intended or accidental.
  • Architecture: segmentation, data flows, and blast radius.
  • Business risk: which systems hold data that would hurt most to lose.

A good assessment uses both. Tools give coverage. People give judgment.

An End-to-End Cloud Security Workflow

1. Prevent

  • Use infrastructure as code, scanned with Checkov or Trivy before deployment.
  • Enforce organization guardrails: SCPs, Organization Policies, Azure Policy.

2. Detect

  • Enable GuardDuty, Security Command Center, or Defender for Cloud.
  • Centralize audit logs in a separate, locked-down account or project.

3. Assess

  • Run Prowler or ScoutSuite on a schedule.
  • Review identity, network and data by hand every quarter.

4. Respond

  • Route critical findings to a person, not just a dashboard.
  • Automate clear fixes with Cloud Custodian.
  • Practice: know how to disable a leaked key or isolate a compromised instance before you need to.

Common Mistakes to Avoid

  • Assuming the cloud provider handles security for you.
  • Giving developers permanent admin access in production.
  • Using long-lived access keys in CI/CD pipelines.
  • Running a scanner once and treating the report as the job done.
  • Ignoring findings marked "low" that combine into a real attack path.
  • Turning on audit logs but never alerting on them.
  • Mixing production and development in the same account or project.
  • Leaving default service accounts with broad roles.

A Quick Multi-Cloud Security Checklist

  • MFA on every human account, phishing-resistant for admins.
  • No root or owner accounts used day to day.
  • No long-lived keys where federation or managed identities work.
  • Least-privilege roles, reviewed with Access Analyzer, Policy Intelligence, or Entra ID access reviews.
  • No SSH, RDP or databases open to the internet.
  • Public storage blocked at the account or organization level.
  • Encryption at rest and in transit, with managed keys for sensitive data.
  • Audit logs enabled, centralized, retained, and alerting.
  • Built-in threat detection enabled in every account.
  • Prowler or ScoutSuite scheduled, with results compared over time.
  • Organization guardrails in place.
  • An incident response plan for leaked credentials.

Final Thoughts

Cloud security can look overwhelming: three providers, hundreds of services, thousands of settings.

But the important questions are the same everywhere. Who can get in? What is exposed? Where is the data? Would we notice if something changed?

Automate the checks that have clear answers, so your attention goes to the questions that need judgment. Most breaches happen not because a team lacked tools, but because a dangerous setting was never looked at by a person who understood it.

If you only do one thing this week, run Prowler against your most important account and fix every critical identity finding. That is usually where an attacker would start.

About me

I'm Vignesh Kumar, a security researcher working across application security, DevSecOps, cloud security, and vulnerability research.

I share practical findings from security assessments and responsible disclosures to help improve the security of real-world systems.

The examples in this article are intended for securing systems you own or administer.