Articles
Identity & Security
The goal of this tutorial is to use Oracle Label Security to set up security based on label policies.
Approximately 30 minutes
This tutorial covers the following topics:
Place the cursor over this icon to load and view all the screenshots for this tutorial.
(Caution: This action loads all screenshots simultaneously, so response time may be slow depending on your Internet connection.)
Note: Alternatively, you can place the cursor over each individual icon in the following steps to load and view only the screenshot associated with that step.
Oracle Label Security makes separation of duty easy: When LBACSYS, the default Oracle-DBA for OLS, creates a policy, a role with the name " <policy_name>_DBA" is automatically granted to LBACSYS with the 'ADMIN' option, so that it can be granted to other users for them to complete and 'own the policy. In this tutorial, the users are called " sec_admin" and " HR_sec".
There are three parts to an access control policy:
| 1. |
The table containing the sensitive data ( LOCATIONS) and the owner of this data ( hr), who determines the sensitivity of his data and who will get access to which level of sensitivity. |
|
| 2. | The user-related part of the OLS policy is maintained by a user called HR_sec, who creates database users and roles and grants clearances to them. | |
| 3. | The Oracle Label Security labels (both for data and users), which enables the access mediation defined by the data owner, are created by sec_admin. Furthermore, this user is responsible for maintaining the performance of the application. | |
When the policy is tested and ready for production, LBACSYS revokes all necessary execution rights and roles from both " HR_sec" and " sec_admin".
Before you perform this tutorial, you should:
| 1. |
Perform the Installing Oracle Database 10g on Windows tutorial. |
|
| 2. |
Perform the Installing Oracle Label security tutorial. |
|
| 3. |
Download and unzip the ols.zip file into your working directory ( c:\wkdir). |
|
In this tutorial, you create a set of users and roles to demonstrate how OLS works. To create users and roles, perform the following steps:
| 1. |
Open a terminal window and execute the following commands:
cd \wkdir
sqlplus /nolog
@ols_create_admin_users_and_roles
set echo off
|
|
In this section, you will create a policy, grant the role to the admin users, creates the levels and labels for the policy. Perform the following:
| 1. |
LBACSYS creates a policy which will control access to the hr.LOCATIONS table; the name of the policy is ' ACCESS_LOCATIONS'; the name of the hidden column which will be appended to the hr.LOCATIONS table to hold the data labels is called ' OLS_COLUMN'. From a SQL*Plus session, execute the following script to create your policy.
@ols_create_policy
connect lbacsys/lbacsys
|
|
| 2. |
When the policy is created, an administration role for this policy is automatically granted to LBACSYS with the 'admin' option. In order to enable proper separation of duty, LBACSYS grants this role and some additional execution rights to the admin users ' HR_sec' and ' sec_admin'. From a SQL*Plus session, execute the following script:
@ols_grant_role
Prompt grant ACCESS_LOCATIONS_DBA to sec_admin and HR_sec:
|
|
| 3. |
The sec_admin user creates the levels for the policy. Each policy consists of levels (one or more), and optional compartments and groups, which are not included in this example. Execute the following script to create levels for your policy.
@ols_create_level
connect sec_admin/welcome1;
|
|
| 4. |
The sec_admin user also creates the labels (which only contain levels, no compartments or groups). Execute the following script:
@ols_create_label
connect sec_admin/welcome1;
execute SA_LABEL_ADMIN.CREATE_LABEL('ACCESS_LOCATIONS',1000,'PUB');
Prompt execute SA_LABEL_ADMIN.CREATE_LABEL('ACCESS_LOCATIONS',2000,'CONF')
execute SA_LABEL_ADMIN.CREATE_LABEL('ACCESS_LOCATIONS',2000,'CONF');
Prompt execute SA_LABEL_ADMIN.CREATE_LABEL('ACCESS_LOCATIONS',3000,'SENS')
execute SA_LABEL_ADMIN.CREATE_LABEL('ACCESS_LOCATIONS',3000,'SENS');
|
|
Later, data access rights will be limited by applying the labels you created earlier to the data. Before this, you need to authorize users and grant privileges to the policies, in order to define the matching access rights to these users. Perform the following:
| 1. |
The HR_sec user binds the labels to the users, defining their clearance. From a SQL*Plus session, execute the following script to create user label authorizations:
@ols_set_user_label
connect hr_sec/welcome1;
|
|
| 2. |
HR, the owner of the LOCATIONS table, needs FULL access to the table, since the user will later add the data labels into the hidden OLS_COLUMN defined earlier. From a SQL*Plus session, execute the following scrip:
@ols_set_user_privs
connect hr_sec/welcome1;
|
|
You can apply Oracle Label Security policies to entire application schemes or to individual application tables. You will apply it to the LOCATIONS table. Perform the following:
| 1. |
The sec_admin user applies the policy to the table. From now on, since READ_CONTROL has been set in the policy definition and no labels are added to the rows, no one can read the data (except HR). Execute the following script:
@ols_apply_policy
connect sec_admin/welcome1;
|
|
Before you can test the policy, you must add the label to the data by performing the following:
| 1. |
HR, the owner of the LOCATIONS table, adds the labels for each row into the hidden column ' OLS_COLUMNS'. In this case, you will assign the Sensitive label to the cities: Beijing, Tokyo and Singapore. You will assign the Confidential label to the cities: Munich, Oxford and Roma. And all other cities, you will assign the label Public.
@ols_add_label_column
connect hr/hr;
update locations
set OLS_COLUMN = char_to_label('ACCESS_LOCATIONS','SENS')
where upper(city) in ('BEIJING', 'TOKYO', 'SINGAPORE');
update locations
set OLS_COLUMN = char_to_label('ACCESS_LOCATIONS','CONF')
where upper(city) in ('MUNICH', 'OXFORD', 'ROMA');
update locations
set OLS_COLUMN = char_to_label('ACCESS_LOCATIONS','PUB')
where OLS_COLUMN is NULL;
|
|
To improve performance of data access, you can create a BITMAP INDEX on the OLS_COLUMN. Perform the following steps:
| 1. |
In order to increase performance, sec_admin creates a BITMAP INDEX on the OLS_COLUMN:
@ols_create_index
connect sec_admin/welcome1;
|
|
In order to limit access for all users to a certain range of IP addresses, SEC_ADMIN uses Oracle Policy Manager to add a WHERE clause to the policy. Perform the following steps:
| 1. |
From a DOS prompt, enter the following command:
oemapp opm
|
|
| 2. |
Login as the SEC_ADMIN user.
|
|
| 3. |
Navigate to the protected table and select the Predicate tab.
|
|
| 4. |
Check the box to make the text field editable and enter the following text and then click Apply.
sys_context ('userenv','ip_address') between '130.35.44.0' and '130.35.44.255'
|
|
| 5. |
Select File > Exit.
|
|
In order to secure the policy you need to revoke policy-specific execution rights and roles from sec_admin and HR_sec. Perform the following steps:
| 1. |
From your SQL*Plus session, execute the following script:
@ols_revoke_access
connect lbacsys/lbacsys;
|
|
After establishing policies to tables and users, and adding labels to the data, you can now test them by performing the following:
| 1. |
Execute the following script to test the access from the SKING user.
@ols_test_policy_sking
connect SKING/welcome1;
Note that the user SKING can see PUBLIC, CONFIDENTIAL and SENSITIVE data.
|
|
| 2. |
Now you can test the policy for the KPARTNER user by executing the following script:
@ols_test_policy_kpartner
connect kpartner/welcome1;
col city heading City format a25
col country_id heading Country format a11
col Label format a10
select city, country_id, label_to_char (OLS_COLUMN)
as Label from hr.locations order by ols_column;
Note that KPARTNER can see PUBLIC and CONFIDENTIAL data.
|
|
| 3. |
Now you can test the PRIVACY policy by executing the following script:
@ols_test_policy_ldoran
connect ldoran/welcome1;
col city heading City format a25
col country_id heading Country format a11
col Label format a10
select city, country_id, label_to_char (OLS_COLUMN)
as Label from hr.locations order by ols_column;
Note that LDORAN can only see PUBLIC data.
|
|
Now that you have tested your policies, you can drop the users and the policies by performing the following:
| 1. |
Execute the following script:
@ols_cleanup
Prompt ====================================================================
|
|
In this tutorial, you learned how to:
| |
Create a policy | |
| |
Set user authorizations | |
| |
Apply a policy to a table | |
| |
Add labels to the data | |
| |
Test the policy | |
Place your cursor on this icon to hide all screenshots.