我写这篇文章的标题时很纠结，我担心它看起来像标题党。如果您因为标题党的样子而来看这篇文章，那么对不起。1 我希望您无论如何都会留下来：这里有很多有趣的2 观点和许多3 脚注。我并非想暗示微服务会导致 安全 问题——当然，像任何组件一样，它们可能会导致安全问题——而是微服务是那些参与安全工作的人员感兴趣的合适对象。我会更进一步说：我认为对于那些关注安全的人来说，它们是一个极好的架构构造。
这是为什么呢？嗯，对于我们这些对 系统安全 感兴趣的人来说，目前的世界是一个有趣的地方。我们看到分布式系统的增长，因为带宽便宜且延迟低。再加上部署到云的便利性，越来越多的架构师开始意识到他们可以将应用程序分解，不仅分解为多个层，还分解为层内的多个组件。当然，当一个层中的各个组件执行相同的工作时，负载均衡器会有所帮助，但是将不同的服务作为小型组件公开的能力导致了 微服务 的设计、实施和部署的增长。
那么，微服务到底是什么？我非常喜欢 维基百科的定义，尽管有趣的是，那里没有提到安全。4 我喜欢微服务的其中一点是，当设计良好时，它们符合 Peter H. Salus 对 Unix 哲学 的描述的前两点
- 编写只做一件事并做好这件事的程序。
- 编写协同工作的程序。
- 编写处理文本流的程序，因为这是一个通用接口。
最后一点的相关性稍差，因为 Unix 哲学通常用于指代独立的应用程序，这些应用程序通常具有命令实例化。然而，它确实概括了微服务的基本要求之一：它们必须具有明确定义的接口。
我所说的“明确定义”不仅仅是指对任何外部可访问 API 的方法的描述，还包括微服务的正常运行：输入和输出——以及，如果存在任何副作用。正如我在之前的文章“优秀系统架构的 5 个特质”中所描述的那样，如果您要设计一个系统，数据和实体描述至关重要。在这里，在我们对微服务的描述中，我们看到了为什么这些如此重要，因为对我而言，微服务架构的关键定义特征是可分解性。如果您要分解5 您的架构，您需要非常非常清楚哪些“位”（组件）将要做什么。
这就是安全开始发挥作用的地方。对特定组件应该做什么的清晰描述使您可以
- 检查您的设计
- 确保您的实现符合描述
- 提出可重用的单元测试来检查功能
- 跟踪实现中的错误并纠正它们
- 测试意外结果
- 监控异常行为
- 审核实际行为以供将来审查
现在，所有这些事情在更大的架构中都是可能的吗？是的，它们是可能的。但是，当实体链接在一起或以更复杂的配置组合时，它们变得越来越困难。当您有更小的部分可以协同工作时，确保正确的实现和行为要容易得多。如果您不能确定各个组件是否在做他们应该做的事情，那么推导出复杂的系统行为——和异常行为——要困难得多。
然而，事情并没有止步于此。正如我在许多 之前的场合 中提到的那样，编写好的安全代码是困难的。7 证明它做了它应该做的事情更加困难。因此，完全有理由将具有特定安全要求的代码——密码检查、加密、密码密钥管理、授权等——限制在小的、明确定义的块中。然后，您可以执行我上面提到的所有操作，以尽力确保其正确完成。
然而还有更多。我们都知道，并非每个人都擅长编写与安全相关的代码。通过分解您的架构，使所有安全敏感的代码都限制在明确定义的组件中，您就有机会让您最好的安全人员来处理这些代码，并限制 J. Random Coder8 将某些绕过或降级关键安全控制的东西放入其中的风险。
它也可以作为学习的机会：能够指出一个设计/实现/测试/监控元组并说：“这就是应该如何完成的。听，读，标记，学习，并内化消化。9”总是好的。
您应该着手将所有遗留应用程序分解为微服务吗？可能不会。但是考虑到您可以获得的所有好处，您可以考虑从安全功能开始。
1好吧，有一点——总是很高兴有读者。
2我知道它们很有趣：我写的。
3可能没那么有趣。
4在撰写本文时。我——或者你们中的一位——完全有可能编辑文章来改变这一点。
5这听起来像是一个园艺术语，这很有趣。并不是说我真的很喜欢园艺，但仍然如此。6
6有趣的是，我最初写的是，“……如果您要分解您的架构……”，这听起来像是以 IT 为主题的谋杀电影的标语。
7经常阅读的读者可能还记得提到过优秀的电影《幕后危机》。
8还存在其他通用角色；请随意选择。
9不是密码摘要：我不认为这是最初的作者所想的。
本文最初发表在 Alice, Eve, and Bob—安全博客 上，并经许可转载。
3 条评论