Microsoft's BitLocker technology, now in its second edition with the release of Windows Server 2008 R2, is most commonly thought of as a solution for protecting desktops and laptops. Its new "To Go" capabilities in Windows 7 extend its encryption powers further to include connected USB drives. Encrypting data stored on these easily-losable devices ensures that a lost or misplaced USB drive doesn't spell a major data exposure event for your company.
But one application of BitLocker that doesn't get much press relates to its inclusion with Windows Server 2008 R2 itself. BitLocker as a full-drive encryption technology can indeed be used to protect your server data in the same ways it protects your laptops.
Now unlike laptops, which have a tendency to roam both inside and outside your protected networks, servers don't often make that transition. For most environments, once a server enters the building, it never again sees the light of day until years later when it's removed for decommissioning.
Servers that are forever secured behind locked doors don't necessarily make best candidate for full-drive encryption technologies. Servers that aren't behind locked doors, however, are a great fit for BitLocker.
If your environment supports branch offices or satellite network sites, it's likely that you don't have the same physical protections in those locations. Even today, many businesses still store branch office servers under the desks of employees, inadvertently creating a major data exposure risk in the lowest-security portions of their networks.
For these environments where servers can easily walk off with little warning, BitLocker on servers makes a lot of sense.
Why Now? Why BitLocker?
BitLocker arrives as Microsoft's second attempt at creating an encryption solution for Windows. It is designed to augment Microsoft's initial effort -- the Encrypting File System (EFS). While BitLocker gets much of the press with its easy installation, useful administrative tools, and handy levels of automation, the most important difference between BitLocker and its older brother EFS has to do with "full drive encryption".
Think for a moment about traditional EFS. Using this solution, you could very easily encrypt files on a file-by-file or folder-by-folder basis. Once enabled, any file or folder was encrypted simply by checking a box within its Properties menu. A few clicks later, and your sensitive spreadsheets or documents were protected against prying eyes.
While convenient for just those documents of importance, this file-by-file nature was also EFS's greatest weakness. The problem: file artifacts. When opening any particular file in its hosing application, new and unencrypted copies of that file could potentially be created in any number of locations. A temporary clear text copy could get created in a TEMP location for emergency restoration. The system could also cache a file, or pieces of that file, in a cache location. Copy-and-paste versus move operations to new folders could have very different effects on whether the file remained encrypted or not.
Because of all these residual artifacts, your safely-encrypted file could -- and often did -- leave pieces of itself strewn about one or more computer systems across the network and in the clear. That's not a great way to remain encrypted.
BitLocker is different because it encrypts the entire drive at once. In this version, that drive also needn't necessarily only be the system drive. By encrypting every drive all at once, BitLocker ensures complete security over files as well as their nasty artifacts.
BitLocker at the branch
Now, this whole-drive approach to encryption also changes the use cases where BitLocker makes sense. Remember that a BitLocker-enabled server encrypts its entire drive(s) at once. This means that the process to boot a server starts by decrypting that drive for use. The result is that BitLocker, unlike EFS, isn't an encrypting solution for your individual files sitting atop a running server. You wouldn't necessarily use BitLocker to encrypt a file against prying eyes who already have permission to view the file.
You can argue that such encryption is unnecessary in environments which permission correctly. Individuals who shouldn't be able to see the contents of a file shouldn't have the NTFS and/or share-level permissions to view it. Reality often overrides, however, and things like corporate security policies and regulatory compliance mandate the encryption of individual files. For these requirements, EFS is still available (with its own set of new Windows Server 2008 R2 features) in this version of the OS.
Those needs aside, BitLocker really does comes in handy for environments where the potential for hardware loss or theft is high. Laptops are a perfect example, as are USB keys. Your semi-protected servers sitting openly under the desks of remote office employees are a particularly smart example, too.
If a would-be intruder steals a BitLocker-enabled server, they simply won't be able to do anything with the data on its drives. Encrypted with 128- or 256-bit AES encryption, a brute-force approach to hacking its contents might take longer than the lifespan of the universe.
You can find plenty of information about actually deploying BitLocker in Microsoft's BitLocker Drive Encryption Deployment Guide for Windows 7. While the guide talks specifically about Windows 7 deployments, the concepts hold true for Windows Server 2008 R2 implementations as well.
|
Greg Shields, MVP, is a co-founder and IT guru with Concentrated Technology with nearly 15 years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization.
His recent book Windows Server 2008: What's New/What's Changed is available from SAPIEN Press. |
|
