Fhyujk

Alice and Eve work for Bob. Alice is a very good worker who does exactly what Bob asks her to do. Eve is a criminal mastermind hell-bent on destroying Bob's company.

Alice and Eve both share the same account.

Eve logs into the account and uses it to sabotage an important business process. The audit log captures this action.

How does Bob know who sabotaged his company? He has to get rid of the bad actor, but can't fire both of them, because his company depends on the work that they do. He could fire just one, but he has no way of knowing which one is his friend and which one is his enemy.

If Alice and Eve had separate accounts, Bob could be sure that Eve was the one who did the sabotage. Eve might even avoid doing the sabotage, if she knows her account will be audited and she will be caught.

EDIT: Adding from comments:

If Eve quits, you now need to reset the password on every account she had access to, rather than just disabling her personal accounts. This is much harder to manage, and you will miss accounts.

Additionally, it removes your ability to have granular control over access. If Alice should be writing checks, and Eve should be signing them, you essentially have no technological way to enforce that if they share the same account.

Also, it makes it harder for a given individual to notice malicious changes to their environment. Alice knows what files are on Alice's desktop. Any new files will likely raise a red flag for her. Alice doesn't know what files are on Alice and Eve's shared desktop. It is likely new files will be met with a shrug and an assumption that another user put it there, not a malicious actor.

You should use separated account in all contexts (security on the top).

Adonalsium example show you because it's required.
There are some rare situations where it is "not possible" or "not usefull" ...

Examples:
"not possible" (legacy protocols/applications)
"no relevant" (anonymous actions)

If it is no possible, but you need to identify, you have to mitigate the risk adding more source informations as possible (e.g. connection info, connection time, etc ...)

You can check ISO 27001 Risk Assessment Methodology, ISO 31000 Risk management as starting point to answer to your question "Why avoid shared user accounts?"

Real story, happened at a friends workplace (jurisdiction: Germany):

A coworker of his rudely insulted clients via her company e-mail. She was fired for this. She did go to court. There, her lawyer made the court aware of the fact that the employees shared their passwords (for instance, for answering a client´s mail in the absence of a certain colleague).

The Judge ruled that there was no good proof that that the person in question was really the one who sent the insulting e-mails. The person had to be rehired and compensated for the lost wage.

The typical answer is accountability, traceability, etc; In other words to be able to know who exactly did what.

A shared account has n potential people doing something but all that you have points to one account doing that thing.

This problem is usually lifted by making sure someone is legally responsible for the activities of this account. This may or may not be feasible, and you may not have someone taking responsibility for the actions of others.

This problem often occurs when you outsource some monitoring activities - the account which does the monitoring tasks should be contractually in charge of that company, which is responsible for its actions.

If you cannot assign a responsible person, it is then up to management to make a decision based on the risk: not having a service vs. not knowing who does what with that account.

I only know one exception to that rule. There is one single machine that is shared by several users, and the following assertions are all true:

• one and only one of those users is in charge of this machine at any moment


• the account can only be used on the local machine - disabled via network

This may happen on 7/7 24/24 systems. In that use case, you still keep an acceptable imputability by knowing the user that was present at a specific moment, provided you could set the above second rule. But in fact, it is equivalent at having an account with no password, and only using physical security.

Best practices are nowhere "defined", that's what the term means. A best practice is simply an established way of doing things that most people think is the best way.

It goes the other way around. Once a "best practice" is dominant, usually someone on a standards board decides to put it into some ISO or other norm. It then rests there, usually without explicit reasoning, or a circular reasoning pointing out that this is best practice.

The reasons for this particular practice are likewise practical ones. If Alice and Bob share an account and something bad happens, they will both point to the other person and you have no way of figuring out who did it. With personal accounts, they'll claim it was compromised, but then you at least have a single point to investigate further.

There are also explicit requirements for accountability in many sub-fields such as compliance, and they play into this.

Another issue not yet mentioned is that if someone receives notification that their account is being accessed or has been accessed at a time when they're aren't/weren't accessing it and wouldn't expect anyone else to do so, they're much more likely to sound an alarm than they would be if they thought that the account might have been accessed by someone whom they'd authorized.

Given that the number of cases where it may be necessary for someone to authorize someone else to perform some particular action on their behalf, it would be extremely helpful if services could at include a means by which accounts could authorize and revoke secondary credentials with limited rights. That would allow the system to report which credential was used to access an account, thus allowing someone to better distinguish expected from unexpected activity.