由于其速度和成本节约，云原生开发已成为公司开发新应用程序的事实上的方式。虽然它为大多数组织打开了Kubernetes、容器和无服务器的世界，但他们仍然需要解决这种开发方式带来的某些复杂性和安全问题。
关于现代云原生应用服务的使用，例如微服务、功能即服务、容器和容器编排框架(Kubernetes)，超过80%的开发人员报告说他们的组织正在实施过程中根据IDC报告“PaaSViewandtheDeveloper”，这些服务正在试点或已经在使用。
根据Gartner的分析，预计未来12个月采用率最高（超过20%的受访者）的云平台是云管理的Kubernetes和容器平台（CaaS）或aPaaS，公民开发平台和云管理的无服务器功能平台(fPaaS/FaaS)。
相关内容：这些供应商如何帮助公司实现云原生安全云原生安全工具指南
“今天，如果我要编写一种新的客户服务门户。对于保险公司来说，不是云原生的可能性非常低。因为它更具可扩展性、更易于更新且更具弹性，”AquaSecurity战略和产品营销副总裁RaniOsnat说。
云原生开发改变了开发人员传统上使用CI/CD和更快速的持续更新软件的方法进行开发的方式。
Osnat表示，这带来了一些挑战，因为用户不一定对一切将在哪里运行有深入的了解，因为它可以在任何地方运行。
“你可以在这个更灵活的环境中工作，但与旧类型的瀑布式SDLC相比，它还要求你更加了解如何打包和交付代码，或者它的过程要慢得多，”Osnat说.
由于设置Kubernetes的困难，很少有公司使用vanillaKubernetes，而是选择更多托管选项。一个这样的选择是Kubernetes的发行版，它具有更好的默认值，并且更适合某些类型的应用程序，例如K3s，轻量级Kubernetes，在物联网中大量使用。Osnat表示，单节点Kubernetes也可以有效地用于开发和测试。
更深入的是云托管产品，例如AKS、EKS、GKE等。
“这些基本上是根据集群为你设置的。您不需要对配置主节点做太多事情，”Osnat说。“许多云开发人员将创建这些的本地版本。例如，亚马逊有EKSAnywhere，它与EKS相同，但你可以在本地运行它，如果你愿意，甚至可以在另一个云上运行，至少在理论上是这样。”
Osnat解释说，更进一步的是OpenShift、Tanzu等平台，它们将Kubernetes与其他功能结合起来，这些功能具有更多自以为是或预设的配置以及其他功能，例如身份访问管理，以及更好的版本控制和部署控制。
云原生对开源的依赖需要额外的安全性
云原生开发和开源的使用正在同步增长，促使公司采取额外的安全措施来处理更开放的代码。
“今天，在一个典型的云原生应用程序中，你会看到70-80%的代码库是开源的。所以你可以说云原生应用程序有很多可重用的代码。造成的问题是，首先，存在一个供应链问题，您无法管理所有进入的代码，”Osnat说。“第二个是已知的漏洞。所以开源比自定义代码有更多已知的漏洞，因为它是开放的。”
ContrastSecurity的《年开源安全状况报告》显示，传统的软件组合分析(SCA)方法试图分析应用程序中包含的所有开源代码——这转化为追逐不构成风险的漏洞的巨大时间和资源支出全部。然而，对于调用的第三方代码，风险是固有的：库的平均年龄为2.6年，应用程序平均包含34个CVE。
根据ContrastSecurity产品营销总监BlakeConnell的说法，在使用功能时，用于安全的传统工具显然是不够的。
“有了函数，因为你只是在组装这些小代码，所有这些小代码本身就是实体。因此，对于安全问题，这种暴露范围更广。然后这些作为这些功能一部分的权限以某种默认方式设置，”康奈尔说。“根据您组装应用程序的方式，您可能希望在这些权限上进一步拧紧螺丝。这是功能无服务器安全角度的一个常见挑战，即过于宽松的功能概念。”
保护无服务器架构
Connell表示，保护无服务器架构也很重要，因为无服务器计算处于云原生发展趋势的最前沿。
根据ContrastSecurity的无服务器应用程序安全状况报告，绝大多数(71%)组织现在拥有六个或更多开发团队来创建无服务器应用程序。这些发现与其他研究一致，例如NewRelic的无服务器技术半年度报告，该报告显示从年到年，无服务器应用程序的平均每周调用量增加了%。
Connell补充说，典型的公司正在使用一组断开连接的旧工具来保护其无服务器应用程序，这些工具不再工作得那么好——即使对于传统基础设施上的应用程序也是如此。
对于无服务器应用程序，这些工具的效率更低。没有面向公众的URL的函数导致的“无边缘盲区”使他们对无服务器架构的可见性很差。ContrastSecurity发现，基础设施、网络和服务器的抽象证明让传统工具感到困惑，并导致误报率超过85%。遗留工具只是缺乏进行充分分析的上下文。
无服务器也提出了自己的挑战，因为它基于可以快速发生然后消失的短暂事物。因此，根据Osnat的说法，所有这些都需要一组非常不同的控件。
因此，组织需要一个良好的优先级策略来了解哪些漏洞正在影响环境，Osnat解释说。
“您可能存在依赖于某些网络连接来被利用的漏洞。但是如果你在一个纯粹的内部和封装的应用程序中运行它，它比对互联网开放的开放应用程序更不利，”Osnat说。
堆栈影响云原生安全
影响云原生安全性的第三个因素是运行应用程序的新堆栈的开始。公司不再依赖底层服务器或虚拟机为他们进行隔离。用户还运行各种类型的工作负载。例如，如果他们在AWSFargate或Azure上的ACI等容器即服务平台上运行容器，则这些容器在持续的虚拟化环境中运行，并且没有可以访问的底层VM.
组织正在赋予开发人员更多的安全责任，但是，这方面的技能短缺，并且开发人员比安全专业人员多得多。这促使公司寻求更自动化的解决方案，以增强开发人员处理安全性的方式。
“我们通过引入高度自动化来解决这个问题，使开发人员能够将安全作为日常工作的一部分，而不是期望他们或要求他们改变工作方式或成为安全专家。没有人期望开发人员成为安全专家，并期望开发人员制定策略。该策略应由安全设置。因此，我们所做的就是启用这个涵盖开发人员、DevOps和安全性的解决方案，”Osnat说。“安全性可以了解正在发生的事情，并且可以为开发人员确定问题的优先级，然后让开发人员在他们的代码中尽可能多地修复这个问题，或者尽可能早地知道有些事情不会被修复。我们可以说这需要尽快修复，你升级到这个版本，或者你用这个包交换这个包或者你改变这个配置，
IDC平台即服务(PaaS)研究总监LaraGreden表示，虽然云提供商正在做很多事情，但在帮助解决安全问题的解决方案的各个供应商提供商的启动开发领域也有很大的发展空间。）实践。
“并不是说拥有软件开发团队的组织只是在利用主要云提供商在安全方面提供的东西，”Greden说。“他们还添加了他们的应用程序在后端调用的其他服务。”
解决其中一些安全问题的另一种方法是通过“委托”开发人员成为安全工作的一部分的概念。根据ContrastSecurity的Connell的说法，开发人员将代码交给安全部门，让安全团队运行静态扫描，并在将它们发回给开发人员之前创建一堆潜在漏洞的日子在今天的云原生世界中是行不通的。
现在自动化发现了一个漏洞，可能是一个过于宽松的功能，并尽早将这些信息提供给他们环境中的开发人员。然后它提供示例代码和建议的补救措施。然后，开发人员可以直接复制和粘贴代码，或者稍微修改它，然后重新提交该函数。解决方案再次扫描，当一切正常并继续运行时，Connell解释说。
云原生开发变得更容易访问和更广泛
据IDC的Greden称，虽然起初组织正在考虑通过利用数据中心中的技术来为其应用程序使用私有云，但现在它已越来越多地转向边缘计算。
“我们今天拥有的是边缘计算，也就是说，在某些情况下，由云提供商提供，”格雷登说。“这是作为云服务发送的，但来自边缘位置。拥有自己的迷你数据中心的组织也可以访问它。”
尽管现在对本地类型的数据中心或位置中心的投资减少了，但出于延迟等原因，计算靠近应用程序的需求并没有消失。“现在，我们能够将云原生开发应用到这些类型的位置，”Greden补充道。
此外，现在比以往任何时候都更多的人可以通过公民开发和使用低代码来使用云原生开发。
“这实际上是一个增强应用程序开发的时代，包括全栈开发人员在内的开发人员，无论他们是初级还是高级，都在说他们使用的工具的第一个属性是代码抽象，以低代码和无代码为代表。代码，”格雷登说。“我们已经达到了供应商能够将某些组件打包在一起而不必重写代码的地步，这确实有助于代码的简单性和代码的优雅性。”
转载请注明：http://www.0431gb208.com/sjsbszl/6553.html
