使用 requestContext（.identity）在 Azure Policy 中返回调用方标识

如果希望Azure Policy根据发出请求的人员（或内容）以不同的方式行为，请使用函数requestContext().identity。

此函数允许你在策略评估时检查调用方标识信息，以便可以编写如下策略：

对于敏感资源类型，仅允许由用户发起的更改
阻止未经批准的客户端应用程序的更新
在执行特定操作前，要求提供更强的登录验证上下文（例如 MFA 信号）

为什么此函数很重要

大多数策略规则都会评估目标资源有效负载。此方法适用于强制实施配置，但它不提供有关调用方的任何信息。
requestContext().identity 通过在策略规则表达式中公开请求标识元数据来填补这一差距。

概括而言，可以评估：

idtyp：调用方标识类型（app或usernull）
appid：用于请求的客户端应用程序 ID
acrs：身份验证上下文类引用（用于检查登录上下文，如 MFA 相关值）
http://schemas.microsoft.com/identity/claims/objectidentifier：调用方对象 ID（用户或服务主体对象标识符）

Important

使用requestContext().identity时，Azure Policy强制执行仍发生在请求时（例如，denymodify和deployIfNotExists）。但是，针对该策略的合规性扫描被标记为NotApplicable。当你的目标是对传入的创建/更新操作进行实时强制，而不是部署后符合性报告时，此模式是最佳模式。

模式：使用 tryGet 安全地读取标识字段

某些请求中可能缺少身份声明。使用 tryGet()，这样在键缺失时，表达式就不会报错。

Example:

{
	"value": "[tryGet(requestContext().identity, 'idtyp')]",
	"equals": "user"
}

示例 1：仅允许批准的客户端应用

此示例将写入操作限制为仅允许来自已知客户端应用 ID 允许列表中的请求。

{
	"mode": "All",
	"parameters": {
		"allowedClientAppIds": {
			"type": "Array",
			"metadata": {
				"displayName": "Allowed client application IDs",
				"description": "List of Entra app IDs permitted to perform write operations."
			}
		}
	},
	"policyRule": {
		"if": {
			"allOf": [
				{
					"value": "[tryGet(requestContext().identity, 'appid')]",
					"notIn": "[parameters('allowedClientAppIds')]"
				}
			]
		},
		"then": {
			"effect": "deny"
		}
	}
}

此限制可用于保护自动化边界，因此只有批准的部署工具可以修改所选资源提供程序。

声明 acrs 可以包含多个逗号分隔的值。使用 split() 来评估它们。

{
	"if": {
		"allOf": [
			{
				"field": "type",
				"equals": "Microsoft.Authorization/roleAssignments"
			},
			{
				"value": "p1",
				"notIn": "[split(tryGet(requestContext().identity, 'acrs'), ',')]"
			}
		]
	},
	"then": {
		"effect": "deny"
	}
}

确切的 acrs 值取决于你的身份和条件访问设计，因此在全面推广之前，请先在你的租户中验证预期值。

示例 3：按特定调用方对象 ID 限定范围

可以检查对象标识符声明，以获取精确的允许或拒绝逻辑：

{
	"if": {
		"allOf": [
			{
				"field": "type",
				"equals": "Microsoft.Resources/subscriptions/resourceGroups"
			},
			{
				"value": "[tryGet(requestContext().identity, 'http://schemas.microsoft.com/identity/claims/objectidentifier')]",
				"notIn": "[parameters('approvedObjectIds')]"
			}
		]
	},
	"then": {
		"effect": "deny"
	}
}

此模式是严格和明确的，但它需要良好的操作卫生才能使标识列表保持最新状态。

正式上线前的设计建议

先从 audit 开始，或在禁用强制执行的情况下进行分配，以便在强制实施 deny 之前验证行为。
先在较小范围内（单个资源组或独立的订阅）进行试点，然后再大范围分配。若要详细了解分阶段发布的最佳做法，请参阅Azure Policy 分配的安全部署。
与平台和安全团队明确沟通，这些策略的合规状态为 NotApplicable。
将基于标识的规则与用于分层治理的资源配置策略配对。

总结

requestContext().identity使 Azure Policy 能够在请求时识别调用方身份，因此你不仅可以管控谁可以执行更改，还可以管控资源应呈现什么状态。

如果使用得当，它对于高影响操作是一项强有力的控制措施，尤其是在结合标准配置策略和分阶段发布实践时。

Last updated on 2026-07-24