Changes in This Release for Oracle Key Vault

Oracle Key Vault 21.8 makes rolling out SSH key management easier by simplifying the upload of SSH public keys. New manageability features and operational security improvements make performing configuration, monitoring, and reporting tasks easier.

Changes for Oracle Key Vault Release 21.8

Oracle Key Vault release 21.8 introduces several new features.

Enforce Separation of Administrator Roles

Starting with Oracle Key Vault release 21.8, you can configure Oracle Key Vault such that an Oracle Key Vault user can have no more than one Oracle Key Vault administrative role.

In previous Oracle Key Vault releases, the Oracle Key Vault administrative roles (System Administrator, Key Administrator, and Audit Manager) could be granted to another Oracle Key Vault user by any user who currently has the role with Allow Forward Grant option.

Starting with this release, you enable Enforce Separation of Administrator Roles check from the Account Management tab of the System Recovery page to prevent the grant of more than one Oracle Key Vault administrative role to any Oracle Key Vault user. Each user can have at most one administrative role. Enabling the Enforce Separation of Administrator Roles option enforces administrative role isolation in Oracle Key Vault.

An Oracle Key Vault user may already have more than one administrative role when the Enforce Separation of Administrator Roles option is enabled. In this case, the user cannot exercise any of the administrative roles even though they have been granted to him. The additional roles have to be removed before the remaining one (intended) administrative role can become operational.

Console Certificate Supports Subject Alternative Name (SAN)

Starting with Oracle Key Vault release 21.8, Oracle Key Vault supports a fully qualified domain name (FQDN) for the console certificates without changing the hostname.

Prior to Oracle Key Vault release 21.8, you would have to change the hostname of the Oracle Key Vault to a fully qualified domain name (FQDN) of the Oracle Key Vault server when generating console certificates to avoid HTTPS certificate browser warnings.

Starting with Oracle Key Vault 21.8, this change is no longer necessary. You can retain the hostname when you add an FQDN as the subject alternative name for the console certificate. Subject alternative name (SAN) is an extension to the X.509 certificate specification that allows the inclusion of additional hostname in the certificate. You can also use this feature to resolve two FQDNs to the same Oracle Key Vault server, if needed. But in this case, you must change the hostname to one of the two FQDNs.

Alert for Platform Certificate Expiration and Server or Node Certificate Expiration

Starting with Oracle Key Vault release 21.8, an alert will be generated when the Oracle Key Vault platform certificates are going to expire within a period defined by the alert configuration.

Platform certificates are used when a new node is added to the cluster. These certificates are different from Oracle Key Vault service certificates and have different expiration dates. They are also rotated using a different method than Oracle Key Vault service certificates. You must rotate the platform certificates before they expire. You cannot upgrade an Oracle Key Vault system with the expired platform certificates. The default configuration for the alert is 90 days. You can change the configured value. The alert will be raised for standalone, multi-master cluster, and primary-standby deployments.

Related Topic

About Configuring Alerts

Upload of Public and Private Keys through okvutil

Starting with Oracle Key Vault release 21.8, you can upload Public and Private Keys through okvutil.

In earlier releases, RESTful services needed to be installed and configured to upload public and private keys to Oracle Key Vault. With Oracle Key Vault 21.8, okvutil has been enhanced to support uploading of public and private key directly, greatly simplifying the enforcement of remote server access controls for public key authentication.

Configurable Key Lengths for Service Certificates

Starting with Oracle Key Vault release 21.8, you can configure the key lengths for the service certificates.

You can choose to set the key length of the certificate authority (CA) certificate to either 2048 bits or 4096 bits. When the next CA certificate rotation is performed, the CA, server/node, and endpoint certificates will be generated with the selected key length. Service certificates with configurable key lengths enable compliance with corporate information security policies.

Changes for Oracle Key Vault Release 21.7

Oracle Key Vault release 21.7 introduces several new features.

Controlling Access to SSH Servers Centrally with Oracle Key Vault

Starting with this release, you can use Oracle Key Vault to centrally manage the access to the SSH servers within your enterprise.

SSH public key authentication is often the preferred method for accessing remote hosts for operation and administrative purposes. In an enterprise setting, multiple administrators grant or revoke access to enterprise users on large number of hosts within their domain. At this scale, the decentralized nature of the access control architecture quickly becomes overwhelming, making the system generally more prone to errors and thus more exposed to security risks.

Using Oracle Key Vault integration with the OpenSSH, you can now control access to the SSH servers centrally. Centralized access control improves security, enables quicker responses to threats, reduces human error and simplifies the server access management at scale.

With release 21.7, Oracle Key Vault adds a new type of endpoint - the SSH Server endpoint. The SSH Server endpoint type must be deployed on the SSH server to facilitate the integration with OpenSSH.

Oracle Key Vault 21.7 now introduces wallet types – SSH Server wallet and General wallet. The SSH Server wallet is associated with a host user on the SSH server and is meant to contain the authorized SSH public keys of the host user. You grant or deny access to the SSH servers by adding or removing the user’s SSH public keys from the SSH server wallets.

Oracle Key Vault now offers SSH server authorization, SSH server access, and other reports to simplify the management and monitoring of server access.

Improved SSH User Keys Management

Oracle Key Vault release 21.7 further improves the centralized SSH user keys management.

The Oracle Key Vault PKCS#11 library integrates with the OpenSSH to support the SSH public key authentication using a SSH key pair from Oracle Key Vault.

This enables the centralized management of SSH user keys in Oracle Key Vault. You can now create SSH keys explicitly. In the previous releases, generic public-private key pairs were used as the SSH keys, making it difficult to distinguish them from other public-private key pairs not used as SSH keys.

You can now associate an SSH user with the SSH Keys, making it easier to identify and monitor the keys. The SSH user is intended to track the actual consumer of the SSH keys, a human, an application, or a machine.

Oracle Key Vault now offers SSH private key authorization and access reports to simplify the management and monitoring of SSH keys. You can separately configure the expiration alerts for the SSH keys.

RESTful Services Utility Changes to Support SSH Keys Management

Starting with release 21.7, you can use the Oracle Key Vault RESTful services utility to create and register SSH keys and manage SSH Server wallets and SSH Server endpoints.

The following Oracle Key Vault RESTful services utility commands have been updated to support the SSH key pair creation and registration of SSH private and public keys:
  • okv managed-object key-pair create
  • okv managed-object private-key register
  • okv managed-object public-key register

A new option --ssh-user is added to these commands. Use of this option makes the underlying public and private key objects identified as the SSH keys.

To support the creation of SSH Server endpoint and SSH Server wallet, following commands have been updated:
  • okv admin endpoint create
  • okv manage-access wallet create

Support Key Creation from Oracle Key Vault Management Console

Starting with release 21.7, you can now create new keys and key pairs from Oracle Key Vault Management console. This allows Oracle Key Vault users to create the keys and key pairs. Previously, only endpoints could create security objects.

As an Oracle Key Vault user, you can now create generic or application specific keys and key pairs. As generic keys, Oracle Key Vault supports creation of symmetric keys and public-private key pairs.

The application keys category supports the creation of the TDE Master Encryption Key, Oracle GoldenGate Master Key, and SSH Key Pair. Once the application key is created, the corresponding application must then be configured to make use of the key from Oracle Key Vault.

At the time of key creation, you can select key algorithm and key length, set the key expiration date, and control whether the key is extractable outside of the Oracle Key Vault cluster boundary.

User created keys can be used by endpoints as usual as long as endpoints can access them.

Support for Node or Cluster Scope for Alerts in Multi-Master Cluster

Starting with Oracle Key Vault release 21.7, in a multi-master cluster, you can set the configuration for certain alerts at the Node or Cluster scope.

In earlier releases, in a multi-master cluster, the same alert configuration was always applied to each cluster node. Using the same alert setting across cluster nodes may not always be ideal. For example, if the system is configured to take backup from a particular node, it is not ideal for the other nodes to raise the System Backup was never done alert. For such nodes, you can set the node scope and turn off the alerts only on these nodes.

Oracle Key Vault 21.7 makes the alert configuration even more flexible by allowing node specific configuration for below alerts:

  • Fast Recovery Area Space Utilization
  • High CPU Usage
  • Failed System Backup
  • High Memory Usage
  • Disk Utilization
  • System Backup

You can even enable or disable these alerts at the per node level. On a given node, the node scope configuration overrides the cluster scope configuration for the same alert.

Setting the Initial Password for the support and root User

Starting with release 21.7, the initial password for the support and root user can no longer be set from the Oracle Key Vault management console during the post-installation steps.

With release 21.7, the root user password continues to be the one that is specified during the initial phase of Oracle Key Vault installation.

The initial password for the support user can now by set by logging in to the Oracle Key Vault terminal console as the root user immediately after the install.

Changes for Oracle Key Vault Release 21.6

Oracle Key Vault release 21.6 introduces several new features.

Ability to Restrict the Extraction of Private Encryption Keys from Oracle Key Vault

Oracle Key Vault 21.6 allows private keys uploaded to Oracle Key Vault to be marked as non extractable, so that they do not leave the Oracle Key Vault deployment boundary.

You can now restrict private keys, as well as symmetric keys, and make them non-extractable by setting the extractable attribute value to false. The false attribute value ensures that the cryptographic objects remain within the Oracle Key Vault boundary.

To control whether private encryption keys can be retrieved (extracted) from Oracle Key Vault, you can use the Oracle Key Vault management console, RESTful services utility commands, the C SDK APIs, and Java SDK APIs.

Ability to Create Asymmetric Key Pairs in Oracle Key Vault

Starting release 21.6, you can now create an asymmetric key pair in Oracle Key Vault.

You may create the private key as non-extractable, or make it non-extractable afterward to ensure that the private key never leaves the Oracle Key Vault deployment boundary.

You can create an asymmetric key pair using RESTful services utility commands, C and JAVA SDK APIs.

With the support of the non-extractable private keys and the sign operations on-board Oracle Key Vault, you can now implement public key authentication using openssh and Oracle Key Vault’s PKCS#11 library such that user’s ssh private key never leaves Oracle Key Vault. During public key authentication, the PKCS#11 library now performs the sign operation within Oracle Key Vault itself. This helps you in enforcing centralized key governance and eliminating locally downloaded, vulnerable private keys.

Ability to Clone an Oracle Key Vault VM

Starting with Oracle Key Vault 21.6, a fresh installation of an Oracle Key Vault VM guest can be stored as a template, and the VM platform cloning capability can be used to clone Oracle Key Vault cluster nodes.

With Oracle Key Vault cluster, using the cloned template, the system administrator can significantly shorten the provisioning time, compared to performing a full installation of each individual cluster node.

Oracle Key Vault supports the cloning feature of the underlying virtualization platform. This eliminates the need to go through the full installation process for each individual cluster node. You can clone an Oracle Key Vault system (installed as a VM) after the installation is complete, but before performing post-installation tasks. When a clone is started up for the first time, it goes through a series of steps to regenerate system-specific configuration that makes it unique (and separate from all other clones). The (remote) cloning capability provided by virtualization platforms allows to clone from an Oracle Key Vault Template, which is an Oracle Key Vault installation that is stopped before this Oracle Key Vault is made unique. It regenerates all of the system-specific configuration; the clone becomes unique by completing the remaining installation steps.

Support the Ability to Provide an Alternate Host Name or an IP Address

Starting Oracle Key Vault 21.6, you can configure Oracle Key Vault with a fully qualified domain name or IP address, such as the public IP address of systems running in cloud infrastructure environments.

Oracle Key Vault provides the ability to provide two alternate host names. You can choose whether to have endpoints use one of these alternate host names when communicating with the Oracle Key Vault server or node. The alternate host name is required to be provided for each node and you can also choose if the endpoint should use the provided host name in a multi-master cluster environment.

This feature is not supported in (deprecated) primary-standby deployments.

Support SAMLv2 Based Single Sign-On (SSO) Authentication for Oracle Key Vault

Starting with Oracle Key Vault release 21.6, Oracle Key Vault supports SAML based Single Sign-On (SSO) authentication.

Oracle Key Vault 21.6 now supports SSO. The SSO feature is SAML based and the user is authenticated via an Identity Provider (IdP). The IdP supported Single Sign-On (SSO) Authentication provides multi-factor authentication (MFA). This provides the ability to minimize the login attempts to one set of credentials hence improving the enterprise security. Single Sign-On (SSO) Authentication is part of an identity and access management (IAM) solution, it utilizes a central directory that controls user access to resources at a more granular level. This allows organizations to comply with regulations that require provisioning users with appropriate permissions. The SSO solution also de-provisions users quickly, another common compliance requirement meant to ensure that former employees, partners, or others cannot access the sensitive data.

Support for Unified Application-Level Tracing and Simplified Diagnostics Collection

Starting with Oracle Key Vault release 21.6, a unified application-level tracing is introduced with the ability to centrally control the tracing level. The diagnostics download process is also simplified.

Previously, to collect the diagnostics, the system administrator log on to the Oracle Key Vault management console, download the readme, log on to the Oracle Key Vault server as a root user, and run commands manually to install the diagnostics utility, and enable selected log options. The system administrator then logs back on the Oracle Key Vault management console to download the diagnostics bundle.

Oracle Key Vault release 21.6 simplifies the process. The system administrator now log on to the Oracle Key Vault management console, select the required diagnostics to download and click the download button.

In addition, to facilitate a centralized trace generation, Oracle Key Vault release 21.6 introduces a component based tracing that allows the system administrator to adjust the trace level for specific Oracle Key Vault components from the Oracle Key Vault management console. These trace levels (in increasing levels of severity) are: MANDATORY, ERROR, WARNING, INFO, and DEBUG.

Aborting Oracle Audit Vault Integration with Oracle Key Vault

Starting with Oracle Key Vault 21.6, Oracle Key Vault integration with Oracle Audit Vault can be aborted, when integration is not successful.

From the Oracle Key Vault management console you can now Abort the integration of AVDF. This is helpful when the integration of AVDF takes longer than usual time to get integrated with Oracle Key Vault.

Event ID Support in Auditing Records

Starting with Oracle Key Vault release 21.6, all the operation events are now categorized using the event IDs.

This feature adds a new field, Event ID, to Oracle Key Vault audit records. The Event ID represents a stable identity that is uniquely associated with an audited operation (type).

  • Multiple audit records for the same audit operation use the same Event ID.
  • Event IDs remains unchanged and remains mapped to the same operation forever as the Event IDs are statically baked into the Oracle Key Vault source code.
  • The text description of the Operation, however, could still change across releases.
  • New operations that are added as part of the new functionality will be given new unique Event ID.

Related Topics

Support for Disk and Network I/O and Application Metrics in Oracle Key Vault Metrics Framework

Starting with Oracle Key Vault release 21.6, Oracle Key Vault expands the metrics framework to include Disk, Network I/O, and Application metrics.

This feature adds metrics for Disk, Network I/O, Application metrics. The current available metrics at any time in Oracle Key Vault helps in determining the system capability and resource usage.

  • Disk I/O: Gives insight into database cache assuming most of the Oracle Key Vault activities are going to be from the database.
  • Network I/O: Gives insight into number of bytes received/sent during a particular time interval. You can compare the data with the historical date to analyze the usage and activity of endpoints. This also provides data as an average value.
  • Application: Gives insight into number of KMIP connections accepted to process the connections in an interval.

Related Topics

Support for Sign and Signature Verify Operations

Starting release 21.6, Oracle Key Vault C and Java SDKs now provide Sign and Verify capability.

You can use either RESTful services utility commands, okvutil, or C and Java SDK to perform sign and signature verify operations.

C SDK APIs

  • KMIP cryptographic operations are as follows:
    • okvSign
    • okvSignVerify
  • Cryptographic utility operations are as follows:
    • okvCryptoContextGetCryptoAlgo
    • okvCryptoContextGetHashingAlgo
    • okvCryptoContextGetDigitalSignAlgo
    • okvCryptoContextSetHashingAlgo
    • okvCryptoContextSetCryptoAlgo
    • okvCryptoContextSetDigitalSignAlgo
    • okvCryptoResponseGetSignatureData
    • okvCryptoResponseGetRecoveredData
    • okvCryptoResponseGetValidity
    • okvSignResponseCreate
    • okvSignVerifyResponseCreate
    • okvSignResponseFree
    • okvSignVerifyResponseFree

Java SDK APIs

  • KMIP cryptographic operations are as follows:
    • okvSign
    • okvSignVerify
  • Cryptographic utility operations are as follows:
    • getCryptoAlgo
    • getHashingAlgo
    • getDigitalSignAlgo
    • setCryptoAlgo
    • setHashingAlgo
    • setDigitalSignAlgo
    • getSignatureData
    • getRecoveredData
    • getValidity

Oracle Key Vault Deployments in Microsoft Azure and Amazon AWS

Starting with Oracle Key Vault release 21.6, you can deploy Oracle Key Vault on Microsoft Azure and Amazon AWS cloud platforms.

In addition to on-premises data centers and Oracle Cloud Infrastructure (OCI), Oracle Key Vault 21.6 can also be deployed in Microsoft Azure and Amazon AWS.

Endpoint IP Address Attribute Added to endpoint get RESTful Command

Oracle Key Vault supports endpoint IP address in the endpoint get RESTful command.

The endpoint IP address that was used at enrollment time is now recorded, and displayed with the okv admin endpoint get --endpoint endpoint_name command.

Sign and Signature Verify APIs

Oracle Key Vault Client SDK release 21.6 adds the support for the sign and signature verify operations.

You can use RESTful services utility commands to perform sign and signature verify operations.

  • KMIP cryptographic operations are as follows:
    • okvSign
    • okvSignVerify
  • Cryptographic utility operations are as follows:
    • okvCryptoContextGetCryptoAlgo
    • okvCryptoContextGetHashingAlgo
    • okvCryptoContextGetDigitalSignAlgo
    • okvCryptoContextSetHashingAlgo
    • okvCryptoContextSetCryptoAlgo
    • okvCryptoContextSetDigitalSignAlgo
    • okvCryptoResponseGetSignatureData
    • okvCryptoResponseGetRecoveredData
    • okvCryptoResponseGetValidity
    • okvSignResponseCreate
    • okvSignVerifyResponseCreate
    • okvSignResponseFree
    • okvSignVerifyResponseFree

Improved Audit Record Messages

With Oracle Key Vault release 21.6, audit record messages are modified to improve for consistency and style.

The object information in the audit record is no longer included in the audit record messages (operation texts). Instead, object information is available under the object column.

Support Endpoint Communication With Oracle Key Vault Using a Secondary IP address or Fully-Qualified Domain Name

Up until Oracle Key Vault release 21.6, the endpoints of an Oracle Key Vault (OKV) system could communicate with it only via its IP address. In particular, for those OKV instances provisioned on Oracle Cloud Infrastructure (OCI) compute instances (which have both a public and private IP), endpoint to Oracle Key Vault communication was via the Oracle Key Vault private IP only.

Starting Oracle Key Vault release 21.6, the Oracle Key Vault system can be configured with a secondary IP address, or a fully-qualified domain name (FQDN) (both of which are referred to as alternate hostname in subsequent text). You can configure at most two such alternate hostnames for a given Oracle Key Vault system. Optionally, you can also choose to have endpoints communicate with the Oracle Key Vault server/node using one of these alternate hostnames. In a multi-master cluster environment, the configuration of an alternate hostname is node-specific: each node that is to have an alternate hostname must be separately configured.

Note:

This feature is not supported in primary-standby deployments (deprecated in Oracle Key Vault release 21.5).

Changes for Oracle Key Vault Release 21.5

Oracle Key Vault release 21.5 introduces several new features.

Support for SSH Public Key Authentication using SSH User Keys from Oracle Key Vault

Starting in Oracle Key Vault release 21.5, you can use SSH key-based authentication with a key pair stored only in Oracle Key Vault.

The Oracle Key Vault PKCS#11 library supports SSH public key authentication using a SSH key pair that is uploaded to Oracle Key Vault. The centralized management of SSH user keys in Oracle Key Vault simplifies key life-cycle management, enables key governance and makes it easier to enforce policies. You can centrally perform actions such as, rotating the keys and revoking them when needed. This also allows you to minimize the risks that are associated with the SSH user keys footprint on local disks.

Automatic Purging of Audit Records Based on a Retention Policy

Starting in Oracle Key Vault release 21.5, you can now purge the old audit records automatically based on a retention policy.

You can now better manage the disk space consumed by Oracle Key Vault audit records without the need to manually delete them once they are deemed no longer needed. You can configure Oracle Key Vault to automatically purge older audit records based on a retention policy. For example, you can configure and apply a policy to automatically purge audit records that are older than 180 days.

Ability to Rotate Endpoint Certificates

Starting in Oracle Key Vault release 21.5, you can rotate an endpoint in order to increase its certificate validity without incurring endpoint downtime.

With Oracle Key Vault release 21.5, you can rotate an endpoint in order to increase its certificate validity without incurring endpoint downtime. Previously, this could only be done by re-enrolling the endpoint. You can choose to rotate multiple endpoints at once if required. Rotating an endpoint certificate this way is independent of the CA or server/node certificate rotation processes.

Related Topics

Endpoint and Endpoint Group Privileges Support for LDAP Users

Starting in Oracle Key Vault release 21.5, you can grant the endpoint and endpoint group privileges to LDAP users through the LDAP group mappings.

The privileges to the LDAP users are granted through the LDAP groups mappings. You map the endpoint or endpoint group privileges to an LDAP group. LDAP users that are members of this group are granted the mapped endpoint or endpoint group privileges at the time of login.

User Account Management

Starting in Oracle Key Vault release 21.5, you can configure the user account profile parameters to meet your corporate user management security policies for the Oracle Key Vault users.

User account profile parameters govern the rules and requirements for the user passwords, and the account lockout behavior of Oracle Key Vault users. These settings apply to Oracle Key Vault users that are created locally. For LDAP users, the user account management policies are managed in the LDAP directory server.

Oracle Key Vault now also supports unlocking of a user account through a password reset. An Oracle Key Vault administrator can unlock a user account by resetting the user’s password.

Related Topics

Severity based Alert Categorization

Starting in Oracle Key Vault release 21.5, alerts are categorized based on their severity levels to improve ease of administration.

Oracle Key Vault supports several types of alerts. Oracle Key Vault now categories these alerts to one of the severity levels: CRITICAL, HIGH, MEDIUM, and LOW. The home page of the Oracle Key Vault management console now displays the unresolved alerts in the order of their severity. Oracle Key Vault administrators can now easily identify most critical alerts that need immediate attention to ensure operational continuity.

Related Topics

Displaying Endpoint Group Membership Column in Endpoint Metadata Report

Starting with Oracle Key Vault release 21.5, additional column for Endpoint Group Membership is available in Endpoint Metadata Report.

The Endpoint Metadata Report displays endpoint information and deployment configuration detail. The Metadata Report now displays the Endpoint Group Membership column.

The Endpoint Group Membership information is useful when:
  • Granting privileges to Endpoint group
  • Performing the Endpoint rotation

Ability to Determine Time of Last Endpoint Activity


Starting in Oracle Key Vault release 21.5, you can quickly determine when an endpoint was last active by checking the Endpoints page on the Oracle Key Vault Management Console.

Starting in Oracle Key Vault release 21.5, you can determine when an endpoint was last active from the Oracle Key Vault Management Console by navigating to the “Endpoints” page and checking the “Last Active Time” column for that endpoint. This information can be useful in quickly determining which endpoints are unused. Previously, the only way to glean this information was from the endpoint activity reports (in particular, in a multi-master cluster, by consolidating all of the endpoint activity reports from all nodes of the cluster).

UEFI Support for OCI marketplace Image

Starting in Oracle Key Vault release 21.5, the Oracle Key Vault OCI marketplace images are available in UEFI mode only.

The OCI marketplace images of the earlier versions of Oracle Key Vault continue to use the BIOS mode.

Separate Alerts for CA Certificate Expiration and Server/Node Certificate Expiration

Starting in Oracle Key Vault release 21.5, you can configure the alerts for the CA certificate expiration and server/node certificate expiration separately.

You can configure different threshold values for these alerts. The default threshold value for CA certificate expiration is 90 days, while that for server/node certificate expiration is 60 days. Having separate alerts makes it easier to determine when a server/node certificate rotation is to be performed. The server/node certificate rotation is short and quick process performed on a per-node basis, as opposed to a CA certificate rotation which affects the entire Oracle Key Vault deployment and involves multiple steps. Previously, a single alert type 'Oracle Key Vault Server Certificate expiration' was raised when either the CA or the server/node certificate was expiring within the configured server certificate expiration threshold.

Changes for Oracle Key Vault Release 21.4

Oracle Key Vault release 21.4 introduces new features that affect this guide.

Ability to Control the Extraction of Symmetric Encryption Keys from Oracle Key Vault

Starting in Oracle Key Vault release 21.4, to strengthen the protection of symmetric keys, you now can restrict these keys from leaving Oracle Key Vault.

This restriction applies to the key material of the symmetric keys, but not its metadata. For example, Transparent Database Encryption (TDE) master encryption keys are stored in Oracle Key Vault. When an endpoint needs to decrypt the key, the PKCS#11 library fetches the TDE master encryption key from Oracle Key Vault to perform the decryption. If your site requires that symmetric keys never leave Oracle Key Vault, then you can configure these keys to remain within Oracle Key Vault during operations. In this case, the PKCS#11 library will send the encrypted data encryption key to Oracle Key Vault. Decryption is then performed within Oracle Key Vault and afterward, the plaintext data encryption key is returned to the PKCS#11 library. The Oracle Key Vault PKCS#11 library performs the encryption and decryption operation within Oracle Key Vault if the TDE master encryption key is restricted to leave Oracle Key Vault, or if it cannot be extracted from Oracle Key Vault.

To control whether symmetric encryption keys can be retrieved (extracted) from Oracle Key Vault, you can use the Oracle Key Vault management console, RESTful services utility commands, the C SDK APIs, and Java SDK APIs.

Enhancements to Certificate Management

Starting in Oracle Key Vault release 21.4, several enhancements to the management of certificates are available.

The enhancements are as follows:

  • Support for using an Oracle Key Vault certificate authority (CA) certificate that has been signed by an external certificate signing authority: You can choose to have the CA certificate issued by a third-party signing authority. This option can be exercised by first generating a certificate signing request (CSR), having that CSR signed by the external signing authority, and then uploading that signed CA to Oracle Key Vault. You will then be required to perform a CA certificate rotation so that all certificates on board Oracle Key Vault (endpoint certificates as well as those used for communication between Oracle Key Vault multi-master cluster nodes) are re-issued by the new CA. In previous releases, the Oracle Key Vault CA certificate was always self-signed.
  • Ability to configure a validity period of Oracle Key Vault self-signed root CA certificate: You can configure the certificate validity period of the Oracle Key Vault self-signed CA. The new validity period would take effect the next time a CA certificate rotation is performed. Previously, this value was fixed and unchangeable.
  • In multi-master cluster environments, the ability to set the order in which endpoints are rotated during the Oracle Key Vault CA certificate rotation process: This enhancement enables you to configure the order in which endpoints are rotated during a CA certificate rotation. Starting in this release, the endpoints are, by default, rotated in order of endpoint certificate expiry (that is, those expiring soonest are rotated first). You can also choose to order the endpoint rotation by providing a cluster subgroup priority list before initiating a CA certificate rotation. Then, during the CA certificate rotation process, endpoints that belong to cluster subgroups higher in the priority list are rotated before those in lower-priority cluster subgroups. In previous releases, when a CA certificate rotation was performed, the endpoints were rotated in random order.
  • Ability to configure a batch number of endpoints rotated during an Oracle Key Vault CA certificate rotation: You can configure the number of endpoints that can be in the Updating to current certificate issuer state at a given point in the CA certificate rotation process. You can configure this value based on the number of endpoints in the Oracle Key Vault configuration. Previously, this value was static and release dependent (for example, at most, 15 endpoints could be in this state in Oracle Key Vault release 21.3).
  • Ability to rotate Oracle Key Vault server and node certificates: Starting in this release, the certificates that are used for communication between Oracle Key Vault systems (cluster nodes in a multi-master cluster environment, or primary and standby environments), and for communication between an Oracle Key Vault system and its endpoints are now known as server certificates (in standalone or primary-standby environments) and node certificates (in multi-master cluster environments). This enhancement provides greater operational flexibility, because you now can choose different validity periods for the Oracle Key Vault CA certificate and server and node certificates. You then can rotate the server and node certificates as often as needed, without needing to go through the entire CA certificate rotation process.

Support for Policy Based Automatic Purging of Old Oracle Key Vault Backups

Starting in Oracle Key Vault release 21.4, you can manually remove the local Oracle Key Vault backup or create a policy to schedule the removal of one or more remote backups.

You can now better manage the disk space consumed by Oracle Key Vault backups on remote backup destination servers without the need to manually delete them once they are deemed no longer needed. You can configure Oracle Key Vault to automatically purge older backups from a remote backup destination based on a policy. For example, you can configure and apply a policy to a remote backup destination to automatically purge backups that are older than 30 days unless the backup is among the 10 more recent backups. In addition, you can now manually delete a local Oracle Key Vault backup.

Ability to Restrict Oracle Key Vault Administrative Role Grants

Starting in Oracle Key Vault release 21.4, you can control whether a grantee of an Oracle Key Vault administrative role can grant the role to other Oracle Key Vault users.

In previous releases, the Oracle Key Vault administrative roles (System Administrator, Key Administrator, and Audit Manager) could be granted to another Oracle Key Vault user by any user who currently has the role. Starting with this release, when an administrator grants the role to another user, the administrator can restrict whether the grantee user can in turn grant the role to other users. This enhancement improves overall user security and helps to adhere to good least privileges practices.

Client IP Address in the Oracle Key Vault Audit Trail

Starting in Oracle Key Vault release 21.4, the Oracle Key Vault audit trail has one new field: Client IP.

The Oracle Key Vault audit trail contains fields to capture information such as the name and type of the entity that performed an operation, the time the operation was performed, the node in which an operation was performed, and the result of the operation. The addition of the Client IP field enables users to better find where operations were performed, particularly in Cloud environments.

Support for Additional Monitoring Information Through SNMP

Starting in Oracle Key Vault release 21.4, additional monitoring information is available through the SNMP nsExtendOutputFull MIB base variable.

The nsExtendOutputFull MIB base variable now returns the following values:

  • Oracle Audit Vault monitor status
  • Oracle Audit Vault agent status
  • Server or CA certificate expiration information (whichever certificate expires sooner)

Changes for Oracle Key Vault Release 21.3

Oracle Key Vault release 21.3 introduces new features that affect this guide.

Enhancements for the Oracle Audit Vault Integration with Oracle Key Vault

Starting in Oracle Key Vault release 21.3, the integration of the Oracle Audit Vault component of Oracle Audit Vault with Oracle Key Vault has been made more secure and easier to accomplish.

This enhancement includes the following changes in functionality:

  • Change in System Administrator and Audit Manager roles: Users who have the System Administrator role no longer can perform the Oracle Audit Vault integration. Instead, for better separation of duty, only a user who has been granted the Audit Manager role can perform the integration. In previous releases, only users with the System Administrator role could perform the integration. However, users who have the System Administrator role can check if the Audit Vault monitoring process is active.
  • Easier integration process: A user with the Audit Manager role now can use the Oracle Key Vault management console to perform all the Oracle Audit Vault integration steps. In previous releases, an Oracle Key Vault administrator had to manually perform steps such as downloading and installing the Audit Vault agent to perform this integration.

Alert for Fast Recovery Area Space Utilization

Starting in Oracle Key Vault release 21.3, an alert will be generated when the Fast Recovery Area Space utilization of the Oracle Key Vault's embedded database exceeds the configured threshold value.

By default, the configured threshold value is 70% and the alert is available for standalone, multi-master cluster, and primary-standby environments. The new alert enables you to better monitor the Fast Recovery Area space usage of the Oracle Key Vault's embedded database.

Related Topics

Cluster Redo Shipping Status Alert Message Change

Starting in Oracle Key Vault release 21.3, the Cluster Redo Shipping Status alert notification message has changed.

In previous releases, users were alerted only when the redo-shipping status was active (up) or inactive (down). The message now, in addition to this information, indicates whether the node in the cluster is operating in read-only mode or is no longer in read-only mode.

Related Topics