Azure Cloud Misconfigurations: How to Avoid Them
Key Takeaways
- The most common Azure finding is overly broad permissions — permanent Contributor or Owner roles at subscription level that are never reviewed are a critical risk
- Flat network architectures without segmentation enable lateral movement: one compromised resource means the attacker can reach everything else
- Publicly accessible Storage Account blob containers without authentication are a recurring, avoidable finding that exposes sensitive data unintentionally
- Without Azure Activity Logs in a SIEM and activated Diagnostic Settings, attacks often go undetected for weeks
- Outdated Conditional Access policies that still allow legacy authentication protocols are among the first five things checked in every security assessment
Most security incidents in cloud environments are not caused by sophisticated attacks but by misconfigurations. In Azure environments, we regularly find the same weaknesses during security assessments. The good news: most can be resolved with manageable effort.
Overly broad permissions
The most common issue we encounter in Azure environments is overly broad permissions. Users and applications have more rights than they need for their tasks. Particularly critical are permanent Contributor or Owner roles at subscription level that are not regularly reviewed.
The risk: if an account with excessive permissions is compromised, an attacker can access the entire environment. The solution is consistent application of the least-privilege principle: permissions are granted only as broadly as necessary and ideally time-limited via Privileged Identity Management (PIM).
Missing network segmentation
Many Azure environments grow organically without planned network segmentation. Virtual networks are flat, resources can communicate freely with each other, and Network Security Groups (NSGs) are either too permissive or not configured at all.
The risk: an attacker who gains access to one resource can move laterally through the entire environment. The solution starts with a clean network architecture: separation of workloads into dedicated subnets, restrictive NSG rules, and where possible, the use of Azure Private Endpoints to isolate services from the public internet.
Unprotected Storage Accounts
Azure Storage Accounts with public access or without encryption are a recurring finding. In some cases, blob containers are configured to be accessible from the internet without authentication.
The risk is obvious: sensitive data becomes unintentionally publicly accessible. The fix is straightforward: disable public access, enable encryption, and control access via Managed Identities or SAS tokens with limited validity.
Missing logging and monitoring
Without centralised logging and monitoring, security incidents go unnoticed. Many Azure environments have neither integrated Azure Activity Logs into a SIEM nor activated Diagnostic Settings for critical resources.
The risk: attacks are only noticed when the damage has already occurred. The solution: feed Activity Logs, Sign-in Logs, and Diagnostic Settings centrally into a Log Analytics Workspace or Microsoft Sentinel and configure alerts for security-relevant events.
Outdated Conditional Access policies
Conditional Access policies are often set up once and never adjusted afterwards. New applications, changed working patterns (such as remote work), or new threat scenarios are not reflected. Particularly critical: legacy authentication protocols that can bypass Conditional Access are still enabled.
Recommendation
These five points are the first things we check in every security assessment. If you are unsure how your Azure environment is positioned in these areas, a targeted assessment provides a clear basis for prioritised improvements.
Frequently Asked Questions
What is the most dangerous Azure misconfiguration in practice?
Overly broad permissions at subscription level are the most common and most dangerous issue. When an account with a permanent Owner role is compromised, an attacker has full access to all resources in that subscription. Privileged Identity Management (PIM) addresses this by making elevated permissions time-limited and approval-based.
Is configuring Network Security Groups once sufficient, or do they need ongoing maintenance?
NSGs require ongoing maintenance. Environments grow and change — new services, new teams, new working patterns all generate rule exceptions that accumulate over time. A regular review at least every six months is necessary to keep NSG rules aligned with actual requirements.
How do I verify that my Azure Activity Logs are actually being analysed?
Check whether your logs flow into a Log Analytics Workspace or Microsoft Sentinel, and whether active alert rules are configured for security-relevant events. Logs that are collected but never queried provide no security value.
What is the concrete risk of public access on Storage Accounts?
Blob containers with public access enabled are readable from the internet without authentication. This affects backups, exports, log files, and application data — often unintentionally left public. A single forgotten container can expose confidential business data to anyone who finds the URL.