浅谈助力零信任安全架构的云IAM设计 | GITC全球互联网技术大会演讲记录

前言

随着云计算、大数据等技术在企业大规模的推广使用，持续集成持续部署的业务交付模式以及移动办公的接入方式深刻地影响了信息安全建设思路，如何能够更动态更智能更安全地保护企业的数字资产的同时不损失效率和体验？Google分享的零信任安全架构实践的相关论文给我们提供了一个非常好的思路，事实上，全面身份化即对网络参与的各个实体（人、服务、设备等）在统一的框架下进行全生命周期管理，而构筑全新的身份安全体系是零信任安全架构的基石。分布式设计模式和实践（如微服务，容器编排和云计算）已经让我们的生产环境变得越来越动态和异构，我们认为传统的安全实践（例如仅仅基于四层网络控制策略的访问控制）在这种复杂性下难以扩展，急需一套全新的IAM（身份和访问控制管理）框架。而云IAM就是能够支持在万物互联背景下的全面身份化以及多租户、多帐号体系、多用户渠道、云原生支持等特性的一整套解决方案，这对于将安全防护从网络层访问控制升级到应用层动态访问控制起到至关重要的作用，也将有效助力零信任安全架构的建设。下文将重点讲述我们对云IAM的理解、方案设计以及部分重点模块的解析。

业务发展带来的安全风险

首先介绍我们的业务背景，因为安全从本质上来说就是为业务服务的。中通目前是国内业务量最大的快递公司，2017年快递业务量达到62.2亿件，居全球第一，并且已经保持了两年的行业龙头地位，今年刚刚过去的双十一期间的业务量又刷新了记录。另外，2016年中通登录美国纽交所，成为了当年IPO规模最大的中概股。目前中通全网有三十多万员工，网络合作伙伴9400多个，服务网点将近三万个，覆盖了全国绝大部分区县和乡镇。在强劲的快递主业的带动下，中通还积极拓展整个电商产业上下游生态链的业务，如中通快运、中通云仓、中通国际、中通商业、中通金融、中快传媒等，并且已经建成了多元发展的集团型企业。

那么在业务如此急速发展的情况下，对我们的IT特别是对信息安全带来了哪些挑战和风险呢？第一是需要上线大量各类应用系统，自研的、外购的、本地部署的、公有云部署的等等，对众多的异构系统如何做好安全管控的集成是非常大的挑战，另外在大促活动时，如双十一期间也需要所有安全组件可以水平灵活扩展。第二，从整个集团来看，整体组织架构非常复杂，人员和设备的数量巨大并且变动频繁，如何做好安全管控也是难题。第三，由于业务的需要，敏感数据需要参与到系统流程中去进行流转，安全保护的难度直线上升。第四，作为电商业务的重要一环，需要和各个生态合作伙伴进行数据对接，并在开放平台提供了大量API，安全管控难度较大。那面对这些安全挑战和风险，有什么比较好的应对方案呢？

解决方案

幸运的是，Google分享的零信任安全架构实践给我们提供了一个非常好的问题解决思路的参考，可以在很大程度上解决上述问题，经过我们初步研究后发现，IAM平台是零信任安全架构的核心基础。图1中橙色的模块都可以算作IAM的范畴，如单点登录、设备库、用户和组数据和证书签发等模块，甚至接入代理也可以作为访问控制管理的一个组件。然而传统的IAM方案已经无法满足我们的需求，因此打造一个强大灵活的下一代IAM平台势在必行。

图1：零信任安全架构（Google BeyondCorp）及其中的IAM组件

结合我们面临的实际问题以及零信任安全架构的需求，我们对下一代IAM的设计提出了如下三个目标：

• 全面身份化支持，使用通用安全身份框架SPIFFE，将客观世界的对象抽象成逻辑上具备不同属性的身份，如人员、设备、应用、API等，实现支持万物互联的身份认证技术，为访问控制奠定基础。

• 云原生支持，真正打通本地/云/办公等网络边界，全面从网络层访问控制升级为应用层动态智能深度检测和控制，同时使用容器、微服务、服务网格、服务编排等技术，实现灵活的水平扩展和异构系统互操作支持，以及端到端全链路的双向认证和传输加密。

• 复杂组织的支持，针对中通这种具有几十万人横跨多个业务单元、面向不同终端客户的商业组织，需要满足跨租户、跨帐号体系、跨端、跨用户渠道、跨应用、跨生态的需求，以及应用和身份数据分离的联邦和多协议的支持，并且能在资源层面对所有操作进行分类分级及自动化审计。

根据以上设计目标，我们的整体设计方案的功能全景视图见图2，尽可能地解耦和拆分模块并作独立部署，将身份相关基础数据抽离出来单独做成身份中心，结合认证中心、权限中心、应用中心、资源中心、证书中心、管理控制台以及开放API、SDK和APP等构成一套体系，然后可以灵活地与各类应用在不同的层级进行对接。这样做的好处就是，不管企业的应用部署到哪里，都可以共享一套强大灵活的身份和访问控制的安全管理基础设施，解决了异构系统集成安全管控问题以及人员设备、敏感数据和API的安全管控问题。

图2：云IAM功能全景视图

云IAM的总体工作流程如图3所示，首先是用户和设备的认证流程，通过单点登录代理将认证请求转发到对应认证协议的处理模块，认证处理模块根据请求上下文连接到对应的身份提供商IDP，经过一系列的交互成功认证后下发访问token。接下来用户携带相关访问token发起相关资源的操作请求，在接入代理和接入控制引擎层面会去认证中心校验token的合法性、拉取授权、鉴权以及相关的风控操作，如果通过校验满足访问控制策略，则提交到相关应用的API执行，当然在返回数据包中还需要进行再次校验是否满足安全策略，以及进行相应的审计日志记录。云IAM平台本质上是以更灵活及更细粒度的方式来管控资源的操作。传统的业务流程就是身份实体首先进行身份认证，认证通过后发起资源操作请求，收到操作请求后根据授权信息进行鉴权，通过则放行操作。那我们新的设计大量地参考了aws的设计理念，更灵活及更细粒度是体现在权限模型、授权方式以及API和资源的严格定义上。无疑aws老板贝索斯是非常有远见的，很多年前就定下了服务化的架构原则，要么服务化要么滚蛋。事实上这一点至关重要，如果不能把资源以及操作资源的API定义清晰和有效隔离，那么将无法实现功能强大的权限控制策略。

图3：云IAM总体工作流程

重点模块的设计

1.身份空间

我们知道身份是任何安全基础架构的基本概念，那么把身份相关的操作串联起来就形成了身份空间，如图4所示。其中包括身份生命周期的管理，主要是客观身份实体和逻辑对象的实时映射，如果要能支持万物互联的认证需求，那么就需要将除了人员以外的更多的实体纳入进来，逻辑对象映射到可操作系统的身份实体，如身份到帐号是个一对多的映射关系，给身份实体赋予了相关权限才能对资源进行操作。这里有一个开源的通用身份认证框架SPIFFE，大家有兴趣可以了解和参考它的设计。

图4：身份空间的设计

2.帐号体系

云IAM平台需要支持多租户模式，如图5所示。每个租户下面会支持设置多个帐号体系如办公的、2b和2c的，每个帐号体系下面可以建立各种形式的帐号组如根据组织架构自动建立的、根据角色建立的等，帐号组里实际上会有各类帐号组成如人员身份的、机器人身份的、设备身份的等。

图5：帐号体系的设计

3.复杂组织架构

根据我们的实际需求，还需要支持集团性质租户的复杂组织架构，如图6所示。集团下辖成千上万的分公司和子公司，公司下面除了挂部门也可以挂公司，同一个帐号可以在不同公司间进行自由切换，同时伴随部门和角色权限的变换等。值得一提的是，我们还设计了组织架构类型的帐号群组，系统自动创建，除了可以辅助人员入职时自动授权外还可以自动加入内部协作IM工具的沟通群组，帮助业务提升协同办公效率。

图6：复杂组织架构

4.系统集成

作为一个云原生设计的IAM平台，必然需要支持和各类异构系统进行安全访问控制的集成以及互操作，如图7所示。第三方应用或者租户可以很方便地接入IAM平台，用户可以无缝使用平台上的应用，这个场景下IAM平台通过配置直接使用第三方的身份数据源IDP。对应的，IAM平台上用户也可以无缝使用第三方的应用，这时相当于在第三方本地建立了一个IAM上云端的IDP缓存，当然这个集成的过程需要符合一些规范的认证协议和数据同步接口，如OIDC、OAuth2、SAML2、SCIM、REST等。

图7：支持系统集成的设计

5.授权

在权限模型方面，我们采用RBAC用于粗粒度访问控制，如控制某一类人可以查看哪些模块，采用ABAC进行细粒度访问控制，如控制某个人员对模块内部的访问权限。在授权方式上支持更多更加灵活的方式，如基于身份的策略、基于资源的策略、独立的访问策略以及设置权限边界等。一个典型的权限配置过程包括定义资源、定义每个资源操作的API、定义访问实体、定义角色权限或者访问策略等。 那么授权的本质是什么呢？主要是回答这个问题：“谁能不能在什么样的上下文中对什么样的资源做什么样的操作”，为此我们设计了一个简易的自定义DSL来描述这个资源操作请求。如{"appid":"eihxiidhh23s","user":"jack","action":"getArticleID","resource":"resources:articles:zto","context":{"remoteIP":"192.168.0.5","trustScore":“90"}}，其中的trustScore是我们重点设计的元素，放入到上下文中，和零信任架构中的风控引擎以及具体的访问控制策略结合起来形成一个动态智能的深度鉴权。

 6.微服务安全架构

为了实现整个平台的灵活扩展和部署，我们参考了ISTIO 微服务架构。ISTIO的安全架构设计得非常漂亮，示意图也非常清晰，如图8。首先是内部微服务通过集成证书中心实现了微服务之间的双向认证和传输加密，再结合用户侧的传输层加密可以实现端到端全流程的双向认证及传输加密，当然要做到这一点是非常有挑战的，我们还在努力中。通过控制平面的pilot组件以及服务名称管理和证书还可以实现各个微服务间的安全隔离和访问控制，另外pilot结合数据平面的边车节点也可以实现访问策略的执行。

图8：ISTIO微服务安全架构

7.证书签发、轮换和吊销

基于传统PKI，为了匹配性能及扩展性方面的需求，设计了证书中心，主要涉及证书签发、证书按规则轮换以及证书吊销三部分的功能，工作流程如图9。新的终端设备或者新的服务上线，都需要自动提交证书申请到证书服务集群，由证书服务集群代理向CA发起请求，拿到证书后转发到申请者。证书轮换由证书申请者按照一定的规则自动重复申请流程即可，证书吊销申请和证书吊销查询服务也统一由证书服务集群代理，通过接口实时查询是否吊销，实现即时吊销的功能。

图9：证书中心工作流程

8.自动化审计

云IAM平台中另外一个重要的功能点就是安全审计，主要是跟踪记录谁在什么时间什么地点以什么样的方式做了什么，聚焦在及时发现和处理异常。我们在这一块的创新点在于自动化审计，首先对所有资源进行分类，然后对所有资源和操作对进行分级，最后根据分类分级和权限以及与其它系统集成自动过滤大部分异常，可以节省大量的人工审计工作。安全审计交付物通常有三方面：主动及时汇报和确认异常以推动策略实施及问题解决；确保审计对象得到合理准确的处理和合规；对企业内审计对象进行关联性分析并得到综合性的报告。

9.移动端APP

我们的云IAM平台还设计开发了配套的移动端APP，主要包括了安全认证模块、IM模块、应用发布模块以及工具模块等，如图10所示。移动端APP帮助我们得以停用传统的静态密码认证方式，配合进行实人认证以及执行风控校验的指定动作等，极大地提升了整个平台的安全性，增加了用户交互方式同时也优化了用户体验。

图10：移动端APP

总结和展望

目前我们已经落地了部分模块和功能，如认证中心SSO模块支持多种认证方式（密码/短信/TOTP/推送/扫码/刷脸/会话代理等）；身份中心借助人脸识别、OCR、活体检测等人工智能技术实现了实人认证功能，可以将人员、证件、帐号以及设备进行绑定；权限中心支持跨应用的集中统一权限管理，目前已经接入了几百个应用；我们通过IAM和第三方厂家网络准入软硬件的对接，实现了精细化的安全访问控制；可以较好地支持联邦认证，通过我们的IAM平台和阿里云邮箱的LDAP进行集成，实现无缝的用户体验；平台可以较好地支持认证互操作，可以分别在钉钉和我们的移动端APP上集成自有应用以及第三方应用。

未来我们将落地更多的模块及在云IAM平台上集成更多的安全组件，如零信任安全架构相关的组件以及一些SDL组件或者工具等。另外我们还将积极拥抱开源技术和开源文化，积极采用开源技术并且制定开源计划回馈社区，未来将逐步开源一些经过我们实践检验过的成熟的安全组件，希望能帮助到有需要的安全团队。

参考资料：

1.Google的beyondcorp安全解决方案：https://cloud.google.com/beyondcorp/

2. AWS的IAM安全解决方案：https://aws.amazon.com/iam/

3. 通用安全身份框架SPIFFE：https://spiffe.io/

4. 服务网格开源项目ISTIO：https://istio.io/