一种银行应用安全控制的实现方法、系统及存储介质与流程

1.本发明涉及金融服务安全保证应用领域，更具体的说涉及一种银行应用安全控制的实现方法、系统及存储介质。


背景技术：

2.随着科技的突飞猛进和信息技术的广泛运用，互联网逐渐成为人们相互联系和业务往来的必要工具。近几年，互联网技术大量运用于银行业务并逐渐成熟。互联网系统安全性越来越收到银行的关注。
3.以互联网应用系统安全为目标，对互联网应用系统的安全问题进行了分析和研究，对公钥基础设施pki(public key infrastructure)的概念以及基本结构和核心技术进行了详细讨论，另外对目前流行的防火墙技术和入侵检测方法进行了分析。银行传统的网上银行的安全机制有以下几种：
4.1、网站认证：银行通过有认证的第三方机构颁发安全证书。有效的防止了网站被假冒，被钓鱼的风险。
5.2：传输安全性：网上银行采用了国际通行的ssl协议加强信息传输的安全。在传输数据时使用加密的因特网安全传输协议https，在一个会话过程开始时，https现在客户端和银行端的web server之间用102bit的rsa算法交换一次加密密钥，以后https就用该加密秘钥用40bit的rc4算法对所有的来往客户端和银行端的数据进行加密，具有很高的安全性。
6.传统加密技术的安全性可以很好的保障系统交易的安全性，但是由于传统的安全机制太过于笨重，在新兴的互联网时代，这种使用ukey做为安全加密的机制显得不合时宜，特别是目前处于移动互联网时代，大部分的移动设备不具备读取这种ukey。因此新互联网时代大部分使用oauth2.0进行对用户的授权认证。oauth就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌(token)，用来代替密码，供第三方应用使用。oauth2.0规定了四种获得令牌的流程：授权码(authorization-code)、隐藏式(implicit)、密码式(password)、客户端凭证(client credentials)。
7.oauth2.0解决了授权认证的问题，https传输协议解决了传输过程中的安全性。但是目前大部分的系统在客户端通过浏览器或者抓包工具看到的数据是明文，技术人员通过分析客户端与服务端传输的报文。使用特殊的手段进行交易的重放和修改交易接口数据，以及通过工具模拟报文对系统进行攻击等。传统的安全机制就不能很好的处理。


技术实现要素：

8.本发明所要解决的技术问题是防止数据在客户端被抓取造成数据泄露，提高系统安全性。
9.为了解决以上问题本发明提供了一种银行应用安全控制的实现方法，通过基于
springcloud的综合网关模块实现对交易的检查，通过oauth2.0的四种获取令牌的方式实现授权，其特征在于将oauth2.0的四种获取令牌方式中增加绑定客户信息，在客户端和服务端增加用户认证，只有后台对客户信息进行了认证成功后，才获得授权查询本客户相关的信息。
10.所述的银行应用安全控制的实现方法，其特征在于所述综合网关模块进行了跨站脚本攻击检查、sql脚本注入检查、交易重放机制检查、流量控制、熔断检查和负载均衡。
11.所述的银行应用安全控制的实现方法，其特征在于使用https协议在传输过程中对整个传输数据进行数据加密，同时还在客户端将整个交易报文使用国密算法sm4进行对称加密。
12.所述的银行应用安全控制的实现方法，其特征在于使用国密算法sm4进行对称加密过程具体如下：
13.在客户端获取oauth2.0的过程中，服务端产生一对sm2的公钥和私钥，将公钥返回给客户端，客户端收到公钥后将公钥存储在本站路径下，不允许进行跨站使用；
14.客户端收到令牌和公钥后，用令牌和公钥进行一次运算，产生一个sm4的密钥，并用sm2返回的公钥进行sm2算法的加密；
15.服务端用sm2的私钥进行解密，并且刷新令牌的客户信息数据内容，将sm4私钥进行关联；
16.客户端和服务端使用sm4密钥进行数据加解密。
17.所述的银行应用安全控制的实现方法，其特征在于交易在网关路由到业务系统之前在网关路由进行数据包的解密，在交易返回客户端之前进行数据包的加密。
18.所述的银行应用安全控制的实现方法，其特征在于通过oauth2协议进行用户身份认证，所有接口请求均需携带认证信息。
19.一种银行应用安全控制的实现系统，其特征在于，采用了所述的银行应用安全控制的实现方法实现增强安全控制。
20.一种计算机可读存储介质，其特征在于，可读存储介质存储有计算机程序，所述计算机程序当被处理器执行时使所述处理器执行所述的银行应用安全控制的实现方法。
21.实施本发明具有如下有益效果：通过改变oauth2.0的令牌授权流程中增加身份认证要求和对交易流程数据进行加解密的改进提高银行系统数据的安全性；并且只需要通过改变交易网关即可实现，使得方案易于实施。
附图说明
22.图1是网关逻辑架构图；
23.图2是预约取证数据流程图；
24.图3是获取密钥流程图。
具体实施方式
25.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他
实施例，都属于本发明保护的范围。
26.spring cloud是一系列框架的有序集合。它利用spring boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用spring boot的开发风格做到一键启动和部署。
27.本发明主要针对的是解决交易流程中可能存在客户越权访问数据或数据被截留或仿冒的安全问题提出了基于springcloud的综合网关模块的改进，由综合网关模块执行对交易的检查，统一检查报文的安全性，包括xss(cross site scripting)跨站脚本攻击检查，sql脚本注入检查、交易重放机制检查等。还包括流量控制、熔断、服务路由、负载均衡等。
28.第一个改进在于改变oauth2.0中获取令牌的流程，原有的oauth2.0的四种获取令牌的授权，都没有绑定客户信息的机制；容易造成后台服务的漏洞，比如水平越权问题，如有的oauth2.0授权机制都是无状态的机制，客户端和服务端都无会话session的保存，客户端通过自己的令牌通过修改接口参数查询出非本客户端的信息，造成信息数据的泄露。因此增加要求牌绑定了客户信息，后台在令牌授权时先要求进行客户信息的认证，授权只能查询本客户的相关信息。
29.第二个改进在于通过国密算法对客户端对报文进行加解密。目前互联网存在这种直接将报文截获后，原封不动的重发相应报文，从来获取相关的数据信息。除开使用https协议在传输过程中对整个传输数据进行数据加密。还在客户端将整个交易报文使用国密算法sm4进行对称加密：
30.图3是获取密钥流程图，具体秘钥传输过程如下：
31.服务器在客户端获取oauth2.0的过程中，服务器产生一对sm2的公私钥，将公钥返回给客户端，客户端收到公钥后将公钥存储在本站路径下，不能进行跨站使用。
32.客户端收到令牌和公钥后，用令牌和公钥进行一次算法，产生一个sm4的密钥，并用sm2返回的公钥进行sm2算法的加密。
33.服务端用sm2的私钥进行解密，并且刷新令牌的客户信息数据内容，将sm4私钥进行关联。
34.客户端和服务端使用sm4密钥进行数据加解密。
35.第三个改进在于将加解密的操作设置在网关路由上实现，也就是综合网关模块来实现。并且通过编写公共模块来实现数据加解密，由于数据报文进行加密处理。为了尽量减少每个业务模块都产生相同的加解密的处理。在网关进行了数据处理，在交易在网关路由到业务系统之前进行数据包的解密，在交易返回客户端之前进行数据包的加密。图1是网关逻辑架构图；网关gateway实现流量控制、负载均衡、加密解码和服务路由，具体支持认证授权服务、短信服务、预约服务等其它服务提供方系统。
36.下面结合附图进一步详细描述本发明方案的技术方案，但本发明的保护范围不局限于以下所述。以银行多端预约区号系统为例进行说明。
37.系统实际包括客户端也可以叫消费端和服务端，消费端和服务端之间还设有网关设备。图2是预约取证数据流程图；基于改进后具体操作始练如下：
38.1：户多端预约取号模块：该模块面向客户，客户根据不同访问渠道进行预约取号，可以从掌上银行，小程序，公众号和h5链接访问预约取号界面进行取号预约，以小程序预约
取号为例，伪代码示意如下：
39.①
客户通过扫码进入预约小程序后，向服务端进行一次获取令牌请求，授权服务端返回令牌以及sm2公钥信息。
40.②
客户输入手机号码后，点击获取短信验证码。{
41.a.将客户手机号、令牌、用公钥加密的sm4密钥将交易传送网关服务端，授权服务端返回成功信息。
42.b.使用sm4加密发送“获取短信验证码”报文，网关在进行路由至短信服务端将报文解密成明文。
43.}
44.③
客户进行预约取号服务，此间交易报文都是进行sm4加密，通过网关服务进行解密路由。
45.④
客户进行预约取号日期时间的修改，此时获取到的令牌已经和手机号码进行绑定，只能获取本手机号码的预约信息，并且只能修改本手机号码预约信息。
46.2、短信验证模块：短信验证码进行客户手机号及接口校验，规定客户获取验证码后，60秒内可重新获取，防止多次请求后台接口，造成短信轰炸，且验证码有效时间长于60秒。
47.3、授权认证服务模块：通过oauth2协议进行用户身份认证，所有接口请求均需携带认证信息，在没有认证的情况下不能访问预约取号任意页面，认证服务模块为预约取号提供安全保障，防止web攻击。
48.综上所述，上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。