2台服务器之间的安全连接
Secure connection between 2 servers
我想要一些面向用户的服务器，比如服务器 A。对于某些任务，服务器 A 应该在服务器 B 上提交作业请求。当服务器 B 完成后，它应该将结果写入数据库或者可能使在服务器 A 上调用并让服务器 A 处理结果（现在不太确定这部分）。
问题是：
服务器A和服务器B如何安全连接？
- 在服务器 B 的端点上，我只想允许来自服务器 A 的调用。
- 在服务器 A 上，我希望某些端点仅可用于服务器 B（并且可能在某些时候某些其他工作机器服务器 C、D.. 等）。
我只是找不到合适的词 google 来形容这个。我想这有一些非常明显的流行语，但谷歌搜索“两台服务器之间的安全连接”并没有产生我正在寻找的东西。
我对这个的总称很感兴趣，但为了完整起见：
- 面向用户的服务器将使用 php
- 工作机器将是一些节点应用程序
我自己的想法（但我不知道如何准确地实现它）类似于我通过 ssh 连接到某个服务器时的情况，我只是将我的 pub-key 添加到服务器。所以它应该是这样的：将服务器 A 的公钥存储在服务器 B 上，反之亦然。然后确保只能对服务器 B 进行经过身份验证的调用。
一个完整的答案会很好，但实际上我已经很高兴得到一个关于我应该谷歌搜索的正确方向的指针或者关于 SO 的另一个问题。
您要查找的技术术语是“身份验证”，这是确定一方与其所说的身份相符的过程。密切相关的是“授权”，它是确定一方是否被允许做某事的过程。
对于这个问题，标准的身份验证技术适用，非常类似于用户的身份验证技术。生成一个长的随机身份验证令牌并将其存储在服务器 B 上。使用 HTTPS 从服务器 B 连接到服务器 A，并传递身份验证令牌。一种流行的方法是使用 Bearer Authentication。添加 header:
Authorization: Bearer {access_token}
在服务器 A 上，验证令牌并在授权后执行请求。
这只是实现 API 密钥的一种特定方式。您也可以将访问令牌（API 密钥）直接放入请求中。它会是相同的。
如果您有容器化或虚拟化设置，这些密钥通常存储在环境变量中。不建议直接存放在代码中（小错误太多导致代码可见）
做同样的事情有更复杂的方法，如果您已经有一个很好的用户身份验证系统，您也可以只为服务器 B 创建一个“服务帐户”并使用您的正常身份验证方案。但是不记名令牌是处理 machine-machine 身份验证而无需创建假帐户的一种很好、简单的方法。
请注意，所有方法都要求您能够保护服务器 B。任何可以访问服务器 B 的人都能够窃取令牌并冒充服务器。缓解这种情况通常需要专门的硬件（例如 HSM），并且超出了大多数系统的需要。
虽然有点复杂，但另一种常用技术是签署您的请求。签名的优点是您永远不必通过网络发送您的身份验证令牌（即使使用 HTTPS），并且您只需将私钥存储在一个地方（服务器 B）。这意味着即使是服务器 A 也不能像使用承载身份验证那样伪装成服务器 B。我经常为此使用 JWS（JSON Web 签名），但如果您没有一个好的库来处理它，它会相当复杂。没有 JWS 的签名很难正确，因为您必须非常小心地签署所有重要的东西，并且很容易忽略部分请求（例如 headers）。如果你走那条路，你可能需要安全专家来检查一下。
从 OAuth2 开始，正如 Mikah 指出的那样，但我通常不建议您控制一切并且实体不多的 point-to-point 身份验证。这只是很多复杂性而没有什么好处。 OAuth2 的要点是允许集中管理复杂的身份验证环境。如果您没有这些问题，复杂性往往会降低安全性，而不是提高安全性。
我想要一些面向用户的服务器，比如服务器 A。对于某些任务，服务器 A 应该在服务器 B 上提交作业请求。当服务器 B 完成后，它应该将结果写入数据库或者可能使在服务器 A 上调用并让服务器 A 处理结果（现在不太确定这部分）。
问题是： 服务器A和服务器B如何安全连接？
- 在服务器 B 的端点上，我只想允许来自服务器 A 的调用。
- 在服务器 A 上，我希望某些端点仅可用于服务器 B（并且可能在某些时候某些其他工作机器服务器 C、D.. 等）。
我只是找不到合适的词 google 来形容这个。我想这有一些非常明显的流行语，但谷歌搜索“两台服务器之间的安全连接”并没有产生我正在寻找的东西。
我对这个的总称很感兴趣，但为了完整起见：
- 面向用户的服务器将使用 php
- 工作机器将是一些节点应用程序
我自己的想法（但我不知道如何准确地实现它）类似于我通过 ssh 连接到某个服务器时的情况，我只是将我的 pub-key 添加到服务器。所以它应该是这样的：将服务器 A 的公钥存储在服务器 B 上，反之亦然。然后确保只能对服务器 B 进行经过身份验证的调用。
一个完整的答案会很好，但实际上我已经很高兴得到一个关于我应该谷歌搜索的正确方向的指针或者关于 SO 的另一个问题。
您要查找的技术术语是“身份验证”，这是确定一方与其所说的身份相符的过程。密切相关的是“授权”，它是确定一方是否被允许做某事的过程。
对于这个问题，标准的身份验证技术适用，非常类似于用户的身份验证技术。生成一个长的随机身份验证令牌并将其存储在服务器 B 上。使用 HTTPS 从服务器 B 连接到服务器 A，并传递身份验证令牌。一种流行的方法是使用 Bearer Authentication。添加 header:
Authorization: Bearer {access_token}
在服务器 A 上，验证令牌并在授权后执行请求。
这只是实现 API 密钥的一种特定方式。您也可以将访问令牌（API 密钥）直接放入请求中。它会是相同的。
如果您有容器化或虚拟化设置，这些密钥通常存储在环境变量中。不建议直接存放在代码中（小错误太多导致代码可见）
做同样的事情有更复杂的方法，如果您已经有一个很好的用户身份验证系统，您也可以只为服务器 B 创建一个“服务帐户”并使用您的正常身份验证方案。但是不记名令牌是处理 machine-machine 身份验证而无需创建假帐户的一种很好、简单的方法。
请注意，所有方法都要求您能够保护服务器 B。任何可以访问服务器 B 的人都能够窃取令牌并冒充服务器。缓解这种情况通常需要专门的硬件（例如 HSM），并且超出了大多数系统的需要。
虽然有点复杂，但另一种常用技术是签署您的请求。签名的优点是您永远不必通过网络发送您的身份验证令牌（即使使用 HTTPS），并且您只需将私钥存储在一个地方（服务器 B）。这意味着即使是服务器 A 也不能像使用承载身份验证那样伪装成服务器 B。我经常为此使用 JWS（JSON Web 签名），但如果您没有一个好的库来处理它，它会相当复杂。没有 JWS 的签名很难正确，因为您必须非常小心地签署所有重要的东西，并且很容易忽略部分请求（例如 headers）。如果你走那条路，你可能需要安全专家来检查一下。
从 OAuth2 开始，正如 Mikah 指出的那样，但我通常不建议您控制一切并且实体不多的 point-to-point 身份验证。这只是很多复杂性而没有什么好处。 OAuth2 的要点是允许集中管理复杂的身份验证环境。如果您没有这些问题，复杂性往往会降低安全性，而不是提高安全性。