As part of a total environment refresh project I've been involved with, to include new encryption capability, I've been deeply involved with trying to understand the data encryption options for both FAS and E-series. Here is some information I hope helps you.
First - both storage platforms rely on full disk encryption (FDE) capable disks. Data is not encrypted external to the disk drive itself - this is truely data at rest only. Once in the controller or on the network, data is not encrypted.
The nice things about FDE disks is that since the encryption engine is built into the disk itself, all encryption takes place at or near wire speed to the disk. Hence there is no single bottleneck to performance and there is no expectation that an encrypted solution will perform differently than an unencrypted solution using the same basic hardware. Granted, the encryption capable disks will cost more, and there are other add-ons for both platforms as well. But, since controllers don't see encrypted data, all controller based features just work. This is significantly important for FAS controllers to allow DoT features like compression and deduplication to be transparent.
FDE disks require a key to be generated and loaded down to the disk to enable encryption of data on the way to the disk platters and to decrypt on the way from the disk platters. Here is where the platforms diverge. E-Series platforms with the encryption license option allow an administrater to manually set (generate) a single encryption key which is used for all the disks. Additionally, E-Series only requires basic FDE capable disks which are available in a ton of sizes from 600GB -1.2TB performance, 800GB and up SSDs, and the usual capacity sizes up to 6TB disks. Very flexible if it meets the needs to, generally, protect data when a disk goes out of service, for instance, or from someone stealing a disk or a shelf.
The FAS platform takes a different take. Rather than just encrypt on FDE disks, the FAS encryption platform is FIPS 140 standard compliant, for government use and for other regulated industries. This adds a lserious layer of complexity. For starters, the disks themselves must be certified to the FIPS standards which means the drive needs to hardend against intrusion, should destory itself if penetrated, and should show external indicators if physical intrusion was attempted. At the platform level, each disk gets a separate encryption key, and the keys need to managed by a FIPS compliant key manager. That is where the SafeNet devices come in - they aren't encryption platforms, they are key managers. All they store are the keys to the drives. When an encrypted FAS platform starts, which NetApp refers to as NetApp Storage Encryption (NSE), the controller knows as it boots that it is in encrypted mode, contacts the key manager securely using SSL with known certificates and key pairs at a known address over a specific known port again all set as options before DoT boots, downloads the keys for all the disk drives, and pushes those keys out to each drive. Only then does it start accessing the data on the disks because once the key is reloaded on each disk the data can be decrypted.
The FAS solution is arguably more secure and meets certain high end certifications that allow it to be used in regulated areas (government, industries) around the world. It is also massively more complex and expensive to deploy and operate. For example, there are only a limited set of FIPS compliant disk drives comonly available from multiple drive manufactureres. Hence, in an NSE solution you are limited to 900GB SAS disks and 800GB SSDs in a DS2246 and 4TB NL-SAS in DS4246 shelves. Note that you can't use DS4486's if you want density. Further - if a FAS controller (single or HA pair) uses encryption all disks attached to the controller must use encryption. Spare replacements require manual intervention to set a key for the disk - no autoassign at controller/shelf level and it's just ready as a spare. And the officially supported Safenet appliances are really expensive comparatively and of course you need at least two to protect the keys - lose the keys and you're out of luck. And during upgrades and hardware maintenance (like motherboard replacements, head replacements, etc.) there are all kinds of extra steps you need to consider to ensure you don't lose the relationship between the controllers, the key managers, and the disks. But if you need that FIPS certification, you need it and at the moment from NetApp there isn't any other choice.
The E-series is more flexible. Obviously there are more disk options. I *believe* that you can encrypt some of the disks but not all if you've deployed mixed disk types, but I think it's all or none within a single shelf unit. Replacements are automatically set for encryption since the controller holds the key. New controller, lost configuration? Just restore the single encryption key. So way easier - just not going to meet the FIPS standards. And of course E-series is block protocols only.
One mechanism to leverage easier encryption and full DoT capabilities is to use E-Series with encryption behind FAS heads with the FlexArray (formerly the old VSeries controllers, now just a license option on FAS). When considering encryption we speced it out both ways - performance was not an issue (the E-Series are really very good at what they do block wise). Total rack space for our example was significantly less because we could use both higher density shelves and higher density disks on the E-Series so at scale the differences got where pronounced quickly.
NetApp does not offer any product similar to the old Decru Datafort that encrypts in transit on the wire. In fact it doesn't make sense for them to do so with the advent of FDE capable disks. Rather all encryption is not a part of the storage platform rather than being external to it. Practically speaking within the data center at least encryption in transit (network/SAN) is less of a concern anyway. If someone breaks into your data center to apply a tap on the wire to intercept data, or if one of your employees does it internally, you have a larger problem that basic encryption is not going to solve. If someone gains access to servers, well then they have credentials to potentially request the data on the server in a decrypted form. Again - a different problem. Unless the data is encrypted up to the point where it is displayed to the target user, data is vulnerable somewhere in your system to anyone who can enter with the right access or credential. Even in a completely end to end encryption mechanism, data remains vulnerable to someone with an unauthorized credential. Encryption may reduce the potential attack vectors, but as you add more you add cost and complexity without necessarily reducing the primary attack vectors (consider Sony - an inside job).
Hope this helps you while considering encryption.
Bob Greenwald
Lead Storage Engineer | Huron Legal
Huron Consulting Group
NCDA | NCIE-SAN Clustered Data OnTap
- Products and Services
- General Discussion & Community Support
- Developer Network
- NetApp Learning Services
- Blogs
