Can Db2 for z/OS be configured to be secure and compliant?

March 27, 2024

Posted By: Gayathiri Chandran in Technical Content,

Introduction

A recent post in this blog posed the question, "Can Db2 for z/OS be hacked?" and provided some examples as cautionary tales. In this post, I want to answer a different question: "Can Db2 for z/OS be configured to be secure and compliant?" The answer is, "Yes." Db2 can be configured to be secure and compliant by leveraging the various security capabilities in Db2, adopting the security best practices implemented for the z/OS operating system, and following the fundamental principles of security such as least privilege, separation of duties, establishing secure defaults, and more.

Let's review some important Db2 security capabilities and how various Db2 processes can be secured.

Secure installation and migration process

The installation and migration process can be secured by using installation SYSOPR authority to install and migrate a Db2 system. The installation SYSOPR authority does not allow access to non-system objects or user data in the subsystem. The use of installation SYSOPR authority prevents unintended access to user data during installation and migration process.

Configuring secure authentication

All users who access Db2, locally or remotely, must be authenticated and authorized to access the Db2 subsystem. Subsystem access control restricts users from connecting to Db2 from an unauthorized environment. Subsystem access can be controlled by specifying profiles in the DSNR RACF class and permitting access only to the users who are allowed to access Db2 from a specific environment.

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.

Db2 supports various security mechanisms for remote authentication including multi-factor authentication (MFA), AT-TLS client certificate authentication, AES 256-bit encrypted user ID and password, and RACF PassTickets. Multi-factor authentication improves the security of the user account by requiring that multiple authentication factors are presented during logon to verify user’s identity.

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 secures the network connections and encrypts the data on the network.

You can ensure that secure authentication is enabled for remote access by setting TCPALVER subsystem parameter to SERVER_ENCRYPT. This setting prevents the exposure of user security credentials on the network.

You can discover applications that do not use compliant authentication methods or have not enabled encrypted connections to take corrective action or enforce compliance using profile tables.

You can also configure trusted context to enforce the security attributes of the connection and limit the scope of user access to a specific connection.

Creating secure access to Db2 for z/OS resources

Db2 supports granular object level privileges and granular authorities that allows to grant the least privilege required to do a task. The granular administrative authorities can be granted based on the administrative tasks.

You can grant the privileges and authorities to an authorization ID or a Db2 role to reduce the security risk of granting PUBLIC access. Using installation SYSADM authority only to perform system administration tasks can reduce the risk of any unintended access to organization data.

Restrict use of implicit privileges

Object ownership comes with a set of implicit privileges that cannot be revoked using SQL REVOKE statement. Ownership to a role or a RACF group eliminates the need to drop and recreate the object when the owner leaves the company. Ownership to a role can be used to restrict access using implicit ownership privileges.

You can transfer the ownership of a database object or a system object (STOGROUP) to a user (primary or a RACF group) or a Db2 role using SQL TRANSFER OWNERSHIP statement.

Protect data using encryption and privacy control functions

Db2 encryption solutions can protect data at rest and in the buffer pool. The Db2 privacy solution that uses row and column access controls allow a security administrator to control access to the data at the level of a row, a column, or both by using SQL statements.

Data set encryption

Db2 for z/OS uses the z/OS DFSMS data set encryption capability, part of IBM 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. Encrypting the data sets can help with certain compliance regulations and can also protect against insider threats from within the operating system.

You can use the DFSMS data set encryption capability to encrypt various types of Db2 data sets including Db2 managed tablespace and index space data sets, active and archive log data sets, data sets that are used by Db2 utilities. DFSMS data set encryption uses a key label that identifies a protected key defined in the Integrated Cryptographic Services Facility (ICSF) key repository, to encrypt and decrypt the data. There are multiple options available to set up the encryption policies.

Data in memory encryption using Db2 Built-in Functions

With DFSMS data set encryption, the data remains in the clear in Db2 buffer pool. The built-in functions, ENCRYPT_DATAKEY and DECRYPT_DATAKEY_datatype provide column-based encryption of security-sensitive data. Encrypting the data at the column level can prevent sensitive data from being exposed in memory.

The built-in encryption functions are introduced in Db2 12 function level 505 (V12R1M505). The built-in function encryption uses the AES 256-bit algorithm and key label for encryption process. The data remains encrypted in memory until the corresponding decrypt data key function is invoked to decrypt the data.

Row permissions and Column masks

A row permission 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 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.

Defining row permissions and column masks restricts 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. This approach ensures that access to security-sensitive data is truly on a need basis, and it prevents system and database administrators including users with installation SYSADM authority from accessing the data without a business need.

Audit Access

The Db2 audit capabilities collect information about Db2 security controls and can be used to monitor the adequacy and effectiveness of the policies and procedures in place to secure the data.

A Db2 audit trace allows to monitor and track all accesses to Db2 subsystem and resources.

An audit policy provides the flexibility to configure audit requirements and to monitor data access by applications and individual users (IDs or roles). Audit trace and audit policies can be specified to start during Db2 start up. An audit policy can also be defined to start during Db2 start up as secure or tamper-proof. A secure audit policy requires Db2 security administrator authority to stop the policy. A tamper-proof audit policy requires additional controls in the z/OS Security Server to modify or stop an audit policy.

Enabling audit traces that audit critical information, to start automatically during Db2 start up is crucial for securing and discovering issues within your databases. For example, installation SYSADM access is performed in Db2 regardless of whether you use Db2 native or external security controls. Defining an audit policy to monitor all use of installation SYSADM authority as secure or tamper-proof can prevent someone with installation SYSADM authority inadvertently stopping the policy that monitors all installation SYSADM access.