Oracle Label Security, Part 1: Overview - Page 2
August 29, 2003
OLS uses three sets of criteria to define both the set of user's permissions to access data in a row as well as the row's accessibility: levels, compartments, and groups.
Levels. As the first security dimension's name implies, a level defines increasing data sensitivity. A typical example includes the standard security levels (Unclassified, Classified, Secret, and Top Secret). Another example for most companies is human resources information. Just about everyone needs to know everyone else's first and last name and e-mail address (i.e. company-wide access). However, only the employee, her supervisor, and the Human Resources department should know salary information about the employee (hopefully!) only the human resources coordinator should know about an employee's participation in a company-sponsored anger-management class.
Compartments. The second security dimension, a compartment defines the areas to which data access is restricted. In other words, compartments can be used to classify data. Typical examples of compartments include functional divisions within a company (Sales, Accounting, Human Resources, Information Technology).
Groups. A group is the third security dimension. It typically defines who is the owner of the data and provides yet another way to classify what type of access is permitted. However, groups have one important difference: They can be used to restrict access to data based on the owning organization's hierarchical structure. Business rules appropriate for group enforcement within a group include geographical areas (localities within states/provinces, and states/provinces within countries) and sales forces (regions that encompass several districts that themselves encompass territories). What's really great about this feature is that OLS allows me to restrict row-level access to specific nodes of the hierarchy. For example, I can grant a sales force's regional manager access to only sales generated within his region's districts; a district manager access to sales generated only within her district's territories; and a salesperson to only the sales generated within his territory.
Security Component Combinations. For each of the label security components, up to 10,000 different values may be established. OLS requires that, at a minimum, one value for the security level must be stored in each label column, even if it indicates unrestricted access is permitted. Note, however, that compartments and groups need not be included in the label column's value. Also, each row and each user can be assigned multiple access permissions for compartments and groups.
OLS provides authorization to access secured data based on the combined set of security components assigned to the user known as the session label. When first set up by the security policy administrator, it also defines the user's initial session label, but note that the session label can be modified by the user to any combination of his or her authorized components. The session label is defined by:
OLS secures the data itself by adding a label column to the table(s) that need secured access. The label column is in essence a simple NUMBER datatype that stores the values that are decoded by OLS during access mediation to determine if the row is accessible to the user's session.
During access mediation, OLS compares the value stored in the label column to the user's label permissions. If the user has been granted sufficient permission to access the row, then the transaction continues. Note that the user must be granted read mode to issue a SELECT statement against the row, and that the user also needs to be granted write mode to perform DML statements (INSERT, UPDATE, DELETE, or MERGE) against the row.
Managing Security Policies
If the setup of these myriad security policies, user levels, and row
security levels seems daunting, fear not! Oracle provides a graphical tool -- Oracle Policy Manager -- that leverages the Oracle Enterprise Manager GUI technology to easily construct and manage OLS security policies. And for those of us who prefer to script our own commands to build the security components, manage the user security policies, and establish row-based security, Oracle supplies several packages to facilitate their easy construction.
So far, we've discussed what needs Oracle Label Security fulfills. In my next article, I'll delve into some actual examples of how to implement Oracle Label security in a database. I'll also show you how to establish security policies, user labels, and row labels. Finally, we'll discuss how Oracle uses access mediation to determine what to do when a user does or doesn't have permission to view or modify a row.
References and Additional Reading
While there is no substitute for direct experience, reading the manual is not a bad idea, either. I've drawn upon the excellent Oracle documentation found in Oracle Label Security Administrator's Guide (A96578-01) for the deeper technical details of this article.