Db2 Encryption
Introduction
Does Encryption need an introduction? Or are we all already aware of the dangers of keeping your stuff unprotected?
Leaving your database not encrypted (and publicly accessible) is just like parking your car in a public car park and leaving the keys in the ignition and the windows wide open – how long will it remain “your” car?
Db2 Encryption
There are fundamentally two types of data encryption in the Db2 universe – the first which deals with the data stored on your disks (“at rest”) and the second which takes care of the data coming in and out of your database (“in transit”).
To effectively protect your database against various threats, you need to apply both to your databases.
Db2 Encryption at Rest
According to the IBM Documentation (formerly known as the “Db2 Knowledge Centre”), there are several options for encrypting your Db2 data at rest:
- Db2 native encryption
Db2native encryption provides a built-in encryption capability to protect database backup images and key database files from inappropriate access while they are at rest on external storage media.
This option is included in Db2 v11.5 and is completely free. - IBM InfoSphere Guardium Data Encryption for encryption of data at rest
IBM InfoSphere Guardium Data Encryption is a comprehensive software data security solution that when used in conjunction with native Db2security provides effective protection of the data and the database application against a broad array of threats.
This is a separate product requiring its own licences, so will not be discussed further here. - Database encryption using AIX encrypted file system (EFS)
If you are running a Db2system on the AIX® operating system, you have the option to set up an encrypted database by using AIX encrypted file system (EFS).
The same can be done on other platforms – for example, using Linux with encrypted disk volumes on AWS.
Db2 Native Encryption
In IBM’s words, Db2 native encryption provides a built-in encryption capability to protect database backup images and key database files from inappropriate access while they are at rest on external storage media.
Db2 native encryption features:
- simple deployment
- does not require changes to the data schema or database applications
- free use on all supported Db2 platforms and configurations.
The encryption capabilities that are used by Db2 are FIPS 140-2 certified and employ NIST SP 800-131A compliant cryptographic algorithms. Db2 also automatically detects and uses any underlying CPU hardware acceleration for encryption when available.
When you encrypt a database, Db2 native encryption protects all files that contain your data, such as:
- All table spaces (both system-defined and user-defined)
- All types of data in a table space (including LOB and XML data types)
- All transaction logs, including archived log files
- LOAD COPY data
- LOAD staging files
Db2 native encryption uses a two-tier approach to data encryption. Data is encrypted with a Data Encryption Key (DEK), which is in turn encrypted with a Master Key (MK). The encrypted DEK is stored with the data while the MK is stored in a keystore external to Db2.
Db2 native encryption ensures that the DEK is never exposed outside of the encrypted database, transaction log, or backup file. There are no interfaces provided to access the DEK in either its clear text or encrypted forms. As the MK is stored in a different location from the encrypted data, the chance of the encrypted DEK being concurrently exposed with the MK used to encrypt it is very unlikely. Since the risk of the DEK being exposed is extremely low, the need to rotate it is negligible. The rotation of the MK, which is used to protect the DEK, can be done efficiently without the need to decrypt and re-encrypt the data
Data Encryption Key (DEK)
Db2 encrypts data with a data encryption key (DEK) before the data is written to disk. The DEK is stored, and encrypted by the master key (MK), within the database or backup image. The DEK itself is generated by Db2 as needed, such as when an encrypted database or encrypted database backup is created. A unique DEK exists for each encrypted database and each encrypted backup.
Master Key (MK)
A master key (MK) is an encryption key that is used to encrypt a data encryption key (DEK). Each encrypted database is associated with one master key at one time. Unless directed otherwise, Db2 generates an MK automatically during these operations:
- Database creation
- Master key rotation
- Restoring into a new database
What if I just want to encrypt my backup?
No worries, Db2 native encryption can also be used to encrypt database backups, even if the source database is not encrypted.
The way to do that is to run the BACKUP command with the following (additional) parameter:
Db2 BACKUP DB … ENCRYPT [ENCRLIB name] …
(More details in the Db2 Docs)
But remember, even if your whole database is encrypted, you still must use this same option to get an encrypted backup. Not sure why this is so, but it clearly says in the Db2 docs: “For databases that are natively encrypted, data is decrypted before backup”?!
Also worth noting: you cannot use both the compression and the encryption at the same time, but only one of them. So, choose wisely 😊
Db2 Encryption in Transit
Db2 uses the Transport Layer Security (TLS) protocol (an enhanced version of SSL) to securely transfer the data from and to the database.
TLS can be used to protect data in transit on all networks that use TCP/IP and is reasonably easy to set up. There are several different configuration options to choose from (using a self-signed certificate; using a CA-signed certificate; using a certificate chain) and if you want to learn all the details, please consult the Db2 documentation at this link, where you will also find useful information on how to configure TLS for Db2 clients, primary/standby HADR servers and the Federation Server.
Here’s a quick overview of how to configure TLS using a self-signed certificate (again, more details in the above link!):
- Create a keystore with GSKit
Run the command gsk8capicmd_64 (part of the GSKit tool) to create a keystore for storing the digital certificate and private key for the Db2 server. - Create a self-signed certificate with GSKit
Create a self-signed certificate by specifying a label, the path to the key database, a distinguished name for the certificate, and other values with the GSKit command gsk8capicmd_64. - Distribute a self-signed certificate to your Db2 clients
Again, use the GSKit command gsk8capicmd_64 to extract a self-signed certificate to a Base64-encoded certificate file. Then distribute this file to your Db2 client computers, for establishing secure TLS connections to your Db2 server. - Configure TLS support on a Db2 server
After creating the keystore and digital certificate, and distributing the certificate to the Db2 client machines, TLS support can be configured on the Db2 server.
Configuration is done by updating the relevant Database Manager configuration parameters.
And that’s basically it, by having done all the above, your database will be securely encrypted from all sides and aspects.
Authentication
To conclude this article, I feel that I need to say a word or two about the Db2 authentication methods, as well as user passwords, both used to grant access to your nicely encrypted Db2 database.
No amount of encryption will protect the data in your databases if your password policy is loose, or even worse – non-existent.
And yet, in my DBA consultant career, I have encountered quite a few Db2 environments where precisely that is the case.
Here are just a few examples to illustrate the point:
- DBAdmin password is a simple string (easy to remember, but also easy to guess)
- DBAdmin password never changes
- All Db2 instances (DEV, TEST, PRE, PROD) share the same DBAdmin password
- DBAdmin password is freely distributed within the company
Any John or Jane Doe can drop a table in your database (not to mention the whole database), if they can connect to it with the DBADM privilege, regardless of the level of data encryption.
And even if the named perpetrators don’t have any malicious intentions, still I have seen it more than once with my own bare eyes, when a developer executed something very disruptive in a live production database, thinking they were connected to the DEV database (because the same credentials work in both cases and it’s too easy to make a mistake), completely oblivious of the impending doom 😬
(if you’re a command-line person like myself, then this blog will show you how to put some colour in your command-line prompt and make it less likely to execute commands in the wrong environment).
Therefore, remember your password and authentication policies when you’re preparing for database encryption!
This article does not cover native media based Encryption (Disk or Tape) which is totally transparent and gas no CPU cost.
Security that maters to business is about who can access what regardless if this is achieved by encryption or otherwise.
You are quite right, this article does not talk much about native media encryption, mostly because that topic is very platform dependent and will therefore vary from case to case (although the article briefly mentions this option, under “Encryption at rest – AIX EFS”). It rather concentrates on the options readily available within Db2, universal to all clients.
The business security is all about allowing access (to individuals and/or groups) to some resources, as you said, and at the same time denying access to other resources, and the encryption is just one layer of the whole process.