2. Azure身份与访问基础
在Azure中讨论“数据安全”，第一个必须建立的认知是：数据访问的起点不是存储账户，也不是数据库，而是身份。Microsoft Entra ID（原Azure AD）是Azure的云身份与访问管理服务，它负责保存身份对象、完成身份验证（Authentication），并为授权（Authorization）提供主体依据。理解用户、组、服务主体、托管标识这四类对象，以及它们在数据访问链路中的位置，是后续学习RBAC、密钥保管、数据库认证和最小权限设计的基础。
一、四类身份对象：谁在访问数据
Entra ID中的身份对象可以按“是否代表人类”和“是否拥有独立凭据”两个维度来区分。用户（User）代表自然人，可以是云内创建的用户，也可以是从本地Active Directory同步或联合过来的账户。组（Group）本身不是访问主体，而是主体的集合，用于批量授权和权限继承。服务主体（Service Principal）是应用程序在Entra ID中的身份表示，代表一个应用或自动化工具。托管标识（Managed Identity）则是Azure为计算资源自动创建和管理的特殊服务主体，它不需要管理员手动维护密码或证书。
这四类对象在数据访问中的角色差异，可以用下面的关系图来理解。图中左侧是身份对象，右侧是它们最终可能访问的数据资源，中间是授权入口。
二、用户与组：人类访问者的组织方式
用户是Entra ID中最基础的身份。创建用户时，需要指定用户主体名称（UPN，如 zhangsan@contoso.onmicrosoft.com）、显示名称和初始密码。对于从本地AD同步的用户，其身份来源是Windows Server AD，Entra ID通过Microsoft Entra Connect保持同步。来宾用户（Guest）则用于跨组织协作，通过B2B邀请机制加入租户。
组的作用是简化授权。假设一个数据平台团队有12名分析师，都需要读取同一个Azure SQL数据库。如果逐个为用户分配权限，后续人员变动时维护成本很高。更合理的做法是创建一个安全组，例如 sg-data-analysts，将12名用户加入该组，然后只针对这个组授予“读取者”角色。当有新分析师入职时，只需将其加入组，权限自动生效；离职时从组中移除即可。
Entra ID支持两种主要组类型：安全组（Security Group）用于权限管理，Microsoft 365组用于协作场景（如共享邮箱、Teams）。在数据访问控制中，应优先使用安全组。组还可以支持动态成员资格，例如按部门属性自动将“数据平台部”的用户纳入组，减少人工维护。
三、服务主体：应用程序的身份
当应用程序需要访问Azure资源时，它不能使用某个用户的账号密码，而应拥有自己的身份，这就是服务主体。服务主体通过“应用注册”（App Registration）创建，注册后会生成一个应用ID（Client ID）和一个租户ID。应用程序使用Client ID和客户端密码（或证书）向Entra ID请求访问令牌，再凭令牌访问数据资源。
服务主体的典型使用场景包括：CI/CD流水线部署资源、自动化脚本读取Key Vault机密、第三方SaaS应用访问存储账户。需要注意的是，客户端密码有有效期，过期后应用将无法认证。因此生产环境更推荐使用证书而非密码，或者直接使用托管标识。
四、托管标识：无需管理凭据的服务主体
托管标识是Azure为计算资源（如虚拟机、App Service、Azure Functions、AKS）自动创建的服务主体。它的核心价值是：开发者不需要在代码或配置中保存任何密码或证书。Azure负责托管标识的凭据轮换，应用程序通过Azure Instance Metadata Service（IMDS）或SDK自动获取令牌。
托管标识分为两种：
- 系统分配托管标识：与某个Azure资源生命周期绑定，资源删除时标识也随之删除。一个资源只能有一个系统分配标识。
- 用户分配托管标识：作为独立Azure资源创建，可以分配给多个计算资源，生命周期独立管理。适合多个资源需要共享同一组权限的场景。
例如，一个运行在App Service上的数据API需要读取Azure SQL数据库。使用系统分配托管标识时，操作步骤如下：在App Service的“标识”边栏中启用系统分配标识；在Azure SQL中为该托管标识创建包含数据库用户；授予该用户 db_datareader 角色。应用程序代码中不再需要连接字符串中的用户名和密码，而是使用 Authentication=Active Directory Managed Identity 的连接方式。
五、四类对象在数据访问中的选择原则
| 身份对象 | 适用场景 | 凭据管理 | 数据访问示例 |
|---|---|---|---|
| 用户 | 人类交互式访问 | 密码 / MFA / 无密码 | 分析师通过SSMS登录SQL查询 |
| 组 | 批量授权与权限继承 | 不适用 | 安全组被授予存储账户读取者角色 |
| 服务主体 | 跨租户应用、外部自动化 | 客户端密码 / 证书 | CI/CD流水线访问Key Vault |
| 托管标识 | Azure内计算资源访问Azure资源 | Azure自动托管 | Function App读取Blob存储 |
六、身份对象与数据访问的衔接点
理解身份对象之后，还需要知道它们如何与数据资源衔接。在Azure层面，RBAC角色分配可以授予用户、组、服务主体和托管标识，作用范围可以是管理组、订阅、资源组或单个资源。在数据层面，Azure SQL支持Entra身份认证，需要为身份对象创建包含数据库用户；存储账户支持通过RBAC授予“存储Blob数据读取者”等角色；Key Vault通过访问策略或RBAC控制机密读取权限。
一个常见的误区是：在Entra ID中创建了用户或组，就认为他们自动拥有数据访问权限。实际上，身份对象只是“谁”，授权才是“能做什么”。没有角色分配或数据层授权，身份对象无法访问任何数据资源。因此，在设计数据安全方案时，必须同时考虑身份对象的创建、组的组织方式、授权范围的选择，以及凭据的生命周期管理。