大公司如何管理他们最重要的密码/密钥？

#1 楼

总的来说，这个问题并没有一个真正的答案，我不一定会认为“大公司”是采用不同方法的独特事物。当然，您指定的特定公司有自己的处理方式，但是最能为他们回答的人是这些公司的员工。
对于大公司而言，它们之间的差异太大，甚至适用于“高科技”公司。有些人采用自顶向下的方法来处理安全性和技术使用问题，有些则没有。有些人非常关心安全性，而很多人则不关心。一些公司更喜欢构建自己的工具，而许多公司更喜欢使用第三方系统，而不是每次都重新发明轮子。
此外，它在企业内部可能千差万别。组织内部的不同部门可能有自己的方法，部门内部的不同团队也可能会做不同的事情，然后当然每个员工可能会经常做自己的事情。同样，这很大程度上取决于技术选择是自上而下还是自下而上。
示例
我工作的公司是一家规模较大（约12,000名员工）的国际电子商务公司。 。我们对内部的大多数事物都使用单点登录（SSO），但仍为员工提供具有在线密码管理器的帐户。它旨在用于员工在工作过程中必须注册的所有其他网站，这些网站他们无法使用我们自己的SSO登录（又称为Internet的其余部分）。该公司还为每个员工使用密码管理器购买了一个“个人”帐户的许可证，主要是希望它会鼓励人们不要在其公司帐户中存储个人密码。
实际上，这种用法与从“部门”到“部门”，其中一些部门几乎被100％采用，而其他业务部门则很少使用它，并且拥有自己的首选方法来存储重要机密。

#2 楼

当我离开时，Facebook身份验证主要致力于多因素身份验证。 Facebook和Google都投资购买了Yubikeys，然后Google继续开发成为FIDO的U2F。服务器访问基于已签名的SSH证书颁发。有一个“碎玻璃” ssh密钥被物理存储在一个保险箱中，还有一些“超级堡垒”主机可以使用，以防站点严重崩溃以至于人们开始报警。但是，IP范围和DNS记录可以像从git存储库中自动应用配置一样简单。 Facebook上的DNS更改很频繁。
几乎所有访问都基于常规用户身份，但通常是分层的。可以使用需要证书和签名质询（将密钥存储在计算机的安全区域中）的VPN连接，这样，如果涉及分配给我的计算机，则只能使用我的凭据访问系统。
在对于使用AWS的小型公司，我已经通过将密码和2FA机密放入Vault中来实现AWS根访问控制，并使用Vault的内置SSS根密钥分发进行备份。每次访问都会记录一次审核访问，因为您需要旋转的2FA代码（保管箱不会让您只读出令牌值来读出机密，除非您协作来获取备份（由一个团队管理）和必要的合谋其他员工。

#3 楼

我为1Password工作。
我们确实有许多使用1Password的大公司，但未经客户的明确许可，我们不会谈论他们的客户。还要注意，我们看不到存储在什么地方，因此我们无法真正从中看到它们是如何处理某些问题的，也就是您提出的很好的管理问题。但是，有时我们会与客户的安全团队讨论此类事情。
有些模糊不清
要注意的一件事是，尽管通过模糊不清进行安全性通常是一件坏事，但您需要了解一些细节提起最好保持安静。例如，如果某个组织正在使用Shamir Secret Sharing，那么您可能不希望公开谁拥有股份以及需要多少股份。
所以我不会告诉您谁是我们1Password帐户的管理员以及他们如何管理自己的主密码和秘密密钥。我也不会详细介绍我们的业务连续性计划的各个方面，以解决其中一些人受到公交车袭击的问题。这些都是经过深思熟虑和得到很好保护的，但是我不想将目标放在任何人的背上。 （当然，您可以猜测，其中一些猜测甚至可能是正确的。）
恢复电源分配
如果您是使用1Password的企业，则可能要做的一件事是尝试确保您限制同时具有1Password恢复能力和组织内电子邮件控制能力的人员数量。除了要注意我们在1Password上从来没有能够使用的密钥之外，我不想深入介绍用于帐户恢复的所有密钥管理的细节，但是如果Alice都是正确的，包括Bob的1Password小组的管理员，她可以阅读Bob的电子邮件，然后她有权接管该小组的Bob的1Password帐户。 （尽管不是Bob看不见的。）请注意，这已记录在我们的安全设计文档中。
因此，某些组织可能希望限制同时拥有两种权力的人员。对于小型组织而言，这是一个比大型组织更大的问题。在较小的公司中，您将拥有较小的IT团队，因此可能需要执行帐户恢复的人员也可能是组织电子邮件地址的管理员。顺便说一下，这就是我们为商业帐户的会员提供免费家庭帐户的原因之一。雇主无权进行任何恢复或访问员工家庭帐户中的数据。
更细粒度的管理权限
成为团队恢复组的成员意味着某些密钥已加密为您的公钥。有许多管理任务不需要成为恢复组的成员。例如，企业可以安全地自动执行供应和取消供应用户的操作，而不必访问或解密恢复组密钥。
通常，我们试图使组织至少（或至少不太痛苦）地遵循用于管理1Password用户的权限的特权策略。
Shamir机密共享，HSM等。
1Password不（还？）提供此技术。但是我有理由相信，我们的某些客户是出于某些主要机密而自行执行此操作的。同样，我有理由相信我们的某些客户正在使用HSM来解密一些主密钥。
我相信，在1Password工具本身之外这样做是一件好事。我们可以做更多的事情来提供挂钩，以使这种集成更容易，但是密钥管理应该通过其他系统进行。
我也很想了解我们的客户在此方面的工作，因此我希望转发以下答案。但是同时，我认为这是一些隐晦有用的政策和实践问题。

#4 楼

您提到私钥。对于这些，一种众所周知的方法是使用硬件安全模块（HSM）。与基于芯片的信用卡一样，它们将密钥保存在您无法打开的盒子中，并将该盒子存放在安全的位置。可以通过电子方式保护对盒子签名功能的访问（当然也不会泄露密钥），例如您的信用卡需要PIN码。如果您需要经常使用密钥，则可以将其直接插入服务器中，也可以将它们离线存储。
HSM通常只是更大的基础结构的一部分，可以保护密钥，同时仍然可以使用它们，但是公司不希望详细展示其工作方式。 IANA虽然不是一个大公司，但是对此非常开放。它“拥有”非常重要的密钥。他们录制了根密钥签名密钥仪式，并将视频在线发布，这是他们建立公众信任的程序的一部分。 HSM存储在保险箱中，并且仅连接到相当受信任的设备（计算机上的只读操作系统，该操作系统也存储在保险箱中）。对密钥进行签名大约需要3个小时，这需要很多个步骤才能将最初存储在USB密钥中的签名请求数据安全地带到HSM，然后再将签名的数据恢复到USB记忆棒上。最后，该过程需要几个彼此不信任的人的物理存在。

#5 楼

@CaffeineAddiction谢谢。我特别是在谈论重要密钥，例如加密密钥，root密码等。谁保留它们？ CEO / CTO和一些值得信赖的员工？

这取决于谁需要访问权限以及公司中的层次结构。较大的公司通常具有由多个团队组成的多个部门。而且并不是每个部门的所有员工都需要相同类型的访问权限。
有多种解决方案来存储机密并管理对它们的访问。我将重点介绍我最熟悉的一个HashiCorp Vault：

使用UI，CLI保护，存储和严格控制对令牌，密码，证书，加密密钥的访问，以保护机密和其他敏感数据或HTTP API。

过去，我还亲自使用磁盘和文件加密技术的组合来保护对它们的访问，例如dm-crypt和gpg。

#6 楼

尽管技术解决方案很棒，但现实是许多公司不使用它们。
我曾在多家公司工作，从小型的两人创业公司到大型的FTSE-100跨国公司。您会发现，敏捷的小型公司通常在技术解决方案方面领先于大型跨国公司。
不幸的现实是，许多大型公司仍使用带有密码的共享电子表格。许多人仍然依靠人们的记忆。例如，根据我目前在一家大型跨国公司中高级管理层的职责，我负责并访问一些系统，这些系统如果被滥用，可能会完全摧毁一家数十亿英镑的公司。其中一些使用SSO并针对公司LDAP进行身份验证。但是，有些依赖共享访问权限，即一个多人共享的登录名。当我开始担任这个职位时，我被口头告知用户名/密码，并告诉它不要写下或与任何人共享。
自从我加入以来，我一直在为此类任务寻求保险库和密码管理解决方案。不幸的是，我碰到的砖墙相当于我们的CTO（正式头衔是不同的，但在这里无关紧要），他坚决反对任何电子密码管理器或保险库（他的论点是-“我不信任他们，不打扰带来再来一次”）。因此，我们继续使用许多密码的电子表格。
我试图推动的特定解决方案是在本地安装一个已知的开源密码管理器（此处未命名）。它允许用户向其添加密码，并与同一安装上的其他用户共享密码。这样，就无需记住任何一个密码。共享密码存储在一个无名帐户中，并与需要它们的其他用户共享。

#7 楼

很好的问题！
免责声明：我曾在大型科技公司工作，而这个答案正是基于此。没有公开公司专有的技术或专有技术。

授权人员

我敢打赌Facebook，Google，Twitter和其他超大型高科技公司不会使用此类第三方服务为其内部密码

实际上，至少有一些确实使用第三方密码管理器-用于员工和非关键服务。根据业务性质，员工经常需要与第三方网站进行交互（员工信息管理，旅行预订，员工信用卡等）。请注意，这些是个人凭据-它们对个人进行身份验证，而不是对资源或流程进行身份验证。
最大的服务将支持公司提供的SSO（单点登录）。 SSO安全得多，但并非所有供应商都支持它。

在大多数大型科技公司中，另一种采用的做法是使用安全密钥通过U2F / FIDO或最近使用的WebAuthn进行两因素身份验证。 / FIDO2

TOTP（“ Google身份验证器”）也很常见，但更容易受到MITM攻击。

对资源和进程进行身份验证

如何一家大公司可以管理一些世界上最敏感的密码吗？ （例如：Gmail团队根访问密码！）

没有“ gmail团队根密码”之类的东西。它的存在将严重威胁用户数据的隐私，进而威胁到公司。
与您在这里的最后一个案例有微妙的区别。我们不是在对人员进行身份验证，而是在对资源和流程进行身份验证。
在这种情况下，通常无需使用密码，也不会从中受益，但是密码仍然出于方便，易于实现的目的使用，或者因为没有其他替代方法。
让我们看一些受大型科技公司的实际案例启发的场景：

保险柜中的8位数字引脚包含将您连接到数据中心的电缆

此保险柜实际上可能容纳或可能不容纳电缆
在这里，我们谈论的是共享资源使用共享凭据进行身份验证。没有任何一种（简单的）方法可以通过使其支持单独的凭据或隔离的访问来使其更加安全。
其他示例：

门代码
警报禁用代码
紧急“破玻璃”-用于密钥凭据


此类资源的最佳做法是：

通过安全通道（例如，密码管理器）
秘密访问审核（对个人进行身份验证，并记录对秘密的访问）
秘密轮换-秘密定期更改

当然，您还将经常查找低于标准的做法！

在电子表格中共享秘密
在一些便利贴中写下秘密
这个人知道的秘密人们知道


方案2-存储用户电子邮件的软件过程

您是否愿意相信这段随机的代码来存储您最亲密的秘密？
此方案更复杂。在这里，我们有一个需要向其他进程（例如数据库或Web服务器）标识自己的进程。

最佳实践可以包括：

不使用密码（或共享机密）。
使用短暂的身份验证令牌，这在Kerberos等协议中很常见

使用密钥管理平台（例如Hashicorp Vault或AWS Key Management Services），这有助于秘密生成，轮换和身份验证。
硬件安全模块的使用，确保过程执行其功能必须访问物理设备。
代码审查协议的使用。这具有访问控制和审核的双重目的，以确保没有任何人可以控制系统。

最坏的做法包括：


将密码/密钥硬编码为源代码


让随意的人在凌晨4点未经批准更改代码



方案3-可以重新启动所有服务器的全球管理员组

当您需要向很多人解释不要按下红色按钮时，您就会遇到问题
这里可以由某些类型的人员执行的操作或任务。
最佳实践是使用适当的基于角色的访问控制（RBAC）系统。这些通常是量身定制的，并且因组织而异。一个原始的示例是UNIX组。
与“共享证书”示例中一样，审计/日志记录是必不可少的，并且在这种情况下更容易，因为资源是基于电子/软件的。组成员资格可以由管理员组（这只是另一个组！）甚至由该组本身的法定人数自由地授予或获取。

关于流程与技术的重要性
/>
是否有知名的大公司使用Shamir的秘密共享的实现？

种类。即使在进行超级安全计算的加密书呆子领域，您也会发现在实践中人工流程通常与技术流程同样重要。
著名的例子：

IANA DNSSEC Root Signing Cerimony，实际上可以保护所有互联网的安全性
不同人拥有的多种密码才能发动核攻击

#8 楼

风险管理和基于角色的访问控制（RBAC）
OP正在寻求技术解决方案，以最终解决围绕风险的问题。其他答案很好地说明了可用的各种工具（例如1Password，Hashicorp Vault等），但我想解决潜在的风险问题。这将确定许多选项中哪一个最有意义。没有一个万能的解决方案，因为不同的企业具有不同的威胁模型，并且面临着不同的风险来源。
OP基本上询问以下风险：

秘密流氓或不可用
许多控制器之一泄露秘密或流氓

通常的风险度量是损失概率x损失值。例如，您有1％的机会每年损失100万美元至$ BAD_THING。如果您可以购买不到$ 10,000的保险来弥补损失，那么这样做是值得的。您正在为风险定价，并确保对此进行防范。如果保险费用太高，并且您选择不采取任何措施并希望自己幸运，那么您就可以承担风险。如果您制定了阻止$ BAD_THING发生的政策和控制措施，则可以减轻风险。
企业会评估丢失（或窃取）加密密钥的潜在损失，为该事件定价，然后寻找控制措施以评估成本。
密钥的“许多控制者”使企业可以将一种风险与另一种风险交易，这可能更可口。单个控制器受到总线的攻击，并且如果一切都依赖于一个键/控制器，则唯一且唯一的密钥被企业拒绝是一个相当大的生存威胁。因此，您可以授予控制器访问多个人员的权限。现在，您不会失去对密钥的访问权限，但可以增加“流氓”的机会。那可能性有多大？选择一个号码。每位员工每年有1％的机会获得访问权限？现在，您可以开始建模在任何给定时间应该有多少人可以访问。
这将导致您进入RBAC。 “ Jane CTO”绝对不应拥有对SuperSecret的个人访问权限。但是，她可能是SecretAdmins组中唯一受信任的成员。该组可以访问SuperSecret，但是该组的成员资格是动态的，可以根据需要进行审核和更改。
具体技术几乎无关紧要。重要的是，秘密控制的设计要与风险特征相匹配。

#9 楼

最敏感的密钥应生成并存储在硬件安全模块（HSM）上，切勿离开。然后，安全性成为对HSM本身的物理访问之一，以及某种方法（如果设备被盗）可以管理撤消密钥。最明显的例子就是管理Web服务器TLS证书的私钥。如果HSM中断，您只会获得一个新证书。如果它被盗了，则吊销证书。
对于丢失密钥的情况将是一个严重的问题，主要思想是将密钥存储在一个或多个HSM中，并且仅使用它来加密其他密钥（您可以将加密的密钥安全地存储在某个地方，但是如果加密的密钥被盗，这不是世界末日），使用TLS根证书对中间证书进行签名的方式，然后这些密钥对其他密钥进行加密，而其他密钥较少有价值且易于替换，它们是用于加密密钥以外的东西的工具。使用公钥加密比以前只使用对称密钥要容易得多。
主密钥是拆分和分发的，但是如何处理对每个公司来说都是特定的。您可以使用单独的HSM生成和存储单独的密钥，然后仅通过串联就可以将它们组合成主密钥。或者您可以将它们异或。在许多情况下，将密钥一分为二就足够了。除了TLS证书颁发机构根密钥以外，我个人了解的任何密钥都只能分为两部分或三部分，方法是将密钥切成碎片，或者将密钥与随机数进行异或。我希望人们现在可以更广泛地使用Shamir的秘密分享，但我不知道。
关键部分可以存储在HSM，U盘或普通纸上。可以将其存储在安全设施中的保管库或安全柜中（例如，银行处理电汇的建筑物的类型足够安全，以至于此类建筑物中带锁房间中的带锁柜子可以被认为足够安全，可以容纳一个柜子）。关键部分（如果没有其他部分在同一建筑物中）。或者可以将其存储在CEO的钱包中。
对于分布式密钥，重要的是要确保检测到任何部分的盗窃，以便可以更改密钥。某些系统已经配置了主密钥和辅助密钥，因此在紧急情况下可以撤消主密钥，而不必先进行配置或安装新密钥的过程。因此，首席执行官可以将自己的股份保留在自己的钱包中，以防万一他们被绑架了，他们将毫不费力地将其交出，而不必忍受绑架者为施加压力而想到的一切。安全始终是一堆折衷。

#10 楼

值得回顾的是2011年的RSA黑客。他们的私人令牌密钥（或种子，可以通过逆向工程算法转换为密钥）并未物理分开的事实令我们许多人震惊。那时，我更有信心，一旦我登录到RSA 2FA令牌安全企业帐户，我就真正在安全的隧道中工作。
哦，那很重要。
我的雇主显然他们也有类似的担忧，因为他们现在禁止美国雇员未经许多层级的重大批准而从美国境外进入。现在，仅将公司拥有的加密设备带出国外，更不用说打开它了，这是严重的违法行为。 （这对外国人和移民雇员造成了沉重打击，他们可能会在原籍国回国探访家属几周。）
从我在贸易媒体上看到的情况来看，公司越来越重视空气的需求（并且钢制保险柜），带间隙的，完全断开的，物理固定的钥匙存放处。可以希望有人采取措施，例如为DNSSEC根签名仪式采取的措施。距离Jon Postel可以接管DNS只是为了提出一个观点，我们还有很长的路要走。 （还是我们？）

#11 楼

但是我敢打赌，Facebook，Google，Twitter和其他超大型高科技公司不会将此类第三方服务用于内部密码，而会使用自己的密码管理器来管理最关键的密码。

您提到Twitter很有趣。据报道：

黑客破坏了员工的Slack帐户，并发现了固定在Slack频道中的Twitter后端的凭据。

如果这是真的，则意味着相当关键的密码可以模拟用户只是（被？）固定在员工可以访问的板上。
我知道（不是很大）公司将所有主密码存储在Google工作表或文本文件中。我在现实生活中见过的最佳实践是共享的KeePass文件。

#12 楼

我与之合作过的大多数大客户（其中一些拥有超过20,000台Unix主机）根本不信任自己的密码。想想大型金融，能源和其他受到高度管制的行业。
他们使用“ Powertech BoKS”之类的产品通过将身份验证与授权分开来控制访问。例如，如果您没有规则（授权）来使用它，那么您是否知道根密码（身份验证）并不重要。是的，这包括在控制台上！
集成令牌和强大的访问控制可能是保护这些大型环境的第一方法。他们不仅仅依靠密码知识来确定访问权限。
例如：仅允许特定用户访问服务器（通过SSH，telnet，f​​tp，x等）...即使许多用户拥有帐户在主机上，也许某些被允许使用SSH，某些被允许使用SCP，另一些被允许使用FTP。最重要的是，它们仅允许来自已识别的已知来源。
系统管理员也许可以使用其个人用户名密码登录到主机...但是，要切换到root帐户，他必须使用2FA。并且...即使他具有有效的2FA响应，他也必须具有切换到root用户的权限，否则访问将被拒绝。管理员不知道root密码。
这些公司中的许多公司还进一步将root帐户的使用限制为特定的时间范围。这意味着即使sysadmin知道root密码，或具有有效的2FA响应成为root，如果他试图在变更控制窗口之外获得这种访问权限，他的访问也会被拒绝。来自已知的主机或网络...即该连接不能源自DMZ，或者仅当来自特定的跳转主机时才允许。
这些严格的控制对于确保这些大型组织的安全至关重要。
至于实际的root密码...因为我们都知道某个时候，有人会需要它... root密码通常在库中保持加密状态。紧急情况下，系统管理员可以“检出” root密码。请记住，签出密码的能力也受到严格控制。在大多数情况下，除非管理员具有允许他访问保管库系统本身的规则以及允许检出特定主机的特定根密码的规则，否则管理员无法检出该密码。首先，他还需要使用2FA访问保管库。在一些更高级的实现中，他无法在不将结帐与有效的变更控制票证绑定的情况下签出密码。一旦签出，保险库将自动为根帐户随机分配一个新密码。
这些概念对许多大公司都适用，但也适用于拥有25个unix主机的公司。这与公司的规模或可能拥有的服务器数量没有太大关系，而是他们考虑数据的敏感程度。甚至小型公司也可以遵守必须满足的法规要求。