In a previous blog post, I asked the question: “What Does ‘Privileged Identity Management’ Mean When Everyone is a Privileged User?” Today, I’d like to explore a related topic: If everyone is, to some degree, a privileged user, how does that change the way we think of managing privilege in the enterprise?
Historically, people have equated “privileged users” with “administrators” of systems or applications because these are the people who have the rights to do things that could potentially have serious consequences. On a Linux system, the “superuser” (usually the “root” account) has unfettered ability to do absolutely anything on that system. In a Windows environment, the equivalent is the local administrator (or domain administrator, who can do anything across all Windows machines within the Active Directory domain). These all-powerful accounts are necessary in order to perform system maintenance, to start/stop services, to view or retrieve data files, etc. So people started sharing the password to these accounts so that different people could perform their job functions (e.g. backup the system, administer a database, retrieve log files, restart a service, upgrade the operating system, etc.). However, with great power comes the risk of abuse or mistakes, and businesses recognized the need to control and track who could use these privileged accounts. As a result, vendors built password-sharing solutions to allow different users to share access to accounts.
This gets back to the question I posed earlier: What does “Privileged Identity Management” mean when everyone is a privileged user? If everyone, is a privileged user to some degree, then we need to look at the state of the art for managing privileges for users as opposed to sharing passwords to share accounts. Certainly, there is a place for sharing super-privileged accounts, but this should be limited to emergency situations (ex. local console access is required for severe system down scenarios). In other cases where privilege is needed, then those privileges should be managed based on the role of the user. For example, if a user needs to simply restart a web server, why should that same user also have the privileges to delete critical system files or perhaps install a keystroke logger?
Another way of thinking about this is that there are “user accounts” that account for all users and their respective job roles, and there are “non-user accounts” that are shared accounts that must be managed for emergency or perhaps legacy scenarios. Eighty percent or more of enterprise use of privilege scenarios deals with “user accounts.” How are you managing and auditing privileges for those accounts?