Introduction to Fine-Grained Access

Security protections start with good identification and authentication. Once you know the user’s identity, you can determine what they are authorized to do and enable the necessary privileges for them to do their work. This can be done successfully by using system and object privileges and database roles in accordance with the least privilege principle. Privileges on database objects is the primary security control governing access to data—even still, it may not be sufficient for your security requirements.

Object Access

You have already seen how object and system privileges allow or disallow access to data objects such as tables, views, and procedures. A user with the select privilege on a table will be able to read all records within that table. The select privilege operates at the object level (where the table is the object in this example). The key distinction here is that the database privileges apply to accessing the object (table or view) but do not specify the security within the object. Limiting access to data within tables is desirable and is often a security requirement.

To understand the requirement better, consider a physical security example that can be used as lesson for digital security: office building security.

For many office buildings, physical security is a concern. As such, a security infrastructure is built and supported. Security guards are employed, security badges are issued to authorized users, and doors and elevators are locked and require some special key to open or activate them.

The first layer of security occurs at the perimeter: gaining access to the facility on which the building resides. This is analogous to the digital first step of identification and authentication. Next, you enter the building and encounter a security checkpoint. In this case, the building is similar to a database table or view: it represents a single object or entity that you wish to protect. Once you get through this security checkpoint, you have access to the building but not necessarily access to every corridor and office within.

Fine-Grained Access

Many of today’s office buildings have secured areas such as floors, corridors and rooms. Most offices within the building are kept locked. The office occupant and perhaps the occupant’s boss and the cleaning crew are the only people with the keys to enter the office. Everyone accepts the fact that people with access to the building do not need nor have access to everything within the building. In a sense, this is an enforcement of the least privilege principle—people have privileges to access only to what they need to do their job and nothing more.

These physical security principles can be applied to data in your databases. While many users may require access to records stored in the same table, most users do not need access to all records within the table. This is especially true for tables with sensitive information.

Need to Know

There is a security tenet commonly practiced that says users can only access data to which they have a “need to know.” It is similar to least privileges in that you are trying to minimize the data to which a user has access. For the organizations that deal with classified data, the need-to-know concept is used extensively to protect information. The reasons are based on the fact that the fewer people who know a piece of information, the easier it is to manage and secure it. While you may trust many people with knowledge of certain critical information, such as the DBA passwords to your databases, need to know dictates that only the people that have a requirement for the information will get access to it. Think of the risks created if everyone knew the administrator passwords—anyone would be able to gain access to the critical data, and you wouldn’t know who accessed what.

For applications in many industries, the need-to-know concept provides a guiding principle in the development of security policies. For example, doctors need to know the diagnosis of the patients they are treating. For privacy reasons, enforcing this access helps ensure that a nosy doctor doesn’t exploit his role as a physician. The doctor should not be looking at the medical records of random patients because they do not need to know that information. Need to know holds true for tax accountants, financial institutions, and many other professions in many industries.

The database must therefore support the ability to provide access to some records while simultaneously restricting access to others. There are several ways to ensure need to know within a database application. The methods can be grossly categorized as security within the application or security within the database. Defense in depth suggests the use of security in the application and security in the database whenever practical and possible. The remainder of this chapter will focus on implementing fine-grained access controls through database views to support the need-to-know security requirements.



Effective Oracle Database 10g Security by Design
Effective Oracle Database 10g Security by Design
ISBN: 0072231300
EAN: 2147483647
Year: 2003
Pages: 111

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net