业务API脱敏的思考

2019-12-11  本文已影响0人  赤子心_d709

背景

api某些字段属于敏感信息,原本在api层返回,现在禁止返回
比如银行卡账号,性别等等
现有架构API+RPC,数据存储redis+DB
暂且不谈db是否脱敏(加解密等),在API层是直接返回敏感信息的
如何方便的API层禁止这一个字段的返回

前提,客户端不强依赖特定字段

场景说明

假设有下面的用户类型,含id,姓名,性别信息,其中性别属于敏感信息

type User struct{
 id int64
 name string
 sex string
}

现在有客户端请求用户信息,客户端只用到了name,根本不用sex,那么这时候就需要脱敏了

方案

前提

1.客户端不强依赖敏感信息字段
比如不给sex信息客户端也能work,不会crash

2.既然是有RPC接口,肯定有类似thrift的定义,各个接口的返回参数,也会定义optional,required

方案1

依赖于rpc的实现,即类thrift接口定义文件都定义UserDto中的Sex字段是optional的,那么rpc server端不返回即可,上游可以接受默认nil

方案2

定义出original response和new response,比如

message user_response{
    required int32 status_code = 1;
    required int64 id = 1
    required string name=2
    required string sex=3
}

message user_new_response{
    required int32 status_code = 1;
    required int64 id = 1
    required string name=2
}

原resp为user_response,新resp为user_new_response
那么吐出api的的时候走一层middleware,将原本的resp通过序列化,json marshell和unmarshell转化成user_new_response,这样端上就不会受到sex的返回了

比较

优点 缺点
方案1 干净,省带宽 强依赖接口定义,如果有一个接口没有写optional,那这个方案就很难执行
方案2 方便,加middleware,不用管rpc各层变更 浪费带宽,序列化等操作耗时

思考

如果历史客户端强依赖某个敏感字段,怎么办?
那么客户端改掉不要依赖,新版执行即可

怎么对老版本客户端返回老resp,新版客户端给新resp?
服务端根据客户端请求的版本号控制就好了

refer

下面写的比较丰富,我的场景其实只是简单的一步
https://www.jianshu.com/p/ee6500509c00
https://www.jianshu.com/p/2e69ff5bb3cc
https://my.oschina.net/u/3867294/blog/3089014

上一篇 下一篇

猜你喜欢

热点阅读