Scribd
Upload
28 views14 pages

Virtual Private Database

Uploaded by

Atif
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
28 views14 pages

Virtual Private Database

Uploaded by

Atif
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

Virtual Private Database

Label Security

1
• Figure 1‐1
This illustration depicts an overview of the computing environment
and shows the different aspects of the environment that need
protection. Databases and the servers on which they reside, the
rights of internal database users, and the confidentiality of
electronic commerce customers all need the protection of
computer security.
2
Oracle Label Security
• Labels enable sophisticated access control rules beyond those of
discretionary access control by using data in the row. When a policy
is applied, a new column is added to each data row. This column
will store the label reflecting each row's sensitivity within that
policy. Level access is then determined by comparing the user's
identity and label with that of the row.
• Oracle Label Security access control depends first on the basic DAC
policy. Together, DAC and Oracle Label Security dictate the criteria
controlling whether access to a row is permitted or denied.
• In most applications, only a relatively small number of tables need
the extra security of label‐based access controls. The protection
provided by standard DAC is sufficient for the majority of
application tables.

3
How Oracle Label Security Works with
Discretionary Access Control
• To be allowed access to a row, a user must first satisfy Oracle9i DAC
requirements, and then satisfy Oracle Label Security requirements.
• Oracle9i enforces DAC based on the user's system and object privileges:
The user must be authenticated to the Oracle9i database, and must have
the object and system privileges DAC requires for the requested operation.
• If DAC permits access, the user's requested operation must then meet the
criteria added by Oracle Label Security, using all of the following facts:
– Oracle Label Security label definitions and label hierarchies
– the labels of the user and row
– Oracle Label Security enforcement options
– the user's Oracle Label Security policy privileges
• Oracle Label Security's flexibility and functionality supports applications in
a wide variety of production environments. It maintains standard
Oracle9i data integrity, availability, and recovery capabilities, including
user accountability and auditing, while enforcing a site's security policies.
4
Oracle Label Security Architecture

Oracle Label Security


is built on the virtual
private database
(VPD) technology
delivered in the
Oracle Enterprise
Edition and
leverages that
product's
Application Context
functionality.

This illustration depicts how Oracle Label Security operates when a user
issues a SQL request. First, Oracle9i checks the DAC privileges to make
sure the user has the SELECT privilege on the table. It then checks to see if
a VPD policy has been attached to the table. If so, the VPD SQL
modification (WHERE clause) is added to the original SQL statement, and
the set of rows to which the user has access is determined. Then Oracle
Label Security checks the labels on each row in this set, to determine the
5
subset of rows to which the user has access.
Figure 1‐3 Oracle Label Security Label‐
Based Security

For example, assume that a user has SELECT privilege on an application


table. As illustrated in Figure 1‐3, when the user executes a SELECT
statement, Oracle Label Security evaluates each row selected to
determine whether the user can access it. The decision is based on the
privileges and access labels assigned to the user by the security
administrator. Oracle Label Security can also be configured to perform
security checks on UPDATE, DELETE, and INSERT statements.

6
Oracle Enterprise Edition: Virtual
Private Database Technology
• VPD supports policy‐driven access control. VPD policies enforce
object‐level access control or row‐level security.
• It provides an application program interface (API) that allows
security policies to be assigned to database tables and views.
• For example, one can allow access to salary data only for managers
in the same facility. Using PL/SQL, developers and security
administrators can create security policies with stored procedures.
These procedures can be bound to a table or view by means of a
call to an RDBMS package.
• Such policies restrict access by using the content of application data
stored in the Oracle9i database or context variables provided by
Oracle9i (and higher), such as user name or IP address.
• Using VPD policies permits developers to remove access security
mechanisms from applications and centralize them within Oracle9i
(and higher).

7
Figure 1‐4 Oracle9i Enterprise Edition
Virtual Private Database Technology

As illustrated in Figure 1‐4, VPD lets you associate security conditions


with tables, views, or synonyms. In this example, when each user selects
from the ORDERS table, the appropriate security condition is
automatically enforced. No matter how the data is accessed, the server
automatically enforces security policies, eliminating the need to use
many views to implement security.
8
Access Mediation Factors in Oracle
Label Security
• Label or Policy Factor
• The label of the data row to which access is
requested
• The label of the user session requesting access
• The policy privileges for that user session
• The policy enforcement options established
for that table

9
• Consider, for example, a standard Data Manipulation
Language operation (such as SELECT) performed upon a row
of data.
• When evaluating this access request by a user with the
CONFIDENTIAL label, to a data row labeled CONFIDENTIAL,
Oracle Label Security determines that this access can, in fact,
be achieved. If the row label were higher, say TOP SECRET,
access would be denied.
• In this way, data of different sensitivities‐‐or belonging to
different companies‐‐can be stored and managed on a single
system, while preserving data security through standard
Oracle access controls.
• Likewise, applications from a broad range of industries can
use row labels with policies providing additional highly
targeted access control wherever necessary, without
disturbing other existing uses for the same tables. 10
Data Labels
• In Oracle Label Security, each row of a table
can be labeled as to its level of confidentiality.
Every label contains three components:
– a single level (sensitivity) ranking
– zero or more horizontal compartments or
categories
– zero or more hierarchical groups

11
12
• The compartment component is not hierarchical, but
simply designates some useful categories typically
defined to segregate data‐‐such as data related to
separate ongoing strategic initiatives. Some
organizations omit using compartments initially.
• The group component is hierarchical and is used to
reflect ownership. For example, FINANCE and
ENGINEERING groups can be defined as children of the
CEO group, creating an ownership relation. This
hierarchy determines that a user labeled with only
ENGINEERING could not view data labeled with
FINANCE, but a user labeled CEO could see data
labeled as either subgroup.
13
Label Authorizations
• Users can be granted label authorizations that
determine what kind of access (read or write)
they have to the rows that are labeled.
• When a label has been applied to a row, only
users authorized for access to that label can see it
or possibly change it.
• No user can access or affect rows for which that
user lacks appropriate authorization.
• If a row has multiple labels, a user must have
appropriate authorizations for each such label in
order to see or alter that row.
14

You might also like