爱丽丝和夏娃为鲍勃工作。爱丽丝是一个非常优秀的工人，他完全按照鲍勃的要求去做。Eve 是一个犯罪主谋，一心要摧毁 Bob 的公司。

Alice 和 Eve 共享同一个帐户。

Eve 登录该帐户并使用它来破坏重要的业务流程。审核日志会捕获此操作。

Bob 怎么知道是谁破坏了他的公司？他必须摆脱坏演员，但不能同时解雇他们，因为他的公司取决于他们所做的工作。他可以只开一枪，但他无法知道哪个是他的朋友，哪个是他的敌人。

如果 Alice 和 Eve 有不同的帐户，Bob 就可以确定 Eve 是破坏者。如果夏娃知道她的帐户将被审计并且她会被抓到，她甚至可能会避免进行破坏。

编辑：从评论中添加：

如果 Eve 退出，您现在需要重置她有权访问的每个帐户的密码，而不仅仅是禁用她的个人帐户。这更难管理，您会错过帐户。

此外，它消除了您对访问进行精细控制的能力。如果 Alice 应该写支票，而 Eve 应该签署它们，那么如果他们共享同一个帐户，你基本上没有技术方法来强制执行。

此外，它使特定个人更难注意到对其环境的恶意更改。Alice 知道 Alice 的桌面上有哪些文件。任何新文件都可能为她带来危险信号。Alice 不知道 Alice 和 Eve 的共享桌面上有哪些文件。新文件很可能会被耸耸肩，并假设另一个用户把它放在那里，而不是恶意行为者。

真实的故事，发生在朋友的工作场所（司法管辖区：德国）：

他的一位同事通过她的公司电子邮件粗鲁地侮辱了客户。她因此被解雇了。她确实去了法庭。在那里，她的律师让法庭知道了员工共享密码的事实（例如，在某个同事不在的情况下回复客户的邮件）。

法官裁定，没有充分的证据表明该人确实是发送侮辱性电子邮件的人。必须重新雇用该人并赔偿损失的工资。

士气：用户帐户的一项功能是区分用户，使他们的行为可审计。只有私人帐户才能实现该功能。

您应该在所有上下文中使用单独的帐户（顶部的安全性）。
Adonasium 示例向您展示，因为它是必需的。有一些罕见的情况是“不可能”或“没用”......

示例：“不可能”（遗留协议/应用程序）“不相关”（匿名操作）

如果不可能，但您需要识别，则必须尽可能降低风险添加更多源信息（例如连接信息，连接时间等......）

您可以查看 ISO 27001 风险评估方法、ISO 31000 风险管理作为起点来回答您的问题“为什么要避免共享用户帐户？”

典型的答案是问责制、可追溯性等；换句话说，能够知道谁到底做了什么。

共享帐户有n 个潜在的人在做某事，但您所拥有的一切都指向一个帐户做那件事。

通常通过确保某人对该帐户的活动负有法律责任来解决此问题。这可能可行，也可能不可行，并且您可能没有人为他人的行为负责。

当您将某些监控活动外包时，通常会出现此问题 - 执行监控任务的帐户应以合同方式负责该公司，该公司对其行为负责。

如果您无法指定负责人，则由管理层根据风险做出决定：没有服务与不知道谁使用该帐户做什么。