In version 6, IBM i introduced the capability to enact encryption across the entire disk drive. That means everything placed on the disk is first encrypted by the disk controller and then written out in that encrypted form. That happens seamlessly across the entire disk unit.
At first glance, this process appears very secure and gives a lot of IBM i pros the initial gut feeling that this is the answer to your encryption needs. One of the benefits is that disk encryption is extremely quick. Most IBM i Power Systems servers have crypto processors built into them or they have disk controller cards that are handling the encryption function at a hardware level, which is generally the fastest way to do any encryption and decryption functions.
A common question is whether encryption has an impact on system performance. Typically the answer is yes, the impact on performance is at least worthy of consideration. But when it comes down to encrypting at the hardware level—arguably the lowest level we can got to—the impact is negligible.
The other factor that bodes well for disk encryption is that the encryption is completely non-invasive. If we make changes to the application or to the database structure in order to accommodate some of the encrypted form, then that’s an invasive function. Most of us don’t want to do that. With full disk encryption, all of that is happening down in the disk controller. The application and the database have no interaction with or no visibility to the encryption going on behind the scenes.
Because of these factors, disk encryption seems plausible. The fact that it can be done seamlessly and quickly make disk encryption an appealing approach.
But we need to dig deeper.
If you’re using internal disk (drives within the chassis of the server itself), full disk encryption has limited benefit. Yes, it’s fast and non-invasive. It will potentially get you the box checked for a compliance mandates that simply says you must encrypt data.
If, however, you’re using external disk—some type of storage area network (SAN)—where the physical drive units are in a different location from the disk controller, then full disk encryption is extremely beneficial. What happens is that the encryption travels down the wire. If someone intercepts that wire, everything that came out of the back of the box was in an encrypted form. If you have a server with the capability of encrypting disk and you don’t have to invest in anything, why not take advantage of this feature?
So, yes, full disk encryption has benefits. But is it the magic solution that meets all of our encryption needs? No. The encryption and decryption functions happen without any interaction with the application or the OS. Encryption happens any time a disk write happens and decryption happens any time a read occurs. The problem is that there’s no differentiation between people who are performing authorized functions (such as running the approved business applications, or doing an FTP or ODBC connection) and people who are performing unauthorized functions.
The data is fed in and out without any decision-making or conditions associated with the encryption. That means that if you have authorized access or unauthorized access, the operating system doesn’t care. It simply provides the clear text version of that data, regardless of the interface being used. It’s totally transparent. From a security standpoint, we want decisions to be made as to whether the user has access to the clear text version of that data, rather than just handing it to that user.
Full disk encryption has value, but it’s not the answer most organizations are looking for. If data protection is the reason why you’re considering encryption, full disk encryption does not provide all the benefits most IT pros want or expect.