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

01. 聊 啥

 

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

 

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

 

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

 

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

 

02. 聊 开

 

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

 

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

 

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

 

 

 

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

 

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

 

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

 

 

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

 

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

 

 

 

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

 

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

 

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

 

 

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

接入层，需要采用 rsa 解密报文加密的 aes key；	
业务系统，需要采用 rsa 解密报文中的敏感字段；

 

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

 

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

 

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

 

 

 

 

03. 聊毕

 

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

 

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

 

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