Conceptual information for Oracle Key Vault covers use cases; how the access control configuration, deployment architectures, and administration works; and roles of the endpoint administrators.
Oracle Key Vault provides a secure, central repository for security objects, such as keys, certificates, passwords, and opaque objects. As an enterprise key management platform, Oracle Key Vault provides a central platform to manage these security objects and their lifecycle.
Oracle Key Vault keeps track of all the endpoints that you enroll with it. Endpoints are the database servers, application servers, and computer systems where actual cryptographic operations such as encryption or decryption are performed. Endpoints request Oracle Key Vault to store and retrieve security objects.
Endpoints must be registered and enrolled to communicate with Oracle Key Vault. Some endpoints, which can generate keys or already possess keys, use Oracle Key Vault as a secure, long-term external storage.
Oracle Key Vault access control facilities provide the flexibility to meet the needs of almost any organization.
Oracle Key Vault allows grouping of keys and other security objects to form a virtual wallet. The main purpose of a virtual wallet is to allow access to security objects by endpoints other than the endpoint that created the objects. Any user can create a new virtual wallet and then add keys to which they have access to that wallet. After you create the empty wallet, you can add any keys to which you have Read and Modify access, to any wallet where you have Manage Wallet access.
Note:Some endpoints may already have Oracle wallet files. You can extract the security objects from the wallet files, upload them to Oracle Key Vault, and then add those objects to a virtual wallet.
In Oracle Key Vault, one security object may belong to multiple wallets. Every security object has an owner, which is the endpoint that created the security object. This owner has Read and Modify access to the security object, even if the security object is not included in any virtual wallet.
An endpoint might need to share these security objects with its trusted peers. For example, an Oracle Database Real Application Clusters (Oracle RAC) node might need to share keys with other nodes in the cluster.
During enrollment of an endpoint, you can specify a default wallet. Keys created or uploaded by the endpoint are automatically added to the default wallet.
Multiple endpoints can have a common default wallet. The contents of this default wallet are shared across all the endpoints without the need to specify an endpoint group for these endpoints. This enables endpoints to create keys or upload an Oracle wallet without specifying a virtual wallet to contain the keys.
Oracle Key Vault audits all actions performed by users and endpoints.
Use cases for Oracle Key Vault include centralized storage and management.
Centralized Storage of Oracle Wallet Files and Java Keystores
Centralizing Management for a TDE Direct Connection of TDE Master Keys
Oracle Key Vault stores copies of Oracle wallet files and keystores in a centralized location for long-term retention and recovery.
Oracle Key Vault stores the security objects from Oracle wallets and Java keystores in a centralized location so they can be downloaded to a new wallet or keystore file when needed.
Without Oracle Key Vault, Oracle wallet files and Java keystores are often dispersed across servers and server clusters and require manual backup to prevent accidental loss of keys. Managing these dispersed objects poses operational as well as security challenges, which the Oracle Key Vault centralized storage platform can prevent.
Oracle Key Vault also enables sharing of Oracle wallet files and keystore files with trusted server peer endpoints. The endpoint software can read the format of Oracle wallet files and keystores and itemize each element of the Oracle wallet files or keystores, and perform a backup, element by element. You can upload both password-protected and auto-login wallets, and then download the wallet contents to a new wallet of either type.
Because the endpoint utility can interpret the contents of Oracle wallet files and keystores, users can manage the individual objects separately, including grouping them to share with other endpoints.
Oracle wallet files
Oracle Key Vault stores and manages the content of Oracle wallet files: symmetric keys (TDE master keys) for encryption, passwords (Secure External Password Store), and X.509 certificates (network encryption).
Oracle Key Vault stores and manages the content of Java keystores: symmetric keys, asymmetric keys such as private keys, and X.509 certificates.
Oracle wallet files from all supported releases of Oracle Database are supported. Oracle Key Vault supports both JKS and JCEKS types of Java keystores.
Figure 2-1 illustrates the centralized storage of Oracle wallet files and Java keystores.
Figure 2-1 Centralized Storage of Oracle Wallet Files and Java Keystores
Oracle Database Advanced Security Guide for topics related to Oracle wallet files (but note that in Oracle Database 12c, TDE wallets are called keystores)
For Oracle databases using TDE, Oracle Key Vault provides centralized management of TDE master keys over a direct network connection as an alternative to copying local wallet files to multiple endpoints.
In this use case, TDE generates the master key and stores it in Oracle Key Vault.
Sharing TDE master keys rather than maintaining local wallet copies is especially useful when TDE is running on database clusters such as Oracle RAC, as the following comparison shows:
With a local wallet copy, for each Oracle RAC node, when a key rotation operation is performed on the master key in the primary node, the local wallet copy is updated and must then be manually copied to other nodes in the Oracle RAC cluster to propagate the new TDE master key.
With the shared TDE keys that Oracle Key Vault provides, a new TDE master key is immediately shared with other nodes in a cluster after a key rotation operation and does not require manual copying of the wallet.
Centralized management is also helpful when copying encrypted data between databases using Oracle Data Pump Export, Import, or the transportable tablespaces of Oracle Database if master keys are stored in the wallet:
Without centralized management, the wallet must be manually copied from source to target databases.
With centralized management, these master keys are easily shared through Oracle Key Vault by granting each endpoint access to a virtual wallet that contains the master keys.
Direct network connections between TDE and Oracle Key Vault are supported on Oracle Database 11g Release 2 and Oracle Database 12c.
Figure 2-2 illustrates the centralized management of a TDE direct connection of TDE master keys.
Figure 2-2 Centralized Management of a TDE Direct Connection of TDE Master Keys
Oracle Key Vault can back up credential files other than Oracle wallets and Java keystores for long-term retention and recovery.
Oracle Key Vault does not interpret the actual content of a credential file; it stores the entire file as an opaque object and provides a handle to the endpoint for retrieval at a later time.
A credential file can contain security objects such as keys, passwords, SSH keys, Kerberos keytabs, and X.509 certificates.
You can directly upload credentials into Oracle Key Vault, consolidating these files in a central repository and sharing them across endpoints in a trusted group. In addition, the files will be backed up and made highly available along with all the other security objects in Oracle Key Vault. Key Vault administrators can set up access control policies to share these credential files with other endpoints.
Previously, without Oracle Key Vault, credential files tended to be scattered in numerous servers in an organization.
Figure 2-3 illustrates how credential files are archived in Oracle Key Vault.
Figure 2-3 Backing Up Credential Files
Oracle Key Vault uses virtual wallets to establish access control and share security objects.
A virtual wallet is a group of security objects that can be used to share access to the objects they contain.
Note:Security objects stored in Oracle Key Vault can exist outside a wallet, but then they cannot be shared and are only accessible by the owner.
Access is granted to subjects (endpoints and administrative users). To make granting access easier, users and endpoints can belong to one or more groups, and access can be granted to a group instead of to each individual member of the group. Groups cannot contain other groups.
To grant access from virtual wallets to subjects:
To set up access or membership from subjects to wallets:
"Oracle Key Vault User Details"
"Adding and Modifying User Group Details"
A user, user group, endpoint, or endpoint group can have special access control options on virtual wallets.
These access control options are as follows:
Read Only: The selected subject can read the attributes of the security object.
Read and Modify: The selected subject can read and modify the attributes of the security object.
Manage Wallet. The selected subject can do the following:
Add or remove security objects from the wallet. The user must also have Read and Modify access on any object to be added to the virtual wallet.
Grant others access to the wallet.
Oracle Key Vault uses two approaches to granting access to objects: direct grants to endpoints or users, or indirect grants through endpoint or user groups.
Access to a virtual wallet is granted directly to subjects (endpoints or users).
Access to a virtual wallet is provided indirectly, by group membership, to users or endpoints. If an endpoint group has access to a virtual wallet, then all the endpoints that are members of that endpoint group also have access to that wallet. This is a simpler alternative to granting access to each of the group members individually.
Anyone with the Manage Wallet access on a wallet can define access or membership relationships. See "Access Control Options".
Note:The Oracle Key Vault management console enables you to set up access and membership bidirectionally. Although access is always granted by the subject to the virtual wallet, links enable you to go from a wallet to the subjects that access it or from a subject to the wallets it can access.
Figure 2-4 is taken from the Endpoint Details page but is similar to the details pages for the other subjects (endpoint groups, users, and user groups). The panels show the two different approaches.
The left panel shows groups that this individual endpoint belongs to. For a group, it would show endpoints that are members of the group.
The right panel shows all the wallets this endpoint or group can access, whether through direct grants to this endpoint or to one of the endpoint groups it belongs to.
Figure 2-4 Sharing from Endpoint to Wallet
Oracle Key Vault is deployed on a server, with connections to the endpoints that have the data to be protected.
Oracle Key Vault is packaged as a software appliance. It is hardened for security according to operating system and database hardening best practices. Unnecessary packages and software have been removed, and unused services and ports are disabled. It is preconfigured with an operating system, database, and the Oracle Key Vault application itself, so that you do not have to install and configure individual components.
Endpoints communicate with Oracle Key Vault over a mutually authenticated Transport Layer Security (TLS) connection using OASIS Key Management Interoperability Protocol (KMIP).
Administrators log in to the browser-based management console using a user ID and password.
The Oracle Key Vault high availability configuration defines one primary appliance and one standby appliance. The standby appliance operates in a passive mode, whereas the primary appliance is active. That is, all the endpoints communicate with the primary appliance only. Communication related to data replication between the primary and standby appliances is mutually authenticated TLS.
When primary appliance is unresponsive for a certain period of time, the standby appliance is automatically promoted as the primary appliance and becomes an active node for the cluster.
See Also:"Configuring High Availability for Oracle Key Vault" for more details
Figure 2-5 illustrates the deployment architecture of Oracle Key Vault.
Figure 2-5 Oracle Key Vault Deployment Architecture
Additionally, some users may not have a specific administrative role, but may be responsible for a specific area, such as a virtual wallet. They can perform actions on the virtual wallet (based on the privileges they have been granted). However, they cannot grant privileges to other users for their virtual wallet.
The Oracle Key Vault administrative roles are designed to be flexible enough to support various organizational structures.
Oracle Key Vault provides three separate roles, so that you can grant each user only the privileges needed for their area of responsibility. Oracle Key Vault does not require that the roles be granted to different users because some organizations may have individuals with multiple areas of responsibility.
Oracle Key Vault controls access and prevents privilege escalation by separating the various duties and functions performed by users and administrators, and ensuring that only those who should be using a function or operating on a specific object are able to do so.
Oracle Key Vault provides separation of duty in a fine-grained manner, to better secure objects.
The separation of duty works as follows:
Access to one object or function can be granted independently of all others by a fine-grained division of access control and operational privileges. This enables you to match the responsibility of each user based.
Three roles provide privileges specific to particular functional areas. These are the Key Administrator, System Administrator, and Auditing Manager roles described in "Overview of Administrative Roles".
You should ensure that every user who interacts with Oracle Key Vault has a unique user account and password.
Administrative roles are divided into key, system, and audit management functions.
The corresponding roles, Key Administrator, System Administrator, and Audit Manager, can only be granted by users who have those roles. One user can be granted multiple roles, if desired.
In some situations, a user with one administrative role must perform one part of the operation and a user with a different role performs a different but related part of the operation: for example, only System Administrators can enroll endpoints and only Key Administrators can create endpoint groups.
During the post-install configuration process, each role is initially granted to a user. If the situation arises where there is no user with a particular role, then you can use the recovery passphrase to repeat the post-install configuration and grant each role to a new or existing user account as described in "Emergency System Recovery Process".
When you use the management console, your access to the various tabs, menus, and actions described "General Oracle Key Vault Management" depends on your role and the objects that you have access to.
The administrative roles are:
The System Administrator manages the Oracle Key Vault server:
Creates, modifies, and deletes users
Enrolls endpoints and deletes them
Sets up high availability
Configures alerts and key rotation reminders
Starts and stops Oracle Key Vault
Grants the System Administrator role to other users
The Key Administrator controls access to security objects and virtual wallets:
Controls user and endpoint access to virtual wallets
Creates and manages user groups
Creates and alters endpoint groups
Has Read, Modify, and Manage Access on all virtual wallets and security objects
Grants the Key Administrator role to other users
The Audit Manager manages the collection of audit data that records the actions of users and endpoints:
Manages the audit trail as the only user who has privileges to export or delete Oracle Key Vault audit records
Has Read access on all security objects
Grants the Audit Manager role to other users
Dashboards in the management console provide a quick look at the current Oracle Key Vault status and open issues that require attention.
Oracle Key Vault uses a special recovery passphrase to recover from emergency situations where there is no user who can access one of the three administrative roles (perhaps due to a forgotten password).
Knowledge of the recovery passphrase allows you to repeat the post-install process where administrative roles are assigned to new or existing user accounts.
The recovery passphrase is also required to restore Oracle Key Vault from a previous backup.
Note the following:
Setting or changing a recovery passphrase
To create or change a recovery passphrase, see "Task 2: Perform Postinstallation Tasks".
To use the recovery passphrase in an emergency "System Recovery".
Performing system recovery
If there is no user who can access one of the administrative roles, you can use the System Recovery process to assign the administrative roles to new or existing user accounts. See "System Recovery".
Maintaining the correct recovery passphrase with a backup
It is important to have the correct passphrase if you need to restore a backup. See "Backing Up and Restoring Data for Oracle Key Vault".
Endpoint administrators are administrators of the respective endpoints, such as Oracle databases or Oracle application servers.
For Oracle database endpoints, the endpoint administrator is the database administrator who is responsible for managing the database. Endpoint administrators perform operations such as archiving and downloading credential files, wallet files, and Java keystores.
Although the endpoint administrator does not have Oracle Key Vault access by default, the same user could have a Key Vault user account.
Any endpoint administrator can use the