Four Data Security Concepts Every Windows Server Admin Should Know

By Chris Lionetti, NetApp


I’ve been getting a lot of questions lately regarding options for protecting data in a Windows Server environment. And if there’s one thing I’ve learned, it’s that there is a lot of confusion regarding the different methods available to secure data. In an attempt to clarify the subject, I’ve decided to cover four terms that are commonly intermixed and/or misused; define exactly what they do; explain the types of protection they provide;  and—perhaps most importantly—review their impact on performance.


First, though, it’s important to understand two concepts:

    • Data-at-Rest encryption: This is when the data sitting on a storage device is encrypted. This is the only method that can prevent your data from being exposed if the physical device is stolen.
    • Data-in-Flight encryption: This refers to the communication path, only. The sender and receiver of the data both encrypt and decrypt the data on the wire. This prevents a hacker from sniffing the network wire and intercepting your data in real time.

Now, for the four terms commonly misunderstood:

    • SMB Signing:  Can ONLY be used to authenticate who the message came from. In other words,   you only know that the message is authentic. The best way to think of this is as a signed postcard. Anyone in the path can read each message. This takes some CPU resources on the source and destination devices. This also only works for SMB based protocols (SMB 3.0 / CIFS) and is for Data-In-Flight, only.
    • SMB Encryption: Much like SMB Signing, this authenticates who the message is from, but it also encrypts all of the contents of the message as well. As analogies go, this is a sealed envelope. However, this consumes significantly more CPU resources on both the source and destination device. This also has the same restrictions as SMB Signing—it’s only available for SMB based protocols and it’s for Data-In-Flight, only.
    • BitLocker Encryption: This can be used to encrypt entire Windows Volumes. This method encrypts each physical block on the volume using the Trusted Platform Module (TPM) generated key. Since every single block is encrypted using the key and the LBA number, even blank sectors across a single drive don’t look like each other. This also means that if selected, all of your Thin Provisioning, Deduplication, Sub-LUN clones, and Offload Data Transfers (ODX) will no longer work. This type of protection consumes a significant amount of CPU resources on the host that has BitLocker enabled. However, it doesn’t affect the CPU on the target device. One limitation is that these BitLocker devices are block devices and thus, cannot be used on SMB shares. BitLocker provides both Data-at-Rest Encryption and Data-in-Flight encryption between the Host and the Target. Special note here: many servers do not contain a TPM chip, in which case using BitLocker may be impractical.
    • Full Drive Encryption (using NetApp Storage Encryption):  This approach encrypts each drive on a NetApp system using a private key. Since the work of encrypting the drives is offloaded from the controller to the encryption processor on the drives, this generates no extra load on either the host or the NetApp controller target device. All advanced features of the NetApp system will continue to work, such as Thin Provisioning, Dedupe, Sub-LUN Clones, ODX, etc. This provides Data-at-Rest encryption. Note that this approach requires using a special FDE version of the storage devices.

It should also be noted that NONE of the four methods above will protect you from a hacker who gains access to your system; they are only used to eliminate external threats, such eavesdroppers and physical asset thieves. The following table summarizes the methods:





Effect on NetApp Controllers

Effect on Windows Host

Block or File





Some controller CPU consumption

Some host CPU consumption

File Only

SMB Encryption



Controller CPU intensive

Some host CPU consumption;

Disable some NIC Offloads

File Only




Disables many advanced features; No controller CPU impact

Host CPU Intensive

Block Only

NetApp FDE





Block & File


SMB Encryption and the BitLocker

It’s important to understand that the SMB encryption feature and the BitLocker feature have nothing to do with one another. This is best illustrated by a simple scenario where both SMB Signing and BitLocker have been enabled. Consider a scenario with Client A, Server M, and NetApp LUN X. If Client A connects to a share on Server M using SMB encryption, and Server M is connected to a Fibre Channel LUN X on the NetApp system, then the packet is: 1) Encrypted by Client A, then 2) Decrypted on Server M, and then 3) Re-encrypted and sent to LUN X.


In this scenario, the data-in-flight on the first leg of the journey (Client A to Server M) is protected via SMB Signing, and then it is protected via BitLocker as Data-in-Flight on the second leg of the journey (Server M to LUN X), and finally protected via Bit Locker as Data-at-Rest at the final location. Note that the server has to pay the encryption CPU tax twice for each transfer whenever these approaches are used in tandem.


Forewarned is Forearmed

I can’t tell you what the right answers are for your data center, but I can make sure that you are well informed to make a decision that can meet your needs while reducing any unwanted side effects. Selecting the wrong approach for securing your data may not just fail to meet your needs; it may also cripple your environment with performance degradation. For more information, check read this blog on NetApp Storage Encryption.