Field Level Security in IBMi allows you to protect data in legacy applications without creating risks to application stability: this feature is implemented so that restricting data access doesn’t require extensive re-development which may create new errors in complex application logic.
These precise protections offer an important opportunity to secure sensitive data in legacy applications quickly and painlessly without modifying the application layer.
IBM i Introduced field-level security capabilities, called Row Column Access Control (RCAC), in version 7.2. This functionality offers important new options for enterprises running IBM i, offering a practical tool for keeping data secure without dramatically restructuring user access. RCAC control is a simple yet powerful feature that risks flying under the radar and unknown to companies that have employed IBM i for a long period of time.
In this blog, we outline the basic functionality of RCAC functionality and take a look at its strategic implications for technology management.
The Advantages of Targeted Access Control in IBM i
Previous versions of IBM i (OS/400) applications only supported menu/option level security: access to particular menus or functions could be controlled, but once a user had access to a given part of the system, no more granular controls could be imposed without significant software changes.
This level of access control extended to the database layer: in older versions of IBM i, user permissions were managed solely through table-level access. A user either had access to all of the data in a table, or none of it.
RCAC provides much more granular controls that can be used to compliment table-level permissions on an as-needed basis: access control is extended to specific rows and columns.
This functionality is executed through SQL-rules applied directly at the database layer. When the database is queried (whether the query comes from an integrated IBM i application or an external system), field-level permissions are checked. If the relevant user doesn’t have access to a given row/column, their query will not return any data from these restricted fields.
How it Works
RCAC functionality is unlocked upon installation of the (free) module IBM Advanced Data Security for i (5770SS1 option 47):
- Users selected as database administrators have the ability to assign row and column-level access permissions.
- Permissions can be based on specific users or group profiles for role-based control.
- Permissions can be also tied to conditional variables, such as the number of days since a given row was entered, the overall size of an account or the status of an order.
- Any number of conditions can be added for the same table, allowing for overlapping rules.
Strategic Implications: Better Security While Keeping Access Control Simple
Many legacy enterprise applications were not built with field-level security in mind. But GDPR, CCPA, and other data protection regimes are driving a need for a much more robust data protection mechanism.
RCAC allows for this protection to be extended precisely, restricting access to sensitive data without dramatically restructuring user access. Crucially, when permission to access a given row/column is not granted, the originating query does not generate an error message. Instead, asterisks are returned. This ensures that the application accessing this data is still completely functional: only access to protected data is affected. This means that RCAC permissions provide a targeted method for protecting sensitive data that doesn’t require heavily modifying existing applications.
For instance, consider a manufacturing facility where shipping operators consult customer order information using IBM i. These personnel only need to see information related to order fulfillment, but customer order records also contain sensitive financial data like product cost.
To keep this data safe, one option is to implement an entirely new table containing orders stripped of sensitive financial data and then modifying the application to use the new table.
But this approach is costly and time-consuming compared to simply instituting some simple RCAC controls. In this case, locking access to a few fields of financial data for operations personnel offers a clean path for better data protection. And it does so without upending a potentially complex series of permissions that workflows for sales, accounting, and customer support depend on.
This ability to protect specific data without risking application stability opens up possibilities for companies trying to improve data protection without re-designing data access for the entire organization. As a fully integrated enterprise technology platform, IBM i has a strong value proposition for companies looking for a streamlined administrative workload for IT systems. RCAC is a perfect fit for this sort of operational environment—a single admin can quickly and easily set up control without any risk to overall system stability.
IBM i’s implementation of RCAC is built for the ground-level reality that altering data access permissions for business-critical systems can be prohibitively time-consuming, risky and complex.