北京
云安全模型正在被生成式AI的工作流重塑。Google Cloud近期发布一份新的安全蓝图，直指企业在Google Kubernetes Engine上运行AI负载时面临的防护缺口。在起草者Glen Messenger和Shannon Kularathna看来，从原型验证到生产部署的转变速度已经远超传统安全模型的适配能力，基础设施团队需要围绕专有模型权重、提示注入等新型应用层威胁，以及严格的合规要求重建控制体系，而且不能拖慢AI开发者的迭代节奏。
这份为首席信息安全官和平台工程团队编写的文档，将安全架构拆解为三层：基础设施层、模型完整性层和应用安全层。文档明确提出，达成这些安全目标需要的不是一个只能运行容器的环境，而是一个能将各层安全能力“开箱即用”地叠加起来的平台。
基础设施方面的建议相当具体。蓝图指出，企业可使用机密GKE节点，这类节点能把硬件级内存加密能力延伸至Nvidia H100 GPU和TPU等加速器。同时，Workload Identity Federation让推理Pod不再依赖长期密钥就能从Cloud Storage拉取模型权重，VPC Service Controls则允许管理员围绕受监管数据构筑一道隔离边界。GKE安全团队的产品经理Messenger写道：“你无法在一个不安全的集群上运行一个安全的AI工作负载。”
模型安全部分的思路与传统软件供应链管理有明显区别。Google指出，传统的软件物料清单无法覆盖数据集、框架等AI特定产物。为此，蓝图引入了一个名为k8s-aibom的开源Kubernetes控制器，可自动生成AI物料清单。在应用层，Model Armor负责检查提示和响应中的注入尝试、敏感数据暴露及有害内容。对于需要执行生成代码或调用非可信工具的AI代理，蓝图建议采用基于gVisor隔离技术的GKE Sandbox进行容器化。
蓝图为安全能力的落地规划了三个递进阶段。第一阶段“部署”聚焦基线控制，例如启用Workload Identity并将敏感工作负载运行在机密节点上。第二阶段“运营”转向生产环境加固措施，包括镜像签名策略和日志聚合。第三阶段“治理”引入组织级防护机制和自动化事件响应。这一定义清晰的分步路径，使不同成熟度的团队都能找到对应起点。
如果把这份蓝图放到行业坐标系里观察，它其实处在一个日渐拥挤的赛道上。亚马逊云科技采取了类似的分层策略，发布了自己的AI安全框架，并配以一个名为“AI on EKS”的开源方案，该方案通过Terraform蓝图来简化部署。SecurityBrief在报道中指出，这一系列动作凸显了一个趋势：云提供商正在将自己已有的基础设施、身份和监控产品重新打包，转化为面向特定AI运营模式的安全方案，提供给在托管平台上构建应用的客户。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
