如果我“被公交车撞上”，我应该如何紧急访问关键业务机密？

#1 楼

我的建议是从保管箱中删除机密，并将其存储在其他位置。任何人都必须易于理解您的指令，但其中可能包含有关如何访问数据的适当保护部分的指令。这样一来，您就可以将事物的可访问性方面与安全方面分开。

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


为每个人都知道的文件设置密码
为文件设置了多个密码，以便每个人维护自己的副本。
有通过N出M算法锁定的文件（相当于需要两个钥匙才能解锁保险箱的数字形式）。
需要使用N出M算法，并且需要一个“主”密码，无论哪一组人可以解锁文件，而哪一位主人会被保管在防篡改的保险箱中，您可以不时检查一下。无论您做什么，“指令”与“敏感信息”的分离都使您可以适当地保护信息，然后提供有关以后如何获取该数据的说明。

您的业​​务逻辑决策还将包括正常运行时间问题。如果您的生活出了问题，那么另一位管理员必须花多长时间才能影响您的业务？考虑在服务器故障的情况下您希望这些说明和敏感信息的复制程度如何。当我管理服务器并需要存储有关如何从备份中还原它的说明时，我使用服务器自己的Wiki来存储该信息以便于查看，但是很明显，在出现故障的情况下，它并没有那么有用，所以我也在该计算机的开发VM上有一个副本，将其副本保存在3台单独的PC上并打印输出。我不能保证打印输出会保持最新状态，但是我确保可以做到最好。正常降级。并非所有的公交车撞车场景都涉及到公交车撞车。有些牵涉到您不幸地无法进入。有些涉及您离开公司，但可以提出一个或两个问题。其他...不。考虑分层计划。较小的事故可能得到很好的保护，而较大的事故仍可能在每个人聚在一起时造成业务损失，但没有永久的后果。以我的备份恢复计划为例，几乎可以保证打印的版本不是最新的。但是，如果雷电摧毁了一个城市街区的每台计算机，那么它总比没有有用。另一方面，如果服务器只是一个硬盘驱动器，而我不得不从备份中还原，则几乎可以肯定我在开发箱上保持同步的版本是最新的。

失败的示例：我是一个由KERBEROS管理的网络上的用户，该管理员不信任其他人，并且没有按巴士打车的计划。当他...离开时，我们举行了一次黑客聚会，试图破坏他的服务器。最后，我们最好的即按即乘的计划是擦拭机器（每台机器）并从头开始。请注意，尽管这不是最佳计划（实际上，我认为这是最糟糕的计划？），但业务仍在不断发展。我们刚停滞了大约两天，有一群脾气暴躁的顾客。用弗兰克·赫伯特（Frank Herbert）的《沙丘》的话说，“香料必须流淌。”即使在最坏的情况下（这可能涉及到一个奇怪的事件，涉及到服务器的硬盘驱动器从总线上掉下来，撞到您的头上，破坏了按总线计划的所有记录），业务确实有办法保持移动...但是我赞成尝试将标准提高一点！

#2 楼

获取USB设备。将所有机密信息放在USB上，最好放在KeePass文件中。在文档中，告诉新用户USB的位置以及如何解锁，但请将设备放在安全的物理位置，例如所有者的办公室，公司的保险箱，安全的保管箱等。公开，并远离其他员工的窥视。

该计划的优点是：


它不在Internet或内部网络上
您可以放心，新员工至少已管理以使负责存放地点的人确信他们是真实的（并且很可能会由高级员工陪同，甚至靠近您的存放地点）。
如果有人试图在您之前遇到闪存驱动器，那么，也许有人应该对自己说：“嗯，安德鲁还活着。为什么有人要触摸它？” >如果有人找到了您的文档，则可能造成的损失是有限的（特别是如果他们设法通过Internet闯入-很少有人去旅行以获取信息）。要找到好东西，他们需要1）您的文档，2）物理访问，3）您“渴望峡湾”。 USB对下一个人来说也是一个很好的小包装-即插即用！还是恐慌，这取决于您对公司的重要性。

#3 楼

创建“仅紧急用途”帐户

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

对于任何凭据，您可能由于各种原因而失去对它们的访问权限-可能是由于知道该凭据被公交车撞到的人，或者是丢失了该凭据的预期安全存储（例如，丢失了该凭据中的计算机）火灾）或通过某种方式设法将密码更改为他们不知道的密码，等等。

有用的是为具有完全访问权限但不打算用于以下目的的关键系统创建单独的帐户日常使用。这意味着：


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

将备份过程和凭据放在此处

当您维护程序，按总线计划和辅助凭据列表时，可以使用方便的任何方式-只需确保在紧急情况下也可以访问这些文档或密码数据库使用帐户。

#4 楼

也许针对您的情况的一种更好的解决方案是设计系统，以便即使您被公交车撞到，并且您的凭据也永远丢失，也不会发生任何不好的情况。身份验证和授权是两个问题。

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

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

如果至少有两个人被授权做某事，那么其中一个人是否被公交车撞到都没关系。爱丽丝可能会被公共汽车杀死，并且其身份信息将永远消失。但是Bob知道他自己的凭据，并且有权执行Alice可以做的任何事情。可能撤销一个人的证书。前雇员，特别是那些条件不好的雇员，是安全责任。您不能强迫前员工忘记密码，因此，为了安全起见，每当员工离职时都应更改所有共享密码。在实践中，这太痛苦了，没有解决。首先不共享密码可以解决此问题。

从不共享密码也可以保持问责制。您不能没有管理员就经营一家公司，但是您希望能够知道某个管理员是否滥用了他的权力。最终，终止或提起诉讼的威胁使任何管理员免受滥用。如果共享密码，那么“必须是使用该密码的其他管理员之一”是合理的辩护。

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

您是否需要共享root密码？不，您根本没有root密码，而是使用sudo。

AWS root凭证如何？您可以改用IAM。

也许您有一个无法避免的特别死脑筋的Web应用程序？您可能无法解决此问题，但是可以掩盖它：使用密码管理器，该密码管理器允许在多个用户之间共享凭据。 （我知道LastPass可以做到这一点）。在您仍然共享密码的同时，您至少拥有一种自动方式来更改它并分发新密码的知识。至少在员工离职时更改密码，但最好更改一次。

#5 楼

此处的大多数答案都与凭据的处理有关，这可能是由于OP中存在以下明确问题： MFA访问）以确保它在不损害安全性的情况下仍能保持全面性？ />
通过公交计划制定安全目标


这个问题的答案是自动化。服务器端的位置分为两类：修复基础结构：通常没有什么可以自动化的：每个问题都是不同的。在那些情况下，熟悉基础架构（服务器，网络，开发人员如何与Git仓库交互）是关键。
维护基础架构：创建新的VM实例，设置Apache，允许开发人员访问资源等。是自动化最明显的地方。

自动化在自动化中的作用显而易见，成功解决自动化中的问题的关键是自动化。自动化的Python和Bash脚本充当了服务器和网络预期的实时文档：当工作流程更改时，脚本也会更改。 Git记录可能适用于旧服务器的更改，并且git commit消息是明确的。

#6 楼

这本身不是关于如何执行此操作的另一种想法，而是标记出尚未讨论但非常重要的内容的要点。我从这些秘密确实对业务至关重要的角度出发。

测试。

已经提出了一些灾难恢复方案。有些简单，有些更复杂。复杂程度越高，测试的理由就越多。这个问题来自于您如何测试在业务关键环境中被“移出”现场的某人？在圣诞节交易期间，将20mm的圆角通过您的生产服务器与您的主要IT人士隔离，将很难通过玩具工厂的董事会。这是董事会面临的困境。如果重要，则需要对其进行测试。测试太重要了吗？

简单的事情会吸引您的注意。有人提到将数据放入保险箱。大。许多人将保险箱放在安全的地下室，并远离人们。这也是在小火后最初充满水的地方。另一个;您狡猾的工资单业务员一直在对您的工资单进行真正的狡猾。警察进来没收您所有的服务器以进行随后的调查。需要一年的时间才能把他们带回来。

商业上的连续性是一种相当成熟的艺术，所以NASA，Google，巴克莱，陆军和核电站也要这样做。进行冗余处理。很抱歉，Andrew这么说，但是在这种情况下，您是公司的主要风险。需要使董事会意识到这一点，并且您和至少一些工具包需要进行冗余处理（从重复的意义上讲）。重要人员保险和/或业务连续性保险。

#7 楼

我处于与中型公司的唯一IT管理员非常相似的情况，该公司在不同平台上有很多零散的，松散相关的自定义软件。更糟糕的是，在过去的十年中，我为公司编写了所有软件，从其POS系统到在线预订，自制CMS，员工培训软件等。在这一点上，我是唯一了解或拥有过的人甚至看到了这些东西的来源。随着公司的发展，我不止一次被要求不要被公共汽车撞到。我将告诉您我们对此的解决方案。


理解会有干扰。管理期望。如果公司不想雇用多余的人（大概是高薪的人）来学习您所知道的一切，那么他们需要期望在紧急情况下需要进来的任何人的学习曲线都会非常陡峭尝试填补你的鞋子。无论您的文档多么出色，这都是事实。
请确保将服务账单发给公司，而不是发给您。
业务文档的连续性。有一次，我被要求写一个简单的英文文档，公司的首席执行官可以阅读，确切地了解我们拥有的服务器，每台服务器上的内容，每件软件的功能以及这些密码帐户。其中包含针对任何需要并保持运行的人员的注释和技巧。但是，根据（1）可以理解，将需要一本书来详细解释所有软件的功能，已知问题和局限性以及结构。因此，该文档包含了基本的要点，希望一旦有人进入代码，他们将开始查看cron任务并阅读注释并掌握其工作方式。

我会在必要时更新连续性文档，PGP会对它进行加密，以便只能由公司首席执行官和我本人打开，并将其上传到他们的网络服务器上到他知道的地址。 CEO负责确保其PGP密钥的安全。这就是全部了。

听着-如果他们甚至在死后都不想让你放松，那么该是时候要求加薪了。

#8 楼

为了全面，您的解决方案必须是程序和技术控制的结合。理解它的最好方法是将技术控件视为增强程序安全性的功能。它们使某些控件成为可能，而其他控件则更易于执行。

考虑到这一点，这在很大程度上取决于您使用PKI的方式。如果您的组织规模较小，预算限制可能会限制您的工作，但如果可能，我建议您使用硬件安全模块（HSM）保护您的私钥-至少要保护您的私钥内部CA（如果有）。该领域的供应商包括Thales和SafeNet。

关于密码，有许多旨在为组织服务的密码管理解决方案。寻找的最重要的事情是以下两件事之一：一种解决方案，它使用户能够在预定的时间范围内为完成其工​​作所需的访问权限授予权限，而不必向该用户提供实际的密码。系统/应用程序，和/或旨在支持拆分机密知识（没有人拥有完整密码）的系统。 AD Domain Admin或DB admin可以执行此操作（例如，他们可以将用户添加到组中，但不能启用实际上打开/修改该组成员通常有权使用的文件的功能-该功能将由另一个同样无法将用户添加/删除到组的管理员）。 Vormetric就是这样的一家供应商-他们使用他们的静态数据加密产品来做到这一点。

尽管高管支持对于任何组织的安全策略的成功都很重要，但在缺少提供这些功能的供应商解决方案的情况下，这一点尤为重要-因为这意味着您可能需要加强安全意识计划来培养这种能力文化变更将支持大多数IT用户不习惯的必要程序控制-严格控制域和企业管理员特权，并且只有在获得变更管理批准后才可以在特定时间段内授予该特权。 IT管​​理员必须包含多人密码+物理控件。

示例包括使用2-4个人生成一半的12个字符的密码。一对人员生成密码并将其输入到“新密码”字段中。第二对重新输入第一对创建的密码组件（以帮助确保第一对中的一个不会每次都恶意或无意地错误键入密码，从而使更改密码后无法访问该帐户）。使用第二对人员还可以确保密码清晰易读。更改密码后，然后将密码片段存储在单独的不透明信封中，进行密封，标记和存放在防篡改袋中。然后可以将袋子放在实物保险箱中。复制异地备份存储的过程，但合并过程以确保每次为每个站点复制密码更新。如果明显的篡改存储空间不足，请寻找经过GSA认可的双重组合保险柜（X-10 Kaba Mas，例如），并采用相同的拆分知识程序。为了提供额外的保护，请将保险箱存储在带有监控该区域的CCTV摄像头系统的位置，并向所有员工发出警告，警告在未经事先书面许可的情况下在该区域发现的任何人都可能会遭到解雇-同样，这应该从顶部开始。

它实际上仅取决于您的威胁模型以及您的组织对安全性的偏好。