Access Controls
There are many aspects of access which need to be considered in any RPA deployment. The primary purpose of this page is to discuss access controls for Blue Prism itself, however, it is also worth noting the other access requirements needed in any Digital Worker implementation:
Target System Access Model
- Defines how Blue Prism Digital Workers and Developers will access target systems
- Access may be via Single Sign-On so influenced by Windows Access Model
- Requirement for digital worker credentials management policy
Windows Access Model
- Defines how the digital worker will access Windows
- Who will manage the Windows credentials – Operations Team or Digital Workers?
- Infrastructure considerations if Login Agent is required
Environment Access Model
- Defines how the production VDI's will be accessed
- Access requires console software with audit trail
- Access to be controlled and limited to specific users and specific VDI’s
The Logical Access Model
The creation and maintenance of a Logical Access Model (LAM) for Blue Prism access in an organisation is imperative due to the following reasons:
- Promotes the segregation of duties and prevents an “everybody admin” scenario, while defining clear responsibilities within Blue Prism across all environments
- The LAM is a documented record of the users or teams that have access to Blue Prism functionality
- The LAM can be used to check that the permissions or access rights applied within Blue Prism match what is defined in the LAM
- The LAM is a documented record of user or team access in Blue Prism that can be reviewed by the Governance Board
- Provides an offline overview of the permissions or access rights to Blue Prism, without the need to manually access each Blue Prism environment one by one
- Offers the opportunity to align the Blue Prism LAM to the security policies and standards in your organisation and to enforce the security requirements
- Provides a documented reference useful for audit purposes and incident management
Creating/Updating the Logical Access Model
Blue Prism recommends each organization creates and implements their own Logical Access Model immediately after a Blue Prism environment is created. This should be included as part of any Blue Prism environment set-up.
The default user roles defined within the product should be replaced with user roles defined by the organization’s own Logical Access Model (LAM), derived from the Robotic Operating Model (ROM). This action should be carried out for each Blue Prism environment, with the differences in permission requirements i.e. Development, UAT and Production, being considered.
Note: Runtime Resource and System Administrator user roles cannot be changed.
The process of creating or updating the LAM should involve all stakeholders, including the Head of RPA, the RPA Governance Board and IT team, while considering the segregation of duties in the organization. This process at a high level will look something like this:
Your Blue Prism LAM should be approved by the Governance Board and should comply to the organization’s security and standards. As the RPA organization grows, the LAM will need to be reviewed and updated before applying any access changes to the environments, by using either the suggested process or by using the chosen internal standard change management methodology. This will ensure the LAM definition reflect the environments setup.
In the case of a Blue Prism upgrade from a previous version, an appropriate review and update of the LAM is also recommended as part of the upgrade project, due to the potential impact of permission/access right changes in newer versions of Blue Prism. Your LAM should document all user accounts and roles defined across all environments.
The following steps are recommended:
The Blue Prism Logical Access Model (LAM) template can be downloaded from the Blue Prism Documents section of the portal or at the bottom of this page. Please ensure that you use the template that mirrors for the version of Blue Prism you are using.
Before starting work on your own Logical Access Model, read the Instructions sheet of the downloaded template and familiarise yourself with the template, Blue Prism user roles and permissions. If you are using V6.3 or later of Blue Prism, you should also familiarise yourself with the access rights that can be applied to groups.
Blue Prism access is role-based and configured independently for each environment, allowing specific users to have different access dependent on the environment. This functionality supports the ability to restrict any user having ubiquitous access across all environments. User roles should only be granted enough permissions to effectively perform their role.
Allowing more permissions than is necessary is a security risk. Users given more than one role will accumulate the maximum permission of all those roles. Please review the Blue Prism help for details on how to create user accounts, available in the product. The Users sheet in the Blue Prism Logical Access Model template can be used to define user accounts set up in different environments. The roles in the template are standard Robotic Operating Model (ROM) roles and they should be replaced with the user roles defined by your ROM if they differ. Note that the Runtime Resource and System Administrator user roles cannot be changed within Blue Prism.
If a user account needs to be granted multiple roles, please review the segregation of duties. Blue Prism recommends assigning only one role to each user account.
Blue Prism supports using a mixture of bespoke and out-of-the-box security roles to allow each user to be granted the appropriate access in each environment.
It is necessary to establish any logical access restrictions that will be implemented to provide an appropriate level of control and governance across the various environments. These may include:
Further guidance on establishing appropriate logical access permissions is provided as part of the Blue Prism Robotic Operating Model documentation available on the Blue Prism Portal.
The Role Permissions spreadsheet in the Logical Access Model template defines the permissions of each user role within Blue Prism, across each environment. The provided template LAM is a “standard” and recommended set of user roles and permissions for each environment. Additional roles and changes to your LAM can be applied, ensuring your LAM reflects your organisation's roles, and complies with your internal security policies and standards. When defining user's roles permissions, reflection on the segregation of duties is strongly recommended.
You should update the Roles Permissions spreadsheet in your own LAM to reflect the intended roles and roles permissions in your organisation. Along with your defined roles, your LAM should also include the Runtime Resource and System Administrator roles. This ensures your Blue Prism environments and LAM are synchronized and useful for audit purposes. These roles should be only assigned to the appropriate user accounts. For information on how to create user roles and select permissions, please review the Blue Prism help provided in the product.
If you are using version 6.3 or later of Blue Prism you have the option of using the Multi-Team Environments feature. The Multi-Team Environment concept of Blue Prism version 6.3 brings a greater level of access control, allowing the definition of access rights in addition to role permissions.
In previous versions, user roles defined system-wide permissions for users, whereas in version 6.3, all Processes, Objects, and Resources reside in groups, and access rights can refine permissions for groups.
Please note, the role permissions in the Blue Prism product were adjusted from version 6.3 onward, therefore a review and update of your LAM should be part of your upgrade to version 6.3, even if you decide not to use the new Multi-Team feature.
For more information on Multi-Team Environments check out the Related Documents section at the bottom of this page.
Additionally, a new Web Service Consumer role is pre-defined in version 6,3 with access to only the "Execute Process as Web Service" and "Execute Business Object as Web Service" permissions.
This role has been created to simplify applying the correct permissions to user accounts that will be used to consume Blue Prism Processes and Objects exposed as Web Services. This role grants the necessary execute permissions without providing access to areas of the Blue Prism interface, such as the Control Room.
The role can be used in conjunction with the capabilities of Multi-Team Environments to restrict which exposed Objects and Processes can be accessed by user accounts assigned to this role. If bespoke user roles are needed for technical purposes such as this, remember to document them in your LAM following review by the RPA Governance Board. A separate LAM template exists for version 6.3 or later and is available below.
This LAM contains: Instructions, Role Permissions, and Users sheets, as well as sheets outlining what a Multi-Team setup might look like for each environment; development, UAT and production. The Instructions sheet of this template explains the multi-team sheets in more detail. If you choose to use Multi-Team Environments, the Users sheet should reflect which team(s) each user is a member of.
The go-live of a complex process often poses several risks that must be recognised and minimised. Intensive support and supervision in the production environment during the stabilisation phase is crucial for the success of the go-live. This is precisely where it is often agreed to establish Hypercare support.
The Hypercare phase is typically a short-term provision of professional support resources. The Hypercare group should only be created to place processes or business objects that need emergency fixes applied to them. This group should offer a set of recommended permissions to deliver efficient support with minimal run-in time during and after the go-live.
The Hypercare group should be used as it strengthens the audit trail. Approval should be given before moving something in/out of the group. Items are only in this group temporarily until stable running is confirmed before being placed back into its appropriate location. Developers can’t edit anything in production except for the items in this group – maintaining security but providing flexibility.
After your own Logical Access Model (LAM) document is created or updated, it should be approved by your RPA Governance Board and should comply to your organisation’s security and standards.
After defining your LAM and having the approval of the RPA Governance Board, the user roles within Blue Prism should be updated accordingly. Please reference the Blue Prism help for more details, by searching for “User Permissions”, “User Roles” or “User Settings”.
In the first step, the user roles and their permissions will be updated in System/Security/User Roles section of the product, to reflect the Role Permissions sheet within your LAM. This needs to take place for each Blue Prism environment.
As the second step, the user accounts and their assignment to user roles will be defined in System/Security/Users section of the product, according to the Users sheet of your LAM, across all environments. If you are using Blue Prism version 6.3 or later and are using the Multi-Team Environments feature, the defined access rights in your LAM will need to be applied to the respective environments.
After your LAM is implemented in all environments, the defined user accounts and user roles should be tested across all environments. You should ensure each user role has enough permissions to perform their role effectively. It is recommended to test at least one user account for each user role across all environments.
When the Logical Access Model implementation is successful tested, the LAM document must be communicated and published appropriately in your organisation. Any planned changes to the LAM should follow the described process and be reviewed before implementation by the RPA Governance Board, while adhering to your internal change management methodology.
We created the Digital Exchange (DX) to help businesses find and consume best-of-breed AI, cognitive and disruptive technologies quickly and easily. By making it simple to get connected to the world’s most forward-thinking companies, we’re “democratizing AI”— and showcasing the art of the possible.
Whether you’re looking to explore your options with a Digital Workforce, upskill your existing Digital Workforce, or share your own cutting-edge technology, the DX is for you.