Few cloud environments are insecure on day one. They become insecure gradually: a temporary firewall rule that was never removed, an access key created for a test and forgotten, a storage bucket made public to share one file. Each change made sense at the time. Together they create the gaps attackers look for.
A cloud security posture review finds that drift and ranks it by risk, so teams fix what matters first instead of working through a list of thousands of alerts. These are the seven areas we review on AWS and Azure, and why each one matters.
1. Identity and access
In the cloud, identity is the perimeter. Most serious incidents start with a compromised credential or an over-permissioned identity, so this is where reviews begin.
- Multi-factor authentication on every human account, and especially on root or Global Administrator accounts.
- No long-lived access keys where short-lived credentials or workload identities can be used instead.
- Least-privilege roles, checked against what identities actually use. AWS IAM Access Analyzer and Microsoft Entra ID tooling help find unused permissions.
- Just-in-time elevation for administrative access rather than standing privilege.
2. Network exposure
We map everything reachable from the internet and ask whether it needs to be. The most common findings are administrative ports such as SSH or RDP open to any address, databases with public endpoints, and services exposed directly instead of through a load balancer or gateway with proper controls.
Private endpoints for managed services, and a deliberate path for administrative access, remove whole categories of risk.
3. Data protection
- Storage that is publicly accessible, intentionally or not.
- Encryption at rest and in transit, and who controls the keys.
- Backups that exist, are protected from deletion, and have actually been restored in a test.
- Sensitive data stored in places it was never meant to be, such as logs or test environments.
4. Logging and detection
If something goes wrong, can you tell what happened? We check that audit logging, such as an AWS CloudTrail organization trail or the Azure Activity Log, is enabled across every account or subscription, stored where it cannot be altered by the people it records, and retained long enough for investigations and audits.
Logs only help if someone looks at them. We also check that high-risk events, such as changes to logging itself or new administrator grants, raise alerts that reach a person.
5. Kubernetes and containers
- Role-based access control scoped to what each team and service needs.
- Admission policies that block privileged containers and unapproved images.
- Image scanning in the pipeline, not only after deployment.
- Secrets delivered from a dedicated secrets manager rather than stored in manifests.
6. Pipelines and secrets
Your delivery pipeline can change production, which makes it one of the most valuable targets in the environment. We look for secrets committed to repositories, static cloud credentials stored in CI systems where federated, short-lived credentials could be used instead, and missing branch protection or review requirements on infrastructure code.
7. Baselines and benchmarks
We compare configuration against recognized baselines, such as the CIS Benchmarks for AWS, Azure, and Kubernetes, using native tools like AWS Security Hub and Microsoft Defender for Cloud where they are available. Benchmarks are a floor, not a goal. Their value is consistency: the same checks, run continuously, so drift is caught when it happens rather than at the next annual review.
How findings are ranked
A raw scan of a mid-sized environment can return thousands of findings. Treating them all as equal guarantees that the important ones wait. We rank each finding by how exploitable it is, whether it is reachable from the internet, what an attacker could reach from it, and how much effort the fix takes.
The result is a short list of urgent fixes, a set of quick wins that reduce risk cheaply, and a longer-term plan for structural improvements, such as moving to workload identities or redesigning network boundaries.
What you should have at the end
- A clear picture of what is exposed to the internet, and why.
- Identity findings tied to real usage, not just policy text.
- Confirmation that logging and backups work, with evidence.
- A remediation plan ordered by risk and effort, with owners.
- Guardrails that stop the same issues from returning.
Our Cloud Security Posture Review covers these areas through configuration review and interviews with your team, and ends with findings and a remediation plan ranked by risk and effort.
Filed under Cybersecurity