Azure Security: The Cloud Misconfigurations Attackers Look For First

In the cloud, most breaches are not caused by sophisticated zero-day exploits. They are caused by misconfiguration: a storage account left public, a management port open to the internet, an identity with far more permissions than it needs. Under the shared responsibility model, Microsoft secures the Azure platform; configuring your resources securely is your job.

I manage security for an Azure-hosted, regulated environment. These are the misconfigurations I check first.

1. Publicly accessible storage

Storage accounts and blob containers with anonymous access can expose backups, exports and personal data to anyone with the URL. Disable anonymous blob access at the storage account level, prefer private endpoints, and use Microsoft Entra ID authorisation instead of shared keys where possible.

2. Management ports open to the internet

Virtual machines with RDP (3389) or SSH (22) open to 0.0.0.0/0 are scanned and brute-forced within minutes of creation. Remove public IPs from VMs that do not need them, use Azure Bastion or just-in-time VM access, and restrict network security group rules to known sources.

3. Over-privileged identities

• Too many Owners and Contributors at subscription level.
• Service principals and managed identities with broad roles "to make it work".
• Permanent privileged role assignments instead of just-in-time access through Privileged Identity Management.

Apply least privilege with Azure RBAC, scope roles to resource groups, review assignments quarterly and remove stale service principals.

4. Secrets in code and configuration

Connection strings, storage keys and API tokens in source code, pipeline variables or app settings are a gift to attackers. Store secrets in Azure Key Vault, use managed identities so applications do not need secrets at all, enable secret scanning in your repositories and rotate any secret that has ever been committed.

5. Missing logging and monitoring

Without logs you cannot detect or investigate an attack. Send the Azure Activity Log, Entra ID sign-in and audit logs and key resource diagnostic logs to a Log Analytics workspace, and connect them to your SIEM such as Microsoft Sentinel. Alert on new role assignments, disabled logging, key vault access anomalies and resource deployments in unusual regions.

6. Ignoring Defender for Cloud recommendations

Microsoft Defender for Cloud continuously assesses resources against the Microsoft cloud security benchmark and gives a secure score with prioritised recommendations. Its foundational posture features are available at no extra cost, and paid plans add threat protection for servers, databases, storage and more. Review recommendations weekly and assign owners.

7. Flat networks and no segmentation

Put workloads in segmented virtual networks, use private endpoints for platform services, and control traffic with network security groups and Azure Firewall. Treat anything reachable from the internet as a priority for review.

8. No guardrails

Use Azure Policy to prevent misconfigurations at creation time: deny public IPs on sensitive resources, enforce encryption, require tags and restrict allowed regions. Prevention scales far better than cleaning up afterwards.

Security and cost go together

Unused resources, forgotten test VMs and orphaned public IPs are both a security risk and a cost. In my experience, a combined security and cost review finds savings and closes attack surface at the same time, as long as logging, backups and security controls are never the things that get cut.

Want an Azure security review? Contact me.

References and further reading

1. Microsoft: Shared responsibility in the cloud
2. Microsoft Defender for Cloud overview
3. Microsoft cloud security benchmark
4. CIS Benchmarks