Role-based access controls


This article can also be found in the Premium Editorial Download "Information Security magazine: Nine tips to guarding your intellectual property."

Download it now to read this article plus other related content.

An Attractive Model
Understanding the limitations of ACL and group policies, NIST established an RBAC standard (http://csrc. nist.gov/rbac/draft-rbac-implementation-std-v01.pdf) as a guideline for

Requires Free Membership to View

vendors who construct role-based systems. It also gives companies direction for successful development and application of RBAC across their enterprise based on real-world functional needs.

Moving toward this standard approach requires vendors and administrators to become more familiar with the RBAC model and the types of security that it can provide for different environments. The model is made up of the following components:

  1. Core RBAC: This is the foundation of the model, and will be integrated in every RBAC implementation. Users, roles, permissions, operations and sessions are defined and mapped according to security policy. It defines many-to-many relationships among individual users and privileges; it describes how a session is a mapping between a user and a subset of assigned roles and accommodates traditional but robust group-based access control.

    Here's how it works. Many users can belong to many groups with various privileges outlined for each group. When the user logs in (this is a session), the various rights assigned to roles and groups that he is a member of are available to him during this session. So if I am a member of the accounting, R&D and administrative groups, I can use any or all of the accumulated privileges assigned to each group.

  2. Hierarchical RBAC: This allows the administrator to set up an RBAC model that maps to the organizational structures and functional delineations required in a specific environment. This is very useful, since businesses are already set up in a personnel hierarchy. In most cases, the higher you are in the chain of command, the more access you will likely have.

    For example, the nurse role can access certain files and the lab technician role can access another set of files. The doctor role inherits the permissions and access rights of these two roles and has more elevated rights already assigned to it.

  3. Static separation of duty: Constraining incompatible combinations of privileges is a critical concept to prevent abuse of authority, including fraud. An obvious example would be that an employee cannot be a member of both the cashier and accounts receivable groups.

  4. Dynamic separation of duties: Deter fraud/conflicts of interest by constraining the combination of privileges that can be activated in the same session (See Figure 1). For example, if I am in the groups cashier and cashier supervisor, I only have the access rights and work within the security context of the particular role I log in under. I do not have the aggregate privileges of both roles during one session.

This was first published in May 2007

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: