RBAC for Physical Access

How to electronically manage physical access control


The Next Logical Step in Physical Access Management

RBAC has become the single-most effective approach to managing large-scale access control, and the American National Standards Institute (ANSI) adopted it as a standard in 2004. RBAC is actually the next step in the historical progression of physical access control management.

There is already a similarity between RBAC and conventional access control group mechanisms. Figure 1 shows the historical development of physical access privilege management, culminating in the use of cardholder groups to help simplify the management of access privileges. There are of course a number of variations to access privilege schemes, but most systems have the elements show in in Figure 1 in common.

One purpose of RBAC is to allow access roles to align with an organization’s actual personnel roles and related job responsibilities, as shown in Figure 2.

In a PACS that supports groups of cardholders (which can play the part of Roles in an RBAC scheme) and groups of access levels(where an access level group can be created for each role), RBAC can be established and managed by established procedure even if the PACS product does not directly support RBAC.


Role-Based Access Control Specifics

In contrast to typical PACS group schemes, RBAC has the following features when properly implemented:

Privileges are assigned to roles. This contributes to scalability, since in most large organizations more than one person has the same role (sales person, accountant, auditor, receptionist and so on). Roles change less frequently than personnel; thus assigning and updating access privileges is simplified.

Roles are assigned to cardholders. Roles are designed to parallel actual organizational roles, which simplifies management and allows role assignment to be done as part of the personnel enrollment process. This lightens the security department’s burden in physical access management.

Roles are hierarchical, that is, they can inherit privileges from other roles. This is required in order to parallel real-world organizational functional roles and to simplify access management. See Figure 3.

It is possible to implement a one-role-per-person policy. Hierarchical inheritance makes it possible to restrict role assignment to one role per person. This is not a requirement of RBAC, but some IT security practitioners favor it as a simplification mechanism.


Make Access Control Simpler

RBAC provides ability to approve the access privileges that are assigned to a specific role, instead of having to individually approve them for each person who will be assigned to the role. This significantly reduces the number of approval workflows required, which at times can be burdensome and can result in delays in access privilege assignments. Such delays often translate into delays in getting individuals functioning in their assigned positions. RBAC can eliminate them.

The process of naming roles that reflect the various organizational positions is termed “Role Engineering.” The resulting roles are called a “Role Catalog,” and its contents reside in the corporate directory or HR management system. Roles engineering is significant work, but the results are incredibly valuable for both physical security and IT.


Company Roles, not IT Roles

Many IT departments, especially in large enterprises, are implementing or already have implemented an Identity and Access Management (IAM) program, to “once and for all” get a good handle on corporate identity management and information systems access management. The program is called Identity and Credential Access Management (ICAM) in the U.S. government, because it uses a single smart card for both physical and logical security. Secure enrollment and card issuance processes are critical to the integrity of access management.

Because the IAM/ICAM programs and projects are run by IT departments, there is a tendency (especially for physical security practitioners) to think of the roles that are developed as “IT roles,” when in fact, they are the organization’s roles. There is every reason for physical security to use these roles in access management.