软件架构与思考

👉 所有文章
高性能 高性能设计模式
数据库 数据库分库分表指南 MySQL 建表参考 MySQL 初始化数据的一些方案 数据版本号
分布式 ID 分布式 ID 生成方案探讨
缓存 缓存 使用数据版本号保证缓存是最新数据 基于redis的二级缓存
微服务 如何实现远程调用 RPC 协议中的数据签名验签和加解密方案探讨 关于服务间调用循环依赖的一些思考 我所理解的负载均衡 一致性哈希 基于Redis的分布式会话管理系统 如何部署服务 灰度发布 如何区分上游和下游 日志级别
算法与协议 一个可扩展的 MQ 消息设计 Dynamo涉及的算法和协议 写时复制
任务分发 Gearman入门 如何使用redis构建异步任务处理程序
安全 关于对账的一些理解 一个简单可靠的 Dubbo 请求/响应数据签名方案
其他 使用卫语句减少 if else 嵌套

RPC 协议中的数据签名验签和加解密方案探讨


(未完成)

本文讨论下,业务数据如何签名验签、加解密。

为什么要做这件事?

理想目标:防篡改,防抵赖,防窃听。

理想目标,可以有损实现。

要考虑的一些点:

  1. 对哪些字段签名?是部分字段还是所有字段?
  2. 对哪些字段加密?是各个字段单独加密,还是所有字段都加密?
  3. 如何保证业务开发友好?
  4. 调用方和服务方协议出现不一致(例如版本不一致导致的两边字段数量不一致),如何保证验签和解密无问题 ?
  5. 评估各种签名、加解密算法的安全级别和性能。
  6. 更新密钥时,要不要平滑过渡?
  7. 是基础组件做?还是业务层做?
  8. 响应数据是否做签名?防止服务方被劫持。
  9. 调用方要不要对响应做一些关键信息校验。如把一个随机字符串传到服务方,服务方原样返回。
  10. 要不要加上请求时间校验,请求数据加上时间戳。服务方只处理最近上下5分钟的请求。
  11. 数据加密是对称加密?还是非对称加密?
  12. 如果是非对称加密,是调用方生成公私钥,还是服务方生成?调用方生成,可以防抵赖,但破坏了调用方体验。
  13. 如果只做签名,是否对签名做非对称加密,以防抵赖?
  14. 各种方案的性能如何?开发是否友好?测试是否友好?

经典案例

微信支付的协议是一个经典的案例。

基于 Dubbo 的一个方案


( 本文完 )

文章目录