本文共 1693 字,大约阅读时间需要 5 分钟。
微服务跨域安全问题
我在写这篇文章的标题时很费劲,我担心它会被当作点击诱饵。 如果您是因为它看起来像点击诱饵而来阅读这篇文章,那么对不起。 我还是希望您能留下来:有很多有趣的分和脚注。 我并不是要暗示的是,微服务会引起问题(尽管当然会像其他任何组件一样),但是微服务是涉及安全性的人们感兴趣的适当对象。 我将进一步介绍:我认为对于那些关心安全性的人来说,它们是一种出色的体系结构。
那为什么呢? 好吧,对于我们这些注重 ,当今世界是一个有趣的地方。 我们看到分布式系统正在增长,因为带宽便宜且延迟低。 除此之外,部署到云的便利性也越来越高,越来越多的架构师开始意识到他们可以将应用程序分解为多个层,而且可以分解为该层中的多个组件。 负载均衡器,当然,这个时候在一个层中的各种成分都进行相同的工作的帮助,但暴露不同的服务小部件的能力,导致在设计,实施和微服务的部署生长。
? 我很喜欢 ,但有趣的是这里没有提到安全性。 我喜欢微服务的要点之一是,经过精心设计,它们符合Peter H. Salus对的描述的前两点:这三个中的最后一个不那么相关,因为Unix哲学通常用于指代通常具有命令实例化的独立应用程序。 但是,它确实封装了微服务的基本要求之一:它们必须具有定义明确的接口。
“定义明确”不仅指对任何可从外部访问的API的方法的描述,还包括对微服务正常运行的描述:输入和输出,以及副作用(如果有的话)。 正如我在上一篇文章中所描述的那样,“ ”,数据和实体描述对于您能够设计系统至关重要。 在这里,在我们对微服务的描述中,我们了解了为什么它们如此重要,因为对我而言,微服务架构的关键定义特征是可分解性。 而且,如果您要分解体系结构,则需要非常非常清楚地了解哪些“位”(组件)将要做什么。
这就是安全性开始发挥作用的地方。对特定组件应该做什么的清晰描述允许您执行以下操作:
现在,在更大的体系结构中所有这些事情都有可能吗? 对,他们是。 但是,当实体链接在一起或以更复杂的配置组合在一起时,它们变得越来越困难。 当您需要一起工作时,确保正确的实现和行为非常容易。 如果您不能确定各个组件是否按其应有的方式工作,则派生复杂的系统行为和不当行为会更加困难。
但是,它并不仅限于此。 正如我在许多提到的 ,编写好的安全代码很困难。 证明它确实应该做的事情更加困难。 因此,有充分的理由将具有特殊安全要求的代码(密码检查,加密,加密密钥管理,授权等)限制在定义明确的小块内。 然后,您可以做上面提到的所有事情,以确保正确完成。
还有更多。 我们都知道,并不是每个人都擅长编写与安全性相关的代码。 通过分解体系结构,使所有对安全性敏感的代码都限于定义明确的组件,您将有机会让最好的安全人员从事这一工作,并限制J.Random Coder 将绕过或降级某个组件的危险。密钥安全控制。
它也可以作为学习的机会:指向设计/实现/测试/监视元组并说:“这就是应该做的。听到,阅读,标记,学习并向内消化,这总是好事。 “
您是否应该将所有旧应用程序分解为微服务? 可能不是。 但是,鉴于您可以获得的所有好处,您可以考虑从安全功能开始。
好吧,有一点-拥有读者总是很高兴。
我知道它们是:我写了它们。
可能不那么吸引人。
在撰写本文时。 我(或其中一位)完全有可能编辑该文章以进行更改。
这听起来像是一个园艺术语,很有趣。 不是说我真的很喜欢园艺,而是。
有趣的是,我首先写道:“……如果要分解您的建筑师……”,这听起来像是一部以IT为主题的谋杀电影的标语。
普通读者可能还记得对优秀影片《它的厚实》的参考。
存在其他通用角色; 请选择。
不是加密摘要:我认为这不是原始作者的想法。
本文最初出现在 ,经许可重新发布。
翻译自:
微服务跨域安全问题
转载地址:http://drszd.baihongyu.com/