Azure Misconfigurations: Identity, Storage & Network Risks

Security exposure this creates

Unpatched vulnerabilities in your tech stack are the #1 entry point for breaches targeting Indian businesses. Here's what to watch.

Azure misconfigurations — not zero-day exploits — are how most Indian tenants get breached. Public Blob Storage containers, overprivileged Entra ID (Azure AD) roles, missing Network Security Group (NSG) rules, exposed Azure SQL or Cosmos DB endpoints, and weak Conditional Access policies together account for the overwhelming majority of real-world Azure incidents. This guide walks through each risk category and gives Indian cloud teams a practical hardening checklist using native tools: Entra ID, Azure Policy, NSGs, and Microsoft Defender for Cloud.

Unlike AWS or GCP, Azure's risk surface is shaped by its identity-first architecture — Entra ID sits at the center of almost every resource-access decision, which means identity misconfigurations cascade further and faster than in other clouds.

Why Azure Misconfigurations Are Different From AWS or GCP

Azure ties nearly every control plane decision back to Entra ID. A single overprivileged service principal or an app registration with excess Directory.ReadWrite.All permissions can touch storage, compute, networking, and Key Vault simultaneously — there is no equivalent single blast radius in AWS IAM or GCP IAM policies scoped per-project. This is also why Microsoft ships Defender for Cloud's Secure Score and Azure Policy as first-class governance tools rather than optional add-ons: the platform assumes teams need continuous configuration drift detection, not a one-time hardening pass.

For Indian cloud teams — many of whom run hybrid estates spanning on-prem AD, Azure, and SaaS like Microsoft 365 — this identity-centrality means a single compromised on-prem account synced via Azure AD Connect can become a tenant-wide incident.

🛡️

SECURITY

If your organization syncs on-prem Active Directory to Entra ID, a misconfigured Azure AD Connect account with Directory Synchronization Accounts role is a common privilege escalation path. Audit sync account permissions quarterly.

1. Public Blob Storage Containers

Azure Storage accounts default to private, but a single misclick — setting a container's public access level to "Blob" or "Container" during creation or via a CI/CD template — exposes every object inside to unauthenticated internet access. Unlike S3, Azure Blob Storage container-level public access applies uniformly to all blobs in that container, so one misconfigured container can leak an entire dataset: customer PII exports, database backups, application logs with embedded secrets, or signed SAS tokens with long expiries.

The most common root causes seen in Indian tenants:

Storage accounts provisioned via Terraform/ARM templates that default allow_blob_public_access = true
Developers setting container access to "Container (anonymous read access for containers and blobs)" while debugging, then forgetting to revert
Shared Access Signature (SAS) tokens generated with account-level scope and multi-year expiry, effectively bypassing container ACLs entirely
Static website hosting enabled on a storage account that also holds non-public application data in the same account

⚠️

WARNING

Allow Blob Anonymous Access is a storage-account-level setting that must be explicitly disabled — even if every container is set to private, a future container or a misconfigured deployment script can silently expose data unless the account-level flag itself is turned off.

2. Overprivileged Entra ID Roles

Entra ID role assignments are where most Azure privilege escalation paths originate. The two recurring patterns:

Standing Global Administrator access. Indian SMB and mid-market tenants frequently have 5-10 users with permanent Global Administrator rights — often carried over from initial tenant setup and never pruned. Global Admin can reset any password, add federated domains, and grant itself Owner on every subscription.

Service principals with tenant-wide Graph API permissions. Automation scripts, CI/CD pipelines, and third-party SaaS integrations are frequently granted Application.ReadWrite.All or Directory.ReadWrite.All when a narrower, resource-scoped permission would suffice. A leaked client secret for such a service principal is equivalent to a Global Admin compromise.

Azure's Privileged Identity Management (PIM) exists specifically to convert standing privileged access into just-in-time, time-boxed, approval-gated access — but PIM must be explicitly licensed (Entra ID P2) and configured; it is not on by default even in tenants that hold the license.

Know your vulnerabilities before attackers do

Run a free VAPT scan — takes 5 minutes, no signup required.

Book Your Free Scan

3. Missing or Overly Permissive NSG Rules

Network Security Groups are Azure's subnet/NIC-level firewall. Common misconfigurations:

Inbound rules allowing 0.0.0.0/0 (Any) on RDP (3389) or SSH (22), often added temporarily for troubleshooting and never removed
NSGs attached at the NIC level but not the subnet level (or vice versa), creating inconsistent enforcement across VMs in the same subnet
Azure Bastion or a jump-box VM correctly locked down, but a second, forgotten VM in the same VNet still has a public IP and an open NSG rule
Application Security Groups (ASGs) not used, resulting in flat, hard-to-audit rule sets that accumulate exceptions over years

graph TD A[Public Blob Storage container] -->|Anonymous read| B[Exposed backup or config file] B -->|Leaked connection string| C[Azure SQL or Cosmos DB access] G[Overprivileged Entra ID role] -->|Standing Global Admin| D[Service principal secret compromised] D -->|Directory ReadWrite All scope| C C -->|Weak Conditional Access| E[Lateral movement across subscription] E -->|Missing NSG restriction| F[Data exfiltration] style A fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0 style G fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0 style B fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style D fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 style F fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0

4. Exposed Azure SQL and Cosmos DB

Azure SQL Database and Cosmos DB both ship with a firewall layer in front of the data plane, and both are routinely misconfigured to allow broader access than intended:

Misconfiguration	Azure SQL	Cosmos DB
Public network access left enabled	Default "Allow Azure services" toggle exposes DB to any Azure tenant's resources, not just yours	Public endpoint reachable unless explicitly restricted to a VNet
Firewall rule 0.0.0.0-255.255.255.255	Sometimes added for "testing" and left in place	Equivalent all-IP rule under Cosmos DB firewall settings
Authentication	SQL auth with weak/shared passwords instead of Entra ID-only auth	Primary/secondary keys embedded in client apps instead of using Entra ID RBAC or resource tokens
Auditing	Azure SQL Auditing not enabled, no Advanced Threat Protection	Diagnostic logging to Log Analytics not configured
Private connectivity	No Private Link / Private Endpoint configured	No Private Endpoint, traffic traverses public internet

💡

TIP

Enable Microsoft Defender for Cloud's Defender for SQL and Defender for Cosmos DB plans — they detect anomalous query patterns (e.g., a service account suddenly running a full-table export) that firewall rules alone cannot catch.

5. Weak Conditional Access Policies

Conditional Access is Entra ID's policy engine for enforcing MFA, device compliance, and location-based restrictions at sign-in time. Weak or absent Conditional Access is consistently among the top findings in Indian tenant reviews:

No Conditional Access policy requiring MFA for admin roles — meaning a phished password alone grants Global Admin access
Legacy authentication protocols (IMAP, POP3, SMTP AUTH) not blocked, which bypasses MFA entirely since these protocols predate modern auth
No sign-in risk or user risk policies configured (requires Entra ID Protection), so impossible-travel and leaked-credential signals go unactioned
Break-glass emergency access accounts either missing or, worse, not excluded from Conditional Access policies — locking out admins during an actual incident

98%Attacks blocked by basic security hygiene such as MFA and least-privilege access (Microsoft Digital Defense Report)

99.9%Account compromise reduction from enabling MFA (Microsoft security research, cited in Microsoft Entra documentation)

13+ lakhCybersecurity incidents reported to CERT-In annually in recent years (CERT-In Annual Report)

Distribution of Azure Misconfiguration Categories

Based on Microsoft's own Cloud Adoption Framework guidance and common findings surfaced by Defender for Cloud's Secure Score across enterprise tenants, identity and access issues dominate the misconfiguration landscape, followed by network exposure and data-layer gaps.

pie title Azure Misconfiguration Categories by Frequency "Identity and Entra ID access" : 35 "Network and NSG exposure" : 25 "Storage and Blob exposure" : 20 "Database exposure" : 12 "Logging and monitoring gaps" : 8

Practical Hardening Checklist for Indian Cloud Teams

Use this as a working checklist against Azure Policy, Defender for Cloud recommendations, and Entra ID admin center — not a one-time audit.

Control area	Action	Native Azure tool
Storage	Disable `Allow Blob Anonymous Access` at account level; audit all SAS tokens for expiry and scope	Azure Policy, Storage Account settings
Identity	Reduce standing Global Admin count to the minimum; enable PIM for just-in-time elevation	Entra ID PIM
Identity	Require MFA for all admin roles and block legacy authentication	Conditional Access
Network	Remove Any-Any inbound NSG rules; replace RDP/SSH direct exposure with Azure Bastion	NSG Flow Logs, Azure Bastion
Database	Disable public network access on Azure SQL and Cosmos DB where feasible; use Private Endpoints	Private Link
Governance	Enforce baseline configs tenant-wide (deny public blob access, require MFA, restrict resource locations)	Azure Policy initiatives
Monitoring	Enable Defender for Cloud across all resource types; review Secure Score weekly	Microsoft Defender for Cloud
Governance	Run periodic access reviews for Entra ID role assignments and service principal permissions	Entra ID Access Reviews

🎯Key Takeaway

Azure's identity-first design means a single overprivileged Entra ID role or leaked service principal secret can cascade into storage, database, and network access simultaneously — hardening Conditional Access and Privileged Identity Management delivers more risk reduction per hour invested than any other single control.

Where Automated Scanning Fits

Manually tracking Blob container ACLs, NSG rule sets, Entra ID role assignments, and database firewall rules across a growing subscription estate does not scale past a handful of resource groups. Continuous configuration checks — the same category of checks Defender for Cloud's Secure Score runs — need to be paired with external attack-surface validation that shows what an attacker sees from outside the tenant, not just what the control plane reports.

This is where a free VAPT scan from Bachao.AI helps: it externally validates exposed storage endpoints, open network ports, and misconfigured public services against your Azure estate, complementing internal tools like Defender for Cloud and Azure Policy rather than replacing them. For organizations that need compliance-grade validation — including under India's DPDP Act — a scan can be paired with a DPDP compliance review and delivered with a CERT-In empanelled partner where a formal audit trail is required.

Dhisattva AI Pvt Ltd built this scanning approach specifically for Indian cloud teams who need continuous, jargon-free visibility into cloud misconfigurations without standing up a dedicated cloud security team.

ℹ️

INFO

Pair external scanning with Microsoft's own Secure Score trend over time — a rising or flat Secure Score alongside new external findings usually means new resources are being provisioned outside your governance baseline (Azure Policy is not blocking non-compliant creates).

Getting Started: A 30-Day Priority Order

Week 1: Audit and disable anonymous Blob access; rotate any long-lived SAS tokens found in code repositories or CI/CD variables.
Week 1-2: Enforce MFA via Conditional Access for all users with any administrative role; block legacy auth protocols tenant-wide.
Week 2: Review and reduce standing Global Administrator and Owner role assignments; enable PIM where licensed.
Week 3: Audit NSG rules for Any-Any inbound exposure; migrate direct RDP/SSH access to Azure Bastion.
Week 3-4: Restrict public network access on Azure SQL and Cosmos DB instances; enable Defender for SQL/Cosmos DB.
Week 4: Enable Defender for Cloud across the full resource estate and set a Secure Score baseline to track monthly.

Further reading on control frameworks: NIST Cybersecurity Framework, OWASP Cloud Security guidance, and Microsoft's own Azure security baseline documentation.

Frequently Asked Questions

What is the most common Azure misconfiguration in Indian companies?

Overprivileged Entra ID role assignments — particularly standing Global Administrator access held by more users than necessary — combined with public Blob Storage containers left open during development. Both are easy to introduce and easy to overlook because they don't break functionality, only security posture.

How do I check if my Azure Storage account is publicly exposed?

In the Azure Portal, open the Storage Account, go to Configuration, and check the "Allow Blob anonymous access" setting — it should be Disabled. Then review each container's individual public access level under Container properties, since account-level and container-level settings both need to be correct.

Does Microsoft Defender for Cloud replace the need for external scanning?

No. Defender for Cloud evaluates configuration from inside the control plane (what Azure Resource Manager reports), while external scanning shows what is actually reachable from the internet, including drift or shadow resources that governance tools may not yet cover. The two are complementary, not substitutes.

What is the difference between NSG and Azure Firewall for network security?

NSGs are stateful, subnet/NIC-level allow/deny rule sets best for basic segmentation, while Azure Firewall is a managed, stateful network firewall with threat intelligence and application-level filtering for perimeter control. Most tenants need both: NSGs for internal segmentation, Azure Firewall (or a WAF) for internet-facing traffic.

How does Conditional Access reduce the risk of Azure account compromise?

Conditional Access enforces MFA, device compliance, and location- or risk-based sign-in restrictions before granting access, so a compromised password alone is not enough to reach admin roles or sensitive resources. Combined with blocking legacy authentication, it closes the most common phishing-to-breach path.

Is Azure misconfiguration risk covered under India's DPDP Act obligations?

Yes — if an Azure-hosted misconfiguration (public storage, exposed database) leads to exposure of personal data, it falls under the DPDP Act's data fiduciary obligations to implement "reasonable security safeguards." Regular configuration audits and external scans form part of demonstrating that safeguard, alongside a DPDP compliance review.

BR

Bachao.AI Research Team

Cybersecurity Research

AI-powered security research and threat intelligence from the Bachao.AI team. Covering the latest vulnerabilities, CVEs, and cybersecurity developments affecting Indian businesses.

Get cybersecurity insights for Indian SMBs

Weekly vulnerability alerts, DPDP compliance tips, and security guides. No spam — unsubscribe anytime.

We respect your privacy. Your email is never shared.