容器安全成熟度模型.docxVIP

容器安全成熟度模型 虽然越来越多的企业开始采用容器化的云原生应用，但传统的安全措施却无力应对新技术发展带来的挑战。当下云原生虽说异常火热，却没有一个清晰的路线图，能够指明在容器化过程中，各个阶段该如何做好安全。由于容器化的每个阶段都会带来新的安全挑战，企业必须在做好基础架构的同时，确保每个阶段的安全。可以预见，从第一个容器化应用开发到管理数千个容器过程中，安全需求也在不断变化。 容器安全成熟度模型，旨在帮助企业在采用容器和容器扩容过程中能够更好理解并成功应对所产生的各类安全挑战。 01 一、引言 无论应用是在容器中运行，还是在虚拟机、主机上运行，发生安全事件的后果都是相同的。此外，在安全事件发生后，无论打多少补丁，也无法挽回已泄露的敏感数据。据调查报告《2020年容器与Kubernetes安全状况》显示，94％的受访者表示，在过去12个月中发生了容器安全事件。 在过去12个月中遭遇过容器安全问题类型和比例 在很多情况下，企业并不完全了解容器化架构所面临的安全挑战，更不用说如何主动应对这些挑战。这时，常见的做法就是将之前的安全策略应用到容器中来，但这并不一定适合新的应用体系架构和开发工作流程。总得来说，就是容器使用率不断提高，但安全总是落后一步。 ? 下文将针对容器安全成熟度模型进行详细解释，旨在帮助企业更好了解需要部署哪些重要工具，采取哪些措施，来满足当前和未来容器安全需求。 二、容器安全成熟度模型 第1阶段：实验学习 在这个阶段，主要是开发人员自己学习如何在机器上使用容器。例如，通过一些不进入生产系统的项目做练习。在这一阶段，所涉及的应用大多是一些基本应用。 ? 这阶段可能持续数月之久。由于只有个别开发人员在学习和测试容器，因此只要项目不是用于生产，就不需要专用的安全工具，也不需要改变以往安全策略。与往常一样，开发人员只需确保安全编码。但是，这个阶段安全也是声明式的和自动化的，是开发工作流程的一部分，而不是在完成应用构建后才解决安全问题。 虽说，在该阶段安全并不太重要，也不会犯什么错误。但是，如果组织机构打算扩展容器化项目，则需要确保让每个人都了解，安全风险和复杂性会在扩展后迅速增加。在第1阶段和第2阶段之间的安全挑战存在巨大差异的，这会让许多组织机构措手不及。 第2阶段：正式启动 在这个阶段，容器化已不再是个别开发人员的业余项目，而是由团队或业务部门开展一部分正式项目。这时，开发团队会用容器创建一个用于生产的新应用或将现有应用容器化。 ? 大多数组织机构在开发其第一个容器化应用时，可能会使用下列其中一种方法： 将现有应用容器化 将现有应用的一部分内容容器化 从头开始在容器中开发新应用 无论开发团队采取哪种方式，这一阶段属于概念验证阶段，主要了解云原生技术会带来效益，以及应用是如何在容器中运行的。 开展一个正式项目，就需要多人合作，这时就有必要建立一个镜像仓库了。组织机构可以创建私有镜像仓库，通过策略规定谁可以访问镜像或镜像仓库，确保镜像来源可信。毕竟攻击者通常会通过镜像仓库中的受损镜像，获得对某个应用的初始访问。 这个阶段的第一个核心问题是认知偏差。从开发人员到习惯使用传统工具的安全专家，几乎没有人完全了解容器中可能出现潜在安全问题。这种知识或技能上差距会导致公司“所采取的安全”措施与“应该采取的安全措施”之间会出现差距。 这一阶段的第二个核心问题是没有做好未来规划。只考虑当前阶段所需的工具和安全需求，而没考虑容器化项目扩大使用范围之后所需的安全能力。公司在此阶段必须考虑以下注意事项： （1）合规策略。容器安全不只是使用安全工具就可以彻底解决，还必须制定一些策略，这样才能够确保在整个容器生命周期中落实合规要求。虽说大多数公司早已经制定了一套安全策略来管理应用开发，但也需要根据容器化应用的特定环境，修改安全策略，满足容器安全需求。 （2）漏洞管理。在开发过程中，漏洞管理最重要的环节就是镜像扫描。不同的扫描工具，其扫描的粒度也不同。有些扫描工具能够发现操作系统漏洞和某些特定语言才会有的漏洞，而有些却无法扫描每个镜像层或某些开源软件包。 （3）配置管理。在该阶段，DevOps和安全团队可以采用CIS基准中针对Docker和Kubernetes的配置指南。在该阶段，团队可能仍会手动进行配置管理，但是自动执行配置检查的工具将改善安全状况并减少运营工作量。 第3阶段：生产部署 到这个阶段，组织的第一个应用已投入生产运行。编排工具开始成为容器化应用生产部署的一个关键部分。使用Kubernetes、MESOS、Swarm等工具可以自动执行与容器运行相关的大多数操作任务。以Kubernetes为例，当容器在Kubernetes中运行时，它们被打包在Pod单元中。Pod可以包含一个或多个容器，但是同一Pod中的所有容器将共享相同的资源和