Netherlands: Software

Introductie Windows Server 2016

Issue link:

Contents of this Issue


Page 114 of 173

105 C H A P T E R 5 | Security Shielded VMs provide protection for the data and state of the VM against inspection, theft, and tampering from those who have administrator privileges. Shielded VM works for Generation 2 VMs that provide the necessary secure startup, UEFI firmware, and virtual Trusted Platform Module (vTPM) 2.0 support required. Although the Hyper-V hosts must be running Windows Server 2016 Technical Preview, the guest operating system in the VM can be Windows Server 2012 or above. A new Host Guardian Service instance is deployed in the environment, which stores the keys required for an approved Hyper-V host that can prove its health to run shielded VMs. A shielded VM provides the following benefits: BitLocker encrypted drives (utilizing its vTPM) A hardened VM worker process (VMWP) that encrypts live migration traffic in addition to its runtime state file, saved state, checkpoints, and even Hyper-V Replica files No console access in addition to blocking Windows PowerShell Direct, Guest File Copy Integration Components, and other services that provide possible paths from a user or process with administrative privileges to the VM How is this security possible? First, it's important that the Hyper-V host has not been compromised before the required keys to access VM resources are released from the Host Guardian Service (HGS). This attestation can happen in one of two ways. The preferred way is by using the TPM 2.0 that is present in the Hyper-V host. Using the TPM, the boot path of the server is assured, which guarantees no malware or root kits are on the server that could compromise the security. The TPM secures communication to and from the HGS attestation service. For hosts that do not have a TPM 2.0, an alternate Active Directory–based attestation is possible; however, this merely checks if the host is part of a configured Active Directory group. Therefore, it does not provide the same levels of assurance and protection from binary meddling and thus host administrator privileges for a sophisticated attacker. However the same shielded VM features are available. After a host undergoes the attestation, it receives a health certificate from the attestation service on the HGS that authorizes the host to get keys released from the key protection service that also runs on the HGS. The keys are encrypted during transmission and can only be decrypted within a protected enclave that is new to Windows 10 and Windows Server 2016 Technical Preview (more on that later). These keys can then be used to decrypt the vTPM to make it possible for the VM to access its BitLocker-protected storage and start the VM. Therefore, only if a host is authorized and non- compromised will it be able to get the required key and turn on the VM's access to the encrypted storage (not the administrator, though, as the virtual hard drive (VHD) remains encrypted on the drive). At this point, it might self-defeating: If I am an administrator on the Hyper-V and the keys are released to the host to start the VM, I would be able to gain access to the memory of the host and get the keys, thus nullifying the very security that should protect VMs from administrative privileges. Fortunately, another new feature in Windows 10 and Windows Server 2016 Technical Preview prevents this from happening. This feature is the protected enclave mentioned earlier, which is known as Virtual Secure Mode (VSM). A number of components use this service, including credential guard. VSM is a secure execution environment where secrets and keys are maintained and critical security processes run as Trustlets (small trusted processes) in a secure virtualized partition. This is not a Hyper-V VM; rather, think of it like a small virtual safe that is protected by virtualization based on technologies such as Second Level Address Translation (SLAT) to prevent people from trying to directly access memory, I/O Memory Management Unit (IOMMU) to protect against Direct Memory Access (DMA) attacks, and so on. The Windows operating system, even the kernel, has no access to VSM. Only white-listed processes (trustlets) that are Microsoft signed are allowed to cross the "bridge" to access VSM. A vTPM Trustlet is used for the vTPM of each VM, separate from the rest of the VM process, which runs in a new type of protected VM worker process. This means that there is no way to

Articles in this issue

Archives of this issue

view archives of Netherlands: Software - Introductie Windows Server 2016