Carnival: Even DB2 Wears a Mask (Database Security)

Data Privacy and Security

Right now we are in the hot phase of the carnival season. Many people are wearing masks. Some move into other characters, some just hide their real identity. Did you know that DB2 is also in the mood for carnival and wears a mask? Here is what my DB2 is doing these days...




With carnival around and April Fools' Day approaching quickly, one of my recent DB2 experiments centered around how to put one of the DB2 security features to good use (as always).You probably have heard that DB2 offers data masking to protect sensitive data from unauthorized access. It is part of the Row and Column Access Control (RCAC) feature. By using CREATE MASK it is possible to define rules how a column value should be returned. Confidential employee data could only be accessible to the HR department, design data only to those engineers needing access. Masking is orthogonal to data encryption, they complement each other and have different use cases.

For my experiment I created a table with highly confidential data:
DB: HLTEST => create table highconf(empid int, salary dec(12,2))
DB20000I  The SQL command completed successfully.
Then I inserted some sample data into it:
DB: HLTEST => insert into highconf values(1,'2000.00')
DB20000I  The SQL command completed successfully.
DB: HLTEST => insert into highconf values(2,'5222.77')
DB20000I  The SQL command completed successfully.
Most of the examples around column access control focus on checking user groups and roles to determine what data to return. I tried a different approach by using the date. How about reporting different salaries on April Fools' Day? Easy:
DB: HLTEST => create mask nice_salary on highconf for column salary return case when current date='2017-04-01' then salary*2 else salary end enable
DB20000I  The SQL command completed successfully.
DB: HLTEST => alter table highconf activate column access control
DB20000I  The SQL command completed successfully.

In the mask defined above DB2 checks the current data and either returns the double salary or, as default, the regular values. The ALTER TABLE statement activates the mask. Everything will look normal before and after the special day:

DB: HLTEST => select * from tmask

EMPID       SALARY       
----------- --------------
          1        2000.00
          2        5222.77

  2 record(s) selected.

By changing the date on my machine (or just changing the mask definition to the current date...) I could verify that my mask works as planned:
DB: HLTEST => select * from tmask

EMPID       SALARY       
----------- --------------
          1        4000.00
          2       10445.54

  2 record(s) selected.

A high salary is reported when the condition is true.

Masks are different to database views because users continue to operate on the same table. Masks are transparent to the regular user. With that capability comes the need for responsibility and compliance for those being able to use masks. Only security administrators (SECADM privilege) are allowed to create masks. It is an action that should be audited for compliance reasons. It is similar to carnival and April Fools' Day where you are still responsible for your actions.

Have fun nonetheless!