Authorization and Access Control

Study Notes

Explicit privileges can be granted to a role or authorization ID.
Implicit privileges can be granted through object ownership.
Administrative authorities, such as SYSADM and DBADM, can be granted to manage access.
Utility authorities, such as ACCESSCTRL, can be granted to manage privileges.
Common Db2 administrative authorities include SYSADM, DBADM, and ACCESSCTRL.

Separating the SYSADM authority can be done to manage access.
Migrating the SYSADM authority can be done to transfer ownership.
Creating roles or trusted contexts with the SECADM authority can be done to manage access.
Altering tables with the system DBADM authority can be done to manage access.
Accessing data with the DATAACCESS authority can be done to manage access.
Granting and revoking privileges with the ACCESSCTRL authority can be done to manage access.

Ownership of objects with unqualified names can be managed to grant implicit privileges.
Ownership of objects with qualified names can be managed to grant implicit privileges.
Ownership of objects within a trusted context can be managed to grant implicit privileges.
Changing object ownership can be done to manage access.
Granting implicit privileges of object ownership can be done to manage access.

Privileges required for executing routines can be managed to grant access.
Examples of granting privileges for routines can be done to illustrate access management.

Run behavior can be used to authorize dynamic SQL statements.
Bind behavior can be used to authorize dynamic SQL statements.
Define behavior can be used to authorize dynamic SQL statements.
Invoke behavior can be used to authorize dynamic SQL statements.
Common attribute values for bind, define, and invoke behaviors can be used to manage access.

Catalog tables with privilege records can be used to retrieve privilege information.
Retrieving all authorization IDs or roles with granted privileges can be done to manage access.
Retrieving multiple grants of the same privilege can be done to manage access.
Retrieving all authorization IDs or roles with the DBADM and system DBADM authorities can be done to manage access.
Retrieving all IDs or roles with access to the same table can be done to manage access.
Retrieving all IDs or roles with access to the same routine can be done to manage access.

Multilevel security can be implemented to manage access.
Mandatory access checking can be used to implement multilevel security.
Implementing multilevel security at the object level can be done to manage access.
Implementing multilevel security with row-level granularity can be done to manage access.
Restricting access to the security label column can be done to manage access.
Managing data in a multilevel-secure environment can be done to manage access.
Implementing multilevel security in a distributed environment can be done to manage access.

Granting or not granting privileges on views can be used to specify access to tables.
Granting privileges on databases, plans, packages, and the entire Db2 subsystem can be done to manage access.
Granting privileges to execute an application plan or package can be done to provide a finely detailed set of privileges.
Granting privileges to an ID can provide a finely detailed set of privileges.

Instead of granting privileges to many primary authorization IDs, consider associating each of those primary IDs with the same secondary ID or a role if running in a trusted context.

RACF determines whether the ID is authorized for Db2 resources.
IMS terminal security can be used to limit the entry of a transaction code to a particular logical terminal.
CICS transaction code security can be used to control the transactions and programs that can access Db2.
Db2 data access control can be used to manage access to data.