|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|News||Recommended Links||Solaris RBAC implementation||RBAC and Solaris privileges||RBAC as a Weapon against SOX Perversions and Kafkaesque Bureaucratization of IT|
|Introduction to Role-based Access Control||What is a role||MAC|
|Separation of Duties||Principle of least privilege||History||Humor||Etc|
Role-Based Access Control (RBAC) is a nondiscretionary access control mechanism which allows the central security policy and as such is very suitable to large organizations environment. the concept of the rile is very close to the Unix concept of a group with two important differences;
RBAC enables more precise implementation of the Principle of Least Privilege. Subjects may login with most of their roles deactivated, and activate a role only when a particular right associated with the role is necessary.
With the past noise about SOX compliance one of the few things that would make sense was the implementation of RBAC under the sauce of SOX compliance. Most of SOX activity resembled Y2K craze and also was equally useless, expensive and superficial effort that benefited mainly large auditing firms and (to a lesser extent) companies with semi-useless or harmful security products. But good managers have has a unique opportunity to play their cards more intelligently and persuade upper-level PHBs to implement RBAC as panacea against all SOX-defined ills. Persuading higher level managers to implement RBAC under SOX-compliance sauce was actually relatively easy as SOX did not even specify what are "adequate internal control", nor which solutions organizations must implement in order to meet this particular requirement. In this case using RMAC as "adequate integral control" solution makes a lot of sense.
This opportunity to implement RBAC is now a water under the bridge but that does not mean that such opportunities will never arise again. This page tries to point you to the relevant resources. Solaris 10 and 11 has RBAC built-in, but other commercial Unixes have now implementation too (AIX 6 is one example).Role-based access control (RBAC) was introduced in 1992 by David Ferraiolo and Rick Kuhn of the NIST. In April of 2004 the American National Standards Institute approved Standard 359-2004: American National Standard for Information Technology—Role Based Access Control. NIST maintains a Web site dedicated to RBAC at http://csrc.nist.gov/rbac. There are two key principles of role-based access control:
From the point of view of security theory RBAC bases access control decisions on the functions a user is allowed to perform within an organization. The users cannot pass access permissions on to other users at their discretion. This is a fundamental difference between RBAC and DAC. That means that RBAC is in fact a form of mandatory access control, but unlike a typical MAC environment it is not based on multilevel security requirements (clearances and security labels). As defined in the TCSEC, MAC is:
A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e. clearance) of subjects to access information of such sensitivity. [Orangebook]
RBAC can lower the cost and complexity of security administration of large servers. RBAC organize privileges into roles.
In large organizations, the application owners do not "own'' the information of the application for which he/she is responsible. For these organizations, the corporation itself or even some government agency is the actual "owner'' of system objects and application owner is simply a custodian.
The act of granting membership and specifying transactions for a role is loosely analogous to the process of clearing users (granting membership) and the labeling (association of operational sensitivities) of objects.
Unlike MAC where the main focus is on capability: who can read what information within a role-based system, the principal concern in RBAC is protecting the integrity of information: "who can perform what actions on what information''
A role can be thought of as a set of transactions that a user or set of users can perform within the context of an organization. Membership in a role is granted and revoked by a system administrator.
Roles are group oriented; the simplest model of roles is probably Unix groups implementation
The key questions here are:
Working with industry groups, the National Institute of Standards and Technology has developed a proposed standard, "Security Requirements for Cryptographic Modules,'' (Federal Information Processing Standard 140-1) that will require support for access control and administration through roles.
To date, these role based systems have been mainly developed for use by military and intelligence. Trusted Solaris was workhorse of military since its Solaris 8. But the most robust implementation is provided by Solaris 10 which can be considered a classic implementation of RBAC in Unix systems.
Despite long history there is no commonly agreed upon definitions or recognition of formal standards, although Solaris 10 implementation serves as de-facto standard.
The Sarbanes-Oxley Act establishes a set of requirements for financial systems, to deter fraud and increase corporate accountability. For information technology systems, regulators may need to know who used a system, when they logged in and out, what accesses or modifications were made to what files, and what authorizations were in effect. IT vendors responding to Sarbanes-Oxley requirements have adopted RBAC as central to compliance solutions because RBAC was designed to solve this type of problem.
This document is merely a re-sorting of the "Principles" output from the NAC 2001 Fall conference, which will hopefully act as a starting point to more comprehensive documentation. The conference material did not contain all of the "principles" that may apply to RBAC, but there were also some good ideas expressed in the contents that were not "principles" as well. This document re-sorts the conference document into "RBAC Principles" items and "Role Engineering Best Practices" items for further discussion.
Principle: A "principle", as used in this context, is a constant (some might call a "rule") that defines a particular behavior or characteristic that any RBAC system must include, exhibit or comply with.
Best Practice: A "best practice" can be an insight based on experience, a recommendation based on research, or even an opinion based on sound reasoning. In this case, certain "best practices" for role engineering or role discovery were contained within the NAC conference "Principle" document.
1. The RBAC system must delineate users, roles, and permissions.
2. A user can be assigned to multiple roles.
3. The system must support the notion of "Separation of Duty " constraints.
4. Must leverage existing standards to the extent possible.
5. An inheritance model must be supported so that a role can inherit rights other roles .
6. The permission with the least privilege applies, in cases where a user is assigned to multiple roles, and two or more roles define a permission on the same object.
7. The system must log changes to role assignments.
8. The system must provide an aggregated view of all permissions assigned to a particular user.
9. The system must provide a view of all users assigned to a particular permission.
110. There must be an administrative interface to add/change/delete roles, permissions and users – as well as the assignments of permissions to roles and roles to users.
111. A role should be able to map to one or more "groups" on one or more target systems.
112. "Users" can be people, applications, devices or functions.
Best Practices for Role Engineering:
1. Roles are abstractions of system entitlements that consider two design criteria:
- Consolidation of entities into meaningful groups that facilitate ease of administration.
- Collections of permissions that are meaningful to specific user communities
2. There are three basic approaches to role engineering:
- "Bottom Up": which derives roles from the groups and permissions defined on the existing systems and platforms in the enterprise.
- "Top Down": which derives roles from an analysis of business function and organizational criteria, typically from a "zero base" starting point.
- "Hybrid": which, as the name implies, derives roles using a combination of bottom up and top down approaches.
3. The top down approach typically is much more difficult to implement, because it will probably result in significant changes to legacy group and permission models.
4. The bottom up approach is typically easier to implement, because the RBAC system will overlay the legacy group and permission models.
5. A successful role definition approach will likely be a hybrid approach
6. The objective of role modeling is to maximize flexibility with minimal administrative effort.
7. Role engineering should consider how role and user administration is to be delegated. More decentralized models benefit from more top down analysis.
8. Top down role engineering will aggregate business processes into organizational parameters.
9. A top down approach can only be successful with participation and buy-in from business units.
110. A role typically maps to a group on a legacy system.
111. Successful implementation of RBAC benefits from a cultural commitment to define common roles that supercede individual privileges.
112. Roles do not have meaning unless they are used to define access privileges.
113. Plan for role life cycle management
114. Consider using use case modeling to validate role definitions.
Google matched content
NIST/Role Based Access Control
Access Control Model
Links to Security-related conferences (great places to pick papers)
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March 12, 2019