What is a privileged user?
It should be a simple question; the two words give you a big hint on where definition should end up. It is a user and quite obviously this user got one or a sum of privileges to do “important stuff”, but so I’m asking you: are you a privileged user?
Well, let us try to figure out the answer together and see if the solution will match the very first thought you had after reading the question.
Let us start by giving a simple definition of a privileged account: yes, you notice immediately, I switched from the word “user” to “account”. No, I won’t confuse you, let’s make it simple: I define the user as the physical identity, in other words that is you. The account is the combination of username/account and any other information that actually enables you to get into “stuff” such as: applications, your corporate network, servers, network devices, etcetera. Or it’s the simple combination I just defined, but not linked to any “physical identity”, an example of which is an application account used to run tasks on a scheduled basis.
Therefore, a privileged account is one of these username/password/permissions “identities” with such a level of access that actually puts this “sum of combinations” in a position to be potentially dangerous for the ecosystem from where, funnily enough, the account itself gets those privileges assigned.
So we have a combination of identities: the physical one (let’s say your basic account), the admin account (the one named for the administrative operations on the systems) and the privileged identity (the one that is built-in and cannot be reconciled to an administrator in a native way).
Our usual governance solution (IGA) tends to take into account the first two identities: the basic and the named admin. Most of the IGA solution takes the term governance to mean who you are, what you have access to and why, but never to include which other identities you will have access to and how. Through the use of this privileged access, your “basic” identity will be able to see things that it should not be allowed to see. For example, think of someone who has access to the HR system as a privileged account and is thus in a position to get sensitive information out of it. The PAM (privileged account management) solution is there for this specific purpose, but lack of that level of analysis and governance that an IGA solution may warrant. Indeed, knowing that a user has access as a root or an administrator that has requested and checked out the password of a built-in account is important, but what if we may also link this information to what we obtain when we compare the “basic” account entitlement or risk factors with the actual request? What if we may evaluate the “central identity” taking into consideration all the information we have? A privileged account governance solution should be aimed to do this, to approach the ecosystem, integrating and including all the identities; not just those that are “under governance“ by design such as the basic or the named admin accounts.
In other words, to simply help you to answer to the question:
Are all of your identities under governance?
Sr. System Consultant at Dell