Vpd   Virtual Private Database By Saurabh
Upcoming SlideShare
Loading in...5
×
 

Vpd Virtual Private Database By Saurabh

on

  • 2,573 views

 

Statistics

Views

Total Views
2,573
Views on SlideShare
2,560
Embed Views
13

Actions

Likes
0
Downloads
50
Comments
0

4 Embeds 13

http://oracleexpert4u.blogspot.com 10
http://oracleexpert4u.blogspot.de 1
http://oracleexpert4u.blogspot.com.br 1
http://oracleexpert4u.blogspot.in 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Vpd   Virtual Private Database By Saurabh Vpd Virtual Private Database By Saurabh Presentation Transcript

    • VPD – Virtual Private Database General Overview
    • VPD - Feature
      • Virtual Private Database offers:
        • Lower cost of ownership
        • Elimination of the “application security problem”
        • Application transparency
        • New business opportunities
      • VPD Features :
        • Partitioned Fine-grained Access Control
          • Create unique application contexts per application
        • Global Application Context
          • Define rules to secure the application
        • Oracle Policy Manager
          • GUI tool for managing VPD policies
        • Support for Synonyms (in 9iR2)
        • Support for Column-Level (in 10g)
        • Add-on Option: Label Security
      • Oracle‘s VPD provides access control at the row level.
      • It works by appending clauses (predicates) to sql statement executed by the user. To make this happen a Pl/Sql function (policy function) is attached to a table which, when executed, returns a string that will be appended to the sql before it is parsed and executed.
      Core Concept: Oracle’s Virtual Private Database (VPD)
      • A simple walkthrough of the basic concept....
      • Create a policy function
      • FUNCTION employee_policy ()
      • RETURN VARCHAR2
      • IS
      • BEGIN
      • RETURN 'locn_ctry = '‘USA''' ;
      • END employee_policy ;
      2 . Attach the employee_function to tbl_employee DBMS_RLS.ADD_POLICY( object_schema => ‘SRC_TSYS_DBA' , object_name => 'TBL_EMPLOYEE' , policy_name => 'VPD_POLICY' , function_schema => ‘SRC_PRIVATE_DBA' , policy_function => 'EMPLOYEE_POLICY' , statement_types => 'SELECT' );
        • 3. Perform SELECT statement
        • User Submits: SELECT * FROM tbl_employee
        • DB parses/executes: SELECT * FROM tbl_employee WHERE locn_ctry = ‘USA‘
    • VPD continued…..
      • User Specific Criteria
      • A more realistic application of the previous example would require changing the country depending on the user.
      • This requires always knowing the users id from within the database regardless of which db account is in use. This information is not available where the user makes access through connection pools within the middle tier based on the front end user account.
      • To overcome this Oracle provides the Client Identifier.
      • Client Identifier
      • The client identifier is a 64 character string that can be defined to uniquely identify the user currently using the connection. Before a connection can be obtained from the connection pool the client identifier must be set correctly.
        • It is unique to a session and stays in the memory attached to that session as long as the session is active.
        • The current value of the Client Identifier can be viewed using
        • Set the Client Identifier and check it for yourself:
        • 1. exec dbms_session . set_identifier ( sys_context ( 'USERENV' , 'OS_USER' ) || ' ' || SYSTIMESTAMP );
        • 2.SELECT sys_context ( 'USERENV' , 'CLIENT_IDENTIFIER' ) FROM dual
    • VPD continued…..
      • Although the Client Identifier provides a means of identifing the user, it does not solve the issue of applying user specific criteria to SELECT statements.
      • To get over this limitation we use the Application Context
      • Application Context
      • Application contexts are akin to session variables. Once set, they can be accessed in a session any time. A different value can be set in another session and the values will not be visible across the sessions (as long as the db user is different). However, if the same db user (front end login) is used the changes will be visible across sessions.
      • A context has attributes, similar to the columns of a table.
      • The attributes of contexts can be defined at runtime.
      • To insert a value into the context you use the following command.
      •   > DBMS_SESSION.SET_CONTEXT ( context, key, value, user, clientIdentifier );
      • Back to generating user specific Select criteria…
      • So, assuming we have a procedure, which is executed upon login to build the users context. Then the policy function can be simplfied to: 
      • FUNCTION employee_policy ()
      • RETURN VARCHAR2
      • IS
      • BEGIN
      • RETURN 'locn_ctry = sys_context(''VPD_CONTEXT'', ''LOCN'')' ;
      • END employee_policy ;
      • This provides us with a user based result.
    • How it comes together...
      • Logging In
      • Authenticate the user
      • Construct the Client Identifier
      • Initialise the application context ( the context must contain the information required to fulfill the policy function requests )
      • Policy Function Execution
      • Execute Select -
      • Oracle parses sql and scan the sql for tables that have policies attached
      • For each table with a policy the policy function will be called. This function returns a predicate that Oracle cleverly appends to the sql. The context is necessary to resolve these predicates.
      • Results sent to user
      The VPD framework is triggered at two specific points in the lifetime of a session. Firstly upon login and secondly when a select statement is submitted. This corresponds to the creation of the user Application Context at login time and the addition of the predicates when a select is executed.
      • Predicates
      • To meet our performance needs we have chosen to user static predicates. That is, they will be fired once and meet the restriction requirements for all users.
      • Genaral predicate rules:
    • How it comes together.....continued
      • General Predicate Rules within the Access Model:
        • Check if table belongs to a data segment
        • If so, check what access the user has to the data segment
        • Filter the result set according to the allowed populations
        • Check which Dimensions apply
        • Get users allowed values for the applicable dimensions
        • Filter the result set according to the dimension values.
      • If anything goes wrong return nothing.
      • A typical predicate…
        • ((SYS_CONTEXT(‘VPD_CONTEXT’, ‘LOCATION_FLAG’) = ‘ALL’)
        • OR
        • (SYS_CONTEXT(‘VPD_CONTEXT’, ‘LOCATION_FLAG’) = ‘NONE’)
        • AND tbl_vpd_empl_xref.empl_id <> tbl_vpd_empl_xref.empl_id) OR
        • (SYS_CONTEXT(‘VPD_CONTEXT’, ‘LOCATION_FLAG’) = ‘I’ AND LOCN_CTRY IN (select generic_id from tbl_dimension_values where user_profile_DIMENSION_ID = SYS_CONTEXT(‘VPD_CONTEXT’,‘LOCATION’)) OR (SYS_CONTEXT(‘VPD_CONTEXT’, ‘LOCATION_FLAG’) = ‘E’ AND LOCN_CTRY NOT IN (select generic_id from tbl_dimension_values where user_profile_DIMENSION_ID = SYS_CONTEXT(‘VPD_CONTEXT’,‘LOCATION’)))
    • RLS In-Depth
      • The preceding example can help you get started, but there is much more to RLS than this. The security policies can be much more complex, and the policy functions typically return dramatically different strings based on user authorizations.
      • DBMS_RLS Package
      • Syntax:
      • DBMS_RLS.ADD_POLICY (
        • object_schema IN VARCHAR2 NULL,
        • object_name IN VARCHAR2,
        • policy_name IN VARCHAR2,
        • function_schema IN VARCHAR2 NULL,
        • policy_function IN VARCHAR2,
        • statement_types IN VARCHAR2 NULL,
        • update_check IN BOOLEAN FALSE,
        • enable IN BOOLEAN TRUE,
        • static_policy IN BOOLEAN FALSE,
        • policy_type IN BINARY_INTEGER NULL,
        • long_predicate IN BOOLEAN FALSE,
        • sec_relevant_cols IN VARCHAR2,
        • sec_relevant_cols_opt IN BINARY_INTEGER NULL
        • )
      • New In 10g:
      • policy type, long_predicate,
      • sec_relevant_cols, and sec_relevant_cols_opt
      • Other DBMS_RLS Procedures (Not Covered in this presentation)
        • CREATE_POLICY_GROUP
        • ADD_GROUPED_POLICY
        • ADD_POLICY_CONTEXT
        • DELETE_POLICY_GROUP
        • DROP_GROUPED_POLICY
        • DROP_POLICY_CONTEXT
        • ENABLE_GROUPED_POLICY
        • DISABLE_GROUPED_POLICY
        • REFRESH_GROUPED_POLICY
    • RLS In-Depth ..(Cont)
      • The PL/SQL functions are registered to tables, views, or synonyms by invoking the DBMS_RLS.ADD_POLICY procedure. The DBMS_RLS package is not granted to everyone; administrators will require direct execute privileges on the package. The ADD_POLICY procedure requires, at minimum, the name of the object to which the policy will be applied, a name for the policy, and the name of a PL/SQL function that will implement the security policy.
      • Creating A Policy Function – e.g. CREATE OR REPLACE FUNCTION dept_only (
          • p_schema IN VARCHAR2 DEFAULT NULL,
          • p_object IN VARCHAR2 DEFAULT NULL)
          • RETURN VARCHAR2
          • AS
          • BEGIN
          • RETURN 'deptno = sys_context(''people_ctx'',''deptno'')';
          • END;
      • Applying the Insert/Update Policy – e.g. BEGIN
        • DBMS_RLS.add_policy
              • (object_schema => 'SCOTT',
              • object_name => 'PEOPLE',
              • policy_name => 'PEOPLE_IU',
              • function_schema => 'SEC_MGR',
              • policy_function => 'Dept_Only',
              • statement_types => 'INSERT,UPDATE',
              • update_check => TRUE);
              • END;
        • Hence
        • update people set ename = '<NEW_VALUE>' will be effectively transformed into
        • update people set ename = '<NEW_VALUE>' where deptno = sys_context('people_ctx','deptno')
    • RLS In-Depth ..(Cont)
      • Delete RLS Policy – The delete policy says that the user can only delete their record
              • e.g. CREATE OR REPLACE FUNCTION user_only (
              • p_schema IN VARCHAR2 DEFAULT NULL,
              • p_object IN VARCHAR2 DEFAULT NULL)
              • RETURN VARCHAR2
              • AS
              • BEGIN
              • RETURN 'username = sys_context(''userenv'',''session_user'')';
              • END;
        • Hence
        • DELETE FROM people; will be effectively transformed into
        • DELETE FROM people where username = sys_context(''userenv'',''session_user'')
      • Viewing the Original SQL and Predicate – The View you may find helpful in inspecting your VPD implementations is the V$VPD_POLICY view. This will tell you what policies have been successfully applied to your SQL statements. The PREDICATE column will actually show the SQL string that was appended to the query. You can join this record with V$SQL, which has the original SQL.
        • e.g. > SELECT object_owner,
        • object_name,
        • policy,
        • sql_fulltext,
        • predicate
        • FROM v$vpd_policy p, v$sql s
        • WHERE p.sql_id = s.sql_id
        • AND predicate IS NOT NULL;
        • OBJECT_OWNER OBJECT_NAME POLICY SQL_FULLTEXT PREDICATE
        • ------------ ------------ ------ -------------------------- ------------
        • SAURABH EMP DEBUG SELECT COUNT (*) FROM emp ename = user
        • PS: No records are recorded if the policy throws an error
    • Bypassing Security
      • RLS Exemption i.e. EXEMPT ACCESS POLICY –
      • 1. While the RLS provides wonderful security, it can be problematic when doing database administration tasks such as performing data backups. As you have seen, even the DBAs and the data owner cannot bypass the RLS policy. If you perform an export as the data owner or another administrator while an RLS policy was enabled, you may very well end up with a dataless backup file. For this reason (and a few others), there is an EXEMPT ACCESS POLICY privilege
              • e.g.
              • SQL>DELETE FROM scott.people_ro;
              • SQL> 0 rows deleted.
              • SQL> GRANT EXEMPT ACCESS POLICY TO SYSTEM;
              • SQL>Grant succeeded.
              • SQL>DELETE FROM scott.people_ro;
              • SQL>14 rows deleted.
      • 2. The system privilege EXEMPT ACCESS POLICY allows a user to be exempted from all fine-grained access control policies on any DML operation such as SELECT, INSERT, UPDATE, and DELETE. If a user is granted the EXEMPT ACCESS POLICY privilege, then the user is exempt from fine-grained access control enforcement. then the user is exempt from fine-grained access control enforcement.
      • e.g. grant exempt access policy to gtsup;
    • Implications of VPD for developers....
      • Adding new tables
        • Does it contain sensitive data ? should VPD be applied.
        • If yes, consider the analysis required to arrive at the predicates.
      • User Profile Issues
        • It is possible for a user to have multiple profiles within Access. These profiles will be provisioned differently and may or may not have access to Production instances.
          • eg. IT_Developer and IT_Support
          • How to switch between profiles ?
    • Summary
      • Virtual Private Database (VPD) helps resolve some of the challenges associated with views. An RLS policy is defined as a mapping from a PL/SQL implemented security function to a table, view, or synonym.
      • To ensure high performance, the RLS mechanism has been written to modify the SQL before it is parsed and executed. This allows the database to use indexes and optimization plans to ensure fast access to data. Using bind variables and application contexts and enabling policy caching can significantly improve RLS performance.
      • Project : Please check out a dummy project at : http://www.psoug.org/reference/fgac_demo.html