Is it bad practice to have a 'super admin' - so they effectively bypass security checks in your system?

Question

I have seen a few system designs in my time and one question keeps cropping up:

Is it bad practice to have 'super admin' - single user - or 'super admin' privileges in your system?

By that I mean giving one or many users 'super admin' privileges so they basically never see a "you do not have permission" error and are never prevented from doing anything in the system.

This is from a security standpoint mainly - If someone somehow managed to login to an account that has 'super admin' privileges (when they shouldn't have access) they could wreak havoc as they can change anything in the system

Answer 1

I would split my answer into two parts:

Super admin in general

When designing a system, you do not want to get into a situation where no one is able to access the system and manage it as needed, especially when an emergency is at hand.

On the other hand, you probably don't want a single entity to be able to manage and control all properties of the said system.

For this particular reason, many designs include this role but with a limited assignment.
This role is mostly assigned to either "non-personal" user account that its credentials are safeguarded by a quorum of trusted people.
Another option is to have this role assigned to multiple trusted users with an approval quorum to apply sensitive modifications.

Sometimes similar account is also created as a local account (in case the others are governed by an organization's centralized identity management platform such as Okta) to allow out-of-band access in case of emergencies.

Users assuming super administrative privileges at all times

Per security design principles, you want to avoid excessive privileges assigned to personnel.
Your system should support access packages and roles to bind for the specific actions they need to perform over your system.
Let them perform whatever operations they need, nothing else.

It doesn't necessarily mean you are giving them the key to your castle if they are system administrators. You can put senstive operations under additional security measures such as just-in-time access with an external supervisor to allow the grant, etc.

Answer 2

You've confused a few different topics into one:

• is it bad practice to have the permission set?
• is it bad practice to assign the permission set to an active user?
• is it bad practice to have weak controls on the reserved user with super-admin permissions?

Of course it is not bad practice to have the permission set if the system requires it. Unix/Linux has had the "root" user for decades. So, the existence of the permission set is not an issue.

Multiple standards, regulations, and advice beg people not to assign super-user permissions to a normal active user. Active normal users tend to interact with untrusted data and code, which is open to compromise. This is why there is an open debate about developers having local admin permissions. They need it (#1), but it is a massive exposure (#2).

Which brings us to your third point, which becomes self-answerable. Because you should not have super-user permissions on a normal user, then you should also have increased protections on that account, since your whole point is to protect it from compromise. In other words, make it impossible for a non-authorised person to log in with that permission set. So, the security of the system is extended to the security of the account.

Answer 3

As a general rule, having some sort of all-powerful role (or user) is probably poor design. However, practicalities should be taken into account.

The root user on a Linux system is all-powerful on that server. They can do absolutely anything - read/modify the RAM or files in use, or shutdown the server or anything else. You could well argue they're a "super admin", and we do generally refer to the root user as a super user.

However, that root user cannot do anything to other servers, or the network infrastructure or anything else "outside" the server in question. Thus, they're not a "super admin" of the whole system - just of that one server. This is an example of segmented access - which is absolutely something that a new systems design should incorporate.

The principle at play here is to allow a human to do the work they need to do (especially in an emergency), but not to allow the human to do more than that. If there's a problem with Server1, then they can do whatever they need to fix Server1, but can't go and mess with Server2 (to work on Server2, they'd have to authenticate again, and separately with Server2). The point being that just because they somehow got the credentials to log on as the super user on Server1 doesn't immediately give them the ability to do it on Server2 - so they can't accidentally do something to Server2, and nor can a hacker use one point of entry to move "sideways" into other areas of the system.

Moving on to non-emergency situations, you have to allow administrators (and users) to work on the system. For that, you'd ideally want to give them a reduced set of permissions, so they're not a "root" type super user anywhere, but can still perform the likely maintenance and other activities that they need to do. This is generally called the Principle of Least Privilege, where you give people just enough permissions to do their work, but nothing more than that (and ideally no where near enough to do any damage).

Assuming an administrator is using their least-privilege credentials/account, then they can do their normal job. However, if a non-normal task comes along (like an emergency, or a special request), then they can (temporarily) elevate themselves to a higher level of privilege (perhaps a super user). This "elevation" step should be an explicit action so that it's something they must have deliberately done, and couldn't have done accidentally (you probably want to log that it's taken place too, so you have an audit). The point here being that if they go on to do something bad, they can't claim it was an accident, or their finger slipped or whatever. When they've finished the special task, they should go back to their normal (restricted) level of permissions. To that end, some "privilege elevations" are time limited so you have to keep renewing them if you want to stay in the higher level - as a means to avoid having people stay at higher privilege indefinitely.

Answer 4

OSes in common use all have such "super admin" capabilities. Clearly, the regular user does not have such privileges and even the administrative user(s) should minimize their use of escalated privilege. This principle is called "least privilege" and some of the other answers cover it in detail. Minimizing privilege use is obviously a "best practice" for the security conscious administrator.

However, even following these best practices does not eliminate the presence of the "super admin" capability. This capability is removed in high security specialized operating systems with a practice called "two person control." Typically, admin accounts have all the normal privileges one associates with them now, but a separate security admin account also exists. Regular admin accounts make security-sensitive privilege changes BUT those changes do not go into effect until approved by a security admin account. A security admin account cannot make privilege or ownership changes, but only approve or disapprove changes made by a regular admin. By restricting those roles to different people, you prevent a single person from having the "super admin" capability.