通过

安全控制 v3：标识管理

标识管理涵盖使用 Azure Active Directory 建立安全标识和访问控制的控制措施，包括使用单一登录、强身份验证、托管标识（和服务主体）进行应用程序、条件访问和帐户异常监视。

IM-1：使用集中式标识和身份验证系统

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
6.7, 12.5 AC-2、AC-3、IA-2、IA-8 7.2, 8.3

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

Azure 指南：Azure Active Directory（Azure AD）是 Azure 的标识和身份验证管理服务。 应在 Azure AD 上标准化，以管理组织的标识和身份验证：

  • Microsoft云资源，例如 Azure 存储、Azure 虚拟机（Linux 和 Windows）、Azure Key Vault、PaaS 和 SaaS 应用程序。
  • 组织的资源，例如 Azure 上的应用程序、企业网络资源上运行的第三方应用程序以及第三方 SaaS 应用程序。
  • 通过同步到 Azure AD，在 Active Directory 中实现企业标识，以确保一致且集中托管的标识策略。

注意：在技术上可行后，应立即将基于 Active Directory 的应用程序迁移到 Azure AD。 可以是 Azure AD 企业目录、企业到企业配置，也可以是企业到使用者配置。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
5.4, 6.5 AC-2、AC-3、IA-2、IA-8、SI-4 8.2, 8.3

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

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

Azure 指南：使用 Azure AD 安全基线和 Azure AD 标识安全分数来评估 Azure AD 标识安全状况，并修正安全性和配置差距。 Azure AD 身份安全评分针对以下配置对 Azure AD 进行评估：-Use 有限的管理角色

  • 启用用户风险策略
  • 指定多个全局管理员
  • 启用策略以阻止旧式身份验证
  • 确保所有用户都可以完成多重身份验证以确保安全访问
  • 需要管理角色的 MFA
  • 启用自助式密码重置
  • 不要使密码过期
  • 启用登录风险策略
  • 不允许用户向非托管应用程序授予许可

注意：请遵循已发布的最佳实践，适用于所有其他身份组件，包括本地 Active Directory、任何第三方功能，以及承载它们的基础架构（例如操作系统、网络、数据库）。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
无 AC-2、AC-3、IA-4、IA-5、IA-9 无

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

Azure 指南：使用 Azure 托管标识，该标识可以向支持 Azure AD 身份验证的 Azure 服务和资源进行身份验证。 托管标识凭据由平台完全托管、轮换和保护，避免源代码或配置文件中的硬编码凭据。

对于不支持托管标识的服务，请使用 Azure AD 在资源级别创建具有受限权限的服务主体。 建议使用证书凭据配置服务主体，并回退到客户端机密进行身份验证。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
无 IA-9 无

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

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

Azure 指南：许多 Azure 服务默认支持 TLS 身份验证。 对于支持用户启用/禁用 TLS 开关的服务，请确保始终启用它以支持服务器/服务身份验证。 客户端应用程序还应设计为在握手阶段验证服务器/服务标识（通过验证由受信任的证书颁发机构颁发的服务器证书）。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
12.5 IA-4、IA-2、IA-8 无

安全原则：使用单一登录（SSO）简化对资源（包括跨云服务和本地环境的应用程序和数据）进行身份验证的用户体验。

Azure 指南：通过 Azure AD 单一登录（SSO）使用 Azure AD 进行工作负荷应用程序访问，从而消除对多个帐户的需求。 Azure AD 提供对 Azure 资源的标识和访问管理（包括 CLI、PowerShell、门户）、云应用程序和本地应用程序。

Azure AD 支持企业标识（例如企业用户标识）的 SSO，以及受信任的第三方和公共用户的外部用户标识。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
6.3, 6.4 AC-2、AC-3、IA-2、IA-5、IA-8 7.2, 8.2, 8.3, 8.4

安全原则：使用集中式标识和身份验证管理系统强制实施强身份验证控制（强无密码身份验证或多重身份验证），以便对所有资源的访问权限。 仅基于密码凭据的身份验证被视为旧身份验证，因为它不安全，并且无法支持常用的攻击方法。

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

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

Azure 指南：Azure AD 通过无密码方法和多重身份验证（MFA）支持强身份验证控制。

  • 无密码身份验证：使用无密码身份验证作为默认身份验证方法。 无密码身份验证中提供了三个选项：Windows Hello 企业版、Microsoft Authenticator 应用手机登录和 FIDO 2Keys。 此外，客户可以使用本地身份验证方法，例如智能卡。
  • 多重身份验证：可以在所有用户上强制实施 Azure MFA、选择用户或基于登录条件和风险因素在每个用户级别。 启用 Azure MFA，并按照 Azure Defender for Cloud 的身份和访问管理建议进行 MFA 设置。

如果旧式基于密码的身份验证仍用于 Azure AD 身份验证，请注意，仅限云的帐户（直接在 Azure 中创建的用户帐户）具有默认的基线密码策略。 混合帐户（来自本地 Active Directory 的用户帐户）遵循本地密码策略。

对于可能具有默认 ID 和密码的第三方应用程序和服务，应在初始服务设置期间禁用或更改它们。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
3.3, 6.4, 13.5 AC-2、AC-3、AC-6 7.2

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

Azure 指南：根据用户定义的条件使用 Azure AD 条件访问更精细的访问控制，例如要求特定 IP 范围（或设备）中的用户登录才能使用 MFA。 Azure AD 条件访问允许根据特定条件对组织的应用强制实施访问控制。

定义工作负荷中 Azure AD 条件访问的适用条件和条件。 请考虑以下常见用例：

  • 需要对具有管理角色的用户进行多重身份验证
  • 要求对 Azure 管理任务进行多重身份验证
  • 阻止尝试使用旧式身份验证协议的用户登录
  • Azure AD 多因素身份验证注册所需的信任位置
  • 阻止或允许来自特定位置的访问
  • 阻止有风险的登录行为
  • 要求特定应用程序使用由组织管理的设备

注意：还可以通过 Azure AD 条件访问策略对登录频率和持久浏览器会话等控制措施使用精细身份验证会话管理。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

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

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

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

Azure 指南：确保机密和凭据存储在安全位置（例如 Azure Key Vault），而不是将它们嵌入代码和配置文件中。

  • 实现 Azure DevOps 凭据扫描程序以标识代码中的凭据。
  • 对于 GitHub，请使用本机机密扫描功能来标识代码中的凭据或其他形式的机密。

Azure Functions、Azure 应用服务和 VM 等客户端可以使用托管标识安全地访问 Azure Key Vault。 请参阅与使用 Azure Key Vault 进行机密管理相关的数据保护控制。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：

IM-9：保护用户对现有应用程序的访问

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
6.7, 12.5 AC-2、AC-3、SC-11 无

安全原则：在混合环境中，使用旧式身份验证的本地应用程序或非本机云应用程序，请考虑使用云访问安全代理（CASB）、应用程序代理、单一登录（SSO）等解决方案来管理对这些应用程序的访问，以便获得以下优势：

  • 强制实施集中式强身份验证
  • 监视和控制有风险的最终用户活动
  • 监视和修正有风险的旧应用程序活动
  • 检测和防止敏感数据传输

Azure 指南：使用旧式身份验证保护本地和非本机云应用程序，方法是将其连接到：

  • Azure AD 应用程序代理结合基于标头的身份验证，发布旧版本地应用程序给远程用户，实现单一登录（SSO），同时通过 Azure AD 条件访问显式验证远程用户和设备的信任度。 如果需要，请使用第三方 Software-Defined 外围（SDP）解决方案，该解决方案可提供类似的功能。
  • 现有的第三方应用程序传送控制器和网络
  • Microsoft Defender for Cloud Apps，将其用作云访问安全代理（CASB）服务，以提供监视用户的应用程序会话并阻止操作的控制（适用于旧版本地应用程序和云端软件即服务（SaaS）应用程序）。

注意：VPN 通常用于访问旧应用程序，它们通常只有基本的访问控制和有限的会话监视。

实现和其他上下文：

客户安全利益干系人（了解详细信息）：