Note: For more information, refer to the two white papers: 1) "Using Oracle Key Manager with Advanced Security Transparent Data Encryption" and 2) "Oracle's Advanced Security Transparent Data Encryption Best Practices" and the "OKM Administrator's Guide". |
Transparent Data Encryption (TDE) with an Oracle Key Manager is an optimal, one-stop, Oracle solution for reliable management of Oracle Database master keys.
Oracle Key Manager (OKM) is now certified with Oracle Advanced Security Transparent Data Encryption. This means that the same encryption technology used with Oracle StorageTek tape drives is now available for managing encryption keys for an Oracle Database 11gR2, including:
Oracle Data Guard
Oracle Exadata Database Machine
Oracle Data Pump
Transparent Data Encryption (TDE) provides the services used for encrypting and decrypting sensitive database information, either at the column level or the tablespace level. The Oracle Key Manager and Transparent Data Encryption solution provides enterprise-class key management for the Transparent Data Encryption universal master keys. This solution allows the keys to be managed outside of the database.
Policy-based key management using Oracle Key Manager (OKM) provides a robust and flexible solution for managing Transparent Data Encryption master keys.
Transparent Data Encryption (TDE) provides encryption services using a two-tiered key approach for both TDE column and tablespace encryption.
The first tier is a master encryption key used to encrypt.
The second tier table or tablespace data encryption keys are stored within the database.
TDE stores the master encryption key in an external security module (Oracle Wallet or HSM). Storing the master key in an HSM is a recommended security practice and is crucial to maintaining the highest level of security from various threats. Use of the Oracle Key Manager for the secure storage of the TDE master encryption keys is recommended. Lost keys mean lost data, so a key management system such as Oracle Key Manager (OKM), is highly recommended.
With TDE configured to use an OKM, the master encryption key is created by the OKM and safely protected. OKM protects keys through replication (multiple copies across the cluster) and through backups of the Oracle Key Manager itself.
Public-Key cryptography standards (PKCS) define a platform-independent standard. A PKCS#11 provider is available for Oracle Solaris and Oracle Linux and has been certified to interface TDE with Oracle Key Manager. This provider is called "pkcs11_kms." TDE can be configured to utilize the pkcs11_kms provider through its built-in support for Hardware Security Modules (HSMs).
The Oracle Solaris pkcs11_kms provider is a configurable component of the Solaris Cryptographic Framework and conforms to the standard Oracle Solaris services for administering PKCS#11 providers. For Linux, the pkcs11_kms provider is installed separately and then configured for use with Oracle Database.
The pkcs11_kms provider interacts with Oracle Key Manager for key creation and key retrieval operations. Encryption and decryption functions are performed in the database and not by Oracle Key Manager. PKCS#11 consumer applications such as TDE identify key objects using a label that they define. TDE generates this label during creation of a master key. The pkcs11_kms provider passes this label along to Oracle Key Manager where it is maintained as meta-data on the data unit. In Oracle Key Manager, keys are associated with data units and for the pkcs11_kms provider this relationship is always 1:1. Each time a new master key is created a data unit with the key's label is created along with the corresponding key object.
Careful thought should be given to planning the solution. The next few sections highlight some of the primary considerations to address in the planning phase.
Oracle Key Manager works with any of the following Oracle Database configurations:
Single Instance, Oracle RAC One Node.
Oracle Database High Availability Architectures.
Oracle RAC - Oracle Database with Oracle Real Application Clusters is certified with Oracle Key Manager. Each node of the Oracle RAC system needs to have a configured pkcs11_kms provider for TDE to use.
All nodes should share the same Oracle Key Manager agent ID for authentication. With Oracle RAC, the network topology utilizes a public and private network.
The private network used for Oracle RAC node-node traffic may be shared with the Oracle Key Manager 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.
Oracle RAC Extended Cluster - In this configuration, KMAs within the Oracle Key Manager cluster should be co-located in the network with Oracle RAC nodes so that key retrieval time is minimized.
Oracle Exadata Database Machine - See the Oracle RAC considerations.
Oracle Data Guard - All secondary databases access the same Oracle Key Manager cluster used by the primary database.
Multiple Database Instances - When running multiple independent database instances on a host, each instance needs to have its own PKCS#11 token configured.
This amounts to creating an Oracle Key Manager agent for each database instance and having the agent authenticate to Oracle Key Manager via the token. This can all be done through use of the kmscfg(1M) tool.
Oracle RMAN.
Oracle Data Pump.
Key retrievals for TDE through the pkcs11_kms token should typically take 100-200 milliseconds per KMA access. When failovers occur, the response time will be a multiple of the number of failover attempts. Backup and key transfer operations for Oracle Key Manager are database-intensive activities that can impact performance of the Oracle Key Manager database.
For this reason, thought should be given to when and where to perform Oracle Key Manager backups. Since Oracle Key Manager backups (and key transfer operations) 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. It is thus recommended to choose a KMA that is not servicing busy Oracle Database instances.
Disaster Recovery planning is a complex topic that is covered in the Oracle Key Manager Disaster Recovery Reference Guide and also in Oracle Database documents.
Disaster Recovery planning decisions influence the network planning exercise as well.
The pkcs11 provider's profile area is a new consideration for disaster recovery planning. Consider recovery scenarios for this storage area to avoid having to reconfigure a pkcs11_kms token, especially when it is shared between nodes of an Oracle RAC.
Oracle Key Manager cluster configuration needs to be planned in accordance with the Oracle Database servers and the enterprise's disaster recovery strategy. The networking options with Oracle Key Manager are very flexible and include multi-homed interfaces used by the Oracle Key Manager management and service network:
Oracle Key Manager Management Network - Each KMA in an Oracle Key Manager cluster contains a front-end network interface referred to as the management network. This interface is primarily intended for management of the various nodes of the Oracle Key Manager cluster and for KMA peer-peer replication of cluster data. For optimal cluster replication performance, a Gigabit Ethernet network is recommended. The service network is recommended for use by agents, but the management network may also be used.
Oracle Key Manager Service Network - The service network is intended for use by agents so that their key retrievals may be isolated from other network traffic. There are two Gigabit Ethernet ports on a KMA that are aggregated together for better reliability. It is recommended that TDE access be over the Oracle Key Manager service network. As briefly mentioned in the overview, the service network can be isolated to KMAs and agents within the same site by not defining a gateway to other sites. This may be desirable if other sites are too remote. For maximum availability though, configuring service network gateways to other Oracle Key Manager sites is an option to be considered.
Network Time Protocol - Configuring Oracle Key Manager system time to use an external NTP server is highly recommended.
Key management planning must address the key lifecycle and security policies of the enterprise. These considerations will naturally lead to discussions on data retention.
The keying material is not yet available for normal cryptographic operations. Keys may not yet be generated, or may be in the pre-activation state. System or enterprise attributes are established during this phase as well.
The keying material is available and in normal use. Keys are in the active state. Keys may be designated as protect only, process only, or protect and process. Oracle Key Manager supports the protect and process (encrypt or decrypt) and process only (decrypt only) sub-states of the active state.
The keying material is no longer in normal use, but access to the keying material is possible and the keying material may be used for process only (decrypt only) in certain circumstances. Keys are in the deactivated or compromised states.
Keys are no longer available. All records of their existence may have been deleted. Keys are in the destroyed or destroyed compromised states. Although the keys themselves are destroyed, the key attributes (for example: key name, type, cryptoperiod, and usage period) may be retained.
All TDE master keys are AES-256 bits and generated by Oracle Key Manager. KMAs may contain a Sun Crypto Accelerator 6000 PCIe Card, a FIPS 140-2 Level 3 certified HSM. When KMAs have this Hardware Security Module then their keys are created by the HSM. Otherwise, cryptographic operations utilize the Solaris Crypto Framework's software token provider. The key lifecycle is the primary configuration item with respect to key policy planning decisions. The periods chosen 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.
Note: The TDE's DDL supports specification of various key sizes for the master key as does the schema encryption dialogs within Oracle Enterprise Manager. Only AES-256 bit keys can be used with Oracle Key Manager. |
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). 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 will be some 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 are generated should not be a concern with TDE as re-key operations will likely be infrequent. If this becomes a concern, then consider lengthening the encryption period on the key policy and re-keying less frequently. The Oracle Key Manager key pool size configuration parameter can also be increased to have the KMAs maintain a larger pool of available keys.
Multiple key policies may be defined for use with different types of databases as needs dictate.
It may be necessary to control access to keys managed by the Oracle Key Manager when multiple database instances or multiple agents are accessing the Oracle Key Manager cluster for various purposes.
All Oracle Key Manager 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 a 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 Oracle Key Manager if they attempt to use a master key for a production database. Such an attempt would also be flagged in the Oracle Key Manager 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.
Oracle Key Manager enforces label uniqueness so that the scope of the label name space is global for an Oracle Key Manager cluster. Should a label conflict occur between different master keys for different database instances, the first label created will always be returned. If this is not the required behavior, then consider using key groups as a means for segregating agents. An agent attempting to access a key that shares an identical label belonging to another key group will be denied by Oracle Key Manager. This will be caught during a re-key operation and the work around will be to re-key until another, non-conflicting, label is generated.
Destruction of data to conform to data retention requirements can begin with the destruction of TDE's master keys. How and when these keys should be destroyed is an important planning item. Oracle Key Manager provides for this and also for tracking the Oracle Key Manager backups, which include these keys. Management of Oracle Key Manager backups is both a Disaster Recovery planning item and key destruction planning item.