关键是对真正需要的操作只实现两人控制。

日常任务

可以编写日常任务，例如部署应用程序版本或应用安全补丁。一位系统管理员可以创建脚本，但在另一位系统管理员审核并批准之前，它无法运行。重新启动应用程序服务器或部署最新的应用程序版本等常见任务可以具有重复使用的预先批准的脚本。非标准任务需要定制脚本。

为此，需要某种工作流管理系统。你也许可以使用像 Trac 这样的票务系统，在像 JIRA 这样的东西上构建一个定制的系统，像 Puppet 这样的配置管理工具可能有一些有用的功能。两个系统管理员不需要在本地；他们可以远程工作。

系统的设计应使尽可能多的日常维护自动化 - 计划的日志轮换等。

诊断

系统管理员可以在没有两人控制的情况下对日志进行只读访问，前提是日志屏蔽了敏感信息。他们还可以拥有一个低权限帐户来查看状态页面，并运行诸如 top 或 ps 之类的命令。这允许单个系统管理员诊断问题 - 他们可以远程工作。他们可以通过将脚本作为例行任务提交来进行补救。但是，在某些情况下这是不可能的，因此需要紧急访问。

紧急访问

有时会出现严重问题，您只需要以 root 身份登录 SSH。要保持两人控制，此时您需要两个人。在实践中，它们需要在物理上彼此相邻。实现访问控制的一种简单方法是为每个配对设置一个帐户，其中每个系统管理员知道一半的密码。您可以使用自定义 PAM 模块创建更智能的系统，甚至可能需要来自两个系统管理员的单独智能卡。

登录后，由系统管理员负责维护两人控制。他们必须在发出命令之前检查彼此的命令，如果其中一个需要退出，则锁定终端。

目标应该是很少需要紧急访问。

开发环境

直播环境只需要两人控制即可。一个单独的系统管理员可以完全访问开发环境——前提是不存在实时数据。他们可以在开发环境中尝试一项任务，执行一些测试，消除错误。只有当他们有一个工作脚本时，他们才会将它提交给另一个系统管理员以供批准。

结论

如果这一切都完成了，我相信你可以用大约 25% 的开销实现强大的两人控制。让它成功依赖于各种东西（如自动化维护），无论如何都是好的做法。如果一个系统如此敏感以至于需要两人控制，那么最好把所有的基础知识都搞好！

我从未见过这在商业或政府环境中实施。我见过的最接近的是一个在线银行平台，大多数系统管理员通常没有 root 访问权限。要执行一项任务，首先要对其进行详细计划，然后在变更控制系统上进行批准。为了实施更改，系统管理员在有限的时间内获得了 root 访问权限。此外，还有少数高级系统管理员拥有永久 root 访问权限，以防万一。这种安排比我通常看到的要好得多——尽管它不能完全由两人控制。

这里有很多很好的答案。归根结底是个人决定，组织过程也是整个过程中非常重要的一部分。

我想指出另一个更易于管理的解决方案。免责声明：这是我正在开发的解决方案。

privacyIDEA是一个双因素管理系统。或者更广泛地说，它是一个身份验证管理系统。一种可能是，您还可以将抽象身份验证令牌“ 4-eyes-token ”分配给用户帐户。通过这种方式，您可以设置某个用户帐户或某些命令 (sudo) 需要两个或更多人的身份验证。这些用户可以使用密码或一次性密码硬件令牌（如 yubikeys）进行身份验证。

好的副作用是，您会在privacyIDEA 中获得经过数字签名的审核日志，这样您就可以知道哪两个人在您的两人规则中采取了行动。

如何以最小的开销实现两人控制？

TL;DR这可以使用一个特殊的sudo命令来完成，该命令需要第二个人来批准每个命令，并结合一个漂亮的白名单来使更安全的命令更方便。重要的是每个命令都得到两人规则的批准，否则保护很容易被破坏。

两人规则实施选项：

不受限制的根访问

root暂时启用访问

一个小的根脚本可能需要第二个人（用户 A）进行授权，然后才能sudo用于代理系统管理员（用户 B）

1. 用户 A：（通过作业enable-sudo user-b
   自动添加具有/etc/sudoers时间限制或计划删除的条目at）

2. 用户 B：sudo do stuff此时将开始工作

不幸的是，一旦用户 A 授权访问，用户 B 很容易添加后门。这可以像重新添加或启动单独的服务一样user-b简单/etc/sudoers。

一旦有人获得root（因为它是“不受约束的”），就不可能强有力地执行安全规则，因此您应该秘密监控最有可能绕过的可能性，并在两人之后开始看起来很奇怪时提醒另一个（更受信任的）系统管理员启用sudo.

• 意外at或cron工作
• 意外的后台进程仍在运行
• 意外启动脚本

并且不要确切地告诉他们您正在使用什么保护措施。这将有助于抵御明显的后门，尤其user-b是在不熟悉现有保护措施的情况下，但不会阻止user-b决心制造麻烦的人。

基于命令的两人规则

创建您自己的 版本sudo，它会在第一人建议的任何命令时向第二人发出警报，并具有批准或拒绝的能力。

我不会在这里详细介绍实现细节，但实现起来相当简单。

在这种情况下，后门必须隐藏在所提供的文件之一中，例如要安装的软件更新。

文件编辑 vim

您的自定义版本sudo不应允许启动直接文件编辑命令。如果有人键入oursudo vi，则oursudo必须启动一个特殊的脚本来编辑文件。

1. 将文件复制到某个/tmp位置（随机生成的文件名以防止符号链接攻击）
2. 以减少对非帐户vim的权限启动（因此不能使用其中的“另存为”功能绕过此包装器）rootuser-bvim
3. 保存完成后，当前diff文件的一个更改为user-a.
4. 获得批准后，将批准的文件从目标位置复制/tmp到目标位置。

物理障碍

要求物理访问才能获得root访问权限有助于使user-b正在做的事情变得可见。根据办公环境的不同，团队可能对正在发生的事情user-b有所了解，和/或user-b可能不太愿意在该环境中造成麻烦。不过，这取决于这种访问的频率。

缺点：root=不受约束

正如您从我提出的想法中可以得出的那样，似乎没有万无一失的保护措施可以防止后门安装。root访问旨在不允许这样做。

白名单命令方法（限制root访问）

最好的办法是创建可用命令的白名单。（sudo有能力提供）一开始这确实会产生很大的开销，但随着您学习常用的命令，最终可能会变得更加实用。

部署应用程序更新

您的应用程序不应以 root 访问权限运行。那些必须通过单独的代码审查系统，然后可以包括来自批准 VCS 提交的更新。

修补[打包]软件

这是不能被限制的，所以我建议使用上面概述的基于命令的两人规则。

故障排除

可以通过 允许使用安全工具sudo，然后使用基于命令的两人规则进行修复。

这里有一种非常相关的加密技术，称为秘密共享：

秘密共享（也称为秘密分裂）是指在一组参与者之间分配秘密的方法，每个参与者都被分配了一份秘密。只有当足够数量、可能不同类型的共享组合在一起时，才能重建秘密；单独的股票是没有用的。

因此，您可以采用的一种策略是：

• 所有管理操作都需要使用加密密钥进行身份验证。
• 密钥在您的n 个管理员之间以n种方式拆分，并使用两份阈值来恢复密钥。
• 每个管理员都必须对所有其他人保密。

我不知道那里有很多秘密共享的实现。请参阅此问题以获取参考。我要补充一点：

• HashiCorp 的 Vault是一个客户端/服务器分布式系统，用于存储和检索机密（例如，应用程序必须访问的密码）。Vault 数据库的内容使用不存储在任何地方的密钥进行加密，而是拆分为一组具有可配置数量和阈值的秘密共享。为了重建密钥，他们有一个他们称之为开封的过程，其中必要数量的股份的所有者必须每个人输入他们的股份。

所以有可能用 Vault 做点什么来实现这一点。关键思想是：

• 将所有管理员凭据保存在 Vault 实例中，该实例仅在需要时打开，在不需要时立即密封；
• 编写所有任务的脚本，这样管理员就永远不会看到实际的凭据，只会看到他们的 Vault 主密钥共享。