微服务-数据库安全

Question

我们正在走微服务路线，尝试打破单体。 以前我们有一个数据库被多个应用程序攻击。 应用程序获得了对他们需要访问的特定表的授权。

对于微服务架构，我们计划在服务中包含一个特定的域，并且该服务有自己的数据库。

我们使用自托管 Windows 服务来支持微服务。 他们都为了持久性而命中了 SQL 服务器。 我们计划使用服务的集成安全性来对数据库进行身份验证。

这是问题开始的地方。 为了验证一项服务并确保数据库未被任何其他服务使用，我们计划为每个应用程序设置一个服务帐户。 现在，对于少数微服务，这些帐户的管理（基于策略的频繁密码更改）是可以的。 一旦服务的数量超出了人工管理的规模，我们担心账户管理（每个服务一个账户）将开始变得痛苦。

目前整个行业是如何做到这一点的。 有什么工具可以用于此目的吗？

Answer 1

我会通过将正确的用户/凭据部署到数据库来解决这个问题，作为从持续集成/持续部署服务器（CI/CD 服务器）自动部署服务的一部分。 您可以将用户凭据作为secrets存储在 CI/CD 服务器中。 此外，集群基础设施系统（例如 kubernetes）也允许您存储机密。

例如，如果您使用 Jenkins 进行部署，您将在部署任务中包含一个操作，以在部署/更新数据库和模式时创建/更新所需的用户/凭证。

还有一个重要的一般说明 - 如果您担心大量服务，这对我来说表明您可能正在计划过于细粒度的服务。 服务范围的一般动机是允许专门的two pizza team拥有单一服务及其完整的生命周期。 您希望每个服务的开发人员比例至少为 1:1。如果您让每个开发人员负责许多微型服务，我认为您不会从微服务架构风格中获益太多。

这里引自Martin Fowler 网站（顺便说一句，非常推荐阅读）：

微服务有多大？

尽管“微服务”已成为这种架构风格的流行名称，但不幸的是，它的名称确实导致了对服务规模的关注，以及关于什么是“微”的争论。 在我们与微服务从业者的对话中，我们看到了各种规模的服务。 报告的最大规模遵循亚马逊的两个披萨团队的概念（即整个团队可以由两个披萨喂养），这意味着不超过十几个人。 在较小规模的情况下，我们已经看到一个由六个人组成的团队支持六个服务的设置。

这就引出了一个问题，即在这个规模范围内是否存在足够大的差异，以至于不应将每打人服务和每人服务规模归为一个微服务标签。 目前我们认为最好将它们组合在一起，但随着我们进一步探索这种风格，我们当然有可能改变主意。