What is a cloud security posture review?
A cloud security posture review is an assessment of how a cloud environment is configured, measured against what it runs and who can reach it. In an Azure estate it reads the Entra ID tenant, the management group and subscription hierarchy, role assignments, network exposure, secrets handling, logging and the configuration of the resources that hold data. It is usually done with read-only access and produces a ranked remediation plan.
Cloud security posture management, CSPM, is the tooling version of the same idea. Defender for Cloud's foundational CSPM is free on every subscription and scores resources against the Microsoft cloud security benchmark. Defender CSPM, the paid plan, adds attack path analysis, a cloud security explorer and agentless scanning. Both are useful inputs to a review. Neither replaces the judgement about which findings matter.
Why is secure score a weak measure on its own?
Secure score counts recommendations and weights them by Microsoft's view of severity across every customer. It cannot know that one storage account holds identity documents and another holds marketing images, so both carry the same weight for the same setting. It treats an exposure the business needs as a gap, and it rewards closing many small recommendations as much as closing one that matters.
Secure score also measures only what Defender can see. A subscription outside the management group Defender covers, a resource in another tenant, a GitHub Actions workflow that deploys with a long-lived secret, or a database reachable from a partner's network all sit outside the number. An estate can show 80 per cent and still have a direct path from the internet to customer data.
- Severity is generic: the score cannot rank a finding by the data or workload behind it.
- Scope is partial: subscriptions, tenants and pipelines outside Defender's coverage do not count.
- Intent is invisible: a deliberate, controlled exposure scores the same as an accident.
- Chains are missed: two medium findings that combine into a path to production read as two medium findings.
- Operation is unmeasured: an alert nobody reads scores the same as one a person acts on.
Which privilege paths does a review trace?
Identity is the control plane in Azure, so the review starts there. It lists every Owner, Contributor and User Access Administrator assignment at management group and subscription scope, and every service principal and managed identity holding them. It traces who can grant themselves more: an account with User Access Administrator, an application with the Microsoft Graph permission to assign app roles, or an automation account running as a privileged identity.
Entra ID and Azure RBAC meet at a well-known seam. A Global Administrator can elevate to User Access Administrator at the root management group with one switch, so every Global Administrator is effectively an owner of every subscription. A review that reads Azure roles without reading Entra roles misses that path.
What exposure does a review look for?
The review lists everything reachable from the internet and asks why. Storage accounts with public network access, databases with a firewall rule allowing all Azure services, App Service and Container Apps endpoints without an identity provider or a web application firewall in front, management ports open on virtual machines, and Key Vaults reachable from any network. Each one is recorded as deliberate and controlled, or as a change to make.
Where a workload needs a private path, the fix is usually a private endpoint with public network access disabled. Where a workload has to be public, the fix is authentication, a web application firewall and logging on the endpoint. The review records the decision against each resource so the next review can tell drift from design.
How are secrets and pipelines checked?
Secrets drift. The review searches app settings, deployment pipeline variables, infrastructure code and repositories for credentials, lists service principals with client secrets and their expiry dates, and checks whether Key Vault access is granted through Azure RBAC with narrow scopes. Deployments that authenticate with workload identity federation hold no long-lived secret at all, and the review checks which pipelines have moved and which still hold a client secret with Contributor rights over production.
The pipeline is part of the posture. Whoever can edit a workflow file that deploys to production with Owner rights can run any code in the subscription. Branch protection, required reviews and environment approvals on those workflows are checked alongside the Azure roles they use.
Would anyone see an attack in the logs?
Logging is checked for three things. Coverage: diagnostic settings that send the activity log, Entra sign-in and audit logs, Key Vault access, and resource logs for data stores to a Log Analytics workspace. Retention: long enough to investigate an incident found weeks after it began, since the Azure activity log alone holds 90 days and Entra sign-in logs 30 days on P1 or P2. Use: an alert rule or a Microsoft Sentinel analytic that fires on the events that matter, routed to a person.
The practical test is a question. If a service principal created a new client secret at 2am last Tuesday, who would know, and how soon? Where the answer is nobody, the review sets out the alert and the route.
How should Defender for Cloud fit into the review?
Defender for Cloud is worth reading in full before any manual work. The recommendations list, the regulatory compliance dashboard mapped to the Microsoft cloud security benchmark, and, where Defender CSPM is enabled, the attack path analysis give a fast picture of where configuration has drifted. The review takes that output, removes what does not apply, confirms the rest by reading the resources, and adds the findings that sit outside Defender's view.
Coverage is checked first. Defender plans are enabled per subscription, so a subscription added after the original rollout often has nothing enabled. The review lists every subscription under the tenant's management groups, every plan enabled on each, and any subscription outside the hierarchy that the organisation still pays for.
How often should cloud posture be reviewed?
Cloud environments change daily, so posture drifts between reviews. A full manual review once a year, or after a major change such as a migration, a new product launch or a change of provider, sets the baseline. Between reviews, Azure Policy assignments in deny or audit mode hold the decisions the review made: no public network access on storage, diagnostic settings required, allowed regions, required tags for data classification.
A monthly check of new role assignments, new public endpoints and expiring credentials catches most drift early. That check can be automated, and its output read by a person who can decide whether a change was intended.
What does the review deliver?
A findings report with each issue verified and reproducible, and a remediation plan ordered by attack path: the changes that cut the shortest routes to sensitive data come first, whatever their secure score weighting. Most plans open with standing privileged roles, internet-exposed data stores, long-lived pipeline secrets and missing sign-in log export.
Black Shard runs production workloads on Azure in Australian regions, including Aurii, the clinical platform it built and operates in Australia East on Container Apps, with Key Vault for secrets and workload identity federation for deployment. The Azure security review applies the same configuration decisions to client estates, using read-only access, and starts at $3,500 ex GST for a fixed scope covering Microsoft 365 and Azure. Where a finding needs proof that it can be exploited, a penetration test confirms it. Scope is set on a free 30-minute scoping call.