阅读： 0
摘要
随着云原生技术的发展，基于微服务架构的应用不断涌现。这种分布式的架构为应用的开发，业务的扩容提供了便捷，同时也对应用的安全防护提出了新的要求。其中一项就是需要设计安全有效的API安全防护机制，以保障外部对应用入口的API访问与应用内部服务之间的API调用的安全。2017年5月，Google、IBM、Lyft联合发布了开源项目Istio[1], 为服务间API访问控制和认证机制的配置提供了平台。利用Istio这个平台，运维人员可以通过创建Service Account、ServiceRole、ServiceRoleBinding对微服务API按照所制定的策略进行安全部署。一种比较直接的策略是借鉴“零信任”的理念，对微服务应用的每个API都进行统一防护。不过在实际环境中，对每个API都施加访问控制会对应用的性能造成影响。而且服务间存在着依赖关系和信任关系，可以利用这些关系对服务的API进行区域化管理。基于这种区域化的思想，CA Technologies在2018年2月提出了微服务架构下的基于区域层次结构的访问控制机制[2]（以下简称DHARMA），通过区域划分的方式为微服务架构下的API建立了安全防护机制。
一、DHARMA简介
在介绍DHARMA之前，需要明确一个基本概念 – 信任区域（trust domain）。在微服务架构下，一个信任区域是指属于同一API调用序列的服务集合。信任区域内的节点分为外部节点和内部节点，外部节点通常为一次完整的API调用链路中入口API所属的服务，内部节点通常为处于调用链路尾部的API所属的服务。属于同一信任区域的服务间是彼此信任的，除非有特殊的防护需求，否则它们之间的API访问是不需要进行认证的。
下面以一个简单的例子对信任区域进行介绍，服务X可以对服务Y的API进行调用，那么服务X与服务Y属于同一信任区域，可以将此区域定义为D1。一个信任区域内的服务可能会收到来自外部或内部其他服务的请求，若我们在原有区域D1的基础上假定服务X可以接收来自外部的请求、且认证方式为OAuth协议，那么此时服务X同时拥有外部API端点与内部API端点，服务Y只有内部API端点。此时信任区域D1的情形如图1所示。
图1 外部对应用入口进行访问时的区域划分策略
若我们在原有区域D1的基础上假定服务X接收的请求来自内部服务，那么需要定义另一个信任区域D2。假定D2中包含服务A、服务B、服务C与服务X，区域D2的认证方式也是OAuth协议，与区域D1的访问方式一致。那么，此时服务X可视为D1的外部节点与D2的一个内部节点，区域D1与区域D2具有区域层次结构（Domain Hierarchy），如图2所示。
图2 服务间发生API时的区域访问策略
区域层次结构的访问控制机制为，外部区域的服务可以通过内部区域暴露的外部端点向内部区域发送API调用请求，若内部区域的服务想要调用外部区域的API，则需要获取外部区域的访问令牌并进行认证。
事实上，DHARMA就是利用区域层次结构实现微服务架构下的API访问控制的模型。
二、DHARMA设计原则
DHARMA模型的设计主要包含以下四个部分：
1. 信任区域。首先对彼此有信任关系的服务进行聚类，聚类的方式是多种的，可以根据服务间的网络隔离关系或服务间的功能相似性。在对有信任关系的服务进行划分后，还需要考虑所划分出的区域中，哪些可以进一步分离出子区域，从而构建出区域的层次结构。
2. 信任机制与访问控制。在对每个服务进行区域层次划分后，还需要定义这些服务在面对从不同区域发送来的API请求时，需要采用何种策略进行应对。对此，DHARMA所提供的方案是：对于同一区域内部的服务间调用，采用信任机制，这些服务间是彼此信任的，可以不需要认证直接进行API调用。对于跨区域的调用，需要在被调用区域的入口进行访问控制，先经过安全证书的认证再进行API调用。
3. 内部节点与外部节点。对于所划分的各个区域，还需要对其中的外部节点与内部节点进行识别。与外部用户或外部区域有交互的服务通常为此区域的外部节点，只在此区域内发生服务间调用并且不与其他区域有交互的服务为此区域的内部节点。
4. API中转代理。从一个区域进入另一区域时，需要进行身份认证，这项工作是由API中转代理完成的。API中转代理可由Istio平台进行部署实现，Istio的Pilot组件可以完成身份认证功能，其认证架构如图3所示。
图3 Istio身份认证架构图
三、DHARMA实现方案
3.1 DHARMA架构
DHARMA模型的总体架构如图4所示。
其工作流程为，外部用户在申请OAuth令牌后，对应用进行访问。在经过API网关时，鉴权服务需要对令牌进行鉴权。鉴权通过后，证书授权服务将令牌转换成JWT。JWT作为外部区域的安全证书，可以对外部区域的服务进行访问。比如，服务A属于外部区域，当A收到JWT时，认证可以通过。
对于从外部区域进入到内部区域的情况，则需要经过内部区域的外部节点，也就是服务B。服务B作为内部区域的入口节点，需要对从外部区域发送来的请求进行认证，认证过程是由API中转代理完成的。DHARMA规定了内部区域入口处所许可的用户凭证与其所在外部区域的安全证书是一致的，那么携带JWT的请求可以通过服务B的中转代理进入内部区域。
在内部区域，通常来说服务间彼此是完全信任的，对服务C的访问不需要进行认证。因为内部区域自身采用网络隔离手段，要绕过区域外部服务并对区域内部服务直接访问是很难实现的，所以直接对服务C的访问是相对安全的。我们也可以理解为，外部节点代替了内部区域中的其他服务完成了认证，同时不经过外部节点是无法访问内部区域的。这也是DHARMA的主要优势，即利用区域化管理的方法，缩减认证的次数，实现更加高效安全的防护。至此，我们已经对DHARMA的整体工作流程有了了解。
图4 DHARMA模型架构图
3.2 DHARMA的认证，授权与鉴权方式
DHARMA制定的区域访问控制规范为：
1. 内部区域的服务间采用信任机制，属于同一内部的服务间是彼此信任的，只要是来自同一内部区域服务的访问，不需要进行认证
2. 内部区域服务的访问控制所需的认证证书与其所属外部区域所传送的认证证书是一致的
3. 外部区域的访问认证是在请求经过API网关时完成的，将从外部用户发送的带有OAuth令牌的请求利用鉴权服务进行鉴权，并将OAuth令牌转换成用于外部区域认证的JWT
表1总结了DHARMA中不同层次区域的认证，鉴权与授权方式。
表1 DHARMA认证，鉴权，授权表
3.3 利用分布式追踪工具实现多层次区域结构划分
DHARMA进行区域划分主要是在系统设计时完成的，而安全厂商并不会参与业务系统的设计开发。那么，安全厂商若要对已经运行的微服务应用进行API的防护部署，则首先需要对已经运行的微服务进行观测。目前现有的分布式追踪工具可以有效地观测服务间的API调用关系。那么，利用分布式追踪工具，可以对微服务进行区域结构划分，进而添加基于DHARMA的安全防护机制。图5为分布式追踪工具Jaeger观测到的API调用树
图5 Jaeger追踪的微服务API调用树形图
图中同一颜色的API属于同一服务。那么，蓝色服务，棕色服务，深黄色服务，浅黄色服务可以被分在同一区域，且蓝色服务为此区域的外部服务。对区域进行划分后，再根据所划分的区域，利用Istio平台进行微服务API的访问控制部署。
上面只是一个比较简单的例子。对于大型微服务应用，一次追踪可能包含数十，甚至上百的服务，这些服务还可能交叉存在于多个追踪链路中，此时DHARMA的区域层次划分方式是无法满足需求的。
我们可以利用DHARMA所提出的区域划分的思想，利用机器学习的方法对追踪到的所有API调用数据进行分析处理，并根据系统中API的脆弱程度和其所管理的服务或数据的重要程度，将这些服务进行多层次的划分。图6展示了多层次区域结构的情况。
图6 多层次区域结构划分示例图
多层次区域结构的访问控制依然根据DHARMA所制定的访问控制规范，那么需要对不同层次的服务间添加安全证书转换机制。在发生区域转换时，对应的JWT值也随之改变，比如从图6中的区域D1进入区域D2时，将在D1中可信的证书JWT1转换为新证书JWT2，转换后的JWT2将在区域D2内被传输并作为进入区域D3的访问通行证。转换机制的加入可以使得不同区域间的安全证书是不同的，这样可以防止攻击者截获证书后对任意服务进行调用，以此实现对大型应用的API进行安全有效的防护。
四、结语
DHARMA模型定义一种微服务API的安全防护策略，其核心思想是区域化管理，就好比为这些服务修筑了城墙。城墙的好处是外来者无法从城门入口外的其他地方进入，管理者只需要对城门入口进行通行证的验证，降低了由于身份认证带来的性能损耗，同时也对服务内部的API调用进行了安全防护。
当然，DHARMA只是提供了一种区域化管理的架构模型。如何针对不同的微服务进行区域划分，层次结构管理，信任与访问控制机制的制定，还需要根据其业务系统架构的设计与安全防护的需要进行个性化部署。
参考文献：
[1] https://istio.io/latest/
[2] https://docs.broadcom.com/doc/securing-microservice-apis-sustainable-and-scalable-access-control