Selecting a User Provisioning Solution

  • Published on
    10-May-2015

  • View
    468

  • Download
    1

Embed Size (px)

DESCRIPTION

User provisioning products help organizations to create, manage and deactivate login IDs and other resources for users. They are intended to streamline administration of user access to systems as users are hired, move through an organization, and leave. This document helps organizations to define criteria which can be used to select an appropriate user provisioning product. The selection process begins with the business case for a user provisioning system. This business case is used to develop functional and technical requirements, which in turn drive the product and vendor selection process.

Transcript

  • 1.Selecting a User Provisioning Product 2014 Hitachi ID Systems, Inc. All rights reserved.

2. User provisioning products help organizations to create, manage and deactivate login IDs and other re- sources for users. They are intended to streamline administration of user access to systems as users are hired, move through an organization, and leave. This document helps organizations to dene criteria which can be used to select an appropriate user provi- sioning product. The selection process begins with the business case for a user provisioning system. This business case is used to develop functional and technical requirements, which in turn drive the product and vendor selection process. Contents 1 Introduction 1 2 Business Case for User Provisioning 2 2.1 Provisioning Resources More Quickly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Simplifying Security Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 Reducing System Administration Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.4 Improving Access Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4.1 Identifying and Removing Orphan Accounts . . . . . . . . . . . . . . . . . . . . . . 3 2.4.2 Timely Access Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4.3 Security Policy Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4.4 Audit Trails and Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4.5 Initial Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Functionality 4 3.1 Basic Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Authorization Workow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Fulllment Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Easy to Use Human Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 i 3. Selecting a User Provisioning Product 3.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 Automatic Change Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6 Consolidated and Delegated User Administration . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7 Directory Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 Technology 12 4.1 Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Integration With Other Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 Scalability and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Securing the user provisioning System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5 Security Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6 Effective Audit Trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5 Deployment and Management 20 2014 Hitachi ID Systems, Inc. All rights reserved. 4. Selecting a User Provisioning Product 5.1 Rapid Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6 Vendor Quality 23 6.1 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.2 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.3 Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.4 Services Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7 Conclusions 25 2014 Hitachi ID Systems, Inc. All rights reserved. 5. Selecting a User Provisioning Product 1 Introduction User provisioning products help organizations to create, manage and deactivate login IDs and other re- sources for users. They are intended to streamline administration of user access to systems as users are hired, move through an organization, and leave. This document helps organizations to dene criteria which can be used to select an appropriate user provi- sioning product. The selection process begins with the business case for a user provisioning system. This business case is used to develop functional and technical requirements, which in turn drive the product and vendor selection process. The remainder of this document is organized as follows: Business case for user provisioning Every user provisioning project must begin with a business justication. This is the background for all subsequent requirements. Functionality Basic functions that a user provisioning system should meet. Technology Technical architecture considerations, and how they impact an user provisioning systems usability. Deployment and management Design considerations that impact the initial deployment and ongoing administration of a user provi- sioning system. Vendor quality The qualities of a successful user provisioning vendor. Conclusions A summary, and a reminder to try before you buy. 2014 Hitachi ID Systems, Inc.. All rights reserved. 1 6. Selecting a User Provisioning Product 2 Business Case for User Provisioning A user provisioning system should not be deployed based solely on a vendors recommendation. Rather, it should address real and measurable business problems, and should yield a measurable return on invest- ment (ROI) in a short time-frame. Following are the most common reasons for deploying a user provisioning system: 2.1 Provisioning Resources More Quickly Users require dynamic access to systems, as their business relationship with a company changes. Systems access must be altered to reect hiring, staff changing responsibilities, and terminations. An important motivation for implementing a user provisioning system is to reduce the time required to enter, route, approve, and fulll requests for new or changed system access. A user provisioning system will reduce the number of days that it takes to route, approve and fulll a change request. This yields better customer service and improves the productivity of new hires and people whose responsibilities have changed. 2.2 Simplifying Security Requests Users frequently have to make security requests, to gain new access to systems as their business require- ments evolve, or to clean up old, no-longer-needed access rights. Users often have difculty guring out who to ask for security changes, and are frequently unable to artic- ulate their needs in terminology clear and specic enough for security administrators to implement. This slows down the security administration process and causes frustration for both users and administrators. A good user provisioning system should reduce or eliminate this friction between users and systems security administration processes. 2.3 Reducing System Administration Cost Organizations with multiple operating systems, directories, and applications manage users in multiple places, using different tools, often operated by different administrators. As staff are hired, moved and terminated, similar updates are applied to each of their accounts, on different systems. This administration is redundant, and reducing the amount of redundant administration has a signicant impact on overall administration cost. In addition, much of the administration work done on most systems is routine: creating standard-setup accounts, deactivating existing accounts, and applying routine updates. Once such changes are approved, a user provisioning system can execute them automatically, without human intervention. This creates a further reduction in administration costs. 2014 Hitachi ID Systems, Inc.. All rights reserved. 2 7. Selecting a User Provisioning Product 2.4 Improving Access Security 2.4.1 Identifying and Removing Orphan Accounts Manual system administration, combined with sometimes unreliable business processes, often leads to orphan accounts on systems. Orphans are simply accounts whose owners are no longer employed by the organization. Orphan accounts pose a serious security risk: if an intruder compromises an orphan account, nobody is likely to notice. An ongoing attack against an orphan account is also unlikely to be noticed. A benet of deploying a user provisioning system is the ability to identify and deactivate orphan accounts on all systems. 2.4.2 Timely Access Deactivation When staff leave an organization, their systems access should be terminated quickly. Failure to do so means that people no longer employed with the organization are still able to access sensitive systems. A benet of a user provisioning system is the ability to quickly identify users whose access should be terminated, and deactivate that access on every system where they have an account. 2.4.3 Security Policy Compliance Security policy normally species how login accounts should be congured for different types of users. Human error in manual administration means that these standards are not always enforced. Automated administration, as implemented by a user provisioning system, ensures compliance with standards. 2.4.4 Audit Trails and Accountability In the event of a security incident or audit, it is important to be able to justify why each user has been granted every account that he can log into. A user provisioning system should log requests and approvals, which constitute an audit trail for access changes. 2.4.5 Initial Passwords An important problem when creating new login accounts is how to securely communicate the initial pass- word to the new user. E-mail is typically insecure, as are default values such as the users name, employee number or login ID. Some user provisioning systems have effective technology to limit the number of people who have access to the initial password on new accounts. This is a major security benet, as it helps to assure that actions performed by that account in question really were initiated by the authorized user. 2014 Hitachi ID Systems, Inc.. All rights reserved. 3 8. Selecting a User Provisioning Product 3 Functionality The business requirements set out in Section 2 on Page 2 can be converted into specic functional require- ments as explained in the following sections. In the following text, an access change may be creation of a new login account, modication of the access rights or setup of an existing login account, or deactivation of systems access. 3.1 Basic Capabilities 3.1.1 Requirements A user provisioning system should support basic user prole updates on every target system: Creating new users. Deleting users. Enabling users. Disabling users. Renaming users. Updating user attributes. Adding users to groups (e.g., security groups, mailing lists). Removing users from groups (e.g., security groups, mailing lists). When creating new users or updating existing ones, the user provisioning system should be able to: Access every attribute in the schema of managed systems user properties, group memberships, etc. Map attributes on managed systems to some central, global schema. 3.1.2 Pitfalls to Avoid Avoid products that either have just a subset of the features mentioned above, or do not support the same features on every system. Make sure that the product supports at least the features identied as business requirements on every managed system. 2014 Hitachi ID Systems, Inc.. All rights reserved. 4 9. Selecting a User Provisioning Product 3.2 Authorization Workow In most organizations, access change requests take a signicant amount of time to ll out, route and autho- rize. A workow system can be used to expedite this process. 3.2.1 Requirements An authorization workow system should support: Easy input of change...

Recommended

View more >