重新思考云原生身份和访问
打破对更细粒度、更智能的定制 IAM 架构的需求
译自 Rethinking Identity and Access for Cloud Native，作者 Matt Moore。
根据 Gartner 的数据，身份和访问管理 (IAM) 市场是一个庞然大物：数百家供应商，预计 2024 年市场规模将达到 190 亿美元。
但是，现成的 IAM 解决方案以及云服务提供商的功能正在被云原生最小权限场景的新世界所扩展。与云原生中的许多其他示例一样，一些最有趣的方法实际上是平台工程师的定制工作，出于其自身组织内部的必要性而产生。
任何帮助客户保护其供应链的供应商，或提供软件（如容器映像）的供应商，这些软件已成为其客户供应链的主要组成部分，都需要认真细致地采取这种安全方法。以下是一些实现该目标的方法。
对经典 IAM 方法施加的新压力
平台工程团队的任务是找出更好的“纵深防御”策略。借鉴 站点可靠性工程 (SRE) 的理念，如果我们假设我们的防线只有 99% 的可靠性，那么合乎逻辑的是，随着时间的推移，我们会看到故障，那么平台团队如何构建冗余保护层，以便在威胁突破其中一层或多层保护后将其阻止？
其中一个关键部分是您的 IAM 策略，以及称为“最小权限”的做法。最小权限原则是广泛接受的安全最佳实践，其目标是最大程度地减少授予身份的访问权限（或特权），涉及多个维度：
通常，云平台中的身份 是从空白开始创建的：无权访问任何内容。
图 1
这是一个很好的起点，并且通过在特定 IAM 范围内授予特定角色（一组功能），理想情况下，这些功能与需要与其交互的确切资源相关联，来添加权限。
假设每个人都遵守这些理想，则可以实现最小权限。此模型的一个好名称是“协作最小权限”，因为它要求参与访问控制模型的每个人共同努力以确保实现最小权限（类似于 协作多任务）。
向审计最小权限演变
平台工程团队的信念应该是任何安全控制都是不可靠的，因此必须部署纵深防御模型，其中使用多个重叠控制来进行制衡，以确保整个系统正常工作。例如，Chainguard 对我们的安全设计进行了更深入的思考，询问我们如何检查协作最小权限模型的假设，并确保没有对我们的资源进行不当访问。
图 2
在考虑最小权限时，关注行为者是相当典型的，如上文以身份为中心的可视化所示，但如果我们重新围绕访问授予箭头另一侧的原子进行定位会怎样？以资源为中心的最小权限视图可能是什么样的？
但是，由于 IAM 模型的层次性质，允许访问的授予可能很难完全发现。那么，我们如何确保我们的资源仅以我们期望的方式被我们期望与其交互的身份访问？答案显而易见：IAM 审计日志。
协作最小权限的基石是非常精细的 IAM 访问授予。当我们翻转事物时，其对偶是非常精细的 IAM 审计日志策略。我们称之为“审计最小权限”的模型。
我们将我们配置的每个云资源与 IAM 审计日志警报策略配对，该策略会在资源在预期最小值之外被访问时触发。此最小值通常根据一组映射到可接受交互（如上图所示）的 IAM 原则来定义。我对这些 IAM 警报策略的昵称已成为“激光网格”，因为它让人联想到好莱坞抢劫案中被激光束包围的无价文物。
映射到 99.9% 预期 + 审计：一种获胜模式
类似于通过使用仅具有 99% 可靠性的两层来构建可靠的分布式系统，并假设它们失败的方式不会相关，您可以将分层防御的可能性提高到 99.99%。
IAM 中有很多众所周知但仍然常见的陷阱。例如，IAM 授予的权限往往过于宽泛，在帐户或项目级别授予权限，而不是在资源级别授予权限。有时授予的能力过于宽泛，可能是由于内置策略过于粗糙。在多个服务中重复使用工作负载标识等行为也是不允许的，因为当三个不同的东西使用同一服务并且其中任何一个需要与新东西通信时，您最终会使用该标识向所有三个服务授予该能力。
将 IAM 视为锁（又名互斥锁）。您希望在持有这些权限时最大程度地减少您所做的工作量。微服务允许您使用一个针对该服务的良好受限接口提取需要某些权限的功能。
这就是 Chainguard 如何围绕我们的 Chainguard Images 产品构建其最小权限实现的方式。我们相信最小权限原则（极简主义）通过短期凭证（短暂性）是最佳安全态势的基础。当我们在资源周围创建服务抽象时，我们在这些资源周围设置激光网格，对我们的审计进行编码，以便在任何实体尝试访问数据时收到警报，这与 99.9% 的预期访问不同。
我们正处于平台工程的一个有趣时刻，微服务实现的隔离、OpenID Connect 和其他身份验证机制的成熟以及平台团队创建新的封装层的能力正在融合在一起。与云原生领域的许多先前的创新一样，平台工程团队出于必要而做出的定制工作，是对未来的展望。我认为随着业界对如何在分布式系统中封装安全变得更加明智，我们将看到更深入的可编程性和审计被引入 IAM。
腾讯云开发者
