Secure Azure OpenAI Zero Trust Architecture Lab

企业里用 Azure OpenAI 的场景越来越多——内部知识库、自动化流程、客服助手、安全运营，几乎每个团队都想接进去用。但真正让AmalUBasnayake 停下来想一想的是这个问题：怎么让应用安全地访问 AI 服务，同时把不必要的网络暴露降到最低，还能保护好身份、凭据和敏感数据？

如果 AI 处理的是公司内部数据、敏感系统或者受保护的资源，这个问题就不只是"锦上添花"了。

一个基础的 Azure OpenAI 部署，不做任何私有网络设计也能跑起来。但站在云安全工程的角度，能跑起来和真正安全是两回事。一套说得过去的架构，至少要照顾到这几件事：网络隔离、私有连接、基于身份的认证、最小权限授权、密钥保护、公网暴露面、内部名称解析，以及零信任的整体思路。

为了把这些概念落地，AmalUBasnayake 搭了一个 Azure OpenAI 零信任安全实验室，用的都是 Azure 原生的安全能力，目标是给一个 Azure OpenAI 工作负载打好安全基础设施的底子。

🎯 项目目标

这个项目的目标从来不是"把 Azure OpenAI 部署起来"这么简单。AmalUBasnayake 更想搞清楚的是：一个 AI 工作负载,怎么在网络、身份、授权、密钥管理这几个层面同时被保护起来。

最终这套架构落了这些点：Azure 虚拟网络、网络分段、私有终结点、私有 DNS、禁用公网访问、系统分配的托管标识、Azure Key Vault、Azure RBAC、Key Vault Secrets User 角色，以及安全的密钥存储。

这些控制项构成了项目 1.0 版本里零信任架构的基础（详见 GitHub 仓库）。

🧠 为什么 AI 工作负载需要零信任

云安全里一个很常见的误区,是把"在 Azure 网络内部"直接当成信任的理由。比如有人会说:“这个应用在 Azure 里面,所以是可信的。"——这不是零信任。

零信任的前提是,访问必须被显式验证,而不是因为网络位置对了就自动放行。放到 AI 工作负载上,这意味着安全要在好几个层面同时生效。

网络层面,Azure OpenAI 服务应该只能通过受控的私有连接路径访问。身份层面,应用和工作负载应该用强身份,而不是把长期有效的凭据硬编码在代码里。授权层面,哪怕身份认证通过了,也只应该拿到这个角色真正需要的权限。密钥层面,敏感凭据要集中保护,不能直接写在应用代码或配置文件里。暴露面上,只要私有连接已经能用,多余的公网访问就该拿掉。

这几层叠在一起,才是一个真正分层的安全模型,而不是指望单靠一个控制项扛住所有风险。

🏗️ 架构总览

整套架构从一个 Azure 虚拟网络开始,它提供私有网络边界。接着建一个专用子网,用来承载私有终结点连接。Azure OpenAI 通过 Azure 私有终结点接入这个虚拟网络,私有 DNS 负责这条私有连接路径的内部名称解析,同时 Azure OpenAI 资源上的公网访问被关掉。

身份这一侧,启用了系统分配的托管标识。密钥管理用 Azure Key Vault 来做,Azure RBAC 通过 Key Vault Secrets User 角色提供最小权限访问。

仓库里同时放了详细架构图和架构概要图（GitHub）。

Secure Azure OpenAI architecture using Private Endpoint, Private DNS, Managed Identity, Key Vault, and RBAC

🔐 安全架构:纵深防御

这个项目背后一个核心的设计原则是纵深防御。不指望靠单一控制项扛住整个工作负载,而是叠加多层安全边界。

Defense in depth security layers

哪怕某一层配置出了问题,其他安全控制还能把潜在的暴露面压下去。这比单纯靠一个 API Key 或者一个公网终结点要靠谱得多。

🌐 第一步——创建 Azure 虚拟网络

第一步是建一个专用的 Azure 虚拟网络。VNet 给这个 AI 工作负载划定了网络边界,也是后面私有通信的基础。

在这套架构里,VNet 要负责:网络隔离、私有连接、分段、可控的通信路径,以及给私有终结点集成打地基。

AmalUBasnayake 没有把 Azure OpenAI 当成一个孤立的 PaaS 服务扔在公网上,而是先给它围了一圈可控的私有网络边界。

Dedicated Azure Virtual Network created for the secure AI workload

🧱 第二步——创建独立的私有终结点子网

下一步是给私有终结点连接单独建一个子网。网络分段之所以重要,是因为它能把基础设施组件在逻辑上分开管理。

最终的结构大概长这样:

Network segmentation structure

仓库里专门记录了用独立子网承载私有终结点这一点,把它作为网络分段设计的一部分（GitHub）。

Dedicated subnet created for Private Endpoint connectivity

🤖 第三步——部署 Azure OpenAI

网络基础打好之后,才轮到部署 Azure OpenAI。到这一步,目标不是把服务暴露出去、指望靠身份认证兜底,而是让它成为整套安全架构真正要保护的核心资源。

接下来要回答的问题变成:谁能访问这个服务?从哪里能访问到?怎么连接过去?凭据怎么保护?访问权限怎么授权?

后面所有的实现都是围绕这几个问题展开的。

Azure OpenAI service deployed as the protected AI workload

🔒 第四步——配置私有终结点

接下来是用 Azure 私有终结点把 Azure OpenAI 接入这个虚拟网络。私有终结点在 VNet 和受支持的 Azure 服务之间建立私有连接。

架构从常见的公网连接模型,变成了私有连接模型:

Conventional public connectivity model

这个实验室里最终落地的是这样:

Private connectivity model

关键的安全收益在于,应用到 Azure OpenAI 资源之间有了一条私有连接路径。

Azure OpenAI integrated with the Virtual Network through a Private Endpoint

🔐 第五步——验证私有终结点连接

建好私有终结点还不算完,这个连接本身得验证过才行。项目在切换到"只走私有连接"之前,先确认了私有终结点连接已经被批准。

这里有个操作上的原则 AmalUBasnayake 觉得挺重要:先把想要的安全路径立起来,再去拆掉备用路径。

仓库把私有终结点连接的批准记录为第五步（GitHub）。

Approved Azure OpenAI Private Endpoint connection

🚫 第六步——禁用公共网络访问

这一步是整个项目里最关键的安全控制之一。私有连接路径搭好之后,Azure OpenAI 的公网访问被彻底关掉。

最终的安全模型是这样:

Public network access disabled

这一步大幅压缩了不必要的网络暴露面。仓库里明确把"公网访问已禁用"列为 1.0 版本已实现的安全控制之一（GitHub）。

光有私有终结点还不够,得让私有连接真正成为唯一的访问路径才算数。

Azure OpenAI configured to prevent public network access

🌐 为什么私有 DNS 很重要

私有连接要真正有用,前提是工作负载能把服务的主机名正确解析到私有终结点上。这就是私有 DNS 在这套架构里的作用。

应用可以继续用 Azure OpenAI 原本的主机名,DNS 配置会在背后把解析结果指向私有连接路径。概念上是这样:

Private DNS resolution concept

这样一来,应用不用硬编码私有 IP 地址就能用上这个服务。仓库明确把私有 DNS 配置列为已实现的控制项,也是核心架构的一部分（GitHub）。

Private DNS integrated into the private Azure OpenAI connectivity architecture

🛡️ 网络安全层的阶段性成果

走到这一步,网络安全层算是搭起来了,包含:

✓ Azure 虚拟网络
✓ 独立的私有终结点子网
✓ Azure OpenAI
✓ 私有终结点
✓ 已批准的私有终结点连接
✓ 私有 DNS
✓ 公网访问已禁用

这构成了第一道主要的零信任边界。但还有个问题绕不过去:如果一个工作负载在私有网络内部,是不是就该自动被信任?

答案是不。光靠网络隔离还不够,下一层要解决的是身份问题。

🧑‍💻 第七步——启用系统分配的托管标识

下一个重要的安全控制是托管标识。传统应用经常把 API Key、密码、连接字符串、客户端密钥这类凭据直接塞进应用配置里,这本身就是额外的风险。

一旦这些凭据通过源代码、配置文件、日志,或者一条没配置好的部署流水线泄露出去,攻击者就有可能拿去复用。托管标识提供了一种 Azure 原生的身份机制,让应用在和受支持的 Azure 资源交互时,不再需要把长期有效的凭据硬编码进代码里。

在这个项目里,AmalUBasnayake 启用了系统分配的托管标识。

System-assigned Managed Identity enabled for identity-based authentication

🧠 为什么托管标识很重要

安全模型现在变成了这样:

Managed identity security model

问题不再是"API Key 存在哪里”,而是变成了"这次请求是哪个身份发起的,这个身份被授予了什么权限"。这对企业级云安全来说是一个更扎实的基础,也更符合零信任的思路——认证和授权被显式评估,而不是单靠网络位置来判断。

仓库把托管标识列为核心的已实现安全控制之一（GitHub）。

🔑 第八步——配置 Azure Key Vault

下一层是密钥管理。哪怕已经用上了基于身份的访问,应用有时候还是需要用到一些特定工作负载或集成所需的密钥。

与其把这些密钥直接写进应用配置,Azure Key Vault 提供了一个集中的密钥管理边界。这个项目里创建了一个 Azure Key Vault,专门给密钥提供集中保护。

架构变成了这样:

Azure Key Vault architecture

密钥存储和应用逻辑被分开了。

Azure Key Vault deployed for centralized secret management

🔐 第九步——配置 RBAC 权限

光创建 Key Vault 还不够,这个身份还需要一个明确定义的授权边界,这就是 Azure 基于角色的访问控制(RBAC) 要解决的问题。

项目里用的是 Key Vault Secrets User 角色,目的是遵循最小权限原则——不给身份整个 Key Vault 的管理权限,只给它处理密钥所必需的那部分权限。

授权流程变成:

RBAC authorization flow

这里有个关键的区别:认证回答的是"你是谁",授权回答的是"你被允许做什么"。

项目明确用 Key Vault Secrets User 角色实现了基于 RBAC 的 Key Vault 访问（GitHub）。

Key Vault Secrets User role assigned using Azure RBAC

🧩 第十步——安全存储密钥

1.0 版本里最后一步实现,是把需要用到的密钥安全地存进 Azure Key Vault。这里的核心原则是分离。

原本的做法是这样:

Before secret separation

改造之后变成:

After secret separation

这样就给密钥管理建了一个专属的控制面。密钥不再被当成普通的应用配置,而是变成受身份和授权策略管辖的、受保护的云资源。

仓库把安全创建密钥记录为第十步（GitHub）。

Secret securely stored inside Azure Key Vault

🔄 把整套安全模型拼在一起

走到这一步,前面这些单独的控制项可以合并起来看成一套完整的安全架构。

Integrated security architecture

每个组件都对应一个不同的安全需求:私有终结点提供私有连接,私有 DNS 支撑内部名称解析,禁用公网访问拿掉了原本不必要的公开路径,托管标识提供基于身份的认证,Azure RBAC 控制授权,Key Vault 提供集中的密钥保护。

这些控制项叠在一起,才构成一套分层的零信任架构。

Final Azure OpenAI Zero Trust security architecture

🔍 从安全工程角度复盘

做完这个项目,AmalUBasnayake 最大的体会是:云安全从来不是一个开关就能搞定的事。一个安全的 AI 工作负载,需要好几层控制同时生效。

网络层回答的是工作负载怎么连到服务;身份层回答的是谁在发起请求;授权层回答的是这个身份被允许访问什么;密钥层回答的是敏感凭据存在哪里;暴露面这一层回答的是,这个服务是不是还能通过一条不必要的公网路径被访问到。

零信任模型把这几个问题串了起来。

Zero Trust model connecting all layers

比起单纯部署一个 AI 服务、打开身份认证就算完事,这套分层模型更贴近真实世界里云安全工程的样子。

🧠 学到的关键经验

搭这套环境的过程,让 AmalUBasnayake 在 Azure 安全的几个方向上都摸了一遍实操。

零信任架构这块,AmalUBasnayake 更深地体会到安全边界应该被显式定义出来,而不是想当然地认为内部资源就是可信的。私有连接方面,私有终结点确实能给 Azure PaaS 服务提供受控的私有访问路径。网络分段能帮着把基础设施组件在逻辑上组织和隔离开。托管标识这块最直观的收获是,基于身份的认证能明显减少对硬编码长期凭据的依赖。RBAC 提醒 AmalUBasnayake 授权要遵循最小权限。密钥管理上,敏感密钥应该放进专门的安全服务,而不是直接写进应用代码里。

说到底,AI 基础设施安全和其他企业级云工作负载没什么本质区别。身份、网络隔离、授权、密钥管理这几件事,一个都少不了。

⚠️ 这个实验室没做到的事

这里有必要说清楚,1.0 版本里实际做了什么,和后续计划做什么是两回事。

这个项目目前聚焦在安全基础设施这一层,并不能算是一套完整的企业级 SOC 监控实现。仓库里把这些能力列为 2.0 版本的未来增强项:Azure OpenAI 诊断设置、Azure Key Vault 诊断日志、Log Analytics 工作区、Microsoft Sentinel、KQL 威胁狩猎、Key Vault 活动监控、Azure OpenAI 活动监控、Defender for Cloud 建议、安全告警,以及事件响应流程。

这些内容被特意和当前实现区分开,为的是让项目如实反映出哪些已经做了、哪些还在计划里（GitHub）。

🚀 未来增强计划——2.0 版本

下一阶段,AmalUBasnayake 打算把重心放在安全监控和检测工程上。可以把 Azure OpenAI 和 Azure Key Vault 的诊断遥测接进 Log Analytics 来扩展这套架构,再引入 Microsoft Sentinel 作为 SIEM 层。

未来的架构大概会演变成这样:

Future architecture with Sentinel and monitoring

Defender for Cloud 也能提供额外的安全态势可见性和建议。这样一来,项目就会从一套"安全的 AI 基础设施"升级成一套更完整的"AI 安全监控与检测工程平台"。

💡 最后的思考

保护好 AI 工作负载,正在变成云和安全工程师越来越绕不开的责任。企业在采用 Azure OpenAI 之类的 AI 服务时,安全团队得跳出模型本身去想问题,周边的基础设施同样重要。

一套安全的 AI 架构,得考虑清楚服务能从哪里被访问到、应用怎么做身份认证、身份被允许做什么、密钥存在哪里、暴露了哪些网络路径,以及安全监控要怎么落地。

这个项目让 AmalUBasnayake 有机会通过一次实打实的 Azure 实践,把这些概念过一遍,而不是只停留在纸面上的理解。最终的结果,是一套用 Azure 原生安全能力搭出来的、面向 Azure OpenAI 的基础零信任架构。

🎓 这个项目验证了哪些能力

做完这一趟,AmalUBasnayake 在这些方向上都有了实打实的动手经验:Azure OpenAI、Azure 虚拟网络、网络分段、Azure 私有终结点、Azure Private Link、私有 DNS、Azure Key Vault、托管标识、Microsoft Entra ID 相关概念、Azure RBAC、最小权限原则、密钥管理、零信任架构、云安全,以及 AI 基础设施安全。

⭐ 一点总结

一个安全的 AI 工作负载,从来不是靠某一个安全功能做出来的,而是把网络隔离、强身份、最小权限授权和安全的密钥管理拧成一套连贯的架构。Azure OpenAI 提供 AI 能力,私有终结点提供私有连接,私有 DNS 负责内部解析,托管标识提供工作负载身份,RBAC 控制授权,Azure Key Vault 保护密钥。零信任,则是把这一整套控制串起来的安全思路。

网络要锁死,身份要验证,权限要收紧,密钥要护好。信任这件事,从来都不该想当然。

📚 参考资料