With the introduction of pervasive encryption in 2017, many clients have embarked on their journey to protect their enterprise data with z/OS data set encryption in an attempt to help satisfy regulatory compliance and to help mitigate the risk of a data breach.
I have disk hardware level encryption. Isn’t that sufficient?
There are different layers of encryption for data at rest: full disk and tape encryption; file or data set encryption; database encryption; and application encryption. Hardware level encryption is still recommended for all storage devices where supported. Full disk and tape encryption provides 100% coverage for data at rest at the storage subsystem level. It provides protection against the potential exposure of sensitive user data stored on storage devices that may have been discarded, lost or stolen. However, no, this isn’t always sufficient.
First, let’s take a look at some of what z/OS data set encryption has to offer.
z/OS data set encryption provides the following benefits that many clients find very valuable:
- Application transparency. You can encrypt data typically without requiring application changes when invoking the standard access method APIs (VSAM, VSAM/RLS, BSAM, QSAM, BPAM). You supply an encryption key label during data set create via a keyword on one of the various allocation methods and, under the covers, the access methods encrypt data on writes, and decrypt data on reads.
- Enabled via policy. You can identify the data sets to be encrypted by specifying a key label via policies, such as RACF data set profile or SMS data class. By using the RACF data set profile, the security administrator is in control of which data sets should be encrypted and which key labels are to be used with those data sets.
- Data set-level granularity. You have complete flexibility in regard to how many encryption keys are to be used to protect your data. You can decide which data sets should be encrypted, and how many unique encryption keys are to be used with those data sets. For example, you can choose to use a unique key per application, where all data sets associated with the application use the same key. This is an important aspect as it relates to how data is protected via access control. Refer to separation of duties below.
- Encryption in flight and at rest. The data is encrypted in the host. The data remains encrypted in flight as it’s transferred over the SAN to be stored on disk, where it’s encrypted at rest. Data also remains encrypted during backup, migration and replication. As data is recalled, restored, and replicated, it is important to note that you must ensure that the data set’s encryption keys are available whenever and wherever an encrypted data set is accessed.
- Audit simplification. Encryption attributes are displayed along with data set metadata through various system services. Auditors can use enhanced tooling to validate compliance requirements, thus helping to reduce the time and effort needed to perform an audit.
And finally, many clients see the following as a critical differentiator for data at rest….drum roll…
- Separation of duties. You can limit who has the authority to access data in the clear, since it requires authority to the data set’s encryption key label. For example, you can choose to only allow the data owner to access the data in the clear by providing SAF access to the key label in addition to SAF access to the data set, while only allowing the storage administrator to manage the data set as a container by only providing SAF access to the data set, which is the access they already have. You can then show who has access to sensitive data by displaying access controls via system services. This allows you to potentially remove certain roles from compliance scope.
Therefore, although hardware level encryption can encrypt 100% of the data at rest, clients are finding that controls offered via z/OS data set encryption can be an advantage in further protecting their sensitive data by helping mitigate the risk of a potential breach and in responding to auditors evaluating certain regulations. For example, limiting who can access sensitive data in the clear provides stronger protection against stolen credentials, which is one of the leading causes of data breaches. Another example, being able to prove that certain data sets are encrypted according to an established security policy using system services or audit tooling may assist in satisfying some audit findings dealing with identifying protection of sensitive data.
That’s great! So can I encrypt everything?
Not quite. Providing data set encryption support for the different data set types has also been a journey. However, the available support could potentially already cover a great deal of your data.
2017:
VSAM and Sequential extended format data sets
Supports transparent access through VSAM, VSAM/RLS, BSAM and QSAM.
With the introduction of encrypted extended format data sets, this allowed exploitation by a number of products and solutions such as z/OS zFS, IBM Db2, IBM IMS™, middleware, logs, batch, and Independent Software Vendor (ISV) solutions.
Availability: V2R3 base
2019:
PDSEs
Supports SMS-managed data member PDSEs with transparent access through BPAM, BSAM and QSAM.
Availability: V2R4 base; V2R3 (OA56324)
2020:
Sequential basic and large format data sets
Supports SMS-managed basic and large format data sets with minimal to no application change through BSAM and QSAM. Encrypted basic and large format data sets have an 8-byte prefix on each block which may need to be taken under consideration.
Access via EXCP is NOT transparent and requires application changes. EXCP applications must change to support the 8-byte prefix on each block. They must also use the IGGENC macro to encrypt before writing and decrypt after reading. This support is designed in an effort to allow the z/OS ecosystem that rely on EXCP access to participate in the pervasive encryption journey with adjustments to their custom data bases.
Refer to section Data set encryption in publication z/OS DFSMS Using Data Sets for considerations and restrictions before converting to encrypted basic and large format data sets.
Availability: V2R5 base; V2R3/V2R4 (OA56622)
And there is more to come in this journey.
What else is important to understand?
Key Management!!! All of the benefits of z/OS data set encryption rest on establishing a robust key management strategy, which is essential to governing and safeguarding the encryption keys that protect your data. There are also various products that help with different aspects of key management, such as TKE for Crypto Express master keys and EKMF Web for operational data encryption keys.
I am ready to learn more! How do I get started?
An excellent resource is the Getting Started with z/OS Data Set Encryption Redbook. It provides an overview of data protection through IBM Z pervasive encryption with a focus on z/OS data set encryption. It describes the software and hardware components involved. The core of the publication includes planning and preparing of the environment as well as implementation steps. It also includes information related to the critical topic of key management.
Where can I find more information?
Refer to the IBM Z Pervasive Encryption content solution page for more information.
Follow the z/OS DFSMS Community to keep up to date on new features related to z/OS data set encryption, as well as other DFSMS enhancements.