有人可以对我正在考虑的微服务安全设计发表评论，审核，批评或其他方面的评论吗？
假设我有三个微服务，每个微服务通过REST端点与其他两个微服务进行通信。每个微服务都包含一个密钥库。在此密钥库中包含由受信任的证书颁发机构签名的微服务的私有/公共密钥对。此密钥库中还有另外两个微服务的公钥证书，从源微服务的签名/可信密钥对导出。
这种实施方式有效，但有些事情并不十分正确。
即，每次我介绍一个新的微服务时，我必须将每个现有微服务的公钥证书添加到其密钥库中，以及b）新微服务的公钥证书到其他所有微服务（假设是新的微服务必须通信bi - 对每个现有的微服务都是双向的，安全的。）
现在，为第二个密钥对重复上述模式，这个密钥对用于签署/验证REST调用中提供的身份验证令牌。
我想知道，除了上述内容之外，是否a）建议并且b）在所有微服务之间共享单个可信公钥证书是否安全？完全不同的东西？
请礼貌。我绝不是这方面的专家。
修改 在阅读了我原来的帖子的回复/评论之后，我想到了我省略了可能使问题更加清晰的细节，因此评论者能够更好地解决这个问题：
有问题的微服务存在于私有内部网中，并且只能由该内部网中的客户端（浏览器或其他微服务）访问。
实际上有一个受信任的CA--即拥有此内部网的公司 - 并且是CA签署微服务的密钥对。
似乎@Andreas的第一条评论暗示了这个问题的解决方案，他写道：“只要发布它们的CA是可信的，它们也会受到信任。”
只要每个新的微服务都部署了a）自己的密钥对，由CA签署（一个用于签名，另一个用于加密），以及b）CA的证书，我可以合理地保证他们将部署新的微服务与所有其他微服务安全地通信（因为我甚至不知道其他潜在的漏洞，这是合理的）。
不知怎的，我已经明白了，我必须为每个微服务的密钥对创建一个全新的证书，并将其包含在其他微服务的密钥库中（对每个新的微服务重复）。相反，我需要的只是一个证书，即在每个微服务的密钥库中签署密钥对的CA的证书。
答案 0 :(得分：3)
一种方法（你的问题是广泛的，没有代码，它可能是关于SoftwareEngineering的主题，而不是在这里）如下：
通过这种方式，当您引入新的微服务时，您只能为其生成一个证书，而在其他微服务中无需更改，这是您需要达到的目标，否则无法进行管理。
通过这样做，您甚至可以根据需要将一些微服务移出我们的系统。它们只需要随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以及给出其他想法的答案，例如使用保险库。
答案 1 :(得分：1)
如果您的微服务没有暴露给网络，那么您可以为此目的创建自签名证书。自签名证书用于内部呼叫。您可以在sslshopper网站上创建它们。
此外，不要对所有微服务使用相同的证书。 我已经实现了类似的解决方案，在我们的例子中，我们已经将Signed Service设置为另一个微服务，它将迎合其他微服务。这个自签名服务将连接到HSM或硬件安全模块。所有Certs都存储在属于HSM的内部你可以在HSM和它的个人资料创建上进行一些谷歌搜索。
信任存储用于保存公共证书，密钥存储用于存储私钥。这是标准的，不是通用的，而是在理想情况下。