7.6 Standards for Roles
In the spreadsheet shown earlier in this chapter, references to "ap_clerk," "hr_manager," and "hr_developer," among others, were used in the "Roles" area of the chart. The convention displayed there was the application name coupled with a task nomenclaturefor example, the Human Resources application (hr) coupled with the "clerk" tasks of entering or updating data within areas of the hr application. In this application, the ability to delete information was not a duty deemed appropriate for a clerk to perform. Only a manager can delete information.
The security plan team must decide on the naming conventions that will be used for role creations on a database-by-database and application-by-application basis. The composition of each role (who will be allowed to perform what actions) also needs to be identified, as well as the designation of who will create and assign roles for each application in each database.
7.6.1 Oracle-Supplied Roles
By default, until Oracle version 7.1.6, Oracle supplied three default roles within a database (CONNECT, RESOURCE, and DBA). From version 7.1.6 forward, Oracle supplies two additional roles (SYSDBA and SYSOPER). These are described in some detail in Chapter 5.
Because the composition of these roles has changed from version to version of the RDBMS, we recommend that DBAs define their own roles for user access. For example, in Oracle's version 6, the RESOURCE role was granted to users who were performing development tasks within a database because the RESOURCE role included the ability to create tables. In Oracle7, the ability to create tables appears in the CONNECT role. However, no tables or indexes can actually be created without a tablespace quota being granted to the user .
7.6.2 Granting Access to the Database
As we explained in Chapter 3, Oracle provides the ability to grant privileges directly either to specific users or to roles. The security team will need to decide whether privileges will ever be directly granted to a specific user or will be granted only through roles. If direct grants are allowed, you'll have to decide under what circumstances they will be used. During application development, for example, the developers will have access to the application schema and will have, through that account, many direct privileges.
Oracle provides the ability to grant privileges in the GRANT statement WITH GRANT OPTION, WITH ADMIN OPTION, or without any option. The security plan should designate whether these options will or will not be permitted within the databases being defined.