2 Oracle Key Vault Concepts

You can deploy Oracle Key Vault successfully with a conceptual understanding of the deployment architecture, use cases, access control, administrative roles, and endpoints.

• Overview of Oracle Key Vault Concepts
  
• Oracle Key Vault Deployment Architecture
  
• Oracle Key Vault Use Cases
  
• Access Control Configuration
  
• Administrative Roles within Oracle Key Vault
  
• Endpoint Administrators
  

2.1 Overview of Oracle Key Vault Concepts

Oracle Key Vault endpoints are computer systems like database servers, application servers, and other information systems, where keys and credentials are used to access encrypted data and other systems. These systems have a need to store and manage their encryption keys efficiently, so that data is secure, accessible, and available to meet the day-to-day activities of the enterprise. Endpoints with pre-existing keys, or the capability to generate them, can use Oracle Key Vault as secure, external, long-term storage.

Endpoints must be registered and enrolled to communicate with Oracle Key Vault. Enrolled endpoints can upload their keys, share them with other endpoints, and download them to access their data. Oracle Key Vault keeps track of all enrolled endpoints.

Security objects can be grouped into a virtual wallet in Oracle Key Vault. The main purpose of a virtual wallet is to group related security objects so that they can be collectively shared with peers in an easy way. Any user can create a virtual wallet, add keys to the empty wallet, and then grant other users, endpoints, user and endpoints groups various levels of access to the wallet. A user must himself have access to security objects, before he can grant access on those same security objects to other users. The access level they grant can be equal to or less that their own. This flexibility is designed to meet the multiple and varying needs of any organization.

The owner of a security object is the entity who created the security object with full read, write, and modify access to the security object. The owner can add the security object to any number of wallets to be shared with other users at various access levels.

When an endpoint is registered with Key Vault, you can specify a default wallet for the endpoint. The main purpose of a default wallet is to ensure that keys have a virtual wallet to upload to when none are specified. All keys generated and uploaded by the endpoint will be automatically added to the default wallet associated with the endpoint.

Multiple endpoints can have a common default wallet. The contents of this default wallet are shared across all the endpoints, without the need to put these endpoints into an endpoint group. This feature enables multiple endpoints to create keys, or upload an Oracle wallet directly to the default wallet.

Oracle Key Vault audits all actions performed by users and endpoints.

2.2 Oracle Key Vault Deployment Architecture

Oracle Key Vault is deployed on a server, with connections to endpoints that have security objects to store and manage.

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 the OASIS Key Management Interoperability Protocol (KMIP).

Administrators log in to the browser-based GUI of the Key Vault management console with a user ID and password.

The Oracle Key Vault high availability configuration defines one primary appliance and one standby appliance. The primary appliance is active and services requests from endpoints. The standby appliance takes over as primary, if the primary fails to communicate with the standby for a time exceeding a configured time threshold. Communication related to data replication between the primary and standby appliances is mutually authenticated TLS.

The following figure illustrates the deployment architecture of Oracle Key Vault.

Figure 2-1 Oracle Key Vault Deployment Architecture

Description of "Figure 2-1 Oracle Key Vault Deployment Architecture"

2.3 Oracle Key Vault Use Cases

The most typical use cases for Oracle Key Vault are centralized storage and management of security objects.

• Centralized Storage of Oracle Wallet Files and Java Keystores
  
• Centralized Management of TDE Master Keys Using Online Master Key
  
• Storage of Credential Files
  

2.3.1 Centralized Storage of Oracle Wallet Files and Java Keystores

You can store all your security objects like Oracle wallets and Java keystores centrally in Oracle Key Vault, and manage them with automatic mechanisms that Key Vault provides for tracking, backup, and recovery. This will help you overcome many operational and security challenges posed by the manual tracking and management of security objects dispersed widely across multiple servers.

Oracle Key Vault stores copies of Oracle wallet files, Java keystores, and other security objects in a centralized location for long-term retention and recovery. These security objects can later be downloaded to a new wallet or keystore file and shared with trusted server peer endpoints.

The Oracle Key Vault endpoint software can read the format of Oracle wallet files and Java keystores to store their contents at the granularity of individual security objects. You can upload both password-protected and auto-login wallets, and then download the wallet contents to a new wallet of either type. This enables users to manage security objects individually, and add them to virtual wallets for sharing.

Oracle Key Vault can individually store and manage the security objects contained in:

• Oracle wallet files

  Symmetric keys used for encryption (including TDE master keys), passwords (Secure External Password Store), and X.509 certificates (network encryption).

  Oracle wallet files from all supported releases of Oracle Database are supported.

• Java keystores

  Symmetric keys, asymmetric keys such as private keys, and X.509 certificates.

  Oracle Key Vault supports both JKS and JCEKS types of Java keystores.

The following figure illustrates the centralized storage of Oracle wallet files and Java keystores.

Figure 2-2 Centralized Storage of Oracle Wallet Files and Java Keystores

Description of "Figure 2-2 Centralized Storage of Oracle Wallet Files and Java Keystores"

See Also:

Managing Secure External Password Store

2.3.2 Centralized Management of TDE Master Keys Using Online Master Key

For Oracle databases using TDE, Oracle Key Vault provides centralized management of TDE master keys over a direct network connection, known as Online Master Key. In this use case TDE generates the master key and stores it in Oracle Key Vault.

Note that Online Master Key replaces the term TDE Direct Connection.

This is a convenient alternative to copying local wallet files to multiple endpoints manually. Sharing TDE master keys rather than maintaining local wallet copies is especially useful when TDE is running on database clusters such as Oracle RAC. The following comparison illustrates the difference:

• Local wallet copy

  When a key rotation operation is performed on the master key in the primary node of an Oracle RAC, the local wallet copy is updated and must then be manually copied to the other nodes to propagate the new TDE master key.

• Shared TDE key in a virtual wallet in Key Vault

  After a key rotation operation the new TDE master key is immediately shared with other nodes in the cluster. There is no need to copy the wallet manually to the other nodes.

Centralized management facilitates the copying of encrypted data between databases using Oracle Data Pump Export, Import, or the transportable tablespaces feature of Oracle Database when master keys are stored in the wallet:

• In non-centralized management the wallet must be manually copied from source to target databases.

• In centralized management these master keys are easily shared by placing them in a virtual wallet in Oracle Key Vault, and then granting each endpoint access to the virtual wallet.

Online Master Keys between TDE and Oracle Key Vault are supported on Oracle Database 11g Release 2 and Oracle Database 12c.

The following figure illustrates the centralized management of Online Master Keys (formerly known as TDE Direct Connect).

Figure 2-3 Centralized Management of Online Master Keys

Description of "Figure 2-3 Centralized Management of Online Master Keys"

See Also:

Using an Online Master Key with Oracle Key Vault

2.3.3 Storage of Credential Files

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 contains security objects such as keys, passwords, SSH keys, Kerberos keytabs, and X.509 certificates.

You can directly upload credential files into Oracle Key Vault, consolidate them in a central repository, and share them across endpoints in a trusted group. Key Vault backs up all credential files for continued and secure access at any time. Access control to credential files is managed by Key Vault administrators.

The following figure illustrates how credential files are backed up in Oracle Key Vault.

Figure 2-4 Backing Up Credential Files

Description of "Figure 2-4 Backing Up Credential Files"

See Also:

"Uploading and Downloading Credential Files"

2.4 Access Control Configuration

Oracle Key Vault allows you control access to security objects at various access levels and time intervals. Any user may be granted access to security objects in Key Vault at a level appropriate to their function in the organization.

• About Access Control Configuration
  
• Access Grants
  
• Access Control Options
  

2.4.1 About Access Control Configuration

You can grant users access to security objects in Oracle Key Vault at a level appropriate to their function in the organization.

Access control can be set on security objects individually, or collectively when they are grouped into a virtual wallet. Oracle Key Vault uses the mechanism of a virtual wallet to share a set of security objects with others. A virtual wallet is a container for security objects like public and private encryption keys, TDE master encryption keys, passwords, credentials, and certificates in Oracle Key Vault. You can set access levels on a virtual wallet for an endpoint or user, thus granting simultaneous access to all the security objects contained within the virtual wallet.

In addition to being able to grant access to individual users or endpoints individually, access can be granted collectively by using endpoint groups or user groups. If multiple endpoints need access to a virtual wallet, it is simpler to add these endpoints to an endpoint group, and grant the endpoint group access to the virtual wallet. The alternative is to grant access to each endpoint individually. When you grant an endpoint group access to a virtual wallet, you are granting access to all the member endpoints in the endpoint group.

2.4.2 Access Grants

You can grant access to virtual wallets directly or indirectly:

• Grant users and endpoints access directly.

• Grant users and endpoints groups access indirectly via group membership. When you grant a user or endpoint group access, you are granting all members of the group access. This is a convenient alternative to individually granting each user or endpoint access.

Note:

You can set access mappings on a virtual wallet in two ways:

• From the user, endpoint, or their respective groups. You can start at the user, endpoint, or respective group and add the wallet and access mappings for this user.

• From the virtual wallet. You can start from the virtual wallet and add users, endpoints, and their respective groups that can access it at access mappings that you set.

See Also:

"Grant Access to Endpoint Groups, Endpoints, User Groups, and Users"

"Grant an Endpoint Access to a Virtual Wallet"

"Grant a User Group Access to a Virtual Wallet"

2.4.3 Access Control Options

You can control access to virtual wallets by setting different access levels for users, user groups, endpoints, and endpoint groups corresponding to their role and function in the organization.

There are three access levels:

• Read Only: Grants read privileges on the security object.

• Read and Modify: Grants read and modify privileges on the security object.

• Manage Wallet. Grants the following privileges:

  • Add or remove security objects from the virtual wallet. The user must have Read and Modify access on the security object to be added to the virtual wallet.

  • Grant others access to the wallet.

  • Modify wallet settings, like its description.

  • Delete the wallet.

2.5 Administrative Roles within Oracle Key Vault

Oracle Key Vault provides three administrative roles: system administrator, key administrator, and audit manager, that may be combined in any way to meet enterprise needs.

• About Administrative Roles in Oracle Key Vault
  
• Separation of Duties
  
• Overview of Administrative Roles
  
• Emergency System Recovery Process
  

2.5.1 About Administrative Roles in Oracle Key Vault

The three administrative roles are designed to be flexible to support various organizational needs and structures. The roles may be used to separate duties, or combined in any way, or not used at all. Users without a specific administrative role may be responsible for a specific area, like a virtual wallet. These users can be granted access to the virtual wallet appropriate to their function within the organization, thus limiting access to security objects to just those users who need it. In this way access to security objects is controlled, yet flexible to meet the changing needs of the enterprise.

2.5.2 Separation of Duties

Oracle Key Vault users can assign the three administrative roles by function, so there a a clear separation of duties between the system and key administrator, and the audit manager.

You can achieve a separation of duties in two ways:

• Grant an administrative user (defined as a user with one of the roles of System Administrator, Key Administrator, or Audit Manager) privileges to one functional area: system, key, or audit management. Create three separate administrative users for each of the functional areas.

• Grant a user access to one object or function independently of all others using a fine-grained division of access control and operational privileges based on the responsibility of the user. These users need not have any of the administrative roles to perform their function.

You should ensure that every user who interacts with Oracle Key Vault has their own user account and password.

2.5.3 Overview of Administrative Roles

Oracle Key Vault has three administrative roles: Key Administrator, System Administrator, and Audit Manager for the administrative users who perform key, system, and audit management functions respectively.

Administrative users can grant their roles to other users, but not others. If one administrative user is performing two administrative functions, that user will have two roles in Key Vault. This user can grant other users one or both the roles as needed. For example if a user has both the System Administrator and Key Administrator role, he can grant another user both those roles or just one, depending on the needs of the organization.

In a strict separation of duties, a user with one administrative role must perform one part of the operation, and a user with a different administrative 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.

One of the post-installation tasks is to create three administrative users for the three roles. In a situation where there is no administrative user present, you can recover the system with the recovery passphrase. You will use the recovery passphrase to repeat the post-installation configuration, and create three administrative users in order to ensure continued operation and management of Key Vault.

When you use the management console, your access to the various tabs, menus, and actions depends on your role and the objects that you have access to. The following list outlines the duties of each administrative user:

• The Oracle Key Vault System Administrator

  • Creates and manages users

  • Adds and manages endpoints

  • Sets up high availability

  • Configures alerts and key rotation reminders

  • Schedules backups

  • Starts and stops Oracle Key Vault

  • Configures SMTP server settings for email notification

  • Configures SNMP for remote monitoring

  • Enables automated endpoint enrollment via RESTful Services

  • Enables audit consolidation with Audit Vault Database Firewall

  • Creates SSH tunnels for Oracle Cloud Database as a Service endpoints

  • Grants the System Administrator role to other users

• The Oracle Key Vault Key Administrator

  • Manages the lifecycle of security objects

  • Has full access on all virtual wallets and security objects

  • Controls access to virtual wallets for users, endpoints, user and endpoint groups

  • Creates and manages user groups

  • Creates and manages endpoint groups

  • Grants the Key Administrator role to other users

• The Oracle Key Vault Audit Manager

  • 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

2.5.4 Emergency System Recovery Process

During installation you will be required to create a special recovery passphrase that Oracle Key Vault uses to recover from emergency situations. These situations can arise due to administrative users not being immediately available, or something more commonplace like forgotten passwords.

The recovery passphrase is needed in the following situations:

1. If there are no administrative users available to log into Key Vault, you can use the recovery passphrase to repeat the post-installation tasks and create new administrative users for system, key, and audit management.

2. If you want to restore Oracle Key Vault from a previous backup you will need the recovery passphrase associated with that backup.

3. If you want to reset the recovery passphrase periodically.

For these reasons it is quite important to store the recovery passphrase in a a safe and accessible place and keep track of older recovery passphrases. The only way to recover from a lost recovery passphrase is to reinstall Key Vault.

See Also:

Recovery passphrase used in "System Recovery"

Maintain the correct recovery passphrase with a backup in "Restoring Oracle Key Vault Data"

Create or change the recovery passphrase in Performing Post-Installation Tasks

2.6 Endpoint Administrators

Endpoint administrators own and manage endpoints. They are typically system, security, or database administrators, but they can be any personnel charged with deploying, managing and maintaining security within an enterprise. Endpoint administrators are responsible for enrolling endpoints.

The endpoint administrator for an Oracle database endpoint is the database administrator, who is responsible for managing the database.