2 Oracle Key Vault Concepts

To successfully deploy Oracle Key Vault, you must understand the deployment architecture, use cases, access control, administrative roles, and endpoints.

2.1 Overview of Oracle Key Vault Concepts

Endpoints are computer systems such as database and application servers, and other information systems where keys and credentials access data.

These endpoint systems must store and manage their encryption keys and secrets 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.

You must register and enroll an endpoint so that it can 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.

You can group security objects such as master encryption keys and credential files 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. A privileged user can create a virtual wallet, add keys to the empty wallet, and then grant other users, endpoints, user groups, and endpoint groups various levels of access to the wallet. A user must have access to security objects before he or she can grant access on those same security objects to other users. The access level they grant can be equal to or less than 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 that 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 Oracle Key Vault, you can specify a default wallet for the endpoint. The default wallet ensures that endpoints are associated with a virtual wallet where the keys will be uploaded if no virtual wallet is specified at the time of wallet or key upload.

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 automatically audits all actions performed by users and endpoints.

2.2 Oracle Key Vault Deployment Architecture

Oracle Key Vault is packaged as a software appliance preconfigured with an operating system, a database, and the Oracle Key Vault application.

This way, you do not have to install and configure individual components. It is hardened for security according to operating system and database hardening best practices. The installation process does not include any unnecessary packages and software, and it enables only required ports and services.

The endpoints communicate with Oracle Key Vault over a mutually authenticated Transport Layer Security (TLS) connection using the OASIS Key Management Interoperability Protocol (KMIP).

The Oracle Key Vault multi-master cluster configuration can contain up to 16 nodes, two of which must be read-write nodes with the remaining being a combination of either read-write pairs or read-only nodes. The multi-master configuration provides several benefits over a primary-standby configuration. The multi-master configuration and the primary-standby configuration are mutually exclusive.

The Oracle Key Vault primary-standby configuration defines one primary server and one standby server. The primary server is active and services requests from endpoints. If the primary fails to communicate with the standby for a time exceeding a configured time threshold, then the standby server takes over as primary. Communication related to data replication between the primary and standby servers is a mutually authenticated TLS connection. This was referred to as the primary-standby option (previously called high availability) in previous releases of Oracle Key Vault.

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

Figure 2-1 Oracle Key Vault Deployment Architecture

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

For multiple geographically distributed data centers with high load and extreme availability requirements, you should deploy Oracle Key Vault in a multi-master cluster configuration. The read-write pairs should span data centers. For single data centers where data does not leave the data center, consider using a classic primary-standby deployment of Oracle Key Vault with a periodic backup. A standalone deployment of Oracle Key Vault is useful for testing and development environments.

2.3 Access Control Configuration

Oracle Key Vault enables you to control access to security objects at various access levels and time intervals.

2.3.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.

You can set access control on security objects individually, or collectively when you group them into a virtual wallet. Oracle Key Vault uses a virtual wallet to share a set of security objects with others. 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 users or endpoints individually, you can collectively grant access by using user groups or endpoint 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.3.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 through a 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.

From the Oracle Key Vault management console, you can grant access mappings on a virtual wallet in the following 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.

2.3.3 Access Control Options

Access control options enable you to set the type of privileges that users have to read, write, and delete security objects.

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:

    • Adding or removing 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.

    • Granting others access to the wallet

    • Modifying wallet settings, such as its description

    • Deleting the wallet

2.4 Administrative Roles within Oracle Key Vault

Oracle Key Vault provides separation of duty compliant administrative roles that you can combine in various ways to meet enterprise needs.

2.4.1 About Administrative Roles in Oracle Key Vault

Oracle Key Vault provides three administrative roles: System Administrator, Key Administrator, and Audit Manager.

  • System Administrator role provides privileges for creating and managing users, creating and managing endpoints, configuring system settings and alerts, and generally administering Oracle Key Vault. This is the most powerful role.
  • Key Administrator role provides privileges for managing the key life cycle and controlling access to all security objects in Oracle Key Vault.
  • Audit Manager role provides privileges for managing the audit life cycle and audit policies.

These roles are designed to be flexible to support various organizational needs and structures. Administrative users can grant their roles to other users, but non-administrative users cannot. If one administrative user is performing two administrative functions, then that user will have two roles in Oracle 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, then he or she can grant another user both those roles or just one, depending on the needs of the organization.

One of the post-installation tasks is to create three administrative users for the three roles. The installation process also prompts you to create a recovery passphrase. 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 Oracle Key Vault.

You can enable users who have no specific administrative role to be responsible for a specific area, such as a virtual wallet. You can grant these users 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 manner, access to security objects is controlled, yet flexible to meet the evolving needs of the enterprise.

When you use the management console interface, your access to the various tabs, menus, and actions depends on your role and the objects that you have access to.

2.4.2 Separation of Duties in Oracle Key Vault

When you grant the Oracle Key Vault roles to users, ensure that you adhere to separation of duty guidelines.

Oracle Key Vault users can be assigned the three administrative roles by function, so there is a clear separation of duties between the System Administrator, Key Administrator, and the Audit Manager. You also can create users that have no administrative privileges.

In a strict separation of duties environment, 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.

You can achieve a separation of duties in two ways:

  • Grant each person who has been granted one of the three roles the appropriate privileges for the functional area for which they are responsible. For example, grant the System Administrator privileges for system-related tasks, the Key Administrator user privileges to manage encryption keys (such as the SYSKM administrative privilege for Transparent Data Encryption), and the Audit Manager privileges such as the AUDIT_ADMIN role for Oracle Database unified auditing policies.

  • 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 do not need to 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 unique user account and password. Because these roles are powerful, also ensure that these users are trustworthy and that they are knowledgeable about the areas that they manage.

2.4.3 System Administrator Role Duties

The Oracle Key Vault System Administrator is responsible for general system-related tasks.

  • Creating and managing users

  • Adding and managing endpoints

  • Setting up the primary-standby servers

  • Configuring alerts and key rotation reminders

  • Scheduling backups

  • Starting and stopping Oracle Key Vault

  • Configuring SMTP server settings for email notification

  • Enabling or disabling FIPS mode

  • Configuring Oracle Key Vault to use a hardware security module

  • Configuring SNMP for remote monitoring

  • Enabling automated endpoint enrollment and key management through RESTful Services

  • Enabling audit consolidation with Audit Vault Database Firewall

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

  • Setting up a cluster

  • Managing and monitoring a cluster

  • Managing the cluster configuration

  • Granting the System Administrator role to other users

2.4.4 Key Administrator Role Duties

The Oracle Key Vault Key Administrator is responsible for managing security objects.

  • Managing the lifecycle of security objects

  • Having full access on all virtual wallets and security objects

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

  • Granting the Key Administrator role to other users

2.4.5 Audit Manager Role Duties

The Oracle Key Vault Audit Manager is responsible for audit-related tasks.

  • Managing the audit trail as the only user who has privileges to export or delete Oracle Key Vault audit records

  • Having read access on all security objects

  • Managing audit settings

  • Granting the Audit Manager role to other users

2.5 Naming Guidelines for Objects

The naming guidelines affect the following Oracle Key Vault objects: users, user groups, endpoints, endpoint groups, and virtual wallets.

The naming conventions for these objects are as follows:

  • You can include the following characters in the names of endpoints, endpoint groups, user groups, and virtual wallets: letters (az, AZ), numbers (0-9), underscores (_), periods (.), and hyphens (-).
  • You can include the following characters in the names of users: letters (az, AZ), numbers (0-9), and underscores (_).
  • In most environments, the maximum number of bytes allowed for the name length is 120 bytes. If you are in a multi-master cluster environment that has any nodes that have not yet been upgraded to Oracle Key Vault release 18.5 or later, then use a maximum of 24 bytes for the object name.
  • The names of users, user groups, endpoints, and endpoint groups are not case sensitive. For example, pfitch and PFITCH are considered the same user in Oracle Key Vault.
  • The names of virtual wallets are case sensitive. For example, wallet_hr and WALLET_HR are considered two separate wallets in Oracle Key Vault.

2.6 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 such as forgotten passwords.

The recovery passphrase is needed in the following situations:

  • If there is no administrative user available to log into Oracle Key Vault, then you can use the recovery passphrase to repeat the post-installation tasks and create new administrative users for system, key, and audit management.
  • If you want to restore Oracle Key Vault from a previous backup, then you must have the recovery passphrase that is associated with that backup.
  • You will be prompted for the recovery passphrase during the node induction process in the cluster mode.
  • You will need it if you want to reset the recovery passphrase periodically.

For these reasons, it is very important to store the recovery passphrase in a safe and accessible place and keep track of older recovery passphrases. The recovery passphrase is the same passphrase that you use when you add nodes to a multi-master cluster.

The only way to recover from a lost recovery passphrase is to reinstall Oracle Key Vault.

2.7 Root and Support User Accounts

Both the root and support user accounts are used with the command-line interface.

The root user account is the super user account for the operating system that hosts Oracle Key Vault. You do not need the root account for normal Oracle Key Vault administration. Instead, you must use the root account when you want to upgrade to a later bundle patch or perform some command-line operations such as adding disk space. The support user is the only account that can remotely log in to the operating system hosting the Oracle Key Vault when SSH is enabled.

Be aware that if you enter the root or support passwords incorrectly three times, then the account is locked for 15 minutes.

2.8 Endpoint Administrators

An endpoint administrator owns and manages endpoints, which are entities such as Oracle databases that use Oracle Key Vault.

This user is typically a system, security, or database administrator, but 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.

2.9 FIPS Mode

FIPS mode enables Oracle Key Vault to adhere to FIPS 140-2 compliance.

Federal Information Processing Standard (FIPS) publications are issued by the National Institute of Standards and Technology (NIST). The publication entitled Security Requirements for Cryptographic Modules (FIPS PUB 140-2) specifies the security requirements over several key areas that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information.

The Oracle Key Vault is FIPS 140–2 compliant. Selecting the option to install with FIPS 140–2 compliance performs all required changes during the installation. No additional modifications are necessary after the installation. You can also enable FIPS 140-2 compliance after the installation if it was not done during the initial installation of Oracle Key Vault. Enabling or disabling FIPS mode requires you to restart Oracle Key Vault.