容器安全成熟度验证标准 Checklistsfor3-LevelContainerSecurityMaturity 容器安全成熟度验证标准 本报告针对以Docker为代表的容器解决方案，建立一个安全要求和控制框架，主要是解决 在规范设计、开发和测试的过程中所需的功能性和非功能性安全控制。该框架有2个核心 作用： 帮助组织机构的开发和运维确保容器的安全性。 帮助容器安全产品和服务供应商以及最终用户调整他们的产品和具体要求。 容器安全成熟度标准 容器安全成熟度可以分为3个层级，相关要求逐渐提升。 Level1（基础级安全）：适用于所有容器项目。 Level2（标准级安全）：适用于那些有额外安全保护需求的容器项目，例如需要处 理敏感数据或者业务逻辑。 Level3（高级安全）：适用于那些执行高价值交易、包含个人敏感数据的最关键容 器项目，或任何需要最高信任级别的容器。 不同层级的容器安全成熟度有不同要求列表（Checklist）。这些检查要求都可以映射到具体 的容器安全产品功能或能力上去，而这些能力是必须内置到容器中去的。 对于这个标准最佳实践是将其作为“挂图作战”看板，基于该标准创建适用于具体项目、平 台、组织的安全检查列表（Checklist）。根据自身企业情况，以及结合该容器安全标准成熟 度框架可以增强组织对于容器安全的认知。 检测标准：12个维度，100+Checklist 场景1：组织层面 除了技术控制之外，容器安全检查标准还要求流程到位，以确保在规划架构时就已明确要解 决的安全问题，并且所有组件的功能和安全规则都是已知的。 场景1，从组织层面列出了与容器解决方案的流程、架构和设计相关的要求。因此，此类别 无法映射到技术测试用例，而必须在流程级别上进行处理。但是，因每个组织的结构不同， 并且每个设置步骤都有不同的组织和流程要求，文本在组织层面控制要求，仅涵盖了一些基 本方面。 ÇàÌÙÔÆ°²È«容器安全成熟度验证标准 Checklistsfor3-LevelContainerSecurityMaturity 描述 L1L2L3 1.检查开发人员，尤其是负责DevOps的人员是否接受了相关的定期安全培 训。√√√ 2.检查管理人员是否接受项目中有关的安全方面的定期培训。 √ 3.检查所有处理的数据是否已经按照内部数据分类标准进行分类。 √√√ 4.检查每个应用程序都能提供其安全需求以及它们将如何解决的相关信息。 √√ 5.检查已知安全风险和漏洞是否已按预设的管理流程迅速消除并集中管理。 √√ 6.检查有关容器基础设施的规则和职责是否已明确，例如镜像的准入准出。 √√ 场景2：基础设施 不同行业的底层基础设施安全设置可能有所不同，但基础设施必须为上层提供所需的安全性。 确保经过安全验证的容器解决方案能够满足以下要求： 确保基础设施能够提供足够的资源。 加固包括容器平台在内的基础架构。 描述 L1L2L3 1.检查容器整体架构和设计，包括内部和外部网络。 √√√ 2.检查基础设施，包括其所有组件（节点、网络、容器等）是否已记录在案。√√√ 3.检查所使用组件都得到维护并相互兼容（OS、引擎、UCP、DTR等）。√√√ 4.检查是否为所有节点分配足够的资源以使其稳定运行。 √√√ 5.检查容器可用资源是否设定有限制。 √√ 6.验证SELinux或AppArmor是否已启用并在所有节点上运行。 √ 7.检查节点的Docker引擎是否定期自动更新和应用是最新版的。 √√√ 8.检查是否使用了允许回滚的灰度部署/发布策略。 √√ 9.检查容器的配置是否支持实时还原可用。 √√ 10.检查Docker的配置权限是否仅限于用户实际所需的访问。 √√√ 11.验证所有节点（包括操作系统）是否都定期经过自动安全扫描。 √√ 12.检查所有节点是否都使用了容器专用操作系统来代替通用操作系统。 √ 13.检查所有节点是否都使用了常规的加固操作。 √√√ 14.检查是否使用了Docker默认配置值（除非特殊申明）。 √√√ 15.检查是否已经尽可能限制node远程访问，包括SSH或RDP等。 √√√ 场景3：容器层面 容器解决方案核心部分就是应用容器。容器本身不仅仅包含了服务和应用逻辑，还包括与其 它系统或容器的交互，这个过程涉及诸多需要保护的敏感数据。确保经过检查验证容器安全 方案能够满足以下要求： 确保容器以最小权限运行。 加固容器内的服务并最小化攻击面。 利用容器技术自身的安全特性。 ÇàÌÙÔÆ°²È«容器安全成熟度验证标准 Checklistsfor3-LevelContainerSecurityMaturity 描述 L1L2L3 1.检查容器root权限（初始化过程除外，但在完成后应删除root权限）。 √√ 2.检查是否启用了用户命名空间。 √√ 3.检查是否在每个镜像中创建了新用户，并使用该用户执行容器内所有操作。 √ 4.检查那些有特定seccomp-profile配置文件，是否已应用于每个容器。 √ 5.检查容器在运行过程中是否被授予了其它额外权限。 √√√ 6.通过哈希值验证所有基础镜像，而不是基于名称或者标签。 √ 7.检查在进入生产环境之前，每个镜像签名是否已经被验证。 √ 8.检查镜像是否只安装了必须软件包。 √√√ 9.检查根文件系统是否设置为可读模式进行挂载。 √√ 10.检查那些特殊容器（例为了故障排除），是否已经删除并已替换为新容器。 √√ 11.验证Dockerfiles是否使用COPY指令而不是ADD指令，除非来源是可 信。√√√ 12.检查远程登录管理服务是否已禁用，包括但不限于SSH、RDP等。√√√ 13.检查公开服务（例如etcd）是否仅限于那些可信系统或经过身份验证系 统。√√√ 14.使用--pids-limit检查容器内允许进程数是否已限制为确定数值。 √ 15.检查容器未安装任何Dockersocket，除非它们用于监视或管理。如果 需要Dockersocket，检查是否设置为只读，并相应地限制容器的访问。√√√ 场景4：编排管理 当容器数量达到一定程度时，就需要一个编排管理工具。编排管理工具可以帮助管理、跟踪 正在发生的事情。由于编排工具是容器基础设施中不可缺少的一部分，因此编排工具的安全 级别将直接影响基础设施的所有其他方面。确保经过验证的容器安全解决方案能够满足以下 安全要求： 确保编排工具的正常运行时间。 对编排工具进行加固。 能够实现与编排工具自动化交互，避免人为错误。 描述 L1L2L3 1.检查编排管理节点是否已设置冗余，并能支持高可用性要求。 √√√ 2.检查部署管理器节点数是否为奇数，并且至少大于3。 √√√ 3.验证管理节点是否分布在多个数据中心和可用区。 √√ 4.检查管理节点是否会在启动自动锁定情况下运行。 √ 5.检查编排工具是否定期平衡活跃容器。. √√√ 6.检查管理器节点是否承担工作任务和运行容器。 √√√ 7.检查验证预定义的标签是否能够正确识别和管理所有资源。 √√ 8.检查是否已经删除那些不需要的容器。 √√ 9.检查同一个节点上运行的容器都拥有同样数据分类级别。 √ 10.验证同一个节点上运行的容器具有相同暴露面（比如面向互联网）。 √ ÇàÌÙÔÆ°²È«容器安全成熟度验证标准 Checklistsfor3-LevelContainerSecurityMaturity 场景5：镜像分发 容器运行的前提是构建镜像。镜像定义了容器运行的内容，包括软件包、版本号等。每个容 器的镜像安全对于确保容器安全运行至关重要。一个安全的容器解决方案至少需要满足以下 几个点： 加固镜像。 镜像内部没有存储敏感数据。 检查镜像是否存在易受攻击的组件。 描述 L1L2L3 1.检查镜像仓库数是否为奇数，并且至少大于3。 √ 2.检查镜像仓库是否启用了垃圾收集并能定期运行。 √√√ 3.验证所有镜像是否经过定期的自动化安全扫描。 √√ 4.检查验证容器是否始终是基于最新的镜像生成而不是本地缓存镜像生成。√√√ 5.检查所有镜像是否都有标签，并只允许生产/Master节点使用默认最新标 签。√√ 场景6：Secrets管理 生产系统通常包括诸多secrets资源，包括加密秘钥、用户名密码等。本节主要说明如何处 理此类敏感信息，确保经过验证容器安全解决方案能够满足以下条件： 保护敏感信息。 验证是否对加密信息进行安全处理。 定期轮换加密秘钥。 描述 L1L2L3 1.检查是否使用了RBAC模型来管理访问控制。 √√ 2.检查DockerContentTrust是否已启动并强制执行。 √ 3.检查是否使用DockerSecrets来处理API秘钥、密码等敏感信息，确认没 有将敏感信息存储在Dockerfile或者Docker-Compose中情况。√√√ 4.检查加入编排工具的密钥是否定期轮换。 √√ 5.验证如果启动自动锁定，检查自动锁定密钥是否定期轮换。 √√ 6.检查node节点证书是否定期更换。 √√ 7.检查CA证书是否定期更换。 √√ 8.检查用于生成内部集群间通信的相互TLS身份验证的CA证书。 √√ 9.检查使用的SSL/TLS证书是否经过验证。 √√√ 10.检查是否使用了Secrets管理安全解决方案处理Secrets对象。 √√ 场景7：网络安全 当下所有应用和服务都不可能单一独立的，通常都是通过网络连接进行交互，形成一个整体 的系统服务。网络安全是一个单独安全门类，但是容器技术会影响网络安全，那么在使用容 ÇàÌÙÔÆ°²È«容器安全成熟度