Db2 and GDPR

Data Architecture is not only related to the mere constellation of technical components that should work together. A data architecture should also reply to the needs of an end user and eventually establish an information architecture that is not only fit for use, but also fit for purpose.

This article will hence not go into great technical depths; you will find other articles describing the details of the technologies suggested in here. The scope of this article is to introduce you to the considerations that can help you to get insight on how business concerns can impact the usage of Db2 for z/OS.

The EU's General Data Protection Regulation (GDPR) is no longer a mystery to us. Everywhere articles pop up that deal with the explanation of the basic GDPR rules that will safeguard the privacy of European citizens. But do you know what features to use in Db2 for z/os in order to get compliant?

A first action every single company should consider is the introduction of the SECADM. The SECADM is the security administrator; this role is not activated by default. In order to activate the role, you need to set zPARM SEPARATE_SECURITY to YES. Once the role has been activated, only the SECADM (and the Install SYSADM) can control security objects in Db2. SYSADMs will no longer be able to access all the data within your subsystem without an explicit grant. Before, it didn’t matter for the law who could see data in Db2, but with GDPR sensitive data should only be accessible with the proper consent of the person related to that data. 

Before doing a deep dive into your data, you could easily start to hide data by default for your SYSADM. The SYSADM should be provided with a role in elevation mode that can be used incidentally and that needs a corresponding justification for its usage. This provides you with an activity log which is required by GDPR to defend your legal interest in the data. The elevation mode can be a mechanism in which the system administrator needs to argue why he wants to do a particular action and get a higher level of authority. After he has taken the action, the authority should be removed again. Technically this could be achieved using a pass ticket or make use of an interface that temporarily grants a role to the individual that needs to take the operational support action.

Next, it is vital to make usage of roles and trusted contexts. A trusted context identifies the end user and the request server; based on that information Db2 can assign different roles and apply different security.

The more information you can collect on the circumstances, with which data is collected, the better you can decide on what an end user is allowed to do or not do. You can refuse data, anonymize it or obfuscate it. Masks and labels allow you to implement policies on who can see what using a given role. As this could result in very complex administration, the use of additional data governance and data security tools will likely be necessary to support you throughout the implementation and operational support.

In order to fully obey the 'Privacy by design' stance of GDPR, which requires you to take notice of all privacy concerns in the design of your application, and likewise your database infrastructure, an additional implementation of data encryption is key for sensitive data. In Db2 11, advanced features have been introduced to encrypt data sets on disk (see for example Judy Tobias’ article on the world of Db2). This will protect the data at rest.

To protect data in transit, it should be made accessible only through Secure Socket Layers (SSL) which should allow you to decrypt data only when it is actually read and where it is actually read. The days that a mainframe DBA could ignore web security standards are over now. Ever since Db2 Connect was replaced by the data server driver this should have been a concern already, but now with GDPR the requirement to work securely on Db2 for z/OS has become equally important to the Business as even internal users are governed by GDPR.

Finally, there is the right to be forgotten, allowing consumers to request a company to delete sensitive data with regard to their person. Deleting someone’s data in operational data is not an easy task, let alone the deletion of personal data in backups or data archives with cold data. In order to facilitate this, I believe you could consider making usage of system backups and system backup restore mechanisms that allow you to restore the backup data in a different subsystem where it can be cleansed and archived again without the personal data that needs to be deleted following GDPR’s requirements.

GDPR requires you to delete sensitive data, unless you have legal grounds to maintain that data. In order to have legal grounds you need to lay down arguments that are either technical either legally backed. If you cannot prove that retaining this data will prohibit your business, you have no right to maintain that data and it must be deleted immediately. If you fail to do so, high fines may apply.

How you implement GDPR regulations in Db2 may not be straightforward and definitely more than one solution will exist to solve the requirements of the regulation. I hope I could already inspire you with a few ideas on how it could be dealt with. For DBAs this will be a great opportunity to expose their knowledge about ‘hidden’ features of Db2 that were considered too advanced before.

Recent Stories
Application Development Using node.js by Bimal Jha

Db2 for z/OS Native REST API

A RESTful Introduction