Planning Considerations When Using TDE

Oracle Database Considerations When Using TDE

OKM is compatible with certain Oracle Database configurations.

OKM is compatible with any of the following:

Single Instance, Oracle RAC One Node
Oracle Database High Availability Architectures
- Oracle Database with Oracle Real Application Clusters (Oracle RAC). Each node of the Oracle RAC system requires a configured pkcs11_kms provider for TDE to use. All nodes must share the same OKM agent ID for authentication. With Oracle RAC, the network topology uses a public and private network. The private network used for Oracle RAC node-node traffic may be shared with the OKM service network for better isolation of key retrieval traffic. Depending on how this private network is configured, this likely precludes agent failover to KMAs outside the private network such as KMAs in a remote site. See Integrate OKM and TDE for shared storage requirements with Oracle RAC and the pkcs11_kms provider configuration files.
- Oracle RAC Extended Cluster. In this configuration, KMAs within the OKM cluster must be colocated in the network with Oracle RAC nodes to minimize retrieval time.
- Oracle Exadata Database Machine.
Oracle Data Guard. All secondary databases access the same OKM cluster used by the primary database.
Multiple Database Instances. When running multiple independent database instances on a host, a PKCS#11 token must be configured for each instance. This amounts to creating an OKM agent for each database instance, and authenticating the agent to OKM through the token. Use the kmscfg tool to complete this task. When running multiple database instances under the same O/S user, but using different OKM agents, you must set the KMSTOKEN_DIR environment variable to a different location each time you invoke the kmscfg utility. See Configure Database for TDE for more information about the kmscfg utility. For more information about running multiple databases on the same host, refer to the document Oracle Advanced Security Transparent Data Encryption Best Practices, referenced at the beginning of this appendix.
Oracle RMAN
Oracle Data Pump

OKM Performance and Availability Considerations When Using pkcs11_kms

Some OKM functions should be performed on KMAs that are not servicing Oracle Database to improve performance.

Key retrievals for TDE through the pkcs11_kms token typically take 100-200 milliseconds per KMA access. When failovers occur, the response time is a multiple of the number of failover attempts. OKM backup and key transfer operations are resource-intensive activities that can impact OKM database performance. Plan carefully to determine when and where to perform OKM backups. Since OKM backups are cluster-wide, they can be performed on KMAs that are not servicing Oracle Database instances. Similarly, key transfer operations are also cluster-wide operations and can be performed on any KMA. Therefore, it is recommended that you choose a KMA that is not servicing busy Oracle Database instances.

Network and Disaster Recovery Planning When Using pkcs11_kms

Disaster recovery planning decisions influence the network configuration.

OKM cluster configuration must be planned in accordance with the Oracle Database servers and the enterprise's disaster recovery strategy. OKM networking options are very flexible and include multi-homed interfaces used by the OKM management and service network. Oracle recommends that TDE access be over the OKM service network. The pkcs11 provider's configuration directory is a new consideration for disaster recovery planning. Consider recovery scenarios for this storage area to avoid the need to reconfigure a pkcs11_kms token, especially when it is shared between nodes of an Oracle RAC.

For detailed information about OKM disaster recovery planning, refer to Disaster Recovery along with the Oracle database publications.

Key Management Planning When Using pkcs11_kms

Key management planning must address the key life cycle and security policies of the enterprise.

See About Key Lifecycles for information about NIST SP-800 key management phases and corresponding OKM key states.
See Re-Key Due to OKM Policy Based Key Expiration for information about an issue that can occur when a key policy is not set to a long enough time period.

Key Policy Considerations

All TDE master keys are Advanced Encryption Standard (AES) 256 bits generated by OKM. KMAs may contain a FIPS 140‐2 Level 3-certified hardware security module, such as an SCA 6000 PCIe card. When KMAs have this hardware security module, their keys are created by the hardware security module. Otherwise, cryptographic operations use the Solaris Crypto Framework's software token provider. See Manage Key Policies for more information.

Key Lifecycle — The key lifecycle is the primary configuration item with respect to key policy planning decisions. The periods for the operational phase of the key's lifecycle should be chosen based upon data retention needs and the frequency with which TDE master keys will be re-keyed. The TDE DDL supports specification of various key sizes for the master key, as does the schema encryption dialogs within OKM. Only AES 256 bit keys can be used with OKM.

Key Policy Encryption Period — The key policy encryption period defines the length of time for the key to be used in the protect and process (encrypt and decrypt) state of the lifecycle. This period should correspond to the time period for use of the master key before it should be re-keyed (for example, maximum one year for PCI).

Key Policy Cyptoperiod — The key policy cryptoperiod is the remaining time allotted for use of the master key to decrypt data during the process only (decrypt only) state of the key lifecycle. The length of this period should conform to the data retention requirements for the data protected by the TDE master key. Typically this value is a number of years corresponding to the enterprise policy for data retention (for example, a seven year retention period for US tax records). The rate at which new keys will be generated should not be a concern with TDE as re-key operations will likely be infrequent. However, if this becomes a concern, then consider lengthening the encryption period on the key policy and re-keying less frequently. You can also increase the OKM key pool size configuration parameter to direct the KMAs to maintain a larger pool of available keys. Multiple key policies may be defined for use with different types of databases as needs dictate.

Key Access Control Through Key Groups

It may be necessary to control access to keys managed by OKM when multiple database instances or multiple agents are accessing the OKM cluster for various purposes.

All OKM agents are assigned to at least one key group (a default key group assignment is required), which authorizes them to have access to the keys within those groups. The agent's default key group is the only key group within which a pkcs11_kms provider's agent will create keys.

Consider using multiple key groups when master keys do not need to be shared across database instances or hosts. An example might be to use one key group for production database instances and another key group for development/test databases, so that isolation is assured. Agents in the test database key group would then be blocked by OKM if they attempt to use a master key for a production database. Such an attempt would also be flagged in the OKM audit log and may be an indicator of a configuration error that could disrupt a production database.

TDE also provides isolation of master keys through their key label naming convention. In the PKCS#11 specification, key labels are not required to be unique. However, OKM enforces unique labels unless the agent includes a default key group attached to a key policy where "Allows Revocation" is true. In this case, OKM relaxes the uniqueness constraints and issues a warning instead of an error for duplicate labels.

If a label conflict occurs between different master keys for different database instances, the first label created is always returned. Any agent attempting to access a key that shares an identical label belonging to another key group will be denied by OKM. This is detected during a re-key operation, and the work around is to re-key until another, non-conflicting, label is generated.

Key and Data Destruction Considerations

Destruction of data to conform to data retention requirements can begin with the destruction of TDE master keys. How and when these keys should be destroyed is an important planning item. OKM provides for this and for tracking of OKM backups, which include these keys. Management of OKM backups is both a Disaster Recovery planning item and key destruction planning item.