通过

安全控制：标识管理

  • 项目

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

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 密钥保管库、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 Identity 帐户。 使用 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：

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

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

AWS 实现和其他上下文：

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

  • 按照 PA-5 (“设置紧急访问”) 中的建议，为紧急访问设置超级管理员帐户。
  • (创建超级管理员电子邮件地址作为 Google Workspace 或 Cloud Identity 超级管理员帐户) 并且此帐户不应特定于特定用户，以防需要紧急恢复。
  • 遵循最低特权和职责分离原则
  • 避免将超级管理员帐户用于日常活动
  • 利用 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 进行工作负载应用程序访问， (客户通过 Azure AD 单一登录 (SSO) 进行) 访问，从而减少重复帐户的需求。 Azure AD 提供对管理平面中 (Azure 资源的标识和访问管理，包括 CLI、PowerShell、门户) 、云应用程序和本地应用程序。

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

Azure 实现和其他上下文：

AWS 指南：使用 AWS Cognito 通过单一登录 (SSO) 来管理面向客户的应用程序工作负载的访问，以允许客户从不同标识提供者桥接其第三方标识。

若要对 AWS 本机资源的 SSO 访问 (包括 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 还支持对企业标识（例如 Azure AD 或 Active Directory 中的企业用户标识）以及来自受信任的第三方和公共用户的外部用户标识进行 SSO。 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，并遵循针对 MFA 设置的云标识和访问管理建议Microsoft Defender。

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

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

Azure 实现和其他上下文：

AWS 指南：AWS IAM 通过多重身份验证 (MFA) 支持强身份验证控制。 可以对所有用户、选择用户或基于定义的条件在每用户级别强制实施 MFA。

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

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

AWS 实现和其他上下文：

GCP 指南：Google Cloud Identity 通过多重身份验证 (MFA) 支持强身份验证控制。 可以对所有用户、选择用户或基于定义的条件在每用户级别强制实施 MFA。 若要保护云标识 (和工作区) 超级管理员帐户，请考虑使用安全密钥和 Google 高级保护计划来最大程度地确保安全性。

如果使用具有 Google Cloud 标识的第三方目录 (（例如 Windows Active Directory) ）的公司帐户，请按照相应的安全指南强制实施强身份验证。 如果使用 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 实现和其他上下文：

客户安全利益干系人 (详细了解) ：

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 密钥保管库），而不是将它们嵌入代码和配置文件中。

如果将 Azure DevOps 和 GitHub 用于代码管理平台：

  • 执行 Azure DevOps 凭据扫描程序来识别代码中的凭据。
  • 对于 GitHub，请使用原生的机密扫描功能来识别代码中的凭据或其他形式的机密。

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

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

Azure 实现和其他上下文：

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

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

如果将 Azure DevOps 和 GitHub 用于代码管理平台：

  • 执行 Azure DevOps 凭据扫描程序来识别代码中的凭据。
  • 对于 GitHub，请使用原生的机密扫描功能来识别代码中的凭据或其他形式的机密。

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

AWS 实现和其他上下文：

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

在 IDE 的 (集成开发环境) （如 Visual Studio Code）上使用 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 Proxy (IAP) 管理对 Google Cloud 外部基于 HTTP 的应用程序（包括本地应用程序）的访问。 IAP 在应用引擎标准环境中使用签名标头或用户 API 工作。 如果需要，请使用可提供类似功能的第三方软件定义外围 (SDP) 解决方案。

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

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

GCP 实现和其他上下文：

客户安全利益干系人 (详细了解) ：