Hierarchy access control in Amazon Connect (Preview)
This is prerelease documentation for a service in preview release. It is subject to change. |
You can restrict access to contacts based on the agent hierarchy assigned to a user. This is accomplished by using permissions such as Restrict Contact Access. In addition to these permissions, hierarchies can also be used to enforce granular access controls for resources, such as users, in conjunction with tags. The remainder of this page contains additional details on configuring hierarchy-based access controls (currently in preview).
Background
Hierarchy-based access control enables you to configure granular access to specific resources based on the agent hierarchy assigned to a user. You can configure hierarchy-based access controls by using the API/SDK or within the Amazon Connect console for supported resources.
Currently, the only resource that supports hierarchy-based access control is Users. This authorization model works in conjunction with tag-based access control, allowing you to restrict access to users, so that they can only see other users belonging to their hierarchy group and who have specific tags associated to them.
Hierarchy-based access control using the API/SDK
In order to use hierarchies to control access to resources within your AWS
accounts, you need to provide the hierarchy’s information in the condition element
of an IAM policy. For example, to control access to a User belonging to a specific
hierarchy, use the connect:HierarchyGroupL3Id/hierarchyGroupId
condition key, along with a specific operator like StringEquals
to
specify which hierarchy group the user must belong to, in order to allow given
actions for it. The supported condition keys are:
-
connect:HierarchyGroupL1Id/hierarchyGroupId
-
connect:HierarchyGroupL2Id/hierarchyGroupId
-
connect:HierarchyGroupL3Id/hierarchyGroupId
-
connect:HierarchyGroupL4Id/hierarchyGroupId
-
connect:HierarchyGroupL5Id/hierarchyGroupId
Each represents the id of a given hierarchy group in a specific level of the User’s hierarchy structure.
For more detailed information on hierarchy-based access control, see Controlling access to AWS resources using tags in the IAM User Guide.
Hierarchy-based access control using the Amazon Connect console
To use hierarchies to control access to resources within the admin website of your Amazon Connect instance, you need to configure the access control section within a given security profile. For example, to enable granular access control access for a given user based on the hierarchy they belong to, you would need to configure the user as an access controlled resource. In this case, you will have two options:
-
Enforce hierarchy-based access control based on the user’s hierarchy:This will ensure that the user being given access can only manage users that belong to his hierarchy. For example, enabling this configuration for a given user will enable them to manage other users that either belong to their hierarchy group or a child hierarchy group. This will ensure that the user being given access can only manage users that belong to his hierarchy. For example, enabling this configuration for a supervisor will enable them to manage other users that either belong to their hierarchy group or a child hierarchy group.
-
Enforce hierarchy-based access control based on a specific hierarchy: This will ensure that the user being given access can only manage users that belong to the hierarchy defined in the Security Profile. For example, enabling this configuration for a given user will enable them to manage other users that either belong to the hierarchy group specified in the Security Profile or a child hierarchy group.
Configuration limitations
Granular access control is configured on a security profile. Users can be assigned a maximum of two security profiles that enforce granular access control. In this case, the permissions will become less restrictive and act as a union of both permission sets. For instance, if one Security Profile enforces hierarchy-based access control and another one enforces tag-based access control, the user will be able to manage any user that belongs to the same hierarchy or tagged with the given tag. If both tag-based and hierarchy-based access control are configured as part of the same Security Profile, both conditions will need to be met. In this case, the user will only be able to manage users that belong to the same hierarchy and tagged with a given tag.
A user can have more than two security profiles, as long as those additional security profiles do not enforce granular access control. If multiple security profiles are present with overlapping resource permissions, the security profile without hierarchy-based access control will be enforced over the one with hierarchy-based access control.
Service linked roles are required in order to configure hierarchy-based access control. If your instance was created after October 2018, this will be available by default with your Amazon Connect instance. However, if you have an older instance, refer to Use service-linked roles for Amazon Connect for instructions for how to enable service linked roles.
Best practices for applying hierarchy-based access controls
Applying hierarchy-based access control is an advanced configuration feature that
is supported by Amazon Connect and that follows the AWS shared responsibility model. It is
important to ensure that you are correctly configuring your instance to comply with
your desired authorization needs. For more information, review the AWS shared
responsibility model
Ensure that you have enabled at least view permissions for the resources that you enable hierarchy-based access control for. This will ensure that you avoid permission inconsistencies that result in denied access requests. Hierarchy-based access controls are enabled at the resource level, which means that each resource can be restricted independently. It is important to carefully review the permissions that are granted when hierarchy-based access control is enforced. For example, enabling hierarchy restricted access to users and view/edit permissions security profiles, would allow a user to create/update a security profile with privileges that supersede the intended user access control settings.
When logged in to the Amazon Connect console with hierarchy-based access controls applied, users will not be able to access historical change logs for the resources that they are restricted on.
When trying to assign a child resource to a parent resource with hierarchy-based access control on the child resource, the operation will be denied if the child resource does not belong to your hierarchy. For example, if you try to assign a User to a Quick Connect but you don’t have access to the user’s hierarchy, the operation will fail. This is however not true for disassociations. You would be able to disassociate a user freely even with hierarchy-based access control enforced assuming you have access to the Quick Connect. This is because disassociations are about discarding an existing relation (as opposed to new associations) between two resources and is modeled as part of the parent resource (in this case, the Quick Connect), which the user already has access to. As such when enforcing hierarchy-based access control on a user resource, it is important to be thoughtful about the permissions granted on parent resources since a user could be disassociated without his or his supervisor’s knowledge.
As a best practice, you should disable access to the following resources/modules when applying hierarchy-based access controls within the Amazon Connect console. If you do not disable access to these resources, users with hierarchy-based access controls on a particular resource that view these pages may see an unrestricted list of users. For more information on how to manage permissions, see List of security profile permissions.
Modules | Permission to disable access |
---|---|
Contact search | Contact search - View |
Historical changes/Audit portal | Access metrics - Access |
Real-time metrics | Real-time metrics - Access |
Historical metrics | Historical metrics - Access |
Login/Login out report | Login/Login out report - View |
Rules | Rules - View |
Saved reports | Saved reports - View |
Agent Hierarchy | Agent Hierarchy - View |
Flow/Flow module | Flow modules - View |
Scheduling | Schedule manager - View |