Data Protection

Learn about data protection in Oracle Database@Google Cloud.

Encryption at Rest for Oracle Database@Google Cloud

Oracle Database@Google Cloud supports Encryption at Rest to safeguard sensitive data residing in database files, backups, and configuration files. Encryption at rest ensures that data is encrypted whenever it is written to persistent storage and decrypted transparently when accessed by authorized Oracle processes. This protection is enabled by Transparent Data Encryption (TDE) and does not require any customer configuration.

Transparent Data Encryption (TDE)

Encryption at Rest is delivered using Transparent Data Encryption (TDE), a component of Oracle Advanced Security. TDE automatically encrypts tablespaces, as well as redo and undo logs, ensuring that all database information is written to disk in encrypted form. Data is decrypted transparently for authorized users and applications. Database backups created using Oracle Recovery Manager (RMAN) or managed backup solutions inherit the encryption configuration, protecting all copies of the database stored on persistent media.

Key Management

TDE requires a master encryption key to secure all tablespace and column encryption keys within the database. For Oracle Database@Google Cloud, you can choose between the following key management approaches:

  • Oracle-managed keys: The Oracle Database automatically generates and stores the master encryption key in an Oracle Wallet, located securely within the database environment. Oracle manages the key lifecycle operations, including backup and restore.
  • Customer-managed keys: You have the option to integrate with OCI Vault to generate and store the master encryption key externally from the database. This enables centralized control, lifecycle management, key rotation, and the ability to audit key usage events.

Customer-Managed Keys in Exadata Cloud Infrastructure

Customer-managed keys for Exadata Cloud Infrastructure enables you to encrypt your data using encryption keys that you control. You can:

  • Enable customer-managed keys when you create databases in Exadata Cloud Infrastructure
  • Switch from Oracle-managed keys to customer-managed keys
  • Rotate your keys to maintain security compliance

Exadata Database on Dedicated Infrastructure

View Encryption details
  1. Navigate to the Oracle Database@Google Cloud console.
  2. From the left-hand navigation pane select Dedicated Infrastructure from Exadata Database Service. Select the Exadata VM Cluster tab. Select the cluster name you're working with and select Manage in OCI. This will take you to OCI console.
  3. In the OCI console, Under the Databases section, select the database to check key management.
  4. In the Database Information Section, at Encryption you can locate the Encryption key. By default, it is Oracle-managed key.

A screenshot of data protection for Exadata Databases.

Manage Encryption Keys

  1. Navigate to the Oracle Database@Google Cloud console.
  2. From the left-hand navigation pane select Dedicated Infrastructure from Exadata Database Service. Select the Exadata VM Cluster tab. Select the cluster name you're working with and select Manage in OCI. This will take you to OCI console.
  3. In the OCI console, Under the Databases section, click the name of the database for which you want to change key management or rotate the encryption key.
    1. On the database details page, select the Actions dropdown.
    2. Select Manage Encryption Key.
    3. Select Change Key Management Type.
    4. From the Vault in Compartment dropdown, select the vault that contains your key. To switch compartments, click Change Compartment.
    5. From the Master Encryption Key dropdown, select the key you want to use. You can also switch compartments here if needed.
    6. (Optional) If you wish to use a specific version of the key, do the following.
      1. Check the box for Choose the key version.
      2. Enter the OCID of the key version.
      3. If you don’t specify a version, the latest version of the key will be used.
  4. Select Update to apply the changes.
Note

If you use Oracle Key Vault - Migration of TDE keys to Oracle Key Vault (OKV) requires an estimated 10 minutes of complete downtime. During the migration, database state will be UPDATING and connections may fail due to multiple database restarts to enable OKV. Applications can resume operation after the migration completes and when database returns to its original ACTIVE state. The OKV keystore password will be set to the current TDE wallet password.
Note

If you are using Oracle Managed Key, then Managing encryption key is not available for the databases that use Oracle managed encryption. This is applicable for operations like Rotate Encryption Key, Assign a new key version for both container and Pluggable Database.

Autonomous Database Service

View Encryption details

  1. Navigate to the Oracle Database@Google Cloud console.
  2. From the left-hand navigation pane:Select Autonomous Database from Autonomous Database Service. Click on the Display Name of your database. This will take open the details page.
  3. In the Details Section, at Encryption, you can locate the Encryption key. By default, it is an Oracle-managed key.

A screenshot of data protection for Autonomous Databases

Managing Encryption Keys

Managing encryption keys for an Oracle Autonomous Database deployed as part of Oracle Database@Google Cloud involves utilizing either Oracle-managed keys or customer-managed keys, with the latter offering more control over the encryption key lifecycle. You can switch to customer managed keys for TDE located in custom keystore like AWS, OKV or Microsoft Azure.

  1. Navigate to the Oracle Database@Google Cloud console.
  2. From the left-hand navigation pane: Select "Autonomous Database" from Autonomous Database Service. Click on the Display Name of your database. This will take open the details page.
  3. Click on the Manage in OCI. This will take you to the OCI console page of the particular Autonomous Database.
  4. In the OCI console, You are at the Autonomous Databases Information section.
  5. Expand on the More Action and Click on Manage Encryption Key.
  6. Click on Encrypt using customer-managed-key.
    1. Select the key Location > You can choose Oracle / AWS / Microsoft Azure / OKV
    2. If you choose Oracle - Specify the Tenancy > Compartment and vault.
    3. If you choose Amazon Web Services (AWS) - Specify the Service Endpoint URI , Key ARN, ARN Role and External ID.
    4. If you choose Microsft Azure - Specify the Vault URI and Key Name
    5. If you choose Oracle Key Vault (OKV) - Specify the OKV Key UUID, OKV Server URI, Certificate DN, Certificate ID and Directory Name.
  7. Click Save to apply the changes.

Encryption of Data in Transit

All Oracle Database deployments in Oracle Database@Google Cloud—including Exadata Database Service and Autonomous Database Service—are protected with encryption of data in transit by default. This ensures that data moving between clients, applications, and the database is secured from unauthorized interception or tampering.

Encryption in transit is implemented using Transport Layer Security (TLS) and mutual TLS (mTLS) for database connections. These protocols establish secure communication channels between database clients and servers, protecting authentication credentials and query data.

Connection Options:

  • TLS: Encrypts traffic between the client and the database using standard X.509 certificates.
  • mTLS: Provides two-way authentication in which both the client and the database present valid certificates before a connection is established. This option offers stronger identity assurance for enterprise workloads.

Exadata Database on Dedicated Infrastructure

By default, database deployments on Exadata Cloud Service are configured to enable native Oracle Net Services encryption and integrity. Also, by default, Oracle Net Services clients are configured to enable native encryption and integrity when they connect to an appropriately configured server. If your Oracle Net Services client is configured to explicitly reject the use of native encryption and integrity then connection attempts will fail.

  • Native SQL*Net encryption for all network connections - Relevant sqlnet.ora parameters set in Exadata Cloud Infrastructure by default are:
    • SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)
      SQLNET.ENCRYPTION_SERVER = requested
      SQLNET.CRYPTO_CHECKSUM_SERVER = accepted
      SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)
  • TCPS protocol offered for network connection to the database on port 2484 (wallet configured at /var/opt/oracle/dbaas_acfs/grid/tcps_wallets). Relevant sqlnet.ora parameters set in Exadata Cloud Infrastructure by default are:
    • SSL_CIPHER_SUITES = (SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
      SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
      SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
      SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

A screenshot of database connections for Exadata Databases

Autonomous Database

Connections to your Autonomous Database are secured, and can be authorized using TLS or mTLS authentication options. TLS authentication is easier to use, provides better connection latency, and does not require you to download client credentials (wallet) if any of these is true for your connections:

  • You are using JDBC Thin Client (version 12.2.0.1 or higher) with JDK 8(u163+) or higher.
  • You are using the Python python-oracledb driver.
  • You are using ODP.NET version 19.14 (or higher), or 21.5 (or higher).
  • You are using an Oracle Call Interface based driver with Oracle Client libraries version 19.14 (or higher), or 21.5 (or higher).

A screenshot of database connections for Autonomous Databases