L13. Securing Servers and VMs: Disk Encryption, Bastion, JIT Access & Defender for Servers

Disk Encryption Options

Azure offers layered options for protecting VM disk data at rest:

• Server-side encryption (SSE): enabled by default on all managed disks, encrypting data at the storage service level using either platform-managed or customer-managed keys (in Key Vault), with no impact on VM performance or boot process
• Azure Disk Encryption (ADE): encrypts the OS and data disks *inside* the guest VM using BitLocker (Windows) or DM-Crypt (Linux), integrated with Key Vault for key management; layered on top of SSE for scenarios requiring guest-level encryption, such as certain compliance mandates
• Encryption at host: encrypts the temp disk and disk caches (not just the persistent managed disks) using platform-managed keys, closing a gap SSE alone doesn't cover, since SSE only protects the managed disk itself, not the host-level caching layer

Azure Bastion

Azure Bastion provides browser-based, TLS-encrypted RDP and SSH connectivity to VMs directly through the Azure portal, without requiring a public IP on the VM or an open management port (3389/22) reachable from the internet. It's deployed once per VNet (in a dedicated AzureBastionSubnet) and covers every VM in that VNet, removing the need for a jump box VM that itself would need patching and securing.

Just-in-Time VM Access

Just-in-time (JIT) VM access, a Defender for Cloud feature, keeps management ports closed by default at the NSG level and only opens them for a specific requester's IP, for a limited time window, after an access request (which can itself require approval). This directly reduces the attack surface presented by a VM with RDP/SSH permanently open, which is one of the most common initial-access vectors for brute-force and credential-stuffing attacks against internet-facing VMs.

Extending Security to Hybrid and Multicloud Servers with Azure Arc

Azure Arc projects non-Azure servers (on-premises, other clouds) into Azure Resource Manager as Arc-enabled servers, which is the enabling step for extending Azure-native security tooling, Defender for Servers, Azure Policy, and Azure Machine Configuration, to machines that were never running in Azure at all. Without Arc onboarding, those servers are invisible to Defender for Cloud entirely.

Defender for Servers

Defender for Servers has two plan tiers: Onboarding covers Azure VMs natively and Arc-enabled hybrid/multicloud servers identically once Arc is in place, applying the same plan and settings regardless of where the underlying machine physically runs.

Agentless Scanning

Agentless scanning for VMs takes a snapshot of the VM's disk and scans it out-of-band, without installing any agent on the VM or consuming its CPU/network resources. This provides vulnerability, malware, and secret findings even for VMs where an agent can't be installed or where agent-based scanning would be operationally disruptive.

VM-Level Security Features

• Secure Boot: ensures only trusted, signed bootloaders and OS components load, preventing bootkit/rootkit persistence at boot time
• vTPM (virtual Trusted Platform Module): provides a virtualized TPM 2.0 for attestation and key storage, required for Windows features like BitLocker inside certain VM security configurations
• Integrity monitoring: continuously attests that Secure Boot and vTPM measurements haven't been tampered with, alerting if boot integrity is violated
• Security type / Trusted Launch / Confidential VMs: "Trusted Launch" bundles Secure Boot + vTPM + integrity monitoring as a VM security type selectable at creation; Confidential VMs go further, encrypting memory in use via hardware-based trusted execution environments, protecting data even from the cloud operator's own hypervisor

Azure Machine Configuration

Azure Machine Configuration (an extension of Azure Policy) audits and can remediate in-guest OS-level settings, registry keys, installed software, local security policy, that Azure Policy's resource-provider-level checks can't see, since those checks only see the ARM-level resource properties, not what's actually configured inside the operating system. Exam tip: A question describing "block internet-facing RDP by default, only allow it temporarily on request" is JIT VM access; a question describing "monitor whether in-guest registry settings still match the security baseline" is Azure Machine Configuration; don't confuse the two even though both live under Defender for Cloud/Azure Policy tooling.