DB2 for LUW Label-Based Access Control

Last week, I delivered a presentation on DB2 "ultra-availability" at a meeting of SIRDUG, the DB2 regional user group (RUG) in Charlotte, North Carolina, USA. One of the things that I really like about presenting at RUG meetings is hearing what other presenters on the agenda have to say. At the SIRDUG meeting I was treated to a very interesting presentation on DB2 for Linux/UNIX/Windows (LUW) label-based access control (aka LBAC - introduced with DB2 for LUW V9.1 and enhanced in DB2 V9.5). The presenter was Roger Sanders, a well-known DB2 author and consultant who recently joined the team at EMC.

I'd heard of label-based access control, but I hadn't thought much about how organizations would leverage the technology to their advantage (I was more focused on other capabilities of DB2 V9 for LUW, such as pureXML and Deep Compression). Roger's presentation opened my eyes.

I won't try to provide in this post the comprehensive overview of DB2 V9 LBAC contained in Roger's presentation (he'll be presenting it at the 2008 IDUG North American Conference in May, and he covered the topic in an article published last year in DB2 Magazine), but I'll give you a real-world example of a data protection situation that could be handled in an effective, robust, and straightforward way with DB2 LBAC, and which otherwise would pose a considerable challenge.

Consider a company's customer care application. The data for this application is stored in a relational database, and in that database is a table with lots of data rows. Some of the rows in the table can be viewed by customer care representatives (the people responding to phone calls from the organization's customers). Those plus some other rows can be viewed by the supervisors of the customer care reps. The Director of Customer Care Operations can view all the rows that are accessible to the Customer Care supervisors, plus additional rows.

Without LBAC, how would you deal with this situation? If the application SQL is dynamic, you could create a view for the customer care reps that excludes rows (and maybe columns, as well) that can't be accessed by this group of employees. You'd create another view for the supervisors, and another for the Director of Customer Care Operations. But the views can't all have the same fully qualified name, can they? So, you might use a different high-level qualifier for each of these views, and use fully-qualified names in the dynamic SQL statements (with the application providing the right high-level qualifier based on the user's ID). If the application SQL is static, you can again go with multiple views with differently-qualified names, but you can use unqualified view names in the application SQL statements if you bind programs once for each view (placing the packages in different collections whilst supplying for each the appropriate high-level qualifier via the QUALIFIER option of bind) and use SET CURRENT PACKAGESET to point to the right collection (and thus the right view) at execution time (again, this requires that the application recognize the user type and provide the appropriate collection name in the SET CURRENT PACKAGESET statement).

You could also do without the views and have the application handle the security. Basically, the code would check a DB2 table (or some file) to determine the role of a given user and, based on that, use one set of static SQL statements or another (or build dynamic SQL statements of one type or another) so that restricted rows (and columns, if applicable) are not presented to the user.

There is a hassle factor for each of these approaches. Use of views means more work for DBAs, and application-based security puts more on the plate of developers who'd prefer to work on business functionality versus who-can-do-what logic (and who don't want to be concerned with different object qualifiers for different users if views are used). More important than the hassle factor is the lack of real robustness inherent in these solutions. The application-based approach to security makes an internal breach possible due to the malevolent coding of a disgruntled developer. Both the application-based and view-based approaches overlook the fact that certain DB2 support people - such as those with SYSADM or DBADM authority - can view ALL OF THE ROWS in ANY table in the database. I'm sure that you trust your SYSADMs and DBADMs, and probably with good reason, but you should know (if you don't already) that many (if not most) serious data breaches result from the actions of company insiders.

Not a pretty picture. Now, add label-based access control to the mix. With LBAC, DB2 itself can have knowledge of an installation-defined hierarchy of user categories (a simple straight-line hierarchy or one of a more complex nature) that have different data access levels, or a non-hierarchical set of such categories. Not only that, but the DB2 database can contain information about several such user-category-based data access arrangements (referred to as "security label components" in LBAC lingo). Security policies that reference these security label components are defined, as are security labels that reference policies and elements of components. Security labels are assigned to rows in a table, and they are granted to users. Once this is done, when a user attempts to access a given row in an LBAC-protected table, such access will be allowed by DB2 only if the row's label protection matches up with the user's label (in addition to rows, table columns can be label-protected).

This may seem a little complicated at first, but a lot of that has to do with the new nomenclature that goes along with LBAC. Once you understand the terminology, it's fairly straightforward. Sure, there's up-front work to set this up, but once LBAC is in place for a database, ongoing maintenance is not an onerous task. And here's the really good part (depending on your point of view): data in an LBAC-protected table can't be accessed by ANY user lacking the required data access label, even if the user in question has SYSADM or DBADM authority. Furthermore, the ability to create and change LBAC-related controls does not belong by default to a DBADM or even to a SYSADM. LBAC set-up and administration is associated with a new DB2 authority type called Security Administrator, or SECADM for short. And, while a SECADM can set up LBAC security for a database, a person with SECADM authority cannot, by default, read any data in any table. It's truly a separation of control over data access from data access itself, and that can significantly reduce the threat of data security breaches for an organization.

I expect that data privacy and security people are going to eat this up (as DB2 for LUW V9 has been pretty widely implemented, I imagine that some organizations are already benefiting - in terms of less sleep lost over worries about data protection - from the LBAC advantage).

Hats off, again, to the folks at IBM's Toronto Lab (home of DB2 for Linux, UNIX, and Windows). LBAC is powerful stuff for the security-minded.