Locking It Down

Capitalize on data security features available in DB2 for z/OS for rock-solid protection

Securing data is more important now than ever before. There are, of course, the always more-stringent government regulations pertaining to the protection of various categories of data—two examples are credit card and healthcare records. In addition, there is the public-trust factor. With companies doing increasing volumes of business with customers through the Internet, client confidence in the security of their data on vendors’ systems is a critical success factor. A widely publicized data breach can result in a significant loss of revenue.

IBM® System z® servers, together with the IBM DB2® for z/OS® database management system, have long been viewed as setting a very high standard with regard to data security. But organizations deploying mainframes still need to be vigilant about raising their game in today’s high-stakes data protection arena. Fortunately, security-related enhancements delivered in the past two releases of DB2 for z/OS—Versions 9 and 10—allow them to do just that. Organizations not leveraging these capabilities could be missing out on great opportunities to achieve an advanced level of data lockdown.


Controlling who can see what

Several recently introduced DB2 for z/OS capabilities are available to help strengthen the vault that protects an organization’s most important data assets. The toolkit includes roles and trusted contexts, permissions and masks for row- and column-level data security, and super-user access controls. Brief descriptions of these capabilities follow.

Roles and trusted contexts

A lot of DB2 for z/OS data access is through client/server applications that connect to DB2 from network-attached application servers. These applications typically use Java Database Connectivity (JDBC) or Open Database Connectivity (ODBC) for data requests, and that means dynamic SQL on the DB2 server. Successful execution of those statements depends on an application’s DB2 authorization ID having the necessary table-access privileges. Roles and trusted contexts, introduced with DB2 Version 9, help to prevent unauthorized use of an application’s DB2 authorization ID and password by someone who might know them.

This security feature is activated through a two-step procedure: first, create a role and grant to it the DB2 privileges required by the application. Then create a trusted context that restricts use of the role’s privileges to the application’s DB2 authorization ID—and only when a DB2 connection using that ID is requested from the IP address, or addresses, of the server, or servers, running the application.

Permissions and masks for row- and column-level data access control

There are two common security requirements for data access control: limiting access to rows in a table for a certain group of end users and masking data values in particular columns of a table for a certain groups of end users. An example of limiting end-user access to rows is allowing employees in a bank branch to view only those rows in a table that pertain to their branch. An example of masking data in specific columns is allowing some end users to see a number, 1–4, indicating a quartile into which account holders’ income falls, instead of seeing actual client income figures.

Historically, these requirements have been addressed by so-called security views, an approach that can become unwieldy as data access control rules multiply. The row-permission and column-mask capabilities that are available in DB2 Version 10 offer a way to implement row- and column-level data access controls that can be much easier to manage than security views. One advantage of this approach is that it allows end users and application programmers to access a target table by its real name versus having to use the names associated with security views defined on the table.

Super-user data access controls

Many security administrators worry about access to data that comes with so-called super-user status. In a DB2 for z/OS context, super-user generally refers to those with SYSADM or DBADM authority. DB2 Version 10 addresses that concern in multiple ways. One important enhancement was the introduction of a new system DBADM authority, which provides DBADM privileges for all databases in a DB2 system. Previously, DBADM authority had to be granted on a database-by-database basis, and there can be many databases within one DB2 system.

The system DBADM authority can enable many organizations to significantly reduce the number of users with SYSADM authority. And if appropriate for an organization, system DBADM authority can be granted without access to data, so a database administrator (DBA) can have the privileges needed to manage databases but not be able to automatically view or change data in those databases.


Taking data security to another level

DB2 for z/OS is a tremendously secure data-serving system, which is one of the primary reasons why it is often the repository for key data assets of organizations around the world. Data protection is a highly sensitive issue for many companies. Organizations that have already implemented high-security data protection using DB2 and System z can make their data security infrastructure even more robust than ever before by taking advantage of these recent enhancements provided by DB2 Versions 9 and 10.

Additional details about these and other DB2 security management capabilities are available in the IBM DB2 10 for z/OS Information Center. Please share any thoughts or questions in the comments.