Virtual Private Database (VPD)

What is VPD?

Virtual Private Database (VPD) is a database security feature that is built into an Oracle database server, as opposed to being part of an application that is accessing the data. The user is only allowed to see the data they have been given permission to see.

VPD is a feature of Oracle Database 11g Enterprise Edition, was introduced in Oracle8i.

Why VPD?

VPD is used when the standard object privileges and associated database roles are insufficient to meet application security requirements. VPD policies can be simple or complex depending on organization’s security requirements. VPD uses application contexts to provide row-level security and fine-grained access control based on a company's security policies. Application contexts are simply key value pairs that are created in a defined namespace.

A simple VPD example might restrict access to data during business hours and a more complex VPD example might read an application context during a login trigger and enforce row level security against the ORDERS table.

No matter how users connect to the protected table (via an application, a Web interface or SQL*Plus), the result is the same. There is no "application security problem" anymore, since the access policy is attached to the table, and cannot be bypassed.

Example:

A customer can only see his orders in the 'orders' table (below), when he is listed in the 'customers' table (above).

Benefits of using VPD

Attaching Oracle Virtual Private Database security policies to database tables, views, or synonyms, rather than implementing access controls in all organization's applications, provides the following benefits:

Security: Associating a policy with a database table, view, or synonym can solve a potentially serious application security problem. Suppose a user is authorized to use an application, and then drawing on the privileges associated with that application, wrongfully modifies the database by using an ad hoc query tool, such as SQL*Plus. By attaching security policies directly to tables, views, or synonyms, fine-grained access control ensures that the same security is in force, no matter how a user accesses the data.

Simplicity: You add the security policy to a table, view, or synonym only once, rather than repeatedly adding it to each of your table-based, view-based, or synonym-based applications.

Flexibility: You can have one security policy for SELECT statements, another for INSERT statements, and still others for UPDATE and DELETE statements. For example, you might want to enable Human Resources clerks to have SELECT privileges for all employee records in their division, but to update only salaries for those employees in their division whose last names begin with A through F. Furthermore, you can create multiple policies for each table, view, or synonym.