Access to attributes and privileged accounts
This section shows you how to define user groups to control access to attributes and privileged accounts.
User groups define which privileges a group of users can have, and user classes define membership criteria for each user group.
Getting started
Requirements
You require the "Manage user groups" administrative privilege in order to access the Privileged access to systems, Access to profile and request attributes and Access to resource attributes menu items.
Navigation steps
Use the page to add and configure user groups. To navigate to this page:
Click the menu item that corresponds with the user group you want to configure:
Manage the system > Security > Access to resource attributes
Manage the system > Security > Access to profile and request attributes
Manage the system > Security > Privileged access to systems
Search for, or select a user group, or click Add new...
Define:
User groups and profile and request attribute groups
Use the Manage the system > Security > Access to profile and request attributes menu to determine profile and request attribute groups a user group can see or edit.
The following built-in user groups are configured for profile and request attributes:
ALLAUTHORIZERS | All users designated as authorizers of requests. |
ALLIMPLEMENTERS | All users designated as implementers of requests. |
ALLRECIPIENTS | All recipients of access change requests. |
ALLREQUESTERS | All requesters of access change requests. |
ALLREVIEWERS | All users designated to complete an entitlement or configuration review. |
You can also define permissions via the Workflow > Attribute groups menu.
Users must have rights to at least one attribute group in order to view or edit attributes in Bravura Security Fabric .
Users can be members of multiple user groups, and are assigned the highest combination of privileges assigned to the rules to which they belong.
For example:
User A belongs to recipient group B with read permissions on attribute group C.
User A belongs to recipient group D with write permissions on attribute group C.
User A in effect has both read and write permissions on attribute group C.
The highest combination of rights is also assigned when a user is both recipient and requester, when using the Requests app. That is, when a user is tracking a request and:
Has requested an change for somebody else, their rights as a requester are in effect.
Is the recipient of a change requested by somebody else, their rights as a recipient are in effect.
Has requested a change for themselves, their combined rights as requester and recipient are in effect.
Similar rules apply for users who are both requester and authorizer.
If an attribute group contains required attributes that can only be edited by authorizers, the requirement is ignored until the request reaches the authorization stage. If authorizers then fail to provide values for the required attributes, the request is automatically denied.
Caution
When a user group is assigned write-only permissions to attributes with restricted or boolean values, they in effect cannot view or edit those attributes. If you require a user to be able to edit attributes with restricted or boolean values, you must assign them read/write permissions.
User groups and resource attributes
Use the Manage the system > Security > Access to resource attributes menu to determine what resource attributes a user group can see or edit.
The following built-in user groups are configured for resource attributes:
ALLUSERS | All users |
ENTITLEMENT_EXPIRY_CONFIG | Users who can configure entitlement expiry days |
GROUP_CREATE_USERS | Users who can create groups |
You can also define permissions via the Manage the system > Resources > Resource attribute groups menu.
Membership to resource attribute user groups is defined by user classes.
User groups and managed system policies
Applies to Bravura Privilege
Use the Manage the system > Security > Privileged access to systems menu to determine what managed systems and managed system policies a user can see or edit.
You can also assign access controls from within a managed system policy.
The following user groups are configured by default for privileged access to systems:
ALLAUTHORIZERS | All users designated as authorizers of requests. |
ALLRECIPIENTS | All recipients of access change requests. |
ALLREQUESTERS | All requesters of access change requests. By default this group has permission to request authorization to view the administrative password of any managed system. |
IT_SEC_USERS | IT security users who are pre-approved to check-out managed account access. |
MSP_REPORT_USERS | Product administrators who can generate and view reports relating to Bravura Privilege , including password check-in/check-out, password expiry, and password history. |
Product administrator user groups and permissions
The permissions granted by a user group work in conjunction with administrative privileges. Product administrators with the "Manage managed system policies" administrative privilege have the right to access managed system policies configuration pages. You add those product administrators to one or more user groups, which control which managed system policies the members have access to. For each managed system policy, the user group can be granted permissions listed in Privileged system access controls .
These permissions apply to administrative menus and to reports, such as the Password change history report. That is, a product administrator who has the " Manage reports " administrative privilege can only generate reports for managed system policies to which he has view access.
Product administrators can belong to more than one user group. The maximum privilege is given when a product administrator belongs to multiple user groups, as privileges are cumulative.
Privileged system access controls
Permission | Description |
|---|---|
View properties for this policy | Allows product administrators to view the managed system policy and its members. |
Modify properties for this policy | Allows product administrators to modify the managed system policy and its members. |
Pre-approved check-out of managed accounts | Allows members to access accounts currently managed by this managed system policy . |
Randomize/override password of managed accounts | Allows members to randomize and override passwords currently managed by this managed system policy . |
Request check-out of managed accounts | Allows members to request access to accounts currently managed by this managed system policy , including account set access requests. Members can use shared account sets, however, they cannot modify them. |
View information: Managed systems/Managed accounts/Group sets/Account sets | Displays the managed system, managed account, group sets, and account sets as hyperlinks throughout the request to allow members to view system/access information from a pop-up window. |
Pre-approved check-out of group sets | Allows members to access group sets currently managed by this managed system policy . |
Request check-out of group sets | Allows members to request access to group sets currently managed by this managed system policy . |
Pre-approved search of recorded sessions | Allows members to be auto-approved to search this managed system policy ’s recorded sessions. |
Pre-approved download of recorded sessions | Allows members to be auto-approved to download this managed system policy ’s recorded sessions. |
Pre-approved view of recorded sessions | Allows members to be auto-approved to view this managed system policy ’s recorded sessions. |
Run reports about privileged access for this policy | Allows product administrators to run reports on recorded session information for this managed system policy . |
Access password history for managed accounts | Allows members to view the password history for a managed account when access is checked out. |
Modify all account sets in this policy | Allows members to modify account sets managed by this managed system policy , whether shared or not. |
Manage systems on this policy | Allows product administrators to modify properties of systems currently managed by this managed system policy . |
Caution
Use of pre-approved options is not recommended for security reasons.
Regular user groups and permissions
Bravura Privilege allows regular users to request temporary access to administrative passwords on managed systems, for themselves or other users, using authorization workflow. See Privileged system access controls for details about workflow.
When you create a Bravura Privilege managed system policy, Bravura Security Fabric automatically gives all users, via the built-in ALLREQUESTERS user group, the permission to:
Request check-out of managed accounts
View information: Managed systems/Managed accounts/Group sets/Account sets
Request check-out of group sets
This default behavior can be changed in the Modules > Privileged access menu. Disable the IDARCHIVE PASSWORD REQUESTED and IDARCHIVE GSET REQUESTED settings. This changes the default behavior so that users must be assigned to a user group with appropriate permission.
You can also override this default behavior via a group’s Access control tab. For each managed system policy, the user group can be granted permissions listed in Privileged system access controls .
If regular users have ” Pre-approved check-out of managed accounts ” and ” Request check-out of managed accounts ” permissions, they are able to check out managed accounts without needing authorization. They can also update the end time of their checkout.
Note
If enabling ” Pre-approved check-out of managed accounts ” for managed system policies with the SSH key authentication type, check-out requests are automatically approved instead of pre-approved.
Regular users can belong to more than one user group. The maximum privilege is given when a user belongs to multiple user groups - privileges are cumulative.
Note
Regular users who are not also members of an administrative group cannot modify managed systems, or randomize or override passwords. Users must have appropriate product administrator capabilities to manage managed systems.
Assigning user group access controls
To define access controls for a user group:
From the user group information page , click the Access control tab.
Select Grant and Deny checkboxes for attribute groups or managed system policies as required.
Click Update.
You cannot modify the access controls of a user group of which you are a member.
Defining user group membership criteria
A user group can have one or more users as members. Membership criteria for a user group is defined by selecting or creating user classes. Users must be participants of the selected user classes in order to have membership in the user group. Each user class must be mapped to the participant type: requester or recipient.
To define user group membership criteria:
From the From the user group information page , click the Membership criteria tab.
To define user group membership criteria by:
Selecting existing user classes:
Click Select… .
If required, click Edit
for any user classes that need to be modified before you select them.Enable the checkboxes for the user classes you want to select as membership criteria, then click Select.
Set the Participant mapping to either the:
REQUESTER who can view and edit other users’ attributes
or
RECIPIENT whose attributes are being viewed and edited
Creating a new user class:
Click Create a new user class.
See User Classes for full details on how to create a new user class.
Repeat this step until you have defined user group membership.
If you have selected multiple user classes, select whether the participants must match All of the user classes or Any of the user classes .
The default setting is All of the user classes .
Once you have finished defining membership criteria, you can click the Test tab to Test membership of individual users, or List members.
Membership of non-built-in user classes can be cached to improve performance. There are options to recalculate or invalidate the cache on the user class configuration page.
Note
In a replicated environment, cache recalculation can only be performed on the instance which runs psupdate.
Configuration Notes
In some cases it may be easier to prevent certain users from accessing specific objects, rather than trying to find a way to grant limited user access.
Use the ACL DENY ENABLE setting on the Manage the system > Policies > Options page to allow product administrators to deny read and write permissions to objects.