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.
Comments
Post a Comment