Latest posts by Paul Schnackenburg (see all)
- Project Honolulu - A new way to manage Windows Server - Wed, Nov 22 2017
- Use Azure Managed Service Identity (MSI) to store passwords in your code securely - Thu, Nov 9 2017
- Azure Data Lake overview - Fri, Sep 22 2017
The spread of server virtualization into both large and small businesses has led to unexpected security implications. Fabric/virtualization administrators now have the highest privileges, instead of the traditional model where domain administrators are the most trusted IT staff. This is precisely why many businesses that virtualize every workload possible still refrain from virtualizing domain controllers. If DCs are virtualized and I’m a Hyper-V or VSphere administrator, I can shut down the VM, copy the virtual disks for offline attacks, or install malware.
The other obvious scenario is public cloud environments where fabric administrators could potentially have full access to tenant VMs.
In Windows Server 2016, Microsoft is tackling this problem with a combination of technologies called Shielded VM. The idea is to have strong separation between the fabric administrators and the workload administrators, implemented through encryption and protected secrets.
The building blocks ^
Shielded VM relies on Generation 2 VMs, first introduced in Windows Server 2012 R2 Hyper-V. They boot from a virtual UEFI (Unified Extensible Firmware Interface) instead of from a traditional BIOS which, among other benefits, gives you Secure Boot. This ensures that neither the firmware nor the VM’s startup files can be tampered with. It also enables BitLocker disk encryption to be used inside the VM’s virtual disks.
Linux VMs are not left out. Several distributions can already take advantage of Generation 2 VM settings and Secure Boot in Windows Server 2012 R2. Shielded VMs in Windows Server 2016 will also work with Linux using dm-crypt.
On the host side, there’s a Host Guardian Service (HGS), which manages the VMs and their lifecycle. To unlock a VM’s drives so the VM can access those drives during the boot process, Shielding Data—stored in an encrypted file—is used to provide the necessary information for the VM to start. HGS is also a “safe harbor” AD forest because it runs a totally separate Active Directory infrastructure than your fabric AD does.
Host Guardian Service role information
There are two attestation models: Hardware Trusted Attestation and Administrator Attestation. The former relies on new hardware, such as Trusted Platform Module (TPM) version 2 chips in the hosts, whereas the latter simply requires that hosts are placed in a particular group in AD. Administrator Attestation is appropriate when you trust your AD infrastructure and fabric administrators.
Today, only Windows Server 2012 (and Windows 8+) and later is supported as a guest OS. Because Windows Server 2008 and R2 can’t run in a Generation 2 VM, Shielded VM can’t just be extended to them. The product team is very conscious of the need to extend at least some of the protections to these OSs as well. I guess we’ll see what comes in Technical Preview 4.
A Shielded VM doesn’t have a thumbnail in Hyper-V Manager, nor does it allow VM Connect to connect to it.
The whole hog: Hardware Trusted Attestation ^
As mentioned, this flavor requires new hardware in the form of TPM v2 chips in the Hyper-V servers. This is so new that it’s hard for Microsoft to find reliable servers to test on. The main benefit here is that the health of the hardware and host OS can be measured and accounted for.
You can use Virtual Machine Manager and Azure Pack in conjunction with Shielded VMs; however, they are not required components. The HGS is a role in Windows Server. It will automatically provide High Availability (HA) if you have more than one instance; Microsoft recommends at least three.
The HGS client is part of Hyper-V. Ideally, the keys used for a real-world implementation should be stored on a Hardware Security Module (HSM).
The HGS role should be run on bare metal installed servers, not on VMs. Of course, the HGS servers should be very well protected physically, and they require TPM chips. However, the current version 1.2 is sufficient. HGS also relies on “Just Enough Administration” (JEA), a new technology coming to Windows/PowerShell for time- and scope-restricted administrative access.
Host Guardian Service role and its prerequisites
Virtualization Based Security ^
Virtualization Based Security (VBS) is the other part of the overall security of the full attestation model. VBS isn’t just for Hyper-V. It can be used for any Windows Server 2016 server, as well as Windows 10 Enterprise clients. It’s Microsoft’s real answer to pass-the-hash and other similar attacks.
Instead of having the kernel of Windows be the “most secure part” of the OS, VBS relies on hardware technologies such as TPM v2, hardware virtualization (Intel-VT-x, AMD-V), second level address translation (Intel calls it Extended Page Tables, and AMD calls it Rapid Virtualization Indexing), along with I/O MMU virtualization (Intel VT-d, AMD-Vi) to create Virtual Secure Mode (VSM).
Essentially, this small piece of software runs in this hardware-virtualized part of the OS and keeps all the secrets, such as passwords and keys. The Local Security Access Sub System (LSASS) has been rewritten to have one part in the normal world and a secure part in VSM that keeps all the secrets. VBS on a Hyper-V host can offer a virtual TPM v2 chip to VMs, enabling them to also use VSM, if they run Windows Server 2016. VBS/VSM is not a technology that’s going to be backported to earlier versions of Windows.
Note that no relationship exists between the virtual TPM chips offered to VMs and any actual physical TPM chips in the hosts. One technology protects the host OS, and the other technology protects the OS in the VM; the virtual one isn’t linked to the physical hardware chip. This makes sense; otherwise, live migrating a VM would be impossible.
When you turn on Shielded VM, VM configuration files are encrypted. All live migration traffic is also encrypted without having to implement IPsec. The host crash dumps are encrypted, VM crash dumps are turned off by default, and they’ll also be encrypted if you enable them.
The end result is that fabric administrators have no access to VMs, can’t attach debuggers while they’re running (the hardened VM worker processes that run each VM don’t allow it), and can’t access the content of BitLocker–protected VHDX files. They can turn the VM off, of course, but because they’re the fabric administrator there are many ways they can power off a host to cause the same denial of service situation.
Azure not left out in the cold ^
With all these exciting technologies coming to on-premises Hyper-V, it’s worth mentioning Azure Disk Encryption, announced a few months back. While third-party services (such as CloudLink, now part of EMC) have for some time provided the capability to encrypt VMs running in Azure IaaS, this is the first time that the platform itself offers the capability.
Three scenarios are catered to: bringing an encrypted VM to Azure, creating a new VM with encrypted disks, and converting a standard VM to an encrypted VM. Both Windows and Linux are catered to. Note that, since Azure runs on Windows Server 2012 Hyper-V, only Generation 1 VMs are available, making this protection less comprehensive.
The keys are stored in another new Azure service, Key Vault. I would expect Azure IaaS to move to the more comprehensive method as they upgrade the underlying hosts to Windows Server 2016 (most likely to Nano Server).
I think Shielded VMs are a great addition to Hyper-V. I also think many enterprises will adopt the technology over the next few years. Most will start with the Administrator Attestation mode and will move to the full hardware attestation model only when servers with the required TPM chips have been on the market for a while.
As with most security improvement technologies, I suspect some businesses will bother with the overhead of implementing Shielded VM, whereas others will jump quickly because of the (and hosting companies will be the very first to line up).