从五个方面入手保障应用安全

2019-07-09  本文已影响0人  磐不渝

前言

随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。

对于应用程序安全,需要在应用架构、代码、运维、管理等多个角度进行安全性评估,在整个应用程序生命周期中,软件工程师们则主要负责身份验证、访问授权、进程间通信安全、代码安全、安全的管理与审计这五方面的方案落地。这五个方面中,前三个侧重于技术实现,代码安全、管理与审计则更需要规范的管理和执行,本文将着重对认证、授权、通信等技术相关内容重点介绍,管理规范相关内容仅做简单说明。

文中以采用了微服务架构的应用程序为背景进行描述,但多数的应用程序的安全方案与是否采用微服务架构并没有强关联,如有差异的地方,文中会提出来。文中描述过程中会涉及到一些微服务架构中相关的概念名词,说明如下:

名词 解释说明
应用 即应用程序,本文中特指一个微服务应用
业务系统 即传统意义上的软件系统,如:OA办公系统、个贷系统等。微服务架构中,业务系统不是个业务逻辑概念,一个业务系统由一个或多个应用(微服务)组成。
网关 即API Gateway 是客户端访问应用的入口,后端应用的API门户。通常负责身份认证、API管理、路由、编排等等
服务 即API,特指程序接口 ,如服务调用 即为 API调用。需注意在本文中不要与微服务、应用等概念混淆
认证管理系统 认证管理系统(IAM),负责身份识别和访问管理,其核心业务是应用系统的访问者的注册、账号密码凭证、访问者基本信息的管理和对已注册的访问者进行合法性认证和访问授权。
授权服务 指身份认证授权服务,在微服务架构中,通常是认证管理系统(IAM)的一个应用。认证中心具备读取"访问者"身份信息的权限。负责核实"访问者"的身份、为访问者颁发授权码、访问令牌等能力
访问者 在安全领域统称"Principal",指应用程序功能UI或API的使用者,包含两类:1,基于登录的客户端 2,API 客户端
API客户端 API Client 即客户端程序类型的访问者,这类客户端自身具备部分API的访问权限,不需要用户授予其访问权限。
基于登录的客户端 Login-based Client ,用户访问服务提供者的应用程序的功能时,需要通过一个客户端交互界面来与服务提供者交互,用户需要先登录,然后由客户端代表用户身份去访问服务提供者应用程序。

微服务架构中安全访问相关的简化版的运行视图如下:

运行视图.png

图中星号*标注的位置就是服务调用过程中安全访问过程中的一些需要认证鉴权的关键位置,如:内外部访问认证、令牌验证与授权、内外网通信协议等。后续章节将对这部分展开分析。

身份认证

多数业务功能类的应用的首要任务就是需要做身份认证。对于数据公开或新闻发布类的门户网站类应用不需要考虑这一点,他们更关注的是数据开放之前的管理和审批。

身份认证或身份验证(Authentication),顾名思义就是对应用程序的"访问者"的身份进行验证识别。访问者分两类。

1. 使用认证管理系统IAM进行访问者注册认证

不论是用户还是API客户端,在访问应用之前,均需要先到认证管理系统IAM进行注册,以创建其的身份凭证(用户账号和密码、客户端ID和密码)。有了身份凭证,才能通过认证服务的验证。

统一认证管理系统IAM(Identity and Access Management )负责身份识别和访问管理,其核心业务是应用系统的访问者的注册、账号密码凭证、访问者基本信息的管理、对已注册的访问者进行合法性认证和访问的初级授权(获取访问者自身数据)等等。

​有些企业还会将组织机构、角色甚至业务功能权限数据也一并归入IAM系统管理。IAM对权限管理范围可大可小,不同企业的管理需求和力度也不一样,需要集中进行功能授权管理还是下放到业务系统中自治各有优缺点,选择合适自己的方式就好。

2. IAM认证管理系统使用OAuth2.0进行访问者授权

​传统WEB应用对于用户登录访问,采用会话状态在服务端保存的方案,用户请求通常采用会话粘滞(Sticky session)或会话复制(Replication session)策略,来保持客户端和服务端的会话。为了会话共享而不得不将会话信息写入公共缓存或数据库,导致微服务应用之间产生了耦合性。

​微服务架构中不推荐采用服务端保存会话的方式,如果引入状态管理不是必要的,那么应用尽量保持无状态运行。推荐使用另外一种基于访问令牌的模式,这种模式下应用中不需要保存会话状态,并且API客户端和基于登录的客户端均方便使用访问令牌。微服务架构推荐使用OAuth2.0 授权协议来搭建IAM系统。Spring 体系可以基于Spring Security OAuth实现授权服务器和客户端。

在本文的上下文中,面向的是企业基于微服务的总体架构进行方案设计,企业整体架构中,默认认证体系方案为企业统一认证而非业务系统各自认证(此方案的前提条件)。OAuth2.0本身是为三方授权而设计的,而在本方案中讨论的是企业内部应用的整体认证和授权,不存在第三方。因此本方案中基于OAuth2.0实现的授权服务可以简单理解为仅为IAM统一认证管理系统中的“账号管理应用资源提供者”做授权,并且默认实现为认证通过自动授予已登录账号数据的读写权限,不在登录通过后与用户交互确认是否同意授权。其他业务系统作为资源提供者的授权则是系统管理员预置好的授权,也不需要由用户登录时决定是否授权。这个OAuth2.0的使用场景可能与其他OAuth2.0相关资料或授权框架默认实现有所不同,请大家注意区分。

OAuth协议中定义了四种角色:

角色分析:

在OAuth2.0授权协议中,主要定义了四种许可类型:授权码许可、简单许可、密码凭据许可和客户端凭据许可,详细请参见规范内容:rfc6749 - The OAuth 2.0 Authorization Framework

下面我们根据访问者类型,分别推荐合适的授权方案。

2.1 API客户端作为访问者,使用客户端凭证许可

典型的API客户端如批量调度系统、物联网设备程序等,通常不需要用户登录授权就可以自动运行。使用客户端凭证许可类型比较适合。

客户端凭证.png

上图为OAuth2.0规范标准流程图,结合此场景中,对应OAuth2.0中的角色,API客户端作为OAuth2.0的客户端、IAM则为授权服务器。

  1. (A) API客户端与授权服务器IAM进行身份验证并请求访问令牌。
  2. (B) 授权服务器IAM对API客户端进行身份验证,如果有效,颁发访问令牌。客户端存储访问令牌,在后 续的请求过程中使用。如果令牌过期或失效或需要重复此流程再次申请访问令牌。

其他说明:

  1. 此类应用通常不具备与用户交互的UI,无需用户授权,具备保证客户端凭证安全的能力
  2. 此类应用后端需要具备通过https访问授权服务器的能力
  3. 此类应用或设备需要具备存储Access Token的能力

2.2 基于登录的客户端作为访问者,使用授权码许可

2.2.1 Web 应用

OAuth2.0 协议中提出前端单页Web应用可以用简单许可模式,但简单许可模式有些局限性,令牌到期就需要重新登录授权,不支持令牌刷新,用户体验较差。很多使用简单授权的应用为了改善用户体验会颁发一个长期的令牌几天甚至几周。

如果有条件使用授权码模式,支持刷新令牌则是一个更好的选择。对访问令牌时间较短如2分钟,刷新令牌为一次性令牌有效期略长如30分,如果存在已作废的刷新令牌换取访问令牌的请求,授权端点也能够及时发现做出相应入侵处理,如注销该用户的所有刷新令牌。在保持良好用户体验的同时还兼顾了部分安全性。

本场景以微服务架构中常见的前后端分离Web应用作为示例,前端是单页应用,网关作为Web后台是服务提供端应用功能入口,也可作为OAuth2.0的客户端,让前端Web应用能借助网关实现授权码交换。因此在微服务架构中,即便是纯前端单页应用类的Web应用,仍可以用基于网关交互的授权码模式获取访问令牌。其他非前后端分离的混合Web应用自身就是客户端,不需要借助网关交换访问令牌。

授权码.jpg

上图为OAuth2.0规范标准流程图,结合此场景对应OAuth2.0中的角色,用户是资源所有者、浏览器为用户代理、网关作为被授权的客户端、IAM则为授权服务器。

  1. (A) 网关通过引导浏览器开始流程授权流程,重定向到统一认证中心的登录页面。
  2. (B)用户输入密码登录,授权服务器验证用户身份,并确认用户是否授权网关的访问请求。
  3. (C)用户授权后,认证中心根据之前网关注册时提供的回调地址,引导浏览器重定向回到网关。重定向URI包含授权码
  4. (D)网关通过包含上一步中收到的授权码和网关自身凭证从授权服务器IAM的请求访问令牌。
  5. (E)授权服务器IAM对网关进行身份验证,验证授权代码,并确保接收的重定向URI与网关注册时的URI相匹配。匹配成功后,授权服务器IAM响应返回访问令牌与可选的刷新令牌给网关。

其他说明:

  1. 为了前端会话保持,访问令牌由网关在响应时返回到前端,存储到前端存储空间,如Cookie(不超过4k)、Local Storage、Session Storage等。
  2. 访问令牌失效后,网关根据自己的客户端凭证+刷新令牌一起发送授权服务器,获取新的访问令牌和刷新令牌,并再返回响应中将访问令牌写入到用户浏览器的存储中
  3. 授权码模式中,用户的凭证(用户名、密码)是用户通过浏览器与授权服务交互,并不经过网关, 安全性最好。

2.2.2 移动App

个人移动设备上安装的原生App本身具备实现授权码流程的能力,不需要借助网关实现授权码流程。认证通过后网关仅负责校验访问令牌即可。

移动App-授权码.jpg

移动App实现登录重定向通常可以采用如下方式:

移动端App的运行环境是不可信的,容易被恶意App入侵的风险,包含如下两种情况:

  1. 重定向过程中的回调URL参数,容易被恶意App占用URL Scheme或者监听localhost端口截取。
  2. 运行环境不可靠,移动App不具备安全保存客户端秘钥的能力,而使用授权码获取访问令牌时需要校验客户端秘钥。

基于上述风险和问题,移动App基于授权码获取访问令牌的流程需要进行优化解决,rfc规范中建议的实现方案是移动App授权流程采用使用带有PKCE支持的授权码模式。PKCE, 全称Proof Key for Code Exchange,即保护授权代码授权。这其实是通过一种密码学手段确保恶意第三方即使截获Authorization Code或者其他密钥,也无法向认证服务器交换Access Token。

经过PKCE改进的授权码、访问令牌交换过程示意图如下:

PKCE.png

上图为PKCE模式下授权码申请和交换访问令牌的过程,说明如下:

  1. (A) 移动App客户端创建并保存名为code_verifier的随机秘钥串,并将秘钥字符串加密转换的结果t(code_verifier)称为code_challenge,将转换后的code_challenge以及转换方法一并发送到授权服务中。
  2. (B) 授权服务返回授权码并记录code_challenge和转换方法t_m
  3. (C) 移动App客户端收到授权码后,将授权码和code_verifier秘钥串发送到授权服务器,用以申请访问令牌。
  4. (D) 授权服务器根据转换方法t_m 转换code_verifier 并与步骤A中收到的code_challenge比较,如果一致则返回访问令牌,否则拒绝非法请求。

第三方无法根据code_challenge推导出code_verifier,因为code_challenge采用了不可逆加密方式。只有移动App客户端自己才知道这两个值。因此即使恶意App截获了code_challenge和授权码,也无法换取访问令牌避免了安全问题。要实现这种移动App的PKCE授权码模式,出移动App自身外,还需要IAM的授权服务器基于标准的授权码流程扩展配合实现。

关于移动App安全认证的详细内容请参考官方规范:

2.3 高度信任的特权类客户端,可以使用资源所有者密码凭据许可

用户密码凭据.png

上图为OAuth2.0规范标准流程图,结合此场景中,对应OAuth2.0中的角色,用户是资源拥有者、特权应用是客户端、IAM提供授权服务器

其他说明:

3. 使用API 网关作业务系统访问入口,负责验证访问令牌

访问者能够访问的接口通常是两类:身份认证API、应用功能类API。

用户登录认证由IAM授权服务器配合用户资源服务负责。认证成功后,IAM访问者颁发访问令牌。后续对应用功能的访问过程中,均须携带访问令牌以表明访问者的身份。

3.1 由网关负责客户端身份验证

网关作为业务系统的API入口,当面向外网的访问者时网关还是内外网的分界,访问令牌验证理应由网关负责,不应该将令牌验证的事情交给服务提供者。 网关负责验证既能避免未经验证的请求进入内网,又能够简化服务提供端的代码,服务提供端无需处理不同类型客户端的验证。实际上好处还不只这些,在网关可以统一做流控无需应用端重复建设类似功能;系统内部调试、变更敏捷,减少了跨组织交互。

网关验证访问令牌有两种方案:网关委托认证服务验证、网关直接验证,说明如下:

网关委托IAM校验令牌.png
  1. 客户端成功认证后,使用UUID类型的访问令牌调用网关上的服务
  2. 由于UUID类型令牌不包含客户端的信息,网关需要委托IAM认证服务校验令牌
  3. 令牌检查合法后,将请求路由到服务提供者
  4. 应用中也无法解析令牌,需要根据UUID令牌到IAM中获取用户信息
网关直接校验令牌.png
  1. 客户端成功认证后,使用JWT令牌调用网关上的服务
  2. 网关自己直接解密JWT令牌进行校验
  3. 令牌检查合法后,将请求路由哦到服务提供者
  4. 应用受到请求后,如果需要更多权限信息,如果可以根据Token去权限管理服务获取权限信息(非必须步骤,需要时添加)。

上述两方案中,方案一的令牌是无业务含义的身份标识字符串,每次收到请求网关都去IAM认证,对IAM认证服务的性能压力较大。方案二中IAM颁发的令牌中包含部分客户端或用户信息,使用JWT加密,IAM将验证方式或SDK提供给了负责认证的网关。对于IAM来说,减少了每次请求令牌认证带来的通信次数,减轻了IAM的压力。

推荐采用方案二实现令牌检查,需要注意的是方案二中的JWT令牌中仅包含必要的信息即可,不要放太多的角色权限信息。后续功能中需要额外的信息时,可以根据令牌再去IAM中获取。如果令牌中存放了很多的权限数据,一旦后台的授权数据发生变化,令牌中的权限数据与实际IAM的权限会存在不一致的问题,只能强制用户下线重新登录。

JWT令牌是防篡改的,但并不加密,如需要存储到浏览器存储中,建议采用JWT+JWE方式进行令牌加密。令牌中存放必要少量数据即可,避免滥用。多数服务器通常会对Http header、cookie长度做限制。

3.2 系统内部应用是否通过网关?

我的答案是不需要,否则太麻烦了。通常网关是独立团队负责,API变更发布、内部联调验证还得跨团队协调实在不可行。推荐系统内直通不走网关,系统之间访问必须走网关。要做到这一点,应用也需要实别请求来源进行客户端认证,这种认证方案没必要太复杂,应用只应该允许信任的网关和系统内部应用程序访问其服务,不允许系统外部请求绕过网关直接调用,因此,需要在网关和系统内部应用之间这个小范围内建立信任,常见方案有两种:

方案一优点是实现简单,缺点是安全级别略低,常见的企业架构中,网关和业务系统会是不同团队甚至不同的厂商负责开发维护,内部令牌共享给了其他团队负责的网关,存在一定的风险。方案二相比方案一略复杂一点,安全性更高,系统内互通用内部令牌,系统和网关认证使用了网关提供的安全令牌检查方式。两种方案可根据实际需求选择。

访问授权

通过认证的API客户端能够访问网关开发的所有API吗?通过认证的用户能够调用所有API吗?通过认证的用户允许调用修改订单的接口,那么他能修改所有人的订单吗?

很显然绝大多数场景下上述三个问题答案都是"不能"。在绝大多数业务场景中除了对访问者的身份认证之外,我们还需要再进一步控制权限。

1. API客户端访问网关接口时,网关需进行API权限控制

如果访问者是API客户端时,API调用的权限需由网关进行控制。建议采用先订阅再访问的授权模式,网关应该仅允许API客户端访问其订阅过的API 。 具体实现方法就是绝大多数网关都会提供的基于API Key控制API访问的方式。

需要注意的是,仅使用API key的访问控制是不够的。API Key是在网关订阅API时生成的一串唯一编号,并不具备识别客户端身份的能力。就好比以前买火车票是不实名的,谁拿到火车票,都可以乘坐对应车次。火车票实名制之后,首先需要核验身份证,核验通过后才能购票乘车。如果证票不符,则不允许乘车。

将客户端认证和API Key配合进行访问认证和权限校验才是个更安全的方案。

API 权限控制.png

上图为访问令牌结合API Key的认证鉴权示意图,说明如下:

2. 用户访问应用功能时需要进行权限控制

用户访问的功能权限或数据权限不要交给网关管控,原因是网关仅能支持API Path授权,而实际需要控制的用户权限有很多,如菜单、API、数据等。如果由网关控制用户权限,管少了不满足需求,管多了就要耦合太多应用数据。

因此推荐用户权限由业务系统自行管理维护和控制。每个业务系统内部如果需要控制用户权限,可以建设一个基础权限框架,负责管理权限数据,并提供访问请求拦截和权限检查的SDK给其他应用。

也有部分企业权限管理要求较高,将系统内部的基础权限框架抽取为独立的权限管理服务,由独立团队维护该服务,采用分布式部署+权限缓存的方式保障性能。这样做的好处是权限模型统一、容易对权限变更进行审批控制和审计。缺点是跨团队交互,变更流程复杂。

关于权限管理,是业务系统自治或是集中管控,根据企业自身的需求特点决定即可。

通信安全

通信安全的方案就是基于传输过程加密的方式,常见的选择就是使用Https协议通信。

微服务架构体系中,逻辑层面上外部请求接入都是通过网关作为入口,网关作为内外网的分界,实际部署上,网关本身也是多实例分布式的高可用部署形态,前面架设有一个负载均衡F5或nginx,用来对外提供Https协议接入和路由转发,而网关内部就是企业内网,默认是可信任的,内网的系统之间的通信会采用更轻量级的HTTP协议。此方案中微服务换成SOA,把网关换成ESB,就是传统的SOA架构中的安全通信方案,本质上没有区别。

示意图如下,

内外网通信协议.png

为什么用了https就能保证通信安全呢?https是http+ssl,采用密码学手段对通信报文做了加密,使得报文无法被篡改,做到了安全传输,从而保障了通信安全。关于https原理和负载均衡器证书配置相关资料网络上有很多,请大家即用即查。

代码安全

管理审计

运维管理安全方面,根据安全需求,要有安全相关的管理规范和工具支撑,对系统管理、权限分配和关键数据进行严格管控,并做好操作审计日志记录。

比如很多安全级别高的行业或企业中如军工类,对于业务系统的修改、权限管理审计做了严格的流程规范和功能支撑。如典型的三员管理,采用三权分立、互相制约的思路,包含系统管理员、安全管理员、安全审计员三个角色,互相能看到对方的信息,将业务过程分成不同的段,每段由对应人员负责,不让任何人掌控全局。

审计工作是非常重要的一环,没有任何系统和流程是绝对安全的。关键的操作、数据变化等审计日志需要完整记录。一旦发生问题,可以通过审计日志排查分析追踪。常见内容举例如下:

以上这些审计方面的工作中,如果是基于API相关的审计信息记录,如边界交互报文数据,建议基于统一的技术框架进行记录管理。一些内部实现方法,则可以采用接口、方法上加注解,AOP拦截后记录的方案。其他情况可根据实际需求设计审计数据存储的方案。

参考引用

转载本文需注明出处:从五个方面入手保障应用安全

上一篇下一篇

猜你喜欢

热点阅读