Features Access Governance
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Access Governance - Hitachi ID Identity Manager

Hitachi ID Identity Manager includes a variety of features that collectively are used to govern the security entitlements assigned to users.

What are security entitlements?

The Burton Group defines an entitlement as:

An entitlement is the object in a system's security model that can be granted or associated to a user account to enable that account to perform (or in some cases prevent the performance of) some set of actions in that system. It was commonly accepted that this definition of entitlement referred to the highest-order grantable object in a system's security model, such as an Active Directory group membership or SAP role and not lower-order objects such as single-file permission setting.

Definition by Ian Glazer, in Access Certification and Entitlement Management v1, September 9, 2009.

http://www.gartner.com/technology/research.jsp (login required)

Access governance overview

Access governance is broken down into a series of features, used to assign appropriate rights to users initially, to monitor and control the rights users have over time and ultimately to deactivate no-longer-required entitlements.

Role based access control

Role-based access control (RBAC) is an approach to managing entitlements, intended to reduce the cost of security administration, ensure that users have only appropriate entitlements and to terminate no-longer-needed entitlements reliably and promptly.

In the context of a single system or application, RBAC means granting privileges directly to roles and attaching users to roles. Users acquire privileges through role membership, rather than directly. Within a single system, roles are sometimes called security groups or user groups.

Single-system RBAC is a time tested and successful strategy, as it allows administrators to group users, group privileges and attach groups of privileges to groups of users, rather than attaching individual privileges to individual users.

Identity management and access governance systems extend RBAC beyond single applications. Roles in an IAM system are sets of entitlements that may span multiple systems and applications. The key element of roles is to replace many technical entitlements with fewer roles that business users can understand. Business users can then a reasonable determination of which users should have which roles. This implicitly specifies which users should have which technical entitlements.

Roles consist of entitlements -- login accounts and security group memberships. Roles are often also nested -- i.e., one role can contain others. Nesting roles can reduce the cost of role administration.

Learn more about the RBAC features included in Identity Manager.

Preventing new and detecting existing violations to segregation of duties policy

Segregation of duties (SoD) policies allow organizations to define toxic combinations of entitlements, which no one user should possess. The most common business driver for these policies is fraud prevention -- i.e., ensuring that fraud cannot be committed without collusion by at least two users.

Learn more about the SoD prevention and detection capabilities included in Identity Manager.

Approving security change requests

A workflow engine allows both business users, in a self-service fashion and automated processes to request and authorize security changes. This is a key feature of any successful user provisioning system.

Users sign into a secure web application and submit change requests by selecting and filling in a suitable form. Requests are validated by the workflow engine and the requester may be required to make corrections.

Some parts of a request may be automatically filled in and may not even be visible to the requester. For example, the user provisioning system might automatically assign a standard login ID to all new accounts, assign a file server and mail server, select a directory OU and so on.

The workflow engine forwards valid requests to one or more authorizers. These are simply other users, chosen through the application of security policy. Example authorizers may include application owners and managers in the chain of command above the requester. Some requests may not require authorization at all.

Authorizers are normally invited to review and either approve or reject change requests by e-mail. A URL is embedded in the e-mail, which authorizers follow to a secure web application where they sign in, see request details and either approve or reject the request.

The workflow engine must allow for the possibility that authorizers will not respond in a timely manner -- by automatically sending reminders and escalating requests from unresponsive authorizers to other responsible users.

The workflow engine must also allow authorizers to actively delegate their responsibility, for example when they schedule time off or when they change jobs permanently.

Self-service and delegated updates to users, profiles and entitlements are illustrated in Figure [link].

figure

    Self-Service Security Administration Workflow (1)

Learn more about the authorization workflow engine built into Identity Manager.

Reliable, automatic access deactivation when users leave

Identity Manager is typically used to first disable and then, at a later date, delete accounts for users who leave an organization. The process often has four distinct phases:

  1. A user (via self-service or delegated security administration, using a web user) or an unattended process (scheduled batch job) submits a request to disable user X on date Y.
  2. Some number of days (N) before the deactivation date arrives (i.e., on date Y-N), the user's current manager-of-record is sent an e-mail, advising him of the impending change and asking him to change the deactivation date if required.
  3. On date Y, all of the user's accounts are disabled. Additional changes, such as removing the user from security groups, may also be performed. Tickets in an external system may be created at this time, to collect laptops, building access badges, etc. E-mails are typically sent to HR and the user's manager to notify them of the completed deactivation.
  4. When accounts are disabled, installation-specific business logic is often triggered, for example to archive mailboxes and home directories, create mail redirection rules, move user accounts to new OUs, remove active security group memberships, etc.
  5. Some number of days (M) after the deactivation date arrives (i.e., on date Y+M), the user's accounts are permanently deleted. This normally includes deleting, moving and/or changing ownership of digital assets such as network home directories, mail folders, etc.

Learn more about the automated provisioning and deactivation mechanism included in Identity Manager.

Periodic review, certification and cleanup of user entitlements

Access certification is a process where business stake-holders are periodically invited to review entitlements, sign-off on entitlements that appear to be reasonable and flag questionable entitlements for possible removal.

Learn more about the access certification features built into Identity Manager.