手册

混合身份认证，其中密码哈希必须保留在本地，并带有故障转移功能。

→Azure AD Connect，启用直通身份验证 (PTA) 和密码哈希同步 (PHS) 作为备份。

原因: PTA 通过针对本地 AD 进行验证，将哈希保留在本地。如果本地 AD 或 Connect 代理不可用，PHS 提供身份验证故障转移。

参考↗

通过根据用户、位置、设备健康状况和风险强制执行精细访问控制来实施零信任。

→Microsoft Entra 条件访问策略，结合命名位置、设备合规性 (Intune) 和登录风险 (Identity Protection)，以及多重身份验证 (MFA) 等授权控制。

原因: 条件访问是零信任的强制执行引擎，在授予访问权限之前，会对每个请求的多个信号进行评估。单一策略无法对不同条件应用不同的控制。

参考↗

在数十个或数百个订阅中强制执行一致的策略（例如，标记、允许的区域）。

→一个管理组层次结构，在根管理组或父管理组级别分配 Azure Policy 计划。

原因: 管理组提供订阅之上的治理范围，允许策略被继承。计划将多个策略捆绑在一起，以简化分配。

参考↗

为管理员提供具有审批工作流和审计功能的即时 (JIT) 特权访问。

→Microsoft Entra 特权身份管理 (PIM)，使N用户具备角色资格，而非永久激活。

原因: PIM 通过要求用户在有时限的期间内激活角色来强制执行最小权限原则，并可选择 MFA、理由和审批，从而创建完整的审计跟踪。

参考↗

从多个订阅中的所有 Azure 资源收集日志，用于集中分析和查询。

→一个单一的、集中的 Log Analytics 工作区，带有资源上下文的 RBAC 用于访问控制。

原因: 集中的工作区可以实现跨订阅查询，简化管理，并避免数据重复。资源上下文的 RBAC 确保用户只能查询他们有权访问的资源的日志。

Azure 资源（例如，App Service、Function、VM）需要安全地访问其他 Azure 资源（Key Vault、SQL、Storage），而无需存储凭据。

→为计算资源分配托管标识（系统分配或用户分配），并授予其在目标资源上的 RBAC 角色。

原因: 托管标识消除了凭据管理（机密、证书），自动处理令牌获取和轮换。使用用户分配的标识可以在多个资源之间共享身份。

参考↗

自动修复由 Azure Policy 识别出的现有不合规 Azure 资源。

→使用“DeployIfNotExists”或“Modify”策略效果。对于现有资源，必须为策略分配创建修复任务，这需要具有足够权限的托管标识。

原因: 默认情况下，具有这些效果的策略仅适用于新建/更新的资源。需要一个修复任务来扫描并修复现有不合规资源。

对所有资源强制执行所需的标签，并自动从父资源组继承标签（例如，CostCenter）。

→使用带有“拒绝”效果的 Azure Policy 来强制执行所需标签，并使用带有“修改”效果的单独策略来在标签缺失时从资源组继承标签。

原因: 拒绝效果在创建时强制执行合规性。修改效果自动化标签传播，减少手动工作并确保一致性。

监控多层或微服务应用程序，以端到端追踪事务并识别性能瓶颈。

→使用 Application Insights 检测所有服务。使用应用程序地图可视化依赖关系，并使用分布式追踪进行端到端请求分析。

原因: Application Insights 是原生的 APM 解决方案，它自动关联跨组件的遥测数据，以提供事务的统一视图，并精确定位延迟问题。

管理外部合作伙伴的访问，包括请求、审批、有时限的访问和定期审查。

→Microsoft Entra ID Governance 权限管理。创建捆绑资源的访问包，定义审批工作流，设置过期策略，并安排访问审查。

原因: 为外部访问提供完整、自动化的生命周期，与手动管理访客帐户相比，减少了管理开销和安全风险。

托管服务提供商或中央 IT 团队需要管理跨多个客户/部门 Azure AD 租户的资源。

→Azure Lighthouse。将客户订阅载入，以授予管理租户具有特定 RBAC 角色的委派访问权限。

原因: Lighthouse 为跨租户管理提供了一个单一控制平面，无需切换目录或管理访客帐户，同时客户保留完全控制权和所有权。

为外部用户提供对本地 Web 应用程序的安全远程访问，无需 VPN 或将应用程序暴露给互联网。

→Microsoft Entra 应用程序代理。

原因: 应用程序代理使用轻量级的本地连接器，建立到 Azure 的出站连接。它充当反向代理，允许 Entra ID 预身份验证和安全访问，而无需应用程序上的入站防火墙规则或公共 IP。

全球分布式应用程序需要一个读写延迟低于 10 毫秒、灵活架构和 99.999% 可用性的数据库。

→启用多区域写入的 Azure Cosmos DB。分区键应选择能够均匀分布工作负载的。

原因: Cosmos DB 专为全球分布而构建，具有开箱即用的多区域写入功能，提供保证的低延迟和最高的可用性 SLA。其他数据库需要手动复制，并且无法匹配写入延迟。

将大容量 IoT 遥测数据摄取到 Cosmos DB 中，实现按设备的有效查询和旧数据的自动归档。

→使用 `/deviceId` 作为分区键。在容器上配置 TTL 以自动删除旧文档。在删除之前使用变更源 (Change Feed) 捕获数据以归档到冷存储（例如 Blob Storage）。

原因: 按 `deviceId` 分区可以将单个设备的数据共置，使查询高效。TTL 提供免费的自动删除功能。变更源 (Change Feed) 启用响应式归档管道。

为具有不可预测、突发性流量和显著空闲时间的工作负载选择一种经济高效的 Azure SQL DB 定价模型。

→使用基于 vCore 模型和无服务器计算层。

原因: 无服务器计算层根据需求自动扩展计算资源，并在空闲期间自动暂停，只按每秒使用的计算资源收费。对于间歇性工作负载，这比预配层更具成本效益。

为大型数据分析平台提供存储解决方案，该平台需要分层命名空间和目录级别的 ACL。

→Azure Data Lake Storage Gen2（启用了分层命名空间的帐户）。

原因: ADLS Gen2 针对大数据分析进行了优化，将对象存储的可扩展性与真正的分层文件系统和 POSIX 兼容的 ACL 相结合，以实现精细安全性。

根据分层要求选择存储冗余：具有读取访问权限的最大持久性、仅 DR 以及区域内数据中心故障保护。

→1. 最大持久性/读取：RA-GZRS。 2. 仅 DR：GRS。 3. 区域内：ZRS。

原因: 将冗余选项与特定的 RPO/RTO 和访问需求相匹配。RA-GZRS 是最高级别。GRS 仅用于故障转移。ZRS 可防止区域内数据中心故障。

使用统一分析平台查询数据仓库中的大型结构化数据和数据湖中的半结构化数据。

→Azure Synapse Analytics。对结构化数据使用专用 SQL 池，对数据湖上的即席查询使用无服务器 SQL 池。

原因: 这种混合方法优化了性能和成本。专用池为托管数据仓库提供高性能，而无服务器池则为数据湖中的原始数据提供按查询付费的访问。

一个用于会话状态和产品数据的缓存解决方案，需要超过 100 GB 的内存和高可用性。

→启用集群的 Azure Cache for Redis Enterprise 或 Premium 层。

原因: Premium/Enterprise 层中的集群通过在多个节点之间分片数据，使缓存能够扩展到单个节点的内存限制之外，同时也提高了吞吐量。

一种 SaaS 应用程序的数据库架构，它隔离租户，同时优化许多小型、突发性工作负载的成本。

→Azure SQL 弹性池。将租户分组到池中以共享资源，并为大型“嘈杂邻居”租户使用专用数据库。

原因: 弹性池提供了资源共享的成本效益，同时强制执行每个数据库的性能限制，在“嘈杂邻居”问题和每个租户一个数据库的高成本之间取得了平衡。

将使用 SQL Agent、跨数据库查询和 CLR 等功能的复杂本地 SQL Server 数据库迁移到 PaaS 服务。

→Azure SQL 托管实例。

原因: SQL 托管实例提供与本地 SQL Server 引擎近 100% 的兼容性，支持 Azure SQL Database 不具备的实例级功能。这非常适合以最少的代码更改进行“提升和转移”。

确保所有数据和客户管理的加密密钥保留在特定的地理边界内（例如，欧盟）。

→将所有资源部署到边界内的区域。使用带有“允许的位置”效果的 Azure Policy 来强制执行此操作。将客户管理的密钥 (CMK) 存储在也位于边界内的 Azure Key Vault 中。

原因: 需要结合物理部署位置、基于策略的强制执行和密钥驻留来满足严格的数据主权法规。

在混合数据资产（Azure、本地、其他云）中发现、分类和跟踪数据血缘。

→Microsoft Purview。

原因: Purview 提供了一个统一的数据治理解决方案，具有自动化扫描、业务术语表、分类和跨各种数据源的血缘跟踪功能。

以不可擦除、不可修改（WORM）状态存储数据（例如，财务记录）并在定义的保留期内。

→Azure Blob Storage，容器上带有基于时间的不可变策略，然后将其锁定。

原因: 锁定的不可变策略可防止任何用户（包括管理员）在保留期到期前删除或修改 Blob，从而满足严格的法规遵从性要求。

为具有几分钟 RPO 和不到一小时 RTO 的 Web 应用程序（App Service + SQL DB）设计灾难恢复解决方案。

→Azure SQL 数据库自动故障转移组、辅助 App Service 部署以及用于路由的 Azure Front Door 或 Traffic Manager。

原因: 此模式解决了每个层的 DR 问题。SQL 故障转移组处理数据复制和故障转移。预部署的 App Service 避免了部署延迟。全球路由器（Front Door/Traffic Manager）将流量导向活动区域。

串行应用程序（A -> B -> C）的复合 SLA 太低。如何改进它？

→识别具有最低单个 SLA 的组件（“薄弱环节”），并通过部署并行实例（例如，跨区域或区域中带有负载均衡器）来使其冗余。

原因: 串行链的复合 SLA 是通过乘以 SLA（SLA_A * SLA_B * SLA_C）来计算的。向组件添加并行实例可以提高其有效 SLA，这对复合 SLA 产生最大的积极影响。

在单个 Azure 区域内实现 VM 的最高可用性。

→将多个 VM 部署到该区域所有可用的可用性区域中。

原因: 可用性区域是物理上独立的数据中心，具有独立的电源、冷却和网络。这可以防止数据中心级别的故障，并提供区域内最高的 99.99% SLA。

为本地 VMware 或 Hyper-V 虚拟机提供到 Azure 的灾难恢复解决方案。

→Azure Site Recovery (ASR)。配置到 Azure 的复制，创建用于协调故障转移的恢复计划，并使用测试故障转移进行无中断的灾难恢复演练。

原因: ASR 是专为本地（和 Azure）VM 的灾难恢复复制而构建的 Azure 服务，提供连续复制、协调恢复和隔离测试功能。

为 Azure SQL Database 实现区域内最高可用性，零数据丢失 (RPO=0) 和读扩展能力。

→使用启用区域冗余的业务关键服务层。

原因: 业务关键层使用 Always On 可用性组，跨多个副本进行同步复制，提供 RPO 为 0。区域冗余将副本放置在不同的 AZ 中，以实现 99.995% 的 SLA。它包含一个可读的辅助副本。

全球应用程序必须从最近的区域为用户提供服务，并自动即时故障转移。

→使用跨多个区域的活跃-活跃部署模式，并使用 Azure Front Door 进行基于延迟的路由和基于健康探测的故障转移。

原因: Azure Front Door 提供全球任意广播路由到最低延迟的后端。其健康探测器检测区域故障并在几秒钟内自动将流量重新路由到健康的区域，从而实现无缝的活跃-活跃架构。

备份 AKS 上的有状态应用程序，包括 Kubernetes 对象定义和持久卷数据。

→使用 Azure Backup for AKS。

原因: Azure Backup for AKS 是原生解决方案，为集群状态 (etcd) 和持久卷数据（通过 CSI 快照）提供集成、基于策略的备份到安全、集中的备份保管库。

保护备份免受意外或恶意删除（包括管理员），以符合法规要求。

→在 Azure Backup 或 Recovery Services 保管库上启用不可变保管库。

原因: 不可变性是保管库级别的设置，确保备份恢复点一旦创建，在到期日期之前不能被任何人删除，从而提供最高级别的备份保护。

一个 App Service Environment v3 (ASEv3) 在一个区域托管着一个关键应用程序，并需要在另一个区域提供灾难恢复解决方案。

→在灾难恢复区域部署第二个 ASEv3。使用 Azure Front Door 进行全球负载均衡和故障转移。使用适当的技术（例如，SQL 自动故障转移组）复制数据。

原因: ASEv3 是区域部署。对于灾难恢复，您必须部署第二个 ASE 并使用像 Front Door 这样的全球路由器来管理流量。ASR 不用于 App Service 灾难恢复。

为具有集中连接（ExpressRoute/VPN）、共享服务和工作负载隔离的企业设计可伸缩网络。

→一个中心辐射型拓扑。中心 VNet 包含网关、Azure 防火墙和其他共享服务。辐射型 VNet 包含应用程序工作负载并与中心进行对等连接。

原因: 这是标准、推荐的企业模式。它集中了安全性和连接性，降低了成本和复杂性，同时辐射型网络提供了强大的工作负载隔离。

全球 Web 应用程序需要第 7 层负载均衡、Web 应用程序防火墙 (WAF)、SSL 卸载和基于 URL 的路由。

→Azure Front Door（标准版或高级版）。

原因: Front Door 是一个现代的云 CDN 和全球负载均衡器，它将这些功能集成到一个服务中，与将 Traffic Manager 与区域 Application Gateways 结合使用相比，提供了更好的性能和更简单的管理。

为多个团队设计一个生产级 AKS 集群，其中包含不同工作负载类型（CPU、GPU、内存密集型）。

→使用专用的系统节点池和多个具有不同 VM SKU 的用户节点池（例如，CPU 使用 F 系列，内存使用 E 系列，GPU 使用 N 系列）。使用集群自动扩缩器，并启用标准/高级层以获得正常运行时间 SLA。

原因: 多个节点池可以将正确的硬件与正确的工作负载匹配，以实现性能和成本效益。分离系统 Pods 可提高稳定性。财务支持的 SLA 需要标准/高级层。

事件驱动的无服务器工作流需要比 Functions 消耗计划的 10 分钟限制更长的执行时间。

→在高级计划或 App Service 计划上使用 Azure Functions，或使用 Azure Durable Functions 进行编排。

原因: 高级计划支持长达 60 分钟（默认 30 分钟）的执行时间并避免冷启动。Durable Functions 非常适合编排可能涉及人工交互或长时间等待的长时间运行、有状态工作流。

为扇出事件通知系统和可靠、有序的命令处理系统选择消息服务。

→对于扇出、反应式事件，使用 Azure Event Grid。对于可靠、事务性命令处理，使用 Azure Service Bus 队列（带会话以实现排序）。

原因: Event Grid 是一种轻量级、基于推送的事件路由服务，专为反应式编程优化。Service Bus 是一种强大的消息代理，具有 FIFO（会话）、死信和事务等功能，适用于企业消息传递。

将运行在私有 VNet 上的 API 安全地暴露给外部合作伙伴，并带有速率限制和身份验证策略。

→在内部 VNet 模式下部署 Azure API 管理 (APIM)，并由带有 WAF 的 Azure Application Gateway 作为公共入口的前端。

原因: 此模式提供深度防御。VNet 中的 APIM 可以访问私有后端。App Gateway 终止 SSL，使用 WAF 检查流量，并将其转发到私有 APIM 实例。APIM 策略处理身份验证、速率限制等。

在全球范围内连接数百个分支机构和 VNet，实现自动化、任意对任意的连接。

→Azure Virtual WAN。

原因: Virtual WAN 是微软针对大规模全球传输网络提供的托管解决方案。它自动化了复杂的路由，并为连接 VPN、ExpressRoute 和 VNet 辐射网络提供了一个统一的中心。

运行需要数千个核心和低延迟 MPI 通信的大规模并行批处理作业（例如，CFD 模拟）。

→Azure Batch，使用启用 InfiniBand 的 VM 池（例如，HB 系列），并采用低优先级（Spot）定价。

原因: Azure Batch 是专为 HPC 设计的作业调度程序。启用 InfiniBand 的 VM 提供 MPI 所需的高吞吐量、低延迟 RDMA 网络。低优先级 VM 大幅降低了容错工作负载的成本。

VNet 中的应用程序需要访问 PaaS 服务（SQL、Storage），且流量不通过公共互联网。

→为 PaaS 服务创建私有终结点。这会为服务在您的 VNet 中提供一个私有 IP 地址。

原因: 私有终结点是 PaaS 私有连接最安全的方法。它们确保流量保留在 Microsoft 主干网络上，并允许您完全禁用 PaaS 服务的公共终结点。

托管具有无服务器 API 后端、CI/CD 集成和自定义域的现代单页应用程序 (SPA)。

→Azure Static Web Apps。

原因: 这是专为此模式构建的、简化的服务。它结合了静态内容托管、用于 API 的集成 Azure Functions、GitHub/Azure DevOps 集成以及带有免费 SSL 证书的托管自定义域。

从 Azure 管理和应用治理（Azure Policy）到在本地和其他云（例如 AWS）中运行的服务器。

→在非 Azure 服务器上安装 Azure Arc 代理，将其投射为 Azure Arc 启用的服务器。

原因: Azure Arc 将 Azure 控制平面扩展到任何基础设施。一旦服务器启用 Arc，就可以像本地 Azure VM 一样使用 Azure Policy、Monitor、Defender for Cloud 等进行管理。

逐步将功能从旧的单体应用程序迁移到新的微服务，而无需“大爆炸”式切换。

→使用 Azure API 管理或 Application Gateway 等反向代理应用“绞杀者无花果”模式。

原因: 反向代理拦截对单体应用程序的调用，并有选择地将特定功能的流量路由到新的微服务。随着时间的推移，代理通过重定向越来越多的流量来“绞杀”单体应用程序，直到旧系统可以退役。

虚拟机位于强制隧道（所有互联网流量路由到本地）的 VNet 中，但它们无法访问 Azure PaaS 服务。

→强制隧道中断了对 Azure 公共终结点的直接访问。使用服务终结点或私有终结点进行 PaaS 访问。或者，为带有“Internet”下一跳的特定 Azure 服务标签添加 UDRs 以绕过隧道。

原因: PaaS 服务具有公共终结点。强制隧道将该流量发送到本地。您必须创建异常路径，可以通过将 PaaS 服务设为私有（终结点）或创建特定的路由异常（带有服务标签的 UDRs）。

中心辐射型网络需要从 Azure 解析本地 DNS 名称，并从本地解析 Azure 私有 DNS 区域。

→在中心 VNet 中部署 Azure DNS 私有解析器。配置入站终结点以供本地解析 Azure DNS，配置带转发规则集的出站终结点以供 Azure 解析本地 DNS。

原因: 这是用于混合 DNS 解析的现代化 PaaS 解决方案，取代了管理自定义 DNS 服务器 VM 的需求。它与私有 DNS 区域和本地 DNS 转发器原生集成。

多个 VNet 需要一个可预测的静态公共 IP，用于所有出站流量，以便外部服务进行白名单。

→在中心辐射型拓扑中，将所有出站流量 (0.0.0.0/0) 从辐射 VNet 路由通过中心 VNet 中的 Azure 防火墙或 NAT 网关。

原因: 在中心集中出站流量可确保所有出站流量都使用中心防火墙/NAT 网关的公共 IP，从而简化管理和外部白名单。NAT 网关对于纯 SNAT 更简单，而防火墙则增加了安全检查。

以在内存中使用时也加密的方式处理高度敏感数据，保护其免受云运营商的影响。

→使用带 Intel SGX 或 AMD SEV-SNP 的 Azure 机密计算虚拟机 (DCsv3/ECsv3 系列) 在基于硬件的可信执行环境 (TEE) 或加密内存中运行代码。

原因: 机密计算解决了安全性的“使用中数据”支柱，这是传统的静态加密和传输中加密无法做到的。它提供了可验证的硬件级别隔离。

SaaS 提供商需要将其在自身 VNet 中运行的服务，完全通过 Azure 私有网络，暴露给客户 VNet 中的客户。

→提供商在其标准负载均衡器上创建 Azure Private Link 服务。客户在其 VNet 中创建连接到该服务的私有终结点。

原因: Private Link 是安全、私有、跨租户服务暴露的明确模式。它避免了公共互联网暴露、IP 重叠问题和复杂的 VNet 对等配置。