随着Kubernetes Istio和AWS App Mesh等云原生技术的发展势头

当Amazon Web Services在3月底宣布其App Mesh时，云本地开发的服务网络创新变得更加有趣。随着云端原生技术(如Kubernetes，Istio和AWS App Mesh)的增长势头 - 以及47%的企业每周多次部署到生产中，围绕网络安全，容器和网格未来的问题正在成为一个问题。非常相关的。

这与安全性转向零信任方法 - 其中dev，sec和ops不信任其软件供应链中的任何组件或其本地堆栈 - 所有从业者都需要解决的关键问题。这些问题可以使每个人更接近现代DevSecOps团队，使用智能，可扩展和自动化的Zero Trust方法，不会降低敏捷性和DevOps。

DevSecOps团队需要关注的是整个软件供应链，它由许多部分组成，并与软件开发生命周期模型保持一致。云优先或拥有云原生技术的人需要检查他们自己的代码，第三方代码及其所有支持基础架构 - 在容器网络级别应用微细分不再足以阻止攻击或防止增加的漏洞，如公开的访问凭据。

在这篇eWEEK数据点文章中，利用来自Alcide的 CTO和联合创始人Gadi Naor的行业信息，我们深入研究了云原生安全的发展方向，网络安全监控的未来，网状网性能以及多层网络的方式控件可以让DevSecOps团队运行安全且不间断的代码和操作。

数据点1：网络安全监控的未来：eBPF和服务网格，如Istio和AWS App Mesh

服务网格周围的运动非常惊人。构建分布式系统和微服务是一回事 - 保护和监控它们极具挑战性。Istio试图通过服务和底层基础设施之间的解耦来应对这些挑战。

现实是，从安全的角度来看，底层网络是不可忽视的，实际上，服务网格边车提供的所有隔离/分段/零信任的感觉都是误导性的。SideCar被“编程”，不会路由非服务流量，这意味着从隔离的角度来看 - 其他东西需要解决这个问题。

这里有eBPF，嵌入或伪造网络级策略来分割和检查网格内部和网格外部的流量，并在此过程中覆盖所有网络接地。

数据点2：服务网格，它们的性能影响以及如何减轻它们

服务网格以安全性和可观察性的形式带来的好处伴随着沉重的资源税。您将每个工作负载与SideCar结合在一起，这意味着网络流量需要被引导到两侧(源和目标)以进行网内通信 - 显然您需要支付计算，内存和网络延迟。

使应用服务网格感知倾向于在网络延迟方面引入显着的性能增益。这种税迫使人们更加需要引入网状网络分割，这意味着政策管理变得更具挑战性，深度网络安全控制肯定会被忽视。

数据点3：节点和负载均衡器的多网络控制对服务流量的作用

很明显，当我们添加抽象层来解决某些操作和安全挑战时，我们最终会管理多个防火墙和隔离策略 - 如果我们交叉切割它，我们将看到Istio网络策略用于网状策略实施，然后，遵循良好实践中，我们会看到代表服务车辆政策的Kubernetes网络政策。然后，我们通过代表基础架构级策略的云原生网络安全控制(AWS安全组，Azure NSG等)来实现这一点 - 显然，策略隔离管理成为一个真正的挑战，不仅不应该被忽视，而且需要一种新的智能和自动化方法来解决它。

数据点4：威胁搜寻和威胁情报的自动化方式

如果策略代表了我们预期的服务行为的执行层，那么威胁搜寻代表了必须对云本机应用程序部署进行“糖涂层”。与强制层方法类似，威胁搜寻需要一个智能和自动化的框架 - 一个与CI / CD集成并随着部署的增长而扩展的框架。这种方法当然需要在精神上植根于零信任，并从网络扩展到开发方，然后扩展到整个SDLC。