环球门户网

将服务网格视为安全工具

更新时间:2021-12-09 22:02:19

导读 如果你喜欢最安全的工作,你有很好的机会,因为你开始变得沮丧,因为微服务有点小,或者可能很多。从软件架构师的角度来看,微服务架构——

如果你喜欢最安全的工作,你有很好的机会,因为你开始变得沮丧,因为微服务有点小,或者可能很多。从软件架构师的角度来看,微服务架构——,即使用REST构建大量小型、分布式和模块化组件的架构——,是非常强大的。

是要快速更改组件而不关闭整个应用程序,还是要向Fly添加新功能?微服务促进了这些目标。您可以独立地修改(或添加)您感兴趣的特定服务,而不必重新构建一个大的整体应用程序。

当然,这一点的缺点是,从安全管理的角度来看,可能是一场噩梦。有几个原因。对于安全架构师来说,这是一个挑战,因为我们最有效的工具之一,——应用程序威胁建模3354,依赖于分析攻击者观点的组件之间的交互。

这样做的前提是随着时间的推移,保持一个或多或少恒定的通信通道。如果开发人员每五分钟推送一次更新,并且服务之间的路径发生变化,那么威胁模型只在那个时间点有效。如果你曾经尝试过威胁模型(并保持更新),这是一个快速增长的应用程序,大量使用微服务,那么你可以确切地知道它有多令人沮丧。

从操作角度来看,这也是一个挑战。在幕后,实现微服务最常见的方式是Kubernette业务流程的Docker。这意味着实际运行服务的容器被设计为短期的:添加新的容器以适应增加的负载,并重新部署容器以适应应用程序更改或更新的配置。

为了说明这一挑战,假设您几天前收到了入侵检测系统警报、日志条目或可疑活动。哪些主机/节点实际参与了哪些主机/节点,它们的状态如何?

试图发现可能是为了抓住机会:当你到达那里时,那些集装箱可能已经被覆盖和重新部署了几次。除非从警报中清楚什么是透明的(什么时候是透明的?)您的事件解决方案现在依赖于从过去某个时间到高度复杂的系统状态的逆向工程。

幸运的是,服务网格体系结构是可以对此提供很大帮助的最新技术之一。作为一种设计模式,服务网格实际上可以在几个方面为安全从业者提供很多帮助。对开发者来说是强大的,但在安全领域对我们来说不是更强大也是——。

什么是服务网格?有一种方式认为它是你服务的“交通调度员”。当一个服务想要与另一个服务通信时,有两种选择。选项1:它知道所有其他存在的服务,并实现与它们对话的逻辑。方案二:需要别人来做这项工作。

想想看,就像寄信一样。如果我想给我在肯塔基州的表弟寄信,我可以写信给我,上车,开车去他家给他。这取决于很多事情:我知道他的地址,我有车,我准备离开,我试图去他家,我知道他是否要搬家,等等。只是效率不高。

最好的办法是把这封信和地址写给我,让邮局来做这项工作。让他们保留必要的资料和投递设备,让我专注于我真正关心的事情:我的信在哪里?

智能实现——,有很多方法可以做到这一点,但最常见的方法是通过“Sidecar”容器。什么是Sidecar集装箱?它只是另一个容器——,一个运行代理的容器,被配置为在服务之间传递流量。这意味着它被配置和部署为将消息的“传递”与应用程序逻辑分开。

从应用程序开发的角度来看,好处应该是相当明显的:开发人员可以专注于业务逻辑,而不是基于‘东西方’通信的机制(即服务之间的通信)。但是,在安全性方面有优势。

值得注意的是,它提供了监控和其他安全服务之间的链接。这可以在不调整单个服务的应用程序逻辑的情况下添加(或者,事实上,甚至是未知的)。因此,例如,如果我想允许服务A仅使用TLS和可靠的身份验证与服务B对话,我可以这样做。同样,如果我想记录容器的哪个版本在给定的时间点与另一个容器对话,我可以配置它来告诉我。

如果它听起来对你有吸引力,它应该是。事实上,它代表了在安全世界中很少发生的事情:它使开发人员能够以更安全的方式而不是更安全的方式做事。

开发人员发现它很有吸引力,因为他们不必为与其他服务的通信提供详细的通信和交付物流信息。此外,它还增加了安全选项,否则我们必须在应用层实现它们。

因此,如果您的组织正在考虑微服务,服务网格体系结构实际上可以帮助您保护环境。如果您已经在使用它,了解它可以帮助您融入对话,并为您提供一些工具来缓解微服务的一些“痛点”。\r\r\r\r\r\n " "

唯一的一点是,学习新的工具集并使架构工具适应新的模型确实需要一些准备工作。无论您使用Istio特使、Linkerd还是其他内容,首先都会要求您阅读文档,以了解哪些功能可用、工具集如何工作以及哪些策略/配置选项可供您使用。这是一个好主意,因为您需要验证配置只是时间问题。

另外,如果你还

为了用威胁来建模您的应用程序,您可能需要考虑新的范例,这总是一个好主意。

具体来说,在您的数据流分析中有一个更符合逻辑的视图——也许是通过分别分析每个服务的输入和输出,而不是假设‘服务A’将只与‘服务B’相关联(或者更糟糕的是,假设服务之间的静态流量是基于应用程序在给定时间点的操作)。

关键是安全专业人员不仅不要害怕服务网格,还要考虑积极拥抱它的实际参与。

EdMoyle是Prelude学院的总经理兼首席内容官。自2007年以来,他一直是ect新闻网的专栏作家。他在计算机安全方面的广泛背景包括在取证、应用渗透测试、信息安全审计和安全解决方案开发方面的经验。ED是面向开发人员的加密库的合著者,并且作为作者、公众演说家和分析师经常为信息安全行业做出贡献。

版权声明:转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益,请作者持权属证明与本网联系,我们将及时更正、删除,谢谢您的支持与理解。