容器安全成熟度模型.docxVIP

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