|
Evolution of Entitlement Management
Traditionally, legacy systems and applications managed user permissions by means of groups. Under this model, permissions are assigned to groups — users inherit permissions by being a member of a group. The ability to assign permissions to a group and determine who can inherit the permission is considered discretionary, as these determinations are made by the application and system owners. However, authority to assign members to a group is deemed non-discretionary and usually is performed by the security organization. This construct has evolved in recent times with the adaptation of RBAC in IAM solutions. Assignment of permissions to a role and determining membership of roles is supposed to be non-discretionary. Users inherit a set of entitlements as their birth right, as they are enrolled into the organization as part of the onboarding process.
Conventionally, managing entitlements has been considered technical, as they are related to applications and are managed in silos without much business input. With the emergence of various regulatory requirements such as the US Sarbanes-Oxley Act, US Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Biley Act (GLBA) and EU Privacy Protection Directive 2002/58/EC, it is increasingly important to streamline the entitlement management process with business oversight, as it becomes a security governance and compliance issue.
RBAC 101
The fundamental concept of RBAC is that roles aggregate privileges. Users are assigned roles and inherit predefined permissions by being members of roles. They are given entitlements — no more than what is required to perform their job function — based on the least privilege access principle. The following diagram in Figure A depicts the key building blocks of the core RBAC reference model per the American National Standard for Information (ANSI)/InterNational Committee for Information Technology Standards (INCITS) 359-2004 Standard. key elements of RBAC are:
USERS By definition, users are individuals who perform one or more job functions within an organization.
ROLES In a business context, roles represent job functions and related responsibilities. Responsibilities represent users’ implicit or explicit authority to execute their job function. In a technology context, roles represent a collection of entitlements that a person inherits from an application perspective to perform a job function.
PERMISSIONS In a technology context, a permission is the provision of authority to someone to perform an operation against an RBAC-controlled object within an application or system.
Role Engineering
As organizations start deploying IAM solutions, it is becoming increasingly important to devise a common set of roles that can be reused, over and over again, as opposed to defining roles every time an IAM component is deployed. One of the challenges often faced is that, if defined incorrectly, roles are ineffective and fail to meet the organization’s requirements.
Roles can be defined at an abstract level from a business perspective, or context-specific to an application or system from a technology perspective. At an abstract level, roles can be a simple label that defines the job function with a set of responsibilities and authority that goes with it. For example, a bank teller’s job function can be a role defined as teller with the responsibility to perform financial transactions with certain limits (authority). At an abstract level, there is no enforcement capability. The role teller in an application has specific entitlements that enable a user to execute transactions with certain limits. How this is configured within the application and how it is enforced is specific to the individual application’s capability.
Whether an organization looks at defining roles either abstract or specific to a context, the requirements to define roles are important and role definition is a critical step in deploying any RBAC system.
Role engineering is the process of defining roles and related information, such as permissions, constraints, and role hierarchies, as they pertain to the user’s functional use of systems, applications, and business processes. It is one of the critical steps in deploying RBAC-oriented IAM systems. Organizations often implement IAM systems based on a role-based paradigm without much consideration for roles3. To minimize deployment effort or to avoid project scope creep, role definition is often not considered part of the initial project. Organizations frequently do not invest enough time to define roles in sufficient detail; rather, they tend to define high-level roles that do not reflect actual organizational job functions. Permissions mapped to high-level roles are usually generic in nature. The result of this random process is that additional efforts are required to manage job- and function-specific permissions manually, outside the IAM system. This often results in IAM systems not delivering the expected business value, for example, adherence to compliance and reduced entitlement management costs. The process of defining roles should be based on a complete analysis of how an organization functions and should include input from a wide spectrum of users, including business line managers and human resources.
|
