系统安全

author：肖博

createTime：2021-1-15

updateTime: 2022-08-18

培训结束时间：2022-08-18

1.1 计算机信息系统安全主要包括

1、实体安全

2、运行安全

3、信息安全

4、安全管理

其中安全管理是基础，如果没有严格的安全制度作保障，其他所有的安全措施都是无用的。

1.2 安全守则

1、假设已经被入侵

2、数据泄露零容忍

3、不依赖IOC（传统入侵指标）

4、自动化才能更轻松

5、淘汰与更新

6、了解攻击模型和框架

这里主要关注运行安全和信息安全，1和4不在能力范围之内。

运行安全和信息安全听起来太广泛，所以以后的整理都以一个一个专题来阐述。

1.3 第一个专题api安全

接口一般要具备三个特征：安全、真实、完整

经常遇到的问题有三个：抓包窃取、掉包篡改、爬取泄露

所有的安全措施都需要根据自己的业务需要去制定，不需要高深的理论和优雅的措辞，下面以我们现有的系统P031做风险分析：

1.3.1 登录安全

现状：

目前接口请求参数和响应数据都可以生成成密文

问题：

用抓包工具抓取的信息都是密文的，也不太容易去破解成明文，但是获取的密文就用密文去请求登录接口，登录成功后，其他的所有接口都是开放的，可以用抓取到的信息去操作所有接口。

解决：

为了更加安全，选择对登录请求参数非对称加密，多加一个时间戳作为请求参数，后台利用超时机制判断请求参数是否过期，比如超时时间定为60s，则抓包的信息有效期在60s之内，基本能解决问题，如果要求严格，可以再增加一个随机数参数，或者直接用加密后的数据也可以，每次请求都是唯一的，后端判断唯一性就能基本解决问题。

注意：用户名、密码，特别是密码存库一定加密处理，例如像我们用md5，加盐加密，2011年csdn用户名密码明文，受到黑客攻击后暴露了600万用户信息。

1.3.2 接口篡改

现状：

目前接口请求参数和响应数据的对称加密

问题：

目前接口基本解决了掉包篡改的问题，符合我们的要求，但是消耗性能和没有验证身份作用。

解决：

百度百科https中说明:HTTPS 协议会使页面的加载时间延长近 50%，增加 10%到 20%的耗电,而https 传输数据正是用的对称加密，间接说明了对称加密消耗性能，一些互联网大厂用的签名的做法，比如md5签名,使用签名还有一个作用就是验证身份的作用，过滤无效请求。当然一些敏感接口或者特殊接口，还是需要用非对称加密保证安全，如果登录，毕竟非对称加密安全性还是有保证的，量子计算机要几十年才能破解。下面是效率测试对比数据：都执行1000次

（1）不执行任何代码，只是打印耗时：40ms

（2）MD5 ：70ms

（3）对称加密AES ：350ms

（4）非对称加密 RSA ：1000ms

1.3.3 接口重放

所有接口都可以参照登录安全中解决抓到的包不能去正常访问接口。

1.3.4 接口幂等

现状：

P031没有涉及，P033可能会有

问题：

比如2014年，京东，订单服务和发货服务，用户下发一个订单，订单成功，订单服务远程调用发货服务的发货接口，由于发货接口不具备幂等性，在网络波动等的情况下，可能重复调用多次发货接口，就导致用户下了一个订单，收到多件货物的情况。

解决：

敏感接口，一定要保证接口幂等性的要求。方法很简单，可以用数据库唯一建控制或者数据库字段状态控制或者代码逻辑控制。

1.3.5 dos攻击

现状：

没有做处理

问题：

一般来说dos攻击是和网络层相关，但是如果P031接口也遇到这种攻击，服务将会因资源耗尽而不能对外提供服务

解决：

可以收集用户的ip或者用户的session来控制一段时间内某一ip或某一用户访问接口的频率；或者通过后台统计，发现异常，设置黑名单。

1.3.6 开放接口

以P010为例，对上层app提供一些下发计划，查询计划执行信息等接口，如果不做接口的一些控制，比如限流、限量等限制，如果受到攻击，或者只是一个接口的调用，比如查询任务执行详情，pagesize=1000000，jvm都有可能oom。开放接口因为要是给别人使用的，安全等级要高一些，顶得住第三方的随意调用，对于一些核心服务能不提供接口尽量不提供，不能因为某一个接口的异常影响整个服务的正常运行。

总结：

api安全措施：

1、使用https

2、接口做权限控制

3、登录页面使用验证码

4、接口密文传输，用户密码密文存储

5、接口防重放

6、接口限流，保证整个服务的安全

7、敏感接口要求幂等性

8、第三方接口特殊处理

9、接口异常自动化告警

10、制定紧急处理方案

11、对于恶意攻击，了解攻击框架，做到知己知彼

12、制定安全管理制度

结语：

所有的安全措施都用上的话有时候难免太过复杂，在实际项目中需要根据自身情况作出取舍，比如可以只使用签名机制就可以保证信息不会被篡改，或者定向提供服务的时候只用认证机制就可以了，如何取舍，全看项目实际情况和对接口安全性的要求，最重要的一条就是安全管理，人为的安全事故，系统安全做的再可靠也无能为力，只能做到后期弥补处理。