A DB2 release that doubles down on data protection
Security threats are always a critical consideration when upgrading software. IBM DB2 for Linux, Unix and Windows (LUW) Version 11.1 contains several new features that help ensure data is well protected from both internal and external threats. Take an in-depth look at the security enhancements that are available with this DB2 release.
DB2 native encryption
Encryption is the process of transforming data into an unintelligible form to prevent it from being accessed by unauthorized users. A special decryption algorithm and a unique key allow only authorized users to access the data in an intelligible form. The key is a random string of bits that is used explicitly for scrambling and unscrambling data.
Encryption is mandatory for compliance with many government regulations and industry standards because it offers an effective way of protecting sensitive information that is stored on electronic media or transmitted through untrusted communication channels. Consequently, to help organizations meet compliance guidelines, new encryption technology known as DB2 Native Encryption, was delivered in IBM DB2 10.5, Fix Pack 5.
DB2 Native Encryption meets the requirements outlined in the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-131 for cryptographic algorithms; it also utilizes Federal Information Processing Standard (FIPS) 140-2–certified cryptographic libraries. In addition, DB2 Native Encryption employs a standard two-tier model for key management: one key, referred to as the Data Encryption Key (DEK) constitutes the first tier; another key known as the Master Key (MK) acts as the second.
The DEK performs the data encryption and decryption. The MK encrypts the DEK. Encrypted DEKs are stored in the appropriate encrypted database or encrypted backup image, while MKs are stored outside the database—but on the database server—in a local Public-Key Cryptography Standards (PKCS) #12–compliant keystore file. File permissions, together with a keystore password, control who can access the MKs stored in the keystore file.
Enterprise Master Key management
DB2 for LUW Version 11.1 extends the DB2 Native Encryption solution by adding support for storing and managing MKs with a Key Management Interoperability Protocol (KMIP) 1.1 standard–compliant keystore such as IBM Security Key Lifecycle Manager (ISKLM). This keystore enables DB2 for LUW to participate in an enterprise-level key management strategy. Consequently, an organization using a KMIP-compliant keystore to manage MKs for its file system encryption, for example, can use the same keystore to manage all of the MKs that are used by DB2 Native Encryption.
Setting up DB2 for LUW Version 11.1 to interact with a KMIP-compliant keystore is relatively easy. You simply assign the value
KMIP to the keystore_type configuration parameter for the database that is to be encrypted. Then, you assign the name of a flat file that contains information such as the host name or IP address of the KMIP-compliant keystore and the absolute path and name of the local keystore file that holds the Secure Sockets Layer (SSL) certificates. These certificates are needed for communication between the DB2 server and the centralized key manager to the keystore_location database configuration parameter. You may also need to configure an SSL connection for the KMIP-compliant keystore to facilitate the secure transfer of master keys across the network. Take a look at how DB2 Native Encryption works with a centralized, KMIP-compliant keystore:
If you’re currently using a local keystore file to store encryption MKs and you would like to use a KMIP-compliant keystore instead, you can use the
db2p12tokmip utility or command to make the desired conversion after upgrading to DB2 for LUW Version 11.1. This DB2 release also provides a technology preview of the capability to store and manage MKs using a Hardware Security Module (HSM). An HSM is a physical computing device that safeguards and manages digital keys. Traditionally, these modules come in the form of a plug-in card or an external device that attaches directly to a computer or network server. Each module contains one or more secure cryptoprocessor chips to prevent tampering and bus probing.
The technology preview provided with DB2 for LUW Version 11.1 is designed to work with HSMs that interface with a Public Key Cryptography Standards 11 (PCKS#11) vendor client, such as SafeNet Luna SA. Take a look at how DB2 Native Encryption works when an HSA is used to store and manage keys:
A technology preview is intended to provide a sample of future capability that may or may not materialize and is important to note. At this time, the technology is not currently supported and is not recommended for production use.
Hardware encryption acceleration
KMIP-compliant keystore support is not the only security enhancement available in DB2 for LUW Version 11.1. If you are using DB2 Native Encryption on the IBM POWER8 architecture, DB2 for LUW Version 11.1 can take advantage of the hardware encryption acceleration that is available with this processor. POWER8 processor–based systems offer in-core Advanced Encryption Standard (AES) and Secure Hash Algorithm (SHA) instructions that are compliant with FIPS 197: AES Specification and FIPS 180: Secure Hash Standard. By taking advantage of this feature, a significant improvement in performance can be seen when workloads are executed against encrypted databases.
SSL support for disaster recovery
High availability disaster recovery (HADR) is a DB2 database replication feature that provides a high availability solution for both partial and complete site failures. HADR protects against data loss by replicating data changes from a source database, called the primary database, to a target database, called the standby database. In an HADR environment, applications can access the current primary database—synchronization with the standby database occurs by rolling forward transaction log data that is generated on the primary database and shipped to the standby database. With HADR, you can choose the level of protection from potential loss of data that you want by specifying one of four synchronization modes: synchronous, near synchronous, asynchronous and super asynchronous.
Because HADR uses TCP/IP to communicate between a primary and a standby database, the databases can reside in two different locations. For example, the primary database might be located at your head office in one city, while your standby database is located at your sales office in another. If a disaster occurs at the primary site, data availability is maintained by having the remote standby database take over as the primary database.
When implementing DB2 for LUW Version V11.1, you can use SSL technology to secure TCP/IP communications and encrypt the data motion between the primary and the standby server—but only if you have DB2 deployed on an x86 Linux system. SSL is a standard security protocol that is used to establish an encrypted link between a client and a server; it provides both data encryption and data integrity. SSL utilizes industry standard encryption technology such as AES cipher or the Triple Data Encryption Standard (3DES) cipher with 128-bit, or more, keys.
Other DB2 advances to explore
Stay tuned for upcoming posts for more information about the release of DB2 Linux, UNIX and Windows Version 11.1. Also, watch a DB2 technology review webinar, and continue your research on the next-generation database software by downloading a 90-day trial.