Compartilhar via

What are Shielded VMs in Windows Server 2016 Hyper-V?

  • Artigo

As Information Technology became the norm, companies have been forced to invest tremendous amounts of money and manpower in protecting sensitive business information. These protections include building physically secured datacenters as well as implementing complex & time-consuming processes to ensure access to both physical and logical resources is strictly controlled.

With the introduction of virtualization, the story was yet further complicated. In a virtualized fabric, we can’t simply use the same techniques that we use to secure physical machines. Simply stated, the meat and potatoes of a VM are merely files on a disk and server admins and storage admins, etc. will have access to these files; access that can be abused and go undetected. For example, a malicious admin can copy the files of 10, 20 or more VMs to a USB stick taking their secrets home with them. If any one of the VMs was an Active Directory domain controller, the malicious admin can use readily available brute force techniques to crack the passwords in the Active Directory database ultimately giving them access to everything else. Attack vectors like these are true of all virtualization platforms.

Introducing Shielded Virtual Machines (VMs)

Windows Server 2016 Shielded VMs remedy this disconcerting situation by extending virtual machines the same security capabilities that physical machines have enjoyed for years, e.g. secure boot, TPMs and disk encryption. As a result, the data and state of a Shielded VM are protected against inspection, theft and tampering from malware running on a Hyper-V host as well as the fabric admins administering it. But, of course, these protections are provided in software—software that is subject to the same sort of attacks. A new Windows Server 2016 service known as the Host Guardian Service (HGS) helps address this problem. Without HGS, a Hyper-V host cannot power a Shielded VM on because it can’t decrypt it. Why? Because Hyper-V doesn’t have the keys—only HGS does. HGS won’t hand out the keys to a Hyper-V host until that host has been measured and is considered “healthy”—a process known as “attestation”. See the picture below for an overview of this process.

Workflow

There are many possible attack vectors that we are able to protect against with Shielded VMs, here are a few examples along with how Shielded VMs protect against the attack:

 

Attack vector Shielded VM defense
A malicious admin steals VHDs Shielded VMs’ VHDs are encrypted
Attach a debugger to the Hyper-V host HGS won’t release keys to hosts with debuggers attached—this is something we measure in HGS
Inject malware on a Hyper-V host All software (kernel mode, user mode and drivers) running on a host is measured
Inject malware into a VM template disk Shielded VMs are only deployed from template disks that match known healthy ones
A malicious admin attempts to move a Shielded VM to an untrusted host Trusted hosts are added to HGS using an identifier unique to their TPM; the new host will not be recognized because it wasn’t added

 

For more information, please take a look at any or all of the following resources:

In the next posts, we will go through the technical details of the Shielded VMs components and its configurations.

Comments

  • Anonymous
    July 14, 2017
    Very helpful