欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

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

程序员文章站 2022-03-10 18:05:08
01. 聊 啥 关注“一猿小讲”的都知道,我们之前分享过应用架构、应用监控、日志归集以及程序员日常内心的那些小揪揪,几乎成了小讲、杂谈的一亩三分地。 说实话,挺神奇,我也不知道每次会给大家带来什么惊喜。 今天的分享也不例外,你们肯定也意想不到,今天我分享的主题居然是:矛与盾,如何做好系统之盾;说人话 ......

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 到了多少?

 

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

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