Cloud Security for Azure in UAE

The shared responsibility line, and where it actually breaks

Azure's infrastructure is genuinely hard to attack directly. Datacentre physical security, hypervisor isolation, DDoS protection on the backbone, and the underlying network fabric are Microsoft's problem, and Microsoft is good at that problem. The line shifts depending on service model. On IaaS (a virtual machine), the customer owns the guest operating system, patching, host firewall rules and everything installed on top. On PaaS (App Service, Azure SQL, Functions), Microsoft manages the runtime and patching, but the customer still owns identity, data classification, network access rules and application-level configuration. On SaaS (Microsoft 365 layered on the same tenant), the customer's job narrows further to identity, data governance and user behaviour, but does not disappear.

The failure mode in the UAE is rarely a wrong diagram of this model. Teams draw the line correctly in a slide and still leave a storage account with public blob access, because nobody owns checking it. Shared responsibility only works if someone is accountable for the customer half on a recurring basis, not just at go-live.

What actually decides whether an Azure environment is secure

Four things determine outcome, in roughly this order of impact:

Identity architecture. Conditional Access, multi-factor enforcement, and how privileged roles are granted matter more than any single product decision. Most Azure compromises start with a phished or reused credential, not a network exploit.

Network and data exposure. Network security groups, Azure Firewall rules, private endpoints for PaaS services, and encryption configuration for storage and databases. Default-deny inbound, explicit allow by exception, is the only posture that holds up under review.

Logging that actually reaches a SIEM. Azure Activity Log, Microsoft Entra ID sign-in logs, and resource-level diagnostic settings need to be turned on and forwarded somewhere a human or a detection rule will see them. Logs sitting unread in a storage account satisfy an auditor's checkbox and nothing else.

Configuration drift control. Environments do not stay secure because someone configured them correctly once. A dev subscription with contributor-level access left active after a project ends, or a firewall rule opened for a two-week test that never got closed, is the normal way these environments degrade.

Where UAE Azure deployments most often fail

Storage and network exposure

Public blob containers and databases reachable from any source IP remain the most common finding in Azure configuration reviews across the region. It rarely starts as a decision. It starts as a temporary exception during a migration or a proof of concept, and nobody schedules the follow-up to lock it back down. Azure Policy can enforce deny rules for public network access on storage and SQL at the subscription level, which removes the dependency on someone remembering.

Identity sprawl and stale service principals

Service principals and app registrations accumulate over years of integrations, and very few organisations have an inventory of which ones still need the permissions they were granted. Certificate and secret rotation on these accounts is often years overdue, because nothing forces the conversation the way an expiring user password does. This is exactly the kind of gap Entra ID governance features (access reviews, entitlement management) exist to close, but only if someone runs the reviews.

Logging gaps that only surface during an incident

Diagnostic settings are per-resource in Azure, which means logging coverage is inconsistent by default: a team that enabled it on VMs during initial deployment frequently never revisited it for storage accounts, key vaults or PaaS services added later. This gap is invisible until an incident response team goes looking for evidence that was never captured.

Cloud Security Posture Management: what it does and does not do

Cloud security posture management, whether that is Microsoft Defender for Cloud, a third-party CSPM, or both, works as a continuous configuration audit. It scans subscriptions against a security baseline (CIS, Microsoft's own benchmark, or a custom one), surfaces resources that violate it, such as public storage, permissive network rules, or missing encryption, and in Defender for Cloud's case can trigger automated remediation for some finding types.

What it does not do is decide what your baseline should be, tell you whether a finding matters for your data classification, or replace a human reviewing exceptions. A secure score of 80 percent is not a compliance outcome; it is a prioritised list of what to fix next. Treat it as the input to a remediation process with owners and deadlines, not the output of one. This site's cloud security work covers how CSPM fits alongside broader hardening beyond Azure-specific controls, and a Microsoft Defender for Cloud deployment is usually the fastest way to get that baseline visibility in an Azure-native tenant.

What UAE regulators and assessors actually look for

Compliance obligations in the UAE vary by sector and emirate, but assessors consistently ask for the same categories of evidence regardless of which specific standard applies: documented data classification, an access control matrix that maps to actual RBAC assignments (not an aspirational one), evidence of encryption in transit and at rest, incident response procedures with defined notification timelines, and logging retention that meets the applicable minimum. NESA's Information Assurance Standards apply to government and critical infrastructure entities and set baseline control expectations. CBUAE guidance shapes what banks and financial institutions are expected to demonstrate. ADGM and DIFC operate their own data protection regimes for entities registered in those free zones. None of these accept a vendor's marketing claim of "compliant out of the box" as evidence; assessors want to see the control actually configured and actually logged.

Design controls to the strictest applicable standard first, then confirm which specific obligations apply to your entity type and licence. Microsoft's compliance certifications describe the platform. They do not describe your configuration of it.

Ransomware in Azure tenants: the pattern that repeats

The attack chain against Azure-hosted environments is consistent across incident write-ups in the region: phishing or a reused credential for initial access, credential or token theft, privilege escalation through an over-permissioned role, lateral movement via service principals or stale admin accounts, then disabling logging and backup access before encryption. The recurring design flaw is credential reuse between backup administration and day-to-day operations. If the account that can delete snapshot backups is the same one used for routine admin work, one phished credential removes both the data and the recovery path. Separating backup access into its own privileged role, with just-in-time activation, closes that failure without new tooling.

Identity is the perimeter: locking down Entra ID

Azure's network edge is not where most attacks land. Identity is. A workable Entra ID configuration for a UAE enterprise tenant includes:

• Conditional Access policies that require multi-factor authentication for sign-ins from outside expected geographies or from unmanaged devices, and that treat break-glass accounts as the highest-risk accounts in the tenant, not an exception to monitor less.
• Role-based access control scoped to least privilege, with Owner and Contributor roles reserved for a small, reviewed group rather than granted by default during provisioning.
• Privileged Identity Management for just-in-time activation of administrative roles, so a compromised credential without an active PIM request cannot use privileges it technically holds.
• Scheduled rotation and an actual inventory of service principal credentials, since these accounts do not get the password-expiry nudge that human accounts do and are consequently the ones left stale for years.

A working baseline for an Azure security review

An Azure environment is in reasonable shape when it can answer these without a scramble: every publicly reachable endpoint is a deliberate decision with an owner, not a forgotten exception. RBAC assignments match a maintained access matrix rather than accumulated history. Diagnostic logging from every resource type in scope reaches a SIEM someone actually monitors, and Microsoft Sentinel is a common landing point for that data in Azure-native environments. Service principal credentials have an inventory and a rotation schedule. And backup or snapshot access sits in a role separate from routine administration.

None of this requires exotic tooling. It requires someone with the authority to enforce it running the same checks on a schedule, because the gap between a secure configuration and a compromised one in Azure is rarely a missing product. It is a control that was configured correctly once and never checked again.