手册

为特权 Azure AD 角色提供即时 (JIT) 访问权限，需要批准和理由。

→为该角色配置 Microsoft Entra Privileged Identity Management (PIM)。设置“激活需要批准”，指定批准者，启用“激活需要理由”，并设置最长激活持续时间。

原因: PIM 是 Azure 原生服务，用于 JIT 角色提升。仅仅让用户符合资格是不够的；策略设置强制执行批准和理由工作流。

参考↗

对所有访问敏感应用程序的用户强制执行 MFA 和合规设备，但特定帮助台组可豁免设备合规性规则。

→创建两个 Conditional Access (CA) 策略。策略 1 针对“所有用户”，排除帮助台组，要求 MFA 和合规设备。策略 2 仅针对帮助台组，仅要求 MFA。

原因: 具有排除项的单个策略将删除被排除组的所有要求。两个有针对性的策略可确保每个组获得正确、独特的控制集。

参考↗

自动响应检测到的身份风险：阻止高风险登录并强制高风险用户重置密码。

→配置两个 Microsoft Entra ID Protection 策略。将“登录风险策略”设置为在高风险级别阻止访问。将“用户风险策略”设置为在高风险级别要求更改密码。

原因: 登录风险是指单个身份验证尝试（实时），而用户风险是关于身份本身的累积得分（受损凭据）。它们需要不同的补救措施。

允许混合身份环境中的用户重置其云密码，并将其同步回本地 Active Directory。

→在 Microsoft Entra Connect 中，启用“密码写回”功能。在 Azure AD 中，为目标用户启用并配置自助密码重置 (SSPR)。

原因: SSPR 提供云端的密码重置用户界面，而密码写回是 Entra Connect 中将新密码哈希同步回本地 AD 的组件。

定期审查所有来宾用户访问权限，并自动删除不再被批准或不活跃的来宾。

→在 Microsoft Entra ID Governance 中创建访问评审。针对所有组中的来宾用户，设置定期计划（例如，每季度），并启用“自动将结果应用到资源”。可选地，审查不活跃的用户。

原因: 访问评审是用于定期重新认证访问权限的专用治理工具。“自动应用结果”功能对于完成闭环并实现自动化删除至关重要。

为外部合作伙伴提供一种自助方式，以请求一组访问权限（组、应用程序、SharePoint 站点），该访问权限在 90 天后自动过期。

→使用 Microsoft Entra Entitlement Management。为合作伙伴创建一个连接组织。创建一个包含资源的访问包。为该包定义一项策略，允许来自连接组织的用户请求访问，并设置 90 天的有效期。

原因: Entitlement Management 旨在大规模治理访问，特别是针对外部用户。它捆绑资源并自动化从请求和批准到过期和移除的整个访问生命周期。

高安全性应用程序要求用户使用可抵御网络钓鱼和中间人攻击的方法进行身份验证。

→强制实施 FIDO2 安全密钥或 Windows Hello for Business 等身份验证方法。这些方法使用公钥加密并绑定到设备，从而防止凭据被盗。

原因: 短信、语音呼叫或简单推送通知等方法容易受到网络钓鱼。FIDO2 和 WHfB 使用与请求来源绑定的加密挑战，使其能够抵御网络钓鱼。

在 VM 上运行的后台服务需要从 Microsoft Graph 读取所有用户配置文件，而无需任何用户交互。

→在 Microsoft Entra ID 中注册应用程序。在 API 权限下，授予它 Microsoft Graph 的 `User.Read.All`“应用程序”权限（而非“委派”）。管理员必须授予管理员同意。

原因: 应用程序权限允许应用程序作为自身进行操作，使用其自己的身份（客户端 ID/密钥或证书）。委派权限需要登录用户上下文，这在非交互式守护进程应用程序中不可用。

允许 AKS 集群中的 Pod 安全访问 Azure Key Vault，而无需使用存储的凭据，如客户端密钥或证书。

→使用 Azure AD Workload Identity。创建一个用户分配的托管标识，在 K8s 服务帐户和托管标识之间建立联合身份凭据，并授予托管标识访问 Key Vault 的权限。

原因: Workload Identity 使用 OIDC 联邦将 Kubernetes 令牌交换为 Azure AD 令牌，完全消除了在集群中存储、管理或轮换机密的需要。

参考↗

保护 Azure Key Vault，仅允许来自特定 VNet 的访问，记录所有操作，并防止关键密钥被意外删除。

→配置 Key Vault 防火墙，允许来自“私有终结点和选定网络”的访问。将诊断日志记录启用至 Log Analytics 工作区。同时启用软删除和清除保护。

原因: 软删除允许从意外删除中恢复，但清除保护可防止即使是特权用户在保留期内永久删除保管库或其内容。这种组合对于保护 TDE 密钥至关重要。

Azure App Service 需要对 Azure SQL Database 进行身份验证以检索数据，而无需在配置中存储连接字符串密码。

→在 App Service 上启用系统分配的托管标识。在 Azure SQL 中，创建映射到 App Service 托管标识名称的包含用户，并授予其必要的数据库角色（例如 db_datareader）。

原因: 托管标识为 Azure AD 中的 Azure 资源本身提供了一个身份。Azure 自动处理凭据的创建和轮换，消除了存储的机密，这是一项重要的安全最佳实践。

使用组织在 Azure Key Vault 中控制的密钥对 Azure VM 托管磁盘进行静态加密。

→创建一个磁盘加密集资源。将其配置为使用 Azure Key Vault 中的客户管理密钥 (CMK)。将磁盘加密集分配给 VM 的托管磁盘。

原因: 这是使用 CMK 的服务器端加密 (SSE)，它在存储基础设施中加密数据。它比 Azure Disk Encryption (ADE) 更简单，ADE 使用 BitLocker/dm-crypt 在来宾操作系统内部加密数据，通常用于同时加密操作系统和数据磁盘。

确保 Azure Container Registry (ACR) 中存储的容器镜像在部署前已扫描漏洞。

→启用 Microsoft Defender for Containers。这将在镜像被推送、被拉取以及持续不断地扫描 ACR 中的镜像，以发现新发现的漏洞。

原因: 这种“左移”安全实践在 CI/CD 管道早期发现漏洞。Defender for Containers 在 Azure 生态系统内原生提供此扫描功能。

检测并接收针对 Azure SQL Database 上潜在的 SQL injection 攻击和异常访问模式的警报。

→在逻辑 SQL 服务器上启用 Microsoft Defender for SQL。这提供了高级威胁防护和漏洞评估。

原因: Defender for SQL 是专用的工作负载保护计划，它使用行为分析和机器学习来检测 SQL injection、暴力攻击和异常数据访问等威胁，这些威胁是网络级工具无法发现的。

将存储帐户限制为特定的 VNet，但仍允许 Azure Backup 等受信任的 Microsoft 服务访问它。

→在存储帐户网络设置中，选择“从选定的虚拟网络和 IP 地址启用”。添加所需的 VNet/子网。然后，勾选“允许受信任的 Microsoft 服务访问此存储帐户”复选框。

原因: 受信任的服务例外为特定的 Microsoft 服务创建了一条安全路径，以绕过 VNet 防火墙规则。如果没有它，代表用户操作的服务（如备份或门户）将被阻止。

保护 Azure SQL 数据库中特定的敏感数据列（例如信用卡号），即使是特权数据库管理员 (DBA) 也无法访问。

→使用 Always Encrypted。客户端应用程序驱动程序在将数据发送到数据库之前透明地加密数据，并且加密密钥永远不会透露给数据库引擎。

原因: 透明数据加密 (TDE) 在静态时（在磁盘上）加密整个数据库，但有权访问的 DBA 仍然可以看到数据。Always Encrypted 提供客户端加密，将管理数据的人员 (DBA) 与能够看到数据的人员分离开来。

在 Azure VM 上处理高度敏感数据，确保即使在内存中，它也能免受管理程序和云运营商的加密和保护。

→部署 Azure Confidential VM。这些 VM 使用基于硬件的 Trusted Execution Environments (TEE)，例如 AMD SEV-SNP，来创建隔离的、加密的内存空间。

原因: 标准 VM 加密（如 ADE 或 SSE）保护静态数据。机密计算是唯一能够保护数据在内存中*使用时*的技术，可在云中提供最高级别的数据隐私和隔离。

App Service 需要使用 Key Vault 中的机密作为应用程序设置，而无需更改应用程序代码以使用 Key Vault SDK。

→在 App Service 上启用托管标识，并授予它 Key Vault 中机密的“获取”权限。在 App Service 配置中，创建一个应用程序设置，其值格式为 Key Vault 引用：`@Microsoft.KeyVault(SecretUri=...)`。

原因: 此功能允许 App Service 平台在运行时使用托管标识解析机密值。应用程序代码只需读取标准环境变量，从而抽象出 Key Vault 交互。

将合规性相关数据以 WORM（一次写入，多次读取）状态存储在 Azure Blob Storage 中，保留期为 7 年。

→在存储容器上，配置不变性策略。使用基于时间的保留策略，设置为 7 年并锁定策略。一旦锁定，在保留期到期之前，任何人都不能修改或删除数据。

原因: 此功能专门设计用于满足法规合规性要求（例如，SEC 17a-4）。锁定策略是使其真正不变的关键步骤。

在使用单个 Azure SQL 数据库的多租户应用程序中，确保一个租户的用户只能看到属于他们自己租户的数据。

→实施行级安全性 (RLS)。创建具有谓词函数的安全策略，该函数根据用户的租户 ID 过滤行，租户 ID 存储在会话上下文或用户查找表中。

原因: RLS 直接在数据库引擎内部强制执行访问逻辑。这比在应用程序层实现过滤更安全可靠，因为它无法被绕过，并且对应用程序代码是透明的。

通过确保从 UEFI 到操作系统内核的整个启动链的完整性，保护第 2 代 VM 免受启动工具包和 Rootkit 的侵害。

→启用 Trusted Launch 来预配 VM。这会激活安全启动，它会验证所有启动组件的签名，并使用虚拟可信平台模块 (vTPM) 进行测量启动和证明。

原因: Trusted Launch 旨在解决可以颠覆传统操作系统级别安全控制的复杂低级恶意软件。它为 VM 建立了硬件信任根。

隔离托管在不同子网中的应用程序层（Web、应用程序、数据）之间的流量。

→为每个子网创建一个专用的网络安全组 (NSG)。在每个 NSG 中，创建入站规则，仅允许来自前一层源 IP 范围在所需端口上的流量。（例如，应用层 NSG 允许来自 Web 层子网的 TCP/8080）。

原因: 为每个子网应用唯一且最小特权的 NSG 可提供纵深防御和对东西向流量的精细控制，这比为 VNet 设置单个复杂的 NSG 更安全。

在中心辐射型拓扑中，强制所有轮辐 VNet 之间的流量由中心中的 NVA 或 Azure Firewall 检查。

→在每个轮辐子网上，为其他轮辐的地址空间创建用户定义路由 (UDR)，并将下一跳类型设置为“VirtualAppliance”以及 NVA/Firewall 的 IP。在 NVA 的 NIC 上启用 IP 转发。

原因: 默认情况下，VNet 对等互连允许轮辐直接通信。UDR 覆盖此默认路由行为，强制流量流向中心检查点。

在您的 VNet 中为 PaaS 服务（例如 Azure SQL、Storage）提供私有 IP 地址，确保流量永不遍历公共互联网。

→在您的 VNet 中为 PaaS 服务创建 Private Endpoint。关键是，在 PaaS 服务的网络设置中，禁用公共网络访问以阻止公共终结点。

原因: Private Endpoint 将服务通过私有 IP *引入*您的 VNet。Service Endpoint 仅优化通过 Azure 主干网络到公共 IP 的路由。禁用公共访问是强制执行仅私有通信所必需的。

允许 VM 出站流量流向一组动态的 Microsoft 服务终结点，例如 Windows Update，而无需手动维护 IP 列表。

→在 Azure Firewall 中，创建一个应用程序规则集合。添加一条规则，将目标 FQDN 类型设置为“FQDN Tag”，并选择“WindowsUpdate”标签。

原因: FQDN Tag 是 Microsoft 管理的 FQDN 精选集合。这是允许访问底层 IP 经常变化的 PaaS 服务的正确方法。Service Tag 用于基于 IP 的规则。

Web 应用程序防火墙 (WAF) 由于托管规则中的误报（例如 SQL injection）而阻止了流向您应用程序的合法流量。

→在 WAF 策略中，将 WAF 保持在“预防”模式。找到阻止流量的托管规则，并为导致误报的特定请求头、Cookie 或正文参数配置排除项。

原因: 排除项是处理误报最精确的方法。它们允许您在对特定异常进行处理的同时，保持对所有其他流量的规则保护，这比禁用整个规则更安全。

提供对 Azure VM 的安全 RDP/SSH 访问，而无需将管理端口暴露给互联网或在 VM 上要求公共 IP。

→将 Azure Bastion（高级功能使用 Standard SKU）部署到 VNet 中的专用子网。通过 Azure 门户访问 VM，该门户通过 Bastion 服务进行连接。

原因: Bastion 充当安全的跳板机，代理 RDP/SSH 连接。唯一的公共 IP 位于 Bastion 服务本身，该服务由 Microsoft 进行强化和管理，从而显著减少了 VM 的攻击面。

为开发人员提供对开发 VM 上管理端口 (RDP/SSH) 的有时限、经审计的访问。

→启用 Microsoft Defender for Cloud 并为 VM 配置即时 (JIT) VM 访问。用户将通过 Defender for Cloud 请求访问，该服务动态修改 NSG 规则，以允许在有限时间内从特定 IP 访问。

原因: JIT 是 Defender for Cloud 的核心功能，它通过默认关闭管理端口，仅在按需时才打开它们来强化 VM 的网络安全态势。

在部署时，在 Azure Kubernetes Service (AKS) 群集上强制执行安全最佳实践，例如不允许特权容器。

→为 AKS 启用 Azure Policy 附加组件。分配名为“Kubernetes cluster pod security restricted standards for Linux-based workloads”的内置策略计划。

原因: 这利用 Azure Policy 作为 Kubernetes 的集中式、大规模准入控制器，在群集中甚至创建工作负载之前，强制执行安全和合规性保障。

将来自 Azure VNet 的所有互联网出站流量路由回本地安全设备进行检查，然后才到达互联网。

→配置站点到站点 VPN 或 ExpressRoute。为地址前缀 0.0.0.0/0 创建用户定义路由 (UDR)，并将下一跳设置为虚拟网络网关。

原因: 这种模式，称为强制隧道，会覆盖 Azure 默认的互联网路由，并强制所有出站流量通过网关流向本地网络，确保任何 VM 都无法绕过企业安全控制。

使用 Azure Firewall 检查来自 VM 的出站 TLS 加密流量是否存在威胁。

→部署 Azure Firewall Premium。启用 TLS 检查和入侵检测 (IDPS)。在防火墙上配置一个从属 CA 证书，并将其公钥作为受信任的根 CA 部署到客户端 VM。

原因: 要检查加密流量，防火墙必须执行中间人操作。这需要 Premium SKU、用于威胁检测的 IDPS，以及适当的证书基础设施，以避免客户端计算机上的 TLS 错误。

以经济高效的方式，保护跨多个 VNet 和订阅的所有面向公众的应用程序免受容量型 DDoS 攻击。

→创建一个 Azure DDoS Protection Plan。将此计划与所有包含需要保护的公共 IP 地址的虚拟网络相关联。

原因: 单个 DDoS Protection Plan 可以覆盖多达 100 个 VNet，您只需为该计划支付固定的月费，而不是按 VNet 或按 IP 付费。这种集中式模型比部署多个计划或使用按 IP 保护 SKU 更具成本效益。

当 Microsoft Sentinel 中创建高严重性事件时，自动禁用 Azure AD 中涉及的用户帐户，并在 Teams 中通知安全团队。

→创建一条自动化规则，在高严重性事件创建时触发。该规则应调用一个剧本 (Logic App)。该剧本使用 Azure AD 连接器禁用用户，并使用 Teams 连接器发布消息。

原因: 这展示了 SOAR（安全编排、自动化和响应）模式。自动化规则是触发/条件引擎，剧本是动作/工作流引擎。

参考↗

在大量 Azure 订阅中应用一套一致的安全策略并启用 Defender for Cloud 计划。

→将所有订阅组织在管理组下。在管理组级别分配 Azure 安全基准策略计划并启用所需的 Defender for Cloud 计划。

原因: 管理组是企业级治理的主要工具。在此级别应用的策略和设置由所有子订阅继承，确保一致性并减少管理开销。

在 Sentinel 中为首次从新国家/地区登录的用户创建自定义检测。

→创建计划查询分析规则。使用 KQL 查询，将最近的 `SigninLogs` 与过去的 `SigninLogs` 摘要历史记录联接，以识别以前未见过的 UserPrincipalName/国家/地区组合。

原因: KQL 的计划查询规则是 Sentinel 中自定义威胁检测的基础，它允许复杂的、有状态的逻辑，超越简单的事件匹配。

出于合规性原因，在 Sentinel 中保留安全日志 2 年，但仅保留最近 90 天的日志以进行快速、交互式查询，从而管理成本。

→在 Log Analytics 工作区中，将“交互式保留”设置为 90 天。将“总保留”（存档）设置为 730 天（2 年）。如果需要，可以按表配置保留策略。

原因: 这种分层方法平衡了成本和功能。交互式层昂贵但快速。存档层用于长期存储，成本非常低。存档数据仍可以通过异步搜索作业或临时恢复进行查询。

在事件调查期间，您需要快速可视化受损用户、其登录 IP 以及他们访问的资源之间的关系。

→从 Microsoft Sentinel 的事件页面，打开调查图。使用该图直观地探索不同警报和日志源中的实体及其连接。

原因: 调查图是一个强大的可视化工具，可以描绘攻击故事，使得理解事件的范围和时间线比手动关联日志查询中的事件容易得多。

检测已入侵用户帐户并正在尝试访问网络中异常资源或主机的攻击者。

→确保在 Microsoft Sentinel 中启用用户和实体行为分析 (UEBA)，并连接相关数据源（Azure AD 日志、Defender for Endpoint/安全事件）。监控 UEBA 以检测与横向移动相关的异常。

原因: UEBA 为每个用户和实体建立正常行为基线。它擅长检测指示横向移动的偏差，例如用户首次访问服务器或使用异常协议，这些情况很难通过静态规则发现。

降低 Microsoft Sentinel 对合规性所需但不需要实时分析的高容量、详细日志的引入成本。

→将这些日志的表计划配置为“基本日志”。此外，使用数据收集规则 (DCR) 结合 XPath 查询或其他转换，在引入之前过滤掉嘈杂、低价值的事件。

原因: 基本日志以有限的查询功能和较短的保留期为代价，提供了显著降低的引入成本。使用 DCR 在源头进行过滤是减少数据量的最有效方法，可防止不需要的数据进入工作区。

自动强制执行安全设置，例如在所有现有和新的 Azure 存储帐户上启用“需要安全传输”。

→分配具有 `DeployIfNotExists` 或 `Modify` 效果的 Azure 策略。对于现有不合规资源，从策略合规性边栏选项卡创建修复任务以应用更改。

原因: 审核和拒绝策略仅报告或阻止不合规。`DeployIfNotExists` 和 `Modify` 与修复任务一起主动纠正错误配置，使策略成为自动化治理和安全强化的强大工具。

检测 AKS 群集中的运行时威胁，例如可疑进程执行或容器连接到已知恶意 IP。

→启用 Microsoft Defender for Containers。这会在集群中的每个节点部署一个 DaemonSet（Defender 代理），该代理从主机和容器收集安全信号，以提供实时威胁检测。

原因: 虽然 ACR 扫描提供“左移”安全性，但运行时保护对于检测部署后发生的威胁至关重要。Defender for Containers 在集群内的主机和工作负载级别提供此可见性。