Introduction to Database Security Policies
Security Threats and Countermeasures
Security threats can be addressed with different types of measures:
- Procedural, such as requiring data center employees to display security badges
- Personnel, such as performing background checks or "vetting" key personnel
- Physical, such as securing computers in restricted-access facilities
- Technical, such as implementing strong authentication requirements for critical business systems
Oracle9i offers many mechanisms which can implement the technical measures of a good security policy.
What Information Security Policies Can Cover
In addition to requirements unique to your environment, you should design and implement information security policies to address the following important issues:
- The level of security at the application level
- System and object privileges
- Database roles
- Enterprise roles
- How to grant and revoke privileges and roles
- How to create, alter, and drop roles
- How to control role use
- Level of granularity of access control
- User attributes which govern access to the database
- Whether to use encryption
- How to implement security in three-tier applications
Features to Use in Establishing Security Policies
- Application Security
- Fine-Grained Access Control
- Application Context
Introduction to Application Security Policies
Creating a Role and Protecting Its Use
Creating and Implementing a New Role
To create a role, you must have the CREATE ROLE system privilege.
Immediately after creation, a role has no privileges associated with it. To associate privileges with a new role, you must grant it privileges or other roles.
You can create roles such that their use is authorized using information from the operating system, from a network authentication service, or from an LDAP-based directory. This enables role management to be centralized.
Protecting Role Use
The use of a role can be protected by an associated password. For example:
CREATE ROLE Clerk IDENTIFIED BY Bicentennial;
A user who is granted a role protected by a password can enable or disable the role only by supplying the proper password for the role using a SET ROLE statement.
Enabling and Disabling Roles
When to Enable Roles
In general, a user's security domain should permit him to perform the task at hand, yet limit him from having privileges which are not necessary for the current job.
A default role is automatically enabled for a user when the user creates a session. A user's list of default roles should include those which correspond to his or her typical job function.
When you drop a role, the security domains of all users and roles granted that role are immediately changed to reflect the absence of the dropped role's privileges. All indirectly granted roles of the dropped role are also removed from affected security domains. Dropping a role automatically removes the role from all users' default role lists.
You can drop a role using the SQL statement DROP ROLE. For example:
DROP ROLE clerk;