Oracle Unleashed- P9

CREATE USER CREATE VIEW DROP PROFILE DROP PUBLIC DATABASE LINK DROP PUBLIC SYNONYM DROP ROLLBACK SEGMENT... ALTER ANY INDEX ALTER ANY PROCEDURE ALTER ANY ROLE ALTER ANY SEQUENCE ALTER AN

SQL> select count(*) from rhett.bonnie;

Error at line 1:

ORA-00942: table or view does not exist

RHETT owns the table BONNIE, and he has granted SCARLETT access to the table If BONNIE is dropped by RHETT and recreated with the same object name, SCARLETT no longer has access to the table This is true until RHETT makes the grant again If there were multiple grants, each grant must be made for each user on each database object This can be quite cumbersome

The WITH GRANT OPTION Option

In many environments, it is beneficial to have users other than the DBA perform grants For example, the DBA might want to allow a project leader to grant rights on database objects to people working on his project Thus, the DBA has to

do the grants only once; then it falls to the project leader to make further grants as necessary

Oracle provides a mechanism for doing this: GRANT OPTION of the grant SQL command With it, a user can issue grant commands just as though he were the actual owner of the database object For example,

SCARLETT owns a view of another database view called GEORGIA This view is based on a table owned by another user, RHETT, and is called CHARLESTON SCARLETT must have WITH GRANT OPTION on GEORGIA If this is not done, grants of this view to other users will not work properly

Resolving Object Synonyms

A synonym is simply a designation for a database object that enables it to be referenced by another name There are two

types of these synonyms: private and public A private synonym is a synonym created by the user that only he uses; no one other than the user who created the synonym can use it A public synonym is accessible to all users in the database

Suppose, for example, that a user, TAL, has a table named HOCKEY for which two synonyms exist"ICE, a private synonym, and SPORT, a public synonym This gives five distinct methods for accessing this particular table:

This example assumes that the appropriate grants have been made on the HOCKEY table to permit access In dealing with synonyms, it is important to understand the order in which the database resolves naming This is important when you test programs for which there is a global table and a local table Consider the following SQL statement:

select * from emp;

When it attempts to resolve this statement, the database first checks whether a database object "such as a table, view, or database link"exists and is owned by the current database user If it finds a match, it stops If a match does not exist, it checks for a private synonym that will direct it to a specific database object If no private synonym exists, it checks for a public synonym that will point it toward an existing database object If no resolution is found, if the database objects referenced by the synonyms do not exist, or if the user has no privileges on the object in question, an error condition occurs

System Security

Whereas object privilege deals with what a user can do to database objects, system privilege deals with what actions a user can perform against the database itself The actions include connecting to the database, creating database tables, and dropping an entire tablespace (with all the database objects in it) The functionality of Oracle7 makes the system

privileges far more scaleable than in Oracle6

Under Oracle6, the Oracle RDBMS resembled UNIX in its overall security scheme UNIX maintains that an account is either the root user or a regular user Admittedly, UNIX has evolved to enable a greater deal of scalability by using things such as access control lists (ACLs) and root set userid (suid) programs Oracle6 is set up so that all users are either the DBA or not the DBA With the release of Oracle7, Oracle moves away from this methodology It is possible now to grant specific privileges to non-DBA users, thereby enabling them to perform certain applications without giving them full DBA access

Defined System Privileges

In Oracle6, three system privileges are available Over 80 system privileges are available in Oracle7 The following is a

partial list of the database system privileges The information comes from the Oracle7 Server Administrator's Guide, an

excellent reference that describes the capabilities of each privilege

ALTER DATABASE

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ALTER PROFILE

ALTER RESOURCE COST

ALTER ROLLBACK SEGMENT

CREATE PUBLIC DATABASE LINK

CREATE PUBLIC SYNONYM

CREATE USER

CREATE VIEW

DROP PROFILE

DROP PUBLIC DATABASE LINK

DROP PUBLIC SYNONYM

DROP ROLLBACK SEGMENT

The WITH ADMIN OPTION Option

WITH ADMIN OPTION is to database system privileges what WITH GRANT OPTION is to database object privileges

By making a grant WITH ADMIN OPTION, the DBA enables a user to grant the system privilege to another user For example,

Oracle7 Server Administrator's Guide

ALTER ANY CLUSTER

ALTER ANY INDEX

ALTER ANY PROCEDURE

ALTER ANY ROLE

ALTER ANY SEQUENCE

ALTER ANY SNAPSHOT

ALTER ANY TABLE

ALTER ANY TRIGGER

BACKUP ANY TABLE

COMMENT ANY TABLE

CREATE ANY CLUSTER

CREATE ANY INDEX

CREATE ANY PROCEDURE

CREATE ANY SEQUENCE

CREATE ANY SNAPSHOT

CREATE ANY SYNONYM

CREATE ANY TABLE

CREATE ANY TRIGGER

CREATE ANY VIEW

DELETE ANY TABLE

DROP ANY CLUSTER

DROP ANY INDEX

DROP ANY PROCEDURE

DROP ANY ROLE

DROP ANY SEQUENCE

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

DROP ANY SNAPSHOT

DROP ANY SYNONYM

DROP ANY TABLE

DROP ANY TRIGGER

DROP ANY VIEW

EXECUTE ANY PROCEDURE

FORCE ANY TRANSACTION

GRANT ANY PRIVILEGE

GRANT ANY ROLE

INSERT ANY TABLE

LOCK ANY TABLE

SELECT ANY SEQUENCE

SELECT ANY TABLE

UPDATE ANY TABLE

The DBA should be careful when granting system privileges, especially the ANY class of privileges Some of them are not meant for public use They put too much power in the hands of users if they are not adequately managed Although the privileges are more scaleable than under previous Oracle versions, the DBA should treat them as mini-DBA

privileges when determining who should receive them

A final issue regarding protecting system privileges is what effect these privileges have within a secure database In most databases, some tables contain information that should not be distributed to the general public, such as payroll

information A user with the some of the ANY privileges, such as SELECT ANY or UPDATE ANY, has access to the tables even without an explicit grant

Grant succeeded.

The DBA can use the PUBLIC account to set up a common set of grants "such as the CREATE SESSION privilege, which permits connection to the database" and grant them to PUBLIC In doing this, the DBA removes the need to make explicit grants to every user when a new account is added

The DBA can use PUBLIC to lock groups of users out of the database without having to restart the instance in RESTRICT mode For example, he can grant CREATE SESSION to PUBLIC and make explicit CREATE SESSION grants to key users, such as IS personnel In the event that activity needs to be done on the database, the following command can be executed from SQL*Plus or Oracle Server*Manager:

revoke create session from public;

This command effectively locks out everyone except the IS users after all the users have logged off the database The grants can be reinstated as follows:

grant create session to public;

Object Security Model

The DBA must consider other factors when setting up a security plan Not only should the setup of the database users be considered, but also the ownership of the database objects Although there is no right or wrong way to go about this, the following sections outline some of the concerns faced by the DBA when setting up object ownership models

Protected Object Ownership Schema

One security model implemented by many sites is the protected schema "sometimes called the pure schema Under this

model, the DBA sets up an account that is not associated with any specific database user This account is used as an ownership account for all the database objects"tables, views, and so on Public synonyms are set up for each database object, and grants are made to each user for each database object Therefore, a single user owns the objects, but the account can be restricted by not issuing passwords to any users except those who perform database object maintenance

There is nothing incredibly mystical about this setup The object owner exists as just another account within the

database Depending on the environment, the DBA can configure the database to have only connection or resource privileges during maintenance windows and then revoke those privileges when completed Thus, access to the object owner account can be given to other users "who might, for example, want to look at the contents of the CAT or

USER_TABLES table" without enabling them to make changes to the database objects themselves

One important note here is that the DBA or person responsible for database object maintenance should maintain a build script for the object Although this information can be obtained from the Oracle Data Dictionary, it is important to have this information accessible in emergency situations

Capacity Planning Requirements

In dealing with database objects, one of the key elements for which the DBA is responsible is the capacity planning requirements of the database Many sites hold to the philosophy that the creation and maintenance of the database objects responsibilities separate from overall database maintenance; most of these sites still agree that capacity planning

is a responsibility of the DBA Everything in the database is stored physically in database files

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Volumes have been written concerning the best ways to optimize the capacity planning of database objects within tablespaces The main concern of capacity planning in this chapter is on security Because users other than the DBA might be involved in creating database objects, he should stay abreast of modifications as they occur For example, it takes only a typographical error in the STORAGE clause to inadvertently fill up a tablespace "1,000K and 10,000K are different by just one zero When no further space is available to expand the tablespace, this can bring production

databases to a screeching halt By the same token, if the next extent sizes are set wrong forgetting the K in 512K makes

it 512 bytes " a database object can quickly reach its MAXEXTENTS When this happens, the only option is to rebuild the object with proper extent sizes Depending on how much data is stored, this might be no small feat

The bottom line on capacity planning requirements from a database security standpoint is to be certain that

accountability exists Object creations should generally be limited to developers or analysts who have the technical knowledge to understand what object creation entails It should not be necessary to hold anyone's hand Likewise, they should not be given a blank check

Avoiding Tablespace Fragmentation Issues

Given the prevalence of tools like Defrag by ARIS and TSReorg by Platinum Technology, tablespace fragmentation is

an obvious problem for most DBAs Tablespace fragmentation, illustrated in Figure 16.1, occurs when free space is available in a tablespace, but when the blocks of free space are not group in contiguous blocks That is, they are not together Although the amount of fragmentation in Oracle7 is much better than in Oracle6, it remains a persistent problem

Figure 16.1 Tablespace fragmentation.

Many DBAs might wonder what tablespace fragmentation has to do with database security The answer is simple: Steps that can be built into the security plan of the database that help minimize some of the main causes of database

fragmentation

Suppose, for example, that a developer calls and complains that he cannot create a new table in tablespace XYZ

Whenever he tries to issue the CREATE TABLE command from SQL, he receives this error message:

cannot allocate extent of size 99 in tablespace XYZ

A quick check of the view DBA_FREE_SPACE shows the amount of free space available in the tablespace, so it is possible to calculate the total amount of free space capable of holding the table The first question that the DBA should pose to the developer is, ÒHow often are you dropping tables and indexes?Ó This is the most common cause of

tablespace fragmentation, especially for tablespaces to which developers have access As a rule, developers perform CREATE TABLE/INDEX and DROP TABLE/INDEX operations on a regular basis, which inevitably leads to

problems

It is a good idea to limit or eliminate access to the tablespaces on which production objects reside You can do this by using tablespace quotas and by not giving anyone other than the protected schema access to the tablespaces Generally, a special work tablespace called WORK or MISC is created Developers can perform adds and drops on it If this

tablespace fragments, it can be defragmented at the DBA's discretion If many people have access to the schema

ownership account, it is often a good idea to revoke quotas on the tablespace from the schema until such a time as needed This depends largely on the user community that is using the account

By limiting the amount of access to production tablespaces, the DBA can help reduce "although not eliminate"

tablespace fragmentation This helps eliminate the amount of crisis mode management that a DBA must undertake

Defining Database Roles

In versions of Oracle prior to Oracle7, explicit grants from the system and the object privilege level are the rule At first, this was not much of a hindrance because of the size of most databases Large databases were the exception; small databases were the rule As databases grew in size, many DBAs began to see how cumbersome and difficult that method

of access grants was For example, in a database system with 40 database tables and views and 100 database users, over 4,000 separate grants must be processed This is a relatively small database, so it is easy to see the cumulative effects of adding users and objects on larger databases systems Likewise, if a change in privilege needs to be made or a table is recreated, all the privileges must be made again

Most DBAs found avenues around this problem by creating SQL scripts or by writing programs that handle the

cumbersome grant process Oracle responded to this problem by providing its user community with database roles

At the simplest level, roles are simply groups of system or object privileges that can be assigned to database users Grants on the desired privileges, such as CREATE SESSION or SELECT ON SCOTT.EMP, are made to a role This role is then granted to a user The database user has all the privileges that have been assigned to the role There is no limit to the number of people who can have the role assigned to them, and changes are replicated to all the database users

by making a change in the grants to the role

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Although it is possible to grant roles to other roles "which is called nesting" there is a limit to the number of

active roles that can be in effect for a single user at any one time This is determined by the value of the INIT.ORA parameter MAX_ENABLED_ROLES The database does not permit more than the limit set by this value to be enabled

Deleting Roles

The DBA can delete a role from the database This operation removes information pertaining to the role from all the users and roles currently in existence As with revoking a system privilege, deleting a role does not affect existing database objects For example,

Setting and Changing the Default Role

Whenever a role is granted to a user, the privileges within the role do not take effect until the role has been set as the

default role The default role tells the database that it is the role whose privileges are currently being used The default

role determines which database role the user uses when he first connects to the database For example,

The DBA should carefully evaluate the ramifications of setting all the roles as default roles before he institutes this option

Password Protecting Roles

At some sites, users are grouped into different privilege levels that require a decision before they perform a certain task Take, for example, a user in an OLTP system who has three roles "ORD_ENTRY, MANAGER, and SUPERUSER Each level might have different levels of privileges MANAGER might have SELECT, INSERT, UPDATE, and

DELETE capabilities on key tables that are not accessible to ORD_ENTR MANAGER might lack certain system privileges that belong to SUPERUSER Whatever the case, the DBA might require a password for each level

This password helps protect the privilege levels by keeping others out of the role, and it also forces the user to know what role he is currently using In theory, he would remember which password he most recently entered Likewise, the password enables the DBA to keep users out of certain privilege groups by changing the password associated with the role

Switching between roles is the same as switching between roles that have no passwords The sole difference is that a correct password must be given before Oracle will accept the role change For example,

Defining Roles at Operating System Level

It is possible to grant roles dynamically at the operating system level For this to take place, a few additional steps must

be performed when the roles are created The benefit is that roles are always identified at the operating system level "in /etc/groups in UNIX, for example They can easily be changed by someone who has privilege to make modifications" usually the system administrator

Using operating system authenticated roles should be considered only at sites where the DBA can make changes

to the appropriate file If the DBA lacks this authority, the entire process entails too much overhead to be useful Grants should be performed at the database level instead

One of the first steps in creating an operating system authenticated role is to make certain that the parameter OS_ROLES

in the INIT.ORA parameter file is set to TRUE This parameter enables the DBA to enable or disable the use of

operating system authenticated roles

To prevent possible breaches of security, a default role cannot be authenticated at the operating system level Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

when Oracle's Multi-Thread Server is running If breaches of security are not a concern, you can enable them for thread sites by setting the value of REMOTE_OS_ROLES to TRUE Consider this carefully

multi-Operating system authenticated roles, like operating system authenticated accounts, must be created at the database level

As with user accounts, this is done by identifying them EXTERNALLY For example,

OPTION on the role)

In the following example, a role named manager is set up in the norm instance:

ora_norm_manager_ad:*:512:larry,daryl,o_daryl

The users larry, daryl, and o_daryl have manager as their default role, with ADMIN OPTION on it Assuming that the role has been created "that is, identified externally" within the database and that the database has been restarted with OS_ROLES set to TRUE, this is all that is required to authenticate an account at the operating system level Modifying this role is a matter of simply adding a user to the group at the UNIX level Note that operating system authentication is not available on all platforms

System Privilege Roles

Oracle6 has only three system privileges The privileges are

Oracle7 provides for backward compatibility by giving combination privileges that simulate the same functionality as their Oracle6 counterparts It uses roles of system privileges to accomplish this task

The Oracle7 CONNECT privileges that are assigned to a user by means of system privilege roles are

ALTER SESSION

CREATE CLUSTER

CREATE DATABASE LINK

The Oracle7 EXP_FULL_DATABASE privileges that are assigned to a user by means of system privilege roles are

SELECT ANY TABLE

BACKUP ANY TABLE

INSERT, UPDATE, and DELETE on SYS.INCEXP

INSERT, UPDATE, and DELETE on SYS.INCVID

INSERT, UPDATE, and DELETE on SYS.INCFIL

The Oracle7 IMP_FULL_DATABASE privileges that are assigned to a user by means of system privilege roles are BECOME USER

The Oracle7 DBA privileges that are assigned to a user by means of system privilege roles are

ALL PRIVILEGES WITH ADMIN OPTION

EXP_FULL_DATABASE

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

IMP_FULL_DATABASE

There have been rumors that these system roles have been provided only for backward compatibility with previous versions of Oracle and that future releases will not support them Although this seems unlikely given the amount of software that that relies on these privileges, you should be aware of it After all, Oracle undertook drastic changes when

it moved from Oracle6 to Oracle7

Database Auditing

This section on database auditing is the one that really causes the Mission: Impossible soundtrack to play louder

Auditing gives the DBA the ability to track information within the database It provides information on who performed a certain operation and when it was performed This is a powerful security feature of the Oracle RDBMS, but it comes with a price

Auditing is a reactive function It gives the DBA information about an activity only after it has already occurred This reactive information provides a snapshot of what occurred, depending on the level of detail being audited It gives the DBA a basis for tracking changes within the database

Because auditing causes additional rows to be added to the database for each operation, it is important to balance the auditing being done against constraints such as performance overhead and physical storage requirements Unless site-specific reasons require otherwise, the DBA should limit the amount of information being audited It is not uncommon for DBAs to run continuous high-level audit trails that track which users are connecting to the database, for example It

is much more uncommon for the database to track all SQL statements being issued by all users at all times As a rule of thumb, the DBA should introduce only lower levels of auditing when he suspects inappropriate activity, and he should

be specific about whom the audit is directed against

To activate auditing for a database instance, the DBA must make certain that the AUDIT_TRAIL parameter of the INIT.ORA parameter file is set to DB or OS to indicate where the audit trail should be written The default value for this parameter is NONE

Statement Level Auditing

Auditing that occurs at the statement level "sometimes called the privilege level" has a wide scope With this level of auditing, an audit record is written for each specific SQL statement that is issued It is possible to limit it to a specific user "such as all CREATE TABLE commands issued by DAVE" or to all users "such as any ALTER TABLE command issued by any user Depending on how specific the DBA makes this level of auditing, the audit information generated can be substantial

In the following example, two audit options are set One option logs CREATE TABLE activity within the database The other option logs all CREATE SESSION activity done by BETO

Statement processed.

Two important parameters appear in every SQL audit command:

BY SESSION/BY ACCESS determines how often audit records should be written In a BY SESSION audit, the database writes a single audit record that sums all the times that an action took place during a given session In a BY ACCESS audit, the database writes a single audit record for each SQL statement that was issued

WHENEVER SUCCESSFUL/WHENEVER NOT SUCCESSFUL determines the conditions under which the audit records should be written Audits that are WHENEVER SUCCESSFUL have information written only if they succeed WHENEVER NOT SUCCESSFUL audits are written only if they do not succeed

System-level roles can be used to implement auditing, so that only a single SQL statement is required to audit several

different operations Consult the Oracle7 Server Administrator's Guide for more information

The CLUSTER statement audits:

CREATE CLUSTER

ALTER CLUSTER

DROP CLUSTER

TRUNCATE CLUSTER

The DATABASE LINK statement audits:

CREATE DATABASE LINK

DROP DATABASE LINK

The INDEX statement audits:

The NOT EXISTS statement indicates a failure because database objects do not exist

The PROCEDURE statement audits:

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

The PUBLIC DATABASE LINK statement audits:

CREATE PUBLIC DATABASE LINK

DROP PUBLIC DATABASE LINK

The PUBLIC SYNONYM statement audits:

CREATE PUBLIC SYNONYM

DROP PUBLIC SYNONYM

The ROLE statement audits:

CREATE ROLE

ALTER ROLE

DROP ROLE

SET ROLE

The ROLLBACK SEGMENT statement audits:

CREATE ROLLBACK SEGMENT

ALTER ROLLBACK SEGMENT

DROP ROLLBACK SEGMENT

The SEQUENCE statement audits:

CREATE SEQUENCE

DROP SEQUENCE

The SESSION statement audits database connections and disconnections

The SYNONYM statement audits:

The SYSTEM GRANT statement audits:

GRANT on system privileges and roles

REVOKE on system privileges and roles

The TABLE statement audits:

The TRIGGER statement audits:

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

CREATE TRIGGER

ALTER TRIGGER ENABLE/DISABLE

DROP TRIGGER

ALTER TABLE with the ENABLE/DISABLE option

The USER statement audits:

Object Level Auditing

It is possible to audit database information at the database object level, which enables you to trap operations done on a specific database object The syntax is essentially the same as that for a statement level audit:

Consult the Oracle7 Server Administrator's Guide for more information

To deactivate object or privilege level auditing, bounce the database and set AUDIT_TRAIL to NONE, or specify the current audit options with the NOAUDIT command For example,

Audit Trail Location

The audit trails from Oracle's AUDIT option can be stored in either the database or the operating system The location is determined at database startup, based on the value of the INIT.ORA parameter AUDIT_TRAIL

SYSTEM

There are two methods for performing this operation:

SQL*Plus to get the exact sizes of the columns Drop the table and recreate it in the new tablespace Make sure that all the relevant grants on the table are made

it with the IGNORE=Y flag set

In an audited database, it is important to make sure that audit trail information is not erased To prevent that from

happening, the DBA should limit the users who can actually write information to this table to SYS This is difficult to

do, however, if users have been granted the DELETE ANY TABLE system privilege The following code segment illustrates a simple way to trap users who attempt to modify the SYS.AUD$ table:

Operating System

By directing the database to archive its information at the operating system level, the DBA enables Oracle to store its audit trail information in the same location as the audit information generated by the operating system This provides a consolidated source of information for DBAs who fill the dual roles DBA and system administrator

There are a few drawbacks to consider, though Because the data is no longer in a table, non-database utilities are needed

to access it Likewise, depending on the amount of information being audited, the database can produce double, triple, or even further increase the amount of information that the operating system currently produces

Summary

Setting up a security plan for a site can be a challenge for any Oracle DBA Aside from the development issues involved

in defining requirements and developing an overall plan, he is faced with political issues that are often insurmountable in creating the security plan

It is important to understand that there are two types of privileges: system privileges and object privileges They are the basis of anything that a user can do while he is connected to an Oracle database These also form the building blocks of database roles, which provide a means for the DBA to group together sets of similar privileges and to grant them to a single user or a group of users

The idea of a security policy is not an easy thing to implement, especially in environments in which one has never existed Even so, it is a crucial piece of the database setup that should not be overlooked

Previous

Page TOC

Next Page Home

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Previous

Page TOC

Next Page Home

Previous

Page TOC

Next Page Home

● 17

The second step is to define the logical database This phase does not deal with how the data will be stored physically, but with how information is grouped logically The requirements are translated into a model that provides a level of abstraction from the physical database, representing data in terms of business entities and relationships, rather than in terms of tables and columns

Physical design is the final phase, in which individual data elements are given attributes and defined as columns in tables This phase also deals with performance considerations relating to the creation of indexes, rollback segments, temporary segments, and the physical layout of data files on disk DDL (Data Definition Language) scripts are written to create database objects and to be used for capacity planning

A simple contact manager will be used as a sample application throughout this chapter, illustrating the concepts and techniques presented for each phase of the design process

Requirements Definition

System requirements are typically gathered through a series of interviews with the end users This is an iterative process

in which systems designers provide structure to the ongoing dialog and document findings, and solicit feedback from the users Although requirements definition is not normally considered part of the design process, the design is driven by the requirements, and the two processes often overlap For example, the logical model may bring out new requirements that were not recognized in the earlier phases of analysis It is important, however, to identify all requirements before

developing a physical design, because capacity planning and hardware purchasing decisions are ineffective without a full understanding of system requirements

A common technique used to define and document database requirements is to develop a data dictionary As the name implies, a data dictionary simply enumerates and defines the individual data elements that must be stored An initial draft

of the data dictionary for a simple contact manager might look like Table 17.1

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.