HPAM stands for High Privileged Access Management. This feature allows organizations to better protect their ecosystem by removing all administrative access from an employee's "standard Identity" By standard Identity, we mean the Identity an organization will use to qualify the user for access within their network or end points (i.e. cloud applications) on a dailly basis. This could be their domain or network account, their Google Apps account, Office 365, etc. Organizations should always deploy HPAM and strip standard Identities of any administrative privileges. By doing this organizations can help to protect administrative access to their applications as well as their domain. There are various popular approaches used today to lock down who is qualified for administrative rights within a given system. Most often, the administrators standard Identity is granted access to a security group which elevates the permissions for the standard Identity within the application. While this approach does have security controls that can be applied, it can become difficult to control and/or separate an Identity's day-to-day work from their more sensitive administration work that can affect the organization as a whole, or groups of users within the organization.
Below is a screenshot of the HPAM configuration screen, followed by a functional description of the options available within the feature.
HPAM Functionality
General Information
| Name | |
| This field is reserved for the name of your HPAM configuration. It is suggested that you name your configuration something of significance related to the types of (privileged) accounts defined within, or if you have a set operational naming convention for privileged access, you should name your configuration the same. This helps to ensure IGA Administrators are referencing the correct process and governance nomenclature utilized by the organization. | |
| Description | |
| As always, the description is important to help bridge the business to technical gap. Use it to your advantage! | |
Properties (on Request) |
|
| Authorized Membership | |
| Enabling "Authorized Membership" will provide system owners with the ability to govern which qualified HPAM administrators are able to request the privileged accounts associated with a specific system. It's important to note that an organization can qualify a user as an "HPAM Identity". This designation will allow users of this type to request HPAM accounts. The "Authorized Membership" feature provides system owners to review the qualified HPAM Identities and select and authorized them for individual accounts to request. This governance feature provides granularity within the privileged access process to ensure that only qualified administrators are able to request access to certain accounts instead of allowing all privileged administrators to request any account in the pool just because they are identified as an HPAM Identity. For example, this can be used to ensure that only Active Directory Administrators will be able to request domain admin privileges, removing the capability of database administrators from requesting Active Directory administrative access. | |
| Authorized Period | |
| Enabling this option will enable the ability for IGA Administrators to define set authorization periods when an account is available for check out. You can define durations when a privileged account will be visible and available for checkout. This feature can be used strategically and was built to enable specific privileged accounts for a set duration for scenarios such as contractors coming in to help an organization for a certain period of time. This feature, when enabled, provides for offering up privileged accounts for check out during those short windows. IGA Administrators can specify unique, purposeful privileged accounts for these scenarios while keeping their internal privileged accounts available (and authorized) for internal use only. This approach can also help with delineating an audit where contractors come on board for segments of time. | |
| Requires Approval | |
| Enabling this option will require approval before the privileged account will be assigned to the requesting Identity. | |
Properties (on Relinquish) |
|
| Reset Password | |
| When a privileged account is revoked from an HPAM Identity, Fischer provides for the ability to scramble the password. This governance mechanism is in place to ensure that the previous person who checked out the account will not know the password upon revocation. This is an important feature to employ when leveraging Fischer's HPAM solution as it protects the integrity of the privileged account allocation process and forces privileged Identities to check the account out again and set the password again before they are able to use it. This provides the necessary oversight related to privileged access to ensure a privileged account is not checked out indefinitely and IGA administrators have control over the reuqest and assignment process. Without this option, while the account would be revoked, the password set by the assigned privileged Identity would not be changed and even without checking the account out again, they would know the password of the account (since they set it) and would be able to circumvent the request process and maintain unauthorized privileged access which can create a security situation for any organization that does not scramble the password upon revocation. | |
| Lock Account | |
| IGA Administrators and System Owners can also employ an account lock upon revocation. This would keep the account locked until the account was once again assigned to a privileged user. This compliments the scrambling of the password and provide the ultimate control over privileged accounts, which is an important step of the governance process. | |
Durations |
|
| Account Duration | |
| The account duration can be configured to display the duration option to requestors in Days, Hours and Minutes. This provides IGA Administrators with the granularity necessary to determine how long they want certain types of privileged accounts to be checked out. Given the feature allows for multiple (privileged) account types to be configured for request, this feature is very powerful and risk-aware to ensure different privileged accounts can be controlled independent of others depending on the access granted by the privileged account. | |
| Available Durations | |
| This combo box allows for IGA Administrators to define the values allowed to be requested when checking out a privileged account. The best practice is to leverage the "Hours" value for most scenarios. This can help to limit the exposure that privileged accounts bring with them and ultimately provide the necessary governance to properly track and enforce this high level of access on a consistent basis, in manageable time chunks. | |
| Configuration Durations | |
| Configured Durations will be selected from the Available Durations. This combo box is what requesting HPAM Identities will be able to select from. Remember to consider the context of the accounts to be checked out for each HPAM account type defined. You will want to take into consideration the risk associated with the available privileged account. | |
| Default Duration | |
| The Default Duration will be the initial value shown in the combo box when a requestor is checking out an account. | |
| Connected Systems | |
|---|---|
|
|
|
| Name | |
| The name field correlates to the Name field within the Connected System definition. | |
| Beneficiary (Notification) | |
| This is the notification that will be sent to the person which will be assigned the privileged access once access has been granted and the privileged account has been assigned. | |
| Requestor (Notification) | |
| This is the notification that will be sent to the person which is requesting the HPAM account, in some cases the entity requesting the account may not be the beneficiary, hence Fischer has provided the ability to send separate notifications. Often times, the requestor and the beneficiary are the same and you may not need to configure both notifications. | |
| System Owner (Notification) | |
| Configuring this notification will ensure that the System Owner of which the privileged account is being assigned is informed of the checking out and assignment of an account on his or her system. | |
| Revocation (Notification) | |
| This notification will be sent to the HPAM Identity currently in possession of a privileged account as well as the HPAM System Owner. This is an important notification to set to ensure communication regarding the revocation makes it to the appropriate personnel and that proper oversight can be tracked for privileged accounts. | |
| Expiration (Notification) | |
| This notification can be configured to be sent upon revocation of the account to the holder (the "beneficiary"). | |
| Expiration Frequency | |
| IGA Administrators can set how far in advanced of the revocation event they want to send the notification to the privileged account holder. Note this is a single notification that is sent, so as you plan for the frequency, ensure you are aware that this will only be sent once. The recommendation is to define this notification to be sent as close as possible to the actual revocation date of the privileged account. | |
Post Process Workflows |
|
| Add | |
| As with other features, Fischer has extended the privileged access feature to allow for the invocation of an external process AFTER the HPAM event (assignment or revocation) has occurred. This can help for systems that may not support native account locking via a Fischer connected system, or if any other business process needs to be executed beyond a notification as a result of an HPAM event occuring. This particular feature will invoke the defined worklfow upon assignment of the account. | |
| Remove | |
| As with other features, Fischer has extended the privileged access feature to allow for the invocation of an external process AFTER the HPAM event (assignment or revocation) has occurred. This can help for systems that may not support native account locking via a Fischer connected system, or if any other business process needs to be executed beyond a notification as a result of an HPAM event occuring. This particular feature will invoke the defined worklfow upon revocation of the account. |
Comments
0 comments
Please sign in to leave a comment.