May be justified to use generic and shared user accounts in order to segregate and reduce risk?

Question

Imagine I have a group of users called "support" that participates solving different kinds of problems. Each user has a nominal username like jsmith that has not much privileges but additional everyone in this group uses two different user accounts: operator and administrator. Each account has different additional privileges. Administrator has administrator privileges and operator can login to a lot of different systems in order to perform different operations.

Now I'm trying to eliminate the use of generic usernames like operator and administrator in order to have accountability and be able to identify who has performed an action. However, would security be improved if I give operator and administrator privileges to each nominal account? I think the security would decrease because one user account would accumulate a lot of privileges (like using root in everyday work).

How can I do this accountability and maintain segregation and security?

Is best practice to create users adm_jsmith and oper_jsmith? This would affect usability because users would need to change between users every time they need to do a different action.

Answer 1

You are right, just giving permissions to each user that needs them only ocasionally is not a good option. Sharing privileged accounts isn´t an option too.

Since you did not specified your environment, I will provide two answers:

Linux/*nix

You could give each administrator the option to escalate to a higher privilege level on his operational account. Tipically, on Linux, you do that by using sudo to run privileged commands. You give such permission to an user by adding it to the sudoers group/file (Ex: https://help.ubuntu.com/community/Sudoers).

The default on most Linux systems is to ask again for the password of the user to allow him to run administrative commands using sudo. However, you may want to ask for a root account password (not the best option since it is a shared password, but may be OK if at least you don´t allow direct root login, making sure one can only use it if he has also a operational account with sudo priviledge).

But if you want even better protection you could ask a different password per user, as described in https://unix.stackexchange.com/questions/94626/set-sudo-password-differently-from-login-one.

Therefore, using sudo each user will need to know his own password to log in (as operator), and also confirm the password to escalate to an administrative mode when needed. If you want to add extra protection, you can even ask for a second password to escalate to administrative privileges (root or second password per user). But each user will have its own (and only one) user and you will have good traceability.

Windows

You should give each admistrator an administrative account, and set UAC to require the user to enter the password again when running administrative operations. That would be the equivalent of Linux with sudo. However, you can not set a different password to be asked, so using two accounts for each administrator looks like the only option if ou want to really isolate the operational and admin accounts. Take a look on this guide from Microsoft, where they recommend exactly that: https://technet.microsoft.com/en-us/library/cc700835.aspx

Separating Administrative and User Accounts for Administrative Users For each user who fills a service administrator role, create two accounts: one regular user account to be used for normal tasks and data administration, and one service administrative account to be used only for performing service administration tasks. The service administration account should not be mail enabled or used for running applications that are used every day, such as Microsoft Office, or for browsing the Internet. Always give the two accounts different passwords. These precautions reduce the exposure of the accounts to the outside world, and they reduce the amount of time that administrative accounts are logged on to the system.

Answer 2

You could build a login that creates a session with a certain user, who then get's some sort of tracking cookie or thing-ie. With this, you still could trace the user and his actions.

Usually you do this by using a framework like Play! or Spring. Examples for Play! can be found here and here. The process is similar on different frameworks: User logs in - gets validated, gets some sort of trackable ID. You then could create a log-file that keeps track of the users actions, or you simply check via the ID, if a user is allowed to do a specific task.

---

A word on the different roles:

Roles are there for a reason. Keeping the roles separate and only for their specific duty helps to reduce problems with trackability and security. A user only should have the rights for a certain job. This is also known as POLP - Principle of least privilege.

If all your users have admin AND operator privileges, tracking a users actions and security become hard to achieve.

A simple example might be a malicious co-worker, he simply deletes or modifies imporant data and then wipes out all the log-files that could reveal his identity. Since he has all the rights he needs, this is very easy to do. Having "normal" users and "admins" would create a barrier, if the user is not an admin, he might be missing the rights to delete the log-files, so he still might be able to delete the data, but now the admin can track him down.

Maybe implementing more roles / groups that contain ONLY the rights they need to do a certain job would be helpful as well?

Answer 3

In this case, it depends on what you want to achieve.

The idea behind segreation, for example not running as root, but as a limited user for everyday activites, is that if the account is compromised for some reason, the damage is contained to the rights that the limited user account has. Segreation does NOT protect against malicious users, in the same way sudo wont protect against malicious admins! If a malicious user with too much rights wants to do anything malicious, that user simply switch to the required account for his tasks.

What segreation is designed to protect against, is: One example is if the user accidentially leaves a terminal logged in and a unauthorized user takes over the terminal, or if a malicious software or virus are installed on the terminal due to careless web surfing, then the virus or unauthorized user can only do whatever the limited user account can do.

Based what you described, I interpret operator is just more of "global user", eg, the normal "user" can only login at their own terminal, but "operator" can login at any terminal as "user".

---

In that case, I would recommend assigning the operator right to the user, and then use some sort of privilege escalation in case a administrator account is required, for example "sudo" or something similiar to that.

---

If you want to have both traceability and segreation, I would recommend creating 2 user accounts for each user. One with the normal rights, and one with the increased rights. I do not see any risk in combining operator and administrator accounts into one account, for those users that have both operator and administrator access, as these accounts should only be used for housekeeping tasks anyways, not for everyday use.

Actually, in these cases, it might even be better to let the operator/administrator accounts be individual accounts, and have a group/shared user account, like "User". Since the user accounts does not have any special rights, it does not matter if someone compromises it.

Answer 4

I think there are multiple options for different purposes:

1. Do you want to avoid your users use the same password for daily work and for administrative tasks (in order to limit the security threats if the commonly used password is stolen)?
2. Do you want to limit the "power users" on some system while enabling them on others?
3. Do you want to track (audit) you users better?

Generally speaking, I think that having all the operations performed by a user tracked and managed on a unique account has many pros, both to simplify (less complexity means usually less flaws), to have consistent management and to track and relate the activities.

That is, for point 3 I'd definitely remove the shared users.

For the points 1 and 2, having multiple accounts for each user is an option, but it's not optimal for point 3 and for management and simplification mentioned just above.

Anyway, as said by CristianTM, on Microsoft it's the best practice: https://technet.microsoft.com/en-us/library/cc700835.aspx
On Linux you might want to have a different password, the root one, to be requested for privileged activities (and you could have the root password centralised), but it won't help for the point 2 by itself (you might than define what systems a user can sudo and what not).

However, the best design I can think is based on the concepts of bastion hosts and authentication proxies; basically, the idea would be to create different bastions to access different privileged services. Bastion are very often authenticated with independent passwords via OTP (much more secure than passwords), and the services behind them can be also segregated from a network prospective.
By giving access for some user to a bastion/proxy (probably 2 hosts at least for redundancy) configured to access a specific service that authenticate users via OTP, you could achieve all the 3 points above greatly (with a dedicated logging/auditing in these servers). Also on Windows, you could define that authentication for users on bastion hosts via RDP is performed with OTP and not with the usual password.

Answer 5

Eliminate the shared user accounts ASAP.

The only time a shared user account is necessary, is when multiple people need to access an archaic system that only supports one (or maybe only a few) user(s).

The only roles worth developing are likely going to be the user and administration roles (and maybe several administration roles.)

The user role is likely to be heavily limited, good for logging onto workstations, performing job duties, and what not. You need to find out what the bare minimum is for the general user population, and create that role.

The operator role, not sure what that is used for exactly, is used to log into multiple systems to perform several different "operations" per your description. Do all operators connect to all of these systems? Do some of them connect to only a few while others connect to a few others, and some connect to all? If there is variance in who connects to what, abolish the role and authorize users on a case-by-case basis (Principle of Least Privilege) to prevent users from obtaining unneeded or unauthorized access to systems and resources. This will enhance your security.

The Administrator account should be broken down into a few groups/roles specific to which systems (or groups of systems) that need to be administrated. They also should focus primarily on administrative duties only. If you are in a Windows AD environment, disabling remote logon will force users to use their regular user accounts to connect to remote systems (with permissions generated from the "operator" account's information) and then use their administrator account (jsmith_a for example) for UAC elevation. Administrative groups should only be granted to this _a account, and only the groups/roles for the systems the user is authorized to administer. This has a double effect of preventing a compromised administrator account from being used to remote to multiple systems, and it also prevents a single compromised user account from making administrative changes.

This will undoubtedly create a "paper trail" for your "operators and administrators" and increase the level of accountability in your environment. Also consider expiring the administrator account (_a) password more frequently than the user account password is expired. A lengthy password history and minimum password age of 1-3 days should suffice to keep even the most dedicated password rotators from cycling their passwords ;) (not that that doesn't show up in the logs anyhow. . .)

hat's a good place to start.