关键信息基础设施上云安全指南（下）

笔者在上一篇中，详细介绍了云安全建设重点、安全防护策略、以及如何构建先进云安全能力框架。

为了帮助组织机构在构建自身云安全解决方案的时候，选择更适合自己的解决方案。本文，提出了一个以容器为中心的CWPP方案评估框架标准，整体包括14大类别，每个类别包含必备项和首选项。必备项是指提供云原生全生命周期保护必须具备的能力。首选项是指用于区分最佳解决方案和普通解决方案的标准依据。

必备项：提供云原生全生命周期保护必须具备的能力。

首选项：用于区分最佳解决方案和普通解决方案的标准依据。

CWPP包括安全监控功能，并将警报和安全信息传递给第三方操作服务，以支持安全操作团队成功修复安全问题。

• 电子邮件警报：CWPP必须提电子邮件、短信的告警功能，以进行基础级操作告警。

• 数据导出与SIEM集成：CWPP必须提供数据导出功能，并与SIEM系统集成。

• Webhook集成：提供通过Webhook与自定义解决方案或处理管道进行集成的能力，以实现可扩展性。

（2）首选项

• 可操作事件或高风险事件的过滤视图：能够使用可定制的标准来过滤和呈现高风险事件和突发事件。

• 即时通讯告警和聊天系统集成：CWPP应该提供通过即时通讯和聊天通讯系统发送警报的能力。

• 映射到ATT&CK框架：安全事件应该映射到ATT&CK框架，为告警和报告提供潜在的威胁上下文。

（1）必备项

• 验证和确定镜像扫描结果的优先级：必须包含一个为容器镜像或镜像仓库安全全问题分配责任人和以及补救责任的机制。

• 验证基线审计的结果并确定优先级：必须包括一种机制，为工作负载和集群配置中的基线或基线违规的情况分配所有权，例如对CIS基线进行审计。

• 运行容器中验证和确定安全风险的优先级：必须包含在实例化容器中检测到的，或由于新报告的cve或环境漂移导致的工作负载的安全问题分配所有权和补救责任的机制。

• 与第三方漏洞管理或ITSM的集成：应支持与第三方治理、风险和合规性(GRC)、IT服务管理(ITSM)或漏洞管理平台的集成。

• 用于修复的本地工作流：应该提供一个修复工作流引擎，通过解决方案来跟踪安全问题。

• 修复指导：提供关于如何纠正潜在安全问题的指导，例如引用不易受攻击的依赖关系、更新容器运行时组件或强化集群配置。

K8S是目前大多数组织所选择的容器编排引擎，它使得企业可以快速采用容器工作负载。

• 审计IAM的权限和角色：K8S平台或云服务商中的身份和访问管理(IAM)原则对于控制谁拥有只读访问权限或管理访问权限至关重要。CWPP必须能够识别对K8S资源的过度许可访问。

• 审核命名空间：审核K8S集群中定义不当或过度允许的命名空间。

• 审核配额：对K8S集群中定义不当或过于允许的配额进行审核。

• 审计资源限制：对K8S集群中定义不当或过度允许的资源限制进行审计。

• 支持K8S的CIS基线：可以根据K8S的CIS基线来审计K8S环境的配置。

• 检测针对kube-apiserver的攻击：kube-apiserver负责控制K8S集群中的大部分内容，包括配置、启动和终止。容器CWPP必须能够检测到针对kube-apiserver的攻击。

• 检测针对etcd的攻击：etcd 通常用于存储敏感的信息片段。因此，它成为攻击者寻求攻击K8S集群或其他集成系统的主要目标，CWPP必须能够检测到针对etcd的攻击。

• 检测对K8S的攻击：CWPP必须能够检测到对K8S的攻击。

• 检测对kube-scheduler的攻击:kube-scheduler是一个控制平面组件，负责将pod匹配到最佳可用的工作节点。因此，CWPP还必须检测针对kube-scheduler的攻击。

• 检测对kube-proxy的攻击：kube-proxy在集群中的每个工作节点上运行。它促进了与K8S集群中的pods的入站网络通信。因此，CWPP必须能够检测针对kube-proxy的攻击。

• 检测针对kube-controller-manager的攻击：kube-controller-manager是另一个控制平面组件，负责管理集群中的许多默认控制循环进程，因此，CWPP还必须检测针对kube-controller-manager的攻击。

• 与现有K8S准入控制器集成：CWPP与现有的K8S准入控制器集成，用于审计和执行，而不用依赖于集群中的专有代理。

• 集成K8S审计日志：CWPP接收K8S API审计日志，以检测有风险或异常的活动，例如在配置图中存储凭据或使用节点端口公开服务。

• 防止针对API服务器的攻击：当检测到针对K8S API服务器的攻击时，CWPP允许自定义响应操作，除了通知或警报。

• 防止针对etcd的攻击：当检测到针对K8S etcd服务的攻击时，CWPP允许自定义响应操作，除了通知或警报。

• 防止针对K8S的攻击：当检测到工作节点上针对K8S 的攻击时，CWPP允许自定义响应操作，除了通知或警报。

• 防止针对kube-scheduler的攻击：当检测到针对kube-scheduler的攻击时，CWPP允许自定义响应操作，除了通知或警报。

• 防止针对kube-proxy的旁路：当检测到针对工作节点上的kube代理实例的攻击时，CWPP允许自定义响应操作，除了通知或警报。

• 防止针对kube-controller-manager的攻击：当检测到针对kube-controller-manager的攻击时，CWPP允许自定义响应操作，除了通知或警报。

（2）首选项

• 审计K8S网络策略：K8S网络策略使用容器网络接口(CNI)插件来控制K8S集群中的服务流量。CWPP应该能够审核定义不正确或过度允许的K8S网络策略。

• 审计K8Spod安全策略：K8S以pod安全策略(PSP)的形式为工作负载提供了一种安全机制。CWPP应该能够审核定义不正确或过度允许的psp。

• 审核Helm图表：CWPP代理连接到Helm包管理器，提供了审计Helm图表的漏洞或错误配置的能力。

• 审计操作员框架包：CWPP代理连接到K8S操作员存储库，如OperatorHub.io，提供审计操作员框架包的漏洞或错误配置的能力。

• 在Kubernetes-native格式中定义设置:CWPP策略和配置直接定义为K8S-native YAML，并提供导出到本地格式的能力。

• 部署自定义准入控制器：CWPP部署自定义资源和自定义准入控制器，用于审计和执行，而不用依赖于集群中的专有代理。

• 使用K8S元数据映射漏洞和运行时事件：CWPP映射K8S中每个应用程序和命名空间的安全发现，以帮助分类。

由于应用程序和基础设施是容器化的，它们也被代码化，理想情况下是不可变的。因此，可以以编程方式审计容器镜像、IaC和策略作为代码(PaC)，以确保符合基线、硬性标准或自定义组织标准。

（1）必备项

• 违反基线或环境漂移的警报：当一个正在运行的容器偏离原始镜像、部署清单或IaC时，CWPP可以通过电子邮件、短信其他机制发出警报。

• 对易受攻击的容器引擎和运行时发出警报：当容器和容器编排引擎、运行时和其他控制平面组件存在已知漏洞时，CWPP可以通过电子邮件、短信其他机制发出警报。

• 支持Docker的CIS基线：CWPP可以根据Docker的CIS基线来审计容器环境的配置。

（2）首选项

• 包括一个触发IaC审计的API：除了定期扫描容器基础设施和容器启动以遵守基线之外，CWPP还可以通过API触发IaC扫描，以支持作为Git提交或CI/CD构建的一部分的扫描。

• 映射到GDPR：CWPP将安全基线配置映射到通用数据保护法规(GDPR)。

• 映射到HIPAA：CWPP将安全基线配置映射到HIPAA中。

• 映射到HITRUST：CWPP将安全的基线配置映射到HITRUST。

• 映射到NISTSP800-53：CWPP将安全基线配置映射到美国国家标准与技术研究所(NIST)特别出版物(SP)800-53。

• 映射到NISTSP800-190：CWPP将安全基线配置映射到NISTSP800-190，作为容器安全标准。

• 映射到NISTSP800-204：CWPP将安全基线配置映射到NISTSP800-204，作为一个微服务体系结构标准。

• 映射到NISTSP800-204A：CWPP将安全基线配置映射到NISTSP800-204A，作为在服务网格上运行微服务体系结构的标准。

• 映射到PCIDSS：CWPP将安全基线配置映射到支付卡行业数据安全标准(PCIDSS)。

CWPP需要以某些方式部署，以便了解容器工作负载和容器化环境。

（1）必备项

• 非内核代理：CWPP通过与容器引擎的集成而在主机上部署（即，每个主机有一个特权代理或容器）。

• 非内核用户模式检测：CWPP通过用户模式检测进行部署（即，每个主机有一个非特权容器或代理）。

（2）首选项

• Kubernetes Daemon设置：CWPP在每个节点的pod中，为K8S集群中的所有容器提供检测和执行。

• 通过HelmHelm图表部署或 Kubernetes操作员进行部署：操作员使用所提供的脚本和编码接口来扩展和自定义侧板、删除集、允许控件和其他组件的部署。

虽然通用监测也是一个非安全主题，但跟踪、日志记录、监视和可观察性机制本质上是容器安全产品的一部分。

（1）首选项

• 公开Prometheus端点：CWPP公开Prometheus端点，并通过其他非安全指标的发现和收集机制进行查询，以获取关于容器配置、性能和可用性的数据。

• 支持Grafana集成：CWPP与Grafana本地集成，以提供通用的仪表板和指标。

为了深入了解安全配置并帮助进行保护和修复，CWPP需要与各种容器平台服务集成。

（1）必备项

• 支持与OCI兼容的运行时：CWPP提供了与容器、CRI-O、Docker、runC和其他与OCI兼容的运行时的集成，以控制大多数容器平台的运行时安全性。

工作负载保护服务需要具有管理功能。这些功能包括支持自定义和通过API进行访问的服务。

（1）必备项

• 支持API的管理(REST或GraphQL)，具有完整文档化的API目录：API可用于启用远程配置，并从其他安全和DevOps工具管理、设置和更改容器平台上的安全策略。

• 在CSV中导出原始数据：来自CWPP的原始数据必须以CSV格式提供，以便导入其他安全系统。

• 导出报告：在GUI中生成的所有安全状态报告必须是可导出的。

• 具有容器元数据、安全事件和其他数据的搜索功能：所有的资产、配置和操作数据都必须能够进行搜索。

• 支持活动目录进行身份验证和授权：CWPP可以从Microsoft活动目录继承角色和组分配，并在容器CWPP管理界面中分配权限。

• 支持LDAP进行身份验证和授权：可以使用轻量级目录访问协议(LDAP)从外部身份提供者继承角色和组分配，并相应地在容器CWPP管理接口中分配权限。

• 支持SAML for SSO：使用SAML和兼容的服务，如Auth0、Okta和Ping标识，在容器CWPP管理界面中启用单点登录(SSO)。

• 支持RBAC进行授权：在CWPP管理界面中提供一个RBAC机制，以限制谁可以读取或修改配置、安全策略、漏洞数据等。

• 使用统一的、与云无关和与平台无关的控制界面：具有统一的安全管理界面进行安全管理操作。

（2）首选项

• 管理CLI：必须提供命令行（CLI）访问，以支持配置和管理、设置和更改容器平台上的安全策略。

• 合规性报告：在默认情况下生成合规性报告，如GDPR、HIPAA、NISTSP800-190 和PCIDSS。

• 可定制的指标：所提供的任何指标都应该是可定制的，以允许用户根据需求求进行调整。

• 针对构建中的容器威胁进行可定制的风险评分：任何构建时风险评分都应该是可定制，以允许根据客户需求进行调整。

• 为交付中的容器威胁进行可自定义的风险评分：所提供的任何交付时间风险评分都应该可定制，以允许根据客户需求进行调整。

• 在运行时对容器威胁进行可自定义的风险评分：运行时风险评分应该可定制，以允许根据客户端需求进行调整。

• 能够通过API导出原始数据：API访问原始数据，应该允许导出到第三方供应商的安全解决方案。

• 持久的自定义搜索：应该存储自定义搜索，这样就可以快速复制潜在的大型复杂搜索条件。

• 关于提高安全性的建议：应提供基于风险的建议，以便用户能够快速识别和确定补救活动的优先级。

容器的工作负载必须与生产群集中的主机上的其他工作负载进行通信。CWPP通常提供许多网络安全机制来监控和控制容器级的网络通信。

（1）必备项

• 提醒异常通信模式：CWPP检测和警报异常或未经授权服务间或服务内容器的通信。

• 跨集群和跨云网络授权：属于同一逻辑应用程序的工作负载可以在不同的集群、区域或云中实例化。因此，网络隔离规则必须同步，确保在工作负载被实例化时都要遵循限制，以保持网络访问控制和最小化用户干预。

• 在使用静态策略的容器集群内使用微隔离功能：CWPP提供了一种机制，它可以基于静态策略来隔离容器流量。

• 服务流量可视化：为容器级流量（服务间和服务内）、控制平面和数据平面通信以及集群的进入/出口提供一个可视化引擎。

（2）首选项

• 对暴露的服务进行警报：对服务在容器化环境之外暴露时进行检测和发出警报，特别是当这种暴露违反了其他容器限制和访问控制时。

• TLS证书的审核：审核用于传输层安全(TLS)通信的证书，包括密钥大小、签名权限、根证书颁发机构、中间证书颁发机构和其他可自定义的参数。

• 审计TLS配置：审计TLS和相互TLS(mTLS)配置，如密码套件和协议版本。

• 捕获和保留服务通信的能力：CWPP记录所有容器网络流量，如源IP地址、目标IP地址、主机名、协议和其他连接数据，以支持数字取证和事件响应。

• 基于容器第7层的下一代防火墙：CWPP使用预定义的规则，提供一个自定义规则引擎，用于限制应用程序级的容器流量。

• 使用动态策略在容器集群内的微隔离能力：CWPP提供了一种机制，可以基于异常的容器行为和服务通信动态地隔离容器流量。

• 强制执行mTLS或基于证书的身份验证：可以在容器化的环境中强制执行mTLS或强制执行基于证书的身份验证，以保护服务通信。

• 能够从流量可视化视图和生产流量中生成微隔离规则：CWPP提供了基于实时容器流量和生产服务通信来创建或自定义规则的能力。

• 与第三方微隔离的集成：CWPP与第三方微隔离产品的集成，而不是在容器CWPP中使用专有的机制或基于代理的方法。

• 集群之间或非容器化架构之间的微隔离能力：CWPP可以控制进出容器集群的网络流量，而不是仅仅在容器化环境中。

• 网络库存：CWPP提供了在给定的日期内检查所有网络端点、服务、pod和容器以及它们各自的通信的能力。

• 微隔离规则建模：CWPP可以在生产集群部署之前，对网络安全规则的创建或修改的影响进行建模。

• 流量可视化显示微隔离规则：可视化引擎显示对于给定的工作负载和容器的入站/出站通信情况，并验证采用的容器网络安全策略是否有效。

Secrets管理功能提供了加密安全的存储机制和API，因此工作负载可以无缝连接并获取它们需要的Secrets。容器CWPP可以作为其他Secrets管理工具的代理，或者由其他工具履行这个角色.

（1）首选项

• 对不遵守Secrets调取规则的容器进行审计：CWPP会持续监视工作负载，以确保它们遵守调取Secrets的请求。理想情况下，它还应该终止不符合规则的Secrets调取请求的工作负载。

• 审计容器镜像中嵌入的Secrets：CWPP在构建时和交付时审计容器镜像，以确保它们不包含硬编码或嵌入的Secrets。

• 对IaC中嵌入的Secrets进行审计：CWPP在构建时和交付时审计IaC，以确保它不包含硬编码或嵌入的Secrets。

• 与 Kubernetes Secrets/etcd集成：CWPP提供了与由etcd支持的原生K8S Secrets机制的简化集成。

写在最后

-完-