RPC 实战与核心原理
何小锋
京东云混合云首席架构师
40244 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 29 讲
RPC 实战与核心原理
15
15
1.0x
00:00/00:00
登录|注册

18 | 安全体系:如何建立可靠的安全体系?

注册中心的验证
接口与应用绑定
优化方案
验证调用方身份
授权平台
安全问题在RPC中的关注点
安全问题的范围
课后思考
总结
服务发现也有安全问题?
调用方之间的安全保证
为什么需要考虑安全问题?
安全体系:如何建立可靠的安全体系?

该思维导图由 AI 生成,仅供参考

你好,我是何小锋。上一讲我们学习了在 RPC 里面该如何提升单机资源的利用率,你要记住的关键点就一个,那就是“异步化”。调用方利用异步化机制实现并行调用多个服务,以缩短整个调用时间;而服务提供方则可以利用异步化把业务逻辑放到自定义线程池里面去执行,以提升单机的 OPS。
回顾完上一讲的重点,我们就切入今天的主题,一起来看看 RPC 里面的安全问题。

为什么需要考虑安全问题?

说起安全问题,你可能会想到像 SQL 注入、XSS 攻击等恶意攻击行为,还有就是相对更广义的安全,像网络安全、信息安全等,那在 RPC 里面我们说的安全一般指什么呢?
我们知道 RPC 是解决应用间互相通信的框架,而应用之间的远程调用过程一般不会暴露在公网,换句话讲就是说 RPC 一般用于解决内部应用之间的通信,而这个“内部”是指应用都部署在同一个大局域网内。相对于公网环境,局域网的隔离性更好,也就相对更安全,所以在 RPC 里面我们很少考虑像数据包篡改、请求伪造等恶意行为。
那在 RPC 里面我们应该关心什么样的安全问题呢?要搞清楚这个问题,我们可以先看一个完整的 RPC 应用流程。
我们一般是先由服务提供方定义好一个接口,并把这个接口的 Jar 包发布到私服上去,然后在项目中去实现这个接口,最后通过 RPC 提供的 API 把这个接口和其对应的实现类完成对外暴露,如果是 Spring 应用的话直接定义成一个 Bean 就好了。到这儿,服务提供方就完成了一个接口的对外发布了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

RPC系统的安全性对于系统的稳定运行至关重要。本文首先介绍了RPC系统中存在的安全问题,指出了服务提供方无法判断请求来源的难题。随后提出了解决方案,即为每个调用方设定唯一身份,并在服务提供方进行登记和审批。文章还讨论了授权平台的设计和优化,提出了将认证过程放到服务提供方进行,使用不可逆加密算法进行身份验证。这种设计不仅解决了安全问题,还能减轻授权平台的压力,提高系统的可用性。此外,文章还探讨了服务发现中可能存在的安全问题,并提出了将接口与应用绑定的解决方案,以避免伪造的服务提供者对外提供错误服务。总之,本文深入浅出地为读者提供了建立可靠安全体系的技术思路和解决方案,强调了在日常编码过程中保持严谨态度的重要性,以防止细小错误引入线上安全问题。RPC系统的安全问题虽然不如公网应用那么复杂,但仍需建立可控的安全体系,以确保服务调用方能拿到真实的服务提供方IP地址集合,并且服务提供方可以管控调用自己的应用。文章还提出了对于权限问题的思考,并鼓励读者分享解决方案。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《RPC 实战与核心原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(16)

  • 最新
  • 精选
  • 陈国林
    可以从鉴权和授权2个方面来看(参考k8s) 1. 鉴权可以用 token 的方式,token鉴权应该是目前用的最多的一种认证方式 2. 授权可以用 RBAC 方式,类似k8s里面的 serviceAccount 和 role 和 roleBinding 等等

    作者回复: 是的,认证和授权一般都是同时使用

    2020-04-05
    11
  • JDY
    我突然觉得,rpc这东西好像跟k8s有点像,k8s是类似把一个大服务拆分成很多模块,完了之后来把这些微服务管理起来,而rpc是提供了一系列接口,通过网络的方式,让各个调用方去调用。不知道能不能这样比较,求老师指点。

    作者回复: k8s可以看做rpc升级版本,后面我会讲到的

    2020-04-15
    10
  • 简单总结一下。服务端提供的安全校验方式。 1.md5摘要校验(安全级别较低,服务端直接提供或者网关代劳) 2.非对称加密算法就行签名(RSA和老师提到的HMAC等算法,服务端直接提供或者网关代劳) 3.Oauth2授权(有单独的授权服务,四种模式任君选择)

    作者回复: 👍

    2020-04-28
    6
  • 陈国林
    老师,你在上文提到的HMAC来做认证,服务提供方是使用 “公钥” 验证服务调用方的签名串吗?那如果是这样的话,是要事先生成公私钥对吧

    作者回复: 是的

    2020-04-05
    5
  • Darren
    我们之前是用的配置中心来存储对应的关系,B服务可以被那些服务调用或者不可以被那些服务调用,同时,也有B服务的接口权限,然后内部网关同步相关信息,保存到内存缓存中,当调用方请求经过网管时,获取调用方,服务方,服务方具体的接口,然后去校验相关的信息,判断是否可以放行,我们的鉴权没有放在服务方本身去实现,是在网关实现的,请老师指点

    作者回复: 前提就是怎么识别调用方的身份,比如应用id

    2020-04-01
    2
    4
  • 百威
    这种授权方式,对于调用方而言,加密后的签名怎么维护呢,感觉有代码侵入呀

    作者回复: 统一授权平台上获取

    2020-04-03
    3
  • 波波
    老师,RPC可以用于公网通信吗?鉴权放在服务端对服务端的压力是不是也挺大的?

    作者回复: 公网一般比较少,鉴权只要一次开销,压力还是可控的

    2020-04-20
    2
  • Raymond
    老师,请问服务提供方对服务调用方的授权认证后,已认证的状态应该存在服务提供端本地吧,那服务端集群中各个节点之间怎么共享同一个服务调用方应用的认证状态呢?还是说每次调用到不同的的服务提供方节点都需要从新进行鉴权?或者说是服务调用方在获取到服务提供方的IP列表后统一进行一次遍历的授权认证?请老师帮助解惑。

    作者回复: 每个节点都得鉴权一次

    2020-05-08
    1
  • 雨霖铃声声慢
    首先肯定是在服务端做,其次是应该在每一个服务提供端对其接口做权限审核,假如一个服务端提供10个接口出来,5个可以被A调用,另外5个不能被A服务调用,那么就应该有个配置文件配置这调用端和服务端各个接口的权限配置信息,这个权限配置应该放在配置中心,然后每个服务端会动态获取配置信息根据配置信息来决定是否拒绝服务。对于新增的调用服务,它需要先申请权限,然后服务端提供方修改配置文件对其提供服务。

    作者回复: 这也是一种思路

    2020-04-02
    1
  • 2102
    权限控制应放在服务提供方,权限控制规则可以放到单独管理节点,服务启动的时候从管理节点获取规则,权限规则变更后下发到服务节点。

    作者回复: 这有一个前提就是统一调用方身份的问题,规则里面是按照什么对象来识别身份

    2020-04-01
    1
收起评论
显示
设置
留言
16
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部