Db2 data access control

Access to data can originate from users through interactive terminal sessions, local or remote stored procedures, utilities, or IMS or CICS® transactions. It can also originate from application programs that run in batch mode, remote applications that use DDF or CLI and JDBC drivers, or web-based applications supported by WebSphere® Application Servers.

Given the variety of access originators, the term process is used to represent all access to data. For example, within a Db2 subsystem, a process can be a primary authorization ID, one or more secondary IDs, a role, or an SQL ID.

A process can gain access to Db2 data through several routines. As shown in the following diagram, Db2 provides different ways for you to control access from all but the data set protection route.

One of the ways that Db2 controls access to data is by using authorization IDs or roles. Db2 relies on IDs or roles to determine whether to allow or prohibit certain processes. Db2 assigns privileges and authorities to IDs or roles so that the owning users can take actions on objects. In this sense, it is an ID or a role, not a user, that owns an object. In other words, Db2 does not base access control on a specific user or person who need access. For example, if you allow other users to use your IDs, Db2 recognizes only the IDs, not the people or programs that use them.