安全架构模型应该怎么设计?

01. 聊 啥

 

关注“一猿小讲”的都知道,我们之前分享过应用架构、应用监控、日志归集以及程序员日常内心的那些小揪揪,几乎成了小讲、杂谈的一亩三分地。

 

说实话,挺神奇,我也不知道每次会给大家带来什么惊喜。

 

今天的分享也不例外,你们肯定也意想不到,今天我分享的主题居然是:矛与盾,如何做好系统之盾;说人话,也就是“聊聊安全架构模型”

 

吃个核桃,坐稳,扶好,我们开始。

 

02. 聊 开

 

一个应用架构的设计肯定离不了安全模块,离开了安全模块设计,相当于系统在裸奔,尤其是金融系统。

 

站在用户的角度。当我们打开 APP 时,点击购买按钮时,页面会提示购买成功 or 购买失败。站在用户的角度,功能体验就是这么简单。大道至简,简单就是美。

 

站在系统的角度。司空见惯,我们认为 APP 就是终端,当用户点击购买按钮时,会请求接入层(也认为是安全层),接入层会记录用户关键行为,然后转发业务报文请求业务系统进行业务处理。

 

 

640?wx_fmt=png

 

如上图所示,把系统划分为终端 APP、接入层、业务系统。生产上这么跑的肯定不在少数。

 

但是有没有考虑过,终端 APP 发过来的报文可信性是较低的,如果报文发生恶意篡改该怎么办?

 

我们会想到可以针对通讯报文采用 RSA 加密。但是如果只有报文的 RSA 加密,那么所有请求的加密规则都是一样的,所以考虑到双保险,那不妨每次请求的时候动态生成 AES Key,先把报文采用动态生成的 AES Key 进行 AES 加密,然后把 AES Key 采用 RSA 加密传输。此时的架构如下图所示。

 

安全架构模型应该怎么设计?_第1张图片

 

此时会存在一个问题,如果模拟发起报文的时候,敏感字段(手机号、姓名、身份证等)发生篡改,是不是会张冠李戴、不可思议?

 

考虑到前面的设计,那么不妨再针对敏感字段,再进行一道 RSA 加密。此时的架构设计确变成了如下(着重关注红色部分)。

 

 

安全架构模型应该怎么设计?_第2张图片

 

到此步,架构设计上肯定比裸奔的系统,安全性提高不少,攻击的门槛也提高了。

 

但是聪明的你们,有没有发现通讯证书、敏感字段证书(也就是 RSA 公钥)都是预置在 APP 服务中,那么是否可以设计出一个密钥管理的模块,这样可以针对证书提供拉取,也可以随时设置证书过期、下线等操作。

 

那么此时的架构设计变成了什么样子呢?(着重关注下图红色部分变化)。

 

安全架构模型应该怎么设计?_第3张图片

 

如果跟着我的思路,走到这一步的你们,肯定会发现如下两点:

接入层,需要采用 RSA 解密报文加密的 AES Key;	
业务系统,需要采用 RSA 解密报文中的敏感字段;

 

那么这样设计,会引起证书的私钥分散、且不容易管理。不过如上图所示,既然有了密钥管理的系统,那么不妨把解密的动作,都统一交给密钥管理系统。

 

这样一来,接入层、业务系统就无需关心密钥相关的事情,大概率的提高了系统之间的可信性。

 

那么此时的架构又变成了什么样子呢?(着重关注下图红色部分变化)。

 

 

安全架构模型应该怎么设计?_第4张图片

 

 

03. 聊毕

 

道高一尺魔高一丈,系统安全就像矛与盾,有矛就有盾,在铸造好盾的前提下,也提倡大家都做一个有职业操守的程序员。

 

结合个人的理解与实际应用,到这安全架构模型也聊个八九不离十啦,不知道聪明的你们 get 到了多少?

 

寄语写最后:技不压身,学比不学强,养成学习的习惯,请不要站在原地。

安全架构模型应该怎么设计?_第5张图片

 

 

你可能感兴趣的:(安全架构模型应该怎么设计?)