Our audit team requires our credentials to be unknown.

[TLovett77]

We're running into an audit issue. Our audit team doesn't want anyone to know the credentials that our bots use, which is understandable--the fewer people who know the credentials, the more secure everything is.

The problem is, if we elevate from QA into production, then we receive some sort of error, we typically need to log into the relevant system(s) to troubleshoot, which of course, requires us to use the bots' credentials.

If you've run into this issue, how has your team gotten past it?

------------------------------
Tracy Lovett
RPA Developer I
Synovus
------------------------------

[david.l.morris]

Hi Tracy,

We're doing the exact same thing. We have a small team who both develops and supports production. So, in our case, it's even worse than just 'someone' knowing the bot passwords. What we did was in two steps. First, we made a Process Automation using Blue Prism that runs once a week, generating and changing the passwords for our Bot NTIDs. We have had this in production for a little while now, and it is working well.

At this point, auditing/compliance would be satisfied, but now just as you mentioned it is difficult to troubleshoot and/or fix problems that occur on a bot user's profile that requires logging in to fix it.

So, our Second step was to integrate CyberArk. I should mention that when I say using CyberArk, I'm not referring exactly to the same solution that Blue Prism suggests when they talk about CyberArk. As I've seen, that's a SOAP-based web service that involves AIM server and blah blah. Instead, we're using CyberArk's PAS (Privileged Account Security) Web Services using REST API. When our Process Automation goes to change passwords for the various NTIDs, the new password is stored in both CyberArk and in Blue Prism's Credential Manager. We didn't want to rely solely on CyberArk or reasons I won't go into now, so we store the passwords/credentials in both places.

Then, we have (or soon will have) trusted people who are allowed to log into CyberArk and click 'Show Password' so that they can see the current password and help us troubleshoot by logging into a VM under a bot's profile or whatever. After they finish troubleshooting or fixing the problem, we run the Password Management automation again so that they will not know the password. CyberArk (along with probably any other secrets manager) has an audit log and the capability to add/remove access to people quickly for this kind of thing.

This solution may seem a bit convoluted, but that's kind of a thing when trying to satisfy compliance. 😃

------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------

[TLovett77]

Awesome. You've given me a direction to start down. Hopefully, something similar will work for us.

Thanks!

------------------------------
Tracy Lovett
RPA Developer I
Synovus
------------------------------