Don’t Run into Security Risks by Managing Robot Accounts the Wrong Way
Robotic Process Automation (RPA) is one of the hot IT topics these days. By using robots that automatically perform tasks that humans executed before, companies unlock a significant potential for cost savings. AI (Artificial Intelligence) helps in realizing RPA solutions. However, if done wrong, the use of RPA can cause severe security challenges.
It starts with the definition of the accounts used by the robots. There appears being a tendency of creating sort of “super-robot” accounts – accounts, that are used by various robots and that accumulate entitlements for multiple robots. Obviously, such approaches stand in stark contrast to the Least Privilege principle. They are the direct opposite of what IAM and specifically Access Governance are focusing on: Mitigating access-related risks.
The only argument for such solution is that management of the robot accounts appears being easier, because accounts can be re-used across robots. But that is just a consequence of doing the management of RPA wrong.
RPA accounts are factually technical (functional) user accounts, which are anyway heavily used in IT. In contrast to common approaches for such technical accounts, there is an individual “user” available: The robot. Each robot can run in the context of its own account, that has exactly the entitlements required for the (commonly very narrow) tasks that robot is executing.
Using standard functions of IGA, robots can be managed as a specific type of user. Each robot needs to be onboarded, which is a process that is very similar to onboarding (and changing and offboarding) an external user. There is nothing fundamentally new or different, compared to existing IAM processes. The robot should have a responsible manager, and changes in management can be handled via well-defined mover processes – as they should be for every technical account and every external user.
The entitlements can be granted based on common entitlement structures such as roles and groups, or – in sophisticated IAM infrastructures – be based on runtime authorization, i.e. Dynamic Authorization Management.
As for technical accounts, in the rare case that someone else needs access to that account, Privileged Access Management (PAM) comes into play. Access to that in some sense shared account can be handled via Shared Account Password Management. Behavior of the accounts can be tracked via the UBA (User Behavior Analytics) capabilities found in several of the PAM solutions in the market, in specific UBA products, or in other solutions.
There are no identity and access related functionalities specific to RPA that can’t be managed well by relying on standard IAM capabilities of IGA (Identity Governance & Administration) and PAM. And if the accounts are managed and associated per robot, instead of creating the “super-robot” accounts, RPA is not an IAM challenge, but IAM helps in managing RPA well, without growing security risks.
Get access to the whole body of KC PLUS research including Leadership Compass documents for only €800 a year
Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live trainings.
AI for the Future of your Business: Effective, Safe, Secure & Ethical Everything we admire, love, need to survive, and that brings us further in creating a better future with a human face is and will be a result of intelligence. Synthesizing and amplifying our human intelligence have therefore the potential of leading us into a new era of prosperity like we have not seen before, if we succeed keeping AI Safe, Secure and Ethical. Since the very beginning of industrialization, and even before, we have been striving at structuring our work in a way that it becomes accessible for [...]