Overview

IBM® Advanced Data Security for i introduces RCAC as an extra layer of data security.

RCAC provides access control to a table at the row level, column level, or both. RCAC can be used to complement the table privileges model. To comply with various government regulations, you might implement procedures and methods to ensure that information is adequately protected. Individuals in your organization are permitted access to only the subset of data that is required to perform their job tasks. For example, government regulations in your area might state that a doctor is authorized to view the medical records of their own patients, but not of other patients. The same regulations might also state that, unless a patient gives their consent, a healthcare provider is not permitted access to patient personal information, such as the patients home phone number. You can use RCAC to ensure that your users only have access to the data that is required for their work. For example, RCAC can filter patient information and data to include only that data, which a particular doctor is authorized to view.

Other patients do not exist as far as the doctor is concerned. Similarly, when a patient service representative queries the patient table at the same hospital, they are able to view the patient name and telephone number columns, but the medical history column is masked for them. If data is masked, a NULL or an alternate value is displayed instead of the actual medical history. RCAC has the following advantages:

1. No database user is inherently exempted from the RCAC rules. Even high-level authorities such as users with all object authority (special authority (such as *ALLOBJ)) authority are not exempt from these rules. Only users with QIBM_DB_SECADM authority can manage RCAC within a database. Therefore you can use RCAC to prevent users with all object authority from freely accessing all data in a database.
2. Table data is protected regardless of how a table is accessed. Applications, improvised query tools and report generation tools are all subject to the access control rules. The enforcement is data-centric.
3. No application changes are required to take advantage of this additional layer of data security. RCAC is established and defined in a way that is not apparent to existing applications. However RCAC represents an important shift in paradigm in the sense that it is no longer what is being asked but rather who is asking. Even though two users can execute what appears to be identical queries, when row permission predicates are added to the query, those two users might observe a different result set. This behavior is the exact intent of the solution. It means that application designers and DBAs must be conscious that queries do not see the whole picture in terms of the data in the table unless granted RCAC authorization.
4. Prior to RCAC controls for data-centric data protection, DB2 for i users would protect the data through the creation of several to many SQL views or Select-omit logical files. While this technique of relying upon a view/logical file to limit data achieves the goal, it creates several problems:
   1. Applications had to be coded to work with specialized views, instead of a common object.
   2. In large installations, the number of views which exist for this purpose quickly grows to a large number, resulting in additional object management considerations like Save/Restore.
   3. The security officer has to spend time adjusting authorizations to many objects.
   4. For select-omit logical files, DB2 for i has to spend processing cycles to keep each select-omit logical file up to date as the underlying object(s) change.

Besides achieving the benefits of innately secure data when deploying RCAC, DB2 for i customers can retire the many views which exist solely to protect data.

IBM Advanced Data Security for i

IBM Advanced Data Security for i is an installable option that is used to manage security policies by enforcing RCAC with permissions and masks.

If IBM Advanced Data Security for i , is not installed, see Installing, upgrading, or deleting IBM i/OS® and related software for information about installing extra licensed programs. To install IBM Advanced Data Security for i, use option 47 in the list of installable options for the operating system.

Tables which contain enabled RCAC permissions or masks can be restored regardless of whether the IBM Advanced Data Security for i is installed. However if the option is not installed, permissions and masks cannot be created and tables, views, or indexes cannot be accessed which contain active permissions or masks.

Separation of duties

Separation of duties helps businesses comply with industry regulations or organizational requirements and simplifies the management of authorities. Separation of duties is commonly used to prevent fraudulent activities or errors by a single person. It provides the ability for administrative functions to be divided across individuals without overlapping responsibilities, so that one user does not possess unlimited authority, such as with *ALLOBJ authority.

For example, assume that a business has assigned the duty to manage security on IBM i to Theresa. Prior to release IBM i 7.2, in order to grant privileges, Theresa had to have the same privileges Theresa was granting. Thus, in order to grant *USE privileges to the PAYROLL table, Theresa had to have *OBJMGT and *USE authority (or a higher level of authority such as *ALLOBJ). This requirement allowed Theresa to access data in the PAYROLL table even though Theresa's job description was only to manage security.

In IBM i 7.2, the function usage, QIBM_DB_SECADM, provides a user with the ability to grant authority, revoke authority, change ownership, or change primary group. This is done without giving access to the object or, in the case of a database table, to the data that is in the table or allowing other operations on the table. QIBM_DB_SECADM function usage can only be granted by a user with *SECADM special authority and can be given to a user or a group.

QIBM_DB_SECADM is also responsible for administering RCAC. RCAC restricts which rows a user is allowed to access in a table and whether a user is allowed to see information in certain columns of a table.

The best practice is that the RCAC administrator has QIBM_DB_SECADM function usage and absolutely no data privileges. The RCAC administrator can deploy and maintain the RCAC constructs and would be unable to grant themselves unauthorized access to data.