Azure VM Security

Azure Virtual Machines (VMs) are IaaS compute resources that run in a virtualized environment. Securing them requires a multi-layered approach covering network access, identity and access management, OS configuration, data protection, and monitoring. The AZ-500 exam tests your ability to implement and manage these controls.

NSGs filter traffic to and from Azure VMs at the subnet or NIC level. Each NSG contains a set of security rules that are evaluated in priority order (from 100 to 4096). Each rule specifies source/destination IP, port, protocol (TCP/UDP/Any), and action (Allow/Deny). By default, inbound traffic is denied, and outbound traffic is allowed. NSGs are stateful: if you allow inbound traffic on port 443, the return traffic is automatically allowed regardless of outbound rules. However, this statefulness does not apply to outbound rules—you must explicitly allow return traffic.

Example rule to allow RDP from a specific IP:

$nsg = Get-AzNetworkSecurityGroup -Name "myNSG" -ResourceGroupName "myRG"
$nsg | Add-AzNetworkSecurityRuleConfig -Name "AllowRDP" -Access Allow -Protocol Tcp -Direction Inbound -Priority 1000 -SourceAddressPrefix "203.0.113.0/24" -SourcePortRange "*" -DestinationAddressPrefix "*" -DestinationPortRange 3389
$nsg | Set-AzNetworkSecurityGroup

Common exam trap: NSGs do not replace firewalls—they are layer 4 filters. Application-level filtering requires Azure Firewall or a WAF.

Azure Bastion provides secure RDP/SSH connectivity to VMs over SSL, eliminating public IP exposure. It deploys as a PaaS service inside your virtual network (VNet) and connects to VMs via private IPs. Bastion uses the HTML5 client, so no additional software is needed. It supports both Azure AD authentication and local credentials. Key limitations: Bastion cannot be used to connect to on-premises VMs or VMs in peered VNets unless the VNet is in the same region and the Bastion is deployed in the spoke VNet.

Deployment example:

az network bastion create --name "myBastion" --public-ip-address "myBastionIP" --resource-group "myRG" --vnet-name "myVNet" --location "eastus"

JIT reduces attack surface by locking inbound traffic to VMs except when users request access via Azure Security Center or Azure Policy. When a request is approved (via RBAC), NSG rules are temporarily created to allow traffic to specific ports (e.g., 3389, 22) for a defined duration (default 3 hours, max 24 hours). After the duration, rules are removed. JIT works with both NSGs and Azure Firewall. It requires Microsoft Defender for Cloud (formerly ASC) enabled on the subscription.

Configuration via Azure CLI:

az security jit-policy create --resource-group "myRG" --location "eastus" --name "myJITPolicy" --vm "myVM" --ports "3389=3h"

Trap: JIT does not protect against attacks that use already-authorized access (e.g., compromised credentials). It only reduces the window of exposure.

ADE uses BitLocker (Windows) or DM-Crypt (Linux) to encrypt OS and data disks at rest. It integrates with Azure Key Vault to manage encryption keys and secrets. Encryption is performed at the hypervisor level, meaning the VM host encrypts data before writing to Azure Storage. ADE requires the VM to be deallocated for the initial encryption (for Windows) or can be done while running (Linux). Key vault must have 'Soft Delete' and 'Purge Protection' enabled.

Enable ADE:

az vm encryption enable --resource-group "myRG" --name "myVM" --disk-encryption-keyvault "myVault" --volume-type "ALL"

Common exam point: ADE does not encrypt temporary disks; those are encrypted at the host level by Azure Storage Service Encryption (SSE).

Azure Policy can enforce compliance by applying built-in or custom policies. Key policies for VM security include:

Example custom policy to require a specific tag:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "field": "tags.environment",
        "exists": "false"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

Update Management in Azure Automation ensures VMs are patched with the latest security updates. It uses the Azure Update Management solution (part of Azure Monitor Logs) and requires a Log Analytics workspace and a Hybrid Runbook Worker. You can schedule updates, define maintenance windows, and get compliance reports. For Azure VMs, you can also use Azure Automanage for automatic updates.

Azure Backup provides backup and restore capabilities for VMs. It uses the Backup extension, stores data in a Recovery Services vault, and supports application-consistent backups (using VSS for Windows). Backup frequency can be daily or weekly, with retention up to 99 years. Encryption is at rest using platform-managed keys (PMK) or customer-managed keys (CMK).

RBAC roles control who can manage VMs (e.g., Virtual Machine Contributor, VM Operator). Azure AD authentication can be used for RDP/SSH access (via Azure AD join or Azure AD Domain Services). For Linux, SSH key authentication is recommended over passwords. Managed identities allow VMs to access other Azure resources securely without storing credentials.

Azure Monitor collects metrics and logs from VMs. The Azure Monitor Agent (AMA) replaces the legacy Log Analytics agent. Security alerts from Microsoft Defender for Cloud detect threats like brute force attacks, malware, and suspicious processes. Enable Defender for Cloud's 'Servers' plan for full coverage. Network Watcher provides packet capture and NSG flow logs.

Generation 2 VMs support Secure Boot and virtual Trusted Platform Module (vTPM). Secure Boot ensures only signed OS kernels are loaded, preventing bootkits. vTPM provides hardware-based key storage for encryption and attestation. These features are enabled by default for Gen2 VMs.

Azure offers host-level encryption (encryption of VM data at the hypervisor) and confidential computing (encryption in use using Intel SGX or AMD SEV-SNP). Confidential computing protects data even from the host OS. These are advanced topics that appear less frequently but are tested in the 'Compute Security' domain.

Enterprise Scenario 1: Financial Services Company A financial firm must comply with PCI-DSS, which requires encryption of cardholder data at rest. They deploy Azure Disk Encryption on all production VMs. They use a Key Vault with hardware security module (HSM) backed keys (Premium tier) and enable soft delete and purge protection. They also enforce JIT VM access for all administrators, requiring approval from a manager for any RDP session. Network security groups are used to restrict access to only necessary ports (e.g., 443 for web servers, 1433 for SQL). Azure Bastion eliminates the need for public IPs on VMs. The firm monitors all access via Azure Monitor and Defender for Cloud alerts.

Scenario 2: E-commerce Platform An e-commerce company runs a multi-tier application with web, app, and database VMs. They use application security groups (ASGs) to group VMs by tier. NSG rules allow traffic only between ASGs (e.g., web to app on port 8080, app to DB on 1433). They deploy Azure Bastion for admin access and enable JIT for all management ports. They use Azure Update Management to patch VMs monthly. For backup, they use Azure Backup with daily backups and 30-day retention. They also enable host encryption for an extra layer of protection.

Common Pitfalls: Misconfigured NSG rules (e.g., allowing all inbound from Internet) can expose VMs. Forgetting to enable soft delete on Key Vault prevents ADE from working. JIT not being enabled on all VMs leaves some exposed. Overlooking Gen2 VM requirements for Secure Boot. Over-provisioning Bastion concurrent sessions can cause connectivity issues.