理解非人类身份治理的视角

一个身份能存在而不被另一个身份引用吗？我们如何知道呢？

这可能对于一篇安全技术文章来说有点哲学，但在处理非人类身份的主题时，这是一个重要的观点要记住。在安全方面，一个更好的问题实际上应该是，“如果一个身份无法进行互动，那么它应该存在吗？”我们可能无法得出对第一个问题的答案，因为证明现实的本质有点超出了计算机科学的范畴。然而，许多人一直在努力构建NHI治理工具，以确定机器身份是否存在，为什么存在，以及是否应该存在。

消除秘密浪费的未来意味着掌握依赖秘密的非人类身份的生命周期和相互依赖关系。但为什么现在呢？让我们退后一步，重新审视一些关于NHIs及其存在的假设。

什么是非人类身份？

在我们继续之前，让我们在这次对话的背景下定义NHI。

In the simplest terms, a non-human identity, also commonly referred to as a machine identity or a workload identity, is any entity that is not human and can perform an action within your system, most commonly interacting exclusively with other non-humans.

这可能是一个需要与数据源交互并将处理后的数据发送到报告系统的Kubernetes pod。这可能是一个将数据传输到中央服务器的物联网（IoT）传感器。这可能是一个基于Slack的聊天机器人。如果在实体创建后不需要直接的人类输入就能完成工作，那么我们应该将该身份视为“非人类”。

所有这些示例的共同点是它们与另一个系统进行交互。如果我们希望它们与整个世界进行通信，那很容易，因为我们只需指向其他非人身份，并以编程方式描述它们应如何交互。然而，我们很可能希望这些系统在特定情况下安全地通信，仅授权特定的身份。这推动了访问管理的秘密演变，从简单的用户名/密码对到API密钥再到证书。

可以说，这是对NHI的广泛定义。但是，通过退一步考虑这些实体如何通过它们的秘密相互关联，我们可以缩小我们关心的范围，从而限定机器身份。

所有NHI连接到其他系统

您能否构建一个独立的应用程序，该应用程序不接受任何输入，不生成任何输出，并且没有可寻址的接口？除了在思想实验之外，是否存在这样的应用程序？虽然想象起来很有趣，但现实是我们关心的所有NHI存在的目的是与其他身份进行通信。

NHI固有地需要连接到其他系统和服务以实现其目的。这种互连性意味着每个NHI都成为相互依赖网络中的一个节点。从NHI治理的角度来看，这需要维护这些连接的准确和动态清单，以管理相关风险。例如，如果一个NHI受到 compromise，它连接到什么，攻击者将能够访问什么以便进行横向移动？

正确的 NHI 治理必须包括工具来映射和监控这些关系。虽然有许多手动方法可以实现这一点，但我们实际上需要的是一种自动化的方式来判断什么与什么相连，用于什么目的，以及由谁使用。在考虑保护我们的系统时，我们可以利用关于在受保护应用程序中构建该映射的所有 NHI 的另一个重要事实，它们都必然有秘密。

所有安全的 NHI 必须有一个秘密

为了在任何两个 NHI 之间建立信任通信，必须存在一个唯一的秘密，例如 API 密钥、令牌或证书，供这些实体进行身份验证。我们可以使用秘密来证明 NHI 的身份并在生态系统中对其进行映射。问题是，我们应该在哪里寻找这些秘密？

在现代企业中，特别是较大的企业，实际上只有两个地方可以存储秘密。您的第一个选择是最佳实践和最安全的选择：秘密管理系统，例如 CyberArk 的 Conjur、HashiCorp 的 Vault 或 AWS Secrets Manager。另一个选择则安全性较低，但不幸的是，却非常常见：在代码或明文配置之外，没有放在保险库中。

企业秘密管理平台，通常被称为保险库，对存储和保护NHIs使用的秘密至关重要。保险库可以为所有秘密提供单一的真相来源，确保它们在静态时被加密，严格控制访问权限，并监控未经授权的访问尝试。这假定您已经在单一企业秘密管理平台上实现了标准化。实际上，大多数组织同时使用许多保险库，使得所有保险库之间的同步成为额外的挑战。

团队可以根据这些秘密的存在情况映射所有现有的机器身份。对于使用多个秘密管理解决方案的企业，您需要知道哪些保险库包含秘密，哪些不包含，并减少在多个保险库中冗余存储同一密钥的开销。

所有NHI秘密都有一个起源故事

机器无法为自己授予权限和访问权限。每个机器身份都是由某个人身份创建或代表的。NHIs的治理必须包括秘密创建跟踪，以确保每个秘密可追溯到其起源，安全分发，并链接到合法身份。虽然通过正确使用秘密管理平台可以解决这个方面，但我们的数据一直告诉我们，每年都会有一定百分比的秘密泄漏，因为我们并未始终使用这些保险库解决方案。

多年来，我们通过帮助团队排除故障事件的经验得知，几乎总是将秘钥创造者定位为首次将凭证引入生态系统的人。我们还可以通过代码历史或其他系统时间戳信息来确定首次出现的时间，这往往是秘钥被创建或以有意义方式出现的最可能时间。

这是一个至关重要的细节，可能从未在任何其他地方正确记录或记录。一旦您了解了谁创建了一个秘钥以利用NHI，那么您就真正理解了我们NHI生命周期的开始。

所有NHI秘钥必须授予一些权限集

在创建时，每个NHI秘钥都必须被授予一定的权限集。范围决定了身份可以执行哪些操作以及在哪些系统上执行。这使得权限范围划定和执行成为治理的关键组成部分。

基本上，有两个风险使理解秘钥范围对企业安全至关重要。首先是配置错误或权限过大的秘钥可能会无意中授予对敏感数据或关键系统的访问权限，极大地增加攻击面。想象一下意外地给予一个可以访问客户PII的系统写入权限。那是一个等待威胁行为者发现并利用的定时炸弹。

同样令人困扰的是，当秘密泄露或泄露时，团队必须首先了解这些权限是如何配置的，才能进行替换。例如，假设你知道一个关键任务的微服务密码被意外地推送到了公共GitHub存储库。在这种情况下，只是时间的问题，它将被组织外的某人发现并使用。在我们最近的从业者之声报告中，IT决策者承认需要平均27天来轮换这些关键密码。团队应该能够在几秒钟或几分钟内采取行动，而不是几天。

需要提供关于检测到的密码的额外背景信息的工具，包括它们的角色和权限。当泄漏发生时，迅速了解暴露的资产以及威胁行为者可能造成的潜在损害，在应对事件时大有裨益。准确知道如何从仪表板视图或API调用中替换它可能意味着阻止一次入侵，使沮丧的攻击者发现他们持有的密钥无效。

所有NHI密码需要进行轮换

机器身份可以在其生命周期中拥有许多秘密，这很可能也应该如此。如果凭证被保留数月或数年，甚至在最糟糕的情况下永久存在，那么NHI秘密的暴露或泄露变得越来越可能。手动轮换容易出错且在操作上耗时，特别是在拥有数千个NHI的环境中。自动化秘密轮换过程是NHI治理的基石，确保在秘密到期或泄露之前刷新秘密。

对于您的保险库中的任何秘密，轮换应该只是脚本编写的简单事情。大多数秘密管理平台提供脚本或其他一些机制来处理安全替换和撤销旧秘密的微妙过程。

但是对于存在于这些保险库之外的NHI秘密，或者可能分布在多个保险库中的同一秘密，该如何处理呢？一个良好的秘密扫描平台需要与这些保险库实现无缝集成，以便您的团队更容易地找到并安全地存储这些秘密在秘密管理器中，并为自动轮换做好准备。GitGuardian与CyberArk的Conjur的参考实现更详细地介绍了如何完全自动化整个存储和轮换过程。

通过识别所有的NHIs并知道它们的创建时间，我们也可以预测它们何时需要轮换。虽然每个团队都会判断每个秘密应该存活多长时间，但任何在创建后从未轮换过的秘密都应该被替换。任何超过一年的秘密，或者对于一些关键任务系统来说，超过几天的秘密也应该被优先考虑尽快轮换。

所有NHIs将会有终结期

NHIs，就像它们的人类对应物一样，有有限的生命周期。当服务被淘汰、替换或不再需要时，它们可能被停用。如果不解决NHIs的停用和清理问题，以防止未使用秘密或过时连接的持久存在，我们就会产生安全盲点。但是，我们如何知道一个NHI的尽头在哪里，特别是如果其秘密仍然有效的情况下？

一个答案是，当一个NHI不再连接到其他活跃系统时，它就不应该再存在。这可以确保攻击者无法利用废弃的NHI秘密在您的环境中立足。请记住，攻击者并不关心一个秘密应该如何被适当使用；他们只关心他们能做什么。

通过绘制一个NHI的秘密允许的所有关系，您可以确定一个系统何时不再连接到任何其他标识。一旦一个标识不再有任何通信方式，它和它的秘密就不应该再存在。这也意味着这个秘密不再需要存储在您的秘密管理器中，让您少了一件需要存储和管理的事情。

了解NHIs周围的世界对于安全至关重要

在2022年，CyberArk的研究显示，在一个环境中，每个人类身份至少需要管理45个非人类身份。如今这个比例可能更接近1比100，并且仍在不断增加。处理您的非人类身份(NHI)治理和生命周期管理的最佳时机是在几年之前。下一个最佳时机就是现在。

是时候采取全面的非人类身份安全方法了，不仅要绘制出您的NHI机密存放在哪里，而且同样重要的是，要了解其他哪些NHI是相互连接的。我们在所有行业中都已经过期，需要大规模实施NHI治理。找到并妥善存储您的机密仅仅是故事的开始。我们必须更好地记录和理解NHI机密的范围、它们的年龄、谁实施了它们以及其他上下文信息，例如它们应该何时更换。

尽管机器身份的数量超过人类，但没有理由独自解决这个问题；我们都在一起。