Authorization and security mechanisms for data access

Authorization

You probably noticed references to authorization in this information. For example, you must be authorized to run SQL statements that create and alter DB2 objects. Even when users run a SELECT statement to query table information, their authorization might limit what they see. The user might see data only in a subset of columns that are defined in a view. Views provide a good variety of security controls.

Before you issue DB2 commands, run utilities, run application packages and plans, or use most other DB2 functions, you need the appropriate authorization or privilege. For example, to make changes to a table, you need authorization to access that table. A privilege allows an action on an object. For example, to insert data into a table requires the privilege to insert data.

GRANT and REVOKE statements provide access control for DB2 objects. Privileges and authorities can be granted to authorization IDs and roles in many combinations, and they can also be revoked.

You can use the RACF® component or an equivalent product to control access to DB2 objects. This is the best option if you want the z/OS® security administrator to manage access to data instead for the database administrator.

Security

Due to the need for greater data security and demands for improved corporate accountability, the federal government and certain industries have developed laws and regulations to guide many corporate processes. The expectation to comply with these laws and regulations is likely to increase in the future. DB2 for z/OS support of roles and trusted contexts help in the area of compliance by enforcing data accountability at the data level. Instead of using a single user ID for all database requests, application servers can provide an user ID with no performance penalty associated with the request.