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 到了多少？
寄语写最后：技不压身，学比不学强，养成学习的习惯，请不要站在原地。
画图不易，码出你们能一看就懂的文章更不易。如果你们感觉稍微有点意思，欢迎关注“一猿小讲”微信公众号，或多多分享转发给你们的朋友就很感激。
