The need for good data security has probably never been as important as it is today. Besides the legal requirements, such as Sarbanes-Oxley or Basel II, companies are ever more aware of the risk and damage of a data leak. A breach in data security is not only embarrassing for a company, but it leads to enormous costs (notification campaigns, legal costs, etc.).
Before DB2 10, we had a set of tools to handle our DB2 security natively. We could work with grants and revokes to provide specific privileges to users or to hand out more administrative rights. As of DB2 9, we’ve already seen increased capabilities to limit access and further protect our data using “roles” and “trusted context.” However, a major issue remained unsolved: separation of duties using DB2 native security. The DBA in charge of database changes and with access to all data was also the person able to grant and revoke authorizations. We could get around that by externalizing our security (e.g. RACF, ACF2, etc.).
Starting with DB2 10, we can separate the different roles using nothing but DB2 native functions. You can easily start this behaviour by setting the DSNZPARM “SEPARATE_SECURITY = Y” and providing to install SECADM values. By starting DB2 with these values, it will separate database administration tasks and security. You can now handover the access control to your security officers and leave the database administration with your DBA. A logical consequence is that your SYSADM can no longer handle grant and revoke requests. This is something to consider when setting separate_security to “yes,” as you don’t want a subsystem without properly defined SECADM.
Besides the improved separation of duty, DB2 10 has many more useful security improvements. One of my favorites is the new “system DBADM.” In many companies, being a DBA means that you are an administrator for all databases and all projects. However, before DB2 10 that meant that the SYSADM had to grant DBADM at database creation to the correct groups/authids. With this new feature, you can grant the DBADM authorization on a system level - this is really cool.
Another feature, earning massive cool points is SQLADM. Before DB2 10, it was difficult having a developer running explains and interpreting the explain output in production because of the privileges required to do so; however, in DB2 10, we can grant a set of key developers SQLADM, allowing them to run explains, run statistics, etc. without the capability to access data.
The last wonderful DB2 10 feature that I want to briefly discuss is the possibility of the DB2 engine to include automatic masking. This can be extremely useful to protect your vulnerable, sensitive data. You define it at the table level once and you can activate it for certain roles in your organisation. And, if applicable, the optimizer will recognize the mask defined and activate the case expressions defined at a table level.
In the world of data security, the rule “to trust is good, to survey is better” should not be forgotten. With all these new features comes the possibility to better audit the use of special authorizations and thus closing the security circle.