微服务安全面临的挑战
- 更多的入口点，更高的安全的风险
- 性能问题
- 服务间通讯安全
- 跨多个微服务的请求难以追踪【对于一个服务来说，可观测性是一个很重要的指标，可观测性包含了三个方面的意义】
- 容器化部署导致的证书和访问控制问题
- 如何在微服务间共享用户登陆状态
- 多语言架构要求每个团队都有一定的安全经验
一、 更多的入口点，更高的安全的风险
- 在
原来单块的应用场景下，我的入口点只有一个，就是我们的应用，所有的请求都会从这个入口点进来，可能是 80 端口，也可能是 443端口，反正入口点很少，在这个入口点上，只需要建立一组fitter【J2EE 原生拦截器实现】或者 interecptor【Spring 容器内拦截器的实现】，就可以控制住所有的安全风险 - 那么在一个
微服务环境下，业务逻辑不在是在一个单一的进程，而是分散在很多的进程里面，每一个微服务都是一个 tomcat【进程】，而每一个进程 tomcat 都有自己的入口点，这会导致我们防范的攻击面比原来大的多，风险也会高的多
二、性能问题
-
单体应用：原来的单体应用里面所有的业务逻辑都在同一个进程里面，那么我需要的安全信息也都在里面，请求进来以后，需要验证身份、权限都是在同一个进程里面完成的 - 而在
微服务架构里面，关于需要的安全的信息很可能在单个微服务的进程里面是没有的，比如访问订单的时候，用户的信息、权限的信息在订单系统里面是拿不到的，需要调用安全中心、用户中心来获取相关的信息，这样就需要进行一个远程调用了，就会对性能造成影响
三、微服务间通信安全
单体应用场景下只需要考虑从外部进来的请求是不是安全的，里面涉及到的服务之间相互的调用是不需要我们考虑安全的，但是在微服务场景下从订单去调用物流的时候，是需要跨网络，从一个进程进入另一个进程，所以需要考虑服务之间的通信安全
四、跨多个微服务的请求难以追踪
对于一个服务来说，可观测性是一个很重要的指标，可观测性包含了三个方面的意义
-
log 【日志，用来记录我们系统发生了什么】
分布式环境中，我们每个系统都会单独记录日志，所以日志是分散来记录的，这个时候需要一个机制能够把所有日志串起来 -
metrics【把日志信息聚合起来】
metrics有两个关键要素，第一个是时间窗口，第二个是一个数字【比如说流量：我们一般会说在1秒钟之内有10个请求，在1分钟之内有两百个请求，过去三小时内下了50个单，过去一天的成交额是100万】最简单的metrics是我们的流量，即每秒钟有多少个请求。在单体应用里面，我们很容易控制这个事情，但是在分布式应用中，可能我们的订单能够承受的并发量是500，物流承受的并发量是700，这个时候我们需要一个整个能够承受服务的流控，而不是单一的承受某一个微服务的流控，这也是一个要解决的问题 -
tracing
要解决在经过某一个服务的耗时，以及经过所有服务的耗时，然后统计性能
五、容器化部署导致的证书和访问控制问题
- 在
微服务的场景里面，我们最常用的部署手段就是容器化，在我们以前的部署里边，部一个应用，部一个集群，我们就要4台机器，然后部署4个实例，这个时候我们的IP 地址都是固定的。然后我们要做什么白名单、安装证书，然后在这4个机器上安装证书，然后根据这4个机器的IP 写白名单就可以了 - 而在微服务里面，我们通常是通过容器化完成部署的。容器化的一个好处就是带来了一个不可变的服务器，当一个容器一旦产生，里面的内容是不会变的，不可变的服务器意味着你可以随时干掉这个容器，然后在另外一个地方启用一个一摸一样的，当我们请求压力大的时候，立马再启用多个容器，来把压力分担掉，所以在微服务部署里面，容器化或者不可变的服务是一个很重要的原则，在这样一个情况下，就是导致我们证书、访问控制会出现一个问题。当然我们可以把证书打到镜像里面，这就要求我们服务的每个镜像是不一样的，那么这个时候，这种差异就会带来维护上的困难，当然也是可以的
- 当然更好的解决方案是我们有一个自动化的机制，在每个容器创建的时候，根据这个容器的属性不同，有一个自动注入的机制，把他需要的证书注入进去，这样每个应用就不用关心自己的证书问题了
- 另外一个访问控制：我们原来机器就4个节点，我写个简单的白名单，写个IP，针对这4个IP能对外访问。或者别人访问我们的时候，只写这4个IP 就可以了
- 但是在容器化的部署中，我们可能随时产生容器的调度，容器的扩缩容，IP 地址是不断变化的，这个时候如何控制白名单、黑名单进行访问控制也是我们要面临的新的问题
- 但是在容器化的部署中，我们可能随时产生容器的调度，容器的扩缩容，IP 地址是不断变化的，这个时候如何控制白名单、黑名单进行访问控制也是我们要面临的新的问题
六、如何在微服务间共享用户登陆状态
- 原来在单体应用中，我们用的是固定session，session是覆盖到所有服务
- 但是在微服务环境下，在进入订单服务的时候，我们需要知道用户是谁，在进入物流服务的时候，我们需要知道用户是谁
- 如何在多个应用之间共享用户登陆状态？在这个请求中所涉及的微服务都知道当前用户是谁？这样 一个信息
七、多语言架构要求每个团队都有一定的安全经验
常见的微服务安全整体架构
整体架构.png
OAuth 2.0 简要介绍
角色分类
用户
真正的人
客户端应用
可能是一个 Web App 或者手机 App，用户会直接访问这些应用
认证服务器
作用
它的作用是认证，证明一个人真的是他，然后发出令牌需要做的事情
1）首先它需要知道有哪些客户端应用【被授权系统】要请求令牌
2）还需要知道有哪些合法的用户【因为他是认证服务器】
3）最后需要知道道发出去的令牌应该用于访问哪些资源服务器认证服务器和资源服务器扮演者一对多的关系，一个认证服务器可以替无限多个资源服务器做认证
资源服务器
存储资源的服务器
OAuth.png
核心交互流程
- 用户在使用客户端的时候，它首先要去认证服务器做一个认证，认证服务器的作用是用来认证说自己是“张三”的真的是张三
- 证明了以后会发一个令牌给客户端应用，告诉客户端应用说，你拿这个令牌，这个令牌就代表了张三这个用户
- 下边客户端应用就会拿这个令牌去访问我们的资源服务器，也就是我们的微服务，这个时候就会带着这个令牌去访问，相当于代表用户去访问我们这个微服务
- 资源服务器【也就是我们的微服务】收到这个请求以后，拿到请求里面的令牌后，他会去访问认证服务器来验证请求中的令牌，问认证服务器，我现在收到一个令牌，这个令牌是谁，认证服务器告诉他，这个令牌是张三，订单服务【资源服务器】就会认为这个请求是张三这个用户发过来的
核心流程的本质
- 本质仍然是一个基于令牌 token 的认证方式
- 这个和我们基于 Cookie、Session 的本质是一样的，都是基于 token 的认证方式
- 本质都是认证服务器发送令牌给客户端，客户端携带令牌进行访问
OAuth 2.0 微服务架构下的问题
- 安全处理和业务逻辑耦合，增加复杂性和变更成本
- 随着业务节点增加，认证服务器压力增大
- 多个微服务同时暴露，增加了外部访问的复杂性
解决方案
所有请求都由网关进行转发
- 安全处理都放在网关，这样安全处理和业务逻辑就不会耦合了
- 即使业务节点增加了，认证服务器承受的压力变小了【因为业务节点增加了，网关可能也需要扩容，但是认证服务不会直接受网关的影响】
- 外部访问只需要访问网关即可，不需要关注具体的微服务
微服务.png
