3. CNAPP工程化架构设计

CNAPP平台要同时覆盖云基础设施、容器编排、工作负载运行时和应用代码，如果只是把若干安全工具拼在一起，很快会遇到数据重复采集、告警口径不一致、策略无法统一下发、响应动作互相冲突等问题。工程化架构设计的核心，是把平台拆成职责清晰、接口稳定的四层：数据采集层、分析引擎层、策略控制层、响应编排层，并让层与层之间通过标准化的数据契约解耦，从而支持横向扩展和功能替换。

四层架构的职责边界

数据采集层负责“把原始事实拿回来”，包括云API配置快照、Kubernetes对象与审计日志、镜像仓库元数据、CI/CD流水线事件、eBPF运行时行为、漏洞库与威胁情报。它的输出不是告警，而是带来源标识和时间戳的标准化事件与资源快照。分析引擎层负责“把事实变成判断”，包括资产归一化、图关系构建、规则与行为检测、漏洞可达性分析、风险评分。策略控制层负责“把判断变成约束”，把检测结果映射为准入策略、网络策略、镜像签名要求和合规基线。响应编排层负责“把约束变成动作”，执行隔离、阻断、工单、通知和回滚。

四层之间必须约定统一的数据模型。推荐以“资源实体 + 关系边 + 事件”作为核心抽象：资源实体用唯一ID标识（如 cluster/ns/workload/image 路径），关系边描述“运行于、拉取自、暴露于、可访问”，事件则携带检测结论和证据引用。这样分析引擎可以跨云、跨集群做关联，策略层也能基于同一实体ID精确下发。

可扩展性的三个关键设计

第一，采集侧采用“代理 + 无代理”混合模式。云API采集适合无代理，按固定周期拉取配置快照，例如每15分钟一次全量、每1分钟一次增量；K8s审计日志通过Webhook或日志管道实时接入；运行时行为用eBPF采集，避免在业务Pod中注入Sidecar带来的资源开销。采集器应支持水平扩展，按云账号或集群分片，每个分片独立消费，避免单点瓶颈。

第二，分析引擎采用流批一体。实时流处理负责秒级检测（如异常进程、可疑外联），批处理负责图关系重建、漏洞可达性计算和每日风险评分。两者共享同一份实体ID和关系存储，避免“实时告警找不到资产上下文”。分析规则以插件形式注册，新增检测能力不需要改动核心引擎。

第三，策略与响应解耦。策略层只输出“决策结果”，例如“拒绝部署镜像X到生产命名空间”，不直接调用K8s API；响应编排层根据决策结果选择执行器（准入Webhook、网络策略控制器、工单系统）。这样策略可以灰度发布，响应动作可以按环境替换，也便于审计“谁在什么时候基于哪条策略执行了什么动作”。

一个可落地的参数示例

假设某企业有3个云账号、12个K8s集群、约2000个工作负载。采集层按集群分片部署12个采集器，每个采集器处理约170个工作负载；云API采集按账号分3个任务，每15分钟全量、每1分钟增量。分析层用2个流处理节点处理运行时事件，峰值约5000事件/秒；批处理每天凌晨重建一次关系图，约200万条边。策略层维护约80条准入策略和40条网络策略，按命名空间标签匹配。响应层配置5类执行器，其中隔离动作要求二次确认，阻断动作在预发环境先观察24小时再上生产。

常见架构陷阱

• 采集层直接输出告警：导致分析层无法做跨源关联，同一风险在多个工具中重复出现。
• 分析引擎与策略层强耦合：检测规则里直接写死“发现即阻断”，无法按环境调整处置力度。
• 响应层绕过策略层直接调用API：动作来源不可审计，回滚困难。
• 缺少统一实体ID：云上资源、K8s对象、镜像、进程各自为政，无法回答“这个漏洞到底影响哪个在线业务”。

把四层职责、数据契约和扩展方式定清楚之后，后续的采集器开发、检测规则编写、策略下发和响应剧本编排才有稳定的工程边界。架构设计阶段多花时间定义接口，比后期在告警风暴中反复修补要划算得多。