云原生安全从“边界防护”走向运行时治理：企业如何评估身份、工作负载与供应链风险？

过去，企业谈云安全，往往先看网络边界：互联网入口是否有防火墙，应用是否经过网关，内外网是否完成隔离。进入云原生环境后，这套思路仍然重要，但已经不足以覆盖真实风险。容器会动态创建和销毁，服务之间通过接口持续调用，身份权限可能跨越多个云账号与集群，代码和镜像还会经过复杂的软件供应链。安全边界因此从“哪里可以进入”扩展为“谁在访问、运行了什么、如何被部署以及运行时发生了什么”。

【软盟资讯·技术导读】云原生安全的核心变化，不是简单增加一套运行时安全产品，而是重新划分安全责任和治理对象。企业需要同时关注身份与访问管理、容器与工作负载、服务通信、软件供应链以及运行时行为，并将这些能力连接到统一的告警、审计和应急流程中。本文从架构决策出发，对比传统边界防护与运行时治理的差异，给出分阶段建设路径和选型判断依据。

一、为什么传统边界防护不再是完整答案

传统安全架构通常以网络位置为主要判断依据：外部流量先经过防火墙或网关，内部系统相对稳定，安全团队可以围绕固定资产、固定地址和固定出口建立规则。

云原生环境改变了这些前提。

一方面，工作负载具有较强的动态性。容器、服务实例和临时任务可能根据流量、发布策略或资源调度快速变化，IP地址和部署位置不再适合作为唯一的安全标识。另一方面，业务调用链被拆分为多个服务，单次请求可能跨越多个命名空间、集群、账号和云服务。即使流量没有离开云平台，也可能存在权限越界、服务冒用、配置错误或敏感数据被不当访问的问题。

更重要的是，风险不一定发生在网络入口。

• 一个权限过大的服务账号，可能在合法认证后访问超出业务需要的资源。
• 一个来源不清晰的镜像，可能在发布阶段通过了基础检查，却在运行时表现出异常行为。
• 一组配置不当的容器，可能没有明显的外部攻击流量，却暴露了不必要的管理接口。
• 一次正常的发布操作，可能将未经审核的依赖、镜像或基础设施配置带入生产环境。

因此，云原生安全的重点逐渐从“阻断未经授权的流量”，转向“持续验证身份、工作负载和行为是否符合预期”。

二、传统边界防护与运行时治理的四个差异

1. 责任归属：从安全团队单点负责转向共同承担

传统模式下，网络边界通常由安全团队或基础设施团队集中管理，业务系统主要负责提出访问需求。云原生环境中，安全责任被分散到应用开发、平台工程、基础设施、安全和运维等多个角色。

这并不意味着“所有人都负责，所以没人负责”。企业需要把责任拆成三个层次：

层次	主要责任	需要回答的问题
平台基础能力	云平台、容器平台、基础设施团队	集群、网络、身份、密钥和审计能力是否可靠
应用与交付过程	开发、测试、DevOps团队	代码、依赖、镜像和部署配置是否经过验证
业务运行治理	安全、运维、业务负责人	生产环境中的访问、行为和告警如何处置

平台团队不应替业务团队定义所有业务权限，安全团队也不应成为所有发布流程的人工审批瓶颈。更合理的做法是建立统一的控制基线，由平台提供默认安全能力，由应用团队承担业务权限和数据使用责任，再由安全团队负责策略、监测、审计和风险监督。

2. 策略落地：从网络规则转向身份、工作负载和行为

边界防护擅长回答“哪些地址可以访问哪些地址”。运行时治理还需要回答：

• 哪个身份在访问？
• 这个身份代表哪个应用或工作负载？
• 访问的资源是否与业务职责匹配？
• 当前行为是否符合该服务平时的通信模式？
• 发生异常时，是否能够限制影响范围？

这要求策略不再只绑定IP地址和端口，而要结合身份、服务、命名空间、环境、数据敏感级别和操作类型。例如，同一个服务在测试环境和生产环境的访问范围可能不同；同一类运维身份在日常巡检和高风险变更时也应有不同的权限约束。

在实践中，策略应当尽量做到三点：

1. 以最小权限为原则：只授予完成业务所需的访问能力，并定期清理长期未使用的权限。
2. 以工作负载身份为基础：减少依赖临时账号、共享密钥和固定网络地址。
3. 以行为验证为补充：当访问主体、时间、资源、操作频率或调用链明显异常时，触发进一步验证或限制。

3. 告警运营：从边界事件处理转向上下文关联

边界设备产生的告警，通常围绕连接、扫描、访问和流量异常展开。运行时治理的告警来源更多，包括身份系统、容器平台、云审计、镜像仓库、代码仓库、服务网格、主机和应用日志等。

如果这些信号彼此孤立，安全团队可能收到大量“看起来都重要”的告警，却无法判断优先级。企业需要把告警运营从单点规则调整为上下文关联。

例如，单独看一次高权限操作，未必能判断风险；但如果它同时满足以下条件，优先级就应明显提高：

• 操作主体并非该服务的常用身份；
• 目标资源属于生产环境或敏感数据范围；
• 操作发生在非正常发布窗口；
• 相关工作负载刚刚更换了镜像或配置；
• 同一时间出现异常网络连接或权限变更。

这类关联并不一定需要一开始就引入复杂的智能分析。企业可以先围绕高价值资产和高风险操作建立基础关联规则，再根据实际误报率逐步完善。

4. 合规审计：从“有无设备”转向“是否持续可证明”

传统审计容易围绕设备清单、策略截图和定期报告展开。云原生环境变化快，静态材料很快失效。企业需要证明的不只是“配置过安全策略”，还包括：

• 谁在什么时间访问了什么资源；
• 哪些工作负载运行过哪些版本；
• 镜像和依赖是否经过审核；
• 权限变更是否有审批和留痕；
• 安全策略是否覆盖生产环境；
• 告警是否被及时分级、处置和复盘。

因此，审计能力应嵌入交付和运行流程，而不是在检查前临时整理材料。身份日志、部署记录、镜像来源、配置变更、运行时事件和处置结果，需要具备关联能力，并明确保存周期、访问权限和责任人。

三、企业应重点治理的四类风险

1. 身份与访问管理：先解决“谁能做什么”

身份与访问管理是云原生安全的基础。企业应关注的不只是用户登录，还包括服务账号、工作负载身份、自动化流水线、云资源角色和第三方集成身份。

常见问题包括：

• 服务账号长期有效且权限范围过大；
• 多个应用共享同一组密钥；
• 测试环境权限被直接复制到生产环境；
• 离职、转岗或项目结束后，权限没有及时回收；
• 自动化流水线可以直接执行高风险生产操作；
• 权限审批存在，但缺少使用记录和定期复核。

改进时不宜一味追求复杂的权限模型。企业可以先建立身份清单和资源清单，明确高权限主体、敏感资源和关键操作，再逐步推进短时授权、分环境授权、职责分离和定期复核。

2. 容器与工作负载安全：关注“运行了什么”

容器安全不能只等同于镜像扫描。镜像来源、基础镜像维护、依赖组件、运行权限、挂载目录、网络访问、系统调用和运行时行为，都可能影响工作负载的安全状态。

企业可以将治理分为三个阶段：

• 发布前：检查镜像来源、依赖风险、配置项、敏感信息和部署权限。
• 部署时：限制特权运行、控制主机目录挂载、设置资源与网络策略，并确保工作负载具有可识别身份。
• 运行中：监测异常进程、异常文件访问、异常网络连接、权限变化和偏离基线的行为。

运行时安全并不是要记录所有事件，而是要围绕高风险资产建立可解释的行为基线。对于核心生产服务，企业应优先保证能够回答“发生了什么、影响了什么、谁需要处理”，而不是盲目追求采集更多数据。

3. 软件供应链安全：把信任前移到交付过程

软件供应链安全覆盖代码、第三方依赖、构建环境、镜像、制品仓库、部署配置和发布流程。它的重点不是某一个组件是否存在问题，而是企业是否知道软件从哪里来、经过哪些处理、最终运行在哪里。

可执行的治理措施包括：

• 建立依赖和制品清单；
• 区分官方来源、内部构建和第三方来源；
• 对构建环境和发布凭据进行权限隔离；
• 对关键制品保留版本、来源和构建记录；
• 在发布前设置风险门槛，但允许业务定义例外审批；
• 对生产环境中实际运行的版本进行持续盘点。

供应链安全不应变成“发现一个风险就阻断全部发布”。企业需要根据业务重要性、风险可利用条件、修复可行性和暴露范围进行分级，避免安全控制直接破坏正常交付。

4. 服务通信与运行时行为：防止风险横向扩散

微服务架构下，服务之间的调用关系比传统单体应用更复杂。企业需要同时掌握调用关系、访问身份、数据流向和异常行为。

对于高价值服务，可以重点关注：

• 是否存在不必要的跨环境访问；
• 服务之间是否使用可验证的身份；
• 敏感接口是否具备细粒度授权；
• 服务调用是否有审计记录；
• 某个工作负载异常后，是否能够限制其继续访问其他服务。

这并不意味着所有企业都必须立即部署复杂的服务网格或全面改造网络架构。技术选择应取决于服务规模、跨集群需求、团队能力、性能影响和现有平台基础。

四、分阶段建设路径：先建立可见性，再推进自动化

第一阶段：盘点资产、身份和责任边界

这一阶段的目标不是立刻购买新的安全产品，而是形成一张可持续更新的风险地图。

至少应盘点：

• 云账号、集群、命名空间和生产环境；
• 关键应用、核心数据和重要服务；
• 用户身份、服务账号和自动化身份；
• 镜像、制品、依赖和部署流水线；
• 已有日志、审计、告警和处置流程。

同时明确每类风险的责任人。没有责任归属的资产清单，很快会变成一次性的文档工作。

第二阶段：建立最低安全基线

企业可以先从影响面较大、实施成本相对可控的控制项入手：

• 关闭不必要的公开访问；
• 清理共享账号和长期有效密钥；
• 对生产环境实施分级授权；
• 限制高风险容器配置；
• 对镜像和依赖建立基本准入规则；
• 确保关键身份、配置和部署事件可审计。

基线不宜写成无法执行的长清单。更有效的方法是根据业务场景设置“必须满足”“需要审批的例外”和“暂不覆盖但需登记”三个层级。

第三阶段：打通告警、审计与处置流程

当基础可见性建立后，企业应减少孤立工具，围绕关键场景建设统一运营能力。例如：

• 高权限身份异常访问生产资源；
• 关键工作负载出现偏离基线的行为；
• 未经审核的制品进入发布流程；
• 敏感配置发生非计划变更；
• 关键服务出现异常跨边界调用。

每类告警都应配套负责人、优先级、处置时限和升级路径。否则，即使技术上能够发现问题，也难以转化为实际风险降低。

第四阶段：推动策略自动化和持续验证

在规则和流程相对稳定后，再推进自动化阻断、动态授权和持续合规检查。自动化的前提是策略可解释、例外可管理、误报可控制。

对于生产环境，建议优先采用分级处置：

• 低风险事件进入观察和复盘；
• 中风险事件触发告警、二次验证或限制部分权限；
• 高风险事件在满足明确条件时执行隔离、暂停发布或撤销授权。

自动化不能替代责任判断。涉及核心业务的阻断动作，应保留人工接管和快速恢复机制。

五、如何选择运行时防护与可观测能力

企业选型不应先问“哪家产品功能最多”，而应先问“我要解决哪类决策问题”。可以从以下维度评估。

覆盖范围

产品或平台是否能够覆盖企业真实环境，包括公有云、私有云、多个集群、虚拟机、容器和无服务器资源。只覆盖单一环境的能力，可能无法支撑跨环境治理。

身份关联能力

告警能否关联到用户、服务账号、工作负载、云角色和具体资源。只显示IP、端口或进程名称，往往难以支持安全团队快速判断。

上下文与可解释性

系统是否能够说明事件的时间线、调用关系、资源影响和风险依据。可解释性不足时，安全团队很难区分真正的异常与正常变更。

部署与性能影响

需要评估采集方式、对节点和应用的资源消耗、对网络延迟和发布流程的影响，以及在高负载情况下的稳定性。运行时防护不能以明显损害业务稳定性为代价。

策略管理与例外机制

企业应关注策略是否支持分环境、分团队和分工作负载管理，是否能够记录例外原因、审批人、有效期限和复核结果。没有例外管理的强制策略，往往会被业务绕开。

与现有系统的集成

重点看能否接入身份平台、云审计、日志平台、工单系统、流水线和应急响应流程。安全能力如果无法进入现有工作流，通常会增加重复操作。

成本可控性

成本不仅包括软件许可，还包括日志存储、数据传输、节点资源、实施服务、规则维护和安全运营人力。企业应按关键环境和高价值资产分阶段覆盖，避免一开始就追求全量采集和全量防护。

团队使用门槛

工具是否符合现有团队的技能结构，是否支持清晰的运维交接和故障排查。技术能力越复杂，越需要评估长期维护成本，而不是只看演示效果。

六、企业容易踩到的几个误区

误区一：把增加安全产品等同于完成安全建设

新增工具只能增加检测或控制能力，不能自动解决权限混乱、责任不清和处置流程缺失。企业应先定义风险场景和成功指标，再判断是否需要引入工具。

误区二：只做镜像扫描，不管运行时

镜像检查能够改善发布前风险，但无法覆盖运行中的权限变化、异常访问、配置漂移和服务间横向影响。供应链安全和运行时安全需要形成闭环，而不是二选一。

误区三：把零信任理解为全面阻断

零信任的核心是持续验证和最小权限，不是对所有访问设置不可执行的限制。如果策略过于复杂、审批过多，业务团队可能通过共享账号或绕过流程恢复效率，反而降低可控性。

误区四：追求全量日志和全量告警

日志越多不等于可见性越好。没有分类、关联和保留策略，过量数据会增加成本，也会稀释真正重要的信号。企业应优先覆盖高价值资产、关键身份和高风险操作。

误区五：把合规报告当成安全运营的终点

合规材料能够证明部分控制存在，但不能替代持续风险管理。企业更应关注控制是否有效、例外是否失控、权限是否长期未复核，以及告警是否真正完成闭环。

误区六：忽略业务恢复能力

运行时隔离、撤销权限和暂停发布都有可能影响业务。安全建设必须同时设计恢复机制，包括回滚、备用路径、人工接管和故障复盘，不能只考虑如何阻断。

七、管理层应关注的衡量指标

云原生安全的指标不宜只看告警数量或工具覆盖率。更有价值的指标应体现风险是否得到控制，例如：

• 关键资产和身份的盘点覆盖率；
• 高权限身份的定期复核完成率；
• 生产工作负载的可追溯比例；
• 镜像、依赖和制品的来源可识别比例；
• 高风险配置的修复或例外审批时效；
• 关键告警从发现到确认、处置的时间；
• 安全策略例外的数量、期限和逾期率；
• 重大变更是否具备完整审计链路。

这些指标需要结合业务目标解释。比如，告警数量下降可能意味着规则优化，也可能意味着采集失效；权限数量减少可能代表治理改善，也可能是系统统计口径发生变化。指标必须配合抽样验证和定期复盘。

【软盟观察】

云原生安全的成熟度，不在于企业部署了多少防护组件，而在于能否把身份、工作负载、软件供应链和运行时行为纳入同一套责任与治理框架。传统边界防护不会消失，它仍然承担网络隔离、入口控制和流量治理等基础职责；但企业不能再把安全判断停留在网络位置和设备边界上。

对多数企业而言，合理路径不是一次性完成全面改造，而是先盘点关键资产和高权限身份，再建立最低安全基线，随后打通审计、告警与处置流程，最后根据业务风险推进策略自动化。运行时安全也不应被理解为单独采购的一类产品，而应成为云平台、研发交付和安全运营共同承担的能力。

在技术投入上，企业需要在覆盖范围、准确性、性能影响、团队门槛和长期成本之间做取舍。尤其要警惕“功能越多越安全”的选型逻辑：无法进入日常流程、无法解释告警、无法管理例外的能力，很难产生持续价值。真正值得优先建设的，是能够帮助企业看清责任、缩小权限、追溯变更、限制影响并快速恢复的安全体系。