90DaysOfDevOps 第 30 天：Microsoft Azure 安全模型——身份、目录、RBAC 与 Azure Policy 实战-北京尧图网络

文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载导读本文是 90DaysOfDevOps 学习路径中专注一个云服务商章节的第 3 讲承接 Day 29 的 Azure 基础订阅、管理组、资源组系统讲解 Azure 的安全体系Azure AD 目录服务、混合身份同步、联合身份Federation、基于角色的访问控制RBAC、Microsoft Defender for Cloud 与 Azure Policy并给出添加自定义域名 → 创建用户 → 创建动态用户组 → 以组为单位授权 → 验证权限收敛的完整实操链路。读完你将掌握 Azure 中以租户、订阅、资源组为核心的安全模型并能独立完成最小权限原则下的用户与权限治理。为什么 Azure 的安全模型与众不同作者在实践多个公有云后发现Azure 与其他公有云最大的差异在于Azure 中永远存在 Azure ADAzure Active Directory。无论你是刚开通试用账号还是企业级大规模使用身份与访问管理都统一建立在 Azure AD 之上——这与 AWS 以 IAMIdentity Access Management为核心的安全模型有本质区别尽管两者在概念上可以类比但实现细节差异巨大。Azure AD 承载了 Azure 及其它微软云服务Microsoft 365、Dynamics 等所用的安全主体security principal是订阅、资源、用户之间所有权限关系的根基。这也是为什么学习 Azure 安全模型的第一步必须先理解目录服务。目录服务Azure AD 的核心机制认证与查询协议Azure AD 作为身份提供方通过以下标准协议完成认证与查询认证协议SAML、WS-Federation、OpenID Connect、OAuth2查询接口统一通过 REST API即Microsoft Graph API读取目录对象租户命名每个租户默认拥有tenant.onmicrosoft.com形式的默认域名同时可绑定自定义域名订阅归属每个订阅都与某个 Azure AD 租户关联租户是订阅和资源的家。Azure AD Connect混合身份同步绝大多数企业并非从零在云端创建账户而是早已在本地维护着一套Windows Server Active DirectoryAD DS。Azure AD Connect 就是打通两者的桥梁将本地 AD 中的用户账户、组、部分对象复制同步到 Azure AD同步支持粒度控制与过滤可按 OU、属性等条件筛选同步范围支持**多林multiple forests与多域domains**环境不仅能连接本地 Windows AD还能桥接其他 Azure AD、Google 等身份源并通过Azure B2B能力与外部个人/组织协作。两种身份验证方案本地 AD DS 与 Azure AD 之间做身份验证核心是身份同步密码处理的组合密码哈希同步Password Hash Synchronization将本地密码哈希同步到 Azure AD直通认证Pass-through Authentication若出于安全策略不希望同步密码哈希则必须启用直通认证——用户的登录请求会由本地 AD 直接校验。文档中特别指出密码哈希的传递是可选项若不使用它就必须启用直通认证两者是二选一的登录验证路径。联合身份Azure AD 作为联合代理如果你使用的是 Microsoft 365、Microsoft Dynamics 加本地 Active Directory将它们联合到 Azure AD 几乎是无缝的。但现实是你的应用生态里往往还有大量非微软生态的服务与目录。Azure AD 的角色不止是微软产品的身份中心它还可以作为联合代理federation broker为这些第三方应用提供身份认证。在 Azure 门户中这一能力体现在Enterprise Applications企业应用程序页面其中内置了大量现成的应用集成选项图库应用向下滚动即可看到长长的精选应用列表。同时该能力还支持自带集成bring your own无论是你正在开发的应用还是不在图库中的非图库应用non-gallery application都可以手动注册并接入联合登录。这意味着 Azure AD 可以成为企业统一的单点登录入口无论应用来自微软还是第三方。基于角色的访问控制RBAC作用域权限在哪里生效Day 29 已介绍过 Azure 的层级边界RBAC 正是按以下四个作用域之一进行授权订阅Subscription管理组Management Group资源组Resource Group资源Resource内置角色Owner / Contributor / ReaderAzure 提供大量内置角色但最核心、最常用的三类为角色能力边界关键差异Owner所有者管理范围内的一切资源可以管理角色分配、更改权限Contributor参与者管理范围内的一切资源与 Owner 范围几乎一致但不能修改权限Reader读者只读查看范围内资源仅具备查看能力除此之外还有面向特定 Azure 资源类型的专用内置角色以及按需自定义的自定义角色custom roles。作者在文档中强调日常使用中内置角色通常已经足够但了解自定义与扩展能力有助于应对复杂场景。两条黄金实践授权对象优先选组而非单个用户把权限授予组再把用户放入组便于批量管理与审计权限是继承的父级作用域如订阅的授权会向下继承到子级作用域如资源组、资源因此设计权限时要格外注意作用域层级。在资源组上查看与验证权限回到 Day 29 创建的90DaysOfDevOps资源组打开其Access Control (IAM)页面可以看到当前已分配的角色列表包括若干参与者Contributor、一个用户访问管理员User Access Administrator以及所有者Owner列表。进一步点击可查看这些角色属于**内置角色BuiltInRoles**中的哪个类别确认分配是否合理。此外IAM 页面的Check access检查访问权限选项卡可以针对某个账户核对它在当前资源组上的实际权限——既能确认目标账户该有的权限是否到位也能排查某用户是否权限过大。Microsoft Defender for Cloud统一安全态势Microsoft Defender for Cloud原Azure Security Center2022 年 1 月更名提供对整个 Azure 环境的统一安全可见性单一仪表板统一展示全部 Azure 资源与非 Azure 资源通过 Azure Arc 接入的整体安全健康状况并给出安全加固建议免费层包含持续的安全评估与安全建议本文示例即基于免费层观察推荐项付费计划按受保护资源类型计费覆盖 Servers服务器、AppService、SQL、Storage存储、Containers容器、KeyVault 等。作者在另一个订阅中打开该服务即使资源很少也能在一个界面集中看到多条安全建议——这正是它集中治理的价值所在。Azure Policy以 JSON 定义的合规与治理Azure Policy 是与 Defender for Cloud 深度集成的原生治理服务用于规模化强制组织标准并评估合规性审计不合规资源并应用自动修复remediation常见用途资源一致性治理、监管合规regulatory compliance、安全、成本与管理标准评估逻辑以JSON 格式存储判定资源是否合规并定义不合规时的处置动作支持的效果effect包括Audit、AuditIfNotExists、Deny、Modify、DeployIfNotExists免费使用唯一例外Azure Arc 连接的资源若使用 Policy 的 Guest Configuration 功能按每服务器/月计费。Policy 与 RBAC 的分工需要澄清RBAC 决定谁能做什么而 Policy 决定资源必须长什么样例如强制所有存储账户启用加密、所有 VM 归属指定区域等两者共同构成 Azure 的治理底座。Hands-On 实战从自定义域名到组级授权实操部分将前面所有概念串成一条可复现的链路全程在 Azure 门户portal.azure.com 主页中完成第 1 步添加自定义域名作者购买了www.90DaysOfDevOps.com域名并将其添加为 Azure AD 的自定义域名Azure Active Directory 门户 → 自定义域名 → 添加随后按提示在 DNS 处验证域名所有权。添加后租户即可使用该域名创建账户。第 2 步在新域上创建用户基于新的自定义域创建用户michael.cade90DaysOfDevOps.com。这类账户属于纯云账户cloud-only account——文档特别指出虽然 Azure AD 允许直接创建云账户但多数组织更倾向于让已存在本地 AD 中的用户通过 Azure AD Connect 同步上来云账户通常用于绿地场景。第 3 步创建动态用户组为所有 90DaysOfDevOps 用户创建一个统一组。创建组时关键选择是成员类型Membership typeDynamic User动态用户Azure AD 根据查询规则自动将匹配的用户加入组Assigned已分配手动逐个添加用户到组。动态组的价值在于规则查询的灵活性。本例的规则很简单匹配用户主体名User Principal Name中包含90DaysOfDevOps.com的账户。第 4 步验证规则由于michael.cade90DaysOfDevOps.com已存在可以立刻验证规则是否生效。作者还额外关联了一个属于其他域名的账户作为对照——因不满足规则该账户不会进入此组。这种对照实验是验证动态规则正确性的最佳方式。随后新增user190DaysOfDevOps.com再打开组页面即可看到两位成员都已自动入组。第 5 步将资源组 Owner 授予组回到资源组在90DaysOfDevOps资源组的 IAM 中添加角色分配把刚刚创建的组设为该资源组的 Owner。这一步完美落地了前文授权对象选组而非用户的实践——后续所有新成员只需进入这个组就自动获得资源组管理权限。同时这里也可以为资源组配置拒绝分配deny assignments进一步收缩访问边界例如某些敏感资源禁止任何继承权限生效。第 6 步以新用户视角验证权限收敛使用michael.cade90DaysOfDevOps.com登录 Azure 门户后可以看到门户只呈现90DaysOfDevOps这一个资源组之前截图中出现的其他资源组一概不可见——因为该用户没有被授予那些资源组的任何权限。这是 RBAC 生效的最直观证明。第 7 步通过 My Apps 门户验证应用访问并非所有用户都需要感知 Azure 门户。对于只需要访问应用的普通用户可以改用My Apps 门户myapps.microsoft.com——这是 Azure AD 提供的单点登录应用门户用户在此看到的是被授权的企业应用而非底层资源。该门户还支持自定义品牌brandingLogo、主题色、说明文案等可以在后续章节进一步定制。规模化控制台之外的选择上面的步骤在门户中一步步完成没问题但如果有 100 个甚至更多用户、组需要批量创建纯控制台操作显然不可持续。文档明确指出两条规模化路径批量操作Bulk operationsAzure AD 提供批量创建Bulk create、批量邀请Bulk invite、批量删除Bulk delete用户的内置入口脚本化PowerShell / Azure CLI用 PowerShell 或 Azure CLI 编写脚本实现自动化。在 Day 34 的实战中可以看到这种能力的延伸作者使用az login通过浏览器认证登录 CLI再配合 PowerShell 脚本仓库中的 Module4_90DaysOfDevOps.ps1 等批量部署虚拟网络、虚拟机、存储与 Web 应用。而 Day 34 中遇到的Network Watcher 无法访问问题恰恰是本文 RBAC 设计的真实回响——90DaysOfDevOps 组的 Owner 权限仅覆盖该资源组而 Network Watcher 这类不归属资源组的服务需要额外单独授权作者通过将 East US 的 Network Watcher Contributor 角色授予该组解决。这从实践角度再次印证了作用域是 RBAC 的边界越界资源必须显式授权。小结Azure 安全模型的骨架可以浓缩为四句话身份在 Azure AD认证协议SAML/OIDC/OAuth2、Graph API、租户与订阅关系全部以 Azure AD 为中心混合是常态Azure AD Connect 负责把本地 AD 同步到云密码哈希同步与直通认证二选一授权走 RBACOwner / Contributor / Reader 三类内置角色作用域继承授权给组实践即可覆盖大多数场景治理靠 Policy 与 DefenderPolicy 用 JSON 定义合规规则并自动修复Defender for Cloud 提供统一安全态势。下一篇将进入 Day 31Microsoft Azure Compute Models把视线从安全转向计算服务虚拟机、容器、无服务器等继续完善 Azure 云服务的知识拼图。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第 30 天Microsoft Azure 安全模型实战指南目录服务、RBAC、Defender for Cloud 与 Azure Policy90DaysOfDevOps 第 30 天Microsoft Azure 安全模型实战指南目录服务、RBAC、Defender for Cloud 与 Az文档/教程90DaysOfDevOps深入解析 Microsoft Azure 安全模型目录服务、身份联合、RBAC 与合规治理90DaysOfDevOps深入解析 Microsoft Azure 安全模型目录服务、身份联合、RBAC 与合规治理本篇基于 90DaysOfDevO文档/教程90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析90DaysOfDevOps 第33天Microsoft Azure 网络模型与 Azure 管理工具实战解析本篇指南基于 90DaysOfDevOps 项文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

90DaysOfDevOps 第 30 天：Microsoft Azure 安全模型——身份、目录、RBAC 与 Azure Policy 实战

相关推荐

DeepSeek Harness桌面端安装部署与插件Skill机制全解析

用Qt实现鼠标自动点击：从GetCursorPos到mouse_event的完整配置

实战复盘 | 基于视觉模型的多模态 RAG 系统，我们踩过的坑与收获（项目已开源）

更多资讯

浅谈 FastMCP：从 MCP Python SDK v1.0 到 v2.0 的迁移实践与 TaoToken 接入

深入解析插件加载机制：从plugin.json到TypeScript SDK的完整链路与排查实践

Playwright多浏览器初始化实战：双实例并行与隔离策略

从手工点点到自动化测试：软件测试工程师的实战进阶之路

插件加载失败深度解析：从failed to load plugins到IAR与MusicFree插件实战

插件机制深度拆解：从设计原理到 failed to load plugins 排查实操

今日更新

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？