The topic of Single Sign-On (SSO) has come up recently with…
Oracle’s Privileged Account Manager (OPAM) is the newest release in the Identity Governance genre of products. It complements Oracle’s current offerings in a handful of very important ways regarding the administration and use of passwords for shared accounts and accounts with elevated privileges. These accounts have the most power, stay around the longest, and contain the highest security risks. Unfortunately, they also present difficult management challenges which often go only partially addressed. To this end, OPAM introduces several capabilities for managing the passwords to these accounts:
- Centralized Password Storage and Distribution
- Automated Password Propagation
- Strengthened Password Security
- Restricted Use of Privileged Accounts
- Improved Compliance
- Centralized Password Storage
At its most basic, OPAM can be used as a password vault for centralizing password storage and providing a single point of access to administer and view privileged account passwords. This eliminates the hassle of sharing password files among team members or coordinating password updates, saving time and preventing frustration. To achieve this securely, OPAM should be configured in conjunction with technologies such as Transparent Data Encryption to encrypt password and account data at rest and SSL to encrypt the data in transit.
Automated Password Propagation
However, OPAM is not just another web-based password vault in isolation from the larger environment. It leverages Oracle’s Identity Connector Framework (ICF) to communicate with the actual target systems, such as LDAP servers, databases and UNIX/Linux servers that house the privileged accounts. Using the ICF, OPAM queries target systems for accounts to manage and automatically pushes changed password values to those accounts. This eliminates the error-prone manual process of propagating passwords to target systems and reduces associated maintenance costs and downtimes.
Strengthened Password Security
Another strong point of OPAM is its ability to manage passwords at the level of individual accounts. Unlike the vast majority of Identity and Access Management products out there, (Oracle and non-Oracle alike), OPAM allows for each individual account to be configured with its own password policy separate from every other account. These account-specific password policies govern not only password complexity, such as constraints on permitted and restricted characters, but also password lifecycle, specifically, how long password histories should be kept, when passwords should expire and if they should be reset relative to their use. In fact, OPAM’s, default configuration enforces single-use passwords that are reset before and after being used, preventing security holes due to stale passwords or passwords shared out-of-band.
Restricted Use of Privileged Accounts
Limiting the use of privileged accounts is a two-part process. First, a user must be granted access to the account, either explicitly as an individual user, or implicitly as a member of a group. Each grant comes with day, time and duration constraints restricting when the password can be used by the grantee. Second, users must then explicitly check out an account before being able to use its password (and must subsequently check in the account when finished with it) so authorized users can only use these passwords at authorized times. However, if the target system supports it, an even more secure alternative to the password checkout is available called a session checkout. With a session checkout, a user never sees the password directly. Instead, OPAM brokers the user’s weblogic credentials to establish an SSH session with the target system. All the password commands and command outputs for that session can be recorded in session transcripts for auditing purposes.
OPAM also improves an organization’s ability to comply with security regulations with real-time dashboards and comprehensive audit reports. Administrators can view the accounts currently managed by OPAM, who has them currently checked out, and in the case of session checkouts, even what has been done with those accounts. If the situation demands it, administrators do have the ability to view password histories, force a password/session check-in, or reset a password. To provide a more historical view of managed accounts, OPAM also integrates with the Common Auditing Framework to provide fine-grained auditing of run-time events. BI Publisher reports can then be run to answer questions about who has used a privileged account, and what target, account, or policy operations have occurred in a given time period.
To summarize, from centralizing password storage, to enabling a greater degree of regulatory compliance, OPAM provides several key features that are crucial to properly mitigating security risks and preventing security holes regarding the management and use of privileged accounts. This Oracle product should be seriously considered as a complement to any existing Identity Governance implementations or even as a stand alone product for those organizations who aren’t currently invested in Oracle Identity.
Have additional questions about this new tool? Leave us a comment below!
This Post Has One Comment
I’ve seen similar rtceristions but still consider the security sufficient ifa) you have some random login number that you write downb) your account gets blocked after 3 tries.If the login number was your account number it could be used for denial of service, so I prefer a random number.Of course someone could still steal your hashed password from the bank and brute-force it which is easier for simple password.But then this is not much easier than installing a trojan, staging a man in the middle attack or sniff your password by other means.