云原生网络安全如何与算力基础设施协同：企业技术团队需要重新评估哪些防护边界？

过去，企业常把安全能力作为算力平台之外的一套“保护系统”：网络边界由防火墙负责，身份权限由统一认证系统负责，容器安全由安全团队负责，数据访问则交给数据库或存储系统管理。云原生工作负载与算力基础设施深度协同后，这种分工正在失效。安全不再只是流量入口处的一道检查，而需要进入算力调度、集群运维、应用交付和数据访问的全过程。

一、首先要重新定义“网络边界”

云原生环境中的边界，不再等同于机房出口、云账号边界或某个公网入口。一个应用可能由多个容器、服务和任务组成，工作负载会随着业务负载在节点之间调度，服务之间持续产生东西向流量。传统上以网络位置划分信任范围的方式，很难完整反映真实风险。

更合理的边界至少包括四个层面：

• 身份边界：谁或什么工作负载可以访问资源；
• 工作负载边界：某个容器、服务、任务具有什么属性和权限；
• 节点与集群边界：计算节点、控制面和租户之间如何隔离；
• 数据边界：哪些数据可以被哪些服务访问、处理和导出。

这意味着，企业不能只问“流量是否来自可信网络”，还要问“请求主体是谁、运行在哪里、以什么身份发起、访问了什么数据，以及当前是否符合业务上下文”。

网络隔离仍然重要，但它应当从唯一的防护手段，转变为多层控制的一部分。对于技术负责人而言，网络架构评估的重点不应只是入口防护设备的能力，还要看策略能否覆盖短生命周期工作负载、动态服务发现和跨集群通信。

二、身份权限要从“账号管理”进入“工作负载管理”

在传统系统中，身份与权限通常围绕员工账号、服务器账号和应用账号展开。云原生环境新增了大量非人工身份，包括服务账号、任务身份、节点身份、自动化流水线身份和临时计算任务身份。

如果这些身份仍沿用长期有效、范围过大的授权方式，算力规模越大，权限失控的影响面就越大。企业需要把权限管理从“给谁开通权限”进一步推进到以下问题：

1. 哪个工作负载正在发起请求；
2. 该工作负载由哪个应用、团队或租户创建；
3. 它当前运行在哪类节点上；
4. 它只需要访问某个接口，还是需要访问整个数据服务；
5. 任务结束后，临时权限是否能够自动回收。

这类控制并不意味着所有权限都要集中到一个系统中，而是需要统一身份语义和授权原则。应用交付流程应当能够携带工作负载身份，算力调度系统应当能够识别资源所属关系，运行时则要能够在身份发生变化或环境不符合要求时收紧访问。

权限设计可以优先遵循三条原则：

• 短时授权优先于长期密钥；
• 服务身份优先于共享账号；
• 基于实际调用关系授权，而不是按网络位置放行。

对于创业公司或规模较小的团队，不必一开始就建设复杂的身份治理体系，但至少应清理共享凭据、区分生产与非生产身份，并建立高权限操作审计。对于多租户平台和大型企业，则需要进一步处理租户隔离、跨集群访问和自动化系统权限等问题。

三、东西向流量需要从“可见”走向“可控”

南北向流量通常更容易被发现，因为它经过公网入口、API 网关或统一出口。东西向流量则发生在服务、容器、节点和集群之间，数量更多、路径更复杂，也更容易被传统监控体系忽略。

东西向流量治理不应简单等同于“把所有服务通信都拦住”。过度控制会增加服务调用延迟、排障难度和运维成本。更可行的做法，是先建立业务通信关系，再针对高价值路径设置更细的策略。

可以按以下顺序推进：

先建立通信资产视图

识别应用、服务、任务、节点和数据服务之间的调用关系，区分正常通信、临时通信和异常通信。资产视图不一定需要一次性做到极细，但必须能够回答关键问题：哪些服务可以访问核心数据，哪些任务具有跨租户调用能力，哪些通信路径没有明确的业务归属。

再对关键路径实施分层控制

对于支付、身份、核心数据处理等高价值服务，可以采用更细的访问规则。普通内部服务则可以先从命名空间、应用身份、环境和数据敏感度等维度进行基本隔离，避免在早期把所有通信都纳入复杂策略。

最后建立异常变化检测

云原生环境的通信关系会随版本发布和任务调度变化。安全系统需要关注的不只是某次请求是否被允许，还要关注调用关系是否突然扩大、访问对象是否发生变化，以及某个工作负载是否开始接触与其职责无关的数据服务。

四、容器安全不能只停留在镜像扫描

容器安全经常从镜像扫描开始，但镜像合规并不代表运行时安全。镜像可能在交付后被赋予过大的权限，节点配置可能存在隔离不足，运行中的服务也可能出现异常行为。

因此，容器安全至少应覆盖四个阶段：

这里的关键变化是：安全策略不能只由安全团队在外围配置，还要嵌入持续交付和算力调度。例如，一个工作负载如果需要高权限、访问敏感数据或使用特殊硬件，平台就应当在部署前触发额外审核，或者将其调度到符合隔离要求的节点，而不是等到运行后再被动发现。

对于高性能计算、AI 训练或批处理任务，安全控制还要考虑资源特性。过多的运行时检查可能影响吞吐，过度细化的日志也会增加存储和分析成本。因此，应根据任务持续时间、数据敏感度、节点共享方式和故障影响范围，决定哪些控制必须实时执行，哪些控制适合事后审计。

五、数据访问边界要跟随任务和算力移动

算力基础设施的弹性调度会改变数据访问路径。一个任务可能被分配到不同节点，临时任务可能在短时间内访问大量数据，跨区域或跨集群计算也可能带来新的数据流动路径。

企业需要避免把“任务运行在内网”直接等同于“任务可以访问内部数据”。数据访问至少应同时考虑：

• 数据的敏感等级和业务归属；
• 发起访问的工作负载身份；
• 任务所在环境和节点属性；
• 访问是否符合当前业务目的；
• 数据是否需要脱敏、最小化或限时使用；
• 访问结果是否会进入日志、缓存或临时存储。

对于训练、分析和批处理场景，尤其要区分“可以读取数据”和“可以复制、导出或长期保存数据”。如果只控制入口而不控制数据副本，安全边界仍然是不完整的。

在投入有限的情况下，可以优先保护高价值数据路径：先梳理核心数据库、对象存储、密钥服务和敏感数据接口，再逐步扩大到普通业务数据。相比一次性覆盖所有数据，这种方式更有利于明确风险和控制成本。

六、安全能力嵌入平台，不能变成新的性能瓶颈

将安全能力嵌入算力和云原生平台，价值在于减少策略断点，但也会带来性能、可用性和运维复杂度的取舍。

性能取舍

流量检查、身份校验、运行时监测和审计都会消耗计算、网络或存储资源。企业应区分实时阻断与异步分析：对高风险访问、权限变更和关键数据操作，可以要求实时决策；对低风险行为和大规模日志，则可以采用异步采集和集中分析。

成本取舍

成本不仅包括安全产品或平台组件，还包括节点资源、日志存储、策略维护、故障排查和团队培训。若安全策略过于分散，平台团队和安全团队都可能承担重复建设。评估方案时，应把日常运维成本和业务中断成本纳入，而不是只看采购成本。

可用性取舍

安全控制本身不能成为单点故障。关键策略服务需要考虑缓存、降级、故障时的默认行为和应急绕行机制。不同业务的容错要求并不相同：核心交易系统可能更强调强阻断和审计，部分离线任务则可以接受短暂延迟或事后校验。

七、企业可以按三个阶段推进

第一阶段：先画清资产、身份和数据关系

优先建立工作负载清单、服务调用关系、节点与租户关系、关键数据访问路径。这个阶段的目标不是马上实现全面自动化，而是消除“谁在访问什么、为什么可以访问”的认知空白。

第二阶段：把关键控制嵌入交付和调度

将镜像检查、部署权限、工作负载身份、敏感数据访问和高风险配置纳入应用交付流程。对于需要特殊算力、跨租户访问或高权限运行的任务，建立额外的策略门槛。

第三阶段：建立持续评估和自动响应

当资产和策略较为稳定后，再逐步引入风险评分、异常通信识别、运行时响应和自动化权限回收。自动化的前提是资产信息和业务关系足够可靠，否则错误阻断可能比风险本身更影响生产。

八、哪些场景适合深度协同，哪些场景应保持边界

并非所有企业都需要立即建设高度一体化的安全平台。以下场景更适合推进安全与算力的深度协同：

• 多租户云平台，需要清晰隔离租户和工作负载；
• AI 训练、批处理等弹性任务较多，算力调度频繁变化；
• 微服务数量较大，东西向调用关系复杂；
• 业务涉及敏感数据，且数据访问需要精细审计；
• 研发、平台和安全团队已经具备协同运维基础。

以下情况则应谨慎推进：

• 现有资产和身份数据本身不完整；
• 团队缺少平台运维能力，无法维护复杂策略；
• 业务对延迟和可用性极其敏感，却没有性能基线；
• 组织仍按部门各自建设系统，缺乏统一的责任边界；
• 为了追求“全覆盖”而引入大量尚未验证的自动阻断规则。

【软盟观察】

云原生安全的核心变化，不是再增加一层安全设备，而是重新安排安全能力与算力基础设施的关系。工作负载在哪里运行、以什么身份运行、调用哪些服务、接触哪些数据，都应成为平台调度和应用交付可以理解的上下文。

企业投入不宜从“买什么系统”开始，而应从三项基础问题开始：资产是否可见，身份是否清晰，关键数据路径是否可解释。只有这些基础关系稳定后，东西向流量治理、容器运行时防护和自动化响应才有可靠依据。

对技术团队而言，最需要警惕的是两种极端：一种是继续依赖传统网络边界，把内部流量默认视为可信；另一种是追求高度自动化，却忽视性能、成本和误阻断风险。更稳妥的路径，是围绕高价值工作负载和关键数据逐步嵌入控制，把安全策略纳入算力调度、集群运维与应用交付，同时保留清晰的故障降级和人工复核边界。