Robot and Developer user accounts - best-practice for security

[BjörnGranacher1]

Hi are there any best practice how to handle robot and developer user or any practical experience to share? (I use ROBOT1, ROBOT2 etc. for robot user and DEV1, DEV2,...for developer personal users to illustrate below.)   Background: assume we are a team of 5 developers who work as a team on 3 automation projects in parallel and implementing 50 projects in various business areas (Finance, HR, Sales) and various systems throughout the year. A development proejct incl. UAT takes 4-6 weeks, later on we have to expect weekly need for some kind of support / bugfix / analysis. we have virtual machines (VM) as Interactive Client for each developer and virtual machines for each Robot (public resource PC)   Assumptions: AD is suggested for BluePrism authentification in corporate environment in order to develop you need to be logged in to the desktop of the interactive client VM and start BluePrism there you should be logged in with a user that has credentials for accessing the applications which are mostly single-sign-on (SSO) nowadays development for RPA also needs to be done in productive systems, we ahve realized that it will not be possible to do all in test systems due to various reasons (replicating specific data, different HTML id in PRD systems needs re-spying) - we see it more like training a new employee: you start training in a test system, but once they start working in the productive system you might want to look over the shoulders and assits to finish your training Requirements: traceability of transactions in our corporate systems (named accounts) - not allowed that 5 developers use the same Robot traceability of changes in BluePrism scripts Concerns, Questions, Ideas: we can't keep adding authorizations to each developer user: they would have very powerfull users which is a risk already we do not want that they permanently have the authorization to issue credit notes authorizations needed for different processes might be conflicting and even not allowed by our Internal Controls due to seggregation of duties need (e.g. issue and approve a credit note) still we need to be able as developers to quickly get access (in a controlled / logged way?) to a process for support / analysis / bugfixing if developers start using the robot like ROBOT1 during development, then we do not see in BluePrism save comments, who saved a change (it is anonymous) - and at that time they can use the client system like SAP with the robot account    

[Denis__Dennehy]

Hello Bjorn, There is a lot to discuss there.  Delivery Methodology, Testing Strategy, Safe develolpment against production data, Access Control, Logical Access Model, Change Control, etc.... all these are large Robotic Operating Model (ROM) discussion points that could be a seperate meeting.  You need to reach out to a ROM Architect/experienced Blue Prism consultant if you need to dive into these topics in detail - if you do not already have someone available to your team with that kind of expertise/experience I recommend you raise that as an issue with your management team. As a starting point I can recommend this high level testing approach guide:  https://portal.blueprism.com/system/files/2017-09/Testing%20Approach_0.pdf You need to discuss with your IT Security/Risk team and the system owners what your requirements are and come up with a development/change strategy that they are happy with.  This could be a process for requesting and quickly receiving temporary production data access when required.  For a banking client developers have no access to production systems but the do need to develop against procuction data - to do they need access to a business user/SME who does have the access they require and who monitors their production access at all times.

[MelissaSuarez_G]

You don't need to give additional access to the developers to use single sing on applications.  1) You can create one user per area: for example, an Accounting Processor user that only has access to the GL and a Human Resources Processor that has access to the HR system. Please note that this are not bot, these are standalone user credentials to access those systems. 2) Store those credentials in the Credential Manager the Blue Prism. This way you can assign the credentials to specific processes. 3) To launch single sing on applications with these credentials, create a business object that execute the ""runas"" command in CMD, passing the username and password. This method ensures that the developers only have access to those credentials when they are working with the process that needs them.