Virtual Private Database (VPD), a feature of Oracle Database 11g Enterprise Edition, was introduced in Oracle8i and is one of the most popular security features in the database. 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 your security requirements. 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. 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.
Attaching Oracle Virtual Private Database security policies to database tables, views, or synonyms, rather than implementing access controls in all your 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.
Running policy functions multiple times can affect performance. You can control the performance of policy functions by configuring how Oracle Database caches the Oracle Virtual Private Database predicates. The following options are available:
- Evaluate the policy once for each query (static policies).
- Evaluate the policy only when an application context within the policy function changes (context-sensitive policies).
- Evaluate the policy each time it is run (dynamic policies).