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 preexisting 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 and audits their actions.

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. 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. A user must have access to security objects before being able to 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 that have access to the shared default wallet, without the need to put these endpoints into an endpoint group.

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 (mTLS) 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 deprecated Oracle Key Vault primary-standby configuration defined 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 2-node cluster deployment (one read-write pair) of Oracle Key Vault, instead of a primary-standby deployment. It provides better resource utilization (no idle standby server) and is the ideal platform for a growing Oracle Key Vault cluster in case the demand increases over time. A standalone deployment of Oracle Key Vault is useful for testing and development environments.

Note:

Oracle Key Vault is packaged as a hardened software appliance. It is strongly discouraged to install any third party software on Oracle Key Vault. Changes to Oracle Key Vault are not supported, may interfere with upgrades, break the appliance and make it unusable.

2.3 Access Control Configuration

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

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 group 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 and Endpoint Privileges within Oracle Key Vault

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

2.4.1 Separation of Duties in Oracle Key Vault

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

Oracle Key Vault users can be assigned the administrative roles by function, so there is a clear separation of duties between the System Administrator role, the Key Administrator Role, and the Audit Manager role. The Create Endpoint, Manage Endpoint, Create Endpoint Group, and Manage Endpoint Group privileges enable users to manage a subset of endpoints or endpoint groups without requiring these users to be granted more powerful administrative roles. You also can create users that have no administrative privileges.

In a strict separation of duties environment, different users are responsible for different functions. For example, for endpoints, the operations to manage an endpoint and grant permissions to the endpoint must be done by different users. Only users with System Administrator role or Manage Endpoint privilege can enroll an endpoint and only users with Key Administrator role or Manage Endpoint Group privilege can add an endpoint to the endpoint group.

You can achieve a separation of duties in two ways:

  • For each person who has been granted a role or a privilege, grant them the appropriate privileges for the functional area that they manage. For example, grant the System Administrator role for system-related tasks such user, backup/recovery, and endpoint management; the Key Administrator role to manage encryption keys, wallets, and endpoint groups (within the Oracle Key Vault interface); and the Audit Manager role to manage auditing-related tasks.
  • Grant a user access to one object or function independently of all others using a fine-grained division of access control. For example, grant the Manage Endpoint privilege and Manage Endpoint Group privileges to different users based on their area of responsibility. 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 the System Administrator and Key Administrator roles are powerful, also ensure that these users are trustworthy and that they are knowledgeable about the areas that they manage.

2.4.2 Administrative Roles

The Oracle Key Vault administrative roles are System Administrator, Key Administrator, and Audit Manager.

2.4.2.1 About Administrative Roles in Oracle Key Vault

Oracle Key Vault provides the System Administrator, Key Administrator, and Audit Manager roles.

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

The System Administrator, Key Administrator, and Audit Manager roles are designed to be flexible to support various organizational needs and structures. By default, users who have these roles may not grant their roles to other users. Users may grant roles to other users only if they are granted the role with the Allow Forward Grant option. If one administrative user is performing two administrative functions, then that user will have two roles in Oracle Key Vault. If the user has received the roles with the Allow Forward Grant option, they may grant or revoke one or both roles to other users.

You can enforce separation of administrator roles by enabling the Enforce Separation of Administrator Roles check from the Account Management tab of the System Recovery page. This prevents the grant of more than one Oracle Key Vault administrative role to any Oracle Key Vault user. The restriction holds even if the grantor has the Allow Forward Grant option. When the Enforce Separation of Administrator Roles check is enabled, an Oracle Key Vault user can have at most one administrative role, enforcing administrative role isolation. It is possible that an existing Oracle Key Vault user may have been granted multiple administrative roles before the Enforce Separation of Administrator Roles check is enabled. For example, post upgrade you may not have removed multiple administrative roles from all the users. Such users who hold multiple administrative roles cannot exercise any of those roles after the Enforce Separation of Administrator Roles check is enabled. The additional roles have to be removed before the remaining one intended administrative role can become operational.

Note:

Users can continue to be granted endpoint and endpoint group privileges when the Enforce Separation of Administrator Roles option is enabled.

One of the post-installation tasks is to create three administrative users for the three administrative roles. The installation process also prompts you to create a recovery passphrase. In a situation where there is no administrative user present, you use the recovery passphrase to repeat the post-installation configuration, and create three administrative users to ensure continued operation and management of Oracle Key Vault.

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.2 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 (you also can grant privileges to individual regular users to handle endpoints)

  • 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 Utility

  • Checking if the Oracle Audit Vault monitoring process is running

  • 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 and revoking the System Administrator role to and from other users

  • Granting and revoking the Create Endpoint and Manage Endpoint privileges to and from other users

2.4.2.3 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

  • Adding and managing endpoint groups (you also can grant privileges to individual regular users to handle endpoint groups)

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

  • Granting and revoking the Key Administrator role to and from other users

  • Granting and revoking the Create Endpoint Group and Manage Endpoint Group privileges to and from other users

  • Managing the extractable attribute settings for private and symmetric keys to allow or disallow them from leaving the Oracle Key Vault cluster boundary

2.4.2.4 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

  • Managing the Oracle Audit Vault integration with Oracle Key Vault

2.4.3 Endpoint Privileges

Oracle Key Vault provides privileges for creating and managing endpoints and endpoint groups.

2.4.3.1 About Endpoint Privileges in Oracle Key Vault

Oracle Key Vault provides fine-grained endpoint-management privileges that enable users who do not have the System Administrator and Key Administrator roles to create and manage endpoints and endpoint groups.

These privileges are as follows:

  • Create Endpoint system privilege authorizes a user to create endpoints.
  • Manage Endpoint object privilege authorizes a user to perform all endpoint management operations on the endpoint.
  • Create Endpoint Group system privilege authorizes a user to create endpoint groups.
  • Manage Endpoint Group object privilege authorizes a user to perform all endpoint group management operations on the endpoint group.

Only users who have the System Administrator or Key Administrator role can grant and revoke the endpoint privileges to other users, as follows:

  • Create Endpoint and Manage Endpoint privileges: System Administrator role
  • Create Endpoint Group and Manage Endpoint Group privileges: Key Administrator role

The System Administrator and Key Administrator roles are powerful roles that enable users with these roles to modify or delete any objects in Oracle Key Vault that belong to other users. The endpoint and endpoint group privileges enable you to allow regular users who do not have these roles to create and manage a specific set of endpoints and endpoint groups. You can grant management privileges to a user for any endpoint or endpoint group regardless of whether the user created the endpoint or endpoint group. These users cannot perform operations on other endpoints or endpoint groups that they are not authorized to manage. These privileges help implement isolation among different sets of endpoints and endpoint groups that are managed by different users. For example, one set of users can be responsible for managing all cloud database endpoints, and other users can be responsible for managing all on-premises database endpoints.

These privileges are enforced when endpoint or endpoint group operations are run from either the Oracle Key Vault management console or using Oracle Key Vault RESTful services utility command-line interface.

2.4.3.2 Create Endpoint Privilege Duties and Scope

The Create Endpoint system privilege enables a user to create an endpoint.

When a user who is granted the Create Endpoint privilege creates an endpoint, Oracle Key Vault automatically grants the Manage Endpoint privilege to the user on that endpoint. This allows the user to manage the endpoints that they created without requiring additional privilege grants. However, the user’s Manage Endpoint privilege on endpoints that they created can be revoked later.

Who Can or Cannot Grant or Revoke the Create Endpoint Privilege?

Only a user who has the System Administrator role can grant or revoke the Create Endpoint privilege. Users who have the Create Endpoint privilege cannot grant or revoke this privilege to or from any user.

How the Create Endpoint Privilege Works with the Manage Endpoint Privilege

Even though the Manage Endpoint privilege is automatically granted to a user who has been granted the Create Endpoint privilege when this user creates an endpoint, the Manage Endpoint privilege can be revoked from this user at any time, so that this user is restricted to creating endpoints only but not modifying or deleting them.

System Administrator Role and the Create Endpoint Privilege

A user with the System Administrator role can create and manage the endpoint. If the System Administrator role is revoked from a user, then the user can no longer manage the endpoint. However, when a user, with the System Administrator role and the Create Endpoint Group privilege, creates an endpoint, Oracle Key Vault grants the Manage Endpoint privilege on the endpoint to the user. If the System Administrator role is revoked from the user afterward, the user can continue to manage the endpoint that the user created.

Revocation of the Create Endpoint Privilege

A revoke of the Create Endpoint privilege prevents the user from being able to create more endpoints. Users cannot revoke the Create Endpoint privilege from themselves. The Create Endpoint privilege can be revoked from a user without affecting the user's Manage Endpoint privilege on one or more endpoints.

Deletion of Users Who Have Been Granted the Create Endpoint Privilege

The endpoint creator does not have perpetual ownership of the endpoint. The Manage Endpoint privilege on that endpoint granted to the endpoint's creator can be revoked, after which the endpoint creator cannot manage that endpoint anymore. Deletion of an endpoint's creator has no special significance other than the one that this user may have been granted the Manage Endpoint privilege at the time of the endpoint creation. If there are no other users with the Manage Endpoint privilege on that endpoint, then the System Administrator becomes responsible for managing that endpoint.

2.4.3.3 Manage Endpoint Privilege Duties and Scope

The Manage Endpoint object privilege on an endpoint enables a user to perform all endpoint management operations on the endpoint.

The user who has the Manage Endpoint privilege on an endpoint can perform the following tasks:

  • Perform all endpoint management operations (such as reenroll, suspend, resume, or delete) on the endpoint.
  • Set the default wallet of that endpoint if the user also has full access on the subject wallet.

Who Can or Cannot Grant or Revoke the Manage Endpoint Privilege?

A user who has the System Administrator role can grant or revoke the Manage Endpoint privilege. If the user with the Create Endpoint privilege creates an endpoint, Oracle Key Vault automatically grants the Manage Endpoint privilege for this endpoint to the user.

System Administrator Role and Users Who Have the Manage Endpoint Privilege

A user who has the System Administrator role can manage any endpoint including those that are created by users with the Create Endpoint privilege. If the System Administrator role is revoked from a user, then the user can no longer manage any endpoint including those he or she created unless the user was also granted the Create Endpoint privilege either at the time of endpoint creation or afterward. The user must be granted either the System Administrator role or the Manage Endpoint privilege on an endpoint to manage that endpoint.

Objects and Wallets Associated with an Endpoint

Objects that are created by an endpoint are always owned by the endpoint. The endpoint creator or users with the Manage Endpoint privilege do not get automatic or implicit access to any objects that were created by the endpoint.

A user with the Manage Endpoint privilege can set the endpoint’s default wallet if the user also has full access on the wallet. Revocation of the wallet access from the user afterwards does not affect the endpoint’s default wallet setting.

Revocation of the Manage Endpoint Privilege

The Manage Endpoint privilege can be revoked on the endpoint from a user without affecting the user's Create Endpoint privilege status. Users cannot revoke the Manage Endpoint privilege from themselves. If there are no users with the Manage Endpoint privilege for the endpoint, then managing that endpoint becomes the responsibility of users with the System Administrator role.

Deletion of Users Who Have Been Granted the Manage Endpoint Privilege

If the user who manages an endpoint is deleted, then the System Administrator or any other users who have the Manage Endpoint privilege for that endpoint can still manage the endpoint.

2.4.3.4 Create Endpoint Group Privilege Duties and Scope

The Create Endpoint Group system privilege enables a user to create an endpoint group.

When a user who is granted the Create Endpoint Group privilege creates an endpoint group, Oracle Key Vault automatically grants the user the Manage Endpoint Group privilege on that endpoint group. This allows the user to manage the endpoint groups that they created without requiring additional privilege grants. However, the user’s Manage Endpoint Group privilege on endpoint groups that they created can be revoked later.

Who Can or Cannot Grant or Revoke the Create Endpoint Group Privilege?

Only a user who has the Key Administrator role can grant or revoke the Create Endpoint Group privilege. Users who have the Create Endpoint Group privilege cannot grant or revoke this privilege to or from other users.

How the Create Endpoint Group Privilege Works with the Manage Endpoint Group Privilege

Even though the Manage Endpoint Group privilege is automatically granted to a user when the user creates an endpoint group, the Manage Endpoint Group privilege can be revoked for the endpoint group from this user at any time, so that this user can no longer modify or delete that endpoint group.

Key Administrator Role and Users Who Have the Create Endpoint Group Privilege

A user with the Key Administrator role can create and manage the endpoint groups. If the Key Administrator role is revoked from a user, then the user can no longer create and mange the endpoint groups. However, when a user with both the Key Administrator role and the Create Endpoint Group privilege creates an endpoint group, Oracle Key Vault grants the Manage Endpoint Group privilege on the endpoint group to the user. If the Key Administrator role is revoked from the user afterward, the user can continue to manage the endpoint groups that the user created.

Revocation of the Create Endpoint Group Privilege

A revoke of the Create Endpoint Group privilege prevents the user from being able to create more endpoint groups. Users cannot revoke the Create Endpoint Group privilege from themselves. The Create Endpoint Group privilege can be revoked from a user without affecting the user's Manage Endpoint Group privilege on one or more endpoint groups.

Deletion of Users Who Have Been Granted the Create Endpoint Group Privilege

The endpoint group creator does not have perpetual ownership of the endpoint group. The Manage Endpoint Group privilege on that endpoint group granted to the endpoint group's creator can be revoked, after which the endpoint group creator cannot manage that endpoint group anymore. Deletion of an endpoint group's creator has no special significance other than the one that this user may have been granted the Manage Endpoint Group privilege at the time of the endpoint group creation. If there are no other users with the Manage Endpoint Group privilege on that endpoint group, then the Key Administrator becomes responsible for managing that endpoint group.

2.4.3.5 Manage Endpoint Group Privilege Duties and Scope

The Manage Endpoint Group object privilege on an endpoint group enables a user to perform all endpoint group management operations on the endpoint group.

The user who has the Manage Endpoint Group privilege on an endpoint group can perform all endpoint group management operations (such as adding or removing an endpoint to or from an endpoint group, delete an endpoint group, and so on) on the endpoint group. This user inherits access to wallets from the endpoint group. This inheritance of wallet access permissions works in the same way as an endpoint or user inherits wallet permissions from an endpoint group or user group, respectively.

Who Can or Cannot Grant or Revoke the Manage Endpoint Group Privilege?

Only a user who has the Key Administrator role can grant or revoke the Manage Endpoint Group privilege. Users who have the Manage Endpoint Group privilege cannot grant or revoke this privilege to or from other users.

Key Administrator Role and Users Who Have the Manage Endpoint Group Privilege

A user who has the Key Administrator role can manage any endpoint group including those that are created by users with the Create Endpoint Group privilege. If the Key Administrator role is revoked from a user, then the user can no longer manage any endpoint groups including those he or she created unless the user was also granted the Create Endpoint Group privilege either at the time of endpoint group creation or afterward. The user must be granted either the Key Administrator role or the Manage Endpoint Group privilege on an endpoint group to manage that endpoint group.

Inheritance of Wallet Access from an Endpoint Group

  • A user who has been granted the Manage Endpoint Group privilege on an endpoint group (this user is also called the endpoint group manager) inherits the access to wallets from the endpoint group. This inheritance of wallet access permissions works in the same way as an endpoint or user inherits wallet permissions from an endpoint group or user group, respectively.

    Granting wallet access to an endpoint group results in implicitly giving the same wallet access to all the users who have the Manage Endpoint Group privilege on that endpoint group. These inherited wallet access from an endpoint group are effective as long as the user is the endpoint group manager for the endpoint group. This rule ensures that all endpoint group managers of an endpoint group always have at least the same level of access to wallets that the endpoint group has. This way, when an endpoint is added to the endpoint group, its endpoint group managers remain fully aware of the wallet permissions that the endpoint is implicitly being granted by virtue of adding an endpoint’s membership into the endpoint group.

  • A user's effective wallet access is the union of the following:
    • Direct wallet access grants to the user
    • Inherited wallet access grants from the user groups of which this user is a member
    • Inherited wallet access grants from the endpoint groups that this user is authorized to manage

How Wallets Are Affected by Revoke Operations

  • Revoking a wallet’s access from an endpoint group only results in the endpoint group's managers to lose the wallet access rights that were inherited from the respective endpoint group. The endpoint group's managers may continue to have access to the same wallet either from direct grants or from the inheritance of wallet access from user groups or other endpoint groups.
  • Revoking the Manage Endpoint Group privilege on an endpoint group from a user (that is, an endpoint group manager) prevents the user from inheriting future wallet access rights from that endpoint group.
  • An endpoint group's manager can revoke access of a wallet from the endpoint group (or from any other user, user group, endpoint, or endpoint group) if the user has the Manage Wallet Access privilege on that wallet even if this access was inherited from the endpoint group itself.

Revocation of the Manage Endpoint Group Privilege

The Manage Endpoint Group privilege can be revoked from a user without affecting the user's Create Endpoint Group privilege status. Users cannot revoke the Manage Endpoint Group privilege from themselves. If there are no users with the Manage Endpoint Group privilege for the endpoint, then managing that endpoint group becomes the responsibility of users with the Key Administrator role.

Deletion of Users Who Have Been Granted the Manage Endpoint Group Privilege

Deletion of an endpoint group's creator does not affect the endpoint groups that this user created. If the user who manages the endpoint group is deleted, then any other users who have the Manage Endpoint Group privilege for that endpoint group can still manage the endpoint group. If no such users exist, then a user who has the Key Administrator role becomes responsible for managing the endpoint group.

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 have an Oracle Key Vault cluster with version 18.4 and older, the maximum object names length is 24 bytes.
  • The names of users, user groups, endpoints, and endpoint groups are not case sensitive. For example, psmith and PSMITH 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 a brief period.

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. (This user is different from the Oracle Key Vault users who have the Manage Endpoints and Manage Endpoint Group privileges.)

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 Standards (FIPS) are standards and guidelines for federal computer systems that are developed by the US National Institute of Standards and Technology (NIST) in accordance with the Federal Information Security Management Act (FISMA). Although FIPS was developed for use by the federal government, many private sector entities voluntarily use these standards.

FIPS 140-2 specifies the security requirements that will be satisfied by a cryptographic module, providing four increasing, qualitative levels that are intended to cover a range of potential applications and environments. Security Level 1 provides the basic security requirements for a cryptographic module. FIPS 140-2 Security Level 1 requires no physical security mechanisms in the module beyond the requirement for production-grade equipment. As a result, this level allows software cryptographic functions to be performed in a general-purpose computer running on a specified operating environment.

FIPS mode enables Oracle Key Vault to adhere to FIPS 140-2 Level 1 compliance. When FIPS 140-2 settings are configured for Oracle Key Vault, it uses FIPS 140-2 Level 1 validated cryptographic libraries to protect keys and data at rest and in transit over the network. Oracle Key Vault clients such as the database PKCS#11 library, okvutil, C-SDK, Java-SDK and RESTful services utility make key management requests to the Oracle Key Vault servers. Oracle Key Vault components such as the KMIP service, the Oracle Key Vault application, embedded Oracle database, and Oracle GoldenGate will process the request and respond to the clients. Administration of Oracle Key Vault is done either using the web console (management console) or REST Admin APIs. The Oracle Key Vault management console is implemented using Oracle APEX backed by Apache and the Oracle database. The RESTful services utility requests are handled by a Tomcat server. Oracle Key Vault backup is done using secure copy protocol (SCP) or the SSH file transfer protocol (SFTP). The overall Oracle Key Vault system runs on Oracle Linux. These Oracle Key Vault components either use the DELL BSAFE or OpenSSL libraries for their cryptographic operations. Each of these components operates the cryptographic libraries in FIPS mode when FIPS mode is enabled for Oracle Key Vault.

Oracle Key Vault currently uses the following:

  • Dell BSAFE, formerly known as RSA BSAFE, as the FIPS 140-2 level 1 validated cryptography library: The specific version of the module used is Dell BSAFE Micro Edition Suite 4.6, which integrates Dell BSAFE Crypto-C Micro Edition (CCME) 4.6.1.0.1 as its underlying FIPS.
  • openssl-1.1.1k-12.el8_9.x86_64 : The specific version of the openssl module that is FIPS certified on Oracle Linux is openssl-libs-1.1.1g-15.el8_3.x86_64.rpm

Note that Oracle Key Vault FIPS mode enforces the use of FIPS-approved algorithms for the Oracle Key Vault only. Third-party vendor software that is used with Oracle Key Vault such as the HSM client software deployed to support root of trust, may operate in FIPS but must use FIPS-approved algorithms, or else the vendor software will not operate when Oracle Key Vault is in FIPS mode or will have failures.