通过

安全控制：标识管理

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

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 中实现企业标识，以确保一致且集中托管的标识策略。

对于应用的 Azure 服务，请避免使用本地身份验证方法，而是使用 Azure Active Directory 集中服务身份验证。

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

Azure 实现和其他上下文：

AWS 指南：AWS IAM（标识和访问管理）是 AWS 的默认标识和身份验证管理服务。 使用 AWS IAM 管理 AWS 标识和访问管理。 或者，通过 AWS 和 Azure 单一 Sign-On（SSO），还可以使用 Azure AD 来管理 AWS 的标识和访问控制，以避免在两个云平台中单独管理重复帐户。

AWS 支持单一 Sign-On，这使你能够将公司的第三方标识（例如 Windows Active Directory 或其他标识存储）与 AWS 标识桥接，以避免创建重复帐户来访问 AWS 资源。

AWS 实现和其他上下文：

GCP 指南：Google Cloud 的标识和访问管理（IAM）系统是 Google Cloud 的默认标识和身份验证管理服务，用于 Google Cloud 标识帐户。 使用 Google Cloud IAM 管理 GCP 标识和访问管理。 或者，通过 Google Cloud Identity 和 Azure Sigle Sign-On （SSO），还可以使用 Azure AD 管理 GCP 的标识和访问控制，以避免在互斥云环境中单独管理重复帐户。

Google Cloud Identity 是所有 Google 服务的标识提供者。 它支持单一 Sign-On，使你能够将公司的第三方标识（例如 Windows Active Directory 或其他标识存储）与 Google Cloud 标识桥接，以避免创建重复帐户来访问 GCP 资源。

注意：使用 Google Cloud Directory Sync。Google 提供与大多数企业 LDAP 管理系统集成的连接器工具，并按计划同步标识。 通过配置云标识帐户并唱 Google Cloud Directory Sync，可以配置哪些用户帐户（包括用户、组和用户配置文件、别名等）将在本地标识管理系统和 GCP 系统之间按计划同步。

GCP 实现和其他上下文：

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

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
  • 启用自助式密码重置
  • 不要使密码过期
  • 启用登录风险策略
  • 不允许用户向非托管应用程序授予许可

使用 Azure AD 标识保护检测、调查和修正基于标识的风险。 若要同样保护本地 Active Directory 域，请使用 Defender for Identity。

注意：遵循已发布的最佳实践，适用于所有其他身份组件，包括您的本地 Active Directory 和任何第三方功能，以及托管这些组件的基础设施（例如操作系统、网络、数据库）。

Azure 实现和其他上下文：

AWS 指南：使用以下安全最佳做法来保护 AWS IAM：

  • 为紧急访问设置 AWS 账户根用户的访问秘钥，如 PA-5（设置紧急访问）中所述。
  • 遵循访问分配的最低特权原则
  • 利用 IAM 组应用策略，而不是单个用户。
  • 在 IM-6（对所有用户使用强身份验证控制）中遵循强身份验证指南
  • 使用 AWS 组织 SCP（服务控制策略）和权限边界
  • 使用 IAM 访问顾问审核服务访问
  • 使用 IAM 凭据报告跟踪用户帐户和凭据状态

注意：如果有其他标识和身份验证系统（例如，如果使用 Azure AD 管理 AWS 标识和访问，请按照 Azure AD 安全基线）遵循已发布的最佳做法。

AWS 实现和其他上下文：

GCP 指南：使用以下安全最佳做法来保护组织的 Google Cloud IAM 和云标识服务：

  • 按照 PA-5 中的建议设置用于紧急访问的超级管理员帐户（“设置紧急访问”）。
  • 创建超级管理员电子邮件地址（作为 Google 工作区或云标识超级管理员帐户），如果需要紧急恢复，此帐户不应特定于特定用户。
  • 遵循最低特权和职责分离原则
  • 避免对日常活动使用超级管理员帐户
  • 利用 Google Cloud Identity 组应用策略，而不是将策略应用于单个用户。
  • 按照 IM-6（“使用强身份验证控制”）中所述的强身份验证指南，为具有提升权限的所有用户遵循强身份验证指南。
  • 使用 IAM 策略限制对资源的访问
  • 使用组织策略服务控制并配置资源约束
  • 使用云审核日志中的 IAM 审核日志记录来查看特权活动

注意：如果有其他标识和身份验证系统（例如，如果使用 Azure AD 管理 GCP 标识和访问，请按照 Azure AD 安全基线）遵循已发布的最佳做法。

GCP 实现和其他上下文：

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

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 在资源级别创建具有受限权限的服务主体。 建议使用证书凭据配置服务主体，并回退到客户端机密进行身份验证。

Azure 实现和其他上下文：

AWS 指南：使用 AWS IAM 角色，而不是为支持此功能的资源创建用户帐户。 IAM 角色由后端的平台管理，凭据是临时的，自动轮换。 这可以避免在源代码或配置文件中创建应用程序和硬编码凭据的长期访问密钥或用户名/密码。

可以使用与预定义权限策略一起附加的服务链接角色，以便在 AWS 服务之间访问，而不是为 IAM 角色自定义自己的角色权限。

注意：对于不支持 IAM 角色的服务，请使用访问密钥，但遵循安全最佳做法（如 IM-8）限制凭据和机密的公开以保护密钥。

AWS 实现和其他上下文：

GCP 指南：使用 Google 托管服务帐户，而不是为支持此功能的资源创建用户托管帐户。 Google 托管服务帐户由后端的平台管理，服务帐户密钥是临时的，并自动轮换。 这可以避免为应用程序和源代码或配置文件中的硬编码硬编码凭据创建长期访问密钥或用户名/密码。

使用策略智能来了解和识别服务帐户的可疑活动。

GCP 实现和其他上下文：

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

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 身份验证的服务或支持禁用 TLS 的服务，请确保始终启用它以支持服务器/客户端身份验证。 客户端应用程序还应设计为在握手阶段验证服务器/客户端标识（通过验证受信任的证书颁发机构颁发的服务器证书）。

注意：API 管理和 API 网关等服务支持 TLS 相互身份验证。

Azure 实现和其他上下文：

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

注意：API 网关等服务支持 TLS 相互身份验证。

AWS 实现和其他上下文：

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

注意：云负载均衡等服务支持 TLS 相互身份验证。

GCP 实现和其他上下文：

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

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，以及来自受信任第三方和公共用户的外部用户标识。

Azure 实现和其他上下文：

AWS 指南：使用 AWS Cognito 通过单点登录（SSO）管理对面向客户的应用程序负载的访问，使客户能够连接来自不同身份提供者的第三方身份。

若要 SSO 访问 AWS 本机资源（包括 AWS 控制台访问或服务管理和数据平面级别访问），请使用 AWS Sigle Sign-On 减少重复帐户的需求。

AWS SSO 还允许将公司标识（例如来自 Azure Active Directory 的标识）与 AWS 标识以及受信任的第三方和公共用户的外部用户标识桥接。

AWS 实现和其他上下文：

GCP 指南：使用 Google Cloud Identity 通过 Google Cloud Identity 单一登录管理对面向客户的工作负荷应用程序的访问，从而减少了重复帐户的需求。 Google Cloud Identity 为 GCP（在管理平面中（包括 Google Cloud CLI、控制台访问）、云应用程序和本地应用程序提供标识和访问管理。

Google Cloud Identity 还支持企业标识的 SSO，例如 Azure AD 或 Active Directory 中的企业用户标识，以及受信任的第三方和公共用户的外部用户标识。 GCP 实现和其他上下文：

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

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 应用手机登录和 FIDO2 安全密钥。 此外，客户可以使用本地身份验证方法，例如智能卡。
  • 多重身份验证：可以在所有用户上强制实施 Azure MFA、选择用户或基于登录条件和风险因素在每个用户级别。 启用 Azure MFA，并遵循 Microsoft Defender for Cloud 标识和针对 MFA 设置的访问管理建议。

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

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

Azure 实现和其他上下文：

AWS 指南：AWS IAM 通过多重身份验证（MFA）支持强身份验证控制。 可以对所有用户强制实施 MFA，选择用户，也可以根据定义的条件在每用户级别强制执行 MFA。

如果将第三方目录（例如 Windows Active Directory）中的公司帐户与 AWS 标识配合使用，请按照相应的安全指南强制实施强身份验证。 如果使用 Azure AD 管理 AWS 访问，请参阅此控件的 Azure 指南。

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

AWS 实现和其他上下文：

GCP 指南：Google Cloud Identity 通过多重身份验证（MFA）支持强身份验证控制。 可以对所有用户强制实施 MFA，选择用户，也可以根据定义的条件在每用户级别强制执行 MFA。 若要保护云标识（和工作区）超级管理员帐户，请考虑使用安全密钥和 Google 高级保护计划实现最大安全性。

如果使用第三方目录（例如 Windows Active Directory）中的公司帐户和 Google Cloud 标识，请按照相应的安全指南强制实施强身份验证。 如果使用 Azure AD 管理 Google Cloud 访问，请参阅此控件的 Azure 指南。

使用 Identity-Aware 代理为 HTTPS 访问的应用程序建立中心授权层，因此可以使用应用程序级访问控制模型，而不是依赖于网络级防火墙。

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

GCP 实现和其他上下文：

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

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 条件访问策略（例如登录频率和持久浏览器会话）实现精细身份验证会话管理控制。

Azure 实现和其他上下文：

AWS 指南：根据用户定义的条件创建 IAM 策略并定义更精细的访问控制条件，例如要求特定 IP 范围（或设备）中的用户登录才能使用多重身份验证。 条件设置可能包括单个或多个条件以及逻辑。

可以从六个不同的维度定义策略：基于标识的策略、基于资源的策略、权限边界、AWS 组织服务控制策略（SCP）、访问控制列表（ACL）和会话策略。

AWS 实现和其他上下文：

GCP 指南：创建和定义 IAM 条件以实现更精细的基于属性的访问控制，根据用户定义的条件，例如要求来自特定 IP 范围（或设备）的用户登录时必须使用多因素身份验证。 条件设置可能包括单个或多个条件以及逻辑。

条件在资源的允许策略的角色绑定中指定。 条件属性基于所请求的资源（例如，其类型或名称）或有关请求的详细信息（例如，其时间戳或目标 IP 地址）。

GCP 实现和其他上下文：

  • IAM 条件 的 概述

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

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 DevOps 凭据扫描程序以标识代码中的凭据。
  • 对于 GitHub，请使用本机机密扫描功能来标识代码中的凭据或其他形式的机密。

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

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

Azure 实现和其他上下文：

AWS 指南：使用 IAM 角色进行应用程序访问时不是一个选项，请确保机密和凭据存储在 AWS 机密管理器或 Systems Manager 参数存储等安全位置，而不是将它们嵌入代码和配置文件中。

使用 CodeGuru 审阅者进行静态代码分析，该分析可以检测源代码中硬编码的机密。

如果对代码管理平台使用 Azure DevOps 和 GitHub：

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

注意：机密管理器为受支持的服务提供自动机密轮换。 对于无法自动轮换的机密，请确保在不再使用时定期手动轮换和清除它们。

AWS 实现和其他上下文：

GCP 指南：使用 Google 托管服务帐户进行应用程序访问不是一个选项，请确保机密和凭据存储在安全位置（如 Google Cloud 的机密管理器），而不是将它们嵌入代码和配置文件中。

使用如 Visual Studio Code 等 IDE（集成开发环境）上的 Google Cloud Code 扩展，将机密管理器管理的内容集成到代码中。

如果对代码管理平台使用 Azure DevOps 或 GitHub：

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

注意：最佳做法是设置机密管理器中存储的机密的轮换计划。

GCP 实现和其他上下文：

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

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 通常用于访问旧版应用程序，通常只有基本的访问控制和有限的会话监视。

Azure 实现和其他上下文：

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

  • Azure AD 应用程序代理，并配置基于标头的方式，以允许远程用户对应用程序进行单一登录（SSO）访问，同时使用 Azure AD 条件访问明确验证远程用户和设备的可信性。 如果需要，请使用第三方 Software-Defined 外围（SDP）解决方案，该解决方案可提供类似的功能。
  • Microsoft Defender for Cloud Apps，它充当云访问安全代理（CASB）服务，用于监视和阻止用户访问未经批准的第三方 SaaS 应用程序。
  • 现有的第三方应用程序传送控制器和网络

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

AWS 实现和其他上下文：

GCP 指南：使用 Google Cloud Identity-Aware 代理（IAP）管理对 Google Cloud 外部基于 HTTP 的应用程序（包括本地应用程序）的访问。 IAP 在应用引擎标准环境中使用签名标头或用户 API。 如果需要，请使用第三方 Software-Defined 外围（SDP）解决方案，该解决方案可提供类似的功能。

还可以选择使用充当云访问安全代理（CASB）服务的 Microsoft Defender for Cloud Apps 来监视和阻止用户访问未经批准的第三方 SaaS 应用程序。

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

GCP 实现和其他上下文：

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