通过

标识管理

标识管理通过控制谁（用户、应用程序、服务）可以访问哪些资源来建立云安全的基础。 与依赖于网络边界和静态凭据的传统基于外围的安全性不同，新式云环境要求跨分布式多租户体系结构进行动态身份验证、持续身份验证和上下文感知访问决策。 实施全面的标识治理的组织会阻止基于凭据的攻击、未经授权的访问和特权提升，而那些忽视标识控制的组织将面临帐户泄露、横向移动和利用弱身份验证或过度权限的持久性威胁。

下面是 Identity Management 安全域的四大核心支柱。

保护用户的身份：通过集中式身份管理、强大的多重身份验证、完整的生命周期管理，以及包括特权访问工作站（PAW）和紧急访问（紧急解锁）帐户的安全访问方法，建立和维护所有用户账户的安全性，特别是特权用户的账户。

相关控件：

保护应用程序和机密： 通过自动化标识管理、适当的服务器和服务身份验证以及保护机密管理来保护非人类标识（应用程序、服务），以防止凭据泄露。

相关控件：

安全访问： 确保身份具有适当的资源访问权限，遵循最低特权原则，避免持久特权，并基于实时风险评估利用基于上下文的访问控制。

相关控件：

IM-1：在确保隔离的同时集中标识和身份验证

Azure Policy： 请参阅 Azure 内置策略定义：IM-1。

安全原则

使用集中式标识和身份验证系统来管理组织的云和非云资源的标识和身份验证。

在集中管理身份和认证的同时，还应确保根据企业范围的策略进行身份的隔离和孤立。 目标是确保使用凭据和标识来管理生产环境，这些凭据和标识与用于日常访问的凭据和标识分开。 基于企业整体战略来分离和隔离身份可能包括：

  • 为身份强制实施最低特权访问
  • 隔离管理身份和非管理身份
  • 跨环境隔离标识
  • 实现工作负荷标识隔离
  • 在各租户间强制实施身份边界分离

待缓解风险

  • 未经授权的访问： 分散式或本地身份验证系统通常会导致安全策略、弱密码做法或未受监视的帐户不一致，使攻击者能够利用配置不当或过时的凭据来访问敏感资源（例如，通过暴力破解或被盗凭据）。
  • 凭据被盗和重用： 碎片化标识系统会增加凭据不安全（例如纯文本或弱哈希）或跨系统重复使用的风险，使攻击者能够从一个被入侵的系统中获取凭据，并在其他位置使用凭据（例如，通过网络钓鱼或凭据转储）。
  • 不一致的访问控制： 如果没有集中式治理，不同的系统可能有不同的访问策略，导致攻击者可以利用这些策略提升特权或访问未经授权的资源。
  • 缺乏可见性和监视： 分散式身份验证缺乏统一的日志记录和监视，因此很难检测可疑活动，例如未经授权的登录尝试或异常用户行为，从而增加未检测到违规的风险。

MITRE ATT&CK

  • 初始访问（TA0001）：利用弱或分散式身份验证机制（例如具有默认凭据或过时协议的本地帐户），使攻击者能够获得未经授权的进入（例如 T1078 - 有效帐户）。
  • 凭据访问（TA0006）：从碎片标识系统窃取凭据、利用不安全存储（例如本地系统中的纯文本密码）或弱身份验证方法，促进凭据转储或重复使用（例如 T1003 - OS 凭据转储）。
  • 特权提升（TA0004）：利用非集中式系统中不一致的访问控制来利用过度特权或孤立的帐户，使攻击者能够提升对敏感资源（例如 T1078 - 有效帐户）的访问权限。
  • 防御逃避（TA0005）：由于缺乏集中监视，绕过检测，使攻击者能够在不触发警报（例如 T1562 - 削弱防御）的情况下执行未经授权的操作。

IM-1.1：集中标识和身份验证

集中式标识管理通过跨所有资源提供一致的策略强制、统一监视和简化访问控制，消除了分片身份验证系统的安全风险。 新式云环境需要单个权威标识源，该源支持强身份验证方法、条件访问策略和全面的审核日志记录。 采用集中式标识系统的组织可减少凭据蔓延，提高安全态势可见性，并简化合规性，同时保持混合和多云体系结构的灵活性。

使用以下方法实现集中式标识管理：

  • 云标识平台采用： Microsoft Entra ID 是 一种多租户的基于云的标识和访问管理服务，可为支持 Entra ID 的Microsoft和非Microsoft环境集中进行身份验证、授权和管理。 标准化 Microsoft Entra ID 用于管理所有资源的身份。

  • 管理云资源标识： 对Microsoft云资源（包括 Azure 存储、Azure 虚拟机（Linux 和 Windows）、Azure Key Vault、PaaS 和 SaaS 应用程序使用托管标识和工作负荷标识联合，以消除机密并确保隔离。

  • 集中组织资源身份验证： 利用单一登录（SSO）和条件访问（例如托管在 Azure 上的应用程序、企业网络上的第三方应用程序和第三方 SaaS 应用程序）提供安全的上下文感知访问。

  • 同步混合标识： 通过 Microsoft Entra Connect Sync 将本地 Active Directory 与 Microsoft Entra ID 同步 ，以保持企业标识的一致集中托管混合标识策略。

  • 消除 Azure 服务的本地身份验证： 避免使用 Azure 服务的本地身份验证方法，并使用 Microsoft Entra ID 集中身份验证，使用无密码方法（例如 Windows Hello、FIDO2 密钥）和多重身份验证（MFA）来增强安全性。

注意： 与 Active Directory 解决方案相比，Microsoft Entra 提供强身份验证、条件访问策略等的优势。在技术上可行后，应使用内部用户的员工租户、Microsoft Entra B2B 进行合作伙伴协作的配置，或为面向使用者的应用 Microsoft Entra 外部 ID 等配置，将基于本地 Active Directory 的应用程序迁移到 Microsoft Entra ID。 还可以对需要自定义属性的旧应用利用 Microsoft Entra 域服务。

实现示例

场景： 金融服务组织需要集中标识管理，在生产、开发和合作伙伴环境之间严格隔离，以遵守法规并防止横向移动。

实现步骤：

  1. 将 Microsoft Entra ID 部署为集中式标识提供者：

    • 为企业标识创建主租户 （contoso.onmicrosoft.com）
    • 配置 Microsoft Entra Connect Sync 以同步本地 AD 用户
    • 为风险基础策略和条件访问启用 Entra ID 保护，要求管理员进行多重身份验证 (MFA)
    • 为 SaaS 应用配置 SSO（Salesforce、ServiceNow、GitHub）
    • 为 Azure 资源部署托管标识，消除 Azure SQL/存储上的本地身份验证
    • 使用 FIDO2 密钥 和 Windows Hello 启用无密码身份验证

  2. 设计用于隔离的管理组层次结构：

Tenant Root Group
├── Corporate Production (finance-prod-sub, hr-prod-sub)
├── Corporate Non-Production (dev-sub, test-sub)
├── Partner Integration (partner-sub)
└── Customer-Facing Tenant (customer-prod-sub, customer-staging-sub)

  1. 实现标识隔离：

    • 生产标识： 具有 PAW 的专用管理员帐户，无需开发/测试访问权限
    • 开发标识： 仅在开发中具有提升权限的标准帐户
    • 合作伙伴标识：Microsoft Entra B2B 具有限时访问权限
    • 客户标识：使用 Microsoft Entra 外部 ID 分隔租户

  2. 强制实施订阅级隔离：

    • 在订阅范围分配 Azure RBAC（prod-admin-group：仅限 finance-prod-sub 的所有者）
    • 实施要求设备合规才能进行生产访问的条件访问策略
    • 在管理组级别为安全基线配置 Azure Policy
    • 为每个环境启用单独的 Log Analytics 工作区

  3. 实现安全控制：

    • 使用订阅边界隔离计费、资源和权限
    • 部署 Azure 防火墙 以限制环境间流量
    • 为 Defender for Cloud 启用统一安全监视
    • 将 Entra ID 审核日志流式传输到 Azure Monitor，针对跨环境访问尝试发出警报
    • 使用 Entra ID 治理进行季度访问评审

结果：

组织建立了一个集中式标识平台来管理所有身份验证，消除了碎片标识孤岛。 通过严格的环境分离，生产凭据与开发人员访问完全隔离，确保开发凭据泄露不会影响生产工作负荷。 在所有环境中都强制实施一致的 MFA 和条件访问策略，同时通过全面的审核线索和职责隔离来维护法规遵从性。

参考：Microsoft Entra ID 初学者教程

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AC-2、AC-3、AC-4、AC-6、SC-2、SC-7
  • PCI-DSS v4： 1.4.2、7.2.1、7.2.2、8.2.1
  • CIS 控件 v8.1： 6.7、12.5、16.1
  • NIST CSF v2.0： PR.AA-1、PR.AC-1、PR.AC-7
  • ISO 27001：2022： A.5.15、A.5.16、A.8.2
  • SOC 2： CC6.1、CC6.2、CC6.6

IM-2：保护标识和身份验证系统

Azure Policy： 请参阅 Azure 内置策略定义：IM-2。

安全原则

在组织的云安全实践中，将标识和身份验证系统作为高优先级保护。 常见安全控制包括：

  • 限制特权角色和帐户
  • 要求对所有特权访问进行强身份验证
  • 监视和审核高风险活动

待缓解风险

  • Credential-Based 攻击：未实现的身份验证、旧式协议（例如 POP3、IMAP）和不安全的 OAuth 2.0 许可流会创建可利用的访问点，使攻击者能够入侵凭据或令牌（例如，通过暴力破解、网络钓鱼或 OAuth 许可滥用）渗透系统。
  • 特权提升：过度预配的 RBAC 角色、持久性特权访问和过度的全局管理员分配可实现未经授权的权限提升，攻击者通过帐户接管或特权属性证书（PAC）滥用来提升访问权限。
  • 资源边界冲突：订阅治理不一致且缺乏环境隔离允许跨资源访问，攻击者通过横向移动（例如利用配置不当的服务主体）攻击开发、测试或生产边界。
  • 跨租户标识滥用：弱跨租户身份验证和未经验证的联合标识会公开多租户环境，攻击者通过令牌重播或未经授权的标识联合来访问外部租户。
  • 访问持久性：标识生命周期管理不足和不受监视的访问评审会导致过时或过度的权限，攻击者通过休眠帐户重新激活或孤立的服务主体滥用来维护长期访问。
  • 威胁检测逃避：跨云和本地环境的零碎监视和未配置的实时警报隐藏恶意活动，攻击者通过 Kerberos 攻击（例如票证传递）或异常令牌使用情况来逃避检测。
  • 策略配置错误：非强制治理策略和缺乏集中式管理组控制会导致安全设置不一致，攻击者通过配置错误的条件访问或角色分配来绕过限制。

MITRE ATT&CK

  • 初始访问（TA0001）：利用未实现的标识协议或配置错误的 OAuth 2.0 应用程序许可，使攻击者能够获得未经授权的输入（例如 T1078 - 有效帐户）。
  • 凭据访问（TA0006）：从不安全标识配置窃取身份验证令牌或服务主体机密、利用弱存储或旧式身份验证方法、促进凭据泄露（例如 T1110 - 暴力破解）。
  • 特权提升（TA0004）：利用标识系统中过度授权的RBAC分配或配置不当的权限属性证书（PAC），从而使攻击者能够提升对敏感资源的访问权限（例如 T1134 - 访问令牌操作）。
  • 横向移动（TA0008）：利用未分离的订阅或跨租户身份配置错误，使对手能够穿越环境或租户边界（例如 T1578 - 修改云计算基础架构）。
  • 持久性（TA0003）：操控未受监视的标识生命周期或孤立无援的服务主体，允许攻击者通过过时凭据（例如 T1098 - 帐户操控）保持长时间的访问。
  • 防御逃避（TA0005）：利用未受监视的标识活动或 Kerberos 票证操控，使攻击者能够隐藏恶意活动（例如，T1550 - 使用替代身份验证材料）。

IM-2.1：评估身份安全评分

标识安全状况需要通过可衡量的指标进行持续评估和改进，以识别配置差距和安全弱点。 标识安全功能分数提供了可作的建议，用于加强身份验证控制、减少特权访问暴露，并实现防止基于凭据的攻击的新式安全功能。 组织定期评审其安全功能分数，确定高影响改进、确定修正工作的优先级，并在保持与行业框架的合规性的同时向利益干系人展示安全成熟度。

通过以下做法来评估并改进您的身份安全状态。

  • 评估标识安全功能分数： 使用 标识安全分数 评估标识安全状况并解决配置差距、评估管理角色分配、MFA 强制、旧身份验证状态和同意策略。

  • 分配有限的管理角色： 通过分配有限的管理角色并指定 2-4 个全局管理员来实现冗余，同时避免过度预配来强制实施最低特权。

  • 启用标识保护策略： 通过 Microsoft Entra ID Protection 启用用户和登录风险策略，并阻止旧式身份验证协议以防止不安全的访问。

  • 强制实施多重身份验证： 要求对支持无密码方法（例如 FIDO2、Windows Hello）的所有用户执行 MFA，并要求管理角色执行 MFA 来保护特权访问。

  • 启用自助服务功能： 启用自助式密码重置（SSPR），以实现安全的用户驱动恢复，并为高风险帐户（例如特权角色）设置密码过期，以平衡安全性和可用性。

  • 控制应用程序同意： 限制用户向非托管应用程序授予许可，以防止未经授权的访问。

  • 部署标识威胁检测： 利用Microsoft Entra ID 保护来检测、调查和修正基于标识的风险。 对于本地 Active Directory，请使用与 Microsoft 365 Defender 集成的 Microsoft Defender for Identity 来监视和保护混合环境。

注意：遵循Microsoft最佳实践，适用于所有其他身份验证组件，包括本地Active Directory、第三方功能以及托管基础设施（操作系统、网络和数据库），以确保身份验证和访问安全性。

实现示例

场景： 金融服务组织需要使用持续监视和基于风险的保护来改善 5,000 个用户和 200 多个应用程序之间的标识安全状况。

实现步骤：

  1. 使用 标识安全分数建立基线：

    • 访问 Microsoft Entra ID 中的“访问标识安全分数”仪表板（当前分数：62/100）
    • 查看优先建议：减少全局管理员（8→3），对特权帐户强制实施 MFA，禁用旧式身份验证，限制应用程序同意
    • 设置目标分数：90 天内 85/100

  2. 部署 Microsoft Entra ID Protection 以自动检测风险：

    • 启用基于风险的策略：要求对高风险用户更改密码，需要 MFA 进行中等/高风险登录
    • 为泄露的凭据、异常活动、特权升级尝试配置警报
    • 与 Microsoft 365 Defender 集成，以获取相关威胁情报

  3. 实现持续监视：

    • 建立每周安全评分评审和每日进行风险检测监控
    • 配置自动补救措施：自动阻止高风险 IP，触发密码重置以应对已泄露的凭据，撤销因异常行为而产生的会话。
    • 定期进行访问权限审查，以删除过期的权限分配

结果：

组织通过持续监视和基于风险的保护显著改善了其标识安全态势。 标识安全分数在目标时间范围内大幅提高，而全局管理员帐户则减少了，以便与最低特权最佳做法保持一致。 MFA 覆盖面已达到所有特权帐户的完整部署，旧式身份验证协议已禁用，大大减少了攻击面。 自动风险检测和响应功能显著缩短了响应时间，而基于凭据的攻击则通过主动监视和自动修正完全消除。

参考：

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AC-2、AC-3、IA-2、IA-4、IA-5、IA-8、SI-4
  • PCI-DSS v4： 7.2.1、8.2.1、8.3.1、8.3.2、10.2.1
  • CIS 控件 v8.1：5.4 、6.3、6.5、8.2
  • NIST CSF v2.0： PR.AA-1, PR.AC-1, DE.CM-1
  • ISO 27001：2022： A.5.15、A.5.16、A.5.17、A.8.5
  • SOC 2： CC6.1、CC6.2、CC6.6、CC7.2

IM-3：安全地自动管理应用程序标识

Azure Policy： 请参阅 Azure 内置策略定义：IM-3。

安全原则

使用托管应用程序标识，而不是为应用程序创建人工帐户来访问资源和执行代码。 托管应用程序标识提供一些好处，例如减少凭据的公开。 自动轮换凭据，以确保标识的安全性。

待缓解风险

  • 在代码或配置中暴露硬编码凭据：静态凭据（例如 API 密钥、客户端机密）嵌入到源代码、构建工件或配置文件（例如 .env、YAML）中，由于错误配置的 SCM 存储库（例如公共 Git 存储库）或 CI/CD 管道而暴露，使攻击者能够通过向令牌终结点发送 HTTP POST 请求来对云 API 进行认证。
  • 通过网络钓鱼或拦截进行凭据盗窃：攻击者通过攻击活动（例如 OAuth 同意网络钓鱼）或 MitM 攻击捕获生存期较长的凭据或 API 密钥，以拦截未加密的 HTTP/HTTPS 流量，利用弱 TLS 配置获取云服务身份验证的令牌。
  • 从弱凭据或重用凭据进行未经授权的访问：不安全配置的凭据（例如低枚举密码、重复使用的 API 密钥）容易受到暴力枚举（例如，通过 REST API 调用喷洒密码）或凭据填充攻击（利用违规数据集授予对云管理 API 的访问权限）。
  • 通过 Rogue 或孤立帐户进行持久访问：攻击者创建未经授权的帐户或利用解除授权资源中未调用的凭据，在云业务流程模板（例如 IaC 文件）中嵌入静态密钥，以通过重复的 OAuth 2.0 令牌交换来维护持久访问。
  • 从权限过高的凭据升级权限：权限范围过大的凭据（例如具有管理员级 IAM 角色的 API 密钥）使攻击者能够通过调用高特权 API 操作（例如资源创建、策略修改），利用配置错误的 RBAC 权限来提升权限。
  • 来自已入侵系统的凭据收集：攻击者从被攻破的云实例（例如，通过内存抓取）或不安全的存储（例如 S3 存储桶、配置存储）中提取纯文本凭据、API 密钥或 OAuth 令牌，并使用已收集的数据对额外的云 API 进行认证，以实现横向移动。
  • 通过未受监视凭据使用实现检测规避：攻击者利用被盗的静态凭据生成模仿合法流量的 API 请求，以便在审计日志被禁用或云遥测缺乏异常检测时规避检测，这延误了对未经授权访问的识别。

MITRE ATT&CK

  • 初始访问（TA0001）：利用云应用程序代码或配置文件中嵌入的硬编码凭据或泄露的用户帐户，利用网络钓鱼（T1566.001）窃取密码或利用配置错误的面向公众的 API（T1190）通过 OAuth 2.0 或基于 API 密钥的终结点进行身份验证。
  • 凭据访问（TA0006）：针对源代码存储库或不安全存储（T1003）中公开的凭据，在云服务身份验证流期间对弱用户密码（T1110.001）进行暴力攻击，或截获 API 密钥和会话令牌（T1539）。
  • 持久性（TA0003）：通过创建恶意用户帐户（T1136.003）或修改云应用程序配置来保留访问权限，以嵌入持久性凭据（T1098.001），确保对云资源进行重复身份验证，而无需检测。
  • 特权提升（TA0004）：通过利用被攻破的用户帐户或泄露的 API 密钥，获取管理访问权限，滥用配置错误的基于角色的访问控制（T1548.004），操控云资源或管理 API。
  • 防御逃避（TA0005）：攻击者通过伪造被盗的 API 密钥或会话令牌（T1606.002）来逃避检测，以模拟合法的云流量或禁用审核日志记录（T1562.001），伪装为授权用户（T1036）以避免监视。
  • 收集（TA0009）：从被入侵的云实例或存储中获取硬编码凭据、API 密钥或用户会话数据（T1213.002），以及针对配置文件或内存转储（T1005）的目标，以收集用于横向移动的敏感数据。

IM-3.1：在支持的 Azure 资源中使用托管标识

Azure 资源通过使用自动管理的托管标识来为支持 Microsoft Entra ID 身份验证的服务进行身份验证，从而消除凭据泄露的风险。 这些由平台管理的凭据经过全面轮换和保护，无需在源代码或配置文件中进行硬编码秘密信息，从而减少攻击面和操作开销。 采用托管标识的组织可防止凭据被盗、简化机密管理和维护安全合规性，同时跨 Azure 资源实现无缝服务到服务身份验证。

使用以下步骤实现托管标识：

  • 选择并启用托管标识： 根据用例在系统分配（绑定到单个资源、使用资源自动删除）或用户分配（独立、可跨多个资源重复使用）之间进行决定。 在创建资源期间启用托管标识（例如，为 Azure 应用服务启用系统分配的标识以访问 Key Vault）。

  • 分配最低特权权限： 使用 Azure 基于角色的访问控制（RBAC）为目标 Azure 服务授予托管身份特定角色（例如 密钥保管库机密用户或存储 Blob 数据读取器）。

  • 在应用程序代码中集成身份验证： 将 Azure SDK（例如 .NET 中的 Azure.Identity、Python 中的 azure-identity）与 DefaultAzureCredential 配合使用，在不嵌入凭据的情况下向 Key Vault、SQL 数据库或存储等服务进行身份验证。 例如，在 C# 中，使用 var credential = new DefaultAzureCredential（）;获取用于从 Key Vault 访问机密的令牌。

  • 启用自动令牌刷新： 确保应用程序自动处理令牌刷新（令牌通常在 24 小时后过期）。

IM-3.2：在托管标识不适用的情况下使用服务主体

服务主体为无法使用托管标识的服务和应用程序提供安全身份验证，通过增强的安全控制实现基于凭据的访问。 组织应将证书凭据优先于客户端机密，以减少暴露风险，同时通过最低特权 RBAC 分配保持严格的权限边界。 正确配置的服务主体可实现安全自动化和集成方案，同时通过机密轮换策略和安全保管库存储将凭据盗窃风险降到最低。

使用以下方法实现服务主体：

  • 在 Microsoft Entra ID 中创建服务主体： 使用 Microsoft Entra ID 为不支持托管标识的服务创建服务主体，确保它表示应用程序或服务（例如，为需要访问 Azure 存储的旧服务注册应用）。

  • 配置受限权限： 使用资源级别的 Azure Role-Based 访问控制（RBAC）为服务主体分配最低特权权限（例如，特定存储帐户的存储 Blob 数据参与者）。

  • 使用基于证书的凭据： 首选证书凭据而不是客户端机密，以提高安全性。 生成自签名证书或 CA 颁发的证书，并将其上传到 Entra ID 中的服务主体。

  • 如有必要，回退到客户端密钥： 如果证书不可行，请在 Entra ID 中创建一个客户端密钥，并设定一个已定义的过期时间（例如 1 年）。 安全地将机密存储在 Azure Key Vault 中，并通过编程方式检索机密，避免在源代码或配置文件中硬编码。 在过期之前轮换机密并删除未使用的机密，以最大程度地降低风险。

  • 在应用程序代码中集成身份验证： 使用 Azure SDK（例如，Azure.Identity 中的 ClientCertificateCredential 或 ClientSecretCredential）通过应用程序代码中的服务主体凭据进行身份验证。

实现示例

场景： 具有 50 多个应用程序的医疗保健组织需要安全身份验证，以满足 HIPAA 符合性，从而消除代码和配置文件中的凭据。

实现步骤：

  1. 为 Azure 服务部署 托管标识 ：

    • 为访问 SharePoint 和 Azure SQL 的 30 个应用服务启用系统分配的标识
    • 为访问 Key Vault 和服务总线的 15 个 Azure Functions 配置用户分配的标识
    • 在 VM 上为后台处理作业部署托管标识
    • 使用 Azure.Identity SDK 重构应用程序代码（DefaultAzureCredential）

  2. 为旧系统配置 服务主体 ：

    • 创建 5 个使用基于 X.509 证书（来自组织 PKI）的身份验证的服务主体。
    • 使用自动轮换将证书存储在 Azure Key Vault 中
    • 分配限定为特定资源组的最小特权 RBAC 角色
    • 对于 CI/CD 管道：使用具有 6 个月有效期和自动更换的客户端机密

  3. 实现监视和管理：

    • 部署 Azure Policy 以审核没有托管标识的资源
    • 配置 Defender for Cloud 以检测凭据泄露
    • 为服务主体权限建立季度访问审核
    • 监控登录日志以检测异常的服务主体活动

结果：

组织成功地将绝大多数应用程序迁移到托管标识，无需在现代云原生服务中管理凭据。 那些无法采用托管标识的旧系统是通过使用具有自动轮换功能的基于证书的服务主体来保护的。 所有硬编码凭据都已从应用程序代码和配置文件中删除，实现了服务主体凭据轮换的完整自动化。 这种全面的转换消除了与以前确定的凭据管理相关的所有符合性审核结果。

参考：

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AC-2、AC-3、IA-2、IA-4、IA-5、IA-9、SC-12、SC-13
  • PCI-DSS v4： 8.2.1、8.2.2、8.3.1、8.5.1
  • CIS 控件 v8.1： 6.7、12.5、16.1、16.9
  • NIST CSF v2.0： PR.AA-1, PR.AC-1, PR.DS-1
  • ISO 27001：2022： A.5.15、A.8.3、A.8.5
  • SOC 2： CC6.1、CC6.2

IM-4：对服务器和服务进行身份验证

Azure Policy： 请参阅 Azure 内置策略定义：IM-4。

安全原则

从客户端对远程服务器和服务进行身份验证，以确保连接到受信任的服务器和服务。 最常见的服务器身份验证协议是传输层安全性（TLS），客户端（通常是浏览器或客户端设备）通过验证服务器的证书是由受信任的证书颁发机构颁发的来验证服务器。

注意：当服务器和客户端相互进行身份验证时，可以使用相互身份验证。

待缓解风险

  • 未经授权的访问：攻击者利用缺失或有缺陷的身份验证来模拟服务或客户端、访问 API、存储或计算资源。 这可实现数据外泄、有效负载注入或系统接管。 例如，未经身份验证的服务间请求可能会从 Azure 存储中提取敏感 Blob，而客户端绕过验证机制可能会直接操作后端 API。
  • 凭据被盗或泄露：攻击者在代码、配置或日志中对凭据（例如客户端机密、令牌）进行硬编码或公开的凭据（例如，客户端机密或令牌）会由攻击者获取，从而授予永久性资源访问权限。 如果 AAD 应用机密被盗，可能会导致无限期冒充一个受信任的服务，访问所有作用域内的终结点，直到被吊销。 弱机密轮换或未加密的存储放大了曝光。
  • 中间人（MITM）攻击：对手拦截不安全的通信、窃取令牌或更改请求。 如果没有相互身份验证，攻击者可能会欺骗标识，从而破坏数据完整性。 例如，未加密的服务到服务调用可能会泄漏 JWT，从而启用伪造的 API 请求。 弱 TLS 密码或缺少证书验证会提高漏洞。
  • 特权提升：过于宽松的标识或配置不当的范围允许攻击者访问未经授权的资源或执行特权作。 具有过多 RBAC 角色（例如，“所有者”）的服务主体可以部署恶意资源，而具有广泛用户权限的客户端可能会更改关键配置，从限制提升到完全控制。

MITRE ATT&CK

  • 初始访问（TA0001）：攻击者利用服务到服务流或客户端到服务流中的弱身份验证，使用被盗的客户端凭据（T1078.004）或网络钓鱼（T1566.002）渗透环境。 例如，配置错误的 OAuth 2.0 应用注册允许通过伪造令牌（T1133）进行未经授权的 API 访问，从而授予对存储或计算资源的访问权限。
  • 凭据访问（TA0006）：攻击者的目标是在代码存储库、日志或不安全的保管库（T1552.001）中暴露的客户端秘钥、证书或 JWT。 技术包括从 CI/CD 管道（T1552.004）中擦除服务主体凭据，或在客户端身份验证期间截获刷新令牌（T1539），从而持续访问受保护的 API。
  • 收集（TA0009）：攻击者从被攻陷的资源（T1213.002）中窃取访问令牌或会话数据等身份验证信息。 这包括从应用程序配置（T1552.001）中提取硬编码的机密，或通过 MITM 在不安全的服务到服务调用（T1040）上捕获传输中的令牌，从而引发进一步的攻击。
  • 特权提升（TA0004）：利用已受攻击的服务主体或权限过多的用户帐户来获取更高权限（T1078.004）。 攻击者利用配置不当的应用权限（T1548.004）修改资源配置或分配管理员角色，提升对系统或租户的控制。
  • 防御逃避（TA0005）：攻击者伪造被盗令牌（T1606.002）以模拟合法流量或操控声明以绕过 API 验证过程（T1036.008）。 禁用审核日志记录（T1562.001）或使用托管标识来与正常操作（T1078）混合，以帮助逃避监控系统的检测。

IM-4.1：对服务器和服务进行身份验证

服务器和服务身份验证在分布式组件之间建立信任关系，防止中间人攻击和服务模拟威胁。 传输层安全性（TLS）提供服务器身份验证的标准机制，客户端在建立安全通信之前验证受信任的证书颁发机构颁发的服务器证书。 跨所有服务通信强制实施 TLS 身份验证的组织可保护传输中的数据，防止凭据拦截，并维护对零信任体系结构至关重要的安全服务到服务交互。

通过以下做法实现服务器和服务身份验证：

  • 为所有服务启用 TLS 身份验证： 默认情况下，许多 Azure 服务支持 TLS 身份验证。 对于默认情况下不支持 TLS 身份验证或支持禁用 TLS 的服务，请确保始终启用它以支持服务器/客户端身份验证。

  • 验证客户端应用程序中的证书信任： 客户端应用程序应设计为通过在握手阶段验证服务器证书是否已由受信任的证书颁发机构颁发来验证服务器/客户端标识。

  • 在适用情况下实现相互 TLS： API 管理和 API 网关等服务支持 TLS 相互身份验证，以提高服务器和客户端相互进行身份验证的安全性。

实现示例

场景： 支付处理公司必须在移动应用程序、后端服务和支付网关之间保护 API 通信，以满足 PCI-DSS 合规性。 他们需要通过相互身份验证防止中间人攻击。

实现步骤：

  1. 对所有服务强制实施 TLS 1.2+ ：

    • 在所有 Azure 应用服务和 API 管理中配置最低 TLS 版本（1.2+）
    • 为所有自定义域从 DigiCert 部署受信任的 SSL/TLS 证书
    • 启用仅 HTTPS 模式以重定向 HTTP 请求
    • 使用“Encrypt=True”和“TrustServerCertificate=False”配置 Azure SQL 数据库

  2. 为关键 API 实现双向 TLS （mTLS）：

    • 在应用服务配置中启用客户端证书身份验证
    • 将受信任的客户端证书 CA 上传到应用服务
    • 配置 API 管理以验证客户端证书（指纹、过期、颁发者）
    • 为每个合作伙伴/移动应用版本颁发唯一的客户端证书
    • 使用适当的访问控制将证书存储在 Azure Key Vault 中

  3. 证书生命周期管理：

    • 为 Azure 托管证书启用自动证书轮换
    • 为即将在 60 天内过期的证书设置警报
    • 实现 OCSP （联机证书状态协议） 检查
    • 配置季度证书吊销测试

  4. 客户端应用程序证书验证：

    • 为移动银行应用（iOS/Android）实现证书锁定
    • 在应用程序代码中验证服务器证书链
    • 将客户端证书存储在设备安全 enclave/密钥链中

结果：

组织通过使用现代TLS标准，实现了所有API通信的完整加密，并为需要增强安全性的高价值API端点实现了双向TLS。 中间人攻击在实施后完全消除，而导致服务中断的证书管理问题通过自动化解决。 所有要求都实现了完全 PCI-DSS 符合性，自动化证书生命周期管理可确保持续的安全性，而不会造成运营开销。

参考：

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： IA-9、SC-8、SC-13、SC-23
  • PCI-DSS v4： 4.2.1、6.2.4、8.2.1
  • CIS 控件 v8.1： 3.10、9.2、13.3
  • NIST CSF v2.0： PR.DS-2、PR.DS-5
  • ISO 27001：2022： A.5.14、A.8.24
  • SOC 2： CC6.6、CC6.7

IM-5：使用单一登录（SSO）进行应用程序访问

安全原则

实现单一登录（SSO），以简化跨云服务、SaaS 应用程序和本地环境的用户身份验证，增强用户体验和安全性。 SSO 允许用户通过受信任的标识提供者登录一次，无需重复登录即可访问所有授权资源。 这可以降低密码疲劳，最大限度地减少凭据蔓延，并通过强制实施集中式 MFA、一致的 TLS 和统一监视，确保安全高效的访问管理来缓解网络钓鱼、暴力攻击和公开凭据等风险。

待缓解风险

  • 在代码或配置中公开 Application-Specific 凭据：嵌入在源代码或配置文件（例如.env、JSON）中的纯文本凭据（例如 API 密钥、密码），通过配置错误的存储库或 CI/CD 管道公开，使攻击者能够通过 API 终结点向云或本地服务进行身份验证。
  • 跨多个登录接口通过网络钓鱼进行凭据盗窃：攻击者通过鱼叉式网络钓鱼（例如假特定于应用的登录页）捕获凭据，或截获到不同登录终结点的未加密流量，利用不一致的 TLS 配置获取多个系统的凭据。
  • 来自弱凭据或重用凭据的未经授权的访问：跨不同应用的低信息量或重复使用的凭据容易受到暴力攻击（例如，通过应用登录 API 喷洒密码）或凭据填充、授予对云服务、SaaS 或本地资源的访问权限。
  • 通过未跟踪的应用程序帐户进行持久访问：攻击者利用单个应用数据库中的非托管帐户，在配置中嵌入凭据，通过重复身份验证维护对孤立系统的访问，而无需集中吊销。
  • 通过使用未受监控的凭据实现检测规避：攻击者利用被盗凭据在不协作的系统之间模拟合法流量，由于审计日志分散或缺乏集中遥测而避开了检测，推迟了对未经授权访问的识别。

MITRE ATT&CK

  • 凭据访问 （TA0006） - 网络钓鱼：Spearphishing Link （T1566.001）：假登录页模拟应用终结点以捕获凭据，利用非 SSO 系统中不一致的 TLS。
  • 凭据访问 （TA0006） - 不安全凭据：文件中的凭据（T1552.001）：提取配置错误的 Git 存储库或 CI/CD 项目中的纯文本 API 密钥或密码。
  • 初始访问（TA0001） - 有效帐户（T1078）：被盗凭据对 Azure、SaaS 或本地应用进行身份验证，绕过非 SSO 设置中的 MFA。
  • 持久性 (TA0003) - 帐户操控 (T1098)：非托管应用帐户或嵌入式凭据可确保不吊销的重复访问。
  • 防御逃避（TA0005） - 伪装（T1036）：被盗凭据伪装成合法的 API 流量，以在隔离系统中躲避检测。

IM-5.1：使用单一登录（SSO）进行应用程序访问

通过单一登录，用户无需重复登录即可进行身份验证并访问所有授权资源，从而消除密码疲劳和凭据蔓延。 通过集中式标识提供者的 SSO 强制实施一致的安全策略，包括多重身份验证、条件访问和跨所有应用程序的统一审核日志记录。 实施 SSO 的组织可减少网络钓鱼漏洞，简化用户体验，并保持对访问模式的全面可见性，同时支持各种用户群体，包括员工、合作伙伴和客户。

使用以下方法在环境中实现 SSO：

  • 计划 SSO 实现： 确定需要 SSO 的应用程序（云、本地、面向客户的）和 Azure 资源。 将用户分类为企业（员工）、外部受信任（合作伙伴）或公共（客户）。 根据应用兼容性决定协议（例如 OpenID Connect、SAML 2.0、OAuth 2.0）。

  • 在 Microsoft Entra ID 中配置 SSO： 利用 Microsoft Entra ID，通过 单一登录（SSO）简化对面向客户的工作负荷应用程序的访问，无需重复的用户帐户。 在 Entra 应用注册模块中注册应用程序，并根据需要使用 SAML 元数据或 OIDC 客户端 ID/机密配置 SSO 设置。 为管理平面访问分配 Azure RBAC 角色（例如参与者）。

  • 为企业用户启用 SSO： 使用 Entra Connect 将本地 Active Directory 与 Entra ID 同步，从而使用公司凭据实现无缝 SSO。

  • 为外部合作伙伴配置 SSO： 为支持 SSO 的合作伙伴配置外部标识，或Microsoft Entra 验证 ID 进行分散式凭据验证。

  • 为公共用户实现 SSO： 将 Entra ID B2C 用于面向客户的应用，使用用户外部标识（例如社交网络标识）为 SSO 设置用户流。

  • 使用条件访问保护访问： 创建条件访问策略以强制实施 MFA、设备符合性或基于位置的规则。 为高风险用户强制执行多因素身份验证（MFA），并使用 Entra ID Governance 来管理和自动化访问配置和解除配置（例如为承包商提供访问包）。

实现示例

场景： 一家拥有 12,000 名员工、500 个合作伙伴和 50,000 名客户的全球制造公司需要整合 75 个应用程序的身份验证，消除密码疲劳，并减少技术支持票证，同时提高安全性。

实现步骤：

  1. 为企业应用程序配置 SAML SSO：

    • 清单 75 个应用程序：45 个 SaaS 应用（Salesforce、ServiceNow）、20 个本地应用、10 个自定义 Azure 应用
    • 为 Salesforce 配置 SAML 2.0 集成（映射 Entra ID 属性，启用 JIT 预配）
    • 使用 Microsoft.Identity.Web SDK 为自定义 Azure Web 应用设置 OpenID Connect
    • 使用 Kerberos 约束委派为 20 个本地旧应用部署 Azure AD 应用程序代理

  2. 为合作伙伴配置外部标识（B2B）：

    • 通过 B2B 协作邀请 500 名合作伙伴用户，使用项目管理工具。
    • 为合作伙伴启用联合身份验证单点登录，以使他们能够使用自己的组织凭据。
    • 实现具有时间限定项目访问权限的访问包（自动到期）
    • 使用跨租户访问设置与 5 个主要合作伙伴建立跨租户信任

  3. 为客户部署 Azure AD B2C：

    • 为访问支持门户的 50,000 个客户设置 B2C 租户
    • 配置社交标识提供者（Microsoft、Google、Facebook）
    • 使用 OAuth 2.0 和 B2C 颁发的令牌保护客户 API
    • 具有公司徽标的品牌身份验证页面

  4. 实现条件访问和管理：

    • 配置基于风险的策略（高风险用户需要密码更改 + MFA，阻止旧身份验证）
    • 为 Salesforce、ServiceNow、Workday 启用基于 SCIM 的用户预配
    • 实现 HR 驱动的生命周期：在 4 小时内自动预配，在 1 小时内自动撤销
    • 为合作伙伴建立季度访问评审和敏感应用的年度认证

结果：

组织成功地在为员工、合作伙伴和客户提供服务的大型应用程序组合中启用了 SSO，极大地提高了安全性和用户体验。 密码重置票证明显减少，用户通过消除重复登录提示获得了巨大的工作效率。 由于凭据暴露点较少，网络钓鱼易感性急剧下降。 通过自动化访问包大幅缩短合作伙伴加入时间，通过无缝社交登录集成，客户满意度显著增加。 最重要的是，完全消除了与弱密码相关的安全事件。

参考：

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： IA-2、IA-4、IA-8、AC-2
  • PCI-DSS v4： 8.2.1、8.2.2、8.3.1
  • CIS 控件 v8.1： 6.3、6.5、12.5
  • NIST CSF v2.0： 保护.AA-1，PR.AC-1
  • ISO 27001：2022： A.5.15、A.5.16
  • SOC 2： CC6.1、CC6.2

IM-6：使用强身份验证控制

Azure Policy： 请参阅 Azure 内置策略定义：IM-6。

安全原则

使用集中式身份与验证管理系统对所有资源访问实施强而防钓鱼的身份验证控制（安全无密码身份验证或多重身份验证）。 仅基于密码凭据的身份验证被视为旧身份验证，因为它不安全，并且无法支持常用的攻击方法。

部署强身份验证时，请先配置管理员和特权用户，以确保最高级别的强身份验证方法，然后快速向所有用户推出适当的强身份验证策略。

注意：如果旧版应用程序和方案需要基于密码的身份验证，请确保遵循密码安全最佳做法，例如复杂性要求。

待缓解风险

  • 通过网络钓鱼或拦截凭据泄露：攻击者通过网络钓鱼或网络嗅探捕获凭据，利用 OAuth 网络钓鱼或会话劫持来访问应用程序和资源。
  • 弱凭据或重用凭据：可预测或重复使用的密码可能导致暴力破解攻击或凭据填充攻击。
  • 代码或配置中的凭据公开：源代码或配置文件中的硬编码凭据通过配置错误或内部错误公开。
  • 来自已泄露帐户的未经授权的访问：受入侵的帐户使攻击者能够广泛访问应用程序和资源，因为行为监视不足。
  • 帐户增殖和无主帐户：重复或放弃的帐户（例如，前员工）可能被攻击者利用或滥用。
  • 跨应用程序的安全策略不一致：跨应用的不同安全控制（例如缺少 MFA）会创建可利用的漏洞。
  • 中间人（MitM）攻击：攻击者截获身份验证会话以窃取凭据或令牌。
  • 来自过度权限账户的内部威胁：过度的权限允许员工或合作伙伴故意或意外滥用。
  • 通过多个登录点进行社交工程：许多登录接口扩展攻击面，以欺骗用户显示凭据。
  • 未经授权的外部访问：管理不善的外部标识（例如合作伙伴、客户）获得对敏感系统的意外访问。

MITRE ATT&CK

  • 凭据访问（TA0006）：从配置错误的存储库或 CI/CD 管道中提取嵌入源代码或配置文件（例如 .env, JSON）中的纯文本凭据（例如 API 密钥、密码），并使用提取的凭据对云服务或本地服务的 API 进行身份验证。
  • 初始访问（TA0001）：通过 spear-phishing 捕获凭据（例如，假特定于应用的登录页、T1566.001），或通过截获传输到不同登录终端的未加密流量，利用不一致的 TLS 配置，从多个系统中获取凭据。
  • 初始访问（TA0001）：通过利用未协调应用中的弱凭据或重复使用的凭据，以及采用暴力破解攻击（例如，通过应用登录 API 进行密码喷射，T1110.001），或凭据填充来获取对云服务、SaaS 或本地资源的未经授权访问。
  • 持久性（TA0003）：通过在单个应用数据库中利用非托管帐户来维护访问权限，在配置（T1098.001）中嵌入凭据以重复向孤立系统进行身份验证，而无需集中吊销。
  • 防御逃避（TA0005）：使用被盗凭据生成 API 或应用请求，模仿跨不同系统的合法流量，从而避开检测（T1036），因为审计日志记录分散或缺乏集中遥测。

IM-6.1：使用强身份验证控制

强身份验证通过消除仅依赖密码来防止基于凭据的攻击，这些密码仍然容易受到网络钓鱼、暴力破解和破坏数据库的攻击。 新式身份验证方法（包括无密码选项（生物识别、安全密钥、基于证书的身份验证）和多重身份验证可大幅降低帐户泄露风险，同时改善用户体验。 部署强身份验证的组织应首先优先考虑管理员和特权用户以保护高价值帐户，然后系统地向所有用户扩展覆盖范围，同时通过增强的安全策略维持对需要密码的旧方案的支持。

使用以下方法实现强身份验证控制：

  • 部署无密码身份验证： 使用无密码身份验证作为默认方法，其中包含四个可用选项：Windows Hello 企业版、Microsoft Authenticator 应用手机登录、密码密钥（FIDO2）和基于证书的身份验证。 Microsoft Entra ID 原生支持无密码身份验证。 此外，客户可以使用本地身份验证方法，例如智能卡。

  • 强制实施多重身份验证： 启用可在所有用户、选择用户或基于登录条件和风险因素的每个用户级别强制执行的 Azure MFA 。 请遵循 Microsoft Defender for Cloud 针对您 MFA 设置的身份和访问管理建议。

  • 维护旧方案的密码安全性： 如果旧式基于密码的身份验证仍用于Microsoft Entra ID 身份验证，请注意，仅限云的帐户（直接在 Azure 中创建的用户帐户）具有默认的基线密码策略，混合帐户（来自本地 Active Directory 的用户帐户）遵循本地密码策略。 对于具有默认 ID 和密码的第三方应用程序和服务，请在初始服务设置期间禁用或更改它们。

实现示例

场景： 拥有 8,000 名员工的技术公司需要通过部署防钓鱼无密码身份验证来消除基于密码的攻击并改善用户体验。

实现步骤：

  1. 在 Microsoft Entra ID 中启用身份验证方法：

    • 导航到 Microsoft Entra 管理中心 > 保护 > 身份验证方法
    • 为所有用户启用 Windows Hello 企业版（默认 Windows 10/11 设备身份验证）
    • 启用传递密钥（FIDO2），认证强制设置为 “是”（确保仅使用 FIDO 联盟 MDS 中已验证的安全密钥）
    • 在 Microsoft Authenticator（预览版）中启用通行密钥，并强制执行证明
    • 启用 Certificate-Based 身份验证（CBA）并配置受信任的证书颁发机构
    • 配置回退 MFA 方法：Microsoft Authenticator 推送通知、OATH 令牌（避免特权用户的短信/语音）

  2. 定义身份验证强度策略：

    • 创建自定义身份验证强度 “管理员抗网络钓鱼”，其要求包括：FIDO2 安全密钥、Windows Hello 企业版、平台 SSO 或基于证书的多重身份验证。
    • 对标准用户使用内置的“无密码 MFA 强度”（包括 Windows Hello、FIDO2、Authenticator 密码密钥、CBA）
    • 使用内置的“多重身份验证强度”（Multifactor authentication strength）作为旧版应用程序访问的备选方案

  3. 为特权用户（150 名管理员）部署防钓鱼身份验证：

    • 使用 USB-A/C 和 NFC 支持（YubiKey 5 系列）购买 FIDO2 安全密钥，实现跨平台兼容性
    • 将密钥分发给所有管理员，并指导他们在 Microsoft Entra Security Info 页中注册
    • 使用具有 PIN 复杂性要求的 TPM 2.0 在 100 Windows PAW 上配置 Windows Hello 企业版
    • 创建面向管理员角色的条件访问策略（全局管理员、安全管理员等）：要求对所有 Azure 门户和管理员应用访问权限使用“管理员网络钓鱼防护”身份验证强度
    • 结果：100% 管理员登录使用硬件支持的网络钓鱼防护方法，证明可防止恶意设备注册

  4. 为最终用户推出无密码身份验证（7,850 个用户）：

    • Windows 用户（6,500）： 使用 TPM 2.0 或生物识别传感器（指纹、面部识别）通过 Intune 部署 Windows Hello 企业版
    • 移动用户（1,200）： 在适用于 iOS/Android 的 Microsoft Authenticator （预览版）中启用通行密钥
      • iOS：利用安全隔区与 FaceID/TouchID 绑定设备的通行密钥
      • Android：利用安全元素或可信执行环境（TEE）结合生物识别身份验证的设备绑定密码
      • 通过 App Attest (iOS) 和 Play Integrity API (Android) 启用认证以验证合法的认证器应用
    • 由 IT 和财务部门参与的 500 名早期采用者进行试点
    • 将强制认证设置为是以确保仅注册设备绑定的通行密钥（阻止不合规的密钥提供商）。
    • 为标准用户创建条件访问策略：需要“无密码 MFA 强度”身份验证来访问公司应用程序
    • 解决边缘情况：没有支持生物识别的设备的用户会收到 FIDO2 安全密钥

  5. 为专用方案部署基于证书的身份验证（CBA）：

    • 为 100 个需要 PKI 集成的外部承包商配置 Microsoft Entra 基于证书的身份验证
    • 从组织 CA 颁发 X.509 证书，有效期为 2 年
    • 为多重身份验证配置 CBA 身份验证绑定策略：需要 certificatePolicyOid + 用户名绑定（强 MFA）
    • 在硬件安全模块（智能卡）或设备安全存储（TPM、Secure Enclave）中存储证书
    • 将 CBA 纳入适用于具有管理员访问权限的承包商的“管理员防止网络钓鱼”身份验证强度策略中

  6. 使用身份验证强度配置条件访问策略：

    • 策略 1 - 管理员保护： 目标所有管理员角色 → 需要“管理员网络钓鱼防护”强度 → 应用于 Azure 门户和 Microsoft 365 管理中心。
    • 策略 2 - 标准用户： 面向所有用户（不包括管理员）→要求“无密码 MFA 强度”→应用于所有云应用
    • 策略 3 - 旧版应用： 目标特定的旧版应用程序无法支持无密码→需要“多重身份验证强度”（允许密码 + 验证器推送/OTP）
    • 策略 4 - 外部访问： 目标来宾/外部用户→要求“多重身份验证强度”最低
    • 监控条件访问洞察，以确保身份验证强度的合规性和策略的有效性。

  7. 旧版应用程序支持和密码安全性（15 个应用）：

    • 确定无法支持新式身份验证的应用程序（SAP GUI、需要密码的旧版 VPN）
    • 对于这些应用，需要通过条件访问启用“多因素身份验证强度”（支持密码 + 验证器推送通知/OTP）
    • 通过Microsoft 365 的条件访问阻止旧式身份验证协议（POP3、IMAP、SMTP AUTH）
    • 为剩余密码用户启用 Microsoft Entra 密码保护 ，其中包含自定义禁止密码列表
    • 规划旧版应用程序的迁移路径以支持新式身份验证协议（OAuth 2.0、SAML 2.0）

  8. 密码消除和恢复机制：

    • 强制实施要求现代应用程序使用无密码身份验证强度的条件访问策略
    • 已注册无密码凭据的用户中，有 95% 的用户禁用密码身份验证
    • 为帐户恢复、初次无密码凭据注册配置 临时访问通行证（TAP）
    • 为需要访问旧版应用的 5% 用户维持密码功能

  9. 监视和持续改进：

    • 在 Microsoft Entra 管理中心查看身份验证方法仪表板
    • 无密码采用率按方法（Windows Hello：81%，认证器通行密钥：15%，FIDO2：2%，CBA：1%，平台 SSO：1%）
    • 在条件访问洞察中查看身份验证强度合规性
    • 监控登录报告，以获取使用的身份验证方法、身份验证强度评估以及被阻止的旧版身份验证尝试。
    • 审核认证失败以识别尝试注册不合规设备的用户
    • 基线：15 个凭据泄露警报/月前无密码
    • 目标：< 实现无密码后每月 2 个警报

结果：

该组织通过防钓鱼身份验证方法实现了跨所有主要平台的全面无密码采用。 使用硬件支持的凭据（FIDO2、Windows Hello、平台 SSO、CBA）实现特权帐户的完整覆盖，消除了高价值目标基于密码的风险。 在整个员工队伍中，通过平台原生解决方案（Windows Hello 81%、Authenticator 通行密钥 15%、FIDO2 2%、CBA 1%、平台 SSO 1%），无密码身份验证的采用率达到 95%。 完全消除了基于密码的安全事件，而网络钓鱼模拟失败率从 18% 下降到 <部署后 2%。 技术支持服务台的密码重置请求减少了 87%，每年的认证支持成本因此节省了 34 万美元。 用户通过生物识别方法体验了 40% 更快的身份验证，通过简化的访问来提高工作效率。 身份验证强度策略可确保精细强制实施，防止身份验证方法降级攻击，并在所有管理员访问方案中保持一致的防钓鱼要求。

参考：

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AC-2、AC-3、IA-2、IA-5、IA-8、IA-11
  • PCI-DSS v4： 7.2.1、8.2.1、8.3.1、8.3.2、8.4.2
  • CIS 控件 v8.1： 6.3、6.4、6.5
  • NIST CSF v2.0： 保护.AA-1，PR.AC-1
  • ISO 27001：2022： A.5.15、A.5.17、A.5.18
  • SOC 2： CC6.1、CC6.2

IM-7：根据条件限制资源访问

安全原则

作为零信任访问模型的一部分，显式验证受信任的信号以允许或拒绝用户访问资源。 要验证的信号应包括用户帐户的强身份验证、用户帐户的行为分析、设备可信度、用户或组成员身份、位置等。

待缓解风险

  • 特权提升：来自拥有过多权限的凭据或帐户：攻击者利用过度许可的共享凭据或用户帐户（例如，全面管理员访问权限），通过 HTTP 请求对管理终端（例如 REST API）执行高权限云 API 操作，例如资源创建、删除或策略修改。
  • 通过被盗的广域凭据进行未经授权的访问：攻击者使用从管理不善的访问系统中窃取的凭据，这些凭据通过鱼叉式网络钓鱼或配置错误的面向公众的终端获取，并利用缺乏精细、资源特定限制的 API 密钥或密码来验证云服务身份。
  • 通过非托管帐户或过度帐户进行持久访问：攻击者创建或修改具有广泛权限的非托管帐户，在云配置（例如，IaC 模板）中嵌入静态凭据，以在不集中权限吊销的情况下通过重复的 API 身份验证维护持久访问。
  • 通过广泛使用的凭据来逃避检测：攻击者利用范围广泛的凭据来生成模拟合法云流量的 API 请求，由于粗略访问控制系统中缺乏特定角色的审计轨迹或细化监控，从而逃避了检测。
  • 来自“过度可访问资源”的未经授权的数据或凭据收集：攻击者利用宽松的访问控制提取敏感数据或凭据（如 API 密钥和用户数据），这些漏洞允许对云资源（如存储桶或虚拟机）进行不受限制的 API 查询或文件访问，而缺乏基于角色的边界。

MITRE ATT&CK

  • 特权提升（TA0004）：利用具有广泛访问权限的超特权共享凭据或用户帐户，滥用宽松的访问控制，跨服务调用高特权的云API操作（例如资源创建、策略修改）。
  • 初始访问（TA0001）：通过利用管理松懈的访问系统中被盗的凭据，使用鱼叉式网络钓鱼或配置错误的面向公众的终端，通过 API 密钥或缺乏细致限制的密码进行身份验证。
  • 持久性（TA0003）：通过创建或修改具有过多权限的非托管帐户来维护访问权限，在云配置中嵌入凭据以重复进行身份验证，而无需基于角色的吊销。
  • 防御逃避（TA0005）：利用广泛的凭据模拟合法的云 API 流量（T1036），由于缺少角色特定的审计记录或监控，避开了粗略的访问日志机制，从而成功逃避检测。
  • 集合（TA0009）：由于缺少基于角色的访问边界，导致可以从云资源中收集敏感数据或凭据，并通过过度宽松的访问权限从存储或实例中提取 API 密钥或用户数据。

IM-7.1：根据条件限制资源访问

条件访问策略通过在授予资源访问权限之前动态评估多个信号来启用零信任安全性，从而超越静态权限来控制上下文感知访问控制。 组织实施条件访问，以强制实施自适应安全要求，例如，要求进行管理活动时使用 MFA、阻止传统身份验证协议，或为敏感应用程序要求使用合规设备。 这些策略提供对身份验证会话的精细控制，同时平衡安全要求与用户工作效率，确保基于实时风险评估的适当保护级别。

使用以下方法实现条件访问控制：

  • 部署Microsoft Entra 条件访问： 使用 Microsoft Entra 条件访问根据用户定义的条件进行精细访问控制，例如要求特定 IP 范围（或设备）中的用户登录才能使用 MFA。 Microsoft Entra 条件访问允许你根据某些条件对组织的应用强制实施访问控制。

  • 定义适用的条件和条件： 在工作负载中定义Microsoft Entra 条件访问的适用条件和条件时，请考虑以下常见用例：

  • 要求管理角色使用多重身份验证： 要求对具有管理角色的用户实施多重身份验证。

  • 要求 MFA 执行管理任务： 需要对 Azure 管理任务进行多重身份验证。

  • 阻止旧式身份验证协议： 阻止尝试使用旧式身份验证协议的用户登录。

  • 强制实施受信任的位置： 需要受信任的位置进行多重身份验证注册，并阻止或授予来自特定位置的访问权限。

  • 阻止有风险的登录行为： 阻止有风险的登录行为。

  • 需要托管设备： 对于特定应用程序，要求使用组织托管的设备。

  • 实现会话管理控制： 还可以通过Microsoft Entra 条件访问策略（例如登录频率和持久浏览器会话）实现精细身份验证会话管理控制。

实现示例

场景： 拥有 3,500 名员工的医疗保健组织需要 150 个 Azure 资源和 45 个应用程序的零信任访问控制，同时确保 HIPAA 合规性。 了解 基于角色的访问控制（RBAC）基础知识 至关重要。

实现步骤：

  1. 建立 RBAC 基线：

    • 定义角色层次结构：全局管理员（3）、安全管理员（8）、应用程序管理员（25）、标准用户（3,464）
    • 为医疗保健方案创建自定义 Azure 角色（PHI 数据读取者、临床应用程序管理员、审核审阅者）
    • 在适当的范围内分配角色（基础结构的订阅级别、应用程序的资源组级别）
    • 在 Microsoft Intune 中注册 4,200 台设备以跟踪合规性

  2. 部署 8 个条件访问策略：

    • 策略 1 - MFA 基线： 所有用户，所有云应用都需要 MFA（登录频率：8 小时）
    • 策略 2 - 特权角色保护： 管理员需要 MFA + 合规设备 + 批准的客户端应用（4 小时会话）
    • 策略 3 - Azure 管理： 要求启用 MFA、使用合规设备并已混合加入 Azure AD 才可访问 portal.azure.com
    • 策略 4 - 旧版身份验证阻止： 阻止 POP3、IMAP、SMTP AUTH（15 个临时例外以及 6 个月的逐步淘汰计划）
    • 策略 5 - 受信任的位置： 要求从不受信任的位置访问 PHI 时进行多因素认证；阻止使用 Tor/匿名代理
    • 策略 6 - 基于风险的控制： 对于登录风险是中级或高级，要求使用 MFA 和更改密码（Entra ID Protection 集成）
    • 策略 7 - 托管设备： 要求加入合规或混合 Azure AD 的设备用于 SharePoint/Azure 网络应用程序
    • 策略 8 - 应用专用会话： 适用于金融系统的 30 分钟会话，阻止 PHI（受保护健康信息）的下载、复制和粘贴

  3. 启用 连续访问评估 （CAE）：

    • 当用户禁用、密码更改或移动到高风险位置时立即吊销令牌
    • 令牌在关键事件发生后 15 分钟内被撤销

  4. 监视和优化：

    • 每周查看条件访问见解（策略影响、用户体验指标）
    • 通过季度评审管理 45 个例外（破玻璃帐户、旧系统）
    • 与利益干系人每月策略评审会议

结果：

组织部署了全面的条件访问策略，覆盖了所有具有完整 MFA 覆盖范围和高托管设备采用的用户。 几乎所有请求的旧式身份验证已被阻止，只有在满足特定业务需求时才允许有限的例外情况。 现在，所有管理员帐户都需要防钓鱼的 MFA，并与合规设备相结合。 对受保护的健康信息的未经授权访问急剧减少，并且基于位置的异常现在会自动被阻止，从而防止以前发生的违规事件。 组织的 HIPAA 合规性分数大幅提高，显示出重要的安全成熟度。

参考：

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： AC-2、AC-3、AC-6、AC-16
  • PCI-DSS v4： 7.2.1、7.2.2、7.2.3
  • CIS 控件 v8.1： 3.3、6.4、6.8、13.5
  • NIST CSF v2.0： PR.AC-1、PR.AC-4、PR.AA-1
  • ISO 27001：2022： A.5.15、A.5.18、A.8.2、A.8.3
  • SOC 2： CC6.1、CC6.3、CC6.6

IM-8：限制凭据和机密的公开

Azure Policy： 请参阅 Azure 内置策略定义：IM-8。

安全原则

确保应用程序开发人员安全地处理凭据和机密：

  • 避免将凭据和机密嵌入代码和配置文件
  • 使用密钥保管库或安全密钥存储服务来存储凭据和机密
  • 扫描源代码中的凭据。

注意：这通常通过安全软件开发生命周期（SDLC）和 DevOps 安全流程进行治理和强制实施。

待缓解风险

  • 未经授权的访问：公开的凭据（例如，API 密钥、密码）可以由攻击者利用代码存储库或日志来访问敏感数据或数据。 例如，泄露的 Azure 服务主体密钥可能允许攻击者访问存储帐户或虚拟机。
  • 特权提升：泄露的机密（如超特权服务帐户令牌）使攻击者能够在云环境中提升其访问权限，从而可能控制整个订阅或关键资源（例如，使用被盗的 Key Vault 机密访问管理功能）。
  • 数据泄露：公开的数据库连接字符串或存储帐户密钥可能会导致未经授权的数据提取、公开敏感信息（例如，客户记录或知识产权），通常通过面向公众的错误配置（例如，打开的 Azure Blob 容器）。
  • 横向移动：被盗凭据允许攻击者跨云资源、利用信任关系或共享机密访问其他系统，例如使用重复使用的令牌从受损的 VM 迁移到 Kubernetes 群集。

MITRE ATT&CK

  • 初始访问（TA0001）：利用公开的凭据，例如公共存储库中的 API 密钥或服务主体令牌或配置不当的存储，使攻击者能够获得对云资源（例如 T1078 - 有效帐户）的未经授权的访问。
  • 特权提升（TA0004）：使用被盗的超特权机密提升访问权限，允许攻击者控制其他资源或订阅（例如 T1078 - 有效帐户）。
  • 集合（TA0009）：利用公开的数据库连接字符串或存储密钥来获取敏感数据，从而导致从云资源（例如 T1530 - 云存储中的数据）进行未经授权的数据提取。
  • 横向移动（TA0008）：使用已泄露的凭据（例如重复使用的令牌或服务帐户）在云资源中进行横向移动，以访问互连的系统或虚拟网络（例如 T1021 - 远程服务）。

IM-8.1 检测实时机密和凭据

主动机密检测通过在攻击者发现凭据之前识别嵌入在源代码、配置文件、通信工具和存档材料中的实时机密来防止凭据泄露。 跨开发管道、基础结构部署和存储系统实现持续机密扫描的组织会检测和修正公开的凭据，包括 API 密钥、连接字符串和身份验证令牌。 集成到 CI/CD 工作流中的自动检测可快速响应凭据泄漏，减少暴露窗口并防止对云资源和服务的未经授权的访问。

通过以下做法实现机密检测：

  • 启用 Azure DevOps 机密扫描： 如果使用 Azure DevOps 进行代码管理，请实现 Azure DevOps 凭据扫描程序 来标识代码存储库中的凭据。

  • 启用 GitHub 机密扫描： 对于 GitHub 存储库，请使用 本机机密扫描功能 来标识代码中的凭据或其他形式的机密。

  • 部署无代理机密扫描： 在 VM、存储和多云实例上启用 Microsoft Defender for Cloud 进行无代理机密扫描，以检测配置文件和源代码存储库中的连接字符串等机密。

IM-8.2 保护机密和凭据

安全机密管理通过集中式保管库、自动轮换和访问控制来保护身份验证凭据，防止凭据被盗和未经授权的服务访问。 Azure Key Vault 提供企业级机密存储，具有针对受支持服务的内置轮换功能、硬件安全模块（HSM）支持以及全面的审核日志记录。 通过托管标识访问的组织在密钥保管库中存储机密，消除了硬编码凭据，实现了自动轮换策略，确保了与安全框架的合规性，并启用在云和混合环境中安全的服务间身份验证。

使用以下做法保护机密和凭据：

  • 在 Azure Key Vault 中存储机密： 当托管标识不是选项时，请确保机密和凭据存储在安全位置（例如 Azure Key Vault），而不是将它们嵌入代码和配置文件中。

  • 实现自动机密轮换： Azure Key Vault 为受支持的服务提供自动轮换。 对于无法自动轮换的机密，请确保在不再使用时定期手动轮换和清除它们。

  • 通过托管标识访问 Key Vault： Azure Functions、Azure 应用服务和 VM 等客户端可以使用托管标识安全地访问 Azure Key Vault，而无需存储其他凭据。

实现示例

场景： 一家拥有跨多个团队开发人员的金融科技初创公司经历了一起安全事件——一枚 API 密钥被提交到公共 GitHub 存储库，导致客户数据泄露，进而招致监管罚款。 他们需要全面的机密检测和保护，以防止将来的凭据泄漏。

阶段 1：机密检测 - 防止凭据泄漏（IM-8.1）

  1. 在安全应用程序生命周期中实现 CredScan：

    • 将 CredScan 集成到 Azure DevOps 管道中以扫描常见机密模式
    • 如果检测到高严重性机密，将管道配置为失败，从而阻止生产部署
    • 初始扫描标识跨存储库公开的机密（存储密钥、SQL 连接字符串、API 密钥、JWT 签名机密）

  2. GitHub 高级安全机密扫描：

    • 为所有存储库启用 GitHub 高级安全性
    • 配置本机机密扫描以检测常见的令牌类型和自定义模式
    • 启用 推送保护 以阻止在推送完成之前包含机密的提交
    • 设置警报以触发事件响应工作流

  3. Microsoft Defender for Cloud 无代理扫描：

    • 为 Azure VM、存储帐户和容器注册表启用 Defender for Cloud
    • 为配置文件、容器映像和 Blob 存储配置无代理的密钥扫描
    • 为运行中的 VM、存储帐户和容器映像中发现的机密设置自动警报

  4. 历史存储库扫描（修正）：

    • 使用 Gitleaks 或 TruffleHog 等工具扫描整个 Git 历史记录以获取公开的机密
    • 识别随时间推移在提交中公开的凭据
    • 实施修正：轮换所有标识的凭据、从 Git 历史记录中删除机密、教育开发人员

阶段 2：机密保护 - 集中式保管库和轮换（IM-8.2）

  1. Azure Key Vault 部署：

    • 按环境创建 3 个 Key Vault（生产、过渡、开发）
    • 迁移机密：数据库连接字符串、第三方 API 密钥、Azure 服务凭据、OAuth 机密、加密密钥
    • 更新微服务以使用 Azure SDKs 检索机密（适用于 .NET 的 Azure.Security.KeyVault.Secrets，@azure/keyvault-secrets 适用于 Node.js，适用于 Python 的 azure-keyvault-secrets）。
    • 从代码、配置文件和 CI/CD 管道中删除所有硬编码机密

  2. 自动机密轮换：

    • 为 Azure 存储密钥、SQL 密码和服务主体机密启用自动轮换
    • 为第三方 API 密钥和数据库凭据实现自定义轮换
    • 为应用程序和操作员配置具有最低特权访问权限的 Key Vault RBAC
    • 为异常访问模式启用审核日志记录和警报

  3. 开发人员工作流和事件响应：

    • 更新训练，提供代码模板，强制实施预提交挂钩以进行机密检测
    • 将管道机密替换为 Key Vault 引用，将托管标识用于服务连接
    • 定义具有清晰升级路径和轮换程序的事件响应手册

  4. 持续监视：

    • 定期进行秘密扩散扫描以确保 Key Vault 外部不存在机密
    • 用于密钥到期和轮换合规性的仪表板跟踪
    • 定期渗透测试和安全审核

结果：

组织在其代码库和基础结构中成功识别并修正了所有公开的凭据。 通过全面迁移到 Azure Key Vault，从生产代码中完全消除了硬编码的机密。 自动机密轮换显著减少了手动开销和人为错误，同时可以显著提高对潜在凭据泄漏的检测和响应速度。 该实施方案使得因暴露凭据导致的安全事件为零，同时通过优化的机密管理流程提高了开发人员的工作效率，并完全符合所有安全审计要求，包括SOC 2和PCI-DSS标准。

参考：

严重性级别

必须具有。

控件映射

  • NIST SP 800-53 Rev.5： IA-5、SI-4、RA-5、SC-12、SC-13、SC-28
  • PCI-DSS v4： 3.5.1、6.3.2、8.2.1、8.3.2
  • CIS 控件 v8.1： 16.9、16.10、16.12
  • NIST CSF v2.0： DE.CM-8, PR.DS-1, PR.AC-1
  • ISO 27001：2022： A.5.15、A.8.3、A.8.24
  • SOC 2： CC6.1、CC6.6、CC7.2
  • Last updated on