Guidelines for Securing User Accounts and Privileges

Oracle provides guidelines to secure user accounts and privileges.

1. 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 TABLEsystem 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 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.
6. 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.
7. 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.
   The SYS schema owns the data dictionary. You can protect the data dictionary by setting the O7_DICTIONARY_ACCESSIBILITY parameter to FALSE. See Guidelines for Securing Data for more information.
8. Only grant the EXECUTE privilege on the DBMS_RANDOM PL/SQL package to trusted users.
   The EXECUTE privilege on the DBMS_RANDOM package could permit users who normally should have only minimal access to execute the functions associated with this package.
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.

                                  https://docs.oracle.com/database/121/DBSEG/guidelines.htm#DBSEG499