You are on page 1of 6

Technology Security: Now Securing Every Row

(Sign In/Register for Account | Subscribe)

Database Middleware Developer Tools Enterprise Management Applications Technology Products A-Z






E-mail this page


Printer View

Technology SECURITY

As Published In

Now Securing Every Row
By Darl Kuhn and Steve Roughton Oracle Label Security controls user access by row. July/August 2003 Most business applications must deal with security issues. Applications often need to restrict access to private records, establish audit trails, or enforce a workflow process, all in compliance with corporate security policies. Building secure software is challenging and complex; administering software security policies across an entire organization can be even more difficult. As a schema designer, you might begin by adding security columns to tables and creating user-specific views against those tables. As a DBA, you'd probably create roles and privileges to protect database objects. And as a developer, you might write PL/SQL packages to encapsulate secure transactions inside the application. These are all valid techniques, but even these methods have certain weaknesses. For example, someone might accidentally export private data to a personal schema, legacy applications might be incompatible with your security objects, or users might use SQL*Plus to bypass application security entirely. Oracle9i Database has a component that can help solve such problems: Oracle Label Security. First introduced in Oracle8i Release 3 (8.1.7), Oracle Label Security is a straightforward tool that enables you to establish and enforce your business security policies. Oracle Label Security is a set of procedures and constraints built into the database engine that enforces row-level access controls on a single table or an entire schema. To use Oracle Label Security, you create one or more security policies, each of which contains a set of labels. You use labels to designate which users have access to what types of data. After creating a policy, you apply the policy to the tables that require protection and grant the labels to your users, and you're done. Oracle Label Security modifies queries transparently and computes access levels on the fly to enforce your new policies. As Oracle9i Database parses each SQL statement, it detects whether any of the tables are protected by a security policy. Depending on the user's access permissions, Oracle9i Database adds security predicates to the statement's WHERE clause. Because this happens inside the database engine, the security mechanism cannot be bypassed, regardless of the source of the SQL statement.

BI & Data Warehousing Embedded Java Linux .NET PHP Security Technologies A-Z

Enterprise 2.0 Grid Service-Oriented Architecture Virtualization

Join OTN Oracle ACEs Oracle Mix Oracle Wiki Blogs Podcasts Events Newsletters Oracle Magazine Oracle Books Certification User Groups Partner White Papers

How Does It Work?
Here's a very simple example to illustrate how Oracle Label Security works. We created and populated a table called documents with four records and defined two security levels: PUBLIC and INTERNAL. Each level also has a numeric value: 1000 or 2000. We then assigned a level to every row in the table. The following shows a simple SELECT on the table: SQL> SELECT * FROM documents; DOCID ----1 2 3 4 DOCNAME ----------SHARE_WARE WEST_PAYROLL EAST_SALES COMP_PAYROLL LEVEL -------PUBLIC INTERNAL INTERNAL INTERNAL DOC_LABEL --------1000 2000 2000 2000

Now let's say we have two users in our database: EMP and MGR. We assign access levels to these users as follows: EMP is assigned PUBLIC read-only. MGR is assigned PUBLIC and INTERNAL read/write. When these users access the table, EMP can read only row 1, whereas MGR has full read/write access to all four rows. What happens internally when these users access the documents table? Suppose the EMP user runs this query: SELECT * FROM documents; Oracle9i Database parses the query and determines that the table is under label security. Oracle Label Security adds a WHERE clause to the query to ensure that EMP sees only rows tagged with PUBLIC access: SELECT * FROM documents WHERE doc_label = 1000; Here's what the EMP user sees after running the query: DOCID ----1 DOCNAME ---------SHARE_WARE LEVEL -----PUBLIC DOC_LABEL --------1000

You might be wondering: "Why not create a view that restricts access, based on some column value?" In fact, if your application requires only a few levels and there are no special security requirements to consider, then adding a security column to your table and using views is adequate. But suppose your system requirements change and you now need to manage several hierarchies of users across multiple organizations, with customized read/write permissions on changing sets of data. In addition, the organizations are in different countries, each with its own laws and security restrictions. These requirements are more difficult to implement if you're just using views. Fortunately, Oracle Label Security is designed to scale; therefore implementing this type of application security is easier than you

1 de 5

05/06/2009 11:04

You will notice a new LBACSYS user. To view the levels you have created.sql script does a SHUTDOWN IMMEDIATE of your database as its last step. 2. is the name of the policy. A policy is the bucket that holds all of your security rules and access requirements. 2000. The row-level data labels and the schema access to the rows are always associated with a policy.sql as follows: SQL> CONN sys/password AS SYSDBA. To verify that your policy was created. Select and install the Oracle Label Security option. 4.enable_policy ('DOC_POLICY'). In this example. In this example. This user will administer your security policies. 6. Install Oracle Label Security (once per database) Create security policy Define levels Define compartments (optional) Define groups (optional) Create labels Apply label policy to table Assign user labels Assign normal grant-level access Assign appropriate labels to table rows When working with Oracle Label Security. you can use Oracle Enterprise Manager's Policy Manager GUI or the Oracle Label Security PL/SQL packages. 'Internal Level').'DOC_LABEL'). Launch the Universal Installer. you have a business need to define row-level access to company documents. As SYS. 9. run $ORACLE_HOME/rdbms/ admin/catols. 3.html might expect. 7. SQL> EXEC sa_components. and a long name. 4.create_policy ('DOC_POLICY'. SQL> EXEC sa_sysdba. 'INTERNAL'. The numeric ID denotes the level of sensitivity higher numbers mean greater sensitivity.Technology Security: Now Securing Every Row http://www. POLICY_NAME ----------DOC_POLICY STATUS ------ENABLED To disable. 1000. Step 3: Define levels Every security policy must contain levels that specify different grades of access to the table. 8. In this step. we'll use the PL/SQL execute the following: SQL> SELECT * FROM dba_sa_levels 2 de 5 05/06/2009 11:04 . DOC_LABEL. is the name of the column that Oracle Label Security will add to the table you'll be placing under label control. you create two levels of sensitivity: PUBLIC and INTERNAL. 5. In this Installation consists of four steps: 1. use the following procedure: SQL> EXEC sa_sysdba. To create a policy. The same concepts apply to either technique. you create a policy named DOC_POLICY. 10. status from DBA_SA_POLICIES. 2.drop_policy ('DOC_POLICY'). A Hands-On Example Implementing Oracle Label Security consists of the following 10 steps: 1. 'Public Level'). or drop a policy. The default password is LBACSYS (so be sure to change this password). In our example implementation. SQL> @?/rdbms/admin/catols Note: The catols. SQL> EXEC sa_sysdba. and the second parameter.create_level ('DOC_POLICY'. which contains all of the Oracle Label Security objects. connect as LBACSYS and use the sa_sysdb. The first parameter.disable_policy ('DOC_POLICY'). 3. DOC_POLICY. SQL> EXEC sa_components. Each level has a policy name. reenable. Restart your instance and run SQL> SELECT username FROM dba_users. Step 1: Install Oracle Label Security You will need to install Oracle Label Security only once per database. INTERNAL is more sensitive than PUBLIC.create_policy procedure: SQL> CONN lbacsys/lbacsys SQL> EXEC sa_sysdba. a short name. query DBA_SA_POLICIES as follows: SQL> SELECT policy_name. Step 2: Create a security policy The next task is creating a security policy.create_level ('DOC_POLICY'. 'PUBLIC'. a numeric ID.

Every label must contain one level and. SQL> EXEC sa_label_admin. a short name. To see information about your compartments. schema_name => 'APP' . table_options => 'LABEL_DEFAULT. 'WEST_REGION'. 10.WRITE_CONTROL'). ALL_REGIONS is the parent and WEST_REGION and EAST_REGION are children of ALL_REGIONS.create_group ('DOC_POLICY'. TRUE).com/technology/oramag/oracle/03-jul/o43security. 200. When you create a label.create_group ('DOC_POLICY'. In this example. To view information about your groups. 'FIN'. That label would look like this: INTERNAL:FIN Create four labels to satisfy the requirements as follows: SQL> EXEC sa_label_admin.create_label ('DOC_POLICY'. compartment_n : group. Step 4: Define compartments (optional) Compartments let you refine access to a row of data within a level. If you specify more than one compartment or group.create_compartment ('DOC_POLICY'. and a long name.create_label ('DOC_POLICY'. 'INTERNAL:HR. The column name is what you defined in Step 2. Step 7: Apply the label policy to the table To place the table under label security. '30900'. a short name. 'INTERNAL:HR:WEST'. as in a company organization chart. table_name => 'DOCUMENTS' . it is used only for ordering when displaying group information. 'PUBLIC'. TRUE). and groups and follow this syntax: level : TRUE). 'FINANCE').documents 3 de 5 05/06/2009 11:04 . In this example. when you created the security policy.create_label ('DOC_POLICY'. To view label information.. SQL> EXEC sa_components. 'HR'. The number does not imply any sensitivity. as follows: SQL> DESC app. 'WEST'. you might have users in the finance department who have access only to internal documents. If you describe the documents table. '20400'. Groups are useful when you have hierarchies of users. When you create a group. you must assign it a number. SQL> EXEC sa_label_admin. '10000'. This number must be unique across all the policies in your database. . compartments.. you have documents with the same level of sensitivity. SQL> EXEC sa_components.FIN:ALL'.Technology Security: Now Securing Every Row http://www. 'EAST'. Oracle9i Database adds a column named DOC_LABEL to the documents table. and groups must be delimited by colons. and a long name. Like compartments. SQL> EXEC sa_components. you must define a hierarchy. . compartments and/or groups. Step 6: Create labels A label is a combination of levels. SQL> EXEC sa_label_admin. you will see the new DOC_LABELcolumn. Step 5: Define groups (optional) As with compartments. compartments. but certain departments can see only subsets of these levels. compartments.. group_n The level.apply_table_policy ( policy_name => 'DOC_POLICY' . The label allows you to snap together different types of access required for various users of the data. SQL> EXEC sa_components. SQL> EXEC sa_policy_admin. TRUE). 'ALL'). The numeric ID for a compartment does not specify its level of sensitivity. query the DBA_SA_GROUPS view. using groups is another optional method for restricting access within a level. 20. 'ALL'). 100. a numeric ID. In the following procedure. 'HUMAN_RESOURCE'). you apply DOC_POLICY to the DOCUMENTS table owned by user APP. '20200'.html ORDER BY level_num. assign the label policy to the table. 'ALL_REGIONS'). 'ALL'. and groups. those must be delimited by commas. 30. For example. Here you create FINANCE and HUMAN_RESOURCE compartments: SQL> EXEC sa_components. query the DBA_SA_COMPARTMENTS view. query the DBA_SA_LABELS view. Labels are a combination of the short names of levels. optionally. 'EAST_REGION'. It is used only to order compartments when displaying access information.create_label ('DOC_POLICY'. When you run this procedure. READ_CONTROL.create_compartment ('DOC_POLICY'. Oracle Label Security will control the read/write access to this table. groups have a numeric ID. 'INTERNAL:FIN:EAST'. Compartments have a policy name.create_group ('DOC_POLICY'.

com/technology/oramag/oracle/03-jul/o43security. 'WEST_PAYROLL'. You can either load the label with its numeric form or. as follows: SQL> CONN mgr/mr_bigg SQL> INSERT INTO app. note that you can manipulate data only as dictated by your security policy and CRUD access: SQL> CONN mgr/mr_bigg SQL> SELECT docname.documents.documents VALUES (4. 'COMP_PAYROLL'. With label security enabled on a table. Alternatively. even the table owner will not be able to read or write without proper label privileges.Technology Security: Now Securing Every Row http://www. Step 10: Assign appropriate labels Now ensure that each row has the appropriate label assigned to it. GRANT SELECT. and DELETE access is validated through a label. and DELETE) access is in place. UPDATE. GRANT SELECT. Because the table is now under Oracle Label Security control. 20400). Connected as MGR. Step 9: Assign normal grant-level access Ensure that CRUD (CREATE. it will ensure that access is also enforced.CHAR_TO_LABEL ('DOC_POLICY'. The WRITE_CONTROL parameter determines which INSERT. To determine which policies have been applied to which tables and schemas. ensure that the loading user (schema) has proper label write permissions. if there is a security policy applied to a table. the default session row label should be used. or DELETE until the CRUD grants are in place. 'SHARE_WARE'.DOCUMENTS table. Oracle Label Security will first check for appropriate CRUD access and then. This example illustrates both approaches. query the DBA_SA_USER_LABELS view. UPDATE. HR_EMP is assigned some read/write access on HR WEST documents. READ_CONTROL. and DELETE activities are authorized via a alternatively. you must use a schema that has privileges to update the label column. LABEL_DEFAULT specifies that if no label is provided for an INSERT statement. Next Steps READ Oracle documentation Oracle Label Security Administrator's Guide /documentation/oracle9i.html Name --------DOCID DOCNAME DOC_LABEL Type -----------NUMBER VARCHAR2(30) NUMBER(10) You can also conceal this column from users by specifying HIDE in the TABLE_OPTIONS parameter when you apply the policy: table_options => 'LABEL_DEFAULT. If you use SQL*Loader to insert data into a protected table. In this example. Users won't be able to SELECT. 30900).HIDE' The TABLE_OPTIONS parameter allows you to define what type of control will be applied to the table. doc_label FROM app.documents VALUES (3. Listing 1 shows the syntax for assigning each of these user labels. DOCNAME DOC_LABEL --------------------SHARE_WARE 10000 WEST_PAYROLL 20200 EAST_SALES 20400 COMP_PAYROLL 30900 Connected as HR_EMP. The READ_CONTROL parameter dictates that SELECT.documents VALUES (2. the same query returns the following: 4 de 5 05/06/2009 11:04 .com keyword search: security Manipulating the Data Now as you connect as different users. UPDATE ON documents hr_emp. To view users and access levels. SQL> INSERT INTO app.html LEARN about Oracle security education. SQL> INSERT INTO app. you assign labels to three users as follows: MGR is assigned a maximum level of read/write. query the DBA_SA_TABLE_POLICIES view. If you already have data in the table. you'll need to update the label column (DOC_LABEL) with appropriate label values. update the label This is where you assign a user's maximum read/write privileges. UPDATE. you can temporarily disable the policy. When a SQL query accesses a table. Label Security works in conjunction with regular table grants. In this case. Step 8: Assign user labels Now you need to define which users have what types of access within a policy.documents VALUES (1. EMP is assigned PUBLIC read/write access. you'll load data from scratch. READ. 20200). Here you make the appropriate CRUD grants to your users: SQL> SQL> SQL> TO SQL> ON CONN app/app GRANT SELECT ON documents TO emp. insert the data into the APP. UPDATE. and then reenable the policy. INSERT. One variation of this rule is that table owners can truncate their data even without Oracle Label Security DELETE permissions. SQL> INSERT INTO app. INSERT documents TO mgr.'PUBLIC')). use the CHAR_TO_LABEL function. The procedures map a user to levels of access and labeled rows.WRITE_CONTROL. UPDATE. 'EAST_SALES'.

For example. use the FULL keyword: SQL> EXEC sa_user_admin. 2001). If you have large volumes of data protected by Label Security. you'll need to install Oracle Label Security.comOracle RMAN Pocket Reference (O'Reilly & Associates. a B-tree index would be appropriate. Regardless of any special privileges such as FULL.'EXPUSER'. exporting table DOCUMENTS 0 rows exported You cannot apply a security policy to the SYSTEM schema. whether or not it is protected by Label Security. . See the Oracle Label Security Administrator's Guide. For example. you'll get the following message: EXP-00079: Data in table "DOCUMENTS" is protected. Depending on the cardinality of your labels. Considerations for DBAs If you are a DBA. if you have an EXPUSER schema that you use to export your database. users are allowed to perform only authorized actions. if you have labels of high cardinality. . or RMAN) of your database to back up LBACSYS's objects. Darl Kuhn (darl. You'll also need to precreate your policies and labels and ensure that the importing schema (user) has full write privileges.DOCUMENTS table as Chapter 12. If you attempt to export LBACSYS. you will need a tuning strategy. Oracle recommends analyzing the LBACSYS schema's objects as well as the application tables and indexes to improve the execution plans generated by the cost-based optimizer. We recommend analyzing LBACSYS's objects after any changes to the security policy.set_user_privs ('DOC_POLICY'. cold. In this way. you cannot use the export utility to back up the LBACSYS'EXPUSER'. You'll need to use a non-SYSTEM schema that has read permission on all rows that are label-protected in a table. the data can be exported only by a schema that has appropriate read permissions assigned to it. with more than 20 years of development and DBA experience." Therefore.DOCUMENTS table. Before you import label-protected data into another database.Technology Security: Now Securing Every Row http://www. you'll receive an error message: "LBACSYS is not a valid username. For example. you may want to consider adding either a B-tree or a bit-mapped index to your label is a staff engineer at Sun Microsystems.kuhn@sun. the same query returns only the following: DOCNAME ------------SHARE_WARE DOC_LABEL --------10000 When any SQL statement accesses the APP. Conventional path may only be exporting partial table. if you try to export the APP.'READ').html DOCNAME ------------SHARE_WARE WEST_PAYROLL DOC_LABEL --------10000 20200 Connected as EMP. for full details. E-mail this page Printer View About Oracle | | Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Privacy 5 de 5 05/06/2009 11:04 . you need to grant it the special READ privilege on all rows protected by a policy: SQL> EXEC sa_user_admin.set_user_privs ('DOC_POLICY'. Inc. you'll need to use a physical backup (hot. this feature cannot be compromised and offers a secure method of implementing and maintaining complex row-level security needs. Note that any schema with the SYSDBA privilege granted to it (such as SYS) can see all data. Oracle9i Database first validates CRUD access and then applies Oracle Label Security restrictions.roughton@sun. When you export data protected by Label Security.'FULL'). Conclusion Oracle Label Security in Oracle9i Database provides a secure way to control fine-grained access to your data. Encapsulated inside the database engine. there are a few additional items to consider. Steve Roughton (steve. To grant a schema full read and write privileges on policy-protected data..

.com. This page will not be added after purchasing Win2PDF.win2pdf. The unregistered version of Win2PDF is for evaluation or non-commercial use only.This document was created with Win2PDF available at http://www.