Now that you’ve streamlined your database, gotten rid of unnecessary columns and/or tables, and moved all or at least part of the data validation code out of your programs, you’re ready to dive a little deeper into DB2’s advanced functionalities.

The previous TechTips explained how to convert your files’ definitions from DDS to DDL and how to move business validations to the database (or at least, to a separate piece of code, an I/O Server). Now let’s see how you can take advantage of some of DB2’s advanced functionalities. I’ll introduce just two, but there’s a lot to explore, so dig into IBM’s DB2 Reference Manual and find out what goodies you can use in your application’s context.

Step Three: Taking Advantage of DB2’s Advanced Functionalities

IBM has been focusing on DB2 as “the way to move forward” in terms of security and performance, among other things. These are indeed the hottest topics today, so IBM’s choice makes perfect sense, in my opinion. That’s why I’ll talk a bit about those two topics and how you can, with fairly simple changes to your database, achieve interesting results.

Let’s start with security. Before everything was connected to the Internet, data security was often seen as physical security, based on doors, locks, and security guards. Today, data security means something different. It’s not that the physical security has lost its usefulness; it’s just that the threats have changed to become more electronic and less physical. That’s why logical security is so important, based on security levels and encryption. Let’s focus on those two aspects, starting with security levels.

If you’re familiar with IBM i’s authorization model, you know how you can secure your objects from prying eyes and idle fingers. What you might not know is that you can do the same for columns in SQL tables. This is something you simply can’t do in a physical or logical file. Using SQL’s GRANT and REVOKE instructions, you can authorize a user or a group of users differentiated access to specific columns in your tables.

Imagine, for example, that you want user BOSS to be the only one to manipulate the data in the BASE_SALARY column of the EMPLOYEE_MASTER table. You’d start by revoking existing update authorizations, using the following statement:

REVOKE UPDATE(BASE_SALARY) ON EMPLOYEE_MASTER FROM PUBLIC

Then, you’d grant access to the BOSS user, like this:

GRANT UPDATE(BASE_SALARY) ON EMPLOYEE_MASTER TO BOSS

However, users with access to the EMPLOYEE_MASTER table would still be able to see the contents of BASE_SALARY. Therefore, if security was somehow breached, an intruder could see the base salary of the employees. DB2 provides an elegant solution for this type of problem: column-level encryption.

DB2’s Column-Leven Encryption

Starting with V5R3, DB2 includes encryption and decryption column functions so that programmers do not have to write their own encryption routines. Underneath the covers, the DB2 Encrypt and Decrypt scalar functions use the IBM Cryptographic Access Provider 128-bit licensed program (5722-AC3) to add another layer of security around your data. However, there are specific data types and lengths requirements that must be met in order to use the Encryption column function. This is because the encrypted version of the data will be a binary value and longer than the original data string. The data types must be one of the following:

• BINARY, VARBINARY
• CHAR FOR BIT DATA, VARCHAR FOR BIT DATA
• BLOB

For instance, the length of an encrypted string value is the actual string length plus an extra eight bytes (or 16 bytes, if BLOB or different CCSID values are used for the input) and must be rounded to an eight-byte boundary. Up to 32 bytes of hint data can optionally be added and stored with an encrypted value.

Let’s see how the base salary scenario can be solved. During the creation of the table, you’d add a SET ENCRYPTION PASSWORD instruction to the CREATE TABLE:

CREATE TABLE MYAPPDB/EMPLOYEE_MASTER

      ( (some columns here) (…)

      , BASE_SALARY VARCHAR(21) FOR BIT DATA

      , (…) (more columns here) )

      SET ENCRYPTION PASSWORD = <your password here>

      WITH HINT = <your hint here>

Then the insertion of a new record, performed by an I/O server for instance, would look something like this:

INSERT INTO MYAPPDB/EMPLOYEE_MASTER

      VALUES(

            (some columns here) (…)

            , ENCRYPT(<Base salary amount>)

            , (…) (more columns here) )

Now, to see the base salary amount, you need to decrypt it first:

SELECT

      DECRYPT_CHAR(BASE_SALARY, <the password here>)

      , (…) (more columns here)

FROM MYAPPDB/EMPLOYEE_MASTER

As you can see, this is fairly simple to implement, and it’s a good solution when you know your database. It’s true that it can get a bit tiresome when you need to protect multiple columns across several tables, but it’s free, thoroughly tested, and supported by IBM!