Manage five common privileged identity management scenarios
Learn how to implement five common privileged identity management scenarios with IBM Security Privileged Identity Manager
It's important for all enterprises to protect their confidential information from external hackers. It is equally important to protect enterprise resources from insider abuse and negligence, such as using weak or shared passwords. Insider security incidents typically occur because the identities (accounts) and passwords for accessing these resources are not well protected or not protected at all. IBM Security Privileged Identity Manager offers controlled sharing and automated logon for privileged identities. It provides:
- Centralized administration, secure access, and storage of privileged shared account credentials
- Role-based access control for shared accounts
- Life cycle management of shared accounts ownership
- Ability to change the password on every check in
- Single sign-on through automated check-out and check-in of shared credentials
- Auditing of shared credentials access activities
- Integration with the broader Identity and Access Management Governance portfolio
Five common privileged identity management scenarios
Based on customers' use cases for shared and privileged identities, take a look at this collection of common scenarios and written how-to guides for each scenario. These scenarios are stand-alone and can coexist with each other. The how-to guides use a fictitious organization, JK Enterprises, which deploys a privileged identity management solution to simplify and streamline the access, compliance, management, and governance of the privileged IDs. Each of the scenarios' how-to guides are described below. Each scenario provides a link to a detailed how-to guide that describes the implementation.
Scenario 1: Pool of delegated administrators or help desk users access a credential pool
The how-to guide for Scenario 1 describes how an enterprise with many servers (either in server farms or heterogeneous servers) managed by a group of people (regular employees or contractors) can define a pool of privileged IDs and manage and track the access to these IDs by their system administrators.
Scenario 2: Application administrators request Ad-hoc privileged access
The how-to guide for Scenario 2 explains how application administrators typically have fewer privileges than system administrators. This scenario describes how higher level privileges can be provided to application administrators when needed and how the access can be controlled (through approval), tracked, and audited.
Scenario 3: Administrators need privileged access in emergencies (The "break the glass" scenario)
The how-to guide for Scenario 3 describes how every organization is susceptible to unplanned absences by system administrators. In these emergency situations, another person needs to carry out the privileged administration tasks. This scenario describes how emergency administrator privileges can be assigned, how to track what the emergency administrator did, and how to (manually or automatically) remove their access.
Scenario 4: Applications or cron jobs use a shared privilege ID
In the how-to guide for Scenario 4, get an explanation on how an organization can write secure applications (including scripts and cron jobs) by eliminating the need to hard code a privileged ID and password. Instead, the applications check out a privileged ID when needed and check it in when done.
Scenario 5: Multiple network administrators share a single superuser account on a network device
Finally, in the how-to guide for Scenario 5, learn how network devices like routers, firewalls, switches, and so on, usually have only one administrator ID that is used by many network administrators. This scenario describes how to track which network administrator used which ID, and for how long. This scenario also describes how to periodically send password change reminders for these devices.
- Visit the IBM Security Privileged Identity Manager on developerWorks community to see more How To Guides.