Introduction to Db2 for z/OS Security
(by Gayathiri Chandran)

Securing the database is critical to protecting the confidentiality, integrity, and availability of enterprise data. There are many different components in managing database security. Understanding the fundamentals is crucial to efficiently secure the system. This paper introduces the basics of Db2 for z/OS Security.

What is Db2 for z/OS Security?

• Control access to Db2 subsystems and resources in Db2.

• Provide functions and encryption capabilities to meet the security objectives and regulatory requirements.

• Provide audit capabilities to monitor and determine if the security plan is adequately designed and security procedures are effectively implemented to protect the data access and consistency.

Db2 for z/OS security deeply integrates with the system Z security functions and leverages the operating system capabilities, which provides a strong advantage.

• A Db2 for z/OS user and the groups associated with the user are defined in the z/OS Security Server such as RACF. z/OS Security Server authenticates and authorizes user access to Db2. Additionally, access to objects in Db2 can also be controlled in the z/OS security server. Db2 for z/OS underlying data sets are protected by the z/OS security server.

• z/OS DFSMS data set encryption is used to encrypt the data sets associated with the Db2 for z/OS logs, catalog and directory objects, user table spaces and index spaces.

• z/OS Communication Server provides functions such as Application Transparent Transport Layer Security (AT-TLS), IP Security (IPSec) and Intrusion Detection Services (IDS) for protection around Db2.

Access to Db2 for z/OS subsystem

Db2 for z/OS subsystem can be accessed in many ways, local using batch, TSO, IMS, CICS, RRSAF, CAF, Tools, etc. and remote using DRDA or REST APIs. All users who access Db2, locally or remotely, must be authenticated and authorized to access the Db2 subsystem.

User authentication for local connections is generally performed by local attachments, such as TSO, IMS, or CICS. If authentication for a
local connection is not performed or if a connection is remote, Db2 invokes z/OS security server, such as RACF to authenticate the user. For remote authentication, Db2 supports various security mechanisms including multi-factor authentication (MFA), AT-TLS client certificate authentication, AES 256-bit encrypted user ID and password, and RACF passticket. The multi-factor authentication support in Db2 is based on the IBM Z Multi-Factor Authentication product, which provides enhanced logon security and centralized management.

When a user is authenticated, Db2 invokes RACF to authorize the user’s access to Db2 subsystem. RACF checks user profiles defined in the DSNR class based on specific subsystem and the other environment information to determine subsystem access for the user. If the user is authorized to access Db2, then the user can access resources in Db2.

Once a user is successfully authenticated and authorized to access Db2, Db2 invokes the connection exit or sign-on exit routine to associate a set of IDs, the primary authorization ID, possibly one or more secondary authorization IDs (can be a RACF group ID), and an SQL ID with the process. A secondary authorization ID can hold additional privileges that are available to the process. An SQL authorization ID (SQL ID) holds the privileges that are exercised when certain dynamic SQL statements are issued.

Db2 for z/OS then checks for a trusted context that matches the primary authorization ID. If a matching trusted context is found, Db2 validates the connection attributes based on the connection type, local or remote. If the validation is successful, Db2 establishes the connection as trusted. Otherwise, Db2 establishes a normal connection. Trusted connection provides various capabilities including better accountability for remote users, use an established database connection for a different user with optional authentication, and acquire more privileges within the trusted context using a database Role. A role is a database entity that groups one or more privileges together in a trusted context.

https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/seca/src/tpc/db2z_usetrustedconnection.html

Access to Db2 for z/OS resources

Db2 for z/OS controls access to its objects and data by a set of privileges through authorization identifiers (IDs) and SQL roles.

A privilege can be held by:

• Explicit grant of the privilege, sometimes on a specific object.

https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/seca/src/tpc/db2z_explicitprivilege.html

• Administrative authority

Includes a set of privileges, often covering a related set of objects. Example: DBADM authority on a database, PACKADM on a collection.

Authorities can also include privileges that cannot be explicitly granted. Example: Ability to execute BACKUP SYSTEM utility is included in the SYSCTRL authority.

https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/seca/src/tpc/db2z_adminauthorities.html

• Ownership of the object

The object owner implicitly holds all the privileges over that object, mostly with the GRANT capability within Db2.

You can revoke those privileges only when you delete or remove the object itself. However, you can transfer the ownership of a database or system object from one owner to another using SQL TRANSFER OWNERSHIP statement.

• Plan and package execution

Db2 for z/OS provides a unique way to control access to plans and packages. The owner of a plan or package can grant the EXECUTE privilege to any ID or role in a trusted context. With the EXECUTE privilege, an ID or role can execute the plan or package without holding the privileges for every action that the plan or package performs.

The access to a table can be further controlled using Row permissions and Column masks. These privacy control functions restrict all users access to the table based on the rules specified for the individual user in the permissions and masks associated with the table, regardless of the privilege held by the user.

• A row permission is a database object that describes a specific row access control rule for a table. In the form of an SQL search condition, the rule specifies the conditions under which a user, group, or role can access the rows of data in the table.

• A column mask is a database object that describes a specific column access control rule for a column. In the form of an SQL CASE expression, the rule specifies the condition under which a user, group, or role can receive the masked values that are returned for a column.

https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/seca/src/tpc/db2z_implementrowcolumnctrl.html

Figure 1. Primary ways within Db2 to a thread access to data

Incorporating Separation of Duties in access control

Db2 for z/OS provides options for controlling access to objects. You can use Db2 native facilities or z/OS Security Server through the Access Control Authorization Exit (DSNX@XAC) to authorize user access to objects, data, and utilities.

The RACF access control module allows to use RACF for Db2 authorization checking. The RACF access control module is activated at the Db2 access control authorization exit point, DSNX@XAC by replacing the default Db2 exit routine.

https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/racf/src/tpc/db2z_racfoverview.html

Encryption

Establishing a secure perimeter around core business data using encryption helps to protect the data from security breaches. Encrypting at multiple layers, such as securing the connections using SSL, enabling data set level encryption for protecting data at rest, encrypting sensitive data in memory provides robust data protection.

Network layer encryption

Db2 for z/OS supports Secure Socket Layer (SSL) protocol by using the z/OS communications server IP Application Transparent Transport Layer Security (AT-TLS). AT-TLS uses policies that are read, parsed, and installed into the TCP/IP stack by the z/OS Communications Server Policy Agent (PAGENT). Db2 continues to send and receive clear text data over its sockets while the transmission is protected by system SSL.

Data at rest data set encryption

Db2 exploits the z/OS DFSMS data set encryption capability, part of Z pervasive encryption to transparently encrypt Db2 for z/OS data at rest without requiring application changes or requiring an administrator to redefine objects in Db2. Db2 12 function level 502 (V12R1M502) adds additional controls to set up encryption policies using Db2 interfaces. Db2 also supports the Coupling Facility (CF) structure encryption capability introduced in z/OS 2.3 to encrypt Group Buffer Pool (GBP) and Shared Communications Area (SCA) data in the coupling facility.

Data in memory encryption

With data set level encryption, the data remains in the clear in memory. The built-in functions, ENCRYPT_DATAKEY and DECRYPT_DATAKEY_datatype introduced in Db2 12 function level 505 (V12R1M505) provide column-based encryption of security-sensitive data using AES 256-bit algorithm and key label. The data remains encrypted in memory until the decrypt data key function is invoked to decrypt the data.

Db2 for z/OS Audit

Auditing allows to determine the adequacy and effectiveness of the policies and procedures in place to secure the data. It enables to address the questions about data security such as:

• Have attempts been made to gain unauthorized access?

• Who is authorized to access the data? Who accessed what data?

• Is the data in the subsystem accurate and consistent?

Db2 uses System Management Facility (SMF) and/or Generalized Trace Facility (GTF) and/or monitor programs for trace data.

Audit Trace

A Db2 audit trace allows to monitor and track all accesses to Db2 subsystem and resources. The various audit classes can be used to record the changes in authorization IDs, data structures, access attempts by unauthorized IDs, privileged administrator access, and the results of GRANT and REVOKE statements.

Audit Policy

An audit policy provides the flexibility to configure audit requirements of your security plan and to monitor data access by applications and individual users (IDs or roles). A Db2 audit policy is a set of criteria that are grouped into various audit categories. It enables to dynamically audit SQL statements and tables without the AUDIT clause specified. More importantly, it allows to audit how a specific Db2 authority is used.

An audit policy can be defined as secure or tamper-proof. A secure audit policy requires security administrator to stop the policy. A tamper-proof audit policy prevents the audit trails from being unnecessarily modified or stopped by privileged users by requiring additional controls in the z/OS Security Server.

Audit change data

A temporal table automatically maintains a history as an audit trail that allows to track when the data was modified. Db2 can also track who modified the data, and the SQL operation that modified the data by specifying the GENERATED ALWAYS AS clause for the table.

References

https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/nav/src/tpc/db2z_securityintro.html

https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/seca/src/tpc/db2z_dataprotection.html

https://www.ibm.com/support/knowledgecenter/SSEPEK_12.0.0/seca/src/tpc/db2z_securityauditoverview.html

https://www.ibm.com/support/pages/node/6406680