RPC 的安全性

最初的 RPC 实施是为隔离的 LAN 网络开发的，并不十分注重安全性。从恶意注册表到恶意服务器，再到针对拒绝服务的客户端到客户端与服务器之间的中间人攻击，该模型中存在着许多能够被攻击、渗透的安全薄弱点。随着时间的推移和互联网的发展，出现了新的标准，并且 RPC 实施变得更加安全。在 RPC 中，安全性通常作为模块或软件包添加。这些模块具有用于认证和授权通信服务（主叫方和被叫方）的库。这些模块并非始终没有错误，并且可能会获得未经授权的系统访问权限。总体而言，安全性正在努力纠正这种情况，使用代码检查和漏洞赏金程序来预先捕获这些错误。但是，随着时间的流逝，会出现新的错误，并且此循环继续进行。这是攻击者和安全专家之间的恶性循环，他们两者都试图超越对手。

例如，Oracle 网络文件系统使用安全 RPC（Oracle，n.d。）在 NFS 中执行身份验证。该安全 RPC 使用具有 DES 加密功能的 Diffie-Hellman 身份验证机制，仅允许授权用户访问 NFS。同样，Cap’n Proto（Kenton，n.d.）声称它可以抵抗内存泄漏，段错误和恶意输入，并且可以在互不信任的各方之间使用。但是，在 Cap’n Proto 中，“ RPC 层无法抵抗资源耗尽攻击，可能允许拒绝服务”，也没有经过任何正式的验证（Kenton，n.d.）。

尽管有可能提出一个使 RPC 实现不安全使用的威胁模型，但必须理解使用任何分布式系统都会增加攻击面，并声称一种范例比另一种范例更安全。，因为范式通常是一个主意，并且依赖于不同的系统设计人员来使用这些范式来构建其系统并照顾特定于实际系统的功能，例如安全性和负载平衡。总是有可能将请求重新路由到恶意服务器（如果注册表被黑客入侵），或者调用者和被调用者之间不信任。但是，我们坚持认为 RPC 范式既不安全也不安全，并且最安全的系统是处于隔离环境中的系统，这些系统通过自毁机制与公共互联网断开连接（Sarma，Weis，（＆Engels，2002）。