Data Security: What Does it Mean to You, to Your Customer, to Your Auditor and to DB2?

Next to performance and new features, the topic of security and security improvements might not be flashy. That doesn’t mean it shouldn’t be important to a database administrator. Determining who has and maybe more importantly, who does not have access to data, is vital to the integrity of data.

Within DB2 for z/OS, there have always been two major types of customers.  The first type uses native DB2 security; the second type uses an external security module like RACF, ACF2, etc.  With the recent data security evolution and increasing need for better security, dividing DB2 shops up in just those two categories would no longer do justice to the issues most of us are facing when it comes to security.  Reviewing your data security strategy should be incorporated in the entire security strategy and the data management handling of your company (e.g. legal requirements, customer satisfaction etc.). If you haven’t reviewed the correct way to handle your data security, then allow me to point you to a presentation that was delivered at the 2011 IDUG DB2 Tech Conference in Prague  by Michael Dewert: “Modernizing Your DB2 for z/OS Security Set-Up.”

For those of you that are using native DB2 security, there have been a lot of security improvements in the last versions of DB2 for z/OS. Version 9 gave us the possibility to work with roles and trusted contexts.  It allows us to better control “who does what when.”  A customer decided (after a human error) that their DBAs should no longer have DBADM rights in production all the time. Aside from incident type exceptions, their database administrators now only have DBADM rights in production during certain weekends of the year.  In order to pull this off they are using a combination of roles and trusted contexts. Well beyond that, trusted context and roles are often used to improve the application server – database server connection. If you choose to place your security in RACF, DB2 version 9 brought important improvements for you as well. Version 9 brought the possibility to promote the RACF ID to improve end-to-end auditing.  To refresh your memory of the possibilities in DB2 version 9, I like to refer you to a presentation that was given by Jim Pickel both at IDUG DB2 Tech Conference in Warsaw and the IDUG DB2 Tech Conference in Dallas in 2008: “Best security practices in DB2 9.”

DB2 10 brought even more possibilities, the most important one being the segregation of duties.  It is without a doubt a security “no-no” to allow user access to the resource and to control own access level.  This has been the situation within DB2 for years: system administrators and database administrators both having access to the data and controlling access to the data.

Recent legislation (e.g Sarbanes Oxley act, 2002) regulated data access and manipulations and its auditing. This brought on new challenges to balance flexibility and manageability on one hand and SOX-compliancy on the other hand. To give you some fresh ideas on this topic have a look at an IDUG user session by the folks of Progressive: “24/7 Environment, Need to Update Production Data? Audit, Data Security & SOX Compliance FEARS!!!”

To better address the separation of duties, DB2 10 brought full native SECADM support, privileged users without data access support, auditing of those privileged users masking of data and many more.  I won’t go into more detail as all of this and more has been fabulously explained by Jim Pickel at IDUG DB2 Tech Conference In Tampa and the IDUG DB2 Tech Conference in Vienna in 2010 in “Security DB2 10 z/OS Presentation.”  Or, if you are looking at a security project in your close future, get the full detail in the IBM Redbook: “Security Functions of IBM DB2 10 for z/OS.”

DB2 also has a good interaction with external security products such as Kerberos and RACF. The Kerberos solution might be something that quite bit of us are facing, so give the following presentation by Davy Goethals a view:  “Connectivity to z/OS using DB2 Connect with Kerberos Authentication” or listen to the audio recording of this session from the IDUG DB2 Tech Conference in Warsaw in 2008.  Or maybe your shop is looking to extract its native DB2 security and migrate it to RACF, what will be the impact, how you start it.  Pete Suhner explains in “Migration of DB2 Access Control from DB2 to RACF.”  Expect to see some improvements in the access control exit of RACF in DB2 11, as mentioned in session B07 of the most recent IDUG DB2 Tech Conference in Orlando  by Jeff Josten: “ DB2 for z/OS: Latest News and Futures.”

Although security might not be fun or flashy for many of us, it is and becomes ever more important.  With outside threats, inside data leaks and legislative requirements data security is not something to be ignored. That’s why at IDUG we spend quite a bit of time discussing it.  Stay safe!

1 Like
Recent Stories
An Introduction to IBM Data Studio

The Basics of SQL Performance and Performance Tuning

Index Decluttering Opportunities in DB2 for Linux, UNIX, and Windows