Oracle Label Security is a security option for the Oracle Enterprise Edition database and was introduced with Oracle 8.1.7. Oracle Label Security mediates access to data rows by comparing labels attached to data rows in application tables (sensitivity labels) and a set of user labels (clearance labels).
Who should consider Oracle Label Security?
Sensitivity labels are used in some form in virtually every industry. These industries include health care, law enforcement, energy, retail, national security and defense industries. Examples of sensitivity labels include:
Confidential : Chicago Operation
Sensitive : Finance : Europe
Application providers can integrate Oracle Label Security functionality to enhance their product offering and gain competitive advantage.
What can Oracle Label Security do for my security needs?
Oracle Label Security can be used to label data and restrict access with a high degree of granularity. This is useful when multiple organizations, companies or users share a single application. Sensitivity labels can be used to restrict application users to an organization or subset of data within an organization, without having to change the application. Data privacy is important to consumers and regulatory measures continue to be announced. Oracle Label Security can be used to implement privacy policies on data, restricting access to only those who have a need-to-know.
Should I use Oracle Label Security to protect all my tables?
The traditional Oracle discretionary access control (DAC) object privileges SELECT, INSERT, UPDATE, and DELETE combined with database roles and stored procedures are sufficient in most cases. Furthermore, before applying OLS to your sensitive tables, some considerations need to be taken into account;
they are documented here.
Are there any guidelines for using Oracle Label Security and defining sensitivity labels?
Yes, a comprehensive
Label Security Administrator's Guide is available online from
tahiti.oracle.com. In addition, a
comprehensive collection of examples is available on the Oracle Technology Network, which walk you through a list of recommended implementation guidelines. In most cases, the security mechanisms provided at no-cost with the Oracle Enterprise Edition (system and object privileges, Database roles, Secure Application Roles) will be sufficient to address security requirements. Oracle Label Security should be considered when security is required at the individual row level.
Where can I find Oracle Label Security?
Oracle Label Security ships on the Oracle Enterprise Edition CD. Oracle Label Security is not installed as part of the typical/default Oracle installation. Choose the "Custom Installation" option and check the box beside 'Oracle Label Security'. After the installation, use 'dbca' (Database Configuration Assistant) to register Oracle Label Security.
Can Oracle Label Security policies and user labels (clearances) be stored centrally in Oracle Identity Management?
What is the difference between Oracle Virtual Private Database (VPD) and Oracle Label Security?
Oracle VPD has several powerful security features – fine grained access control (FGAC), application context and global application context. VPD policies are written using PL/SQL, and can be assigned to an individual table or view. Information requests which reference tables and views protected by VPD are modified according to the policy assigned to this table or view. VPD policies can be as simple as enforcing access during business hours. VPD policies can restrict access by comparing the value of an attribute in an individual row with an application context value. Global application context allows an application context to be accessed across multiple database sessions, reducing or eliminating the need to create a separate application context for each user session.
Oracle Label Security is an out-of-the-box solution for row level security, built on VPD technology. No coding or software development is required, allowing the administrator to focus completely on the policy. Oracle Label Security provides an interface for creating policies, specifying enforcement options, defining data sensitivity labels, establishing user label authorizations, and protecting individual tables or schemas. Data sensitivity labels provide a powerful and flexible method of restricting access to data. For example, data belonging to different organizations or companies can be separated using data sensitivity labels and selectively shared between companies by changing the data sensitivity label.
Depending on the complexity of the security policy, Oracle Virtual Private Database (VPD) may be the preferred method for implementing your security policy. In addition, Oracle Label Security is best suited for situations where access control decisions need to be based on the sensitivity of the information.
Oracle VPD is provided at no cost with the Oracle Enterprise Edition. Oracle Label Security is an add-on security option for the Oracle Enterprise Edition.
Can I combine Virtual Private Database and Oracle Label Security?
Yes, there are two 'intersections':
A 'Where' clause can be appended to an OLS policy, which provides one more level of granularity. An example would be that users, regardless of their label authorizations, are only allowed to connect from a specific IP address or subnet, and/or during business hours only.
A VPD policy (column sensitive or not) can evaluate user labels and determine access to columns and rows without the need to apply data labels on these rows. (
Can I use Oracle Label Security with the Oracle E-Business Suite?
The Oracle E-Business Suite uses Oracle VPD internally to provide fine-grained access control.
Steven Chan's blog is a good source of security-related questions regarding Oracle's E-Business Suite.
How do Label Security and Database Vault complement each other?
Tables in Database Vault that are protected with OLS policies behave the same as if they were stored and accessed in a 'normal' database, since Database Vault provides access controls at the object level, not down to the row level.
OLS labels can be assigned to Database Vault 'Factors'; these labels are then merged with the user clearance labels, following the algorithms documented in chapter 4.4.5 of the OLS admin guide: "Merging Labels with the MERGE_LABEL Function", before access control decisions are being made by comparing the merged user labels with the row labels. (
A VPD policy can be written so that it only becomes active when a certain column (the 'sensitive' column) is part of a SQL statement against a protected table. With 'column sensitivity' switch on, VPD either returns only those rows that include information in the sensitive column the user is allowed to see, or it returns all rows, with all cells in the sensitive column being empty, except those values the user is allowed to see.
This page contains sample screen shots for the various configurations of VPD.
Can I base Secure Application Roles on Oracle Label Security?
Yes, the procedure, which determines if the 'set role' command is executed, can evaluate OLS user labels. In this case, the OLS policy does not need to be applied to a table, since row labels are not part of this solution. (
What are Trusted Stored Program Units?
Stored procedures, functions and packages execute with the system and object privileges (DAC) of the definer. If the invoker is a user with OLS user clearances (labels), the procedure executes with a combination of the definer's DAC privileges and the invoker's security clearances.
Trusted stored procedures are procedures that are either granted the OLS privilege 'FULL' or 'READ'. When a trusted stored program unit is carried out, the policy privileges in force are a union of the invoking user's privileges and the program unit's privileges.
Does VPD or OLS add an additional column to the protected table?
When an OLS policy is applied to a table, it adds an additional (hidden) column to it. The name of this column needs to be specified when the policy is initially created.
An existing column can be used to store the OLS row labels; its datatype needs to be defined as 'number(10)'.
VPD does not add an additional column to the protected table.
Why is the additional OLS row label column hidden?
Most applications were not designed with access control mechanisms in mind, so OLS needs to do this transparently.
When an application queries a table with a 'select * from <tablename>;', it returns all columns, including the not-hidden label column. Existing applications may not be designed to display an additional column, and malfunction. But a hidden column is displayed only when it's name is included in the SQL statement, hence a 'select * from <tablename>;' returns all columns as expected by the application, excluding the hidden OLS column.
Are there any administrative tools available for Oracle Label Security?
Beginning with Oracle Database 11gR1, the functionality of Oracle Policy Manager (and most other security related administration tools) has been made available in Enterprise Manager Grid Control, enabling administrators to create and manage OLS policies in a modern, convenient and integrated environment.
How do I install and start Oracle Policy Manager?
Starting with Oracle Database 11gR1, Oracle Policy Manager is no longer available. Enterprise Manager Database Control is installed by default and is started by issuing:
$ emctl start dbconsole
Before LBACSYS, the owner of the OLS objects and policies, can log into Enterprise Manager Database Control to create and manage OLS policies, the account must be unlocked, and the 'Select Any Dictionary' system privilege must be granted to LBACSYS.
How can I maintain the performance of my applications after applying Label Security access control policies?
Pay attention to the following hints:
Only apply sensitivity labels to those tables that really need protection
Do not apply OLS policies to schemas
Usually, there is only a small set of different data classification labels; if the table is mostly used for READ operations, try building an Bitmap Index over the (hidden) OLS column, and add this index to existing indexes in that table