Role-based access control (RBAC) extends the privilege-based access control by grouping a set of privileges into roles and assigning these roles to users. A role can be defined as a classification of a work task. For example, you can define the manager role in a company. The manager role comes with a set of responsibilities, such as hiring employees, doing performance reviews, negotiating salaries, approving bonuses, and so on. These are common responsibilities that a typical manager performs across all departments. In order to fulfill these responsibilities, managers need certain privileges, such as access to employee records and other data privy to managers only. When an employee becomes a manager or when a new manager is hired into the company, the employee assumes the manager role and gets along with it the privileges associated with that role. IDS provides the same concept in the DBMS in the form of roles.
From a security perspective, it makes sense to split the administration duties to different employees in a company to minimize the risks of misusing the database content. To support this duty separation, IDS has the following predefined roles:
- Database Server Administrator (DBSA)
- User account responsible for configuring, tuning, and maintaining the server instances based on the local IDS database server installation
- Duties include the startup and shutdown of the database server, disk space management, backup and restore, performance tuning, and troubleshooting
- Database System Security Officer (DBSSO)
- Defines the audit masks for particular users working on the local database server instance
- Audit Analysis Officer (AAO)
- Responsible for audit configuration and audit trail analysis
- Database Administrator (DBA)
- Maintains a specific database in the local database server
- Permission was either automatically given to the database creator or granted by the database creator
- Does not necessarily include database server privileges
- Operating System Administrator (OSA)
- Defines and maintains the local user accounts including the AAO, DBSA, and DBSSO groups
- Installs the IDS product; responsible for changing required group permissions for role separation
- Maintains the kernel parameter settings and resource limits, such as files and memory
- Local or remote user accounts that are used to run database-based applications
- Privileged Users
- IDS defines the informix and the root users as privileged users
You can create custom roles in the database to suit your needs. A role can only be created by a DBA privileged user. Privileges are granted to roles by the DBA, and roles are assigned to users. A user can assume a role depending on the task being performed and relinquish the role when the task is completed. A user can be granted more than one role, but the user can assume only one role at any given time. Thus, depending on the operations to be performed, the user assumes a role and acquires the privileges that come with it.
The following sections describe the syntax and semantics of role creation, granting and setting of roles, default roles, revoking roles from users, revoking privileges from roles, and dropping roles.
A role is applicable only within the database in which it is created.
Listing 3 provides the syntax of the
ROLE statement, where role_name is the
name of the role:
Listing 3. Syntax:
CREATE ROLE role_name;
The syntax for granting privileges to roles is equivalent to the syntax of granting privileges to users. The role name has to be specified in place of the user name. Only a DBA can grant a privilege to a role.
Listing 4. Syntax: Granting privileges to roles
GRANT priv_list ON table To role_list;
Granting a role to a user is similar to granting a privilege to a user. The main difference is that in the case of granting a privilege to the user, it is granted on an SQL object, such as a table, column, view, routine, language, or fragment. While granting a role, there is no SQL object associated with the grant. A role's existence is within a database, and the user assumes a role for the set of privileges that come along with it. These privileges can be on any of the SQL objects, as discussed in the previous section. Similar is the case with revoke role statement.
Listing 5. Syntax: Granting/revoking roles to users
GRANT role_name TO user_list; REVOKE role_name FROM user_list;
A user with the DBA privilege grants roles to users. The
GRANT role statements do not activate the role. A role is
activated by the
SET ROLE statement.
An administrator can define a default role to be assigned to
individual users or PUBLIC for a particular database. The default role
is automatically applied when the user establishes the connection with
the database. Listing 6 provides the syntax of the
GRANT DEFAULT ROLE statement.
A default role can be granted to a set of users.
Listing 6. Syntax: Grant default role
GRANT DEFAULT ROLE role_name TO user_list;
After a non-default role is granted to the user, the user must use the
SET ROLE statement to enable the role. The user assumes the default
role as soon as a connection to the database is established. If no
default role is granted to the user, then the user does not have any
current role in the database when the connection is established. The
user can change the current role or switch to a new role using the
ROLE statement. Listing 7 provides the syntax of the
SET ROLE statement. The role
can be set to role_name. The role can also be set to a NULL value or
NONE, in which case the current role is disabled. When the role is set
to DEFAULT, the default role is enabled.
Listing 7. Syntax: Setting a role
SET ROLE role_name; SET ROLE NULL; SET ROLE NONE; SET ROLE DEFAULT;
When the user assumes a new role, the user acquires all the privileges
of the role in addition to the privileges that the user already holds
as an individual or as PUBLIC. If a role is granted to another role
that has been assigned to the user, then the user acquires all the
privileges of both roles, in addition to privileges the user already
holds as an individual or as PUBLIC. A user can be granted several
roles, but can assume no more than one non-default role, as specified
SET ROLE statement. If the
SET ROLE statement is repeated, then
the new role replaces the old one as the current role.
Only a DBA or the user to whom the role is granted with the
OPTION can drop a role. After you drop a role, no user can grant or
enable the dropped role. Also, users who are currently assigned the
dropped role lose their privileges that came with the role, unless the
same privileges were granted to PUBLIC or to the user individually. If
the dropped role is a default role, then the default role for the user
becomes NULL. Listing 8 provides the syntax of the
DROP ROLE statement. The name
of the role is indicated by role_name.
Listing 8. Syntax: Drop role
DROP ROLE role_name;
While discretionary access control works at the level of database objects such as databases, tables, columns, views, and so on, label-based access control works at the level of data rows and columns. Tables are protected by security policies, and individual rows and columns are protected by security labels. The database security administrator (DBSECADM) creates security policies and labels, and grants labels to individual users. When individual users with security labels write data rows to a table protected by an equivalent security policy, data labels are generated in individual rows of the table. The cardinal principle by which LBAC works is that users whose security labels dominate the data labels protecting the rows are able to read data. How is the dominance calculated? Any label is composed of individual components and elements within each component. A user label dominates a row label if individual components in the user label dominate individual components of a row label for a given security policy. These concepts are best described with sample scenarios.
Consider a company LBL Corp., which has a traditional organizational structure. Figure 3 shows the partial organizational structure of the company. This figure shows all departments of the company headed by the respective VPs:
- Marketing (VP)
- Sales (VP)
- West-region (Director)
- East-region (Director)
- South-region (Director)
- North-region (Director)
- Engineering (VP)
- Finance (VP)
- HR (VP)
Figure 3. LBL Corp. - Departments
The following scenarios describe three business requirements for LBL Corp. and then describe how to use LBAC to fulfill these business requirements.
The sales department is further divided into regions headed by the respective regional directors. The hierarchy extends further into sub-regions and finally into individual sales-persons. Figure 4 shows an expanded view of the sales organization:
- Sales (VP
- West-region (Director)
- East-region (Director)
- Georgia (Manager)
- Atlanta (Sales rep 1; Sales rep 2)
- Florida (Manager)
- Georgia (Manager)
- South-region (Director)
- Dallas (Sales rep 1; Sales rep 2)
- Houston (Sales rep 1; Sales rep 2)
- North-region (Director)
Figure 4. LBL Corp. - Sales department
The prime requirement of storing sales data is that employees are able to see the data belonging to them and their subordinates while not seeing data that belongs to their peers. For instance, the sales vice president should be able to see sales data belonging to all the regions, whereas each regional director only sees data belonging to their region. Using a similar approach down the hierarchy, an individual sales person can only see his own data.
This can be accomplished by granting labels to users in the organization such that labels granted to people higher up in the hierarchy dominate labels granted to people who report to them. Thus, the label granted to the sales VP dominates the labels granted to any of the regional directors, the labels granted to regional directors dominate the labels granted to any of the sub-region managers that report to them, and the labels that are granted to individual sales people are dominated by labels granted to their managers. This is best accomplished by defining a TREE component for the sales organization. This tutorial further discusses this scenario as an example while defining the security policies and labels for the sales data table.
Another scenario in which LBAC is useful is where the documents are classified based on their level of sensitivity and a user with their sensitivity level can read documents belonging to lower sensitivity levels. Once again, consider Figure 3, where marketing documents can be classified into sensitivity levels, such as Top Secret, Secret, Confidential, and Unclassified. The CEO of the company could be granted a label that has Top Secret as its component element. A technical architect could be given a higher sensitivity level so that competitive information is accessible. This is best accomplished by defining the ARRAY component of sensitivity levels. This tutorial discusses this scenario further while describing examples of creating security components.
Now, let's look at a third scenario that describes the usage of the SET component type. Consider the HR department in Figure 3. The VPs of individual departments can see the employee records belonging to their own departments. They should not be able to see records of employees belonging to other departments. But the human resources VP should be able to see all employee records of the company. Thus, the HR VP has a label that includes all departments. Other VPs have labels that have only their departments as part of the SET component. This tutorial demonstrates this with examples in subsequent sections.
The discussion of the sample scenarios demonstrates that LBAC provides the framework to create security policies in a variety of ways and to protect data with these policies. The chief characteristic of an LBAC-protected table is that security and privacy is achieved by making data access more granular. The SQL objects that enable LBAC enforcement are security label components, security policies, and security labels. These objects are used in protecting individual rows and columns in tables. LBAC enforcement is done at a lower level than DAC enforcement. After the privileges are checked at the database level and table level, LBAC enforcement is done at row and column levels to fetch individual rows. Only a DBSECADM can create LBAC SQL objects or apply them to tables or grant them to users. The DBSECADM is a built-in role provided by IDS, and this role is granted to individual users by the database system administrator. All LBAC SQL objects exist in the context of a database. There are three important steps in creating an LBAC framework:
- Defining the security policy
- Creating the security labels
- Assigning the security labels to the users