IBM i 7.2 Tightens Data Access And Security

June 2, 2014 Dan Burger

Row column access control (RCAC) is the new set of security tools in town. They were released because the IBM midrange systems are not Fort Knox in a box. Even shops that have their security policies dialed in (and most of them don’t), RCAC, which became available in IBM i 7.2, is another layer of security that provides options to counter measures that are more expensive and detrimental to performance. If regulatory compliance concerns you, RCAC is particularly valuable.

Even if data leaks and security audits aren’t your biggest concerns, there are lessons that are better learned before trouble arrives rather than after.

Everyone has security issues to deal with, although many choose not to confront them. The reasons may be tied to a common belief that their systems are bullet proof or a willingness to just hope for the best.

Row column access control is probably going to be ignored by all the folks who pretty much ignore security. Companies that make security a priority will find RCAC functionality worth a closer look.

The companies that take security seriously understand they have applications containing data that should have limited exposure. Sometimes these applications have built-in security, but often they do not. In some situations security at the database level is a good choice, and other times it is not.

A company should examine its software, take into account the OS release it runs on, and make a decision to either move to 7.2 and use RCAC or find another answer, says Kent Milligan, a team member from IBM‘s DB2 for i Center of Excellence.

The complexity of a company’s security policy is going to be critical to determining whether row and column access controls are the proper solution from a performance perspective, he says. Adding extra security controls to a database can create unacceptable performance degradation.

“We think this reinforces the message that companies need a database engineer who stewards the database objects and definitions,” Milligan says, with the “we” referring to the team at the DB2 for i Center of Excellence. “A person who has a global view that if a certain change is made to the database the performance impacts will be taken into account. The RCAC allows simple security checks with the row permissions and column masks that won’t have a huge impact on performance. If the security policy is complex, someone should take a look at and compare performance when considering alternatives.”

Of course, if a company is not using security procedures or the procedures are minimal, then there’s a pretty good chance no one is paying attention to database performance.

“RCAC is meant to be an additional layer of security, just as field procedure encryption is,” Milligan says. “But without the foundation layer, which should be object-based security, additional layers are not making up for that. Without the object-based security implementation, it will probably cause the row permission definitions to be really complex because it will have to limit access by a larger number of users than if the foundation security was covering that. The more permutations of access, the more complex the RCAC becomes.”

RCAC should not be quickly dismissed as being inherently complex or that only those with a high level of database knowledge should attempt it. Those familiar with adding extra rules to database access will find this similar. Those unfamiliar with the database could find themselves defining a row of permissions with a dozen or more criteria checks without considering the performance drag those actions may be creating. The impacts aren’t always obvious until later.

“When security is enforced at the database as part of data-centric programming, it is there for all methods of interfacing with the database,” the DB2 for i expert says.

From Milligan’s perspective, RCAC will be an easy transition for companies already using SQL and data-centric features in their databases. However, it is not exclusive to those shops as it supports all data interfaces SQL and non-SQL.

A few of his insights should help RCAC users avoid some sticky issues.

When using some of the non-SQL query interfaces–for example, Open Query File and Query400–there are some minor differences in the result sets returned. Also, there are a few legacy objects such as multi-format logical files that aren’t supported by RCAC permissions. If an application is using that type of legacy file, it won’t work after the row and column access controls on a table or physical file are defined.

“We are recommending functional and performance testing to make sure the transition doesn’t negatively impact applications,” he says. “There will probably be a delay in the adoption cycle because of the testing for impacts on non-SQL interfaces.”

On the topic of security underpinnings, security expert Pat Botz strongly suggests companies get object-level authorities correct as a first order of business.

“The people who are overlooking other security measures are likely going to overlook RCAC as well,” he says. “These are the same people who believe the IBM i is just inherently secure. There are tons of people who mistakenly believe this. Row and column access control isn’t a substitute for object-level authority, but it is a very useful addition.”

Until row column access control was available, the only way to prevent multiple users of a library from seeing information that they had no business seeing was to physically separate all the files that were created before the access became a concern. That could be a huge time-intensive job that is made much simpler with RCAC by using row permissions.

Botz has written an article on the Botz & Associates website that explains his view of the new RCAC capabilities and includes information on how to get started using the tools.

Row and column access control for DB2 on i follows two years after IBM introduced these features to Linus-Unix-Windows and zOS databases. Customers there were first to ask for more granular control of security at the database level, Milligan says.

SQL expert Mike Sansoterra, a frequent contributor to the IT Jungle newsletter Four Hundred Guru, is impressed with RCAC for several reasons. First, it provides a data protection scheme for both new and legacy applications with little, if any, code changes. He also points out the value of greater data protection granularity by limiting access to rows in various tables based on rules assigned by a database administrator. The importance of column masks for limiting users’ views of column data–such as the last four digits of a social security number or last four digits of a credit card number should also provide benefits, he says.

“All of this is maintained within DB2 so it doesn’t matter which interface the data is accessed through (ODBC, JDBC, HLL, Query/400, etc.); all data is protected without building security exits or other programming constructs,” Sansoterra notes. “And the data protection is setup in such a way so that administrators can setup access control rules, but even they won’t see the data.”