*intranet* REST API 调用应该如何保护？答案

【问题标题】：How should *intranet* REST API calls be secured?*intranet* REST API 调用应该如何保护？
【发布时间】：2013-09-11 19:28:20
【问题描述】：

这是场景。防火墙外的用户在浏览器中执行 UI 操作。浏览器对系统 A 进行 REST API 调用（并在通过防火墙的入口点或附近进行身份验证和授权）。系统 A（在公司网络防火墙内）对系统 B（也在公司网络防火墙内）进行 REST API 调用。

考虑到系统 A 的入口点已经进行了身份验证和授权，对于从系统 A 到系统 B 的“内部”REST API 调用来说，多少安全性才足够？

【问题讨论】：

您只是在询问如何对 REST 调用进行身份验证？
“保护”是指“验证凭据/知道用户是谁并确定授权”，还是指“保护它免受嗅探器攻击，以便人们无法读取传输中的数据” ? （或完全不同的东西）
@user2246674 - “最佳实践”仅表示 established best practices - 这不是最好的，因为“谁是最好的足球队”（这将是一个相对/意见/基于术语）它是“最佳实践”如“OWASP 推荐的身份验证最佳实践是什么。（不是相对的，不是基于意见的，而是已建立和商定的）
这个问题太宽泛了，你没有提到 A 和 B 之间的“安全”要求与“外部世界”发出的请求有什么不同
@Taylor 我的查询特定于 Intranet 上下文。因此，可能会使用各种方法来保护对系统 A 的初始调用。但是，如果有的话，我们应该使用什么方法来保护从系统 A 到系统 B 的调用。既然是内部调用，那么多少安全性就足够了?

【解决方案1】：

与其他任何事情一样，这取决于所涉及数据的敏感性，以及风险级别与组织想要花费的金额。

通常，使用强 SSL（https 连接）就足够了。如果您需要审核哪个System A 提交了请求，您可能需要包含身份验证机制——为此，您可以使用以下任何一种：客户端证书、HTTP Auth（基本或摘要）、用户名/密码作为请求参数、IP -地址映射、API 密钥等

对于系统->系统调用，如果客户端系统没有改变（即不是网络浏览器或主动改变客户端），你甚至不需要“真正的”证书——一个强大的自签名证书就足够了，并且因为您将其分发到您的客户端系统，所以他们都知道源代码在没有第三方签名的情况下是有效的。

如果数据非常敏感，您可以在客户端和服务器之间建立专用连接，或者使用物理分离的网络或 VPN。

【讨论】：

感谢您的回复。我对这些选项有些熟悉。 IP 地址映射听起来是最简单的。我相信这就像让系统 B 维护一组允许调用它的 IP 地址并根据该列表验证每个传入呼叫的 IP 地址一样简单。有没有更结构化或标准的方法来做到这一点？这种方法的缺点是什么？我认为让系统 B 维护主机名而不是 IP 地址并进行反向 DNS 查找可以防止系统 A 的 IP 地址更改。想法？
思考：反向 DNS 不可靠——管理 DNS 条目比 IP 地址分配问题更多。如果您需要考虑可能通过单个服务器（即 Web 浏览器 -> 客户端服务器 -> 服务）访问服务的不同客户，IP 映射可能会成为问题
澄清：系统B不需要知道最终用户的IP地址。系统 B 只需验证请求是否来自系统 A（代表最终用户）。
IP 白名单在这种情况下很常见，如果系统 A 有一个静态 IP。
“IP 白名单”的一个缺点是，如果请求通过中介（负载均衡器、代理服务器）到达系统 B，使用 request.getRemoteAddr() 可能很难获取源 IP 地址等），在这种情况下我们可以尝试 request.getHeader("X-FORWARDED-FOR")。

【解决方案2】：

新的（2018 年+）最佳做法是以与保护外部服务完全相同的方式保护内部服务。

为什么？

因为超过 60% 的数据披露来自内部来源。内部系统与外部系统一样可能会破坏数据，因此您需要拥有与外部系统相同的控制措施。

【讨论】：

【解决方案3】：

对于初学者来说，如果两者都在私有子网中，那么这已经是相当大的安全性了。如果您有任何理由相信外部人员可以连接到该 API，那么请继续实施一个安全的 API 密钥，在允许执行任何调用之前对其进行检查。

【讨论】：

感谢您的回复。子网的想法很有趣，但我认为（作为一个缺点）它在内部人员未经授权的访问方面留下了空白。关于 API 密钥，正如下面的介绍所指出的，这种方法显然没有标准化。 slideshare.net/jfaustin/securing-your-api 到目前为止，我赞成 (a) IP 地址映射（简单，但脆弱）或 (b) 基于 SSL 证书的握手，以允许系统 A 向系统 B 标识自己（更难，但标准化和健壮）。
这些都不是特别优雅。你真的应该只在你的 API 中添加凭据身份验证......即，为了使用 API，让消费者首先调用一个身份验证端点，该端点将验证他们的凭据（证明他们应该被允许使用它），它返回一个临时密钥，那么所有后续调用都必须提供该密钥，否则就会死掉。