随着组织的数字身份数量激增，基于身份的网络攻击活动也在不断增长。在身份优先的安全原则下，新一代身份安全方案需要更好的统一性和控制度。而在现有的身份管理模式中，组成业务运营的各应用程序和服务需要依赖特定的身份存储系统来获取凭据，往往难以管理和集成到统一的安全流程中。在此背景下，一种新兴的身份安全防护理念——身份结构免疫（identity fabric immunity）开始受到行业关注。

从身份管理到身份结构免疫

目前的IAM（统一身份安全管理）方案大多独立于需要保护的应用程序而存在，其他应用服务需要依赖IAM服务来获取授权和身份验证信息。这种身份安全管理的模式在一定程度上发挥了作用。但是当企业业务大量上云后，特别是在面对多家云提供商或公共云、私有云和本地化混合部署环境时，就开始显得力不从心。而实际上，多云和混合云部署已经成为了现代应用系统开发的常态。

研究人员发现，企业脆弱的身份安全态势往往是由其整体身份结构中的不完整、配置错误或易受攻击的元素引起的。由于今天的应用程序大量分布式部署，用户、合作伙伴和客户需要从任何地方登录系统，这使得安全团队没有一个易于界定的网络和物理边界来保护它们。当现有的IAM解决方案不足以全面满足组织的身份安全需求时，身份结构免疫理念应运而生。

身份结构免疫起初是一种维护企业应用系统生态及其安全关系的方法。它遵循了零信任架构的安全理念，可以用来引导企业从容应对错综复杂的现代软件应用安全需求。身份结构免疫的一个核心思想就是“融合身份”，将所有的用户身份提取到抽象层中，从而减少潜在攻击机会，及时改进威胁应对和事件响应机制，并简化身份和访问控制。

当基础设施复杂性开始在组织内部带来统一身份管理的挑战时，身份结构免疫所倡导的安全抽象层就提供了一条解决方案。身份结构免疫中的“免疫”指系统结构中固有的威胁抵抗力。集成式安全层则为实施一致的策略、持续的监视和集中的管理创建了一个统一平台。身份结构旨在提供其他组件可以依赖的层。这一层始于基础设施的多样性这个前提，并使拥有不同配置文件的组件参与其中尽可能简单。

身份结构免疫的一个主要优点就是，它为组织开展身份安全防护工作时引入了整体观。身份结构免疫并不是一种具体的产品，而是通过实施身份编排，帮助组织创建一个完整的身份体系结构，从而将现有的IAM解决方案和各种防护产品整合起来。没有身份结构免疫这样的整体方法，组织的CISO及安全运营团队可能会永远跟在攻击者的后面，始终很被动的响应攻击。

根据研究机构Gartner预测，到 2027 年，身份结构免疫技术将能够帮助企业阻止 85% 的身份安全攻击，从而将违规的财务影响降低 80%。研究人员认为，通过实施身份结构免疫原则，组织不仅可以通过身份威胁和检测响应 （ITDR）技术来保护身份结构中的现有 IAM 组件，而且还可以通过合理配置来进一步提升这些组件的实际防护能力。

身份结构免疫应用实践

身份结构免疫技术在今后几年会变得越来越重要。不过它的建设应用需要组织投入一定的时间和资金，因此建议企业随着数字化业务发展的需要，分阶段逐步实施。以下是身份结构免疫应用中的几个关键角色：

•IdP（身份提供者）：身份结构免疫方案在提供各种功能的身份验证服务时，必须有一个中央记录目录，IdP就扮演这个角色。它可以是一个数据存储系统，比如轻量级目录访问协议（LDAP）或云IAM。组织在应用身份结构免疫方案时，一些原有的凭据系统需要迁离到独立的数据存储系统；

•API网关：该组件为应用程序和身份结构之间的安全通信提供便利。它主要是在网络路由层，为各应用程序和服务集中提供了身份编排和安全验证机制；

•身份代理（IB）：它使客户端组件更容易进行对话以协商身份验证。这个组件专门用于方便ID使用者和提供者之间的初始身份验证交互；

•策略引擎：该组件可以根据用户角色、属性和上下文（比如位置和设备）定义授权规则。与ID代理一起，它提供了高级抽象以消除基础设施的不规则性；

总的来说，身份结构免疫致力于以统一的、集中管理的方法来解答这些问题：应用程序如何进行身份验证和授权？用户如何配置API并与之交互？如何创建和撤销凭据？采用解答这些问题的一致框架意味着减少攻击面，并减少系统中的复杂谜团。企业规模越大，越难以通盘考虑这些因素，这时采用分阶段模型或成熟度模型来考虑就很有用。

为了帮助读者对身份结构免疫概念有更直观的了解，以下介绍了一个典型应用场景：有一个暴露API并实施业务逻辑的后端（可能是Java、.Net或NodeJS），具体的堆栈并不重要。它与某处的身份存储系统进行通信，安全方面接受凭据（可能是用户名/密码），并对其进行验证。一旦成功，某种令牌被添加到用户会话中。可以通过多种方式处理令牌，比如通过cookie或请求头。

而后端组件需要通过以下步骤才能进入到身份结构免疫架构中：

•把它放在API网关后面。客户机请求现在被发送到API网关，API网关负责身份验证，还可能负责授权。

•在独立身份提供者上托管用户凭据。这可以通过两种基本方式来处理：将现有凭据迁移到IdP，或者要求用户在新的IdP上重新注册。

•API网关现在与IdP通信，建议提供用户凭据，并接收授权令牌，可能是JWT（JSON web令牌），最好是通过OIDC之类的标准协议完成。

•用户通过身份验证后，根据令牌判断进一步的请求。JWT之类的令牌可能保存用户声明（比如角色），随后根据该信息，借助API网关和IdP进行授权处理，其他组件则可以看作是相应的变体。

https://www.csoonline.com/article/2077860/what-is-identity-fabric-immunity-abstracting-identity-for-better-security.html