Chapter 7: Privileges and Roles

This chapter discusses database privileges and roles. Understanding privileges and how they can be granted is important to employing effective security. Roles allow administrators to grant users the necessary privileges needed to perform their job. Roles are a powerful and manageable way to provide a least-privileged environment, which is important to ensuring a sound and secure database.

The intent of this chapter is not to duplicate the Oracle product documentation, which discusses both privileges and roles. The objective here is to point out some of the important and subtle aspects that are associated with privileges and roles. This is a very important chapter because database access, and to a large extent database security, relies on user privileges.

Access Control, Authorizations, and Privileges

We’ll begin by reviewing a few terms: access control, authorizations, and privileges. You will find these terms littered throughout security policies. These terms, while sometimes used interchangeably, are in fact different. A good understanding is helpful and often necessary in discussions about security policies and implementations.

Access Control

Access control is the process of allowing or preventing access to a resource. There are many ways to determine access or implement access control. A simple way to describe access control is to associate it with a commonly understood implementation called access control lists.

Access control lists (ACLs) are a common way for people to describe the security policy associated with a given application or database. The list is conceptual in most cases and describes who can access what and how they can do it. The ACLs are derived from the organization’s security policies. It’s important to understand that the list is not the enforcement mechanism. The enforcement mechanism is something inside the application or database engine that refers to the list to determine access.

Enforcing Access Control

Think of access control mechanisms as the sentry standing guard at an entry portal. The guard’s job is simply to permit or restrict people from entering the portal. The decision to allow entry may be based on anything, such as a list of approved names, proof of an organizational affiliation, or possession of some kind of permission slip or token. The important thing is that the role of the guard is well defined and narrowly focused. The job is to grant or deny access based on something. As people wish to gain entry, the guard will either allow entry or disallow entry.

The access control mechanisms in the database “stand guard” over database objects, such as tables, views, and procedures. The database decides who gets access to what based on privileges. Privileges, however, can be obtained in multiple ways. Effective security design implies the importance of understanding how privileges can be given, obtained, and managed.

Authorizations

A person is considered authorized when they are allowed to perform an action as described by some governing policy. A boarding pass may authorize a person to get on an airplane. A special badge may authorize a person to enter a secure area. That is, the sentry standing guard should allow them access because they are approved and allowed to gain entry. This doesn’t mean the guard has to let them pass, only that the guard should let them pass.

An authorization translates into one or more privileges, such as the privilege to be in a secure area or the privilege to access a database. The access control mechanisms of the application or database are actually implemented by checking a user’s privileges. Authorizations are abstractions. They represent a binding between a security policy and the actual privileges a user has in a specific context.