Applied Oracle Security: Developing Secure Database and Middleware Environments- P21 pps

We categorized the credit limits as shown in the table: Credit Limit Category Credit Limit Range We can associate these OLS labels with the DBV identities we defined for the Connection_

Trang 1

CUST_LAST_ CUST_YEAR_OF_BIRTH CUST_MARIT CUST_INCOME_LEVEL

- - -

-Beiers

Duval

Greeley

Grover

Hamilton

Krider

Majors

Rowley

Stone

9 rows selected

This example demonstrated column-level security using DBV factors and VPD It is important to note that you can filter the records (row-level security) on the same table with the same approach

You can do this by omitting the sec_relevant_cols and sec_relevant_cols_opt parameters to the

DBMS_RLS.ADD_POLICY procedure call With this approach, MARY would not have been able

to see any records (no rows selected) when querying the SH.CUSTOMERS tables outside the corporate network.

DBV Factor Integration with OLS

DBV includes a feature that allows you to associate DBV identities with OLS labels When a specific DBV identity is asserted for a session, the OLS label associated with the identity will be merged with the maximum label that is assigned to the user The merge operation is controlled by

an OLS merge algorithm configured by the DBV security administrator The merge results in an effective OLS session label that cannot be “upgraded” by the user because of the integrated access control of DBV and OLS Even if the label assigned to the user exceeds the label of the DBV identity, the effective OLS label could be “downgraded” by the label of the DBV identity The OLS session label controls the records that a user can SELECT, INSERT, UPDATE, or DELETE when OLS labels are applied to data tables.

To illustrate this integration, suppose we have an OLS policy that defines labels with which

we will categorize customer data records (SH.CUSTOMERS) based on their credit limit We categorized the credit limits as shown in the table:

Credit Limit Category Credit Limit Range

We can associate these OLS labels with the DBV identities we defined for the Connection_ Type factor used in the preceding section to establish an effective session label for OLS based on the identity that is set by DBV We will prevent any session from accessing customer data records labeled as HIGH when the database session has come from outside the corporate network

(Connection_Type = ‘OTHER’) The following table summarizes the rules we will establish:

Trang 2

Connection_Type Identity Effective Session Label for OLS

The steps to achieve this type of integration are as follows:

1 Define the OLS policy’s components and labels.

2 Create a column for the OLS label to be stored, and label the data records that will

be protected.

3 Apply the OLS policy to the tables to be protected.

4 Assign an OLS label range to the users that require access to the data.

5 Enable the OLS policy within DBV and define the merge algorithm.

6 Define the DBV factors whose identities will be merged with the default OLS session

label for a user.

7 Associate OLS labels from the policy to each DBV identity.

We can implement an OLS policy for our example by simply defining three OLS level components and three OLS labels using the LBACSYS account The LBACSYS account is the object-owner account for the OLS option.

lbacsys@aos> first create the OLS policy with the

lbacsys@aos> name of the column to store the label

lbacsys@aos> in and the default access control options

lbacsys@aos> BEGIN

sa_sysdba.create_policy(

policy_name => 'CUSTOMER_POLICY'

, column_name => 'CUSTOMER_LABEL'

, default_options =>'READ_CONTROL,WRITE_CONTROL,CHECK_CONTROL'

);

END;

/

PL/SQL procedure successfully completed

lbacsys@aos> create the OLS levels for the

lbacsys@aos> customer policy

lbacsys@aos> BEGIN

customers with a low credit limit

sa_components.create_level(

policy_name=> 'CUSTOMER_POLICY'

, level_num => 10

, short_name => 'LOW'

, long_name => 'LOW CREDIT LIMIT'

);

Trang 3

customers with a moderate credit limit

, level_num => 20

, short_name => 'MODERATE'

, long_name => 'MODERATE CREDIT LIMIT'

);

customers with a high credit limit

, level_num => 30

, short_name => 'HIGH'

, long_name => 'HIGH CREDIT LIMIT'

);

END;

/

lbacsys@aos> create the OLS labels for the

lbacsys@aos> customer policy

lbacsys@aos> BEGIN

customers with a low credit limit

sa_label_admin.create_label(

, label_tag => 10

, label_value => 'LOW'

);

customers with a moderate credit limit

, label_tag => 20

, label_value => 'MODERATE'

);

customers with a high credit limit

, label_tag => 30

, label_value => 'HIGH'

);

END;

/

Note that OLS compartment and group components work with the DBV/OLS integration, but this example will simply use OLS level components We can now create a column named CUSTOMER_LABEL in the SH_CUSTOMERS table This column name was specified in the call to SA_SYSDBA.CREATE_POLICY earlier This column will hold the OLS label number for each data record and is a requirement for OLS The label numbers were defined in the calls to SA_LABEL_ ADMIN.CREATE_LABEL We will first remove the VPD policy on SH.CUSTOMERS table that we had created in the preceding example, then add the new label column, and then populate the data records with the appropriate label number Note that Oracle supports the condition in which multiple VPD and OLS policies exist and interoperate on a single table We are simply removing

Trang 4

the example here to clarify that a single access control policy is active The DBV realm

administrator, MARY, of the Sales History realm can perform these steps.

mary@aos> remove the VPD example from the previous example

mary@aos> BEGIN

dbms_rls.drop_policy(

object_schema => 'SH'

,object_name => 'CUSTOMERS'

,policy_name => 'POLICY_CUSTOMERS'

);

END;

/

mary@aos> add the column to the customer table

mary@aos> to hold the OLS security label

mary@aos> ALTER TABLE sh.customers ADD customer_label NUMBER;

Table altered

mary@aos> populate the customer_label column with the appropriate

mary@aos> data label for LOW credit limit customers

mary@aos> UPDATE sh.customers SET customer_label = 10

WHERE cust_credit_limit < 5000;

19309 rows updated

mary@aos> data label for MODERATE credit limit customers

WHERE cust_credit_limit BETWEEN 5000 AND 9999;

25451 rows updated

mary@aos> data label for HIGH credit limit customers

WHERE cust_credit_limit >= 10000;

10740 rows updated

mary@aos> save the data changes

mary@aos>COMMIT;

Commit complete

The next step is to use the LBACSYS account to apply our OLS policy to the SH.CUSTOMERS This will provide the label-based access control protection on the table for any subsequent SELECT, INSERT, UPDATE, or DELETE transactions on the table To perform this step, we must consider that OLS places Oracle database triggers on tables that are being protected These triggers are used to ensure that labels for new data records are provided and will perform auditing for OLS operations on the protected tables The SH.CUSTOMERS table is protected by the Sales History realm that will obviously prevent these CREATE TRIGGER statements from completing

Trang 5

successfully The best approach to handling this is to authorize the LBACSYS account in the Sales History realm as a participant rather than disabling the realm altogether.

dbvowner@aos> authorize LBACSYS in the Sales History realm

dbvowner@aos> BEGIN

dbms_macadm.add_auth_to_realm (

realm_name =>'Sales History'

, grantee => 'LBACSYS'

, rule_set_name => NULL

, auth_options => dbms_macutl.g_realm_auth_participant );

END;

/

dbvowner@aos>connect lbacsys

Enter password:

Connected

lbacsys@aos> apply the OLS policy to the customer

lbacsys@aos> table with the table-specific

lbacsys@aos> access control options

lbacsys@aos> BEGIN

sa_policy_admin.apply_table_policy(

, schema_name => 'SH'

, table_name => 'CUSTOMERS'

, table_options => 'READ_CONTROL,WRITE_CONTROL,CHECK_CONTROL'

);

END;

/

At this point in the configuration, the DBV Sales History realm administrator, MARY, cannot query data in the SH.CUSTOMERS table.

mary@aos> SELECT

cust_last_name

, cust_year_of_birth

, cust_marital_status

, cust_income_level

FROM sh.customers

WHERE cust_state_province = 'TX'

AND ROWNUM < 1

ORDER BY cust_last_name

/

no rows selected

We have to assign MARY a label range in the OLS policy using the LBACSYS account We want to provide MARY full access to all records in the SH.CUSTOMERS table so the range that will be assigned to her will be LOW–HIGH.

assign the labels ranges of data

Trang 6

sa_user_admin.set_user_labels(

, user_name => 'MARY'

, min_write_label => 'LOW'

, max_read_label => 'HIGH'

, max_write_label => 'HIGH'

, def_label => 'HIGH'

, row_label => 'HIGH'

);

END;

/

As a result of this label range assignment, MARY can now access the records in the

SH.CUSTOMERS table.

mary@aos> query the SH.CUSTOMERS table

mary@aos> SELECT

cust_last_name

, cust_year_of_birth

, cust_marital_status

, cust_income_level

FROM sh.customers

WHERE cust_state_province = 'TX'

AND ROWNUM < 10

ORDER BY cust_last_name

/

CUST_LAST_ CUST_YEAR_OF_BIRTH CUST_MARIT CUST_INCOME_LEVEL

- - -

-Beiers 1982 single K: 250,000 - 299,999

Duval 1981 single H: 150,000 - 169,999

Greeley 1977 F: 110,000 - 129,999

Grover 1970 married D: 70,000 - 89,999

Hamilton 1961 single G: 130,000 - 149,999

Krider 1967 F: 110,000 - 129,999

Majors 1948 single G: 130,000 - 149,999

Rowley 1969 single H: 150,000 - 169,999

Stone 1978 single I: 170,000 - 189,999

9 rows selected

Having defined the OLS policy for the table, we want to protect and authorize the named users in this OLS policy, and we can remove the realm authorization for the LBACSYS account in the Sales History realm We can also identify this OLS policy as being integrated with DBV using the PL/SQL procedure DBMS_MACADM.CREATE_MAC_POLICY.

dbvowner@aos> remove the realm authorization for LBACSYS

dbvowner@aos> as we've applied the policy on the table

dbvowner@aos> BEGIN

dbms_macadm.delete_auth_from_realm (

realm_name =>'Sales History'

, grantee => 'LBACSYS'

Trang 7

/

dbvowner@aos> enable the OLS policy within DBV and

dbvowner@aos> define the merge algorithm

BEGIN

dbms_macadm.create_mac_policy(

, algorithm => 'LII'

);

END;

/

The algorithm LII means “Least upper-bound of all levels, Intersection of compartments, Intersection of groups.” This algorithm is the most appropriate and most commonly used

algorithm in commercial and government systems This algorithm and others are available with OLS and are described in the “Label Security Administrator’s Guide” should you need to research them for your application’s needs In our example, this algorithm basically means that the merging of the label LOW with a label of HIGH will result in LOW, or the least upper-bound of the levels We now need to configure DBV with the name(s) of the DBV factor(s) whose identities will be merged with the default OLS session label for a user using this algorithm Here we are simply using one factor, Connection_Type, and will use the PL/SQL procedure DBMS_MACADM ADD_POLICY_FACTOR to accomplish this.

dbvowner@aos> BEGIN

dbms_macadm.add_policy_factor(

, factor_name => 'Connection_Type'

);

END;

/

Note that the DBV integration with OLS does in fact support the merging of multiple factors with OLS The final step in our configuration is to associate an OLS label from the policy to each DBV identity for the DBV factor Connection_Type This can be accomplished using the PL/SQL procedure DBMS_MACADM.CREATE_POLICY_LABEL:

dbvowner@aos> we will assign the LOCAL_DBA identity

dbvowner@aos> an OLS label of HIGH

dbvowner@aos> BEGIN

dbms_macadm.CREATE_POLICY_LABEL(

identity_factor_name => 'Connection_Type'

, identity_factor_value => 'LOCAL_DBA'

, policy_name => 'CUSTOMER_POLICY'

, label => 'HIGH'

);

END;

/

Trang 8

dbvowner@aos> we will assign the CORPORATE_SSL identity

dbvowner@aos> BEGIN

, identity_factor_value => 'CORPORATE_SSL'

, label => 'HIGH'

);

END;

/

dbvowner@aos> we will assign the CORPORATE_PASSWORD identity

dbvowner@aos> BEGIN

, identity_factor_value => 'CORPORATE_PASSWORD'

, label => 'HIGH'

);

END;

/

dbvowner@aos> we will assign the OTHER identity

dbvowner@aos> an OLS label of LOW

dbvowner@aos> BEGIN

, identity_factor_value => 'OTHER'

, label => 'LOW'

);

END;

/

dbvowner@aos> COMMIT;

Commit complete

We now want to examine how our policy behaves using the scenario in which MARY is querying the SH.CUSTOMERS table from within the corporate network In this scenario, we expect MARY to be able to see all customers no matter what their credit limit In addition, we expect the effective OLS session label to be the maximum label MARY is authorized to see—HIGH.

mary@aos> show the Connection_Type factor and session context

mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type

, DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method

, DVSYS.GET_FACTOR('Client_IP') Client_IP

Trang 9

CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP

-CORPORATE_PASSWORD PASSWORD 192.168.0.200

1 row selected

mary@aos> query MARY's OLS authorization and

mary@aos> the effective OLS session label

mary@aos> SELECT sa_session.label('CUSTOMER_POLICY')

"EFFECTIVE_SESSION_LABEL"

FROM DUAL;

EFFECTIVE_SESSION_LABEL

-HIGH

1 row selected

mary@aos> SELECT

cust_credit_limit

, count(*)

FROM sh.customers

GROUP BY cust_credit_limit

ORDER BY cust_credit_limit

/

CUST_CREDIT_LIMIT COUNT(*)

-

1500 11334

3000 7975

5000 7724

7000 8634

9000 9093

10000 5935

11000 2935

15000 1870

8 rows selected

Next we want to examine how our policy behaves when MARY is querying the SH.CUSTOMERS table from outside the corporate network In this scenario, we expect MARY to be able to see only customers with a credit limit of LOW In addition, we expect the effective OLS session label to be the maximum label MARY is authorized to see—LOW.

FROM DUAL;

-OTHER PASSWORD 10.10.10.10

Trang 10

1 row selected.

mary@aos> query MARY's OLS authorization and

mary@aos> the effective OLS session label

mary@aos> SELECT sa_session.label('CUSTOMER_POLICY')

"EFFECTIVE_SESSION_LABEL"

FROM DUAL;

EFFECTIVE_SESSION_LABEL

-LOW

1 row selected

mary@aos> SELECT

cust_credit_limit

, count(*)

FROM sh.customers

GROUP BY cust_credit_limit

ORDER BY cust_credit_limit

/

CUST_CREDIT_LIMIT COUNT(*)

-

1500 11334

3000 7975

2 rows selected

As you can see, even though MARY is in fact authorized to see data records labeled as HIGH and MODERATE, when she connects to the database from outside the corporate network, the integration of this OLS policy with DBV factors prevents this access This integration allows us

to mediate row-level access controls policies such as OLS with environmental factors such as the network path a client used to connect to the database, the method of authentication, or both This integration capability truly is multifactored security.

When we started our discussion on the DBV and OLS integration, we made the assertion that the effective OLS session label established by this integration could not be “upgraded” by the user

We can demonstrate this by attempting to set the session label to the maximum label the user is authorized to see using the OLS PL/SQL procedure SA_SESSION.SET_LABEL within the context

of the session MARY established outside of the corporate network:

FROM DUAL;

-OTHER PASSWORD 10.10.10.10

1 row selected

Định dạng
Số trang	10
Dung lượng	136,53 KB