微服务跨域安全问题_为什么微服务是安全问题

微服务跨域安全问题

我在写这篇文章的标题时很费劲，我担心它会被当作点击诱饵。 如果您是因为它看起来像点击诱饵而来阅读这篇文章，那么对不起。 ¹我还是希望您能留下来：有很多有趣的²分和^3个脚注。 我并不是要暗示的是，微服务会引起安全性问题（尽管当然会像其他任何组件一样），但是微服务是涉及安全性的人们感兴趣的适当对象。 我将进一步介绍：我认为对于那些关心安全性的人来说，它们是一种出色的体系结构。

那为什么呢？ 好吧，对于我们这些注重系统安全性的人来说 ，当今世界是一个有趣的地方。 我们看到分布式系统正在增长，因为带宽便宜且延迟低。 除此之外，部署到云的便利性也越来越高，越来越多的架构师开始意识到他们可以将应用程序分解为多个层，而且可以分解为该层中的多个组件。 负载均衡器，当然，这个时候在一个层中的各种成分都进行相同的工作的帮助，但暴露不同的服务小部件的能力，导致在设计，实施和微服务的部署生长。

微服务到底是什么 ？ 我很喜欢Wikipedia的定义 ，但有趣的是这里没有提到安全性。 ⁴我喜欢微服务的要点之一是，经过精心设计，它们符合Peter H. Salus对Unix哲学的描述的前两点：

1. 编写可以做一件事并且做得很好的程序。
2. 编写程序以协同工作。
3. 编写程序来处理文本流，因为这是一个通用接口。

这三个中的最后一个不那么相关，因为Unix哲学通常用于指代通常具有命令实例化的独立应用程序。 但是，它确实封装了微服务的基本要求之一：它们必须具有定义明确的接口。

“定义明确”不仅指对任何可从外部访问的API的方法的描述，还包括对微服务正常运行的描述：输入和输出，以及副作用（如果有的话）。 正如我在上一篇文章中所描述的那样，“ 好的系统架构的5个特征 ”，数据和实体描述对于您能够设计系统至关重要。 在这里，在我们对微服务的描述中，我们了解了为什么它们如此重要，因为对我而言，微服务架构的关键定义特征是可分解性。 而且，如果您要分解^5个体系结构，则需要非常非常清楚地了解哪些“位”（组件）将要做什么。

这就是安全性开始发挥作用的地方。对特定组件应该做什么的清晰描述允许您执行以下操作：

• 检查您的设计
• 确保您的实现符合说明
• 提出可重复使用的单元测试以检查功能
• 跟踪实施中的错误并予以纠正
• 测试意外结果
• 监控不良行为
• 审核实际行为以供将来检查

现在，在更大的体系结构中所有这些事情都有可能吗？ 对，他们是。 但是，当实体链接在一起或以更复杂的配置组合在一起时，它们变得越来越困难。 当您需要一起工作时，确保正确的实现和行为非常容易。 如果您不能确定各个组件是否按其应有的方式工作，则派生复杂的系统行为和不当行为会更加困难。

但是，它并不仅限于此。 正如我在以前的许多场合中提到的那样 ，编写好的安全代码很困难。 ⁷证明它确实应该做的事情更加困难。 因此，有充分的理由将具有特殊安全要求的代码（密码检查，加密，加密密钥管理，授权等）限制在定义明确的小块内。 然后，您可以做上面提到的所有事情，以确保正确完成。

还有更多。 我们都知道，并不是每个人都擅长编写与安全性相关的代码。 通过分解体系结构，使所有对安全性敏感的代码都限于定义明确的组件，您将有机会让最好的安全人员从事这一工作，并限制J.Random Coder ⁸将绕过或降级某个组件的危险。密钥安全控制。

它也可以作为学习的机会：指向设计/实现/测试/监视元组并说：“这就是应该做的。听到，阅读，标记，学习并向内消化，这总是好事。 ⁹ “

您是否应该将所有旧应用程序分解为微服务？ 可能不是。 但是，鉴于您可以获得的所有好处，您可以考虑从安全功能开始。

---

1好吧，有一点-拥有读者总是很高兴。

2我知道它们是：我写了它们。

3可能不那么吸引人。

4在撰写本文时。 我（或其中一位）完全有可能编辑该文章以进行更改。

5这听起来像是一个园艺术语，很有趣。 不是说我真的很喜欢园艺，而是。 ⁶

6有趣的是，我首先写道：“……如果要分解您的建筑师……”，这听起来像是一部以IT为主题的谋杀电影的标语。

7普通读者可能还记得对优秀影片《它的厚实》的参考。

8存在其他通用角色； 请选择。

9不是加密摘要：我认为这不是原始作者的想法。

本文最初出现在安全博客Alice，Eve和Bob上 ，经许可重新发布。

翻译自: https://opensource.com/article/17/11/microservices-are-security-issue

微服务跨域安全问题