Deploy Oracle Key Vault with Oracle Exadata Database Service (Oracle Database@Google Cloud)

Oracle Key Vault is a fault-tolerant, continuously available and highly scalable key management system that has been purpose-built to provide key management for Oracle database deployments, in this case, Oracle Exadata Database Service on Oracle Database@Google Cloud. Oracle Key Vault enables customers to securely manage security objects for Oracle Database@Google Cloud in Google Cloud, that includes encryption keys, Oracle wallets, Java Keystores (JKS), Java Cryptography Extension Keystores (JCEKS), and credential files with SSH private keys, etc.

Utilizing Oracle Key Vault with Oracle Exadata Database Service (Oracle Database@Google Cloud) provides customers the following benefits:

  • Fault tolerance
  • High availability
  • Scalability
  • Security
  • Standards-compliance

Oracle Key Vault manages security objects which include encryption keys, Oracle wallets, Java Keystores (JKS), Java Cryptography Extension Keystores (JCEKS), and credential files. Credential files can include SSH private keys, used for public key authentication to remote servers (on-premises or in any cloud), or database account passwords for unattended execution of regularly scheduled maintenance scripts. Oracle Key Vault is optimized for the Oracle Cloud Stack (database, middleware, systems), and advanced security transparent data encryption (TDE). In addition, it complies with the industry standard OASIS Key Management Interoperability Protocol (KMIP) for compatibility with KMIP-based clients.

Oracle Key Vault works with endpoints, an endpoint is a computer system such as a database server, an application server, and other information systems. Endpoints must be registered and enrolled so that they can communicate with Oracle Key Vault. Enrolled endpoints can upload their keys, share them with other endpoints, and download them to access their data. Keys are used to access encrypted data and credentials are used to authenticate to other systems. For database servers hosting one or more Oracle databases, each Oracle database will be at least one endpoint.

Oracle Key Vault streamlines day-to-day operations with encrypted databases deployed as RAC or with Active Data Guard, pluggable databases, OCI GoldenGate encrypted trail files, as well as globally distributed (sharded) databases, Oracle ZFS Storage Appliance, and Oracle Zero Data Loss Recovery Appliance. Oracle Key Vault facilitates the movement of encrypted data using Oracle Data Pump and transportable tablespaces, a key feature of Oracle Database.

While Oracle and Google are responsible for securing the underlying infrastructure supporting Oracle Key Vault, customers are responsible for implementing the required security controls in their applications and any configuration mechanisms to meet their security and compliance mandates. Oracle Key Vault provides hold your own key by default.

Before You Begin

To take advantage of this reference architecture, the following are required:

Oracle Database@Google Cloud

  • Access to an Google Cloud subscription and directory
  • Access to an OCI tenancy
  • Active Oracle Database@Google Cloud multicloud link between the Google Cloud and OCI
  • Prior to provisioning, ensure adequate Oracle Exadata Database Service limits and OCI service limits
    1. In the OCI menu, click Governance & Administration.
    2. Under Tenancy Management, click Limits, Quotas and Usage.
    3. From the Service dropdown, select Database.
  • Plan your network topology:
    • Requires at least one Google Cloud Virtual Private Cloud (VPC) that can be paired with a corresponding OCI virtual cloud network (VCN)
    • The CIDR blocks for any Google Cloud Virtual Private Cloud (VPC) and OCI VCNs must not overlap
Oracle Key Vault
  • Access to an Oracle Key Vault image, built on-premises from the corresponding ISO file
  • Oracle Key Vault installation requirements
  • Setting up NTP is required

Architecture

This architecture shows how to deploy Oracle Key Vault on a Google Cloud virtual machine (VM) as a secure long-term external key management storage for Oracle Exadata Database Service encryption keys in Oracle Database@Google Cloud.

The architecture diagram depicts the recommended Oracle Key Vault multi-master cluster in Google Cloud to provide continuously available, extremely scalable, and fault-tolerant key management for the Oracle Database in Oracle Exadata Database Service (Oracle Database@Google Cloud).

Two Oracle Key Vault nodes in the same zone form a read/write pair, providing continuous read availability. This is because when one of the two nodes is non-operational, then the remaining node is set to be in the read-only restricted mode. When a read/write node is again able to communicate with its read/write peer, then the node reverts back to read/write mode from read-only restricted mode. Four nodes (as shown in the architecture diagram) provide continuous read/write availability.

Oracle Key Vault can be deployed on-premises, in OCI, Google Cloud, Microsoft Azure, and Amazon Web Services, as long as network connectivity can be established. Stretched Oracle Key Vault clusters (on-premises to cloud, or across cloud providers) are also possible, giving you maximum deployment flexibility and local availability of your encryption keys. Oracle Key Vault provides "hold your own key" functionality out of the box, without the need for an additional, expensive third-party key management appliance.

The following diagram illustrates this reference architecture.



key-vault-database-google.zip

The architecture has the following components:

  • Google Cloud Region

    Google and OCI regions are localized geographic areas. For Oracle Database@Google Cloud, a Google Cloud region is connected to an OCI region. A zone in Google Cloud is connected to an availability domain in OCI. Google Cloud and OCI region pairs are selected to minimize distance and latency.

  • Google Cloud zone

    A zone is a physically separate data center within a region that is designed to be available and fault tolerant. Zones are close enough to have low-latency connections to other zones.

  • Google Cloud Virtual Private Cloud

    Google Cloud Virtual Private Cloud (VPC) is the fundamental building block for your private network in Google Cloud. VPC enables many types of Google Cloud resources, such as Google virtual machines (VM), to securely communicate with each other, the internet, and on-premises networks.

  • Exadata Database Service on Dedicated Infrastructure

    Oracle Exadata Database Service delivers proven Oracle Database capabilities on purpose-built, optimized Oracle Exadata infrastructure in the public cloud. Built-in cloud automation, elastic resource scaling, security, and fast performance for OLTP, in-memory analytics, and converged Oracle Database workloads help simplify management and reduce costs.

    Exadata Cloud Infrastructure X9M brings more CPU cores, increased storage, and a faster network fabric to the public cloud. Exadata X9M storage servers include Exadata RDMA Memory (XRMEM), creating an additional tier of storage, boosting overall system performance. Exadata X9M combines XRMEM with innovative RDMA algorithms that bypass the network and I/O stack, eliminating expensive CPU interrupts and context switches.

    Exadata Cloud Infrastructure X9M increases the throughput of its 100 Gbps active-active Remote Direct Memory Access over Converged Ethernet (RoCE) internal network fabric, providing a faster interconnect than previous generations with extremely low-latency between all compute and storage servers.

  • Oracle Database@Google Cloud

    Oracle Database@Google Cloud is the Oracle Database service (Oracle Exadata Database Service on Dedicated Infrastructure or Oracle Autonomous Database Serverless) running on Oracle Cloud Infrastructure (OCI), deployed in Google Cloud data centers. The service offers features and price parity with OCI. Users purchase the service on Google Cloud Marketplace.

    Oracle Database@Google Cloud integrates Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC), and Oracle Data Guard technologies into the Google Cloud platform. Oracle Database@Google Cloud offers the same low latency as other Google-native services and meets mission-critical workloads and cloud-native development needs. Users manage the service on the Google console and with Google automation tools. The service is deployed in Google Virtual Private Cloud (VPC) and integrated with the Google identity and access management system. The OCI and Oracle Database metrics and audit logs are natively available in Google. The service requires that users have an Google tenancy and an OCI tenancy.

  • Key Vault

    Oracle Key Vault securely stores encryption keys, Oracle Wallets, Java KeyStores, SSH key pairs, and other secrets in a scalable, fault-tolerant cluster that supports the OASIS KMIP standard and deploys in Oracle Cloud Infrastructure, Google Cloud, Microsoft Azure, and Amazon Web Services as well as on-premises on dedicated hardware or virtual machines.

Recommendations

Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.
  • Oracle Key Vault ISO

    To build the right Oracle Key Vault solution, make sure to use the latest Oracle Key Vault installation medium. See Explore More for the Oracle Software Delivery Cloud link.

  • Oracle Key Vault Image Building

    To build the Oracle Key Vault image from the ISO, do so on a local system with at least 1 TB of storage with at least 32 GB in RAM. Create the virtual hard disk as Fixed size and in the VHD format.

  • Multi-Master Cluster

    Deploy Oracle Key Vault as a multi-node cluster to achieve maximum availability and reliability with read/write pairs of Oracle Key Vault nodes.

    Oracle Key Vault multi-master cluster is created with a first node, then additional nodes can be subsequently inducted to eventually form a multi-node cluster with up to 8 read/write pairs.

    The initial node is in read-only restricted mode and no critical data can be added to it. Oracle recommends to deploy a second node to form a read/write pair with the first node. After which, the cluster can be expanded with read/write pairs so that both critical and non-critical data can be added to the read/write nodes. Read-only nodes can help with load balancing or operation continuity during maintenance operations.

    Refer to the documentation to learn how a multi-master cluster affects endpoints, both in the way an endpoint connects and with restrictions.

    For large deployments, install at least four Oracle Key Vault servers. Endpoints should be enrolled by making them unique and balanced across the four servers to ensure high availability. For example, if a data center has 1,000 database endpoints to register, and you have four Oracle Key Vault servers to accommodate them, then enroll 250 endpoints across each of the four servers.

    Ensure that the system clocks of the endpoint host and the Oracle Key Vault server are in sync. For Oracle Key Vault server, setting up NTP is required.

  • Read/Write Pair

    A pair of nodes that operates with bidirectional synchronous replication. The read/write pair by is created by pairing a new node with a read-only node. Data can be updated, including the endpoint and wallet data, in either node by using the Oracle Key Vault management console, or Oracle Key Vault client software. The updates are replicated immediately to the other node in the pair. Updates are replicated asynchronously to all other nodes.

    A node can be a member of at most one bidirectional synchronous pair.

    A multi-master cluster requires at least one read/write pair to be fully operational. It can have a maximum of 8 read/write pairs.

  • Oracle Key Vault Read/Write Nodes

    A read/write node is a node in which critical data can be added or updated using the Oracle Key Vault or endpoint software.

    The critical data that is added or updated can be data such as keys, wallet contents, and certificates.

    Oracle Key Vault read/write nodes always exist in pairs. Each node in the read/write pair can accept updates to critical and non-critical data, and these updates are immediately replicated to the other member of the pair, the read/write peer. A read/write peer is the specific member of one, and only one, read/write pair in the cluster. There is bi-directional synchronous replication between read/write peers. Replication to all nodes that are not a given node's read/write peer is asynchronous.

    A node can be a member of, at most, one read/write pair. A node can have only one read/write peer. A node becomes a member of a read/write pair, and therefore a read/write node, during the induction process. A read/write node reverts to being a read-only node when its read/write peer is deleted, at which time it can form a new read/write pair.

    A read/write node operates in read/write mode when it can successfully replicate to its read/write peer and when both peers are active. A read/write node is temporarily placed in read-only restricted mode when it is unable to replicate to its read/write peer or when its read/write peer is disabled.

  • Create a Multi-Master Cluster

    A multi-master cluster is created by converting a single Oracle Key Vault server to become the initial node.

    This Oracle Key Vault server seeds the cluster data and converts the server into the first cluster node, which is called the initial node.

    After the Oracle Key Vault server has been converted to the initial node of the multi-master cluster, the different types of nodes that you need can be added to the cluster. The cluster is expanded when additional Oracle Key Vault servers are inducted and added as read/write nodes, or as simple read-only nodes.

Considerations

Consider the following points when deploying this reference architecture.

  • Performance

    For optimum performance and load balancing, add more read/write pairs.

    Multiple read-only nodes can be added to a cluster, but for optimum performance and load balancing, you must have more read/write pairs to prevent the cluster from being overloaded.

    Oracle Key Vault multi-master cluster requires at least one read/write pair to be fully operational. It can have a maximum of eight read/write pairs.

  • Availability

    The multi-node cluster provides high availability, disaster recovery, load distribution, and geographic distribution to an Oracle Key Vault environment. It provides a mechanism to create read/write pairs of Oracle Key Vault nodes for maximum availability and reliability.

    After you initialize the cluster, you can expand it by adding up to 15 more nodes, as either read/write pairs or read-only nodes. A multi-master cluster can contain a minimum of two nodes and a maximum of 16 nodes.

    You can add read-only Oracle Key Vault nodes to the cluster to provide even greater availability to endpoints that need Oracle wallets, encryption keys, Java keystores, certificates, credential files, and other objects.

Acknowledgments

  • Authors: Suzanne Holliday, Anwar Belayachi, Peter Wahl, Julien Silverston
  • Contributors: Wei Han, Leo Alvarado

Change Log

This log lists significant changes: