随着数字经济时代到来,云计算、大数据、物联网等新兴技术在关键信息基础设施领域深度应用,数字技术已经成为企业转型和发展的关键要素,而云是企业数字化转型的基础支柱,也是企业的首要技术重点。我国在十四五规划中,将云计算作为数字经济重点产品之首,要求加快数字化发展,建设数字中国,实施“上云用数赋智”行动。在数字化转型不断加深的大背景下,越来越多的关键信息基础设施正在将数据和应用程序迁移到云中。同时,新基建也推动了大量云化基础设施采用了云原生的技术路线。如图1所示,关键信息基础设施在经历信息安全时代后,进入数字网络“云安全”时代。

图1 关键信息基础设施网络安全发展

随着关键信息基础设施上云步伐加速,云上安全问题也更加广泛和突出。调研显示,云计算所面临的挑战中,安全问题排在首位。

图2 云计算安全问题突出

关键信息基础设施云安全建设重点

满足监管合规要求

随着《网络安全法》、《数据安全法》、《网络安全审查办法》和《关键信息基础设施安全保护条例》(以下简称《条例》)的颁布,关键信息基础设施云上安全得到空前重视。随着《条例》的实施,现有承载着能源、交通、水利、金融、公共服务、电子政务等重要行业应用的云计算服务平台,将越来越多地纳入到关基安全管控范畴当中,云服务提供者及其客户将面临常态化的合规监管约束。根据《条例》第十二条要求,“安全保护措施应当与关键信息基础设施同步规划、同步建设、同步使用”,实现“安全三同步”建设,同时具备安全职责明晰、制度完善、落实有力的安全运营管理机制,并将云安全能力建设融合到DevSecOps研发运营一体化工作中,实现敏捷开发。同时参照《信息安全技术 关键信息基础设施安全保护要求》等标准,关键信息基础设施安全保护制度应建立在网络安全等级保护体系基础上,着眼分析识别、检测评估、监测预警、事件处置、主动防御等重点活动的建设,围绕关键信息基础设施网络安全风险识别到事件处置进行闭环管理。依据相关政策标准要求,梳理关键信息基础设施安全保护框架,如图3所示。

图3 关键信息基础设施安全保护框架

通过框架内容可以发现,关键信息基础设施网络安全需要建立起分析识别、检测评估、监测预警、事件处置、主动防御的立体化安全保护体系,在满足合规要求的基础上,打造实战化防御能力。

  • 分析识别围绕关键信息基础设施承载的业务,开展业务识别、资产识别、风险识别等活动,为后续环节开展工作打下基础;
  • 检测评估对安全防护环节的安全措施有效性进行验证,定期开展相关核查活动;
  • 监测预警制定实施网络安全监测预警制度,及时对安全事件做出响应;
  • 事件处置对网络安全事件进行报告和处置并采取相应的应对措施。
  • 主动防御在减少暴露面的同时,采取诱捕、溯源、干扰和阻断等措施主动发现网络攻击事件;

新的基础设施需要新的安全防护

随着越来越多的关键信息基础设施云化,云数据中心数据、算力集中,云上威胁加剧。对组织机构数据和业务影响比较大的威胁,诸如数据勒索、数据丢失、数据泄露等,成为云上安全威胁的关注重点。云计算专属安全问题主要集中在hypervisor层的安全威胁、虚拟资源的隔离机制变化和虚拟机的安全威胁等方面。根据调查显示,关基行业最关切的12个云安全风险如图4所示。针对这些威胁风险,关键信息基础设施企业需要建立新的、有效的安全解决方案。

图4 12大重点云安全风险

行业需求的不断变化、业务规模的持续上涨,促使各行业积极寻求变革、拥抱新技术。云原生作为构建云上业务应用的最优模式集合,提供计算、编排、存储、安全、可观测等灵活多样的技术方案,已成为云上业务技术选型的优先项。银行业从传统网点模式走向互联网金融模式,制造业依托工业互联网走向“智造”,交通业大力推广“智慧交通”走向真正的互联互通。云原生在行业转型升级过程中提供众多可灵活组合的标准能力,呈现降本增效、弹性伸缩、敏捷迭代、高可用性等多重价值。与此同时,随着云原生技术的进一步普及,伴随而来诸多全新的安全性问题,如图5所示。例如,镜像风险、微服务风险、基础设施风险等。因此关键信息基础设施需要新的云安全解决方案。

图5 新的云原生安全风险

构建先进云安全能力框架

依托《关键信息基础设施安全保护条例》,并参照《信息安全技术 关键信息基础设施安全保护要求》等标准,本着解决关键信息基础设施面临的新安全风险的目标,需要围绕关键信息基础设施打造特殊保护、整体防控、动态防护、联防联控、主动防御、精准防护、纵深防御的安全体系。

建设思路

不同环境场景下关键信息基础设施所面对的安全威胁呈现动态变化,需要根据关键信息基础设施的业务特点、网络特征及面临的安全威胁,构建动态的风险监测和安全防护措施,形成动态的安全防护机制。所以关键信息基础设施云安全建设思路在遵循合规要求、全栈覆盖、自适应安全、可视化运营四大准则的基础上,通过完整识别出云平台信息化各个层次,将安全能力与云基础设施、虚拟机、容器、云服务、云应用、云数据相结合,实现安全能力对云平台的深度结合、全面覆盖,做到安全自适应,如图6所示。

图6 云安全解决方案建设思路

整体能力框架

云计算平台从基础设施层面的计算环境到云端应用的开发部署模式一直在快速发展演进。以云原生技术为代表的新技术的应用,不断引入各类新型安全风险,“安全边界”的定义方式随着系统技术架构的演进“悄悄”发生着变化。为了打造内、外部综合防护的安全能力,实现关键信息基础设施云安全的动态防护,强化覆盖整个业务链、供应链的应急响应能力,关键信息基础设施云安全整体能力框架,应在打造云安全运营体系的基础上,围绕云安全管理体系、技术体系、合规监管体系,提供全栈式安全产品与服务,满足重点行业、关键领域的业务安全需求,整体能力框架如图7所示。

图7 云安全整体能力框架


关键信息基础设施云安全解决方案要求

关键信息基础设施网络安全事关国家安全、社会安全,亟待构建与数字化业务融合的新型网络安全体系。云计算模糊了传统的安全边界,安全建设前移将成为趋势,安全攻防的复杂程度也大大增加。伴随着云原生技术的应用,除了增加的复杂性之外,云原生化工作负载在整个生命周期中出现了许多新的威胁向量,如容器镜像漏洞、嵌入的密钥、配置错误或公开的服务、易受攻击的容器运行时等。专注于保护容器化工作负载和K8s的云工作负载保护平台(CWPP),成为保护组织云原生安全的关键。

然而每个组织都有自己的要求和优先级,为了使组织能够选择适合自己的解决方案,下面提供了一个评估以容器为中心的CWPP的框架标准,整体包括14大类别,每个类别包含必备项和首选项。必备项是指提供云原生全生命周期保护必须具备的能力。首选项是指用于区分最佳解决方案和普通解决方案的标准依据。

1、镜像扫描

为了保护容器安全,软件成分分析(SCA)工具需要解析容器镜像格式,并分析正在运行的工作负载,以便准确地扫描和报告漏洞。

(1)必备项

  • 推送镜像时在镜像仓库中扫描:当镜像推送或存储到镜像仓库时,CWPP可以扫描容器镜像以识别已知的漏洞。
  • 拉取或编排中的扫描CWPP作为容器交付或容器编排的一部分进行扫描,以识别已知的漏洞。
  • 连续扫描运行的容器扫描实例化的容器或运行的工作负载,以识别新报告的或环境漂移导致的已知漏洞。
  • 显示容器镜像和正在运行的容器中的特定漏洞如果发现新的CVE,CWPP会显示该漏洞存在于哪些镜像或正在运行的容器和相关镜像层中。

(2)首选项

  • 支持获取第一手漏洞研究和威胁情报CWPP可以通过基于内部研究的额外漏洞信息来增强NVD和CVE报告。
  • 分析镜像元数据:可以扫描标签、镜像配置、相关的文档文件、针对已知问题或敏感数据类型的环境变量和其他元数据。
  • 包括一个可以触发镜像扫描的API或Webhook:提供一个WebAPI或Webhook,可以根据需要调用镜像扫描。
  • 包括一个API或webhook来触发镜像扫描并返回扫描结果,作为在CI/CD内的构建和部署的一部分:提供一个web API或webhook来调用镜像扫描,作为连续集成/连续交付(CI/CD)的一部分并返回可以作为构建管道的一部分进行编程解析的结果。
  • 识别镜像层次结构和所属方:CWPP可以区分镜像层层次结构和传递依赖中的漏洞,它还可以跟踪基本镜像和镜像层的来源。
  • 识别存在漏洞的镜像层:CWPP需要详细说明文档文件中引入漏洞的相应层。
  • 通过相应的策略引擎对容器构建管道进行控制:CWPP具有预定义的规则和相应的策略引擎,用于控制容器构建和交付。
  • 通过相应的策略引擎对容器实例化进行控制:CWPP提供预定义规则和相应的策略引擎阻止易受攻击的容器镜像实例化为容器实例的能力。
  • 突出显示具有已知漏洞的组件:CWPP显示的容器镜像和运行的容器,可以通过更新的依赖项、修补程序或文档化的代码进行修复。
  • 突出显示具有可用修复程序的已知漏洞的组件:CWPP可以通过更新的容器镜像和运行时容器补丁或文档化的代码修复进行漏洞修复。
  • 突出显示具有已发布漏洞的组件:CWPP可以显示容器镜像和运行时容器当前容易受到的攻击或基于公共脆弱性评分系统(CVSS)给出的威胁分析指标。
  • 启用与SaaS断开连接的本地镜像分析:CWPP提供了直接在CI/CD管道或容器镜像仓库中进行扫描的能力,而无需在数据中心环境或私有云之外共享镜像内容
  • 提供关于已知漏洞的攻击向量细节:CWPP公开了关于漏洞如何被潜在利用的信息,这有助于确定优先级。
  • 支持沙箱扫描:CWPP可以在一个孤立的非生产环境中实例化一个容器,并观察正在运行的容器,从而发现在启动后和运行期间出现的漏洞。
  • 支持容器镜像仓库的预定扫描:可以按照定制的时间计划扫描容器镜像仓库。
  • 扫描有效容器镜像以确定已知的漏洞:CWPP扫描有效镜像(即给定容器的所有镜像层)并报告漏洞。
  • 使用CVE和NVD之外的其他第三方漏洞源:CWPP使用其他漏洞源,如SontatypeOSS索引或VulnDB。
  • 基于镜像和镜像仓库元数据验证镜像完整性:CWPP比较镜像仓库路径和镜像名称,以识别社工攻击。
  • 使用哈希验证镜像的完整性:CWPP确保运行的容器的哈希与镜像的哈希匹配,以识别社工攻击。
  • 使用签名验证镜像完整性:CWPP确保运行的容器的数字签名与镜像的数字签名匹配,以识别社工攻击。
  • 支持对易受攻击的镜像进行虚拟补丁:CWPP以代码修复或更新的容器镜像依赖关系的形式,为已知的漏洞提供可支持自定义策略的缓解机制。

2、镜像仓库支持

容器镜像作为典型的DevOps工作流的一部分被创建并存储在镜像仓库中。容器CWPP与给定的容器镜像仓库集成的能力,对于确保整个生命周期的容器安全至关重要。

(1)必备项

  • OCI分发规范-符合镜像仓库的要求:CWPP集成了OCI分发规范并符合容器镜像仓库的文档要求。

(2)首选项

  • 对Amazon、Azure、Harbor、Jfrog等镜像仓库的支持:直接镜像仓库集成,以增强CWPP本身的功能。

3、容器运行时保护

容器运行时和容器编排引擎都是生产集群的攻击向量。CWPP必须能够连续监控运行时的活动,并在发生异常行为或攻击时做出反应。

(1)必备项

  • 支持应用程序或进程显示:可以监控容器工作负载行为和服务通信,并提供一个可视化引擎来帮助理解大规模的容器行为。
  • 支持应用程序或进程警报:当出现偏离自定义的安全策略或容器基线时,可以对系统调用、异常的容器工作负载行为和服务通信发出警报。
  • 支持应用程序的强制执行:当出现偏离容器基线或定制的安全策略时,可以对系统调用、异常的容器工作负载行为和服务通信采取纠正措施。包括阻止正在运行的容器中的特定操作,或使用容器编排引擎终止工作负载。
  • 阻止工作负载启动:阻止任何违反组织策略的工作负载的容器初始化。
  • 检查容器漂移:可以检测运行的容器是否偏离容器镜像源、支持的IaC或硬性合规标准。
  • 支持容器基线化和流量分析:可以记录给定容器工作负载的容器行为和服务流量,并通知不符合基线的异常行为。
  • 检测违法主机隔离策略行为:检测在没有适当隔离策略的情况下启动容器工作负载、与主机系统(如文件系统、命令行)交互或试图违反容器安全原则。
  • 检测到持久性存储的挂载:检测容器工作负载试图挂载可能导致安全问题的存储路径。
  • 检测特权容器和具有升级特权能力的容器:检测容器工作负载在使用特权标志启动时,是否以root身份主动运行或从用户模式请求提升特权。
  • 支持基于签名的恶意软件或防病毒扫描:扫描运行容器中基于已知签名的病毒或恶意软件。

(2)首选项

  • 检测异常行为:检测容器出现偏离已建立的(硬性的)基线或IaC定义的异常行为。
  • 基于自定义安全策略检查容器异常:CWPP将功能扩展到基本的漂移检测或违反基线的行为之外。此功能由一个策略引擎支持,该策略引擎具有可自定义的细粒度策略,可用于定义和管理容器行为。
  • 日志记录并控制容器内的交互式用户会话:当用户向正在运行的容器发出操作系统命令时,CWPP记录用户输入。
  • 支持基于机器学习或基于行为的恶意软件或防病毒扫描:通过分析流量、进程行为或其他属性,在没有签名帮助的情况下,扫描正在运行的容器中的病毒或恶意软件。

4、DevOps工具集成

容器镜像和相应的IaC的创建通常是通过DevOps支持工具来驱动。DevOps工具通常包括一组基于git的版本控制系统(VCSs)和代码存储库、工件存储库、持续集成和持续交付服务、应用程序开发生命周期管理(ADLM)和缺陷跟踪。

(1)必备项

  • 应用程序开发生命周期管理ADLM和缺陷跟踪支持:CWPP可以将安全发现(从镜像扫描或容器安全事件)导出到外部ADLM或缺陷跟踪系统,这样就可以使用标准的DevOps工作流来处理问题。

(2)首选项

  • 二进制或工件存储库支持:提供webhook或与二进制存储库的本地集成,以扫描编译的工件或推送到存储库的依赖项。
  • CI/CD支持:提供一个与CD服务集成的GUI,如CloudBeesJenkins、AWS代码部署或Azure管道。
  • 基于git的VCS支持:提供webhook或与基于git的VCS的本地集成,以扫描纯文本源代码和将代码提交到存储库中的IaC。

因此,云安全建设已然成为关键信息基础设施数字化转型升级的“刚性需求”,需要在做好顶层设计的基础上,选择适合组织自身需求的安全解决方案,打造主动防御、动态防御、整体防控和精准防护的安全体系,真正将关键信息基础设施云安全工作做实落地,实现关键信息基础设施网络安全的平战一体化。

5、安全监控

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

(1)必备项

  • 电子邮件警报:CWPP必须提电子邮件、短信的告警功能,以进行基础级操作告警。
  • 数据导出与SIEM集成:CWPP必须提供数据导出功能,并与SIEM系统集成。
  • Webhook集成:提供通过Webhook与自定义解决方案或处理管道进行集成的能力,以实现可扩展性。

(2)首选项

  • 可操作事件或高风险事件的过滤视图:能够使用可定制的标准来过滤和呈现高风险事件和突发事件。
  • 即时通讯告警和聊天系统集成:CWPP应该提供通过即时通讯和聊天通讯系统发送警报的能力。
  • 映射到ATT&CK框架:安全事件应该映射到ATT&CK框架,为告警和报告提供潜在的威胁上下文。

6、漏洞管理

容器CWPP提供了一系列的构建时、交付时和运行时安全功能,从而检测到容器镜像、镜像仓库、运行容器工作负载、集群的问题。因此,容器CWPP还必须提供漏洞管理能力。

(1)必备项

  • 验证和确定镜像扫描结果的优先级:必须包含一个为容器镜像或镜像仓库安全全问题分配责任人和以及补救责任的机制。
  • 验证基线审计的结果并确定优先级:必须包括一种机制,为工作负载和集群配置中的基线或基线违规的情况分配所有权,例如对CIS基线进行审计。
  • 运行容器中验证和确定安全风险的优先级:必须包含在实例化容器中检测到的,或由于新报告的cve或环境漂移导致的工作负载的安全问题分配所有权和补救责任的机制。

(2)首选项

  • 与第三方漏洞管理或ITSM的集成:应支持与第三方治理、风险和合规性(GRC)、IT服务管理(ITSM)或漏洞管理平台的集成。
  • 用于修复的本地工作流:应该提供一个修复工作流引擎,通过解决方案来跟踪安全问题。
  • 修复指导:提供关于如何纠正潜在安全问题的指导,例如引用不易受攻击的依赖关系、更新容器运行时组件或强化集群配置。

7、K8S的集成和功能

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

(1)必备项

  • 审计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中每个应用程序和命名空间的安全发现,以帮助分类。

8、基础设施安全

由于应用程序和基础设施是容器化的,它们也被代码化,理想情况下是不可变的。因此,可以以编程方式审计容器镜像、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)。

9、部署模式

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

(1)必备项

  • 非内核代理:CWPP通过与容器引擎的集成而在主机上部署(即,每个主机有一个特权代理或容器)。
  • 非内核用户模式检测:CWPP通过用户模式检测进行部署(即,每个主机有一个非特权容器或代理)。

(2)首选项

  • Kubernetes Daemon设置:CWPP在每个节点的pod中,为K8S集群中的所有容器提供检测和执行。
  • 通过HelmHelm图表部署或 Kubernetes操作员进行部署:操作员使用所提供的脚本和编码接口来扩展和自定义侧板、删除集、允许控件和其他组件的部署。

10、通用监测

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

(1)首选项

  • 公开Prometheus端点:CWPP公开Prometheus端点,并通过其他非安全指标的发现和收集机制进行查询,以获取关于容器配置、性能和可用性的数据。
  • 支持Grafana集成:CWPP与Grafana本地集成,以提供通用的仪表板和指标。

11、基础设施支持

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

(1)必备项

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

12、管理

工作负载保护服务需要具有管理功能。这些功能包括支持自定义和通过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访问原始数据,应该允许导出到第三方供应商的安全解决方案。
  • 持久的自定义搜索:应该存储自定义搜索,这样就可以快速复制潜在的大型复杂搜索条件。
  • 关于提高安全性的建议:应提供基于风险的建议,以便用户能够快速识别和确定补救活动的优先级。

13、网络安全

容器的工作负载必须与生产群集中的主机上的其他工作负载进行通信。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可以在生产集群部署之前,对网络安全规则的创建或修改的影响进行建模。
  • 流量可视化显示微隔离规则:可视化引擎显示对于给定的工作负载和容器的入站/出站通信情况,并验证采用的容器网络安全策略是否有效。

14、Secrets管理

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机制的简化集成。

写在最后

关键信息基础设施是经济社会运行的神经中枢,是网络安全的重中之重。电力、交通、能源、金融等关键基础设施皆与数字化挂钩,各种关键核心资产纷纷上云,虚拟空间与物理世界的边界逐渐消弭。因此,云安全建设已然成为关键信息基础设施数字化转型升级的“刚性需求”,需要在做好顶层设计的基础上,选择适合组织自身需求的安全解决方案,打造主动防御、动态防御、整体防控和精准防护的安全体系,真正将关键信息基础设施云安全工作做实落地,实现关键信息基础设施网络安全的平战一体化。