How does z/OS data set encryption differentiate itself from other types of encryption for data at rest?
As clients begin their journey with pervasive encryption, they consider how best to protect their data in order to satisfy regulatory compliances and avoid potential data breaches. They often wonder how data set encryption differentiates itself from other types of encryption for data at rest, specifically hardware-level encryption. Understanding the value of each type of encryption helps clients pursue the approach that’s right for them.
You may have seen the encryption pyramid depicting different layers of encryption for data at rest: full disk and tape encryption; file or data set encryption; database encryption; and application encryption. Note that all encryption levels are complementary. Hardware encryption should be enabled for all storage devices where supported. Full disk and tape encryption provides 100% coverage for data at rest. It provides protection against the potential exposure of sensitive user data stored on storage devices that may have been discarded, lost or stolen. However, this isn’t always sufficient.
That’s where z/OS* data set encryption can help. With z/OS data set encryption, you can encrypt data without requiring application changes. You supply an encryption key label during data set create and, under the covers, the access methods encrypt data on writes, and decrypt data on reads. Data set encryption provides the following capabilities that differentiate it from hardware-level encryption:
- 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.
- Data set-level granularity. You can decide which data sets should be encrypted, and how many unique encryption keys are to be used. For example, a unique key per data set, one key for all data sets, one key for all data sets associated with an application, etc.
- Separation of duties. You can decide who has the authority to access data, since it requires authority to the data set’s key label. For example, you can choose to only allow the data owner to access the data, while the storage administrator can only manage the data set. This allows you to remove certain roles from compliance scope.
- Encryption in flight and at rest. The data is encrypted in the host. Therefore, the data is 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.
- Audit simplification. Encryption attributes are displayed along with data set metadata. Auditors can use enhanced tooling to validate compliance requirements.
Pervasive encryption is a journey. Learn more about z/OS data set encryption and why it may be the right choice for your enterprise data (bit.ly/2T1ZUw8).