Use of Role-Based Access Control (RBAC) in Health ...



Use of Role-Based Access Control (RBAC) in Health Information Systems

J.M. Davis

Role-based access control provides one type of information used to make access control decisions. Other types of access control information includes entity-based, context-based and rule-based. RBAC cannot by itself provide all of the information needed to make access control decisions in complex Health information systems.

Problem: How can one effectively use RBAC in VHA's future healthcare systems?

Discussion: VHA’s VistA system provides a type of role-based access control using menus and options keys. These mechanisms work well but are also very application specific and do not scale to an enterprise-wide or interoperable management approach.

HL7 has passed a ballot for an international RBAC standard. ISO continues to develop privilege management infrastructure standards as does ASTM. VHA needs to integrate these standards and technologies into future healthcare systems.

Model for secure system

For the purposes of discussion, consider the model of a house with several rooms with several filing cabinets in each room. In order to enter the house, one will need to have the key to the front door. This key identifies you as a person authorized to enter the house.

Each room of the house is equipped with a keypad lock mechanism. In order to enter a room the user now must know the lock code for the room. The user will not be able to enter rooms for which he has not been provided the keypad lock code.

Inside each room are filing cabinets. Each filing cabinet is also protected. Some filing cabinets may actually be safes. Other filing cabinets may have looser controls like a childproofing device.

Some content in the rooms may be behind a glass barrier. To access this content the user may break the glass with the little hammer next to the wall, however, doing so will set off an alarm.

Model for a secure IT system

Like the model for the house, the IT user must also have a key to the enterprise. The basic model for this is the user authentication service. If the user is unable to authenticate then no further services will be provided. User authentication is the key to the enterprise front door.

Once authenticated, the user will want to be able to access one or more rooms. In an IT sense, a room may be a functional area such as healthcare, administration, Human Resources, finance, etc. The keypad lock code for these functional areas is the user structural role. The structural role is the way in which an enterprise controls user authorizations to connect to a protected resource. Without this role, the user will be unable to access services and data from within protected applications.

Once authorized access to workflow belonging to a particular functional area, the user will need appropriate permissions specifying what he can do within the application. RBAC provides access control information supporting this type of access to applications.

HL7 balloted permissions are based upon a workflow analysis. These permissions provide access to various workflows within an organization, which might be represented at the application level by the screens and data presented to the end-user. In VistA, menu keys provide a further level of granularity that allows administrators to further control information presented to individual users. Assigned to individual users, this type of access control information would be considered entity-based access control.

As permissions are assigned at deeper and deeper levels within an application, the ability to support enterprise-wide or to manage interoperable roles diminishes. Since it is also necessary to implement these features within the application code itself, intimate knowledge of the internal operation of the application is necessary. This is contrary to the goal of removing security functionality from applications and managing it at an enterprise level. How then are we to reconcile this apparent contradiction?

Solution

One possible solution may be in a careful analysis of the true function of these application specific controls and in particular by considering the differences between entity-based need-to-know controls and least privilege.

Least privilege is a more restrictive type of access control requiring that the end-user only receive permissions necessary to do the job assigned. Access to additional privileges would be in violation of the security policy and potentially represents a security breach since the user may have access to information and data specifically not allowed.

Need-to-know restrictions, on the other hand, could possibly be implemented in a less stringent manner. For example, application-level filters can restrict user access as a business rules rather than a security role. If this is allowable under the security policy in effect, then failure of the filter does not imply a breach of security rules as the user was in fact authorized access to all of the information in the first place.

This is loosely analogous to the break-glass scenario. In the break-glass case, users may demand access to information by breaking the glass. They are authorized to do this, and they are also authorized to see the information on the other side of the glass… no additional permissions are required. The consequence of breaking the glass is perhaps additional auditing and warning to management that unusual access has been obtained, however, there is no reason to presume a security violation has occurred. Break-class is therefore, strictly speaking, an implementation of a business function not a security one.[1]

In a similar way, a system could implement need-to-know restrictions on the menu system using programmatic techniques that did not require calling the security functionality. This would be appropriate in conditions where failure of the filter did not imply a security breach and the user already had authorization to the information.

The advantage of this approach is that the security functionality inherent in RBAC can be associated with external workflow level processes and not internal application processes. This distinction allows for separation of security and business functionality.

This approach is similar in some respects to the way in which DoD handles classification levels. For example, a person with a confidential clearance may not have access to all information classified confidential under need-to-know restrictions. Nevertheless, inadvertent exposure to information that had been restricted under need-to-know does not necessarily represent a security event since the user was authorized for access at the confidential level. Access to the information at a lower level (e.g., "unclassified") automatically implies a violation of the security policy. DoD uses the more formal security mechanism of compartmentalization to restrict individual user access to information at the same security level.

Conclusion: this paper has defined an appropriate use for RBAC that allows for separation of security and business rules. It proposes business-level filters to implement applications-specific need-to-know access without the necessity of employing more stringent security functions. This greatly simplifies application development, certification and understanding of the security mechanisms.

Where the use of filters to implement need-to-know restrictions are insufficient to implement a security policy, then least-privilege mechanisms using an application level security kernel could be employed. Such a kernel would likely be proprietary, application specific and not interoperable.

Implementation of these mechanisms requires careful analysis of application functionality, risk profile, and specific use cases requiring access either by break-glass mechanisms or need-to-know filters. In no case should violation of existing security policy be allowed. Nevertheless, the application of business filters to implement certain types of information separation is a promising technique that should be considered to simplify the design and deployment of componentized systems.

-----------------------

[1] Distinguish break-glass from "emergency access" in which the user must assert additional permissions that he does not normally possess.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download