本文给大家介绍派拉云身份管理在华为云平台上的实践，包括一些架构实践和业务实践。

首先会介绍上云的架构实践，包括云身份管理平台在华为云里面的部署架构，还有自动化的CRUD过程，再到云上产品的运维和安全的实践。

1. 上云架构实践

1.1 派拉云身份管理平台华为云架构

上图是派拉云在华为云的总体架构图，我们可以看到各个组件在华为云中的监控及部署情况，包括华为云的组件，派拉云的组件和一些云原生底层的组件。

从流量上来看，当用户端流量进来的时候，首先会进入华为的云防火墙，来做三层网络和四层网络的安全防护，包括一些安全策略都会在云防火墙来定义。流量经过云防火墙后，首先会经过DDoS高防护的服务，为流量安全进行一个防护。再到WAF防火墙，对于七层网络安全进行防护。

安全流量经过层层防护以后，就会进入到业务上面，首先会分两部分，一部分是静态资源都会通过CDN组件来把静态的文件进行缓存，动态的请求会通过ELB来进行流量转发，会把流量打入到开发子平台里面的Ingress组件中。

整个容器平台里面也使用了华为云组件，包括应用编排的服务、云容器的引擎等。再对云容器的实例进行一个编排，进行安全防护，所有的服务都会运行在云容容器实例里面，按照编排好或者是说按照配置好的策略在容器里面运行。

在云上业务会分两个环境，一个是预生产环境，一个是生产环境，他们是通过VBC进行隔离。预生产环境大部分时候部署的数量是比较少的，每个服务可能只有一个节点，个别服务可能是两个节点，主要是用于我们安全测试、功能线上验证。实际最终生产的部署，会根据实际的这个业务情况、访问量、流量来进行扩容，保证每个服务都是高可用的，至少2个节点保证高可用。

流量打进Ingress组件后，进入生产环境，下一步就会到Web网关、API网关，我们基于Springcloud Gateway标准进行开发，由Gateway来管理认证、筛选和路由转发。Gateway网关里面会存储在筛行状态，对于下游的服务是一个完全无状态的，保证了我们的服务可以很快的扩容。在此之外还有我们的微服务的一些基础服务，在服务之外有一些注册、配置中心。其中Nacos负责对于每一个服务的注册、发现进行管理。Springboot admin对每个微服务的JVM的监控。SkyWalking负责链路追踪。

除此以外我们做了一个ParaPKI的服务，它是用于对于整个服务里边的Https的公钥、私钥，Topic验证的公钥私钥，底层数据库中存储的密钥，全部由ParaPKI服务统一管理。ParaPKI会独立的存储管理所有的密钥，保证云环境中所有的服务、数据的安全性。

最底层用到了华为云的云原生的组件，包括镜像服务，我们的容器镜像也会同步到华为云的镜像服务中去。由华为云的镜像服务把镜像推到我们的容器中去，比如一些云的数据库，Redis，镜像存储，ELK，MQ，对于镜像，我们完全按华为云对镜像的标准去做，能使用标准组件就使用标准组件，网络、容器、中间件等全部交给华为云平台去解决，华为云的稳定性保证了这些组件的稳定，我们只需要关心自己的业务开发和业务的监控就可以，大大节约了我们的时间和精力。

1.2  云上自动化发布实践

根据上图我们讲一下华为云里面自动化发布的实践，分为云上和云下两个环境。云上环境主要是用于发布生产环境，我们SaaS服务的生产环境会在云上发布，还包括SaaS服务的UIT环境，预生产环境，用于测试回归、云上环境的验证。

我们公司内部的RDC机房会运行的一个测试环境和一个开发环境，开发人员提交代码之后，会通过这个Gitlab触发自动化编译，在自动化编译之前对代码进行安全扫描，扫描通过代码会进行打包。那么会打两种包，一种是Java的jar包，会放在Nexus里面，另外一个是打好的镜像会放在Harbor里面，在Nexus和Harbor里面的正式版本是必须是通过Jenkins来进行打包，绝对不允许个人直接把包会发到Nexus和Harbor里，这样保证全部包是自动化编译成功的，这个时候Jenkins 再触发我们内网的K8S平台进行发布，会根据不同环境会发布到开发环境，也根据策略会发布到测试环境。开发人员会在开发环境进行冒烟、调试，调试完成之后也是会触发Jenkins正式发布到测试环境。测试环境由测试人员进行集成测试，测试完成之后，通过流程触发Jenkins把Harbor里面的镜像推送到华为云的镜像仓库里去。

之后在云上的开发平台，会从云上的镜像拉取数据，进行一个版本发布。首先会在我们的预生产环境进行一个预生产发布，发布之后由我们的测试人员和我们的产品人员对这个版本的情况进行回归测试，测试没有问题之后，我们发布到生产环境。生产环境采用滚动发布和灰度发布，我们先会发布一个最新的版本，那么最新版本它的流量不一定很大，在一定时间里，次新版和最新版是一个并存的，那么在次最新版验证通过之后，就会逐步的把流量切换到最新版，次新版就作为一个备份，后面发布会依照进行一个滚动。

在这个过程当中，其实还会遇到另外一个问题，在我们的测试环境、生产环境都需要用很多个云上组建的管理平台，比如说Nexus、Harbor、Jenkins，这些都是运维人员来管理，而且他的账号权限非常大，如果账号被泄露，账号被窃取，对整个系统都有致命风险。所以所有的运维组件我们都基于Nginx做一个双向的Https认证，虽然对应的端口开放，但是人员如果没有对应的客户端证书，是无法访问这个组件的，我们给每个管理人员颁发了个人证书，只有他使用个人证书在他自己的电脑上才可以访问这些组件的后台，而且证书都是有过期时间的，一般30-40天，证书就失效，需要重新颁发。

所以在整个的开发过程当中安全一直是贯穿着我们的整个研发体系里面的，包括我们工具的使用、代码的安全。

1.3 云上运维架构和安全实践

下面我们根据上图介绍一下我们的云上运维架构和安全实践。这里要说的是从开发到运维 ，再到前后端联调，再到我们真正发布到生产环境、测试环境全过程的一个控制。在整个过程中，我们使用到了IDaaS这个产品，这个产品由我们自己研发，也作为研发过程中的一个工具，相当于既是开发的产品，又是开发过程中使用的工具。我们利用IDaaS的能力对整个研发过程进行管控。

首先对于我们的重点用户、开发人员的开发环境，我们使用沙箱进行防护，用户本地的代码完全是加密的。第二是代码防泄漏的能力，从我们的Git上拉代码，如果是个人在公司内网，拉代码是没有问题的，但是很多情况下需要远程办公，比如前一段时间的上海疫情，整个2个多月，疫情没有影响到我们的开发进度，每一个开发人员的电脑上装SDP的零信任客户端，通过本人的标识和RDC机房的标识进行认证和身份管理，所有的流量都会进入零信任网关产品，零信任网关会对流量进行加密和还原，来通过权限进行访问控制，整体的权限是由零信任中心的策略进行配置的。那最终这个用户对于Git代码的请求会从零信任网关转到Git服务器上，获取开发人员所需的数据。

刚才说了个人和Git服务器的访问控制，在开发过程中还涉及到开发人员之间的联调，比如前后端的联调，由于大家都是在家办公，他们的网络如何保证安全？我们是通过Web网关和API网关进行一个中转的连接。比如说后端开发人员本地启动了一个服务，会把服务发布到我们的API网关中，前端开发人员就可以通过API网关进行联调，整个过程是一个加密的通道来进行安全防护。

除此之外，还有一些运维人员，DevOps的一些管理，上文提到DevOps的所有的工具所有通信过程都是经过Https双向认证防护。还包括SSO单点登录，因为运维软件非常多，这些软件和IDaaS进行了单点登录的集成，只要登录一次，就可以访问到我们运维平台的任何软件。

最后还有一个问题，DevOps中的各个运维组件和我们的服务之间的访问，传统方式是通过端口进行访问，而在我们的架构中，所有的微服务都必须经过Https双向认证，保证流量的安全。

这样的一个整架构就保证我们从开发阶段代码的安全，再到我们的前后端调试的安全，再到我们的运维为对于产品的发布的安全，再到我们发布的服务内部的调用的安全能力，做一个这个全面的防护。

2. 上云业务实践

2.1 多租户

在SaaS类产品中多租户是个必备的能力。使用一套硬件环境为多个租户提供服务，多个租户同时使用服务可以分摊我们的硬件成本。不过问题是在一个资源中不同租户的数据安全隔离如何实现？

这里就举个例子，比如说现在有3个租户，假设叫ABC，对应的租户id为123，首先以二级域名的方式对租户进行一个区分，每个租户在自己的这个浏览器里面输入他的二级域名首先会进入到Springcloud Gateway的网关，Gateway接收到这个请求后，首先根据Https中域名进行租户查询，还有一种情况就是，C这个租户还想用自己的域名进行访问，只要把他的域名映射到我们的开放端口，他就可以用他的域名来进行访问。我们网关查询到这个租户ID的时候，他会通过我们的Http头把租户ID放到我们的Header头里面，当然头里面还有一些认证的信息，一起转发到我们的路由中去，再又路由发到我们的服务中去，我们的服务在接收到访问信息时，会把租户信息存储下来，这时候相同线程的租户在操作的时候就自带了租户ID。如果是访问数据库，不管他经过了多少次转换，从线程中获取租户ID，查询时，查询条件带上租户ID，插入和修改时把租户ID写入，保证数据库中的数据的租户隔离。服务和服务直接访问的时候，发起的服务也会对Header头进行添加租户ID，接收的服务也会从头中获取租户ID，重复以上的操作。

对于数据库，我们使用了Maxwell的binlog监控功能，监控所有的写入操作，根据我们业务，比如新用户需要缓存到Redis中，对于一些高性能的查询，也需要使用Maxwell把mysql的数据写入ES中，在es中同样也有租户ID的区分。再比如一些用户增删改的变化，也是Maxwell通知MQ，每个租户使用broker进行隔离，其他的服务和业务在消费MQ时，会根据租户ID获取他们的信息

这样就能从用户浏览器里面开始访问，到网关、服务、Redis、数据库、ES、消息队列，这一整套所有的过程都是经过租户ID的隔离，用户在整个过程中只能查询和操作自己的数据，无法影响其他租户。

2.2 高可用高并发

下面根据上图讲一下高可用和高并发的能力。

作为统一身份管理产品，我们有很多的C端的客户，他的用户量可能会上百万甚至上千万，对于这么大量的用户，他的访问量可能会非常之大，并发也会非常之大，可能这种百万级或者千万级。并发可能要到8000到1万。那么对于这么大的并发要求，我们是怎么处理呢？

首先对于访问端可能有多种方式，比如手机APP、电脑浏览器、微信公众号、小程序，要进入任何一个系统之前都会要先登录，所以我们的统一登录压力会非常之大。我们首先在这个请求的基础上做一个动静分离，对于这个静态资源从CDN来进行获取，只有动态的请求才会进入到我们的业务系统，所有的请求都会到我们的负载均衡上，从负载均衡上到我们的API网关，在API网关上会做一些限流熔断、灰度发布的基本功能，最终都会进入我们的微服务认证，就是Springcloud Gateway，在整个过程中我们认为量最大的并发业务就是认证登录服务，我们所有的用户信息都缓存到了我们的Redis中，缓存的不是用户的用户名密码，而是用户名密码的Hash值，用户登录的时候通过Hash值比较来验证登陆信息。第二个要说的功能是，当我们的用户发生了变化，比如新注册，比如用户信息的修改，我们要把修改的信息推送到消息队列，由消息队列再推送到使用我们平台做统一平台身份认证的应用中去，各个应用来进行注册订阅就可以获取到实时的变化，这样就把我们的功能进行了解耦，我们只要关注登录这个并发较高的操作。对于用户的查询，我们把用户的信息都存储一份到ES中，方便查询。我们整个架构就把所有的用户高频操作进行一个解耦，来支撑大高的并发，高可用的事项我们是基于K8S的平台，我们每个服务已经拆分的足够小，目前我们整个的身份管理的这个产品有30多个微服务，每个服务都是可以独立运行，可以不依赖其他的服务进行运行，对于高可用、动态扩容都可以很好的支持。

2.3 安全架构

下面根据上图，我们来谈一下安全架构的实践。

从我们最前端的Https的调用，我们暴露的任何服务必须是Https，并且我们的服务具备Https防止被代理人中间人攻击的功能，提高了客户端的安全。一个用户的访问进入到我们Gateway的时候，第一步我们要先进行服务的认证，你有没有权限调用我的这个接口，如果没有权限可能要进行登录，登录完了之后我们SSO会给他颁发一个合法的Token，用户的登陆过程完成以后，他访问下游服务的时候都会携带着这个Token。在下游服务，可能是访问服务A，也有可能路由到服务B，但是他在访问服务A或者服务B的时候，他有2个动作，第一个这两个微服务之间的调用，必须是Https双向认证，必须有服务端证书和客户端证书，另外消息头中要携带Token信息，服务之间所有的流量会进入到我们的微服的认证的组件，认证SDK会拦截所有的流量，检测他有没有携带Token，和Token是否经过认证，保证这个这个认证的一个合法性，还需要做Https的校验，PKI的Agent会进行双向的校验。所有的证书的颁发都是我们的PKI来实现的，另外防止证书的丢失我们有一个OCSP服务，比如说某个证书丢失了或者过期了，需要吊销了，我们可以通过OCSP对证书进行一个吊销。这样做的优点在于，加入黑客已经通过JNDI进行注入了，非法启动了一个脚本，这个时候他是没有客户端证书的，因为我们的所有证书完全是在内存中运行的，这个时候如果他想访问其他服务，虽然网络端口是通的，由于他没有客户端证书，他就没有办法在内网环境访问另外一个 服务，他也没有办法监听加密的网络流量，这样就使得威胁最小化，即使你注入了一个服务，他也没有办法横向移动，保障了整个微服务内部的安全。

2.4 统一身份管理

2.4.1 云原生架构

这个图其实和本文第一个图比较像，在第一个图的基础上做了细化。流量从客户端访问，通过DNS、WAF、负载均衡、CDN进入到我们的内部，前面这些都是华为云标准的组件。当流量进入API网关的时候，我们会对API进行控制，这里有一个我们自己研发的API管理平台，对于我们对外发布的API，进行管理，包括负载均衡、熔断限流。当流量进入我们的容器空间，首先会进入到Springcloud，这里所有的服务都会部署PKISDK，是用来做认证的，这个SDK其实是一个类似于Java Agent，他不会入侵到我们的业务系统里面，只要在容器里面，启动的时候以Agent的方式把这个功能启动，就可以保证流量的双向认证和加密。所有的服务的流量都会被记录下路，放到我们的数据库中去，所有的请求都是经过Token验证的，所有的连接都是Https双向认证的，这样就完成了安全性和可观测性的云原生架构构建。

2.4.2 单点登录

下面我们介绍统一身份管理，统一身份管理首先要做单点登录，我们每个人在工作中每天要访问很多的应用，可能是商业应用，也可能是SaaS应用，也可能是开源的应用，还比如是自己开发的应用，用户在访问这些应用的时候，都要输入用户名密码，而且很多商业应用密码要定期轮换，密码强度也不同，这就会产生很大的成本，有一些人干脆就用一个贴纸把自己的用户名密码写下来贴在自己工位上，这样的用户名密码基本上等于没有任何安全可言，针对这种情况我们做了统一的单点登录。

首先在登录方式上我们支持了多种登录方式，比如用户名密码、微信扫描、短信验证码、人脸识别、指纹识别，当用户进行一次登录后，我们通过标准的单点登录协议，和后面的系统做对接，只要用户登陆后拿到可信的Token，就可以登录任何系统。当然这是一个理想的状态，对于不支持标准协议的应用，我们也有办法。一个是网关劫持，通过一个API网关反向代理，在访问系统时，从我们的平台拿到用户名密码进行登录，在代理中提交登录。另一个是浏览器插件，类似记住密码的功能，每次通过浏览器访问，浏览器插件都会把用户名密码带到后台。

当使用单点登陆，用户的用户名密码就很关键，如果用户名密码丢失被别人拿到，别人就可以访问任何系统了，对于这个问题，我们引入了多因素认证，就是先输入用户名密码，在输入手机号验证码，保证密码的安全性。但是这样又降低了便利性，对于这个问题我们做了另一个平台，做了浏览器的指纹识别，只需要第一次输用户名密码和手机验证码，后面如果浏览器指纹没有变化，就只用输入用户名密码即可，当换了一台机器还需要校验手机验证码来保证安全性。此外，还有一些不同第三方的认证的一个互信，比如国内的微信扫码登陆和国外的OKTA认证，两个方式登陆进去，两个区域可以进行互动。刚才讲的都是Web服务，那我们的服务器、网络设备、运维系统的单点登陆如何处理，我们支持标准的LDAP服务，和单点登陆系统的用户密码都是完全一致的，同时也支持了SCIM服务和云厂商对接。

2.4.3 身份治理

上面我们讲了单点登录，下面我们说一下身份治理。什么是身份治理，我们的用户在我们的企业中存储了很多的信息，包括人力资源系统、OA系统、邮件系统等等，我们需要把这个人在单位的唯一标识和身上的各种属性，放到我们的身份管理平台统一处理、梳理、分析。这其中有个问题就是数据不一致，比如在人力资源系统中叫张三，而在邮件系统中叫zhangsan，我们需要把连个账户关联起来。我们通过一些策略，把个人的统一信息，包括岗位、角色等推送到每一个业务系统中去，这样的优势是这个人在单位中具有唯一的编号，唯一的身份，他的这个身份在所有的应用系统中产生的数据、日志都可以关联到人，对人做分析，这对我们的数字化转型是一个必备的功能，当用户的数据达到一定的程度，就可以对用户的数据进行梳理，数据从各个业务系统收集起来之后，在我们统一身份管理平台进行维护，然后把这些身份的源数据作为一个基础能力供应给所有的实质的业务系统，那么打通各个业务系统之间的关键关系，让业务在各个业务系统的流动会更变得更加简单。

3.小结

随着社会的发展，我们可以看到IT系统的复杂性增加，用户的身份、登陆、统一管理都是亟需解决的问题，通过上文的描述和讲解，我们可以了解到派拉云和华为云在身份应用上云的技术架构和业务实现，通过这些我们可以更详细的理解一个安全的身份系统面临的问题，使用的技术，并最后如何解决身份应用上云的一些问题，整体的了解身份应用云上技术架构。

本文参与华为云社区【内容共创】活动第21期。

任务19：《DTSE Tech Talk 技术直播 NO.4》身份应用云上技术架构实践