实现安全应用容器架构的最佳实践

©2022国际云安全联盟大中华区版权所有1 摘要 在DevOps等一些敏捷软件开发方法的设计、开发和部署应用阶段往往会采用应用容器和微服务架构。这些软件开发方法里需要嵌入安全。本文从开发者、运营者和架构师的视角，提出了一些建议和最佳实践，解决在可信赖的安全系统工程中保护应用程序容器所面临的挑战。 @2022国际云安全联盟大中华区-保留所有权利。本文档发布在国际云安全联盟大中华区官网(http://www.c-csa.cn)，您可在满足如下要求的情况下在您本人计算机上下载、存储、展示、查看、打印此文档：（a）本文只可作个人信息获取，不可用作商业用途；(b)本文内容不得篡改;(c)不得对本文进行转发散布;(d)不得删除文中商标、版权声明或其他声明；（e）引用本报告内容时，请注明来源于国际云安全联盟。 序言 为深入贯彻落实国家关于建设网络强国、数字中国、智慧社会的战略部署，在各行业主管部门的监督和政策指引下，信息化水平快速提升，构筑全方位的网络安全体系也成为网络安全核心任务。 众所皆知，云计算/云原生技术因能极大地提高云上资源利用率以及应用交付效率而被广泛采用。然而，云计算/云原生技术的发展也让用户遭受了更多高级威胁与攻击。如何构建有效的云原生安全管理体系应对层出不穷的安全威胁这一问题也一直受到千行百业用户的关注与热议。 此次发布的《实现安全应用容器架构的最佳实践》充分考虑了这些年安全应用容器架构的技术发展和行业需求，更好地满足数字化安全的未来发展。 如今，在DevOps等一些敏捷软件开发方法的设计、开发和部署应用阶段往往会采用应用容器和微服务架构。这些软件开发方法里需要嵌入安全。安全的DevOps要求安全人员、开发者和运营者协同工作，方可设计、构建出值得信赖的安全系统。 本文从开发者、运营者和架构师的视角着手，通过通俗易懂的语言提出了一些紧贴落地实践的建议和最佳实践（包括了跨环境的代码加固、主机安全、来自平台/主机的容器持续性监控、容器间的网络通信、验证镜像的完整性和安全性、容器取证、平台管理、容器管理、容器加密等17个方面），希望读者朋友在阅毕后可对安全应用容器架构有更为清晰的理解，能更快、更好地开展应用实践。 李雨航YaleLiCSA大中华区主席兼研究院院长 致谢 《实现安全应用容器架构的最佳实践(BestPracticesforImplementingaSecureApplicationContainerArchitecture)》由CSA工作组专家编写，CSA大中华区秘书处组织翻译并审校。 中文版翻译专家（排名不分先后）： 组长：刘文懋翻译组：陈俊杰 郭嘉伟 刘连杰 刘文懋李娜容 马维士 申屠鹏会 杨玉欢 郑剑锋 审校组：王亮 陆琪 刘文懋 姚凯 研究协调员：刘连杰 感谢以下单位的支持与贡献： 安易科技（北京）有限公司北京华云安信息技术有限公司北京网御星云信息技术有限公司绿盟科技集团股份有限公司厦门服云信息科技有限公司深信服科技股份有限公司 腾讯云计算（北京）有限责任公司中国工商银行股份有限公司 英文版本编写专家 应用容器和微服务工作组主席包括： AnilKarmelAndrewWild 主要作者： JohnKinsellaCemGurkokFrankGeck 参与编著者：JeffBarnes RandallBrooks RamaswamyChandramouli MadhavChablani AtulChaturvedi AradhnaChetal JoshuaCuellar JoshuaDaniel ShyamkantDhamke MicheleDrgon MicheleDrgon FrankGeck MichaelGreenCemGurkok AmirJerbi AmirJerbi JuanitaKoilpillaiYinLee AaronLippold VishwasManral JamesMcCloskeyJamesMcCloskey LloydOsafo LloydOsafo AlexReboMichaelRoza EdSantiago EdSantiago ShankarKenStavinoha ShanthiThomas DavidWayland ShawnWellsJohnWrobel MarkYanalitis JohnOsborne AshishKurmiJamesYapleCSA人员： VrettosMoulos HillaryBaronMarinaBregu 在此感谢以上专家。如译文有不妥当之处，敬请读者联系CSAGCR秘书处给与雅正! 联系邮箱：research@c-csa.cn；国际云安全联盟CSA公众号。 目录 摘要2 序言3 致谢4 英文版本编写专家4 内容提要7 1介绍8 1.1目的和范围8 1.2文档结构8 1.3读者8 2应用容器9 3应对应用容器挑战的缓解措施14 3.1.1跨环境的代码提升14 3.1.2主机安全15 3.1.3平台或宿主机侧的容器持续监控17 3.1.4容器网络-宿主机与容器通信18 3.1.5容器网络-容器间的通信18 3.1.6验证镜像的完整性和安全性19 3.1.7容器取证21 3.1.8跨容器的信任链22 3.1.9容器卷管理24 3.1.10容器秘密（Secret）管理26 3.1.11平台管理-生命周期事件通知27 3.1.12平台管理-资源请求27 3.1.13平台管理-容器资源管理28 3.1.14容器管理-容器资源伸缩28 3.1.15容器管理-数据备份与复制29 3.1.16容器管理-不同容器管理平台主机间容器迁移31 3.1.17容器加密31 附录A-缩略语33 附录B-词汇表34 附录C-参考36 内容提要 根据NISTSP800-180中的定义，应用容器和微服务架构用于设计、开发和部署应用程序。因为利用了敏捷的软件开发方法，如DevOps，所以应用组件的安全需要纳入软件全生命周期中考虑。NIST800-160系统安全工程，定义了基于广泛利益相关者需求的值得信赖的安全系统需求。 本文旨在成为《保护应用容器和微服务所面临的挑战》文档的配套文档。《保护应用容器和微服务所面临的挑战》文档从开发者、运营者和架构师的视角定义了保护应用容器和微服务所面临的挑战，而本文则提供了应对挑战的建议和最佳实践。 本文包含的建议和最佳实践源自信息安全、运营、容器开发和微服务方面拥有丰富知识和实践经验的不同团队的广泛合作。这些建议和最佳实践是面向开发者、运营者和架构师的。 1介绍 1.1目的和范围 本文目的是提供实现安全应用容器架构的最佳实践和建议，适用于各种角色，包括开发者、运营者和架构师。保护DevOps的安全要求安全人员、开发者和运营者协同工作，设计出值得信赖的安全系统。 此文的范围仅限于应用容器。 1.2文档结构 此文档由以下部分和附录组成： 第2节介绍应用容器 第3节总结保护应用容器安全的建议和最佳实践 附录A提供此文档中常见缩略词 附录B提供从文档中选出来的词汇表 附录C提供此文档中引用的文献列表 1.3读者 此文档面向应用开发者、应用架构师、系统和安全管理者、安全项目经理、信息系统安全官和其他相关责任人或对软件开发生命周期中的应用容器安全感兴趣的人员。 本文假设读者具有一定操作系统、网络和安全方面的专业知识，以及应用容器、微服务和敏捷应用程序开发方法(如DevOps)方面的专业知识。由于应用容器技术不断变化的特性，我们鼓励读者利用其他资源(包括本文中列出的资源)获取更新的更详细的信息。 2应用容器 正如在《保护应用容器和微服务的挑战》一文所述，利益相关方的责任是保护所有的应用容器和微服务，而这些容器和服务具有独特的特质，因而会带有不同的安全后果。因此，应用容器和微服务的特质给开发者、运营者和（微服务的）架构师所带来的挑战已被识别。最佳实践中存在的其他挑战在下表列出。 表1-应用程序容器的最佳实践 3.1.1跨环境（开发、质量保证、测试、生产）的代码提升 最佳实践视角 开发者应该建立信任基本源。开发者 运营者应利用容器管理平台安全地跨环境移动镜像。 运营者 3.1.2主机安全 必须通过容器技术（例如标签）记录多租户或敏感数据需求，允许自动化部署和审计容器。 运营者 容器运行时与远程服务（容器仓库、容器编排）间必须使用加密通信。 运营者 除非绝对必要，容器不能运行在特权模式下。运营者 除非绝对必要，容器运行时仅允许容器内部挂载数据卷（例如不挂载/proc、/etc、运行时套接字等）。 运营者 用户应移除所有功能，仅显式保留进程必需项。使用白名单而非黑名单机制。 运营者 3.1.3平台或宿主机侧的容器持续监控 开发者需要使用清晰的版本模式识别运行容器开发者 中的应用程序版本。 运营者应配置容器运行时向中心化日志系统传输日志。 运营者 对于运营者，监控服务的容器不能运行在特权模式下，也不能访问宿主机。 运营者 3.1.4容器网络：宿主机与容器通信 建议应用程序使用安全的网络通信协议。开发者/运营者运营者应提供鉴别和鉴权的基础设施。运营者 运营者应提供网络监控的基础设施。运营者 3.1.5容器网络：容器间通信 应用程序必须使用安全的网络通信协议。开发者/运营者运营者必须提供鉴别和鉴权的基础设施。运营者 运营者必须提供网络监控的基础设施。运营者 运营者必须使用容器化解决方案支持不同粒度的开放服务访问控制。 运营者 3.1.6验证镜像的完整性和安全性 开发者应在镜像构建过程中对镜像签名，并在使用前验证镜像。 开发者 开发者应在开发过程中使用漏洞扫描工具。开发者/运营者开发者应在镜像中仅包含必要的组件。开发者 运营者应在基础设施设计中确保仅允许使用已签名和已验证的镜像。 运营者 运营者应在基础设施设计中保障可持续识别新运营者 公布的漏洞。 3.1.7容器取证 对于新应用程序，开发者应在计划和设计阶段建立和保持包含日志功能在内的编码策略。 开发者 对于现有应用程序，开发者应实现捕获应用程序日志（从鉴别日志开始）的计划。 运营者 运营者应将容器环境的取证功能引入规划。运营者 对于新的基础设施，运营者应实现规划好的取证功能。 运营者 对于现有的基础设施，运营者应从捕获数据（即网络流量、磁盘和内存数据）开始，迭代输出新的功能。 运营者 3.1.8跨容器信任链 开发者应确保镜像签名是构建镜像过程的一部分，并在使用前验证镜像。 开发者/运营者 开发者应在开发过程中使用漏洞扫描工具开发者/运营者开发者应确保在镜像中仅包含必要的组件。开发者 运营者应根据3.1.6(验证镜像的完整性和安全性)的建议，设计镜像完整性校验、漏洞扫描和修补漏洞的基础设施。 运营者 运营者应使用安全加固过的、安全配置过容器引擎的可信宿主机存储镜像或运行容器。 运营者 运营者应使用鉴别和鉴权机制（即双向认证的TLS），确保容器间、容器与管理平台间的可信通信。 运营者 运营者应基于用户角色限制容器和镜像的访问。 运营者 运营者应监控容器配置参数和运行时的完整性。 运营者 3.1.9容器卷管理 开发者应得到足够的培训，确保开发应用程序时尽可能不出现使用共享容器卷和非必要的宿主机目录访问。 开发者 运营者应提供支持资源管理、访问控制和监控容器卷的基础设施。 运营者 运营者应提供隔离不同用户和不同应用程序间网络通信的基础设施。 运营者 运营者应提供接口支持同一实体（如工作负载）的容器间通信。 运营者 3.1.10容器密钥管理 为开发者提供培训和最佳实践指南。开发者 为开发者建立通用软件库，处理后端应用程序代码中的敏感数据和密钥。 开发者 运营者应通过集成部署工具或脚本，以及容器编排工具设计密钥管理架构。 运营者 3.1.11平台管理—生命周期事件通知