从系统架构分析安全问题及应对措施

标签: 系统架构 分析 安全 | 发表时间:2023-03-04 13:58 | 作者:京东云开发者
出处:https://juejin.cn/tag/%E6%9E%B6%E6%9E%84

作者:京东物流 廖宗雄

在日常生产生活中,我们常说,“安全第一”、“安全无小事”。围绕着安全问题,在各行各业都有对各类常见安全问题的解决方案和突发安全问题的应急预案。在互联网、软件开发领域,我们日常工作中对各类常见的安全问题又有哪些常见的解决方案呢?在此,结合经典架构图做一个梳理。

经典架构图

下面,结合上述的经典架构图,对数据存储、微服务接口、外网数据传输及APP层可能出现的安全问题进行分析,并给出一些常见的应对措施。

1 数据存储

为了保证数据存储的安全,对于敏感数据在进行存储时,需要进行加密存储,同时,敏感数据建议在全公司进行收口管理,便于统一管理。对敏感数据进行加密存储时,常见的加密方式有可逆加密和不可逆加密,分别适用于不同的敏感数据。

1.1 可逆加密或对称加密

可逆加密,即通过对密文进行解密后,能把密文解密还原出明文。对称加密算法加密和解密用到的密钥是相同的,这种加密方式加密速度非常快,适合经常发送数据的场合,缺点是密钥的传输比较麻烦。比如:网络购物的收货地址、姓名、手机号等就适合用该加密方式,常用的对称加密算法有DES、AES,下面以AES为例说明对称加密的过程。

在该加解密中,对于秘钥K的生成需要加解密双方共同制定并妥善保管。通常,我们会把该秘钥K存储在需要使用加解密程序的进程内,便于在程序使用时直接进行使用。

1.2 不可逆加密

不可逆加密,即不需要解密出明文,如:用户的密码。不可逆加密常用的算法有RES、MD5等,在此以MD5为例进行说明。但大家都知道,MD5算法是存在碰撞的,即不同的明文通过MD5加密后,存在相同的密文。因此,直接使用MD5对密码进行加密在生产上是不严谨的,通常还需要配合盐(salt)进行使用。对于盐的使用,也有一定的技巧,一种盐值是固定的,即所有的明文在进行加密时都使用相同的盐进行加密;另一种是结合具体的业务场景,用可变盐值,比如:就密码加密而言,可以把用户名的部分或全部作为盐值,和密码进行一起加密后存储。

2 微服务接口

微服务的安全,需要从请求鉴权和请求容量限制这2个方面来考虑。对于请求鉴权,可以设置请求IP黑名单的方式,对该IP的所有请求或全部放行或全部拒绝,该方式的粒度较粗。而如果要做得较细粒度一些,可以针对具体的API进行token鉴权,相比粗粒度该方式会控制得比较精准;

  <jsf:consumer id="setmentService" interface="com.jd.lfsp.jsf.service.SetmentService"
                  protocol="jsf" alias="${jsf.consumer.alias}" timeout="${jsf.consumer.timeout}" retries="0">
        <jsf:parameter key="token" value="${jsf.consumer.token}" hide="true" />
</jsf:consumer>

除了对请求鉴权外,在实际的生产中,还可以对请求容量进行限制,对请求容量进行限制时,可以按QPS进行限制,也可以对每天的最大请求次数进行限制。在jsf平台管理端,可以对具体的方法进行请求的QPS限流。

3 数据传输

数据传输主要分为数据通过前端APP的请求,进入到服务网关前和进入服务网关后这俩部分,对于数据已经进入服务网关后,这属于机房内的数据传输,通常这类加密意义不大,对这类的数据传输的安全需要建立相应的内部安全机制及流程规范,通过制度措施来保证。而数据在进入服务网关前,对数据的安全传输有哪些可做的。在数据请求进入服务网关前,通常我们有基于SSL协议的传输加密以及现在普遍通用的HTTPS加密。

HTTPS也是HTTP和SSL协议的结合体,所以在数据传输中,SSL协议扮演了至关重要的角色。那SSL协议的工作过程是怎么样的,他是怎么保证数据传输过程中的安全的呢?下面为大家解析一下SSL协议的工作过程。

SSL客户端与SSL服务端验证的过程如下:

  1. SSL客户端向SSL服务端发送随机消息ClientHello的同时把自己支持的SSL版本、加密算法、秘钥交换算法、MAC算法等信息一并发送;
  2. SSL服务端收到SSL客户端的请求后,确定本次通信采用的SSL版本及加密组件和MAC算法,并通过ServerHello发送给SSL客户端;
  3. SSL服务端将携带自己公钥信息的数字证书通过Certificate发送给SSL客户端;
  4. SSL服务端通过ServerHelloDone消息通知SSL客户端版本和加密组件协商结束,开始进行秘钥交换;
  5. SSL客户端验证SSL服务端发送的证书合法后,利用证书中的公钥加密随机数生成ClientKeyExchange发送给SSL服务端;
  6. SSL客户端发送ChangeCipherSpec消息,通知SSL服务端后续将用协商好的秘钥及加密组件和MAC值;
  7. SSL客户端计算已交互的握手消息的hash值,利用协商好的秘钥和加密组件加密hash值,并通过Finished消息发送给SSL服务端,SSL服务端用相同的方法计算已交互的hash值,并与Finished消息进行对比,二者相同且MAC值相同,则秘钥和加密组件协商成功;
  8. 同样地,SSL服务端也通过ChangeCipherSpec消息通知客户端后续报文将采用协商好的秘钥及加密组件和MAC算法;
  9. SSL服务端端计算已交互的握手消息的hash值,利用协商好的秘钥和加密组件加密hash值,并通过Finished消息发送给SSL客户,SSL客户端用相同的方法计算已交互的hash值,并与Finished消息进行对比,二者相同且MAC值相同,则秘钥和加密组件协商成功;

通过上面的这个交互过程,我们可以看出,在使用SSL的过程中,除了客户端(浏览器)跟服务器之间的通讯外,其他的任何第三方想要获取到协商的秘钥是比较困难的。即使有比较厉害的人获取到了,基于目前用户在某个网站上的时效性,会影响我们对应秘钥的时效性,因此,造成的破坏性也比较有限。

4 APP

在APP层的安全问题,需要结合服务端一并来解决,在这主要介绍验证码这种形式。验证码作为一种人机识别手段,其主要作用是区分正常人操作还是机器的操作,拦截恶意行为。当前互联网中,大多数系统为了更好地提供服务,通常都需要用户进行注册。注册后,用户每次在使用系统时需要进行登录,登录过程中,为了防止系统非法使用,通常都需要用户进行登录操作,登录过程中,常用的验证方式主要通过验证码进行验证,当前比较常用的验证码有以下几种类型。

4.1 短信验证码

目前用得比较广泛的一种验证码形式,输入有效的手机号后,系统给手机号发送相应的短信验证码完成验证。

4.2 语音验证码

通过输入有效的手机号,系统给手机号拨打电话后,用语音播报的方式完成验证码的验证。

4.3 图片验证码

较传统的验证码验证方式,由系统给出验证码在页面显示,在进行页面提交时,验证码一并提交到系统后台验证。

4.4 语义验证码

比较新颖的一种验证码形式,但是该种方式相比较而言对用户不是特别友好,需要慎用。

除了上述的几种目前常用的验证码外,还有文本验证码、拼图验证码、问题类验证码等,在此就不再一一列举,大家如果感兴趣可以自己去搜索、学习。

这主要从系统的架构上,分析了日常工作中我们所接触到的比较常见的一些安全问题及其应对措施,在实际工作的安全问题远不止这里提到的内容。希望在日常工作中,我们大家都绷紧安全的神经,时刻关注自己工作中的各类潜在的安全问题,争取把安全问题消灭在系统发布前。

5 参考文献

SSL是如何加密传输的数据的:
[技术每日说] - SSL是如何加密传输的数据的!

名词解释:

  • SSL:(Secure Socket Layer,安全套接字层),位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性,从而实现客户端和服务器之间的安全通讯。该协议由两层组成:SSL记录协议和SSL握手协议。
  • HTTPS:(全称:Hypertext Transfer Protocol over Secure Socket Layer),是以安全为目标的HTTP通道,简单讲是HTTP的安全版(HTTP+SSL)。即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。

相关 [系统架构 分析 安全] 推荐:

从系统架构分析安全问题及应对措施

- - 掘金 架构
在日常生产生活中,我们常说,“安全第一”、“安全无小事”. 围绕着安全问题,在各行各业都有对各类常见安全问题的解决方案和突发安全问题的应急预案. 在互联网、软件开发领域,我们日常工作中对各类常见的安全问题又有哪些常见的解决方案呢. 在此,结合经典架构图做一个梳理. 下面,结合上述的经典架构图,对数据存储、微服务接口、外网数据传输及APP层可能出现的安全问题进行分析,并给出一些常见的应对措施.

Android 系统架构分析

- - CSDN博客移动开发推荐文章
Android:开源的 Linux + Google 的封闭软件 + 私有的基带 + 运营商锁定 = 开放的 Android 手机. iPhone:开源的 BSD + 苹果的闭源软件 + 私有的基带 + 运营商锁定 = 封闭的苹果 iPhone. 一个平庸的应用商店,开发者依靠广告赚钱,商店并非独此一家,用户找不到好软件.

twitter系统架构分析

- - 企业架构 - ITeye博客
twitter系统架构分析. (一)twitter的核心业务. twitter的核心业务,在于following和be followed:. (1)following-关注. 进入个人主页,会看到你follow的人发表的留言(不超过140个字),这是following的过程;. (2)followed-被关注.

数据分析平台系统架构

- - 企业架构 - ITeye博客
      大数据技术是近几年发展比较繁荣的技术方向,出了很多优秀的开源项目,也有越来越多的公司投入大量人力在其中. 认识到数据的重要性,数据分析平台系统也成为数据平台重点建设的项目,数据分析被广泛应用到电商、金融、教育、医疗领域. 开源的OLAP数据分析引擎:. 1.2 wedata系统架构图. 已有 0 人发表留言,猛击->> 这里<<-参与讨论.

解剖Twitter:Twitter系统架构设计分析

- flychen50 - 互联网的那点事
随着信息爆炸的加剧,微博客网站Twitter横空出世了. 用横空出世这个词来形容Twitter的成长,并不夸张. 从2006年5月Twitter上线,到2007年12月,一年半的时间里,Twitter用户数从0增长到6.6万. 又过了一年,2008年12月,Twitter的用户数达到5百万. Twitter网站的成功,先决条件是能够同时给千万用户提供服务,而且提供服务的速度要快.

高效稳定的大型网站系统架构分析(转)

- - 网站架构_搜搜博客搜索
  千万人同时访问的网站,一般是有很多个数据库同时工作,说明白一点就是数据库集群和并发控制,这样的网站实时性也是相对的. 这些网站都有一些共同的特点:数据量大,在线人数多,并发请求多,pageview高,响应速度快. 总结了一下各个大网站的架构,主要提高效率及稳定性的几个地方包括:.     程序开发是一方面,系统架构设计(硬件+网络+软件)是另一方面.

深入解析物联网操作系统(架构/功能/实例分析)

- - IT瘾-geek
1.       物联网的主要特点.                        i.             连接. 所谓连接,指的是各种各样的终端设备,都能够通过某种网络技术,连接到一个统一的网络上. 下一代的基础通信网络,包括未来的5G,通信网络架构重构等,为物联网提供泛连接网络是核心目标.

Uber 的实时数据分析系统架构 - 网站架构札记

- -
Uber 实时系统的 Use case:. 举一个更详细些的例子,UberEATS 是 Uber 的外卖服务. 实时系统也为这个功能估算送餐时间. 所有来自乘客和司机的事件 event ,由 Kafka 收集. Kafka 使用 Pub-sub 的订阅发布模式. Uber 整个系统中各个 microservice 之间的通信也通过了 Kafka.

HBase 系统架构

- - 博客园_首页
HBase是Apache Hadoop的数据库,能够对大型数据提供随机、实时的读写访问. HBase的目标是存储并处理大型的数据. HBase是一个开源的,分布式的,多版本的,面向列的存储模型. 5 可在廉价PC Server搭建大规模结构化存储集群. HBase是Google BigTable的开源实现,其相互对应如下:.

Facebook 的系统架构

- Ivan - 博客园新闻频道
  来源:http://www.quora.com/What-is-Facebooks-architecture (由Micha?l Figuière回答).   根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:. Web 前端是由 PHP 写的. Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能.