In the days of old, we used to love throwing around acronyms. OK, maybe times haven’t changed that much, but they sure have in the world of managing privileged users. It used to only focus on what a user could or could not do, but it has evolved to also control what they can access and even how they have the ability for that access.
What is a Privileged User?
Let’s start with the original concept of a privileged user. Perhaps this was a user who could do something special like pay an invoice over a certain dollar amount. Maybe this privilege was the ability to modify a quote after a salesperson created it. Or what about the help desk having the ability to help the person calling in by taking control of their PC or even impersonating them to solve their issue? All of these are instances of Privileged Identity Management (PIM) and now part of what we call Privileged Access Management (PAM).
What did this solution solve for? Well, the first instance that comes to mind is controlling and recording when a user needs access to a Windows or Linux Server. The user wouldn’t even need to know the passwords of those servers, he would only need to provide proof of his identity, hopefully utilizing 2FA. This solved compliance issues as well as checking off those boxes around audit findings, although it did require some logging and additional capabilities to do correctly. This capability was what mainstream PAM vendors focused on and have become quite good at, but a privileged user needs to keep moving on.
As the mainstream PAM solutions evolved and focused on user access, the issue around fine grain entitlements became even more segregated. Take the concept of an accounting person being able to approve and pay an invoice up to $5,000; what needs to be done to pay an invoice over that amount? In this one-time event, the GRC world introduced the concept of firefighter access to allow for temporary approval of the fine grain entitlements to enable such an ability. But how do those fine grain entitlements tie back to privileged user access? How are they maintained and controlled?
We all look to traditional users when thinking PAM, but what about Service Accounts, Bots and IoT? All of these “Identities” are forms of accounts that need to provide a specific capacity and in many cases are in themselves Privileged. Many of these accounts operate and function just like a human being but they are far from being that. How does traditional PAM solutions handle these?
And what about those times when emergency access was needed for large numbers of users? That’s when traditional PAM really shines. PAM allows a large number of users’ immediate access to protected resources with the simple flip of a toggle (group) for those urgent needs. By utilizing password vaulting and session management, companies now had the means of ensuring the right people had access to the right resources. Emergency averted… or was it?
So, what does cloud migration mean for PIM/PAM?
Like the rest of the modern computer enterprise, services started to move outside the castle walls, over those moats, and into the ether to that place called the cloud. What did this mean to those traditional PIM/PAM solutions? How do we actually control that access now? What are we controlling access to anyway? Servers? Applications? Infrastructure? Consoles? Who knows…it’s the cloud! This move to the cloud introduces a whole new problem in Privileged Access Management.
With the evolution to cloud provided applications, the person who signed up for the service is now the privileged user. This user can delegate admin rights to anyone she wants, which can spiral out of control. It is commonly referred to as an island of identity, and it creates an inherent lack of control. So how does a traditional PAM solution solve for this? They really don’t!
With the movement of your infrastructure to the cloud utilizing AWS, Azure, and GCS, you now have to deal with consoles that can let people do all kinds of crazy stuff that traditional PAM was not designed to control or even report on. These changes require you to rethink how you are going to attack the problem and ultimately think about how a cloud problem requires a cloud solution.
In my next post, I am going to explain how this can easily be solved utilizing a solution purpose-built for the cloud. I will discuss how cloud PAM works and why you should be considering this in your enterprise.