Azure Fundamentals · 课时

企业身份与访问设计

使用管理组、自定义角色和 Privileged Identity Management 设计大规模 RBAC 模型，为敏感操作强制执行即时访问。

企业身份与访问设计 是 CoddyKit 上的免费 Azure Fundamentals 课时。这是第 4 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 Azure Fundamentals 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Azure Fundamentals 课程共包含 4 节课。

企业级身份

在企业 Azure 环境中，身份和访问管理必须扩展到数百个订阅、数千名用户和数十个团队，而且每个团队都有不同的资源访问需求。设计良好的身份模型既能防止权限过度分配（用户拥有过多访问权限），也能防止权限不足（用户无法完成工作）。其基础是 Microsoft Entra ID，并结合 Azure RBAC 以及 Privileged Identity Management (PIM) 等治理工具。

重新认识 RBAC 基础

Azure 基于角色的访问控制（RBAC）通过三个组成部分授予访问权限：

安全主体——谁（用户、组、服务主体或托管身份）
角色定义——做什么（允许执行的一组操作，例如“Contributor”）
范围——在哪里（管理组、订阅、资源组或单个资源）

将这三个要素组合起来，就形成了角色分配。角色会沿层次结构继承——在管理组分配的角色适用于其下的所有订阅。

# Assign the Reader role at a management group level:
az role assignment create \
  --assignee 'user@company.com' \
  --role 'Reader' \
  --scope '/providers/Microsoft.Management/managementGroups/LandingZones'

内置角色与自定义角色

Azure 提供了 100 多个涵盖常见场景的内置角色（Owner、Contributor、Reader 以及特定服务的角色）。对于大多数企业使用场景，内置角色已经足够。不过，如果您需要的权限与任何内置角色都不匹配，例如需要一个可以读取 VMs 但不能删除 VMs 的角色，则可以遵循最小权限原则，创建具有所需精确权限的自定义角色。

# Create a custom role:
az role definition create --role-definition '{
  "Name": "VM Operator",
  "Description": "Can start and stop VMs but cannot create or delete them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/<subscription-id>"]
}'

基于组的访问分配

请尽可能将角色分配给 Entra ID 组，而不是单个用户。将角色分配给组后，所有成员都会继承该角色。此后，添加或删除访问权限只需将用户添加到组或从组中移除，而不必在多个范围内修改角色分配。这会大幅减少管理开销，并确保执行相同职能的团队成员拥有一致的访问权限。

# Create a group and assign a role to the group:
az ad group create \
  --display-name 'ProductionContributors' \
  --mail-nickname 'prod-contributors'

az role assignment create \
  --assignee '<group-object-id>' \
  --role 'Contributor' \
  --scope '/subscriptions/prod-subscription-id'

特权身份管理（PIM）

特权身份管理（PIM）是 Entra ID 的一项服务，可为 Azure 资源和 Entra ID 角色提供即时（JIT）特权访问。用户不再永久拥有 Owner 或全局管理员访问权限，而是成为特权角色的符合条件者，并在需要提升权限时请求激活。激活可能需要 MFA、理由以及指定审批者的批准。

# Workflow with PIM:
# 1. Security team makes 'alice@company.com' eligible for 'Owner' on prod subscription
# 2. Alice requests activation via PIM portal or myaccess.microsoft.com
# 3. Alice provides justification: 'Emergency patching for CVE-2026-1234'
# 4. Manager approves the request (optional step)
# 5. Alice receives Owner access for 4 hours, then access expires automatically
# 6. All activation events are logged in Entra ID audit logs

PIM 在企业中的优势

PIM 可为企业环境提供多项安全优势：

减少攻击面——不存在可能遭到入侵的永久管理员账户
审计记录——每次激活都会记录时间戳、理由和审批者
访问评审——PIM 支持定期评审，由管理者确认哪些用户应继续保留符合条件者资格
限时访问——即使访问已获批准，也会自动过期，防止遗忘已提升的权限

设计 RBAC 模型

设计良好的企业 RBAC 模型通常包含以下层级：

管理组级别——为治理团队提供广泛的查看者访问权限；分配策略
订阅级别——为管理单个订阅的应用程序团队提供团队级 Contributor 访问权限
资源组级别——特定于服务的角色（例如，仅需要 Blob 访问权限的应用程序可以使用 Storage Blob Contributor）
资源级别——仅用于需要精细控制的特殊情况

Service Principal 和托管标识

应用程序和自动化流程不应使用用户帐户向 Azure 进行身份验证。应改用：

Service Principal —— Entra ID 中的应用注册，包含客户端 ID 以及客户端密钥或证书；用于 CI/CD 管道和本地自动化
托管标识 —— 为 Azure 托管资源（VM、App Service、AKS）自动管理的凭据；无需管理或轮换机密

为 Service Principal 和托管标识分配所需的最低 RBAC 角色。

# Assign a role to a managed identity:
az role assignment create \
  --assignee-object-id '<managed-identity-object-id>' \
  --assignee-principal-type ServicePrincipal \
  --role 'Storage Blob Data Contributor' \
  --scope '/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>'

资源访问的条件访问

Entra ID 中的条件访问策略会为身份验证决策提供智能判断。在 Azure 资源管理中，您可以要求管理员访问（Azure 门户、CLI）只能在以下条件下获得允许：

符合要求的设备（由 Intune 管理）
命名位置（企业网络或 VPN）
After MFA（对特权操作始终强制执行）

将条件访问与 PIM 结合使用，可以为 Azure 管理访问建立非常强的安全态势。

访问评审

Entra ID 访问评审允许管理员定期确认用户是否仍需要已获授予的访问权限。评审可以委托给资源所有者或经理，由他们针对每位用户回答“是，此人仍需要访问权限”或“否，移除该访问权限”。访问评审可以按季度安排，并自动移除不再获得批准的访问权限，从而防止访问权限随时间不断累积。

紧急访问帐户

每个企业都应至少维护两个紧急访问（紧急解锁）帐户，即不受条件访问或 MFA 要求保护的全局管理员帐户（而是使用硬件 FIDO2 密钥）。这些帐户仅用于 Entra ID 或 MFA 系统不可用且无法访问普通管理员帐户的情况。使用紧急访问帐户时应立即触发安全警报，并接受严格审计。

快速检查

请测试您对本课程中 Microsoft Azure Fundamentals (AZ-900) 概念的理解。

课程回顾

在本课程中，您学习了：企业 RBAC 在管理组、订阅和资源组范围使用基于组的分配；特权身份管理提供即时访问，以消除永久管理员角色；应用程序身份验证应使用托管标识和Service Principal，而不是用户帐户。恭喜您，您已完成 AZ-900 学习路径中的企业架构和治理部分！

常见问题解答

「企业身份与访问设计」课时是免费的吗？

是的 — 「企业身份与访问设计」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Azure Fundamentals 课程的其余内容，请升级到 CoddyKit PRO。 Azure Fundamentals 课程共包含 4 节课。

「企业身份与访问设计」这节课中我会学到什么？

使用管理组、自定义角色和 Privileged Identity Management 设计大规模 RBAC 模型，为敏感操作强制执行即时访问。你通过在浏览器中直接运行的动手代码来练习 Azure Fundamentals，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Azure Fundamentals 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Azure Fundamentals 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 4 节课，共 4 节。

「企业身份与访问设计」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Azure Fundamentals 课中编写并运行代码吗？

能。每节 Azure Fundamentals 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 Azure Fundamentals