Row and column access control

Row and column access control is a Db2 security solution that uses SQL to control access to a table at the level of a row, a column, or both.

Traditionally, access control at the row and column level is implemented through views. Using views as an access control method works well only when access rules, restrictions, and conditions are monolithic and simple. It however becomes ineffective when view definitions become too complex because of the complexity and granularity of privacy and security policies. It also becomes costly when a large number of views must be manually updated and maintained. In addition, the ability to update views proves to be challenging. As privacy and security policies evolve, required updates to views may negatively affect the security logic particularly when database applications reference the views directly by name. Db2 row and column access control helps resolve all these problems.

Implemented through SQL and managed by the Db2 security administrator, row and column access control allows you to manage access to a table with filtering and data masking. Unlike multilevel security, row and column access control is integrated into a database system, and all applications and tools that use SQL to access the database are automatically subject to the same control. This effectively eliminates the need to filter security-sensitive data at the application level and ensures that the data is protected when the applications and tools use SQL to access it.

Row and column access control is based on a security policy that specifies the rules and conditions under which a user, group, or role can access rows, columns, or both of a base table. The access control is not needed at the view level because the view automatically receives row and column access control that is activated on the underlining base table. The row and column access control rules do not affect how a read-only view is determined. All users access the same base table (as opposed to alternative views of a table), but access restrictions are based on individual user permissions and masks that are specified by a policy associated with the table.

An authorization ID or role with the SECADM authority can manage row and column access control. The SECADM authority can activate or deactivate row and column access control for a table, grant or revoke the CREATE_SECURE_OBJECT system privilege, and create, alter, or drop row permissions and column masks. The SYSADM authority can perform the same tasks if the SEPARATE SECURITY system parameter on panel DSNTIPP1 is set to NO during installation.

Row and column access control can be activated for a table before or after row permissions or column masks are created for the table. If row permissions or column masks already exist, activating row and column access control simply makes the permissions or masks become effective. If row permissions or column masks do not yet exist, activating row access control for a table means that Db2 will generate a default row permission that prevents any access to the table by SQL, and activating column access control means to wait for the column masks to be created.

When a table is activated for row or column access control, all users, including the table owner and the SECADM, SYSADM, or DBADM authorities, are subject to the same security rules and restrictions. This ensures that access to security-sensitive data is truly on a need basis and prevents system and database administrators from unnecessarily accessing it. Since security policies or rules are expressed and enforced through SQL, row and column access control is inherently flexible.

Row access control and multilevel security are mutually exclusive. If a table is activated for row access control, it cannot be altered to include a security label column; if a table has a security label column, it cannot be activated for row access control. Column access control, on the other hand, is not affected by multilevel security. If a table is activated for column level access control, it can be altered to include a security label column, and vice versa.