PS Product SecurityKnowledge Base

🛰️ Cloud Audit Cookbook by Provider

Intro: A lot of older cloud-security guidance talked about “security assessment” as if the only serious option was a consultant, a scanner, or a penetration test. In practice, a huge amount of value comes from disciplined audit of configuration state, identity design, logging coverage, and provider APIs.

What this page is for

Use this page when you need a practical audit path for cloud environments that asks:

  • what is deployed;
  • who can do what;
  • what is exposed;
  • which logs exist;
  • which controls are missing;
  • how to turn findings into code or policy.

A practical audit loop

  1. Inventory accounts, subscriptions, or projects.
  2. Query configuration state and identity posture.
  3. Compare with baseline and threat model.
  4. Triage findings into: exploitable now, weak design, hygiene debt, evidence gap.
  5. Fix the issue.
  6. Codify the fix in Terraform, policy, SCP, Azure Policy, org policy, admission, or CI checks.

Legacy versus current tool selection

Older or historical reference Why it mattered Practical 2026 use
Scout2 early cloud posture review keep as historical reference only; prefer maintained cloud audit tooling and provider-native evidence
one-off spreadsheet review human-readable still useful for decisions, but not as the audit source of truth
CSP console-only review simple to start good for spot checks; weak as a repeatable audit process
“just run a pentest” visible output use only as one input; it does not replace control-state review

Minimal open-source path

  • provider CLI and APIs;
  • Prowler or equivalent posture checks;
  • Terraform static review;
  • targeted identity and network queries;
  • durable export of findings.

Broader enterprise path

  • provider-native policy and config history;
  • posture tooling or CNAPP / CSPM;
  • IaC scanning in PRs;
  • detection coverage checks;
  • exception tracking and codified remediation.

AWS quick audit cookbook

Identity and access

aws iam generate-credential-report
aws iam get-account-summary
aws iam list-account-aliases
aws iam list-roles
aws iam list-policies --scope Local

Look for:

  • dormant or over-privileged IAM users;
  • broad inline policies;
  • old access keys;
  • missing federation or role assumption patterns.

CloudTrail and logging

aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name org-trail
aws logs describe-log-groups

Look for:

  • trails missing in important regions;
  • logs not centralized;
  • missing data events for sensitive services where required;
  • no retention policy or weak retention.

Network exposure

aws ec2 describe-security-groups
aws ec2 describe-instances
aws ec2 describe-network-acls
aws elbv2 describe-load-balancers

Look for:

  • 0.0.0.0/0 or ::/0 on administrative ports;
  • public instances that should sit behind load balancers;
  • inconsistent ingress intent across SGs and NACLs;
  • forgotten internet-facing assets.

Storage exposure

aws s3api list-buckets
aws s3api get-public-access-block --bucket my-bucket
aws s3api get-bucket-policy-status --bucket my-bucket

Look for:

  • public or cross-account buckets without strong reason;
  • no encryption policy;
  • no access logging where it matters;
  • weak lifecycle or retention around sensitive data.

Prowler example

prowler aws -M json-asff -o ./prowler-output

Use the tool for breadth, then validate the highest-value findings directly with provider APIs.

Azure quick audit cookbook

Identity and tenant basics

az account show
az account management-group list
az role assignment list --all
az ad signed-in-user show

Policy and security baseline

az policy assignment list
az policy state list --top 20
az monitor activity-log list --max-events 20

Network and public exposure

az network nsg list
az network public-ip list
az network application-gateway list

Look for:

  • public IPs attached to things that should not be public;
  • NSGs that allow broad admin access;
  • drift between intended policy and effective state.

GCP quick audit cookbook

Projects and IAM

gcloud projects list
gcloud projects get-iam-policy PROJECT_ID
gcloud iam service-accounts list --project PROJECT_ID

Logging and audit coverage

gcloud logging sinks list --project PROJECT_ID
gcloud logging read 'resource.type="gce_instance"' --limit=20 --project PROJECT_ID

Network posture

gcloud compute firewall-rules list --project PROJECT_ID
gcloud compute addresses list --project PROJECT_ID
gcloud compute instances list --project PROJECT_ID

Look for:

  • broad ingress rules;
  • unnecessary public IPs;
  • service accounts with excessive scope;
  • missing central export of logs.

Turning findings into code

Bad outcome

  • scanner runs once;
  • security writes a document;
  • engineering fixes half the issues;
  • the same classes of issue return next quarter.

Better outcome

  • finding becomes a Terraform module fix, policy, or CI control;
  • future violations fail earlier;
  • exceptions are explicit and time-bound.

Practical snippet — convert audit into Terraform policy backlog

Finding: security group allows SSH from 0.0.0.0/0
Owner: platform networking
Immediate fix: restrict to bastion / VPN CIDR
Codified fix: reusable SG module denies public SSH by default
Preventive gate: tfsec / Checkov / OPA policy in CI
Exception path: approved short-lived break-glass rule only

Practical checklist

  • Can we enumerate accounts, projects, and environments from code and provider APIs?
  • Can we explain who has admin-equivalent access?
  • Can we identify all public entry points quickly?
  • Can we prove logging is enabled and retained where needed?
  • Are the highest-frequency findings being fixed in code, not only in consoles?

---Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.