我的建议是从保管箱中删除秘密并将它们存储在其他地方。您的说明必须易于任何人阅读，但它们可以包含有关如何访问正确保护的数据部分的说明。这使您可以将事物的可访问性方面与安全方面分开。

一旦您可以单独考虑安全性，您就可以开始提出真正的问题，即您需要多少保护这些密钥？这是一个业务逻辑问题，因此请咨询您的管理层。你可能会：

• 拥有每个人都知道的文件的密码
• 设置一个包含多个密码的文件，以便每个人维护自己的副本。
• 使用 M-out-of-N 算法锁定文件（数字等效于需要两把钥匙来解锁保险箱）。
• 有一个 M-out-of-N 算法，需要一个“主”密码，无论哪一组人解锁文件，并且一个主密码物理上保存在一个防篡改的保险箱中，您不时检查它。

在这里使用创造力。 无论您做什么，将“指令”与“敏感信息”分离后，您就可以适当地保护信息，然后提供有关如何在以后获取该数据的说明。

您的业​​务逻辑决策还将包括正常运行时间问题。如果您的生活出现问题，那么在业务受到影响之前，另一个管理员必须接管您的工作多长时间？考虑在服务器出现故障时，您希望这些指令和敏感信息的复制程度如何。当我管理服务器并需要存储有关如何从备份中恢复它的说明时，我使用服务器自己的 wiki 存储该信息以便于查看，但显然这在故障情况下不会那么有用，所以我也在该机器的开发 VM 上有一个副本，将其副本保存在 3 台单独的 PC 和打印输出上。我不能保证打印输出会保持最新状态，但我确保我能做到最好。

这也指出了一些并不总是受到公共汽车计划影响的东西：优雅降级。并非所有被公共汽车撞到的场景都涉及被公共汽车撞到。有些涉及您只是在不幸的时候无法访问。有些涉及您离开公司，但可以回答一两个问题。其他……不要。考虑分层计划。小事故可能得到很好的保护，而更大的事故仍可能导致业务损失，而每个人都将事情放在一起，但没有什么是永久性的。以我的备份恢复计划为例，几乎可以保证印刷版不会完全是最新的。但是，如果闪电摧毁了一个街区的每台计算机，那还是比什么都没有帮助。另一方面，如果服务器只是一个硬盘驱动器，我不得不从备份中恢复，

此失败的示例：我是由 KERBEROS 管理的网络上的用户，管理员不信任他人并且没有撞车计划。当他... 离开时，我们有一个黑客聚会试图破坏他的服务器。最后，我们最好的即兴撞车计划是擦拭机器（每台机器）并从头开始。请注意，虽然这不是最好的计划（事实上，我认为这是最糟糕的计划？），但业务仍在继续发展。我们刚刚停滞了大约两天，并且有一群脾气暴躁的客户。用弗兰克赫伯特的沙丘的话来说，“香料必须流动。” 即使在最坏的情况下（这可能涉及一个奇怪的事件，涉及您的服务器的硬盘驱动器从公共汽车中甩出并击中您的头部，从而破坏了“撞车计划”的所有记录）， 有办法继续前进……但我赞成尝试将标准提高一点！

获取 USB 设备。将所有秘密放在 USB 上，最好放在 KeePass 文件中。在文档中，告诉新人 USB 在哪里以及如何解锁，但将设备放在安全的物理位置，例如所有者办公室、公司保险箱、安全的保险箱等。公开，远离其他员工的窥探。

该计划的优点是：

• 它不在互联网或内部网络上
• 您可以放心，新员工至少已经设法说服存储地点的负责人他们是真实的（并且很可能会被高级员工包围，甚至靠近您的存储地点）。
• 如果有人试图在你之前拿到闪存驱动器，呃，被众所周知的公共汽车撞到，那么有人可能会想，“嗯，安德鲁还活着。为什么有人触摸这个？”
• 如果有人找到您的文件，他们所能造成的损害是有限的（特别是如果他们设法通过互联网闯入 - 很少有人会去公路旅行以获取您的信息）。

要找到好东西，他们需要 1）您的文档，2）物理访问，3）您“渴望峡湾”。USB 也是一个简洁的小包装，适合下一个人使用——即插即用！或者恐慌，这取决于你对公司的重要性。

创建“仅用于紧急情况”的帐户

对于大多数系统，您将拥有在日常管理中使用的某种特权帐户，这些帐户可能会或可能不会根据您的组织策略进行个性化。

至于任何凭证，您可能会因为各种原因而无法访问它们——要么是因为知道它们的人被公共汽车撞到，要么是因为丢失了该凭证的预期安全存储（例如，在火灾中丢失了一台计算机），或者是通过某种方式管理将密码更改为他们不知道的密码等。

可能有用的是为具有完全访问权限但不适合日常使用的关键系统创建单独的帐户。这意味着：

1. 目前，没有人无法访问它们——没有人知道所需的密码。
2. 如果有人访问它们，则应通知每个人（因为在正常情况下不应该发生这种情况）。例如，在登录时向多个关键用户发送电子邮件的自动化脚本，来自这些帐户的所有操作都会被记录下来，如果从这些帐户运行某些东西，您的日常监控就会亮起。
3. 需要时，人们可以访问这些帐户——一种简单的方法是生成一个长密码或密钥，将其打印出来，放入密封并签名的信封中，然后将其锁定在保险箱中。

将您的备份程序和凭据放在那里

当您以任何方便的方式维护您的程序、紧急事故计划和二级凭证列表时 - 只需确保这些文档或密码数据库也可以从紧急使用帐户访问。

也许对您的情况更好的解决方案是设计系统，即使您被公共汽车撞到，并且您的凭据永远丢失，也不会发生任何不好的事情。

也许最好把这个问题看作两个问题，身份验证和授权。

身份验证确定您就是您声称的身份。某些系统可以知道它确实来自您的请求，因为只有拥有您凭据的人才能提出请求，并且只有您知道凭据。

授权确定您被允许做某件事。请求可以是真实的但未经授权。

如果至少有两个人被授权做一件事，那么其中一个人是否被公共汽车撞到也没关系。爱丽丝可能会被一辆公共汽车撞死，而她的凭证知识将永远丢失。但是 Bob 知道他自己的凭据，并且他有权做 Alice 可以做的任何事情。

如果系统的设计方式是任何人都可能被公共汽车撞死，这也意味着有可能撤销一个人的凭据。前雇员，尤其是那些以不良条件离开的雇员，是一种安全责任。您不能强迫前员工忘记密码，因此为了安全起见，您应该在员工离开时更改所有共享密码。在实践中，这太痛苦了，而且还没有完成。首先不共享密码可以解决问题。

从不共享密码也保留了责任。您不能在没有管理员的情况下经营企业，但您希望能够了解某个特定管理员是否滥用了他的权力。最终，终止或诉讼的威胁会阻止任何管理员滥用。如果密码是共享的，那么“必须是拥有密码的其他管理员之一”是一种合理的辩护。

有时您会遇到似乎无法避免共享密码的情况。但通常有一个解决方案，即使它不是立即显而易见的。

你需要共享root密码吗？不，您根本不能拥有 root 密码，而是使用sudo.

AWS 根凭证呢？您可以改用 IAM。

也许您有一个无法避免的特别脑残的 Web 应用程序？您可能无法解决这个问题，但您可以掩盖它：使用允许在多个用户之间共享凭据的密码管理器。（我知道 LastPass 可以做到这一点）。当您仍在共享密码时，您至少有一种自动更改密码和分发新密码知识的方法。至少在员工离开时更改密码，但最好更频繁地更改密码。