手册

根据用户属性（例如，部门）自动管理安全组的成员资格。

→配置一个 Microsoft Entra ID 安全组，其成员资格类型为“动态用户”，并定义基于属性的规则。

原因: 基于属性的规则消除了用户生命周期变更的持续手动管理。需要 Entra ID P1/P2。

参考↗

从单一管理点对多个订阅应用一致的治理（策略、RBAC）。

→创建一个管理组，将订阅置于其下，并在管理组范围分配策略或 RBAC 角色。

原因: 策略和角色分配会由所有子订阅继承，从而实现集中且一致的治理。

参考↗

防止在整个订阅中在未经授权的 Azure 区域部署资源。

→在订阅范围分配具有 `Deny` 效果的内置“允许的位置”Azure Policy。

原因: 策略提供预防性治理。RBAC 控制操作，而非部署位置。资源锁防止修改/删除，而非新的部署。

授予管理 VM 的权限，但不授予管理底层虚拟网络或用户访问的权限。

→在资源组或 VM 范围分配内置的“虚拟机参与者”角色。

原因: 此角色提供特定的 VM 管理权限（启动、停止、重新映像），而无需授予广泛的 Contributor 或 Owner 权限。

当用户从公司网络外部访问特定云应用（例如 Azure 门户）时，要求进行 MFA。

→创建条件访问策略，其中包含公司 IP 的“命名位置”作为排除条件，并要求 MFA 作为授权控制。

原因: 排除受信任位置是绕过公司网络上的 MFA，同时在其他所有地方强制执行 MFA 的关键。

参考↗

防止删除关键资源，即使是具有 Owner 角色的管理员。

→对资源或其资源组应用 `CanNotDelete` 或 `ReadOnly` 资源锁。

原因: 资源锁适用于所有用户，无论其 RBAC 角色如何，可提供最强的保护，防止意外删除。

自动修复 Azure Policy 识别的现有不合规资源（例如，添加缺失的标记）。

→对于具有 `Modify` 或 `DeployIfNotExists` 效果的策略，为策略分配创建修复任务。

原因: 修复任务触发策略对所有现有不合规资源的纠正措施，自动化将环境带入合规状态的过程。

按部门、项目或业务部门报告 Azure 成本。

→对所有资源应用一致的标记（例如，“CostCenter”）。使用 Azure Cost Management 按该标记筛选和分组成本。

原因: 标记是跨不同资源组和订阅进行自定义成本分配和报告的主要机制。

仅在需要时，在有限时间内，通过审批工作流授予管理员特权角色。

→使用 Microsoft Entra Privileged Identity Management (PIM)。使符合条件的用户具有角色并配置激活要求。

原因: PIM 强制实施 Just-In-Time (JIT) 访问，减少了常设特权帐户的暴露，并提供了完整的审计跟踪。

允许外部合作伙伴使用其自己的公司凭据访问 Azure 资源。

→使用 Microsoft Entra B2B 协作邀请合作伙伴作为访客用户到您的租户。

原因: B2B 避免在您的租户中创建和管理新凭据；合作伙伴使用其现有的身份提供者进行身份验证。

最小化很少访问但必须保留的长期数据（例如合规性档案）的存储成本。

→使用 blob 生命周期管理策略自动将 blob 从热/冷层过渡到存档层。

原因: 存档层的存储成本最低。生命周期规则根据 blob 的年龄或上次访问时间自动分层过程。

参考↗

在主区域中断期间，确保从辅助区域读取存储数据。

→使用读访问异地冗余存储 (RA-GRS) 或 RA-GZRS 配置存储帐户。

原因: 标准 GRS/GZRS 复制数据，但在故障转移之前不允许读取辅助数据。“RA”前缀是持续读取访问所必需的。

能够立即撤销特定容器的一组共享访问签名 (SAS) 令牌。

→根据容器上存储的访问策略创建 SAS 令牌。要撤销，请修改或删除该策略。

原因: 修改存储的访问策略会立即使所有与其关联的 SAS 令牌失效，从而提供集中式撤销机制。

将本地文件服务器与 Azure 文件共享同步，同时最大程度地减少本地磁盘空间使用。

→部署 Azure 文件同步并在服务器终结点上启用云分层。

原因: 云分层仅将频繁访问的（“热”）文件缓存在本地，而较少使用的文件则分层到 Azure，在本地服务器上显示为存根。

将存储帐户的网络访问限制为特定的 VNet 子网和公共 IP 地址。

→启用存储帐户防火墙。为子网添加虚拟网络规则，并为公共 IP 添加 IP 地址规则。

原因: 存储防火墙直接在存储帐户的公共终结点上提供网络级访问控制，阻止所有其他流量。

通过允许在指定期限内恢复，保护 blob 免受意外删除。

→在存储帐户上启用 blob 软删除并配置保留期限（例如，14 天）。

原因: 软删除在配置的期限内保留已删除的 blob，允许简单的取消删除。这是防止意外数据丢失的第一道防线。

满足合规性要求，以不可擦除、不可修改 (WORM) 状态存储数据一段固定时间。

→在 blob 容器上配置基于时间的保留策略并锁定该策略。

原因: 锁定的基于时间的保留策略使 blob 不可变，阻止任何人在保留期限到期之前删除或修改（包括管理员）。

当网络带宽有限时，将非常大的数据集（例如 50+ TB）迁移到 Azure Blob Storage。

→使用 Azure Data Box 物理设备进行离线传输。

原因: 对于大型数据集，通过物理设备传输数据比通过慢速或饱和的网络连接传输数据要快得多。

为 VM 实现 99.99% 的 SLA，并保护应用程序免受区域内单个数据中心故障的影响。

→在同一区域内跨不同的可用性区域部署多个 VM 实例。

原因: 可用性区域是物理上独立的数据中心。可用性集仅保护单个数据中心内的机架级故障（99.95% SLA）。

参考↗

在全面发布之前，通过实时生产流量部署和测试新的应用程序版本，实现零停机时间。

→使用 App Service 部署槽。部署到槽，测试，然后执行交换。可以选择使用流量路由进行金丝雀测试。

原因: 槽提供了一个完整的暂存环境。交换操作是近乎即时的流量重定向，确保零停机时间。

在不进行基础设施管理且成本最低的情况下，按计划运行一个短生命周期的容器化批处理作业。

→使用 Azure 容器实例 (ACI)。

原因: ACI 提供按秒计费且无群集管理开销，使其成为零星或短生命周期容器工作负载最具成本效益的选项。

自动缩放具有可预测的日常峰值（例如工作时间）的工作负载，同时也能处理意外的峰值。

→使用基于计划的规则和基于指标的规则配置 VM 规模集自动缩放。

原因: 结合主动（计划）和被动（指标）扩展提供了性能（高峰前准备就绪）和成本效率（空闲时缩减）的最佳平衡。

将 Azure Kubernetes Service (AKS) 群集的容器映像安全地存储在具有漏洞扫描功能的私有注册表中。

→使用 Azure 容器注册表 (ACR) Premium SKU 并使用托管标识将其与 AKS 集成。

原因: ACR 提供位于 Azure 中的私有注册表。Premium SKU 包含漏洞扫描。托管标识提供从 AKS 到 ACR 的安全、无凭据身份验证。

在不导致应用程序停机的情况下，对所有 VMSS 实例执行操作系统或应用程序更新。

→更新 VMSS 模型（例如，新映像版本）并使用滚动升级策略。

原因: 滚动策略以可配置的批次更新实例，确保在整个更新过程中始终有一部分实例可用于提供流量。

部署一个必须共享网络和存储的多容器应用程序（例如，应用 + 日志记录 sidecar），而无需完整的编排器。

→将容器部署到单个 Azure 容器实例 (ACI) 容器组中。

原因: 容器组共置多个容器，共享本地主机网络和卷，非常适合 sidecar 模式，而无需 Kubernetes 的复杂性。

在 VM 部署后增加其操作系统或数据磁盘的大小。

→解除分配 VM，在 Azure 中调整磁盘资源大小，启动 VM，然后在客户操作系统内部扩展分区。

原因: 调整 Azure 磁盘大小仅分配更多空间。必须指示客户操作系统通过扩展其文件系统分区来使用新空间。

允许 App Service 安全地从 Azure Key Vault 访问机密，而无需在应用程序中存储凭据。

→在 App Service 上启用系统分配的托管标识，并授予该标识对 Key Vault 机密的 `Get` 和 `List` 权限。

原因: 托管标识提供了一种无凭据的身份验证机制。应用程序可以自动获取 Key Vault 的访问令牌，从而消除了机密管理。

将大型复杂的 Infrastructure-as-Code 部署组织成更小、可重用和可维护的组件。

→将部署重构为 Bicep 模块，每个模块代表一个逻辑单元（例如网络、计算），并从主 Bicep 文件中进行编排。

原因: 模块促进代码重用，提高可读性，并简化复杂基础设施部署的管理。

在 VNet 内隔离应用程序层（Web、应用、数据），防止非相邻层之间的直接通信。

→为每个层使用单独的子网，并对每个子网应用网络安全组 (NSG) 以控制流量流。

原因: NSG 允许基于源/目标 IP 范围（子网）、端口和协议进行细粒度、有状态的过滤，从而实现网络微细分。

通过 Microsoft 骨干网络私下连接不同 Azure 区域中的两个 VNet。

→在两个 VNet 之间配置全局 VNet 对等。

原因: 全局对等比 VNet 到 VNet VPN 连接更简单、延迟更低、带宽更高。流量保留在 Microsoft 私有网络上。

VNet-A 与 Hub-VNet 对等，Spoke-VNet 也与 Hub-VNet 对等。VNet-A 中的 VM 无法访问 Spoke-VNet 中的 VM。

→原因是 VNet 对等是非传递的。要启用通信，请直接对等 VNet-A 和 Spoke-VNet，或在 Hub 中使用 NVA。

原因: 对等不会创建链式连接。每个 VNet 必须直接连接才能通信，除非配置通过网络虚拟设备路由。

通过公共互联网从本地网络到 Azure VNet 建立持久、加密的 IPsec 隧道。

→在 VNet 中部署 Azure VPN 网关并配置 Site-to-Site (S2S) 连接。

原因: 这是单个本地站点与 Azure VNet 之间混合连接的标准、安全和可靠的解决方案。

Azure 负载均衡器继续将流量发送到不健康的后端 VM，导致应用程序超时。

→在负载均衡器上配置运行状况探测，该探测准确检查后端 VM 上应用程序的运行状况。

原因: 负载均衡器完全依赖运行状况探测来检测不健康的实例。如果没有正确配置的探测，它无法将失败的 VM 从流量轮换中移除。

根据 URL 路径（例如，/images/* vs /api/*）将 HTTP/S 流量路由到不同的后端服务器池。

→使用具有基于路径的路由规则的 Azure 应用程序网关。

原因: 应用程序网关是第 7 层负载均衡器，它检查 HTTP 请求并可以根据 URL 路径做出路由决策。标准 Azure 负载均衡器是第 4 层，无法做到这一点。

具有自定义 DNS 服务器的 VNet 中的 VM 无法解析 Azure Private DNS Zone 中的主机名。

→配置自定义 DNS 服务器，有条件地将私有区域的查询转发到 Azure 提供的 DNS 解析器 IP (168.63.129.16)。

原因: 当使用自定义 DNS 服务器时，它会绕过 Azure 的内部 DNS。必须通过将请求转发到 Azure DNS 来教会自定义服务器如何解析特定于 Azure 的区域。

强制所有来自 spoke VNet 的出站互联网流量由中心 VNet 中的中央 Azure 防火墙检查。

→将带有用户定义路由 (UDR) 的路由表应用于 spoke 子网。UDR 是指向防火墙私有 IP 的默认路由 (0.0.0.0/0)。

原因: UDR 覆盖了 Azure 到互联网的默认系统路由，允许您控制和集中出口流量流以进行安全检查。

为没有公共 IP 地址的 VM 提供安全的 RDP/SSH 访问，而无需配置 VPN。

→将 Azure Bastion 部署到 VNet 中的专用子网 (AzureBastionSubnet)。

原因: Bastion 提供托管跳转盒服务，允许通过 Azure 门户通过 TLS 进行安全管理访问，从而消除了 VM 上的公共 IP 暴露。

确保 VM 和 PaaS 服务（例如 Azure SQL）之间的流量保留在私有网络上，并且 PaaS 服务无法公开访问。

→在 VM 的 VNet 中为 PaaS 服务创建私有终结点，并禁用 PaaS 服务的公共网络访问。

原因: 私有终结点为 PaaS 服务提供了 VNet 中的私有 IP，同时禁用公共访问确保它只能通过该私有 IP 访问。

将全球用户路由到最近的区域应用程序终结点，以确保尽可能低的延迟。

→使用 Azure 流量管理器并采用“性能”路由方法。

原因: 性能路由方法使用 DNS 将客户端引导至距离其位置网络延迟最低的终结点。

当资源指标（例如，VM CPU 百分比）在设定的持续时间内超过阈值时，发送通知（电子邮件、SMS、Webhook）。

→在 Azure Monitor 中创建指标警报规则，并将其链接到定义通知操作的操作组。

原因: 这是标准模式。警报规则定义条件（什么/何时），操作组定义结果通知（谁/如何）。

确定两个 VM 之间的流量是否被特定的网络安全组 (NSG) 规则阻止。

→使用 Azure Network Watcher 中的 IP 流验证工具。

原因: IP 流验证模拟数据包流，并明确报告是哪个 NSG 和规则允许或拒绝了流量，使其成为解决 NSG 冲突的明确工具。

为 Azure VM 配置计划的、基于策略的备份，具有应用程序一致性和长期保留。

→创建恢复服务保管库，定义备份策略（计划、保留），并为目标 VM 启用备份。

原因: 恢复服务保管库是 Azure 备份的中央管理实体。它安全地存储备份数据并管理所有备份和恢复操作。

参考↗

创建集中式仪表板，以监视跨多个订阅的 VM 性能（CPU、内存、磁盘、网络）。

→部署一个中央 Log Analytics 工作区，并为所有目标 VM 启用 VM Insights，将它们指向该工作区。

原因: VM Insights 收集和聚合性能数据，提供预构建的工作簿和跨订阅的整合“大规模”性能视图。

主动识别未充分利用的 Azure 资源和节省成本的机会（例如，VM 调整大小）。

→定期查看 Azure Advisor 中的成本建议。

原因: Azure Advisor 自动分析资源使用情况，并提供可操作的个性化成本节约建议，无需额外配置。

将 Azure VM 从主区域复制到辅助区域，以提供灾难恢复能力。

→使用 Azure Site Recovery。创建恢复服务保管库并为 VM 启用到目标区域的复制。

原因: ASR 是用于编排 VM 复制、故障转移测试以及 Azure 区域之间故障转移/故障回复的原生 Azure 服务。

在单个 Log Analytics 工作区内为安全日志和性能日志设置不同的数据保留期，以优化成本。

→设置工作区级别的默认保留期，然后在单个表级别配置更长的保留期（例如，对于 SecurityEvent 表）。

原因: 按表保留允许您满足特定数据的长期合规性需求，同时最小化不那么关键、高容量数据的存储成本。