Preregistration Tasks

Prior to registering a database, be sure to complete the necessary preregistration tasks. The tasks required depend on the type of database that you want to register.

This article has the following topics:

Create an Oracle Data Safe Service Account on Your Target Database

Every target database that you want to use with Oracle Data Safe requires an Oracle Data Safe service account on it. By default, Autonomous Databases already have this account. On non-Autonomous Databases, you need to create an account.

Exception for Autonomous Databases

For all types of Oracle databases that you want to register with Oracle Data Safe, except for Autonomous Databases, you need to manually create an Oracle Data Safe service account. Create it with the least amount of privileges on the database.

An Autonomous Database comes with an Oracle Data Safe service account precreated on it so you do not need to create one. The account is named DS$ADMIN and is initially locked with the password expired. When you register an Autonomous Database with Oracle Data Safe, Oracle Cloud Infrastructure unlocks this account and resets its password. If you deregister the Autonomous Database, the account is locked again.

Create an Oracle Data Safe Service Account on a Target Database

Create the Oracle Data Safe service account with the least amount of privileges.

  1. Log in to your database with an account that lets you create a user.
  2. Create a user account with minimal privileges, for example:
    CREATE USER DATASAFE_ADMIN identified by password
    DEFAULT TABLESPACE "DATA"
    TEMPORARY TABLESPACE "TEMP";
    GRANT CONNECT, RESOURCE TO DATASAFE_ADMIN;
    • Replace DATASAFE_ADMIN and password with your own values.
    • Do not use SYSTEM or SYSAUX as the default tablespace. You cannot mask data if you use these tablespaces.
  3. Grant roles to the Oracle Data Safe service account. See Grant Roles to the Oracle Data Safe Service Account on Your Target Database.

Grant Roles to the Oracle Data Safe Service Account on Your Target Database

The Oracle Data Safe features that you can use with your target database depend on the roles you grant to the Oracle Data Safe service account on that target database. You can grant and revoke roles as needed.

The roles are different for Autonomous Databases versus non-Autonomous Databases. For non-Autonomous databases, you can grant roles to the Oracle Data Safe service account prior to or after registering your database. For Autonomous Databases, you first need to register your database, which unlocks the Oracle Data Safe preseeded service account, and then grant and revoke roles as needed. By default, the Oracle Data Safe service account on an Autonomous Database is already granted some of the roles.

Roles for the Oracle Data Safe Service Account

Oracle recommends that you grant only the roles needed to the Oracle Data Safe service on your target databases. How you grant roles depends on the type of target databases that you have.

The following table describes the roles for non-Autonomous Databases and Autonomous Databases. If you are registering a non-Autonomous Database (for example, a DB system, on-premises Oracle Database, or an Oracle Database on a compute instance), you can grant the roles in the first column. If you are registering an Autonomous Database, you can grant the roles in the second column. By default, some or most of the roles are granted by default so it is best to refer to each type of target registration.

Roles for Non-Autonomous Databases Roles for Autonomous Databases Description

ASSESSMENT

DS$ASSESSMENT_ROLE

Privileges required for the User Assessment and Security Assessment features

AUDIT_COLLECTION

DS$AUDIT_COLLECTION_ROLE

Privileges required for accessing audit trails for the target database

DATA_DISCOVERY

DS$DATA_DISCOVERY_ROLE

Privileges required for the Data Discovery feature (discovering sensitive data in the target database)

MASKING

DS$DATA_MASKING_ROLE

Privileges required for the Data Masking feature (masking sensitive data in the target database)

AUDIT_SETTING

DS$AUDIT_SETTING_ROLE

Privileges required for updating target database audit policies

Grant Roles to the Oracle Data Safe Service on an Autonomous Database

By default, an Autonomous Database comes with a database account specifically created for Oracle Data Safe named DS$ADMIN. The roles that you grant to this account determine the Oracle Data Safe features that you can use with your Autonomous Database.

For an Autonomous Database on Shared Exadata Infrastructure, all roles are already granted by default, except for DS$DATA_MASKING_ROLE.

For an Autonomous Database on Dedicated Exadata Infrastructure, only DS$ASSESSMENT_ROLE and DS$AUDIT_COLLECTION_ROLE are granted by default. You need to grant the other roles.

Note:

If Database Vault is enabled on your Autonomous Database, be aware that there are specific steps to take in the procedure below to get Oracle Data Safe to work with Database Vault.

To grant or revoke roles from the Oracle Data Safe service account on an Autonomous Database database, you can run the DS_TARGET_UTIL PL/SQL package on the Autonomous Database. You need to run this package as the PDB Admin user (ADMIN) or as a user that has execute permission on the DS_TARGET_UTIL PL/SQL package.

You can grant or revoke roles as often as needed.

  1. If Database Vault is enabled on your database and you want to use the User Assessment or Security Assessment features in Oracle Data Safe, connect to your database as a user with the DV_OWNER role and grant the DV_SECANALYST role to the DS$ADMIN user.
  2. To grant or revoke a role from the Oracle Data Safe service account, do the following:
    1. Using a tool like SQL*Plus or SQL Developer, log in to your Autonomous Database as the PDB Admin user (ADMIN) or as a user that has execute permission on the DS_TARGET_UTIL PL/SQL package.
    2. Run one of the following commands:
      EXECUTE DS_TARGET_UTIL.GRANT_ROLE('role_name');

      or

      EXECUTE DS_TARGET_UTIL.REVOKE_ROLE('role_name');

      where role_name is the name of an Oracle Data Safe role. role_name must be in quotation marks.

      Note:

      If Database Vault is enabled on your database and you grant the DS$DATA_MASKING_ROLE role, expect an ORA-20001 error and proceed to step 3.
  3. If Database Vault is enabled on your database and you want to use the Data Masking feature in Oracle Data Safe, do the following:
    1. Connect to the database as a user with the DV_OWNER role and authorize the ADMIN user to the Oracle System Privilege and Role Management Realm.
    2. Connect to the database as the ADMIN user and grant UNLIMITED TABLESPACE to the DS$ADMIN user.
    You can now use the Data Masking feature.
  4. (Optional) If Database Vault is enabled on your database and you want to revoke the User Assessment or Security Assessment feature: Connect to the database as the a user with the DV_OWNER role and revoke the DV_SECANALYST role from the DS$ADMIN user.
    The Assessment features are no longer available for the database.
  5. (Optional) If Database Vault is enabled on your database and you want to revoke the Data Masking feature:
    1. Connect to the database as the ADMIN user and revoke UNLIMITED TABLESPACE from the DS$ADMIN user.
    2. Connect to the database as a user with the DV_OWNER role and unauthorize the ADMIN user from the Oracle System Privilege and Role Management Realm.
    The Data Masking feature is no longer available for the database.

Grant Roles to the Oracle Data Safe Service on a Non-Autonomous Database

To grant or revoke roles from the Oracle Data Safe service account on a non-Autonomous Database, you need to run a SQL privileges script called datasafe_privileges.sql. You can download this script from Oracle Data Safe in Oracle Cloud Infrastructure. To run the script, you need to be connected to your database as the SYS user.

You can run the script as many times as needed. For example, suppose that in the beginning you only need to use the Activity Auditing feature in Oracle Data Safe. You can run the SQL privileges script to grant the database access to only Activity Auditing. Later, you decide you want to use the Data Discovery feature too. You can run the SQL privileges script again on the database to grant the database access to Data Discovery. You cannot run the SQL privileges script on the root container of a database (CDB$ROOT).

  1. Download the SQL privileges script. This script is available within the wizards that assist with target database registration. You don't need to work through the wizard and register your target database at this time. Just start the wizard and you'll see the link to download the script on the first page. Download the script and exit the wizard.
    1. On the Overview page in the Oracle Data Safe service, find the tile for the wizard that corresponds to the type of database you are working with. Click Start Wizard.The wizard displays the Data Safe Target Information form.
    2. Click Download Privilege Script and save the datasafe_privileges.sql script to your computer.
    3. Click Cancel.
  2. With SQL Developer or SQL*Plus, connect to your database as the SYS user, and then run the SQL privileges script with the following statement:
    @datasafe_privileges.sql <DATASAFE_ADMIN> <GRANT|REVOKE> <AUDIT_COLLECTION|AUDIT_SETTING|DATA_DISCOVERY|MASKING|ASSESSMENT|ALL> [-VERBOSE]
    • <DATASAFE_ADMIN> is the name of the Oracle Data Safe service account that you created on your database. It is case-sensitive and must match the account name in the dba_users data dictionary view in your database.
    • Specify GRANT or REVOKE depending on whether you want to add privileges to or remove privileges from the Oracle Data Safe service account.
    • You can specify only one feature per command, although ALL grants or revokes privileges for all features.
    • -VERBOSE is optional.
    For example, to grant all privileges (and make all Oracle Data Safe features available):
    @datasafe_privileges.sql <DATASAFE_ADMIN> GRANT ALL -VERBOSE

    To grant the privileges required to use a feature (masking in this example):

    @datasafe_privileges.sql <DATASAFE_ADMIN> GRANT MASKING

Create a Wallet or Certificates for a TLS Connection

Prior to configuring a TLS connection to a non-Autonomous Database during target registration, you need to create one or more wallets or a certificate, depending on whether client authentication is enabled on your database.

The following are two examples:

Create JKS Wallets for a TLS Connection to a DB System that has Client Authentication Enabled

During target registration, you can configure a TLS connection between Oracle Data Safe and a DB system. You are required to upload two JKS wallets: a TrustStore wallet and a KeyStore wallet.

In this article, you learn how to create these two JKS wallets with self-signed certificates. While self-signed certificates are fine for testing purposes, Oracle recommends that you use certificates signed by a trusted or internal certificate authority (CA) for production systems.

You also learn how to enable client authentication on your DB system and configure the listener to accept SSL/TLS encrypted connections.

Part 1: Create a Database Server Wallet and Certificate

From the command line, access your database server. Then, as shown below, use the orapki utility to create a database server wallet, create a self-signed certificate and load it into the wallet, and export the certificate. Ensure that the location to the orapki utility is added to your path.

  1. Create a directory for your database server wallet.
    $ mkdir -p <wallet path>

    For example:

    $ mkdir -p /u01/app/oracle/myserverwallet
  2. Create an auto-login wallet.
    $ orapki wallet create -wallet <wallet path> -pwd <wallet password> -auto_login

    For example:

    $ orapki wallet create -wallet /u01/app/oracle/myserverwallet -pwd mypassword -auto_login
  3. Create a self-signed certificate and load it into the wallet.
    $ orapki wallet add -wallet <wallet path> -pwd <wallet password> -dn "CN=<database hostname>" -keysize 1024 -self_signed -validity 3650

    For example:

    $ orapki wallet add -wallet /u01/app/oracle/myserverwallet -pwd mypassword -dn "CN=CloudST2.debdev19.oraclecloud.internal" -keysize 1024 -self_signed -validity 3650
  4. Check the contents of the wallet. Notice that the self-signed certificate is both a user certificate and trusted certificate.
    $ orapki wallet display -wallet <wallet path> -pwd <wallet password>

    For example:

    $ orapki wallet display -wallet /u01/app/oracle/myserverwallet -pwd mypassword
     
    ... 
    Requested Certificates:
    User Certificates:
    Subject:        CN=CloudST2.debdev19.oraclecloud.internal
    Trusted Certificates:
    Subject:        CN=CloudST2.debdev19.oraclecloud.internal
  5. Export the certificate so that you can load it into the client wallet later.
    $ orapki wallet export -wallet <wallet path> -pwd <wallet password>  -dn "CN=<hostname>" -cert <server certificate path>

    In this example, you export the certificate into a tmp directory on your database server. The certificate name can be whatever you want, but it needs to have a CRT file extension.

    $ orapki wallet export -wallet /u01/app/oracle/myserverwallet -pwd mypassword -dn "CN=CloudST2.debdev19.oraclecloud.internal" -cert /tmp/CloudST2-certificate.crt
  6. Check that the certificate has been exported as expected.
    $ cat <server certificate path>

    For example:

    $ cat /tmp/CloudST2-certificate.crt
    -----BEGIN CERTIFICATE-----
    MIIB0TCCAToCAQAwDQYJKoZIhvcNAQEEBQAwMTEvMC0GA1UEAxMmQ2xvdWRTVDIuZGViZGV2MTku
    b3JhY2xlY2xvdWQuaW50ZXJuYWwwHhcNMTYwNTExMTEyMDI2WhcNMjYwNTA5MTEyMDI2WjAxMS8w
    LQYDVQQDEyZDbG91ZFNUMi5kZWJkZXYxOS5vcmFjbGVjbG91ZC5pbnRlcm5hbDCBnzANBgkqhkiG
    9w0BAQEFAAOBjQAwgYkCgYEAr6fhuQly2t3i8gugLVzgP2kFGVXVOzqbggEIC+Qazb15JuKs0ntk
    En9ERGvA0fxHkAkCtIPjCzQD5WYRU9C8AQQOWe7UFHae7PsQX8jsmEtecpr5Wkq3818+26qU3Jyi
    XxxK/rRydwBO526G5Tn5XPsovaw/PYJxF/fIKMG7fzMCAwEAATANBgkqhkiG9w0BAQQFAAOBgQCu
    fBYJj4wQYriZIfjij4eac/jnO85EifF3L3DU8qCHJxOxRgK97GJzD73TiY20xpzQjWKougX73YKV
    Tp9yusAx/T/qXbpAD9JKyHlKj16wPeeMcS06pmDDXtJ2CYqOUwMIk53cK7mLaAHCbYGGM6btqP4V
    KYIjP48GrsQ5MOqd0w==
    -----END CERTIFICATE-----
Part 2: Create a Client Wallet and Certificate

You can continue to work from your database server. From the command line, use the orapki utility to create a client wallet, create a self-signed certificate and load it into the wallet, and export the certificate.

  1. Create a directory for your client wallet.
    $ mkdir -p <client wallet path>

    For example:

    $ mkdir -p /u01/app/oracle/myclientwallet
  2. Create another auto-login wallet.
    $ orapki wallet create -wallet <client wallet path> -pwd <wallet password> -auto_login

    For example:

    $ orapki wallet create -wallet /u01/app/oracle/myclientwallet -pwd mypassword -auto_login
  3. Create a self-signed certificate and load it into the wallet.
    $ orapki wallet add -wallet <client wallet path> -pwd <wallet password> -dn "CN=<client computer name>" -keysize 1024 -self_signed -validity 3650

    For example:

    $ orapki wallet add -wallet /u01/app/oracle/myclientwallet -pwd mypassword -dn "CN=myhost.example.com" -keysize 1024 -self_signed -validity 3650
  4. Check the contents of the wallet. Notice that the self-signed certificate is both a user certificate and trusted certificate.
    $ orapki wallet display -wallet <client wallet path> -pwd <wallet password>

    For example:

    $ orapki wallet display -wallet /u01/app/oracle/myclientwallet -pwd mypassword
    
    ...
    Requested Certificates:
    User Certificates:
    Subject:        CN=myhost.example.com
    Trusted Certificates:
    Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
    Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US
    Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
    Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
    Subject:        CN=myhost.example.com
  5. Export the certificate so that you can load it into the server wallet later.
    $ orapki wallet export -wallet <client wallet path> -pwd <wallet password> -dn "CN=<client computer fullname>" -cert <certificate path>

    In this example, we export the certificate into a tmp directory. The certificate name can by anything you like, but it must have a CRT extension.

    $ orapki wallet export -wallet /u01/app/oracle/myclientwallet -pwd mypassword -dn "CN=myhost.example.com" -cert /tmp/gbr30139-certificate.crt
  6. Check the certificate.
    $ more <certificate path>

    For example:

     $ more /tmp/gbr30139-certificate.crt
    
    -----BEGIN CERTIFICATE-----
    MIIBsTCCARoCAQAwDQYJKoZIhvcNAQEEBQAwITEfMB0GA1UEAxMWZ2JyMzAxMzkudWsub3JhY2xl
    LmNvbTAeFw0xNjA1MTExMTQzMzFaFw0yNjA1MDkxMTQzMzFaMCExHzAdBgNVBAMTFmdicjMwMTM5
    LnVrLm9yYWNsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKH8G8sFS6l0llu+RMfl
    7Yt+Ppw8J0PfDEDbTGP5wtsrs/22dUCipU9l+vif1VgSPLE2UPJbGM8tQzTC6UYbBtWHe4CshmvD
    EVlcIMsEFvD7a5Q+P45jqNSEtV9VdbGyxaD6i5Y/Smd+B87FcQQCX54LaI9BJ8SZwmPXgDweADLf
    AgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAai742jfNYYTKMq2xxRygGJGn1LhpFenHvuHLBvnTup1N
    nZOBwBi4VxW3CImvwONYcCEFp3E1SRswS5evlfIfruCZ1xQBoUNei3EJ6O3OdKeRRp2E+muXEtfe
    U+jwUE+SzpnzfpI23Okl2vo8Q7VHrSalxE2KEhAzC1UYX7ZYp1U=
    -----END CERTIFICATE-----
Part 3: Exchange Client and Server Certificates

Continue to work on the database server. Load the server certificate as a trusted certificate into the client wallet, and load the client certificate into the server wallet. You do this because each side of the connection needs to trust the other.

  1. Load the server certificate into the client wallet.
    $ orapki wallet add -wallet <client wallet path> -pwd <wallet password> -trusted_cert -cert <server certificate path>

    For example:

    $ orapki wallet add -wallet /u01/app/oracle/myclientwallet -pwd mypassword -trusted_cert -cert /tmp/CloudST2-certificate.crt
  2. Check the contents of the client wallet. Notice that the server certificate is now included in the list of trusted certificates.
    $ orapki wallet display -wallet <client wallet path> -pwd <wallet password>

    For example:

    $ orapki wallet display -wallet /u01/app/oracle/myclientwallet -pwd mypassword
    
    ...
    Requested Certificates:
    User Certificates:
    Subject:        CN=myhost.example.com
    Trusted Certificates:
    Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
    Subject:        CN=myhost.example.com
    Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US
    Subject:        CN=CloudST2.debdev19.oraclecloud.internal
    Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
    Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
    
  3. Load the client certificate into the server wallet.
    $ orapki wallet add -wallet <server wallet path> -pwd wallet password -trusted_cert -cert <client certificate path>

    For example:

    $ orapki wallet add -wallet /u01/app/oracle/myserverwallet -pwd mypassword -trusted_cert -cert  /tmp/gbr30139-certificate.crt
  4. Check the contents of the server wallet. Notice that the client certificate is now included in the list of trusted certificates.
    $ orapki wallet display -wallet <server wallet path> -pwd <wallet password>

    For example:

    $ orapki wallet display -wallet /u01/app/oracle/myserverwallet -pwd mypassword
    
    ...
    Requested Certificates:
    User Certificates:
    Subject:        CN=CloudST2.debdev19.oraclecloud.internal
    Trusted Certificates:
    Subject:        CN=CloudST2.debdev19.oraclecloud.internal
    Subject:        CN=myhost.example.com
    
Part 4: Create a JKS Wallet from the PKCS#12 Wallet

In this part, you use the orapki utility to convert the client wallet, which is currently in PKCS#12 format, into a JKS wallet. You do this because Oracle Data Safe requires a JKS wallet and does not support PKCS#12 wallets.

  1. Enter the following command to create a JKS wallet:
    $ orapki wallet pkcs12_to_jks -wallet  <client wallet location> -pwd <password> [-jksKeyStoreLoc  <jksKSloc> 
    -jksKeyStorepwd <jksKSpwd>] [-jksTrustStoreLoc <jksTSloc> -jksTrustStorepwd <jksTSpwd>]

    where the parameters are as follows:

    • <server wallet location> is the p12 server wallet location
    • <password> is the wallet password
    • <jksKSloc> is the JKS KeyStore location
    • <jksKSpwd> is the JKS KeyStore password
    • <jksTSloc> is the JKS TrustStore location
    • <jksTSpwd> is the JKS TrustStore password

    For example:

    $ orapki wallet pkcs12_to_jks  -wallet /u01/app/oracle/myclientwallet -pwd password -jksKeyStoreLoc /tmp/keystore.jks  
    -jksKeyStorepwd password -jksTrustStoreLoc /tmp/truststore.jks  -jksTrustStorepwd password

    The JKS TrustStore and JKS KeyStore files, truststore.jks and keystore.jks respectively, get created after this command is successfully executed. You upload these files during target registration in Oracle Data Safe.

    Note:

    The JKS TrustStore and JKS KeyStore file names can be anything you want.
  2. Copy the JKS TrustStore and JKS KeyStore files to your client machine.
Part 5: Configure the Server Network

In this part, you configure the wallet location, enable client authentication, and enable SSL/TLS encrypted connections on the target database.

  1. In the sqlnet.ora file on the database server, add the wallet information and enable client authentication. To do this, open $ORACLE_HOME/network/admin/sqlnet.ora on the database server, and add the following entries. Also, ensure that double encryption is not enabled in sqlnet.ora.
    WALLET_LOCATION =
       (SOURCE =
         (METHOD = FILE)
         (METHOD_DATA =
           (DIRECTORY = /u01/app/oracle/myserverwallet)
         )
       )
    
    SSL_CLIENT_AUTHENTICATION = TRUE
  2. In the listener.ora file on the database server, add the wallet information and configure the listener to accept SSL/TLS encrypted connections. To do this, open $ORACLE_HOME/network/admin/listener.ora file, enter the wallet information, and add a TCPS entry.

    For example:

    SSL_CLIENT_AUTHENTICATION=TRUE
    WALLET_LOCATION =
      (SOURCE =
        (METHOD = FILE)
        (METHOD_DATA =
          (DIRECTORY = /u01/app/oracle/myserverwallet)
        )
      )
    
    LISTENER =
      (DESCRIPTION_LIST =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = TCP)(HOST = server1.localdomain)(PORT = 1521))
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
          (ADDRESS = (PROTOCOL = TCPS)(HOST = server1.localdomain)(PORT = 1522))
        )
    )
  3. Restart the listener.
    $ lsnrctl stop
    $ lsnrctl start
Part 6: Configure the TLS Connection During Target Registration in Oracle Data Safe

When you register the target database in Oracle Data Safe, make sure to do the following:

  • Select the TLS connection type.
  • Set the port number according to the port number you set in the listener.ora file. In this example, the port number is 1522.
  • For the server distinguished name, enter the name you used when you created the self-signed certificate for the target database. In this example, the name is CN=CloudST2.debdev19.oraclecloud.internal.
  • Select JKS wallet type.
  • Upload the JKS TrustStore file. In this example, it is truststore.jks.
  • Upload the JKS KeyStore file. In this example, it is keystore.jks.

Create a PEM Certificate for a TLS Connection to a DB System that has Client Authentication Disabled

In this article, you learn how to create a PEM certificate that you can use when configuring a TLS connection between Oracle Data Safe and a DB system that has client authentication disabled. This example shows you how to create a self-signed certificate. While a self-signed certificate is fine for testing purposes, Oracle recommends that you use a certificate signed by a trusted or internal certificate authority (CA) for production systems.

  1. Ensure that the location to the orapki utility is added to your path. The examples in this procedure use this utility.
  2. From a command window on your server, create a location for your wallet and change to the wallet directory.
    $ mkdir /mywallets
    $ cd /mywallets
  3. Create a wallet in the current directory.
    $ orapki wallet create -wallet ./ -pwd password -auto_login 
  4. View the contents of the wallet.
    $ orapki wallet display -wallet . -pwd password

    Notice that there are no certificates in the wallet yet.

  5. Create a self-signed (root) certificate and add it to the wallet.
    $ orapki wallet add -wallet . -dn "CN=rootca" -keysize 2048 -self_signed -validity 3650 -sign_alg sha256 -pwd password

    The certificate is added to the wallet for the user with the specified distinguished name (CN=rootca).

    The certificate contains a key pair (private key and public key).

    -keysize is the size of the private key.

    -validity 3650 specifies the number of days, starting from the current date, that the certificate is valid.

    -self_signed means that an external certification authority (CA) does not need to sign the private key and public key.

    sha256 is the signing algorithm.

  6. View the contents of the wallet and verify that you have a User Certificate and a Trusted Certificate:
    $ orapki wallet display -wallet . -pwd password

    Under User Certificates, you should now have CN=rootca.

    Under Trusted Certificates, you should now have CN=rootca.

    The User Certificate and Trusted Certificate are the same in that they sign themselves (self-signed).

  7. Export the self-signed certificate from the wallet:
    $ orapki wallet export -wallet . -dn "CN=rootca" -cert root1.crt -pwd password

    root1.crt is the name of the exported file.

  8. Configure the wallet on the target database by doing the following:
    1. Copy the self-signed certificate to the wallet folder on your target database.
    2. In the listener.ora file on the target database, add a line SSL_CLIENT_AUTHENTICATION = FALSE, enable the port for TCPS (for example, 1553), and define the wallet. Use the following code example as a guideline.
      # listener configuration file
      
      CONNECT_TIMEOUT_LISTENER = 0
      SSL_CLIENT_AUTHENTICATION = FALSE
      LISTENER = (ADDRESS_LIST =
      	(ADDRESS=(PROTOCOL=ipc)(KEY=19c))
      	(ADDRESS=(PROTOCOL=tcp)(HOST=ipaddress)(PORT=1552))
      	(ADDRESS=(PROTOCOL=tcps)(HOST=ipaddress)(PORT=1553))
      )
      WALLET_LOCATION = 
        (SOURCE =
      	(METHOD = FILE)
      	(METHOD_DATA =
      	   (DIRECTORY = /home/oracle/wallet)
      	)
         )
    3. In the sqlnet.ora file on the target database, add a line SSL_CLIENT_AUTHENTICATION = FALSE and add the wallet location. Use the following code example as a guideline.
      # sqlnet configuration file for clients
      
      automatic_ipc = off
      SQLNET.AUTHENTICATION_SERVICES = (beq, none)
      SSL_CLIENT_AUTHENTICATION = FALSE
      names.preferred_servers = (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=19c_ns))(CONNECT_DATA=(RPC=ON)))
      
      namesctl.noconfirm = true
      WALLET_LOCATION=
      	(SOURCE=(METHOD=FILE)(METHOD_DATA=
      	  (DIRECTORY=/home/oracle/mywallets)))
    4. From a command window, restart the listener on the target database.
      $ lsnrctl start
      $ lsnrctl stop
  9. When you register the target database in Oracle Data Safe, make sure to do the following:
    • Select the connection type TLS.
    • Set the port number according to the port number you set in the listener.ora file. In this example, the port number is 1553.
    • For the server distinguished name, enter the name you used when you created the self-signed certificate in the wallet. In this example, the name is CN=rootca.
    • For the wallet or certificate type, select PEM Certificate and select the self-signed certificate that you exported from the wallet. In this example, the file is root1.crt.

Configure a TLS Connection Between the On-Premises Connector on Your Host Machine and Your Oracle Database

Prior to configuring a TLS connection during target registration, you need to configure a TLS connection between the Connection Manager of the on-premises connector on your host machine and your Oracle database.

  1. Open a command prompt on the host machine that has the unzipped install bundle.
  2. Find the distinguished name (DN) of the Connection Manager certificate from the client Connection Manager wallet by running the following command:
    orapki wallet display -wallet <CMAN wallet location>
  3. Export the Connection Manager certificate by running the following command:
    orapki wallet export -wallet <Connection Manager wallet location> -dn <distinguished name of the Connection Manager certificate> -cert <Connection Manager certificate file name>
  4. Add the Connection Manager certificate to your on-premises Oracle database server's wallet by running the following command:
    orapki wallet add -wallet <database wallet location> -trusted_cert -cert <Connection Manager certificate file name>
  5. Export the database server certificate by running the following command:
    orapki wallet export -wallet <database wallet location> -dn <db server DN> -cert <database server certificate file>
  6. Add the database server certificate to the Connection Manager wallet by running the following command. When prompted, enter the wallet password. This is the password that you created when you downloaded and installed the install bundle.
    orapki wallet add -wallet <Connection Manager wallet location> -trusted_cert -cert <database server certificate file>
  7. Restart the database listener and restart the on-premises connector.

Add Oracle Data Safe's NAT Gateway IP Address to Your Virtual Cloud Network's Security List

To allow Oracle Data Safe to connect to an Oracle Cloud database with a public IP address, a database administrator needs to add an ingress security rule to the target database's virtual cloud network (VCN). The rule needs to specify the Oracle Data Safe's Network Address Translation (NAT) gateway IP address that corresponds to the region in which Oracle Data Safe is enabled.

The following table lists the IP addresses of the Network Address Translation (NAT) gateways for the regional Oracle Data Safe services in Oracle Cloud Infrastructure.

Region Name Region Identifier IP Address
Australia East (Sydney) ap-sydney-1 192.29.144.137
Australia Southeast (Melbourne) ap-melbourne-1 192.29.208.54
Brazil East (Sao Paulo) sa-saopaulo-1 192.29.128.12
Brazil 2 South East (Vinhedo) sa-vinhedo-1 129.149.3.3
Canada Southeast (Toronto) ca-toronto-1 192.29.11.175
Canada Southeast (Montreal) ca-montreal-1 192.29.80.133
Chile Central (Santiago) sa-santiago-1 129.149.33.79
France 1 South (Marseille) eu-marseille-1 129.149.96.76
Germany Central (Frankfurt) eu-frankfurt-1 138.1.2.134
India Central (Hyderabad) ap-hyperabad 129.148.128.73
India West (Mumbai) ap-mumbai-1 192.29.50.43
Isreal 1 (Jerusalem) il-jerusalem-1 129.149.121.123
Italy 1 Northwest (Milan) eu-milan-1 129.149.113.84
Japan Central (Osaka) ap-osaka-1 192.29.241.166
Japan East (Tokyo) ap-tokyo-1 192.29.39.149
Netherlands Northwest (Amsterdam) eu-amsterdam-1 192.29.192.5
NRI Dedicated Region ap-chiyoda-1 151.104.93.74
NRI Dedicated Region (Osaka) ap-ibaraki-1 151.104.113.252
Saudi Arabia West (Jeddah) me-jeddah-1 192.29.224.67
Singapore 1 ap-singapore-1 129.148.179.67
South Korea Central (Seoul) ap-seoul-1 192.29.21.43
South Korea North (Chuncheon) ap-chuncheon-1 129.148.144.110
Sweden 1 Central (Stockholm) eu-stockholm-1 129.149.82.65
Switzerland North (Zurich) eu-zurich-1 192.29.56.254
UAE East (Dubai) me-dubai-1 129.148.214.150
UAE 2 Central (Abu Dhabi) me-abudhabi-1 129.149.51.0
UK Gov South (London) uk-gov-london-1 151.104.51.221
UK Gov West (Newport) uk-gov-cardiff-1 151.104.60.181
UK South (London) uk-london-1 147.154.236.187
UK West (Cardiff) uk-cardiff-1 129.149.16.17
US DoD East (Ashburn) us-gov-ashburn-1 155.248.73.73
US East (Ashburn) us-ashburn-1 147.154.0.253
US Gov East (Ashburn) us-langley-1 155.248.8.210
US West (Phoenix) us-phoenix-1 147.154.108.200
US West (San Jose) us-sanjose-1 129.148.160.136

For more information, see Security Lists in the Oracle Cloud Infrastructure documentation.

Obtain Permissions to Register an Autonomous Database with Oracle Data Safe

To register an Autonomous Database with Oracle Data Safe, you require permissions in Oracle Cloud Infrastructure Identity and Access Management (IAM).

The permissions are explained as follows:

  • Permission in IAM to access to the database: The user group requires at least the use permission on the autonomous-database resource in Oracle Cloud Infrastructure. See the autonomous-databases Resource section in OCI Resources for Oracle Data Safe.
  • Permission in IAM to register a database with Oracle Data Safe: The user group requires the manage permission on the target-databases resource in Oracle Cloud Infrastructure. See the section called target-databases Resource in OCI Resources for Oracle Data Safe.
  • (Databases with private IP addresses) Permission in IAM to use or create an Oracle Data Safe private endpoint: To register an Autonomous Database that has a private IP address, you need to create or have access to an Oracle Data Safe private endpoint in Oracle Cloud Infrastructure. See the section named data-safe-private-endpoints Resource in OCI Resources for Oracle Data Safe.
  • (Databases with private IP addresses) Permission in IAM to use or create virtual networking resources: If you plan to create an Oracle Data Safe private endpoint to connect to your Autonomous Database, you need to obtain permissions in Oracle Cloud Infrastructure Identity and Access Management (IAM) on the underlying virtual networking resources of a private endpoint for the relevant compartments in your tenancy. See the section named Virtual Cloud Networking Resources in OCI Resources for Oracle Data Safe.
  • (Autonomous Database on Dedicated Exadata Infrastructure) If Database Vault is enabled on the database, connect to your database as a user with the DV_ACCTMGR role and temporarily grant the DV_ACCTMGR role to the ADMIN user.
  • (Autonomous Database on Dedicated Exadata Infrastructure) Obtain the ADMIN password for your target database because you need it during target database registration.

Obtain Permissions to Register an Oracle Cloud Database with Oracle Data Safe

Prior to registering an Oracle Cloud Database with Oracle Data Safe, you need to obtain permissions in Oracle Cloud Infrastructure Identity and Access Management (IAM), on the database, and in Oracle Data Safe. If your target database has a private IP address, you need to obtain permissions to use or create an Oracle Data Safe private endpoint.

The permissions are explained as follows:

  • Permission in IAM to access to the database: You require at least the inspect permission on three resource types: db-systems, db-nodes, and vnics. For example, to grant the Data-Safe-Admins group the inspect permission on all db-systems, db-nodes, and vnics in a tenancy, a tenancy administrator could write the following policy:
    allow group Data-Safe-Admins to inspect db-systems in tenancy
    allow group Data-Safe-Admins to inspect db-nodes in tenancy
    allow group Data-Safe-Admins to inspect vnics in tenancy
  • (Exadata Cloud Service) Permission in IAM to inspect cloud virtual machine clusters in the tenancy: You require the inspect permission on the cloud-vmclusters resource in your tenancy in Oracle Cloud Infrastructure. For example:
    allow group Data-Safe-Admins to inspect cloud-vmclusters in tenancy
  • Permission in IAM to register a database with Oracle Data Safe: You require the manage permission on the target-databases resource in Oracle Cloud Infrastructure. See the section called target-databases Resource in OCI Resources for Oracle Data Safe.
  • (Target database has private IP address) Permission in IAM to use or create an Oracle Data Safe private endpoint: If your target database has a private IP address, you need to connect to it using an Oracle Data Safe private endpoint. To access or create an Oracle Data Safe private endpoint, you require permissions in IAM. You also require permission in IAM to access or create the underlying virtual cloud networking resources for the private endpoint for the relevant compartments in your tenancy. See the sections named data-safe-private-endpoints Resource and Virtual Cloud Networking Resources in OCI Resources for Oracle Data Safe.
  • Permission to use at least one feature in Oracle Data Safe: You require privileges in Oracle Data Safe via an authorization policy to use at least one Oracle Data Safe feature in the compartment where your target database resides. See Create IAM Policies for Oracle Data Safe Users and Configure Authorization Policies in Oracle Data Safe.
  • Permission to log in to the database as an administrator: You need to be able to log in as the SYS account on your target database to create the Oracle Data Safe service account and run the SQL privileges script to enable Oracle Data Safe features on the target database.

Obtain Permissions to Register an On-Premises Oracle Database with Oracle Data Safe

To register an on-premises Oracle database with Oracle Data Safe, you require permissions in Oracle Cloud Infrastructure Identity and Access Management (IAM), on the database, and optionally in the Oracle Data Safe Console. The permissions are different if you use an Oracle Data Safe private endpoint versus an Oracle Data Safe on-premises connector to connect to your target database.

The permissions are explained as follows:

  • Permission in IAM to register a database with Oracle Data Safe: You require the manage permission on the target-databases resource in Oracle Cloud Infrastructure. See the section called target-databases Resource in OCI Resources for Oracle Data Safe.
  • (Option 1) Permission in IAM to use or create an Oracle Data Safe private endpoint: If your target database has a private IP address, you can connect to it using an Oracle Data Safe private endpoint. To access or create an Oracle Data Safe private endpoint, you require permissions in IAM. You also require permission in IAM to access or create the underlying virtual cloud networking resources for the private endpoint for the relevant compartments in your tenancy. See the sections named data-safe-private-endpoints Resource and Virtual Cloud Networking Resources in OCI Resources for Oracle Data Safe.
  • (Option 2) Permission in IAM to use or create an Oracle Data Safe on-premises connector: If your target database has a private IP address, you can connect to it using an Oracle Data Safe on-premises connector. To access or create an on-premises connector, you require permissions in IAM. See the section named onprem-connectors Resource in OCI Resources for Oracle Data Safe.
  • Permission to use at least one feature in Oracle Data Safe: You require privileges in Oracle Data Safe via an authorization policy or IAM policy to use at least one Oracle Data Safe feature in the compartment where your target database resides. See Create IAM Policies for Oracle Data Safe Users and Configure Authorization Policies in Oracle Data Safe.
  • Permission on the database to log in as an administrator: You need to be able to log in as the SYS account to create the Oracle Data Safe service account and run the SQL privileges script to enable Oracle Data Safe features on the target database.

Obtain Permissions to Register an Oracle Database on Compute with Oracle Data Safe

To register an Oracle Database on Compute with Oracle Data Safe, you require permissions in Oracle Cloud Infrastructure Identity and Access Management (IAM), on the database, and optionally in the Oracle Data Safe Console. The permissions are different if you use an Oracle Data Safe private endpoint versus an Oracle Data Safe on-premises connector to connect to your target database.

The permissions are explained as follows:

  • Permission in IAM to register a database with Oracle Data Safe: You require the manage permission on the target-databases resource in Oracle Cloud Infrastructure. See the section called target-databases Resource in OCI Resources for Oracle Data Safe.
  • (Option 1) Permission in IAM to use or create an Oracle Data Safe private endpoint: If your target database has a private IP address, you need to connect to it using an Oracle Data Safe private endpoint. To access or create an Oracle Data Safe private endpoint, you require permissions in IAM. You also require permission in IAM to access or create the underlying virtual cloud networking resources for the private endpoint for the relevant compartments in your tenancy. See the sections named data-safe-private-endpoints Resource and Virtual Cloud Networking Resources in OCI Resources for Oracle Data Safe.
  • (Option 2) Permission in IAM to use or create an Oracle Data Safe on-premises connector: If your target database has a private IP address, you can connect to it using an Oracle Data Safe on-premises connector. To access or create an on-premises connector, you require permissions in IAM. See the section named onprem-connectors Resource in OCI Resources for Oracle Data Safe.
  • Permission to use at least one feature in Oracle Data Safe: You require privileges in Oracle Data Safe through an authorization policy or IAM policy to use at least one Oracle Data Safe feature in the compartment where your target database resides. See Create IAM Policies for Oracle Data Safe Users and Configure Authorization Policies in Oracle Data Safe.
  • Permission on the database to log in as an administrator: You need to be able to log in as the SYS account to create the Oracle Data Safe service account and run the SQL privileges script to enable Oracle Data Safe features on the target database.

Add Security Rules

If you plan to connect to your target database with an Oracle Data Safe private endpoint, prior to registering your target database, you need to add security rules to your virtual cloud network (VCN) to allow communication between your target database and Oracle Data Safe.

Overview

You can add the necessary security rules to your virtual cloud network's (VCN's) security lists or network security groups (NSGs). Both stateful and stateless security rules are allowed. In general, the security rules need to 1) allow your target database to receive incoming traffic from Oracle Data Safe, and 2) allow Oracle Data Safe to send requests to the target database.

There are two approaches that you can take when creating the security rules. The first approach is to allow communication between Oracle Data Safe and all IP addresses within the same subnet (0.0.0.0/0). With this configuration, Oracle Data Safe can connect to all of your target databases in the subnet.

The other approach is to be more specific by configuring separate ingress and egress rules as follows:
  • In the NSG or security list for your target database, add an ingress rule that allows your target database's private endpoint IP address on the target database's port to receive incoming traffic from Oracle Data Safe's private endpoint IP address from all ports.
  • In the NSG or security list for your Oracle Data Safe private endpoint, add an egress rule that allows Oracle Data Safe's private endpoint IP address on all ports to send requests to the target database's private endpoint IP address on the target database's port. If the target database has multiple IP addresses, you need configure an egress rule for each IP address. In the case of an Oracle On-Premises Database, you only need to configure an egress rule, and not an ingress rule.

For more information about security lists and network security groups, see Access and Security in the Oracle Cloud Infrastructure documentation.

Add Security Rules for an Autonomous Database on Shared Exadata Infrastructure with Private VCN Access

For an Autonomous Database on Shared Exadata Infrastructure with Private VCN Access, you need to create an ingress rule and an egress rule in the target database's virtual cloud network (VCN) in Oracle Cloud Infrastructure..

  1. Obtain the private IP address and NSG or security list for your target database.
    You can find the network information on the Autonomous Database Information tab under Network in your database's Console in Oracle Cloud Infrastructure. For example, suppose your target database's private endpoint's IP address is 10.0.0.112 and the NSG name is nsg-atp.
  2. Obtain the private IP address and NSG or security list for your Oracle Data Safe private endpoint.
    You can find the network information for your Oracle Data Safe private endpoint on the Private Endpoint Information page in the Oracle Data Safe service in Oracle Cloud Infrastructure.
  3. Open the VCN for your target database.
  4. In your target database's NSG or security list, create an ingress rule that allows your target database's private endpoint IP address (for example, 10.0.0.112/32) on the target database's port (for example, 1522) to receive incoming traffic from Oracle Data Safe's private endpoint IP address (for example, 10.0.0.79/32) from all ports.
    Ingress rule for NSG
  5. In your Oracle Data Safe private endpoint's NSG or security list, create an egress rule that allows Oracle Data Safe's private endpoint IP address (for example, 10.0.0.79/32) on all ports to send requests to the target database's private endpoint IP address (for example, 10.0.0.112/32) on the target database's port (for example, port 1522).
    Egress security rule for NSG

Add Security Rules for an Autonomous Database on Dedicated Exadata Infrastructure

For an Autonomous Database on Dedicated Exadata Infrastructure, you need to create an ingress rule and an egress rule in the target database's virtual cloud network (VCN) in Oracle Cloud Infrastructure.
  1. Obtain the subnet (or floating IP addresses if known) and the name of the NSG or security list for your target database.
    An Autonomous Database on Dedicated Exadata Infrastructure can have up to 8 floating IP addresses for the database nodes.
  2. Obtain the private IP address and the name of the NSG or security list for your Oracle Data Safe private endpoint.
    You can find this information on the Private Endpoint Information page in the Oracle Data Safe service in Oracle Cloud Infrastructure.
  3. Open the VCN for your target database.
  4. In your target database's NSG or security list: Create an ingress rule that allows your target database's private endpoint on port 2484 to receive incoming traffic from Oracle Data Safe's private endpoint IP address (from all ports).
  5. In your Oracle Data Safe private endpoint's NSG or security list, do one of the following:
    • Create an egress rule that allows the Oracle Data Safe private endpoint (from all ports) to send requests to all IP addresses on the target database's subnet on port 2484.
    • For each floating IP address, create an egress rule that allows the Oracle Data Safe private endpoint (from all ports) to send requests to the floating IP address on port 2484.

Add Security Rules for an Oracle Cloud Database

For an Oracle Cloud Database, you need to create an ingress rule and an egress rule in the target database's virtual cloud network (VCN) in Oracle Cloud Infrastructure.

  1. Obtain the IP address(es) and NSG name for your target database's private endpoint.
    • You can find your target database information in your target database's Console in Oracle Cloud Infrastructure.
    • A bare metal or vitual machine DB system has one private IP address.
    • An Exadata Cloud Service database can have multiple floating IP addresses for the database nodes. It can also have scan IP addresses for the database system. Oracle recommends that you use one of the scan IP addresses. You can find a scan IP address under Network on the DB System Information tab in Oracle Cloud Infrastructure. Alternatively, you can enter the private floating IP address of any one of the database nodes.
  2. Obtain the private IP address and NSG name for the Oracle Data Safe private endpoint.
    You can find the Oracle Data Safe private endpoint information on the Private Endpoint Information page in the Oracle Data Safe service in Oracle Cloud Infrastructure.
  3. Open the VCN for your target database.
  4. In your target database's NSG, create an ingress rule that allows your target database's private endpoint IP address (for example, 10.0.0.112/32) on the target database's port (for example, 1521) to receive incoming traffic from Oracle Data Safe's private endpoint IP address (for example, 10.0.0.79/32) from all ports.
  5. In your Oracle Data Safe private endpoint's NSG, create an egress rule that allows Oracle Data Safe's private endpoint IP address (for example, 10.0.0.79/32) on all ports to send requests to the target database's private endpoint IP address (for example, 10.0.0.112/32) on the target database's port (for example, port 1521).

    For an Exadata Cloud Database, create an egress rule for one of the scan IP addresses. Alternatively, you can use the private floating IP address of any one of the database nodes. The database port number is 1521.

Add Security Rules for an Oracle Database on Compute

If you plan to connect to your Oracle Database on Compute by using an Oracle Data Safe private endpoint, create an ingress rule and an egress rule on the target database's virtual cloud network (VCN) in Oracle Cloud Infrastructure. If the target database is in a non-Oracle cloud environment, configure the ingress rule in the non-Oracle Cloud environment.

  1. Obtain the IP address and the name of the NSG or security list for your target database's private endpoint. You can find your target database information in your target database's Console in Oracle Cloud Infrastructure.
  2. Obtain the IP address and the name of the NSG or security list for the Oracle Data Safe private endpoint. You can find the Oracle Data Safe private endpoint information on the Private Endpoint Information page in the Oracle Data Safe service in Oracle Cloud Infrastructure.
  3. Open the VCN for your target database, either in Oracle Cloud Infrastructure or in a non-Oracle cloud environment. In the target database's NSG or security list, create an ingress rule that allows your target database's private endpoint IP address (for example, 10.0.0.112/32) on the target database's port (for example, 1521) to receive incoming traffic from Oracle Data Safe's private endpoint IP address (for example, 10.0.0.79/32) from all ports.
  4. In Oracle Cloud Infrastructure, open the VCN for your Oracle Data Safe private endpoint. In the Oracle Data Safe private endpoint's NSG or security list, create an egress rule that allows Oracle Data Safe's private endpoint IP address (for example, 10.0.0.79/32) on all ports to send requests to the target database's private endpoint IP address (for example, 10.0.0.112/32) on the target database's port (for example, port 1521).

Add Security Rules for an Oracle On-Premises Database

For an Oracle On-Premises Database, you need to create an egress rule in the virtual cloud network (VCN) for your Oracle Data Safe private endpoint. You do not need to create an ingress rule.

  1. Obtain the private IP address of your target database. The IP address is where the listener is running. For example, suppose the Oracle database listener is running on 10.0.0.2.

    For a Real Application Cluster (RAC) database, you need to specify the IP addresses for the RAC database nodes and not the SCAN IP addresses. Whether you specify all the nodes in your RAC database depends on how you configured your pluggable databases (PDBs).

  2. Obtain the private IP address and the name of the NSG or security list for your Oracle Data Safe private endpoint.
    You can find the Oracle Data Safe private endpoint information on the Private Endpoint Information page in the Oracle Data Safe service in Oracle Cloud Infrastructure.
  3. Open the VCN for your Oracle Data Safe private endpoint. In your Oracle Data Safe private endpoint's NSG or security list, create an egress rule that allows Oracle Data Safe's private endpoint IP address (for example, 10.0.0.79/32) on all ports to send requests to the target database's private IP address (for example, 10.0.0.2/32) on the target database's port (for example, port 1521).
    Egress rule for an Oracle On-Premises Database