数据安全

1、数据安全

  • 数据传输安全
  • 多线程数据安全
  • 高并发下数据安全

 

2、数据传输安全

  2.1、数据加密

  数据加密一直是保密数据的重要部分,常见的加密算法有可逆加密算法和不可逆加密算法,可逆加密算法又分为对称加密算法和非对称加密算法。

比如一个系统的登陆操作,客户输入用户名登陆,如果不进行任何保障措施,用户名和密码明文传输,被不法分子截获数据后,显然是不安全的。如果我们这时对密码进行不可逆加密,如md5,对用户名进行可逆加密,如des,这时候在截获数据时,得到的将是一串密文,显然,即使要破解,也需要相当时间。

但这样,有一个明显问题,就是接口吞吐量下降,明显,加密情况下,由于需要解密数据,接口的响应速度会下降。

可能,对于一些非重要数据,我们这样牺牲系统性能换取来的安全可能有些过了。

 

  2.2 数据签名

  数据签名又是什么呢?它和数据加密的区别呢?

  数据签名,相当于对传输的数据,进行一些不可逆加密算法后,如md5,生成一段签名字符串sign。

  比如上述列子中,登陆操作中如果还要传输IP,地点等等数据,这些数据明显没那么重要,这时可以对全部传输数据进行签名,生成sign,将其传入后端,后端用同样算法及密钥计算比较sign,如果一致认为数据正确,直接拿到IP,地点等数据(不用解密,相对于解密各个信息,理论上所有信息计算签名要节省时间),不一致则认为被修改过,返回错误信息。

 

  2.3 session,token机制

  session(cookie)和token机制的出现是为了校验用户状态的。

  比如不法分子知道了我们的后台接口,恶意伪造大量数据攻击,即使这些数据不正确,而服务器每次都需要校验这些数据的正确性,显然带来大量性能消耗。

  我们当然可以进行一些优化操作,如对于同一个IP,短时间大量请求则封掉该IP一段时间,但这不是太合理的。

  设想,如果用户登陆后,保存状态,只有登陆的用户可以访问这些接口,每次请求到来,均先校验用户登陆状态,对于session,如果没有sessionid或者sessionid错误或者过期则直接返回登陆界面。对于token,与session同理,没有token或者token错误或者过期的直接返回登陆页面。

  这样,我们开始校验token或者session,就可以拒绝大量伪造请求。

 

   2.4 Https(数字证书机制)

  上面,无论数据加密还是签名,我们发现最重要的就是加密方法和加密密钥。

  对于两台服务器交互,可能不用太担心,但是如果是webapp或者原生app,不法分子反编译前端代码后,就有可能拿到加密方法和加密key,怎么办呢?

  这就属于Https要解决的事情,下篇文章会介绍https,这儿先简单说下:

  在加密算法中,有一种叫做非对称加密的算法,有公钥和私钥组成,他有个特点:公钥加密的数据,只有私钥能解密;私钥加密的数据,只有公钥能解密。

  https就是需要让客户端与服务器端安全地协商出一个对称加密算法。剩下的就是通信时双方使用这个对称加密算法进行加密解密。

  ①客户端启动,发送请求到服务端,服务端通过非对称加密算法(如RSA)生成公钥pubkey1和私钥prikey1。

  ②服务端将公钥pubkey1发给客户端,客户端用自己的非对称加密算法也生成一套公钥pubkey2和私钥prikey2,并将公钥pubkey2通过pubkey1加密后返回服务端。

  ③服务端用私钥prikey1解密后拿到pubkey2,并将确定好的未来交互的对称加密算法和密钥通过pubkey2加密,返回客户端。

  ④客户端用私钥pubkey2解密数据,拿到服务器给定的加密算法和密钥,双方开始用其数据通信。

  这样仍有一个问题,如何证明公钥pubkey1加密的这串数字是客户端来的,即证明他就是他。。。

  这就是https的数字证书,相当于网络中心的部分,证明他就是他。数字证书就是来干这个的。

 

3、多线程数据安全

  • 同步代码块、同步方法
  • Lock对象
  • 使用线程安全的容器
  •  使用队列,强行把多线程转为单线程,缺点消耗内存
  •  数据库乐观锁

4、高并发下数据安全

  • 流量优化:防盗链处理
  • 前端优化:减少HTTP请求,合并css或js,添加异步请求,启用浏览器缓存和文件压缩,CDN加速,建立独立图片服务器,
  • 服务端优化页面静态化,并发处理,队列处理
  • 数据库优化:数据库缓存,分库分表,分区操作,读写分离负载均衡、数据库乐观锁
  • web服务器优化负载均衡,nginx反向代理,7,4层LVS软件

 


 

转载出处

https://blog.csdn.net/JavaZWT/article/details/80953348 

posted @ 2019-07-25 11:38  啧啧啧花儿不谢呀!  阅读(205)  评论(0编辑  收藏  举报