Information security, and privacy and protection of corporate assets and data are critical in any business.

Oracle Database comprehensively addresses the need for information security by providing cutting-edge security features such as deep data protection, auditing, scalable security, secure hosting, and data exchange.

Oracle Database leads the industry in security. To maximize the security features offered by Oracle Database in any business environment, it is imperative that the database itself be well protected.

Security guidelines provide advice about how to configure Oracle Database to be secure by adhering to and recommending industry-standard and advisable security practices for operational database deployments. Many of the guidelines described in this section address common regulatory requirements such as those described in the Sarbanes-Oxley Act. For more information about how Oracle Database addresses regulatory compliance, protection of personally identifiable information, and internal threats, visit:

http://www.oracle.com/technetwork/topics/security/whatsnew/index.html

You should always apply security patches as soon as they are available. If problems arise, then you should contact Oracle regarding vulnerabilities.

• Downloading Security Patches and Workaround Solutions
  Security patches apply to the operating system on which Oracle Database resides, Oracle Database itself, and all installed Oracle Database options and components.
• Contacting Oracle Security Regarding Vulnerabilities in Oracle Database
  You can contact Oracle Security regarding vulnerabilities in Oracle Database.

Oracle provides guidelines to secure user accounts and privileges.

1. Lock and expire default (predefined) user accounts.

   Oracle Database installs with several default database user accounts. Upon successful installation of the database, the Database Configuration Assistant automatically locks and expires most default database user accounts.

   If you perform a manual (without using Database Configuration Assistant) installation of Oracle Database, then no default database users are locked upon successful installation of the database server. Or, if you have upgraded from a previous release of Oracle Database, you may have default accounts from earlier releases. Left open in their default states, these user accounts can be exploited, to gain unauthorized access to data or disrupt database operations.

   You should lock and expire all default database user accounts. Oracle Database provides SQL statements to perform these operations. For example:

   ALTER USER ANONYMOUS PASSWORD EXPIRE ACCOUNT LOCK;
   

   Installing additional products and components after the initial installation also results in creating more default database accounts. Database Configuration Assistant automatically locks and expires all additionally created database user accounts. Unlock only those accounts that need to be accessed on a regular basis and assign a strong, meaningful password to each of these unlocked accounts. Oracle provides SQL and password management to perform these operations.

   If any default database user account other than the ones left open is required for any reason, then a database administrator (DBA) must unlock and activate that account with a new, secure password.

   If a default database user account, other than the ones left open, is required for any reason, then a database administrator (DBA) can unlock and activate that account with a new, secure password.

   Securing Oracle Enterprise Manager Accounts

   If you install Oracle Enterprise Manager, the SYSMAN and DBSNMP accounts are open, unless you configure Oracle Enterprise Manager for central administration. In this case, the SYSMAN account (if present) will be locked.

   If you do not install Oracle Enterprise Manager, then only the SYS and SYSTEM accounts are open. Database Configuration Assistant locks and expires all other accounts (including SYSMAN and DBSNMP).

2. Discourage users from using the NOLOGGING clause in SQL statements.

   In some SQL statements, the user has the option of specifying the NOLOGGING clause, which indicates that the database operation is not logged in the online redo log file. Even though the user specifies the clause, a redo record is still written to the online redo log file. However, there is no data associated with this record. Because of this, using NOLOGGING has the potential for malicious code to be entered can be accomplished without an audit trail.

3. Practice the principle of least privilege.

   Oracle recommends the following guidelines:

   1. Grant necessary privileges only.

      Do not provide database users or roles more privileges than are necessary. (If possible, grant privileges to roles, not users.) In other words, the principle of least privilege is that users be given only those privileges that are actually required to efficiently perform their jobs.

      To implement this principle, restrict the following as much as possible:

      • The number of SYSTEM and OBJECT privileges granted to database users.

      • The number of people who are allowed to make SYS-privileged connections to the database.

      • The number of users who are granted the ANY privileges, such as the DROP ANY TABLE privilege. For example, there is generally no need to grant CREATE ANY TABLE privileges to a non-DBA-privileged user.

      • The number of users who are allowed to perform actions that create, modify, or drop database objects, such as the TRUNCATE TABLE, DELETE TABLE, DROP TABLE statements, and so on.

   2. Limit granting the CREATE ANY EDITION and DROP ANY EDITION privileges.

      To maintain additional versions of objects, editions can increase resource and disk space consumption in the database. Only grant the CREATE ANY EDITION and DROP ANY EDITION privileges to trusted users who are responsible for performing upgrades.

   3. Re-evaluate the SELECT object privilege and SELECT ANY TABLE system privileges that you have granted to users.

      If you want to restrict users to only being able to query tables, views, materialized views, and synonyms, then grant users the READ object privilege, or for trusted users only, the READ ANY TABLE system privilege. If in addition to performing query operations, you want users to be able to lock tables in exclusive mode or perform SELECT ... FOR UPDATE statements, then grant the user the SELECT object privilege or, for trusted users only, the SELECT ANY TABLE system privilege.

   4. Restrict the CREATE ANY JOB, BECOME USER, EXP_FULL_DATABASE, and IMP_FULL_DATABASE privileges. Also restrict grants of the CREATE DIRECTORY and CREATE ANY DIRECTORY privileges.

      These are powerful security-related privileges. Only grant these privileges to users who need them.

   5. Restrict the BECOME USER privilege to users of Oracle Data Pump, and the DBMS_WORKLOAD_CAPTURE and DBMS_WORKLOAD_REPLAY packages.

      The BECOME USER privilege is used only for the following subsystems:

      • Oracle Data Pump Import utilities impdp and imp, to assume the identity of another user to perform operations that cannot be directly performed by a third party (for example, loading objects such as object privilege grants). In an Oracle Database Vault environment, Database Vault provides several levels of required authorization that affect grants of BECOME USER.

      • DBMS_WORKLOAD_CAPTURE and DBMS_WORKLOAD_REPLAY PL/SQL packages, as a required privilege to be granted to users who must use these packages.

      If you use the AUTHID CURRENT_USER clause when invoking one of these subsystems (for example, in static references in PL/SQL code), then ensure that the CURRENT_USER is granted the BECOME USER privilege, either by a direct grant or through a role.

   6. Restrict library-related privileges to trusted users only.

      The CREATE LIBRARY, CREATE ANY LIBRARY, ALTER ANY LIBRARY, and EXECUTE ANY LIBRARY privileges, and grants of EXECUTE ON library_name convey a great deal of power to users. If you plan to create PL/SQL interfaces to libraries, only grant the EXECUTE privilege to the PL/SQL interface. Do not grant EXECUTE on the underlying library. You must have the EXECUTE privilege on a library to create the PL/SQL interface to it. However, users have this privilege implicitly on libraries that they create in their own schemas. Explicit grants of EXECUTE ON library_name are rarely required. Only make an explicit grant of these privileges to trusted users, and never to the PUBLIC role.

   7. Restrict synonym-related privileges to trusted users only.

      The CREATE PUBLIC SYNONYM and DROP PUBLIC SYNONYM system privileges convey a great deal of power to these users. Do not grant these privileges to users, unless they are trusted.

   8. Do not allow non-administrative users access to objects owned by the SYS schema.

      Do not allow users to alter table rows or schema objects in the SYS schema, because doing so can compromise data integrity. Limit the use of statements such as DROP TABLE, TRUNCATE TABLE, DELETE, INSERT, or similar object-modification statements on SYS objects only to highly privileged administrative users.

   9. Restrict permissions on run-time facilities.

      Many Oracle Database products use run-time facilities, such as Oracle Java Virtual Machine (OJVM). Do not assign all permissions to a database run-time facility. Instead, grant specific permissions to the explicit document the root file paths for facilities that might run files and packages outside the database.

      Here is an example of a vulnerable run-time call, which individual files are specified:

      call dbms_java.grant_permission('wsmith', 'SYS:java.io.FilePermission','<<ALL FILES>>','read');
      

      Here is an example of a better (more secure) run-time call, which specifies a directory path instead:

      call dbms_java.grant_permission('wsmith', 'SYS:java.io.FilePermission','<<actual directory path>>','read');
      

4. Revoke access to the following:

   • The SYS.USER_HISTORY$ table from all users except SYS and DBA accounts

   • The RESOURCE role from typical application accounts

   • The CONNECT role from typical application accounts

   • The DBA role from users who do not need this role

5. Grant privileges only to roles.

   Granting privileges to roles and not individual users makes the management and tracking of privileges much easier.

6. Limit the proxy account (for proxy authorization) privileges to CREATE SESSION only.

7. Use secure application roles to protect roles that are enabled by application code.

   Secure application roles allow you to define a set of conditions, within a PL/SQL package, that determine whether or not a user can log on to an application. Users do not need to use a password with secure application roles.

   Another approach to protecting roles from being enabled or disabled in an application is the use of role passwords. This approach prevents a user from directly accessing the database in SQL (rather than the application) to enable the privileges associated with the role. However, Oracle recommends that you use secure application roles instead, to avoid having to manage another set of passwords.

8. Create privilege captures to find excessively granted privileges. Privilege analysis captures the privileges that users and applications use, and then presents these in a format for easy analysis. From there, you can revoke unnecessary privileges if you want.

9. Monitor the granting of the following privileges only to users and roles who need these privileges.

   By default, Oracle Database audits the following privileges:

   • ALTER SYSTEM

   • AUDIT SYSTEM

   • CREATE EXTERNAL JOB

   Oracle recommends that you also audit the following privileges:

   • ALL PRIVILEGES (which includes privileges such as BECOME USER, CREATE LIBRARY, and CREATE PROCEDURE)

   • DBMS_BACKUP_RESTORE package

   • EXECUTE to DBMS_SYS_SQL

   • SELECT ANY TABLE

   • SELECT on PERFSTAT.STATS$SQLTEXT

   • SELECT on PERFSTAT.STATS$SQL_SUMMARY

   • SELECT on SYS.SOURCE$

   • Privileges that have the WITH ADMIN clause

   • Privileges that have the WITH GRANT clause

   • Privileges that have the CREATE keyword

10. Use the following data dictionary views to find information about user access to the database.

    • DBA_*

    • DBA_ROLES

    • DBA_SYS_PRIVS

    • DBA_ROLE_PRIVS

    • DBA_TAB_PRIVS

    • DBA_AUDIT_TRAIL (if standard auditing is enabled)

    • DBA_FGA_AUDIT_TRAIL (if fine-grained auditing is enabled)

Oracle provides guidelines for securing passwords in a variety of situations.

When you create a user account, Oracle Database assigns a default password policy for that user. The password policy defines rules for how the password should be created, such as a minimum number of characters, when it expires, and so on. You can strengthen passwords by using password policies.

Follow these guidelines to further strengthen passwords:

1. Choose passwords carefully.

   In addition to the minimum requirements for creating passwords, follow these additional guidelines when you create or change passwords:

   • Make the password have a length of between 12 and 30 bytes, and include both alphabetic characters and digits in the password.

   • Have the password contain at least one digit, one upper-case character, and one lower-case character.

   • Use mixed case characters and special characters in the password.

   • You can include multibyte characters in the password but not in the password of any common user or role.

   • Use the database character set for the password's characters, which can include the underscore (_), dollar ($), and number sign (#) characters.

   • You must enclose the following passwords in double-quotation marks:

     • Passwords containing multibyte characters.

     • Passwords starting with numbers or special characters and containing alphabetic characters (a–z, A–Z). For example:

       "123abc"

       "#abc"

       "123dc$"

     • Passwords containing any character other than alphabetic characters, numbers, and special characters. For example:

       "abc>"

       "abc@",

       " "

   • You do not need to specify the following passwords in double-quotation marks.

     • Passwords starting with an alphabetic character (a–z, A–Z) and containing numbers (0–9) or special characters ($, #, _). For example:

       abc123

       ab23a

       ab$#_

     • Passwords containing only numbers

     • Passwords containing only alphabetic characters (a–z, A–Z)

   • Do not include double-quotation marks within the password.

   • Do not use an actual word for the entire password.

2. To create a longer, more complex password from a shorter, easier to remember password, create the password from the first letters of the words of an easy-to-remember sentence.

   For example, "I usually work until 6:00 almost every day of the week" can be Iuwu6aedotw.

3. Ensure that the password is sufficiently complex.

   Oracle Database provides a password complexity verification routine, the PL/SQL script utlpwdmg.sql, that you can run to check whether or not passwords are sufficiently complex. Ideally, edit the utlpwdmg.sql script to provide stronger password protections.

4. Remember that multibyte characters are not allowed in passwords for common users or roles.

   For users who are local to a PDB, if you want to use multibyte characters in the password, then ensure that the database character set is configured as a multibyte character set so that the authentication will work properly.

   Be aware that because multibyte characters consume more bytes than single-byte characters, they tend to provide less entropy per byte. Because the maximum length of the password is currently limited to 30 bytes, to help increase the amount of entropy in a password, Oracle recommends that you also include a number of single-byte characters in the password, even when multibyte characters are being used.

5. Associate a password complexity function with the user profile or the default profile.

   The PASSWORD_VERIFY_FUNCTION clause of the CREATE PROFILE and ALTER PROFILE statements associates a password complexity function with a user profile or the default profile. Password complexity functions ensure that users create strong passwords using guidelines that are specific to your site. Having a password complexity function also requires a user changing his or her own password (without the ALTER USER system privilege) to provide both the old and new passwords. You can create your own password complexity functions or use the password complexity functions that Oracle Database provides.

6. Change default user passwords.

   Oracle Database installs with a set of predefined, default user accounts. Security is most easily broken when a default database user account still has a default password even after installation. This is particularly true for the user account SCOTT, which is a well known account that may be vulnerable to intruders. In Oracle Database, default accounts are installed locked with the passwords expired, but if you have upgraded from a previous release, you may still have accounts that use default passwords.

   To find user accounts that have default passwords, query the DBA_USERS_WITH_DEFPWD data dictionary view.

7. Change default passwords of administrative users.

   You can use the same or different passwords for the SYS, SYSTEM, SYSMAN, and DBSNMP administrative accounts. Oracle recommends that you use different passwords for each. In any Oracle environment (production or test), assign strong, secure, and distinct passwords to these administrative accounts. If you use Database Configuration Assistant to create a new database, then it requires you to enter passwords for the SYS and SYSTEM accounts, disallowing the default passwords CHANGE_ON_INSTALL and MANAGER.

   Similarly, for production environments, do not use default passwords for administrative accounts, including SYSMAN and DBSNMP.

8. Enforce password management.

   Apply basic password management rules (such as password length, history, complexity, and so forth) to all user passwords. Oracle Database has password policies enabled for the default profile. Guideline 1 in this section lists these password policies.

   You can find information about user accounts by querying the DBA_USERS view. The PASSWORD column of the DBA_USERS view indicates whether the password is global, external, or null. The DBA_USERS view provides useful information such as the user account status, whether the account is locked, and password versions.

   Oracle also recommends, if possible, using Oracle strong authentication with network authentication services (such as Kerberos), token cards, smart cards, or X.509 certificates. These services provide strong authentication of users, and provide protection against unauthorized access to Oracle Database.

9. Do not store user passwords in clear text in Oracle tables.

   For better security, do not store passwords in clear text (that is, human readable) in Oracle tables. You can correct this problem by using a secure external password store to encrypt the password within an Oracle wallet. (An Oracle wallet is a secure software container that stores authentication and signing credentials.)

   When you create or modify a password for a user account, Oracle Database automatically creates a cryptographic hash or digest of the password. If you query the DBA_USERS view to find information about a user account, the data in the PASSWORD column indicates if the user password is global, external, or null. The DBA_USERS view also has a column called PASSWORD_VERSIONS, which lists the types of cryptographic hash that exist for the user's password (11G or 12C).

10. Disable the HTTP verifier if the user is not going to be using either XDB authentication or HTTP Digest authentication.

    The HTTP verifier is used only for XDB authentication and HTTP Digest authentication. If a user is not going to use XDB authentication or HTTP Digest authentication, then you can safely remove the HTTP verifier from the user's list of verifiers. To remove a user's HTTP verifier, execute the following statement:

    ALTER USER username DIGEST DISABLE;

Oracle provides guidelines for role management.

1. Grant a role to users only if they need all privileges of the role.

   Roles (groups of privileges) are useful for quickly and easily granting permissions to users. Although you can use Oracle-defined roles, you have more control and continuity if you create your own roles containing only the privileges pertaining to your requirements. Oracle may change or remove the privileges in an Oracle Database-defined role, as it has with the CONNECT role, which now has only the CREATE SESSION privilege. Formerly, this role had eight other privileges.

   Ensure that the roles you define contain only the privileges that reflect job responsibility. If your application users do not need all the privileges encompassed by an existing role, then apply a different set of roles that supply just the correct privileges. Alternatively, create and assign a more restricted role.

   For example, it is imperative to strictly limit the privileges of user SCOTT, because this is a well known account that may be vulnerable to intruders. Because the CREATE DBLINK privilege allows access from one database to another, drop its privilege for SCOTT. Then, drop the entire role for the user, because privileges acquired by means of a role cannot be dropped individually. Re-create your own role with only the privileges needed, and grant that new role to that user. Similarly, for better security, drop the CREATE DBLINK privilege from all users who do not require it.

2. Do not grant user roles to application developers.

   Roles are not meant to be used by application developers, because the privileges to access schema objects within stored programmatic constructs need to be granted directly. Remember that roles are not enabled within stored procedures except for invoker's right procedures.

3. Create and assign roles specific to each Oracle Database installation.

   This principle enables the organization to retain detailed control of its roles and privileges. This also avoids the necessity to adjust if Oracle Database changes or removes Oracle Database-defined roles, as it has with CONNECT, which now has only the CREATE SESSION privilege. Formerly, it also had eight other privileges.

4. For enterprise users, create global roles.

   Global roles are managed by an enterprise directory service, such as Oracle Internet Directory.

Oracle provides guidelines for securing data on your system.

1. Restrict operating system access.

   Follow these guidelines:

   • Limit the number of operating system users.

   • Limit the privileges of the operating system accounts (administrative, root-privileged, or database administrative) on the Oracle Database host computer to the least privileges required for a user to perform necessary tasks.

   • Restrict the ability to modify the default file and directory permissions for the Oracle Database home (installation) directory or its contents. Even privileged operating system users and the Oracle owner should not modify these permissions, unless instructed otherwise by Oracle.

   • Restrict symbolic links. Ensure that when you provide a path or file to the database, neither the file nor any part of the path is modifiable by an untrusted user. The file and all components of the path should be owned by the database administrator or trusted account, such as root.

     This recommendation applies to all types of log files, trace files, external tables, BFILE data types, and so on.

2. Encrypt sensitive data and all backup media that contains database files.

   According to common regulatory compliance requirements, you must encrypt sensitive data such as credit card numbers and passwords. When you delete sensitive data from the database, encrypted data does not linger in data blocks, operating system files, or sectors on disk.

   In most cases, you may want to use Transparent Data Encryption to encrypt your sensitive data.

3. For Oracle Automatic Storage Management (Oracle ASM) environments on Linux and UNIX systems, use Oracle ASM File Access Control to restrict access to the Oracle ASM disk groups.

   If you use different operating system users and groups for Oracle Database installations, then you can configure Oracle ASM File Access Control to restrict the access to files in Oracle ASM disk groups to only authorized users. For example, a database administrator would only be able to access the data files for the databases he or she manages. This administrator would not be able to see or overwrite the data files belonging (or used by) other databases.

   For more information about managing Oracle ASM File Access Control for disk groups and the various privileges that are required for multiple software owners, see Oracle Automatic Storage Management Administrator's Guide.

Oracle provides guidelines to secure the ORACLE_LOADER access driver.

1. Create a separate operating system directory to store the access driver preprocessors. You (or the operating system manager) may need to create multiple directories if different Oracle Database users will run different preprocessors. If you want to prevent one set of users from using one preprocessor while allowing those users access to another preprocessor, then place the preprocessors in separate directories. If all the users need equal access, then you can place the preprocessors together in one directory. After you create these operating system directories, in SQL*Plus, you can create a directory object for each directory.

2. Grant the operating system user ORACLE the correct operating system privileges to run the access driver preprocessor. In addition, protect the preprocessor program from WRITE access by operating system users other than the user responsible for managing the preprocessor program.

3. Grant the EXECUTE privilege to each user who will run the preprocessor program in the directory object. Do not grant this user the WRITE privilege on the directory object. Never grant users both the EXECUTE and WRITE privilege for directory objects.

4. Grant the WRITE privilege sparingly to anyone who will manage directory objects that contain preprocessors. This prevents database users from accidentally or maliciously overwriting the preprocessor program.

5. Create a separate operating system directory and directory object for any data files that are required for external tables. Ensure that these are separate from the directory and directory object used by the access directory preprocessor.

   Work with the operating system manager to ensure that only the appropriate operating system users have access to this directory. Grant the ORACLE operating system user READ access to any directory that has a directory object with READ privileges granted to database users. Similarly, grant the ORACLE operating system user WRITE access to any directory that has the WRITE privilege granted to database users.

6. Create a separate operating system directory and directory object for any files that the access driver generates. This includes log files, bad files, and discarded files. You and the operating system manager must ensure that this directory and directory object have the proper protections, similar to those described in Guideline 5. The database user may need to access these files when resolving problems in data files, so you and the operating system manager must determine a way for this user to read those files.

7. Grant the CREATE ANY DIRECTORY and DROP ANY DIRECTORY privileges sparingly. Users who have these privileges and users who have been granted the DBA role have full access to all directory objects.

8. Consider auditing the DROP ANY DIRECTORY privilege. You can create a unified audit policy to audit privileges.

9. Consider auditing the directory object. You can create a unified audit policy to audit objects.

Oracle provides guidelines to secure the database installation and configuration.

Changes were made to the default configuration of Oracle Database to make it more secure. The recommendations in this section augment the new, secure default configuration.

1. Before you begin an Oracle Database installation on UNIX systems, ensure that the umask value is 022 for the Oracle owner account.

   See Oracle Database Administrator's Reference for Linux and UNIX-Based Operating Systems for more information about managing Oracle Database on Linux and UNIX systems.

2. Install only what is required.

   Options and Products: The Oracle Database CD pack contains products and options in addition to the database. Install additional products and options only as necessary. Use the Custom Installation feature to avoid installing unnecessary products, or perform a typical installation, and then deinstall options and products that are not required. There is no need to maintain additional products and options if they are not being used. They can always be properly installed, as required.

   Sample Schemas: Oracle Database provides sample schemas to provide a common platform for examples. If your database will be used in a production environment, then do not install the sample schema. If you have installed the sample schema on a test database, then before going to production, remove or relock the sample schema accounts.

3. During installation, when you are prompted for a password, create a secure password.

   Choose the password carefully, ensure that you change the default passwords, and change the default passwords of administrative users.

4. Immediately after installation, lock and expire default user accounts.

   For better security, you should lock and expire all default (predefined) user accounts.

Security for network communications is improved by using client, listener, and network guidelines to ensure thorough protection.

• Client Connection Security
  Authenticating clients stringently, configuring encryption for the connection, and using strong authentication strengthens client connections.
• Network Connection Security
  Protecting the network and its traffic from inappropriate access or modification is the essence of network security.
• Secure Sockets Layer Connection Security
  Oracle provides guidelines for securing Secure Sockets Layer (SSL).

The ENFORCE_CREDENTIAL environment variable controls how an extproc process authenticates user credentials and callout functions.

You can specify this variable in the extproc.ora file. Before modifying this variable, review your site's security requirements for the handling of external libraries. For maximum security, set the ENFORCE_CREDENTIAL variable to TRUE. The default setting is FALSE.

Oracle provides guidelines for auditing.

• Manageability of Audited Information
  Although auditing is relatively inexpensive, limit the number of audited events as much as possible.
• Audits of Typical Database Activity
  Oracle provides guidelines for when you must gather historical information about particular database activities.
• Audits of Suspicious Database Activity
  Oracle provides guidelines for when you audit to monitor suspicious database activity.
• Audits of Sensitive Data
  Oracle recommends that you include the ACTIONS ALL clause when you create unified audit policies on sensitive objects.
• Recommended Audit Settings
  Oracle provides predefined policies that contain recommended audit settings that apply to most sites.
• Best Practices for Querying the UNIFIED_AUDIT_TRAIL Data Dictionary View
  To get the best results from querying the UNIFIED_AUDIT_TRAIL data dictionary view, you should follow these guidelines.

The CONNECT role, introduced with Oracle Database version 7, added new and robust support for database roles.

• Why Was the CONNECT Role Changed?
  The CONNECT role is used in sample code, applications, documentation, and technical papers.
• How the CONNNECT Role Change Affects Applications
  The CONNECT role changes can be seen in database upgrades, account provisioning, and installation of applications using new databases.
• How the CONNECT Role Change Affects Users
  The change to the CONNECT role affects general users, application developers, and client/server applications differently.
• Approaches to Addressing the CONNECT Role Change
  Oracle recommends three approaches to address the impact of the CONNECT role change.