【问题标题】:How to implement TLS between microservices如何在微服务之间实现 TLS
【发布时间】:2018-10-28 07:00:43
【问题描述】:

有人可以对我正在考虑的微服务安全设计中的微服务安全设计发表评论、审查、批评或其他漏洞吗?

假设我有三个微服务,每个微服务都通过 REST 端点与另外两个通信。每个微服务都包含一个密钥库。在此密钥库中是包含微服务的私钥/公钥对,由受信任的证书颁发机构签名。此密钥库中还有另外两个微服务的公钥证书,从源微服务的签名/可信密钥对导出。

这个实现是可行的,但它的味道不太对劲。

也就是说,每次我引入一个新的微服务时,我必须将 a) 每个现有微服务的公钥证书添加到其密钥库中,以及 b) 新微服务的公钥证书到每个其他微服务(假设新微服务必须与- 定向且安全地使用每个现有的微服务)。

现在,对第二个密钥对重复上述模式,这个密钥对用于签署/验证 REST 调用中提供的身份验证令牌。

我想知道,在所有微服务之间共享单个受信任的公钥证书是否 a) 可取和 b) 安全?完全不同的东西?

请保持礼貌。我绝不是这方面的专家。

编辑: 在阅读了对我原始帖子的回复/cmets 后,我突然想到,我省略了可能使问题更清楚的细节,因此评论者能够更好地解决它:

  1. 相关微服务存在于私有 Intranet 中,并且只能由该 Intranet 中的客户端(浏览器或其他微服务)访问。

  2. 实际上存在一个受信任的 CA(即拥有该 Intranet 的公司),并且正是该 CA 签署了微服务的密钥对。

@Andreas 的第一条评论似乎暗示了这个问题的解决方案,他在其中写道:“只要发布它们的 CA 是可信的,它们也将是可信的。”

只要每个新微服务都部署了 a) 自己的密钥对,由 CA 签名(一个用于签名,另一个用于加密),以及 b) CA 的证书,我就可以合理地保证它们会部署新的微服务与所有其他微服务安全通信(由于我什至不知道的其他潜在漏洞,这是合理的)。

不知何故,我想到我必须为每个微服务的密钥对创建一个全新的证书,并将这些证书包含在其他微服务的密钥库中(对每个新的微服务重复)。相反,我只需要一个证书,即签署密钥对的 CA 的证书,在每个微服务的密钥库中。

【问题讨论】:

  • 为什么需要添加每个服务的公共证书?只要颁发它们的 CA 是可信的,它们也将是可信的。这就是网络本身的运作方式,那为什么不适合你呢?
  • 感谢您使用了TLS,而不是大家误用的其他东西,但请将其从标签中删除。以及 java 和 tls1.2,因为您的问题并非特定于这些情况。
  • @Andreas 在您需要对客户端进行身份验证时效果不佳(对于服务器的身份验证很容易)。服务器需要事先对证书有所了解,或者使用私有 PKI,否则任何人都可以出示任何 CA 签署的任何证书。
  • 如果可以,请依靠基础架构来提供安全通信。例如,如果您使用 Docker Swarm,您可以为网络激活连接加密:docs.docker.com/network/overlay/…
  • @ConstantinGalbenu 加密不是相互认证

标签: ssl microservices pki


【解决方案1】:

一种方法(您的问题很广泛,如果没有代码,在 SoftwareEngineering 上可能比这里更热门)如下:

  1. 创建您自己的 CA
  2. (可选,仅为您的微服务创建子 CA)
  3. 由该 CA 生成所有证书
  4. 让您的代码信任来自该 CA 的所有证书,而不是检查证书本身(但您仍应检查日期、正确的签名等)

这样,当您引入一个新的微服务时,您只需为其生成一个证书,而其他微服务无需更改任何内容,这是您需要达到的目标,否则无法管理。

通过这样做,您甚至可以根据需要将一些微服务移出系统。它们只需要随 CA 公钥一起提供。

我建议不要为不同的微服务重复使用相同的证书,因为这只会导致问题。

此外,相关性松散,但请务必阅读以下内容: https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf 它显示了在网络之外使用 TLS 时的各种陷阱。这是一个大开眼界。虽然仅针对 TLS 而不是 PKI 问题,但此 Internet 草案 (https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/) 可以提供有关如何使用一些安全默认选项正确实施 TLS1.2 的有用见解。 “LTS”部分特指“长期支持”。

还请查看此相关问题:https://security.stackexchange.com/questions/175627/securing-internal-micro-services-letsencrypt-vs-self-signed-certificates-be 以及为您提供其他想法的答案,例如使用保险库。

【讨论】:

  • 哇,谢谢你的链接。迫不及待地想读它。我相信它会完全破坏我的方法。你一针见血:在网络之外使用 TLS 让我觉得有点莫名其妙。
【解决方案2】:

如果您的微服务未向网络公开,那么您可以为此创建自签名证书。自签名证书用于内部调用。您可以在 sslshopper 网站上创建它们。

另外,不要对所有微服务使用相同的证书。 我已经实现了类似的解决方案,在我们的例子中,我们将签名服务设置为另一个微服务,它将迎合其他微服务。这个自签名服务将连接到 HSM 或硬件安全模块。所有证书都存储在属于 HSM 的内部到配置文件。您可以在 HSM 上进行一些谷歌搜索并创建配置文件。

信任存储用于保存公共证书,密钥存储用于存储私钥。这是标准,不是通用的,但在理想情况下。

【讨论】:

    猜你喜欢
    • 2020-10-24
    • 2017-09-14
    • 1970-01-01
    • 2017-09-26
    • 2021-11-27
    • 2019-02-26
    • 2018-03-03
    • 2019-08-19
    • 2020-09-20
    相关资源
    最近更新 更多