Research on Virtual Private Data Control Methods in Oracle

As database technology becomes more and more widely used, the increasing number of database users and the increasing sensitivity of data content make database security more important. To prevent unauthorized viewing and modification of data in the database, you must control user access to the data. Fine-grained access control, that is, virtual private database, provides powerful row-level security functions.

Fine-grained access control is used to provide users with a local view of a table based on a series of defined standards by transparently changing requests for data. During running, all queries are appended with a predicate to filter the rows that the user can see. For example, if you can only view the account admin account, the fine-grained access control settings automatically query:

Select * from accounts;
Where am_name = 'admin ';

DBA sets a security policy on the table ACCOUNTS. This policy has a related function called policy function. It returns a where am_name = 'admin' string used as the predicate '.

Repeated analysis required to generate a predicate is an overhead that can be trimmed in some cases. For example, in most cases, the predicates are not static as am_name = 'Scott; it is more dynamic based on the user's identity, the user's permission level, and the account administrator to which the user reports. Strings created and returned by policy functions may be highly dynamic. To ensure the results, Oracle must re-execute policy functions each time, which wastes resources and reduces performance. In this type of policy, each execution of a predicate may be very different. This policy is called a "dynamic" policy, which has been provided in the Oracle9i database and earlier versions.

In addition to retaining dynamic policies, Oracle Database 10 Gb also introduces several new types of policies based on the construction of predicates, providing better control for improving performance: context_sensitive, shared_context_sensitive, shared_static and static. Now let's take a look at the meaning of each policy type and how to use them in an appropriate context.
To maintain backward compatibility, the Default policy type in 10g is "dynamic"-just as in Oracle9i. In this case, for each row and each user, the policy function is re-evaluated every time the table is accessed. Let's analyze the rule predicates in detail:
Where am_name = 'admin'

If the where clause is ignored, the predicate has two different parts: the part before the equality operator (am_name) and the part after the equality operator ('Scott '). In most cases, the latter part is more like a variable because it is provided by the user's data (if the user is SCOTT, the value is 'Scott '). The part before the equal sign is static. Therefore, even if the function does not have to obtain the value of the policy function for each row to generate an appropriate predicate, the performance can be improved by understanding the static nature of the previous section and the dynamic nature of the subsequent sections. In 10g, you can use the "context_sensitive" type policy as a parameter in dbms_rls.add_policy call to implement this method:

Policy_type => dbms_rls.context_sensitive

In another example, we have a table named ACCOUNTS, which has several columns, one of which is BALANCE, indicating the account BALANCE. Assume that a user is allowed to view accounts lower than a specific balance, and the balance is determined by the application context. We do not fix the balance value in the policy function, but 3 is determined based on the application context, such:
Create or replace vpd_pol_func
(
P_schema in varchar2,
P_table in varchar2
)
Return varchar2
Is
Begin
Return 'balance <sys_context (''vpdctx '', ''maxbal '')';
End;

1 2 Next Page