Db2 for z/OS considerations for GDPR readiness

Notice

Clients are responsible for ensuring their own compliance with various laws and regulations, including the European Union General Data Protection Regulation. Clients are solely responsible for obtaining advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulations that may affect the clients’ business and any actions the clients may need to take to comply with such laws and regulations.

The products, services, and other capabilities described herein are not suitable for all client situations and may have restricted availability. IBM does not provide legal, accounting, or auditing advice or represent or warrant that its services or products will ensure that clients are in compliance with any law or regulation.

Contents

GDPR

Product configuration for GDPR

Data lifecycle

Data storage

Data access

Data processing

Data monitoring

Responding to data subject rights

GDPR

General Data Protection Regulation (GDPR) has been adopted by the European Union (“EU”) and applies from May 25, 2018.

Why is GDPR important?

GDPR establishes a stronger data protection regulatory framework for processing of personal data of individuals. GDPR brings:

• New and enhanced rights for individuals
• Widened definition of personal data
• New obligations for processors
• Potential for significant financial penalties for non-compliance
• Compulsory data breach notification

Read more about GDPR

• EU GDPR Information Portal
• ibm.com/GDPR website

Product configuration for GDPR

Offering Configuration

The following sections provide considerations for configuring Db2 for z/OS to help your organization with GDPR readiness.

You can use the following approaches to protect your data and system resources by controlling access to Db2 objects, subsystems, and other assets:

• Use the installation SYSOPR authority for Db2 installation or migration to prevent unintended access to data during the installation or migration process. For more information, see Installation SYSOPR.

  For more information, see Installation or migration without requiring SYSADM.

• Use appropriate data access control for all types of access to data in the Db2 subsystem. 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. For more information, see Db2 data access control.
• Review all security-related subsystem parameter settings for your Db2 environment and tailor them appropriately, as described in Generating tailored Db2 12 installation, migration, or function level activation jobs. For example:
  • The AUTH subsystem parameter controls how Db2 checks authorizations.
  • The TCPKPALV subsystem parameter controls the authentication methods required to access Db2 from a remote system.
• Use Db2 Secure Socket Layer (SSL) support to protect data in-flight for all access to Db2 subsystems from a different systems. For more information, see, Encrypting your data with Secure Socket Layer (SSL) support.
• Start RACF Checking for the DSNR class to control whether users can gain access to the Db2 subsystem from outside of Db2. The DSNR class when started is checked on every process into Db2 to ensure that the user is authenticated and authorized to access the Db2 subsystem. For more information, see Permitting access from remote requesters.
• Start RACF checking for the SERVER class if you use stored procedures in a WLM-established address space. For more information, see Enabling RACF checking for the DSNR and SERVER classes.
• Audit all access to Db2 to verify that the security protections and procedures in place for your Db2 subsystem are adequately designed and implemented to meet the goals of your security objectives. For more information, see Auditing access to Db2.
• Use appropriate access control methods for For example: data sets that store the data of the Db2 subsystem. If not properly secured, the data sets can be accessed outside of Db2. For example, control all access to offline utilities or encrypt all data sets for greater protection. For more information, see Data set protection.

Data lifecycle

Db2 for z/OS is a relational database management system that stores a collection of information provided by the user, which can include personal data.

The data is organized into rows, columns, and tables, and indexed to make it easier to find relevant information. Data is updated, expanded, and deleted as new information is added. Db2 processes workloads to create and update data, querying the data and running applications against it.

All access to data that is stored in Db2, including personal data requires the use of an authenticated and authorized user ID by the z/OS security server. Users must provide a valid user ID and credentials to access Db2. Once authenticated, users must have additional privileges to query or modify tables that contain user data. Db2 supports many authentication credentials such Kerberos, a password, a passphrase, a passticket, or a client certificate.

The most common way for users to access a Db2 system is by the use of passwords or password phrases, but the simplicity of passwords presents a relatively simple point-of-attack for gaining access to personal data. However, you can use multi-factor authentication for z/OS for access to Db2, which requires that multiple authentication factors be presented during logon to verify a user's identity minimizes these risks or types of attacks. For more information, see Multi-Factor Authentication for z/OS.

Db2 maintains a set of tables, known as the Db2 catalog, that contain information about the data that Db2 controls. You can use the information in the Db2 catalog to understand which tables contain personal data. You can retrieve catalog information by querying the catalog tables with the appropriate privileges. For example:

• The SYSTABLES catalog table contains information about every table, view, and alias in your Db2 system. Each row tells you whether the object is a table, a view, or an alias, its name, who created it, the database that it belongs to, the table space that it belongs to, and other information.
• The SYSCOLUMNS catalog table contains one row for every column of each table and view.
• You can Store your own information about tables and columns in the REMARKS columns of the SYSTABLES and SYSCOLUMNS catalog tables. Review the tables and columns to help isolate tables that contain personal data. For more information, see Using the catalog in database design.

You can protect any tables that contain personal data by minimizing access to the table and enabling auditing of all queries or changes to the table.

Data storage

Identify tables that contain account or personal data and develop a security plan to protect these tables:

• Create security plan that includes both techniques and procedures based on your security objectives. For an example security plan, see Scenario: Securing data access with Db2 facilities at Spiffy Computer. Do not view this security plan as an exact model for your security needs. Instead, use it to understand various possibilities and address problem areas that you might encounter when you implement your own security plan.

• Periodically generate image copies of the Db2 catalog, directory, and user databases to ensure that backups do not contain deleted users. These copies minimize the risk of exposure personal data for deleted users if the RECOVER utility is required to recover the data.

Data access

In addition to privileged user control, use the following approaches for roles and access rights for personal data:

• Use column masks and row permissions to enable a fine-grained access control methodology to ensure that the personal data is accessed selectively and only for a defined purpose. For more information see Managing access through row permissions and column masks.
• Use trusted contexts to verify the identity of requesting users in the application context, before allowing access to the personal data. In modern 3-tier applications, verifying the online context of a user's identity is challenging because applications and application servers usually connect to the database as a single database user, making it hard to track the originating user.

  Trusted contexts addresses this concern by providing a policy-based authorization model that recognizes application-level users, privileges, and roles within the database. With built-in support for propagating application users’ sessions to the database, RAS allows security policies on data to be expressed directly in terms of the application users, their roles and security contexts. For more information, see Managing access through trusted contexts.

• Use roles to remove implicit privileges and require explicit privileges to access client data. Ownership of Db2 objects carries a set of related implicit privileges on the objects. However, Db2 provides separate controls for creation and ownership of objects. In general, when you create an object, the owner of the object can be your primary authorization ID, one of your secondary authorization IDs, or the role that you are associated with in a trusted context. For more information, see

Separation of duties

Db2 provides a range of audit-able administrative authorities that help you control access to personal data. The granularity and flexibility in Db2 administrative authority help you achieve adequate separation of duties and responsibilities and prevent a single user from possessing unlimited privileges which could be used to gain access to personal data.

Use the following approached to control the separation of duties:

• Separate Db2 security administration, database administration, and data access control from system administration by setting the SEPARATE_SECURITY subsystem parameter to YES. You can set the parameter by using the SEPARATE SECURITY field on panel DSNTIPP1 during installation or migration. The SEPARATE_SECURITY subsystem parameter does not apply to or affect users with installation SYSADM authority.

  If you set SEPARATE_SECURITY to YES:

  • The SYSADM authority can no longer manage security-related objects (such as roles, trusted contexts, row permissions, and column masks) or have the ability to grant or revoke privileges that are granted by others.
  • The SYSCTRL authority can no longer manage roles or grant or revoke privileges that are granted by others, either. Instead, the SECADM authority will manage all security-related objects. The SECADM and ACCESSCTRL authorities control access to all databases even though they cannot access any user data in the databases.
  • The SYSADM authority can only set CURRENT SQLID to its primary or one of its secondary authorization IDs. The SYSADM, SYSCTRL, and system DBADM authorities can only set BIND OWNER to the primary or one of the secondary authorization IDs of the binder. Finally, the SYSADM authority does not have implicit insert, update, delete access to the SYSIBM.SYSAUDITPOLICIES table.

  However, if you set SEPARATE_SECURITY to NO,which is the default:

  • The SYSADM authority retains all the existing privileges and responsibilities and gets implicit privileges of the SECADM authority. That is, the SYSADM authority continues to be the security administrator and manage all security-related objects, perform grants, and revoke privileges that are granted by others.
  • The SYSADM authority has implicit insert, update, delete access on the SYSIBM. SYSAUDITPOLICIES table and is able to set CURRENT SQLID and BIND OWNER to any value.
  • The SYSCTRL authority has most of the implicit privileges of the ACCESSCTRL authority. SYSCTRL can manage roles, perform certain grants, revoke privileges that are granted by others, and set BIND OWNER to any value.

  In Db2 12, the installation SYSADM authority is not affected by the setting of the SEPARATE_SECURITY parameter. Installation SYSADM can manage security-related objects, grant and revoke authorities or privileges, and set CURRENT SQLID and BIND OWNER to any value regardless of the setting of the SEPARATE_SECURITY parameter.

  For more information, see Separating the SYSADM authority.

Privileged administrators

Traditionally, restricting access to client data by privileged users such as DBAs has been difficult. Such restrictions might affect day-to-day operations, such as migration and maintenance of Db2. However, you can take advantage of the granularity ofDb2 administrative authority and simplify your system database administration based on the security needs of your business. Doing so allows you to eliminate or minimize the need for granting the SYSADM or install SYSADM authority.

Separate the privileges of the SYSADM authority and migrate them to other administrative authorities. Your security policies must identify the administration model to use for separating the SYSADM authority and define the criteria for assigning specific administrative authorities to specific authorization IDs or roles. For an example model for migrating the SYSADM authority to other authorities, see Migrating the SYSADM authority.

Administrators

Minimize the exposure of personal data when migrating or installing a Db2 subsystem, by using the installation SYSOPR authority to perform all installation or migration tasks. The SYSADM and installation SYSADM authorities provide unrestricted access to all user data, which in some cases can introduce unintended and unnecessary data exposure.

Starting in Db2 12, you can use the installation SYSOPR authority can help reduce those risks. The installation SYSOPR authority provides all the privileges that are required for installing or migrating Db2. For example, with installation SYSOPR, you can access catalog and directory objects, create, drop, or alter system objects, execute the -ACTIVATE command, specify the owner for the BIND and REBIND commands, and run the CATMAINT utility. However, you are not allowed any access to non-system objects or user data in the subsystem. For more information, see Installation SYSOPR.

Activity logs

You can audit security information such as any access denials, grants, or revokes for tables with personal data. With audit policies you can audit all access to these tables. The default causes no auditing to take place. When auditing is enabled, Db2 sends audit data to SMF by default. SMF records audit data in type 102 records. When you invoke the -START TRACE command, you can also specify GTF as a destination for audit data.

Data processing

Db2 relies on the z/OS Security Server, which includes RACF or an equivalent system, a program that helps achieve data security by controlling access to Db2. For RACF protection, the user must supply a userid and user credential to the z/OS Security Server before a process is attached to Db2. Access control is defined for each user based on his authorization IDs and roles associated with a process.

You control access within Db2 by granting or revoking privileges and related authorities that you assign to authorization IDs or roles. A privilege enables its holder to perform a specific operation, sometimes on a specific object.

Db2 relies on authorization 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. IDs or a roles—not users—own objects. In other words, Db2 does not base access control on a specific user or person who needs 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. For more information, see Db2 data access control.

Db2 provides built-in data encryption and decryption functions that you can use to encrypt personal data, such as credit card numbers and medical record numbers. You can encrypt data at the column or value level. When you use data encryption using the build in function, Db2 requires the correct password to retrieve the data in a decrypted format. If an incorrect password is provided, Db2 does not decrypt the data.

Db2 provides a simple, transparent, and consumable approach to enabling encryption of data at rest. To implement encryption at rest, your security or storage administrator enables z/OS DFSMS data set encryption on your underlying Db2 data sets that contain tables with personal data. z/OS DFSMS data set encryption is a hardware and software solution.

• Use z/OS DFSMS data set encryption to protect all of your Db2 system-managed and user-managed objects, such as Db2-managed table space and index space data sets, data sets that are used by Db2 utilities, and sequential input and output data sets. For more information, see Encrypting your data with z/OS DFSMS data set encryption.
• z/OS DFSMS data set encryption uses a key label to encrypt and decrypt the Db2 data. The key label identifies a protected data key in the z/OS ICSF key repository which is managed by your ICSF administrator.

Data deletion

You can delete personal data from a Db2 subsystem by completing the following steps:

1. Issue SQL statements to delete the rows or column from the tables that contain personal data.
2. Run Db2 utilities to generate new backups and logs that do not contain the deleted personal data. For more information, see Actions to take to aid in successful recovery of inconsistent data.

Data monitoring

Db2 stores changes to data and significant events in recovery log records. You can monitor the change records to monitor the processing of personal data. You can set up audit policies to dynamically enable auditing of all access to tables that have personal data.

You can use temporal auditing to automatically trace of the following types of audit information: who modified the data, when the data were modified, and what SQL operation modified the data in the table. For more information, see Scenario for tracking auditing information.

Db2 provides robust activity monitoring capabilities that you can use to monitor all aspects of the system through the Db2 trace facility. Db2 trace can record several types of data, including: statistics, accounting, audit, performance, monitor, and global traces. The trace records are written using GTF or SMF records. Trace records can also be written to storage, if you are using the monitor trace class. For more information about Db2 trace and the various trace types, see Types of Db2 traces.

Responding to data subject rights

Db2 supports SQL queries that can be used by individuals to access their personal data.

You can create applications that issue SQL statement, in user-friendly formats that individuals can use to query or modify tables that contain personal information, and manage their personal data.