Introduction

Identity theft and data breaches are some of the fastest-growing crimes in United States. Personal data, like social security and credit card numbers, is stolen to commit frauds and for economic gains. Criminals get this data from computer networks, e-mails, mail, trash, and many other places. Despite companies' best efforts to keep intruders out of networks and sensitive systems, more than 70 percent of data breaches are carried out by employees. In order to safeguard against intruders, most of the databases use authentication to verify that users are who they say they are; authorities and privileges control access to a database and the objects and data that reside within it. However, existing access control mechanisms are insufficient or add too much overhead to get the desired results. IDS 11 provides a sound solution to these situation in Label-Based Access Control. LBAC makes it possible to grant and restrict read and write access to individual rows and columns based on an employee's job function, department, or other designated criteria.

Back to top

What is LBAC?

Label-Based Access Control is a mechanism that lets a database system control access to a database object based on a security label contained in that object and the security label granted to the user attempting to access that object. It is a form of mandatory access control.

The IDS implementation of LBAC allows control over who can access data in individual rows and columns of a table. The LBAC capability is configurable and can be tailored to match the user's particular security environment.

A database security administrator, a user to whom the new DBSECADM role has been granted, performs all LBAC configurations. The database security administrator configures the LBAC system by creating security policies. A security policy describes the criteria that is used to decide who has access to specific data. After creating a security policy, the security administrator creates security labels that are part of that policy.

Once created, a security label can be associated with individual columns and rows in a table to protect the data held there. The database security administrator allows users access to protected data by granting them security labels. When a user tries to access protected data, that user's security label is compared to the security label protecting the data. If the user's security label dominates the data's security label, access is permitted; otherwise, it is denied.

The database security administrator can also grant exemptions to users. An exemption allows users access to protected data that the user's security labels might have otherwise prevented from accessing. Together, the security labels and exemptions are called LBAC credentials.

Back to top

Database security administrator (DBSECADM)

Database security administrator (DBSECADM) is a new built-in role introduced to perform all security-related administration, including setup of the LBAC security infrastructure. It is a server-level role and can be granted only by the database server administrator (DBSA).

The LBAC security infrastructure setup performed by DBSECADM includes setting up security label components, security policies, security labels, granting security labels and exemptions to users, and protecting tables by attaching policies.

The DBSECADM role can be granted to users by DBSA as follows:

GRANT DBSECADM TO 'lynette', 'manoj';
        

Back to top

Security label component

Security label components are the building blocks for security policies and labels. There are three types of security label components: array, set, and tree.

• Array security label component: An array is an ordered list of elements that can be used to represent a simple hierarchy. In an array, the order in which the elements appear is important. The first element ranks higher than the second element, and the second higher than the third. There can be a maximum of 64 unique elements in an array.
  
  An example of an array security component is the sensitivity level of data in an organization:
  
  Figure 1. Array component
  
  
  

  The array security component can be created by DBSECADM as follows:

  CREATE SECURITY LABEL COMPONENT level ARRAY [ 'Trade Secret', 'Secret', 'Confidential', 'Public'];

  
  
• Set security label component: A set is an unordered list of elements. In a set, the order in which the elements appear is not important. There can be a maximum of 64 unique elements in a set.
  
  An example of set security component is the departments in an organization:
  
  Figure 2. Set component
  
  
  The set security component can be created by DBSECADM as follows:
  
  Listing 1. Create set security component
  

  CREATE SECURITY LABEL COMPONENT department SET { 'Product Development', 'Quality Assurance', 'Marketing', 'Sales', 'HR', 'Finance'};

  
  
• Tree security label component: A tree is a collection of elements representing a complex hierarchy having multiple nodes and branches. There can be a maximum of 64 unique elements in a tree.
  
  An example of tree security component is the regions of operation of the organization:
  
  Figure 3. Tree component
  
  
  The tree security component can be created by DBSECADM as follows:
  
  Listing 2. Create tree security component
  

  CREATE SECURITY LABEL COMPONENT region TREE ( 'Worldwide' ROOT, 'Americas' UNDER 'Worldwide', 'Europe' UNDER 'Worldwide', 'Asia Pacific' UNDER 'Worldwide', 'USA' UNDER 'Americas', 'Canada' UNDER 'Americas', 'UK' UNDER 'Europe', 'Australia' UNDER 'Asia Pacific');

  
  

Back to top

Security policy

Security policy defines the composition of the security labels and specifies the rules used to control access to sensitive data. A security policy is made up of security label components. There can be a maximum of 16 unique security components in a security policy.

A security policy can be created by DBSECADM as follows:

                
CREATE SECURITY POLICY MegaCorp
COMPONENTS level, department, region
WITH IDSLBACRULES;
        

Back to top

Security label

Security labels are database objects applied to rows and columns in order to protect data, and granted to users to give them access to protected data. A security label belongs to a security policy and contains a value for each security component in that security policy. A value in the context of a security component is a list of zero or more of the elements allowed by that component. Values for array type components can contain zero or one element, and values for set and tree type components can have zero or more elements.

A security label can be created by DBSECADM as follows:

                
CREATE SECURITY LABEL MegaCorp.director
COMPONENT level 'Secret', 
COMPONENT department 'Product Development', 'Quality Assurance', 
COMPONENT region 'USA';
        

Security labels are applied to data in order to protect the data. They are granted to users to allow them access to protected data. A user can be granted at most two security labels for a security policy — one for read and the other for write. A user can also have the same label for both read and write access. When a user tries to access protected data, his security label is compared to the security label that is protecting the data. If the user's security label dominates the data's security label, access is granted.

A security label can be granted to users by DBSECADM as follows:

                
GRANT SECURITY LABEL MegaCorp.director TO 'john' FOR READ ACCESS;
GRANT SECURITY LABEL MegaCorp.manager TO 'john' FOR WRITE ACCESS;
GRANT SECURITY LABEL MegaCorp.director TO 'susan' FOR ALL ACCESS;
        

Access rules

Access rules can be divided into two categories: read access rules and write access rules. Read access rules are applied when a user attempts to read labeled data. Write access rules are applied when a user attempts to insert, update, or delete labeled data. IDS has a predefined set of read and write access rules that are collectively called IDSLBACRULES. When a user tries to access labeled data, their security label is compared to the security label that is protecting the data, and one or more of these predefined rules will be used to determine if one label dominates another.

Back to top

Read access rules

The read access rules are applied when data is read (SELECT, UPDATE, and DELETE operations) and can be summarized as follows:

• IDSLBACREADARRAY: Each array component of the user security label must be greater than or equal to the array component of the data security label to allow access to data.
• IDSLBACREADSET: Each set component of the user security label must include the set component of the data security label to allow access to data.
• IDSLBACREADTREE : Each tree component of the user security label must include at least one of the elements in the tree component of the data security label (or the ancestor of one such element) to allow access to data.

Write access rules

Write access rules are applied when data is written (INSERT, UPDATE, and DELETE operations) and can be summarized as follows:

• IDSLBACWRITEARRAY: Each array component of the user security label must be equal to the array component of the data security label to allow access to data.
  
• IDSLBACWRITESET: Each set component of the user security label must include the set component of the data security label to allow access to data.
  
• IDSLBACWRITETREE: Each tree component of the user security label must include at least one of the elements in the tree component of the data security label (or the ancestor of one such element) to allow access to data.

Exemptions

Exemptions provide a way to allow users to bypass one or more access rules for a security policy. If a user holds an exemption on a particular rule of a particular security policy, that rule is not enforced when the user tries to access data protected by that security policy. A user can hold multiple exemptions. If the user holds an exemption to every rule used by a security policy, then the user will have complete access to all data protected by that security policy.

An exemption can be created by DBSECADM as follows:

	
GRANT EXEMPTION ON RULE IDSLBACREADSET FOR MegaCorp TO 'john';
GRANT EXEMPTION ON RULE ALL FOR MegaCorp TO 'susan';
        

Back to top

How security labels are compared

When a user tries to access labeled data, his LBAC credentials are compared to security label protecting data to see if access is allowed. A user's LBAC credentials are any security labels he holds plus any exemptions that he holds.

Security labels are compared component by component. If a security label does not have a value for one of the components, then an empty value is assumed. As each component is examined, the appropriate IDSLBACRULES are used to decide if access is allowed. If any of the access rules are violated, the user is denied access to data. If the user holds an exemption for the rule that is being used to compare two values, then that comparison is not done (in other words, access rule is not applied for that component).

Back to top

Data protection

Data in a table is said to be protected when the table is associated with a security policy and either rows, columns, or both are protected by security labels. Data in a table can only be protected by security labels that are part of the security policy protecting the table. Data protection, including adding a security policy, can be done when creating the table or later by altering the table. A table can be associated with only one security policy. When a protected table is accessed, IDS enforces two levels of access control. The first level is the traditional Discretionary Access Control (DAC). That is, IDS verifies whether the user attempting to access the table has been granted the required privileges to perform the requested operation on that table. The second level of access control is Label-Based Access Control (LBAC), which can be at the row level, column level, or both.

• Row-level protection: A table can be protected with row-level protection granularity by attaching a security policy to the table and by specifying the column where the row security label will be stored. IDS has introduced a new data type, IDSSECURITYLABEL, for storing row security labels. Security labels are associated with rows (stored in IDSSECUIRTYLABEL type column) when rows are inserted into table or during alter, where the default security label specified is applied to all existing rows in the table. Row security labels can be modified by updating the row and specifying new security label for the IDSSECUIRTYLABEL type column. A table can have at most one column of type IDSSECURITYLABEL.
  
  A row-protected table can be created as follows:
  
  Listing 6. Create a row-protected label
  

  CREATE TABLE employee (lbl IDSSECURITYLABEL, id int, name char(25), ssn char(15)) SECURITY POLICY MegaCorp; ALTER TABLE department ADD (lbl IDSSECURITYLABEL DEFAULT ‘director’), ADD SECURITY POLICY MegaCorp;

  
  
• Column-level protection: A database can be protected with column-level protection granularity by attaching a security policy to such table and by attaching a security label to one or more columns of that table. When a column is associated with a security label, that column is referred to as a protected column. Column security labels cannot be modified. The existing security label for the column will have to be disassociated and a new security label attached if column security label is to be modified. A table can have any number of protected columns.
  
  A column-protected table can be created as follows:
  
  Listing 7. Create a column-protected table
  

  CREATE TABLE employee (id int, name char (25), ssn char(15) COLUMN SECURED WITH manager) SECURITY POLICY MegaCorp; ALTER TABLE department MODIFY (budget decimal(15,2) COLUMN SECURED WITH director), ADD SECURITY POLICY MegaCorp;

  
  

Back to top

Built-in security label functions

IDS provides three built-in SQL functions for dealing with security labels:

• SECLABEL_BY_COMP: This function builds a security label (internal encoded representation) by specifying a security policy and values for each of the components in the label. The return value has a data type of IDSSECURITYLABEL. This function is used in insert and update operations to provide the row security label for a data row.
  
  Listing 8. SECLABEL_BY_COMP function
  

  INSERT INTO employee VALUES (SECLABEL_BY_COMP('megacorp', 'Secret: (Product Development,Quality Assurance):Europe', 1, 'Manoj', '123-45-6789'); UPDATE employee SET lbl = SECLABEL_BY_COMP ('megacorp', 'Public:Marketing:Americas') WHERE id = 2;

  
  
• SECLABEL_BY_NAME: This function builds a security label (internal encoded representation) by specifying a security policy and the name of a security label that is part of that security policy. The return value has a data type of IDSSECURITYLABEL. This function is used in insert and update operations to provide the row security label for a data row.
  
  Listing 9. SECLABEL_BY_NAME function
  

  INSERT INTO employee VALUES (SECLABEL_BY_NAME('megacorp', 'manager', 3, 'Lynette', '987-65-4321' ); UPDATE employee SET lbl = SECLABEL_BY_NAME ('megacorp', 'director') WHERE id = 4;

  
  
• SECLABEL_TO_CHAR: This function returns a string representation of the values that make up a security label. This function is used in select operations to retrieve the row security label column. It can be thought of as the reverse of SECLABEL_BY_COMP.

Back to top

Conclusion

In this article, you've explored how you can use the IDS LBAC feature to deploy fine-tuned policy controls. Label-based access control provides you with a method to have complete control on who can access the data in a very granular way. You can deploy the LBAC infrastructure easily, and you can fine-tune it to match the need of the most demanding security environments, such as government or defense.

Resources

Learn

• developerWorks Informix zone: Find articles and tutorials, and connect to other resources to expand your Informix skills.
  
  
• Informix library: Get more details on Informix.
  
  
• IBM Informix Dynamic Server v11.00 Information Center: Learn more about IDS 11.
  
  
• developerWorks Information Management zone: Learn more about Information Management. Find technical documentation, how-to articles, education, downloads, product information, and more.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Technology bookstore: Browse for books on these and other technical topics.
  
  

Get products and technologies

• Informix Dynamic Server: Download a free trial version of IDS.
  
  
• Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Lynette Adayilamuriyil is a software engineer and has worked on IBM Informix Dynamic Server for the past nine years. She has vast experience in kernel and security areas of IDS.

Manoj Mohan is a software engineer working on IBM Informix Dynamic Server for the past nine years. He has vast experience in networking and security areas of IDS.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• What is LBAC?
• Database security administrator (DBSECADM)
• Security label component
• Security policy
• Security label
• Read access rules
• How security labels are compared
• Data protection
• Built-in security label functions
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Informix Dynamic Server Enterprise Edition
• Demo: Use DB2 First Steps and the DB2 Control Center
• Webcast: A smarter way to successful SOA - Information as a trusted strategic asset
• Briefing: Information on Demand
• Buy: Informix Dynamic Server Enterprise Edition

My developerWorks community

Dig deeper into Information Management on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers