企业官网建设流程全解析

• 文档/教程

导读：本文是 90DaysOfDevOps 学习路径中"专注一个云服务商"章节的第 3 讲，承接 Day 29 的 Azure 基础（订阅、管理组、资源组），系统讲解 Azure 的安全体系：Azure AD 目录服务、混合身份同步、联合身份（Federation）、基于角色的访问控制（RBAC）、Microsoft Defender for Cloud 与 Azure Policy，并给出"添加自定义域名 → 创建用户 → 创建动态用户组 → 以组为单位授权 → 验证权限收敛"的完整实操链路。读完你将掌握 Azure 中以租户、订阅、资源组为核心的安全模型，并能独立完成最小权限原则下的用户与权限治理。

为什么 Azure 的安全模型与众不同

作者在实践多个公有云后发现：Azure 与其他公有云最大的差异在于Azure 中永远存在 Azure AD（Azure Active Directory）。无论你是刚开通试用账号，还是企业级大规模使用，身份与访问管理都统一建立在 Azure AD 之上——这与 AWS 以 IAM（Identity & 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 Directory（AD DS）。Azure AD Connect 就是打通两者的桥梁：

• 将本地 AD 中的用户账户、组、部分对象复制（同步）到 Azure AD；
• 同步支持粒度控制与过滤（可按 OU、属性等条件筛选同步范围）；
• 支持**多林（multiple forests）与多域（domains）**环境；
• 不仅能连接本地 Windows AD，还能桥接其他 Azure AD、Google 等身份源，并通过Azure B2B能力与外部个人/组织协作。

两种身份验证方案

本地 AD DS 与 Azure AD 之间做身份验证，核心是"身份同步 + 密码处理"的组合：

1. 密码哈希同步（Password Hash Synchronization）：将本地密码哈希同步到 Azure AD；
2. 直通认证（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 / Reader

Azure 提供大量内置角色，但最核心、最常用的三类为：

除此之外，还有面向特定 Azure 资源类型的专用内置角色，以及按需自定义的自定义角色（custom roles）。作者在文档中强调，日常使用中内置角色通常已经足够，但了解自定义与扩展能力有助于应对复杂场景。

两条黄金实践

1. 授权对象优先选组而非单个用户：把权限授予"组"，再把用户放入组，便于批量管理与审计；
2. 权限是继承的：父级作用域（如订阅）的授权会向下继承到子级作用域（如资源组、资源），因此设计权限时要格外注意作用域层级。

在资源组上查看与验证权限

回到 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 Center，2022 年 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.cade@90DaysOfDevOps.com。这类账户属于纯云账户（cloud-only account）——文档特别指出：虽然 Azure AD 允许直接创建云账户，但多数组织更倾向于让已存在本地 AD 中的用户通过 Azure AD Connect 同步上来，云账户通常用于绿地场景。

第 3 步：创建动态用户组

为所有 90DaysOfDevOps 用户创建一个统一组。创建组时关键选择是成员类型（Membership type）：

• Dynamic User（动态用户）：Azure AD 根据查询规则自动将匹配的用户加入组；
• Assigned（已分配）：手动逐个添加用户到组。

动态组的价值在于规则查询的灵活性。本例的规则很简单：匹配用户主体名（User Principal Name）中包含@90DaysOfDevOps.com的账户。

第 4 步：验证规则

由于michael.cade@90DaysOfDevOps.com已存在，可以立刻验证规则是否生效。作者还额外关联了一个属于其他域名的账户作为对照——因不满足规则，该账户不会进入此组。这种"对照实验"是验证动态规则正确性的最佳方式。

随后新增user1@90DaysOfDevOps.com，再打开组页面即可看到两位成员都已自动入组。

第 5 步：将资源组 Owner 授予组

回到资源组，在90DaysOfDevOps资源组的 IAM 中添加角色分配：把刚刚创建的组设为该资源组的 Owner。这一步完美落地了前文"授权对象选组而非用户"的实践——后续所有新成员只需进入这个组，就自动获得资源组管理权限。

同时，这里也可以为资源组配置拒绝分配（deny assignments），进一步收缩访问边界（例如某些敏感资源禁止任何继承权限生效）。

第 6 步：以新用户视角验证权限收敛

使用michael.cade@90DaysOfDevOps.com登录 Azure 门户后可以看到：门户只呈现90DaysOfDevOps这一个资源组，之前截图中出现的其他资源组一概不可见——因为该用户没有被授予那些资源组的任何权限。这是 RBAC 生效的最直观证明。

第 7 步：通过 My Apps 门户验证应用访问

并非所有用户都需要感知 Azure 门户。对于只需要访问应用的普通用户，可以改用My Apps 门户（myapps.microsoft.com）——这是 Azure AD 提供的单点登录应用门户，用户在此看到的是被授权的企业应用而非底层资源。

该门户还支持自定义品牌（branding）（Logo、主题色、说明文案等），可以在后续章节进一步定制。

规模化：控制台之外的选择

上面的步骤在门户中一步步完成没问题，但如果有 100 个甚至更多用户、组需要批量创建，纯控制台操作显然不可持续。文档明确指出两条规模化路径：

1. 批量操作（Bulk operations）：Azure AD 提供批量创建（Bulk create）、批量邀请（Bulk invite）、批量删除（Bulk delete）用户的内置入口；
2. 脚本化（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 安全模型的骨架可以浓缩为四句话：

1. 身份在 Azure AD：认证协议（SAML/OIDC/OAuth2）、Graph API、租户与订阅关系全部以 Azure AD 为中心；
2. 混合是常态：Azure AD Connect 负责把本地 AD 同步到云，密码哈希同步与直通认证二选一；
3. 授权走 RBAC：Owner / Contributor / Reader 三类内置角色 + 作用域继承 + "授权给组"实践，即可覆盖大多数场景；
4. 治理靠 Policy 与 Defender：Policy 用 JSON 定义合规规则并自动修复，Defender for Cloud 提供统一安全态势。

下一篇将进入 Day 31：Microsoft Azure Compute Models，把视线从安全转向计算服务（虚拟机、容器、无服务器等），继续完善 Azure 云服务的知识拼图。

• 文档/教程