Security
Components
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.
Session
Labels
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:
-
Minimum and
maximum security levels
-
Zero, one, or
more than one authorized compartments
-
Zero, one, or
more than one authorized groups
Row
Labels
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.
Access
Mediation
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.
Conclusion
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.
»
See All Articles by Columnist Jim Czuprynski
» 
Comment and Contribute
