Oracle security 05-using fine-grained access control

云和恩墨成就所托 by 王朝阳 18516271611 sonne.k.wang@gmail.com
Using Fine-Grained Access Control

Objectives
After completing this lesson, you should be able to do
the following:
• Describe how fine-grained access control (FGAC)
and the Virtual Private Database (VPD) work
• Implement FGAC or the VPD
• Group policies

Fine-Grained Access Control: Overview
• Limits row access
• Uses a predicate
• Is returned from a
function
• Is associated with a
table or view
• Is automatically
enforced
SELECT * FROM orders
WHERE sales_rep_id = 406;
ORDERS
SELECT * FROM orders;
SELECT * FROM orders
WHERE sales_rep_id = 152;
SELECT * FROM orders;

Benefits
• Security: FGAC is always applied.
• Simplicity:
– Define once
– Independent of application
• Flexibility:
– Apply different access to different SQL statements.
– Group policies.
• High performance:
– Static and dynamic policies
– Active policies stored in memory

Virtual Private Database
A Virtual Private Database (VPD) combines an
application context and FGAC to:
• Enforce business rules to limit row access
• Use a secure application context to provide high
performance resolution of user attributes.

Examples of the Virtual Private Database
The VPD allows multiple policies on the same table:
• Customer example:
– Context attribute: cust_id
– Predicate: customer_id =
sys_context ('oeapp', 'cust_id')
• Sales representative example:
– Context attribute: emp_id
– Predicate: sales_rep_id =
sys_context ('oeapp', 'emp_id')

How Fine-Grained Access Control Works
1. The user accesses a table or view with a policy.
2. The database calls the policy function.
3. The policy function returns a predicate.
4. The database adds the predicate to the statement.
5. The data server executes the modified statement.
becomes
SELECT *
FROM orders
WHERE customer_id =
sys_context
('oeapp', 'cust_id');
SELECT *
FROM orders;

Tools
• The PL/SQL procedures and packages, such as:
– SYS_CONTEXT returns context attributes
– DBMS_SESSION manages:
- Contexts
- Global identifiers
– DBMS_RLS manages:
- Contexts
- Policies
- Policy groups
• Oracle Policy Manager is a GUI that:
– Uses DBMS_RLS
– Provides security policy administration
– Manages the VPD and Oracle Label Security

Oracle Policy Manager

DBMS_RLS
• Associate policies with tables or views:
– ADD_POLICY
– ADD_GROUPED_POLICY
• Enable and disable policies:
– ENABLE_POLICY
– ENABLE_GROUPED_POLICY
• Refresh policies:
– REFRESH_POLICY
• Group policies:
– CREATE_POLICY_GROUP
• Manage driving contexts:
– ADD_POLICY_CONTEXT
– DROP_POLICY
– DROP_GROUPED_POLICY
– DISABLE_GROUPED_POLICY
– REFRESH_GROUPED_POLICY
– DELETE_POLICY_GROUP
– DROP_POLICY_CONTEXT

Column-Level VPD
• Statements are not always rewritten.
• Example: A policy protects the SALARY and the
COMMISSION_PCT columns of the EMPLOYEES table.
The FGAC is:
– Not enforced for this query:
– Enforced for these queries:
SQL> SELECT last_name, salary
2 FROM employees;
SQL> SELECT last_name FROM employees;
SQL> SELECT * FROM employees;

Column-Level VPD: Example
BEGIN
dbms_rls.add_policy(object_schema => 'hr',
object_name => 'employees',
policy_name => 'hr_policy',
function_schema =>'hr',
policy_function => 'hrsec',
statement_types =>'select,insert',
sec_relevant_cols=>'salary,commission_pct'
sec_relevant_col_opts=> dbms_rls.ALL_ROWS);
END;
/

Policy Types: Overview
The policy types specify how often a policy function
should be reevaluated. The types are:
• Dynamic
– DBMS_RLS.DYNAMIC (Default)
• Static
– DBMS_RLS.STATIC
– DBMS_RLS.SHARED_STATIC
• Context sensitive
– DBMS_RLS.CONTEXT_SENSITIVE
– DBMS_RLS.SHARED_CONTEXT_SENSITIVE
• Shared: Shared policies allow you to share the
same policy function with different objects

Static Policies
• The policy function is evaluated once.
• The resulting policy predicate is cached in
memory.
• Every statement accessing protected objects uses
the same policy predicate.
exec dbms_rls.add_policy(
object_schema =>'hr', object_name => 'employees', -
policy_name => 'hr_policy' , -
function_schema =>'hr',policy_function=>'hrsec' , -
statement_types => 'select,insert' , -
policy_type => dbms_rls.static , -
sec_relevant_cols =>'salary,commission_pct');

Context-Sensitive Policies
• The policy function is evaluated for each session
when:
– The statement is first parsed
– There is a related change in the local application
context
• The resulting policy predicate is cached in the
user’s session memory.
exec dbms_rls.add_policy(
object_schema =>'hr', object_name =>'employees2', -
policy_name => 'hr_policy2' , -
function_schema =>'hr',policy_function=>'hrsec2', -
statement_types => 'select,insert' , -
policy_type => dbms_rls.context_sensitive , -
sec_relevant_cols =>'salary,commission_pct');

Sharing Policy Functions
departments
countries
emp_v
employees
Same policy
function

Exceptions to FGAC Policies
Policies are not enforced for:
• DIRECT path export
• Users with DBA privileges ( AS SYSDBA )
• Users granted EXEMPT_ACCESS_POLICY

Implementing a VPD
1. Create a PL/SQL package that sets the context.
2. Create an application context:
– Is associated with the package created in step 1
– Prevents the context from being changed
3. Write the function that creates a predicate:
– Use the application context created in step 2.
– Return a predicate for a WHERE clause.
4. Create a policy:
– Associates the function with a table
– Causes the predicate to be added to the WHERE
clauses

Step 3: Write the Function That
Creates a Predicate
CREATE PACKAGE BODY oe_security AS
FUNCTION cust_order (
object_schema VARCHAR2,
object_name VARCHAR2 )
RETURN VARCHAR2
IS
BEGIN
RETURN 'customer_id =
sys_context(''oeapp'', ''cust_id'')';
END cust_order;
END oe_security;

Testing the Security Function
SQL> SELECT oe_security.cust_order('a', 'b')
FROM dual;
OE_SECURITY.CUST_ORDER('A','B')
---------------------------------------------
customer_id = SYS_CONTEXT('oeapp', 'cust_id')

Writing a Function That Returns
Different Predicates
• The owner of the table has access to all rows:
• Sales representatives see only their orders:
• Customers can see only their own orders:
• Other users have no access:
RETURN 'sales_rep_id =
sys_context(''hrapp'', ''emp_id'')';
RETURN 'customer_id
= sys_context(''oeapp'', ''cust_id'')';
RETURN '1=2';
RETURN '1=1';

Step 4: Create a Policy
• Create the policy as follows:
• Arguments include the following:
– Associated table: OE.ORDERS
– Policy name: OE_POLICY
– Function: SECURE.OE_SECURITY.CUST_ORDER
– Applies to: SELECT
dbms_rls.add_policy (
object_schema =>'oe', object_name => 'orders',
policy_name => 'oe_policy',
function_schema =>'secure',
policy_function =>'oe_security.cust_order',
statement_types =>'select')

Partitioned Fine-Grained Access Control
• Application-driven
security policies
• Different policies apply,
depending on the
active driving context
• Policies can be
developed
independently.
• The default policy
always applies.
Default policy
Order-entry
policy group
Inventory
policy group
AN
D
AN
D
Orders

Grouping Policies
1. Determine the default policies.
2. Set up a driving context for each table:
a. Create the context.
b. Create the function that sets the context.
c. Make the context the driving context.
3. Create a policy group for each application.
4. Add each policy to the appropriate group.

Default Policy Group
• A predefined default policy group is always
applied.
• It is named SYS_DEFAULT.
• Each object has a default group.

Creating a Driving Context
• Create the context:
• Create the procedure that sets the context:
CREATE CONTEXT app_driver
USING oe.pkg_apps_cxt;
CREATE OR REPLACE PACKAGE BODY oe.pkg_apps_cxt
PROCEDURE set_driver( policy_group VARCHAR2)...
APP_ DRIVER
OE.PKG_APPS_CXT

Making the Context a Driving Context
Associate the driving context with a table:
dbms_rls.add_policy_context(
object_schema =>'OE',
object_name => 'ORDERS' ,
namespace => 'APP_DRIVER',
attribute => 'ACTIVE_APP')
APP_ DRIVER Orders

Creating a Policy Group
• Create the OE group:
• Create the AC group:
dbms_rls.create_policy_group(
object_schema =>'OE',
object_name => 'ORDERS',
policy_group => 'OE_GRP' );
dbms_rls.create_policy_group
( 'OE', 'ORDERS', 'AC_GRP' );

Adding a Policy to a Group
1. Add the OE_SECURITY policy to the OE group:
2. Add the AC_SECURITY policy to the AC group:
dbms_rls.add_grouped_policy (
object_schema=>'oe', object_name=>'orders',
policy_group =>'oe_grp',
policy_name => 'oe_security',
function_schema =>'secure',
policy_function => 'oe_context');
dbms_rls.add_grouped_policy (
'oe', 'orders', 'ac_grp', 'ac_security',
'secure', 'ac_context');

Performance
For best performance:
• Consider indexing the column in the predicate
• Do not use subqueries in the predicate
• Do not use literals in the predicate
• Use STATIC_POLICY=TRUE when possible
• Use DBMS_RLS.STATIC_POLICY or
SHARED_STATIC_POLICY when possible

Export and Import
• For export and import, consider the following
guidelines:
– To restore the policies, the user must have the
execute privilege on the DBMS_RLS package.
– If a user attempts to export a table with fine-grained
access policies enabled, then only those rows that
the exporter is privileged to read are exported.
– Only SYS or a user with the
EXPORT_FULL_DATABASE role enabled can perform
DIRECT path export.

Policy Views
• Policy views list security policies: *_POLICIES
• Policy context views list driving contexts:
*_POLICY_CONTEXTS
• Policy group views list policy groups:
*_POLICY_GROUPS
• Dynamic performance views list active policies:
– V$VPD_POLICY
– GV$VPD_POLICY

Checking for Policies Applied
to SQL Statements
SQL> SELECT distinct policy, predicate, sql_text
2 FROM v$vpd_policy p, v$sql s
3 WHERE s.child_address = p.address;
POLICY PREDICATE
------------ ---------------------------------------
SQL_TEXT
--------------------------------------------------------
OE_POLICY 1=1
select * from oe.orders
OE_POLICY sales_rep_id = SYS_CONTEXT('hrapp', 'id')
select * from oe.orders

Summary
In this lesson, you should have learned how to:
• Describe how FGAC and the VPD work
• Implement FGAC or the VPD by using the
DBMS_RLS package
• Group policies:
– Using the DBMS_RLS package to group policies
– Setting up a driving application context by using
DBMS_RLS

Q&A

Oracle security 05-using fine-grained access control

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de Zhaoyang Wang

Mais de Zhaoyang Wang (20)

Último

Último (20)

Oracle security 05-using fine-grained access control