通过

安全控制 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：- 使用有限的管理角色

  • 启动用户风险策略
  • 指定多个全局管理员
  • 启用阻止旧式身份验证的策略
  • 确保所有用户都可以完成多重身份验证以实现安全访问
  • 要求对管理员角色执行 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，通过 Azure AD 单一登录 (SSO) 访问工作负载应用程序，从而避免了对多个帐户的需求。 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 for Business、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 条件访问显式验证远程用户和设备的可信度。 如果需要，请使用可提供类似功能的第三方软件定义外围 (SDP) 解决方案。
  • 现有的第三方应用程序传送控制器和网络
  • Microsoft Defender for Cloud Apps，将其用作云访问安全代理 (CASB) 服务，以提供用于监视用户的应用程序会话和阻止操作， (旧版本地应用程序和云软件即服务 (SaaS) 应用程序) 。

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

实现和其他上下文：

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