In the medical setting in which I work, we have an ethical and a legal obligation to protect patients’ data using a variety of means. Among the many business processes and technical methods, we include various types of encryption. When talking about encryption, we’ll often use phrases like, “encrypted in transit” and “encrypted at rest.” Encrypting content in transit involves technologies like SSL, denoted most obviously when you place an https in front of a web hyperlink in your browser. But today, as the headline implies, we’ll eventually focus on a particular type of encryption for data at rest, where it’s stored on disk. But first an overview.
Full Disk Encryption
Generally speaking, full disk encryption is one of my favorite tools. While a computer running full disk encryption remains in the hands of an authorized user with the appropriate boot-up password, the system is as useful as it would be otherwise, save for a performance toll that is often imperceptible on today’s hardware. There’s little need to think about manually encrypting specific file content, as everything written to the system is automatically and seamlessly encrypted. If the system later falls into the hands of an unauthorized user, particularly once it has been powered off, the data is inaccessible for all practical purposes. When I lost a Lenovo ThinkPad to a residential burglary in 2009, the data on that laptop was the very least of my concerns, thanks to full disk encryption.
For many Linux distributions, implementing LUKS (Linux Unified Key Setup) disk encryption is as simple as checking an ‘Encrypt’ checkbox during installation. Your operating system will be encrypted from the beginning, having never written anything other than a small boot partition (containing only the operating system kernel) in unencrypted form. With Apple FileVault and Microsoft BitLocker, however, disk encryption is configured after the operating system installation is complete. Today we’ll install Windows Server 2012 R2, and then implement BitLocker after the fact.
Trusted Platform Module
Microsoft’s BitLocker likes to rely on a hardware feature called Trusted Platform Module (TPM) version 1.2 and higher. It’s not mandatory, but historically it’s been a pain to get along without it. With Windows Server 2008 R2, for example, servers that didn’t have TPM required that the encryption key be stored on a USB flash drive. This becomes a problem in today’s data centers, where the majority of servers run atop VMware or a similar virtualization layer. There’s no way to pass TPM functionality from the underlying physical hardware through to a virtual machine. The limitation becomes obvious when running VMware’s High Availability (HA) and Distributed Resource Scheduler (DRS) tools, which routinely move virtual machines from one physical host to another at a moment’s notice. There was one way to get around the requirement to use either a TPM or a USB flash drive with BitLocker in Windows Server 2008 R2, but it required a compromise analogous to taping your house key to the outside of your front door. Better to use a 3rd-party solution. Fortunately, with Windows Server 2012 R2, we can implement BitLocker full disk encryption on a virtual server using a boot-up password that’s not stored with the server, and is known only to authorized administrators. We should note that Windows Server 2012 isn’t supported on VMware ESXi prior to version 5.5. Finally, let’s get started.
Within The vSphere Client
I’ll begin by defining my new virtual machine on which I plan to install Windows Server 2012 R2. When given the choice of Guest Operating System, I’ll be sure to sure to select Microsoft Windows Server 2012 (64-bit) from the list. For today’s example, I’ll use 2 virtual CPU sockets, 8 GB of RAM, the default SCSI controller, and I’ll create two virtual drives, sized 60 GB and 100 GB, for use as an OS and a data partition respectively. I’ll later set my CD/DVD drive to point to an ISO image of the Windows Server 2012 R2 installation media, and set it to Connect at power on.
Windows Server 2012 R2 Base Installation
Systems Administrators responsible for the installation, security and support of Windows Server are typically very familiar with performing a vanilla Windows installation. For the sake of keeping an already long post manageable, I’ll skip the how-to of a basic Windows setup. On a modern server hardware platform, the whole thing can be performed in about the same amount of time as it takes to read a definitive list of steps. It’s surprisingly fast when compared with prior versions of Windows. For purposes of this article, I installed Windows Server 2012 R2 with the GUI console and otherwise default settings. After that, I installed the VMware Tools, gave the server a desired name, set my timezone, enabled Remote Desktop, installed Windows Updates and set the firewall as desired. Finally, I created as drive D a basic disk containing an NTFS partition utilizing that 100 GB data drive that I’d defined using the vSphere Client earlier. Now we have the Windows Server 2012 R2 platform on which we’re ready to configure BitLocker.
Installing the BitLocker Feature
- Launch Server Manager from the shortcut near the left end of the Taskbar at the bottom of the screen.
- From Server Manager, click on Add roles and features. A Wizard will launch.
- Click Next at the Before you begin pane (if shown).
- Select Role-based or feature-based installation, followed by Next.
- Choose Select a server from the server pool, and then highlight your machine in the list below. Then click Next.
- You’ll be presented with a list of Server Roles, some of which could be active, depending on what you may have chosen to install previously. Rather than selecting a new role, simply click Next.
- Now you’re presented with a list of Features. Click on the box next to BitLocker Drive Encryption. A pop-up will reveal a list of additional dependencies which will also be installed. Click Add Features.
- Now back at the wizard, click Next. If you wish, highlight the checkbox to Restart the destination server automatically if required. Then click Install.
- The install will take a few seconds. If you didn’t choose an automatic restart, you should manually reboot when prompted.
Group Policy Change
Given that we don’t have TPM support on our virtual machine, we’ll need to make a local Group Policy change to allow using BitLocker without it. While we’re modifying Group Policy, we’re going to upgrade our cipher strength and make other changes as well. Though the following steps target our individual machine, similar policy could be applied to an Active Directory organizational unit, or even a whole domain.
- Navigate to Start > (down arrow) > Run, and launch the following command:
- Use the arrow symbols to expand the tree under Local Computer Policy as needed. You’ll want to navigate to: Computer Configuration \ Administrative Templates \ Windows Components \ BitLocker Drive Encryption.
- Select Choose drive encryption method and cipher strength. Turn the policy to Enabled, and choose the method AES 256-bit. Hit OK when done.
- Now navigate to subfolder \Fixed Data Drives.
- Select Enforce drive encryption type on fixed data drives. Turn the policy to Enabled, and choose the type Full encryption. OK when done.
- Now navigate to BitLocker Drive Encryption \Operating System Drives.
- Select Require additional authentication at startup. Turn the policy to Enabled. Select Allow BitLocker without a compatible TPM. Leave the settings below it in their default state, allowed but not required. Click OK when done.
- At the same level in the tree, also select Enforce drive encryption type on operating system drives. Turn the policy to Enabled, and choose the type Full encryption. OK when done.
Turning On BitLocker
- Launch Control Panel via the Start menu.
- Change the view to Large icons if it isn’t already, so that all options are presented.
- Launch BitLocker Drive Encryption.
- Focusing on our operating system drive first, BitLocker should be off at this point. Click on the option to Turn on BitLocker.
- Your system will run a quick diagnostic check. When it doesn’t discover a TPM, it will give you two alternatives. Choose Enter a password.
- Enter your desired BitLocker drive encryption password twice, and then click Next.
- You’ll be asked to back up your recovery key. Choose Save to a file, and store it in a network location known to be secure. It won’t let you save the recovery key to the drive you’re encrypting, nor can you continue without saving it somewhere.
- When prompted with the option to Run BitLocker system check, un-check it. The choice to Start encrypting will appear. Select it.
- A lock & key symbol will pop up on the System Tray near the lower, right-hand corner. You can double-click on it and monitor your progress. It took around 7 minutes to encrypt our 60 GB operating system drive, as our underlying hardware and storage environment are relatively recent and robust.
- Now, let’s Turn on BitLocker on our data volume. You may need to click on the down arrow / up arrow over at the right to see the option. Let’s use the same password as before so as to be consistent.
- Save your recovery key to a path known to be secure when prompted, before clicking Next. Choose to Encrypt entire drive if presented with a choice of what to encrypt. Then click Next.
- Start encrypting. Our empty 100 GB data volume was encrypted in about 12 minutes.
- If your data volume is seen as a removable drive, Turn on auto-unlock so that it comes up with the server.
Every time that you reboot your server, you’ll have to connect to the console via the vSphere Client and put in your password at the screen shown below, before the server will continue to load the operating system. While it’s a slight hassle, it’s consistent with the level of effort to reboot any Linux variant on which your OS volume is encrypted. (Within Windows Server 2012 R2, there’s also an available BitLocker Network Unlock, which is outside the scope of today’s conversation.)
Full disk encryption is but one of several layers of security that an organization (or an individual) can use to control access to their data. Disk encryption is insufficient on its own, of course, without proper access rules, encryption in transit, firewalls, antivirus, security updates and the like. And disk encryption may be most useful at the endpoints – small desktops, laptops and mobile devices – which are more likely to grow legs and walk than one’s core server infrastructure is. But in the year 2014, it’s better to be safe than sorry. Encrypt everything; everywhere. In transit and at rest. And with Windows Server 2012 R2 and BitLocker on top of VMware ESXi 5.5, it’s easy enough to do that with our virtual Windows Server assets going forward.
[I briefly referenced BitLocker: How to deploy on Windows Server 2012 and BitLocker Frequently Asked Questions (FAQ) when walking through this process for the first time.]