Introduction to VPD

Virtual private database (VPD) enables you to enforce security, to a fine level of granularity, directly on tables, views, or synonyms. Because security policies are attached directly to tables, views, or synonyms and automatically applied whenever a user accesses data, there is no way to bypass security.

When a user directly or indirectly accesses a table, view, or synonym protected with a VPD policy, the server dynamically modifies the SQL statement of the user. The modification creates a WHERE condition (known as a predicate) returned by a function implementing the security policy. The statement is modified dynamically, transparently to the user, using any condition that can be expressed in or returned by a function. VPD policies can be applied to SELECT, INSERT,UPDATE, INDEX, and DELETE statements.

Note:

Users need full table access to create table indexes. Consequently, users with privileges to maintain an index can see all the row data even if they do not have full table access under a regular query. To prevent this, apply VPD policies to INDEXstatements.

Functions that return predicates can also include calls to other functions. Within your PL/SQL package, you can embed C or Java calls to access operating system information or to return WHERE clauses from an operating system file or central policy store. A policy function can return different predicates for each user, for each group of users, or for each application. Using policy functions over synonyms can substitute for maintaining a separate view for each user or class of users, saving substantial overhead in memory and processing resources.

Application context enables you to securely access the attributes on which you base your security policies. For example, users with the position attribute ofmanager would have a different security policy than users with the position attribute of employee.

Consider an HR clerk who is only allowed to see employee records in the Retail Division who initiates the following query:

SELECT * FROM emp;

The function implementing the security policy returns the predicate division = 'RETAIL', and the database transparently rewrites the query. The query actually executed becomes:

SELECT * FROM emp WHERE division = 'RETAIL';

Column-Level VPD

Column-level VPD enables you to enforce row-level security when a security-relevant column is referenced in a query. You can apply column-level VPD to tables and views, but not to synonyms. By specifying the security-relevant column name with the sec_relevant_cols parameter of the DBMS_RLS.ADD_POLICYprocedure, the security policy is applied whenever the column is referenced, explicitly or implicitly, in a query.

For example, users outside of the HR department typically are allowed to view only their own Social Security numbers. When a sales clerk initiates the following query:

SELECT fname, lname, ssn FROM emp;

The function implementing the security policy returns the predicate ssn='my_ssn' and the database rewrites the query and executes the following:

SELECT fname, lname, ssn FROM emp WHERE ssn = 'my_ssn';

Column-Level VPD with Column-masking Behavior

If a query references a sensitive column, then the default behavior. of column-level VPD restricts the number of rows returned. With column-masking behavior, which can be enabled by using the sec_relevant_cols_opt parameter of the DBMS_RLS.ADD_POLICY procedure, all rows display, even those that reference sensitive columns. However, the sensitive columns display as NULL values.

To illustrate this, consider the results of the sales clerk query, described in the previous example. If column-masking behavior. is used, then instead of seeing only the row containing the details and Social Security number of the sales clerk, the clerk would see all rows from emp, but the ssn column values would be returned as NULL. Note that this behavior. is fundamentally different from all other types of VPD policies, which return only a subset of rows.

VPD Security Policies and Applications

The security policy is applied within the database itself, rather than within an application. This means that the use of a different application will not bypass the security policy. Security can thus be built once, in the database, instead of being implemented again in multiple applications. VPD therefore provides far stronger security than application-based security, at a lower cost of ownership.

It may be desirable to enforce different security policies depending on which application is accessing data. Consider a situation in which two applications, Order Entry and Inventory, both access the ORDERS table. You may want to have the Inventory application use a policy that limits access based on type of product. At the same time, you may want to have the Order Entry application use a policy that limits access based on customer number.

In this case, you must partition the use of fine-grained access by application. Otherwise, both policies would be automatically ANDed together, which is not the desired result. You can specify one or more policy groups, and a driving application context that determines which policy group is in effect for a given transaction. You can also designate default policies that always apply to data access. In a hosted application, for example, data access should always be limited by subscriber ID.

oracle VPD介紹

Introduction to VPD

Column-Level VPD

Column-Level VPD with Column-masking Behavior

VPD Security Policies and Applications

相關文章