9.1 Azure Virtual Machine Hardening & Host Security

6.1 Azure Virtual Machine Hardening & Host Security

Virtual machines deployed in Infrastructure as a Service (IaaS) environments represent a critical boundary under the Cloud Shared Responsibility Model. Because customers retain full administrative control over the guest operating system, securing Azure Virtual Machines requires a comprehensive defense-in-depth approach covering OS baseline configuration, endpoint protection, dynamic administrative access management, disk encryption, and hardware-level memory protection.

---

OS Baseline Hardening & Azure Machine Configuration

Hardening a virtual machine begins with establishing and maintaining a secure operating system baseline. Unhardened virtual machines with default OS configurations often contain unnecessary services, weak local password policies, exposed SMB protocols, and unpatched vulnerabilities that facilitate lateral movement following an initial breach.

OS Security Baselines

Microsoft publishes security baselines for Windows Server (such as Windows Server 2022 and 2025) and enterprise Linux distributions (RHEL, Ubuntu, AlmaLinux). Key hardening requirements include:

• Disabling Legacy Protocols: Disabling SMBv1, NBT-NS, LLMNR, and insecure TLS versions (TLS 1.0/1.1).
• User Rights Management: Restricting local administrator access, enforcing strong password complexity, and disabling the built-in local Guest account.
• System Services & Port Filtering: Disabling unused background services and applying local guest OS firewall rules.
• Audit Logging: Enabling advanced auditing policies for logon events, privilege usage, and process creation (including command-line logging).

Azure Machine Configuration (Guest Configuration)

Azure Machine Configuration (formerly known as Guest Configuration) extends Azure Policy governance inside virtual machines without modifying image source files. Operating via an in-guest extension and native Guest Configuration agent, it enables security teams to:

• Audit In-Guest Settings: Continuously evaluate whether VM OS settings comply with benchmark standards (e.g., CIS benchmarks or Microsoft security baselines).
• Enforce Configuration State: Automatically remediate drifted configurations (such as re-enabling local firewall profiles or updating password retention policies).
• Managed Identity Authentication: Use system-assigned or user-assigned managed identities to communicate securely with Azure Resource Manager without storing local credentials.

Azure Automanage for Virtual Machines

Azure Automanage automates host lifecycle security by applying Microsoft best-practice profiles to VMs. Upon onboarding, Automanage automatically configures and maintains:

1. Machine Configuration security baselines
2. Microsoft Defender for Cloud monitoring agents
3. Azure Update Manager automated patching schedules
4. Azure Backup policy retention schedules
5. Log Analytics workspace telemetry collection

---

Antimalware Extensions & Endpoint Protection

Protecting virtual machine workloads against malware, ransomware, and zero-day exploits requires real-time endpoint detection.

Microsoft Antimalware Extension for Azure

Microsoft Antimalware for Azure is a free, real-time protection capability available for Windows Server VMs. It operates as an Azure VM extension and provides:

• Real-Time Protection: Scans file system access, process execution, and network downloads to identify and block malicious activity.
• Scheduled Scans: Executes quick or full system scans during designated low-utilization maintenance windows.
• Signature Updates: Automatically fetches updated malware signatures from Microsoft Active Protection Service (MAPS).
• Custom Exclusions: Allows administrators to define file, path, and process exclusions (e.g., database transaction logs) to prevent performance degradation.

Exam Tip: In production enterprise environments, Microsoft Defender for Servers integrates Microsoft Defender for Endpoint (MDE) directly onto Azure VMs and Azure Arc-enabled servers. MDE provides advanced Endpoint Detection and Response (EDR), automated incident investigation, and live response capabilities beyond static antimalware scanning.

---

Just-In-Time (JIT) VM Access via Defender for Cloud

Exposing management ports—such as RDP (Port 3389) for Windows and SSH (Port 22) for Linux—directly to the public internet creates severe vulnerability exposure. Automated internet scanners continuously probe public IP addresses using brute-force dictionary attacks and known protocol exploits.

+-----------------------------------------------------------------------------------+
|                         JUST-IN-TIME (JIT) ACCESS FLOW                            |
+-----------------------------------------------------------------------------------+
| 1. Default State:   Network Security Group (NSG) has DENY rule for RDP (3389)    |
| 2. User Request:    Admin requests RDP access via Defender for Cloud / Azure CLI  |
| 3. Authorization:   Defender verifies Azure RBAC & Conditional Access policy      |
| 4. Dynamic Rule:    Defender injects high-priority ALLOW NSG rule (Source IP/3hrs) |
| 5. Expiration:      Timer expires -> NSG rule automatically deleted / DENY resumes |
+-----------------------------------------------------------------------------------+

JIT Operational Architecture

Just-In-Time (JIT) VM Access, a feature of Defender for Servers Plan 2, enforces a Zero Trust access model for administrative ports:

• Default Lock Down: JIT configures Network Security Group (NSG) deny rules that block all inbound traffic on selected ports (e.g., 3389, 22, 5985, 5986).
• On-Demand Port Opening: When an administrator requires management access, they submit a JIT request specifying:
  • The target virtual machine
  • The specific port requested
  • The authorized source IP address (or specific CIDR range)
  • The requested time duration, bounded by the maximum request time set on that port rule (3 hours in Defender for Cloud's default policy)
• Automated Rule Lifecycle: Upon approval, Defender for Cloud dynamically injects a temporary, high-priority Allow rule into the target NSG. Once the requested time window elapses, Defender automatically removes the allow rule, re-establishing total port lockdown.
• RBAC Requirement: Users initiating JIT access requests require the Microsoft.Security/locations/jitNetworkAccessPolicies/initiate/action permission on the VM scope.

---

Azure Storage & Disk Encryption: ADE vs. SSE

Azure offers two primary disk encryption architectures to protect data at rest: Azure Disk Encryption (ADE) and Server-Side Encryption (SSE).

Azure Disk Encryption (ADE)

ADE performs volume encryption inside the guest operating system using BitLocker on Windows and dm-crypt on Linux. It encrypts both the OS disk and attached data disks:

• Key Vault Dependencies: ADE stores BitLocker volume encryption keys (BEKs) and Key Encryption Keys (KEKs) in Azure Key Vault. The Key Vault must have the enabledForDiskEncryption access property set to true (enabled for disk encryption deployment).
• Platform Limitations: ADE is not supported on Ephemeral OS disks, Ultra Disks, or basic tier VM sizes. Changing VM size or restoring snapshots requires specific ADE decryption handling.

Server-Side Encryption (SSE)

SSE operates transparently at the Azure Managed Disk storage cluster layer using 256-bit AES encryption:

• Platform-Managed Keys (PMK): Enabled by default on all Azure Managed Disks at no additional cost.
• Customer-Managed Keys (CMK): Allows organizations to control encryption key lifecycles using keys stored in Azure Key Vault or Azure Key Vault Managed HSM. Managed Disks access Key Vault via a Disk Encryption Set (DES) resource bound to a system-assigned managed identity.
• Double Encryption: Enables two independent layers of AES-256 encryption at the storage layer (one using PMK and one using CMK, or host-based encryption) for stringent regulatory compliance.

Host-Based Encryption

Host-based encryption encrypts data directly on the Azure VM host server before sending it to Azure Storage. This guarantees that data flowing between the VM host CPU/RAM and the underlying storage cluster is encrypted end-to-end, while fully supporting Ephemeral OS disks.

---

Confidential Compute Virtual Machines

Standard encryption techniques protect data at rest (on disk) and in transit (over the network). However, data in use (resident in RAM during CPU execution) remains unencrypted in traditional virtualization host hardware.

+-----------------------------------------------------------------------------------+
|                     CONFIDENTIAL VM (TEE) MEMORY PROTECTION                       |
+-----------------------------------------------------------------------------------+
|  +-----------------------------------------------------------------------------+  |
|  |                     Guest OS & Applications (Encrypted RAM)                 |  |
|  +-----------------------------------------------------------------------------+  |
|  |         Hardware Trusted Execution Environment (AMD SEV-SNP / Intel TDX)    |  |
|  +-----------------------------------------------------------------------------+  |
|  ========================= HARDWARE ISOLATION BOUNDARY ========================== |
|  |              Hypervisor / Host OS / Cloud Operator (No RAM Access)          |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

Hardware-Enforced Trusted Execution Environments (TEEs)

Confidential VMs leverage hardware-based Trusted Execution Environments (TEEs) powered by AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) or Intel TDX (Trust Domain Extensions):

• RAM Encryption in Use: Main memory (RAM) is hardware-encrypted using CPU-generated memory keys. Even if an adversary gains root access to the host hypervisor or physically extracts memory modules, the RAM contents remain opaque.
• Attestation & Virtual TPM (vTPM): Provides remote cryptographic attestation certifying that the VM launched on genuine confidential hardware with an unaltered code state.
• Confidential OS Disk Encryption: Encrypts the OS disk with keys sealed directly to the VM's vTPM, ensuring the VM boots only when hardware attestation succeeds.