The Virtual Private Database (VPD) provides row-level access control beyond the capabilities of roles and views.
Row Level Security
A customer can only see his orders in the 'orders' table (below), when he is listed in the 'customers' table (below).
VPD can be configured such that the policy is enforced only when a critical column is selected.
Example : The account manager with the account_mgr_id “149” can see all rows from the customers table, but not the credit limits. As soon as she queries the 'credit_limit' column, she can only see her own customers.
The most advanced configuration (“Column Hiding”) of VPD allows for the most effective combination of ease-of-use and security: She still has access to all public information in the 'customers' table, but confidential information remains hidden:
VPD can be used in combination with the “application context” feature to enforce sophisticated row and/or column level security requirements for privacy and regulatory compliance.
Within the enterprise, the Virtual Private Database results in lower costs of ownership in deploying applications. Security can be built once, in the data server, rather than in each application that accesses data.
Central Data Security
The security is stronger, because it is enforced by the database. The Virtual Private Database ensures that, no matter how a user gets to the data (through an application, a report writing tool, or SQL*Plus), the same strong access control policy is enforced.
How the Virtual Private Database Works
The Virtual Private Database is enabled by associating one or more security policies with tables or views. Direct or indirect access to a table with an attached security policy causes the database to consult a function that implements the policy. The policy function returns an access condition known as a predicate (a WHERE clause), which the database appends to the user's SQL statement, thus dynamically modifying the user's data access.