Working with Data Encryption

Note:

Encryption is a licensed feature for certain models. For details, refer to the "Oracle Software License Agreement ("SLA") and Entitlement for Hardware Systems with Integrated Software Options" and the Licensing Information User Manual for the software release.

Oracle ZFS Storage Appliance offers transparent data encryption for individual shares (filesystems and LUNs) and shares created inside of projects. Starting with software release OS8.8.0, storage pools can be set to require encryption for all projects and incoming replication streams at pool creation time. When a pool is set to enable encryption of projects, shares will by default inherit the encryption settings from the pool. Pool encryption properties cannot be set during initial appliance setup or during reconfiguration after a factory reset because no keystore is configured.

Managing Encryption Keys

Oracle ZFS Storage Appliance includes a built-in LOCAL keystore and the ability to connect to the Oracle Key Manager (OKM) system. Each encrypted project or share requires a wrapping key from either the LOCAL or OKM keystores. The data encryption keys are managed by the storage appliance and are stored persistently encrypted by the wrapping key from the LOCAL or OKM keystore.

OKM is a comprehensive key management system (KMS) that addresses the rapidly growing enterprise need for storage-based data encryption. Developed to comply with open standards, this feature provides the capacity, scalability, and interoperability to manage encryption keys centrally over widely distributed and heterogeneous storage infrastructures.

OKM meets the unique challenges of storage key management, including:

  • Long-term key retention - OKM ensures that archive data is always available, and it securely retains encryption keys for the full data life cycle.

  • Interoperability - OKM provides the interoperability needed to support a diverse range of storage devices attached to mainframe or open systems under a single storage key management service.

  • High availability - With active N-node clustering, dynamic load balancing, and automated failover, OKM provides high availability, whether the appliances are sited together or distributed around the world.

  • High capacity - OKM manages large numbers of storage devices and even more storage keys. A single clustered appliance can provide key management services for thousands of storage devices and millions of storage keys.

  • Flexible Key Configuration - Per OKM cluster, keys can be generated automatically or created individually for a LOCAL or OKM keystore. Security administrators are responsible for providing the key names which, when combined with the keystore, associate a given wrapping key with a project or share.

Maintaining Keys

Shares and projects that use OKM keys that are in a deactivated state remain accessible. To prevent an OKM key from being used, the OKM administrator must explicitly delete the key.

To ensure encrypted shares and projects are accessible, back up your Oracle ZFS Storage Appliance configurations and LOCAL keystore key values. If a key(s) becomes unavailable, any shares or projects that use that key become inaccessible. If a project key is unavailable, new shares cannot be created in that project.

Keys can become unavailable in the following ways:

  • Keys are deleted

  • Rollback to a release that does not support encryption

  • Rollback to a release where the keys are not configured

  • Factory reset

  • The OKM server is not available

Encryption Key Life Cycle

The encryption key life cycle is flexible because you can change keys at any time without taking data services offline.

When a key is deleted from the keystore, all the shares that use it are unmounted and their data becomes inaccessible. Backing up keys in the OKM keystore should be performed using the OKM backup services. Backup of keys in the LOCAL keystore is included as part of the System Configuration Backup. For the LOCAL keystore, it is also possible to supply the key by value at creation time to allow it to be escrowed in an external system, which provides an alternative per-key backup/restore capability.