论文部分内容阅读
摘 要：近年来，微服务的应用开发架构越来越受到软件开发人员的关注和青睐，很多公司都已经开始使用微服务架构来进行应用程序的开发。但是微服务架构的应用，也引入了很多对应的安全问题。本文主要从微服务架构核心安全问题，从用户访问微服务的身份认证和鉴权、微服务与微服务之间的通信时身份认证与鉴权，微服务与第三方通信的边界三个方面进行分析，并对目前针对这些问题常用的解决方案和技术进行研究和探索。
微服务架构的引入为软件的开发带了诸多好处，比如开发语言选择的灵活性，缩短软件的开发周期，减少小团队软件开发成本，增强应用服务的伸缩能力等等。微服务架构在带来各种开发优势的同时，也带了分布式系统的很多安全问题，微服务架构在带来各种开发优势的同时，也带了分布式系统的很多安全问题。对于微服务的安全性问题来说，其应用层的访问权限和鉴权的安全性问题是整个安全体系中占据着至关重要的地位。
1 微服务架构下安全问题简述
微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用服务程序都可以独立在自己的进程中运行，并且相互之间可以使用轻量级机制来进行通信。这些服务程序主要围绕业务进行构建，每个应用程序都可以部署到独立的服务器上，因此其可以使用自动部署机制进行独立部署，而且每个应用服务都可以使用不同的编程语言进行编写，也可以使用不同数据管理技术，
传统的单体应用时，通常所有的服务都是部署在同一台服务器上的，各应用接口之间的调用通常是属于本地调用方式，而且每项服务（或者组件）不需要对用户进行验证。验证工作主要集中由拦截器（如JavaEE的servlet）处理，拦截器对访问身份和全向进行验证审查其是否允许访问。验证完成之后，在不同平台上的不同服务（或者组件）间发送用户登录凭证。而微服务模式下，不同的服务是分别部署在不同的服务器上的，因此每个服务器上都需要进行用户身份验证和鉴权信息。
基于以上现象，微服务架构的身份认证和鉴权问题是影响整个微服务架构安全的核心问题，其对微服务架构的推广和应用起着关键性的作用。
2 微服务架构的身份认证与鉴权问题
2.1用户访问微服务的身份认证和鉴权
用户访问微服务时，主要是用户身份信息传递的安全性问题，其包含用户身份信息的认证信息和对应身份和权限信息的管理问题。对于用户访问微服务的身份认证与鉴权的方法，
第一种现有的方法就是使用单点登录（SSO），但是在这种方案中，每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，当动辄数十个微应用时，这种方案的弊端会更加明显。
第二种是分布式的Session，这种方案的原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。在某些场景下，这种方案很不错，用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性了。第三种方法就是客户端 Token 方案，这种方案里令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，Borsos 更喜欢使用JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。目前还有一种解决方案是客户端Token与API网关结合，这个方案里所有请求都通过网关，从而可以有效地隐藏了微服务。在请求时，网关将原始用户令牌转换为内部会话ID令牌。这种方案的出现主要是为了解决第三种方案中撤销服务难的问题。
2.2微服务与微服务之间的通信时身份认证与鉴权
微服务之间的产生通信的场景主要包括用户间接触发的微服务之间的相互访问和非用户触发的微服务之间的相互访问两种，针对这两种情况，根据应用系统的数据敏感程度的不同，对于系统内微服务的相互访问可能有不同的安全要求充分考虑，对于微服务之间通信时的身份认证和鉴权问题，目前常用的方式有采用Service Account（服務账号）进行安全控制，这种方法是使用用户账号（User Account）来标识一个系统用户，并对其进行身份认证和操作鉴权。类似地，可以为系统中每一个服务也创建一个账号，称为服务账号（Service Accout）。该服务账号表示了微服务的身份，以用于控制该微服务对系统中其它微服务的访问权限。当一个微服务访问另一个微服务时，被访问的微服务需要验证访问者的服务账号，以确定其身份和资源操作权限。另一种方法是采用服务之间相互进行身份识别的SPIFEE标准。
2.3微服务与第三方通信的边界安全问题
除用户访问和微服务之间的相互访问外，外部的第三方系统也可能需要访问系统内部的微服务。对于微服务集与外部世界的通信，一般由API网关模式实现。利用API网关模式，需要进行声明的微服务能够在该网关内获得对应的API。当然，并不是所有微服务都需要立足于API网关实现声明。而且最终用户对微服务的访问（通过API实现）应当在边界或者API网关处进行验证。对目前最为常见的API安全保护模式为OAuth2.0方式进行研究和验证。
对于微服务与第三方应用的身份认证与鉴权问题，目前也有了一些解决方案，第一种就是使用API Token，由微服务应用提供一个API Token的生成界面，用户登录后可以生成自己的API Token，并在第三方应用使用该API Token访问微服务的API。这样就只允许第三方应用访问该Token所属用户自身的数据，而不能访问其他用户的敏感私有数据。但是某些第三方应用需要访问不同用户的数据，或者对多个用户的数据进行整合处理，就出现了使用 OAuth来进行权限控制的操作。这种方式在当第三方应用访问服务时，应用会提示用户授权第三方应用相应的访问权限，根据用户的授权操作结果生成用于访问的Token，以对第三方应用的操作请求进行访问控制。
3 总结
微服务架构越来越受到开发者的喜爱和关注，本文主要是对微服务架构模式下身份认证和鉴权技术进行分析，提出微服务架构所面临的安全性问题，并针对微服务架构需要进行身份认证和鉴权的三种情况进行分析，并对着三种情况下所采用的身份认证和鉴权技术进行分析和比较。
微服务架构的引入为软件的开发带了诸多好处，比如开发语言选择的灵活性，缩短软件的开发周期，减少小团队软件开发成本，增强应用服务的伸缩能力等等。微服务架构在带来各种开发优势的同时，也带了分布式系统的很多安全问题，微服务架构在带来各种开发优势的同时，也带了分布式系统的很多安全问题。对于微服务的安全性问题来说，其应用层的访问权限和鉴权的安全性问题是整个安全体系中占据着至关重要的地位。
1 微服务架构下安全问题简述
微服务架构是一种将单个应用程序作为一套小型服务开发的方法，每种应用服务程序都可以独立在自己的进程中运行，并且相互之间可以使用轻量级机制来进行通信。这些服务程序主要围绕业务进行构建，每个应用程序都可以部署到独立的服务器上，因此其可以使用自动部署机制进行独立部署，而且每个应用服务都可以使用不同的编程语言进行编写，也可以使用不同数据管理技术，
传统的单体应用时，通常所有的服务都是部署在同一台服务器上的，各应用接口之间的调用通常是属于本地调用方式，而且每项服务（或者组件）不需要对用户进行验证。验证工作主要集中由拦截器（如JavaEE的servlet）处理，拦截器对访问身份和全向进行验证审查其是否允许访问。验证完成之后，在不同平台上的不同服务（或者组件）间发送用户登录凭证。而微服务模式下，不同的服务是分别部署在不同的服务器上的，因此每个服务器上都需要进行用户身份验证和鉴权信息。
基于以上现象，微服务架构的身份认证和鉴权问题是影响整个微服务架构安全的核心问题，其对微服务架构的推广和应用起着关键性的作用。
2 微服务架构的身份认证与鉴权问题
2.1用户访问微服务的身份认证和鉴权
用户访问微服务时，主要是用户身份信息传递的安全性问题，其包含用户身份信息的认证信息和对应身份和权限信息的管理问题。对于用户访问微服务的身份认证与鉴权的方法，
第一种现有的方法就是使用单点登录（SSO），但是在这种方案中，每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，当动辄数十个微应用时，这种方案的弊端会更加明显。
第二种是分布式的Session，这种方案的原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。在某些场景下，这种方案很不错，用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性了。第三种方法就是客户端 Token 方案，这种方案里令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，Borsos 更喜欢使用JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。目前还有一种解决方案是客户端Token与API网关结合，这个方案里所有请求都通过网关，从而可以有效地隐藏了微服务。在请求时，网关将原始用户令牌转换为内部会话ID令牌。这种方案的出现主要是为了解决第三种方案中撤销服务难的问题。
2.2微服务与微服务之间的通信时身份认证与鉴权
微服务之间的产生通信的场景主要包括用户间接触发的微服务之间的相互访问和非用户触发的微服务之间的相互访问两种，针对这两种情况，根据应用系统的数据敏感程度的不同，对于系统内微服务的相互访问可能有不同的安全要求充分考虑，对于微服务之间通信时的身份认证和鉴权问题，目前常用的方式有采用Service Account（服務账号）进行安全控制，这种方法是使用用户账号（User Account）来标识一个系统用户，并对其进行身份认证和操作鉴权。类似地，可以为系统中每一个服务也创建一个账号，称为服务账号（Service Accout）。该服务账号表示了微服务的身份，以用于控制该微服务对系统中其它微服务的访问权限。当一个微服务访问另一个微服务时，被访问的微服务需要验证访问者的服务账号，以确定其身份和资源操作权限。另一种方法是采用服务之间相互进行身份识别的SPIFEE标准。
2.3微服务与第三方通信的边界安全问题
除用户访问和微服务之间的相互访问外，外部的第三方系统也可能需要访问系统内部的微服务。对于微服务集与外部世界的通信，一般由API网关模式实现。利用API网关模式，需要进行声明的微服务能够在该网关内获得对应的API。当然，并不是所有微服务都需要立足于API网关实现声明。而且最终用户对微服务的访问（通过API实现）应当在边界或者API网关处进行验证。对目前最为常见的API安全保护模式为OAuth2.0方式进行研究和验证。
对于微服务与第三方应用的身份认证与鉴权问题，目前也有了一些解决方案，第一种就是使用API Token，由微服务应用提供一个API Token的生成界面，用户登录后可以生成自己的API Token，并在第三方应用使用该API Token访问微服务的API。这样就只允许第三方应用访问该Token所属用户自身的数据，而不能访问其他用户的敏感私有数据。但是某些第三方应用需要访问不同用户的数据，或者对多个用户的数据进行整合处理，就出现了使用 OAuth来进行权限控制的操作。这种方式在当第三方应用访问服务时，应用会提示用户授权第三方应用相应的访问权限，根据用户的授权操作结果生成用于访问的Token，以对第三方应用的操作请求进行访问控制。
3 总结
微服务架构越来越受到开发者的喜爱和关注，本文主要是对微服务架构模式下身份认证和鉴权技术进行分析，提出微服务架构所面临的安全性问题，并针对微服务架构需要进行身份认证和鉴权的三种情况进行分析，并对着三种情况下所采用的身份认证和鉴权技术进行分析和比较。