Separate administrator accounts are becoming a normal part of access policies in enterprises. Expert Matthew Pascucci explains why this is a good idea and how to implement it.
I have to create a policy for separate administrator accounts for all employees that require privileged access. In a community of hundreds of employees, their access includes Windows, Linux, Oracle, SAS and more. I’m considering creating separate admin accounts, but I’ve received some pushback. Have you seen such policies implemented successfully in larger organizations? Are separate administrator accounts the best way to go?
Creating a policy for separate administrator accounts isn’t something unusual; it’s actually becoming a standard. Creating a separate account for administrators allows for the proper separation of duties and security on accounts that have full access to systems and data.
This can become an issue within a larger company — not because it can’t be done, but because it’s going to take more work in order to complete. A lot of this work might also change the mindset of the administrators and management.
I’ve seen large companies create separate accounts for administrators in a few ways. One way was creating accounts for systems with read-only access to review configurations and access so they didn’t accidentally create an issue within a system when reviewing the application. On the flip side, I’ve also seen the same thing happen where accounts were created that were only used when the administrator was about to make a change to a system, or if he needed to elevate his rights.
Either way, it’s recommended that there be two accounts created for administrators that are managing systems, and especially those systems that have access to sensitive data or privileged access to systems. One should be used to make changes, and the other should be read-only. You can even remove administrator accounts from particular users that don’t need them, but who still need read access to a system.
Many times, I’ve seen users — particularly Windows admins, but it could happen with any OS — run their privileged account as their normal user account during the day. In this example, Windows domain admins are one click away from having their account compromised via phishing, cross-site scripting or other attacks. There are always complaints about admins not being able to perform their work without elevated access throughout the entire day, but, in most cases, it’s just not true. Admins can use run as from their workstations if they’re Windows admins, and sudo or jump boxes for Linux-based administrators, to limit the exposure of using these privileged accounts at all times.
There are many tools out there right now in the privileged access management space that help with this problem, but, many times, this comes down to a cultural attitude shift. Upper management needs to see the need and risk of privileged accounts being used to browse the internet, and the danger that can arise from that. I’m never in favor of using fear, uncertainty and doubt to scare someone into making a decision, so the more facts you have to make your case to management, the better it’s going to be for you.
I’d recommend getting a few pilot users from each group and setting up a second account for each with use cases. Getting the details upfront can go a long way in educating users and management on the risk of not having separate administrator accounts.