职责分离

职责分离是确保单个个体不具备完成恶意行为的所有必要权限的概念。在 Cloud KMS 中,这可能是一种操作,例如使用密钥来访问和解密用户通常无法访问的数据。

职责分离是大型组织的常用的业务控制手段之一,旨在帮助避免发生安全或隐私事件和错误。该手段被认为是最佳做法。

如需查看进一步的指导,请参阅我们关于安全使用 IAM 的文档

在单独的项目中设置 Cloud KMS

Cloud KMS 可以在现有项目(例如 your-project)中运行,将使用 Cloud KMS 中的密钥加密的数据存储在同一项目中是明智的。

但是,对该项目具有 owner 访问权限的任何用户也可以在该项目中管理Cloud KMS 中密钥(并执行加密操作)。这是因为密钥本身由项目拥有,而项目的用户是 owner

因此,为了实现职责分离,您可以在 Cloud KMS 所属的项目(例如 your-key-project)中对其进行运行。然后,根据您的分离要求的严格程度,您可以执行以下任意操作:

  • 推荐)在项目级别创建不具备 owneryour-key-project,并在组织级别分配一名组织管理员。此组织管理员与 owner 不同,他们无法管理或使用密钥,但他们有权设置 IAM 政策以限制授予谁密钥管理和使用的权限。使用组织级节点,可以进一步限制对组织中的项目的权限。如需了解与 Cloud KMS 搭配使用的 owner 的替代角色,请参阅下一部分。
  • (不推荐)向 your-projectowner 以外的用户授予 your-key-projectowner 角色,其中的密钥来自正在使用的 Cloud KMS。该用户仍然可以访问所有密钥操作。

选择合适的 IAM 角色

对于较小的组织,ownereditorviewer 的初始角色可能为密钥管理提供足够的精细度。在需要分离职责的大型组织中,owner 角色提供对敏感安全操作的过多访问权限,这并不是我们所期望的。在这种情况下,我们建议您使用预定义角色:

  • 对于其应用需要加密的业务所有者:使用组织级组织管理员角色。

  • 对于管理 Cloud KMS 的用户,即组织的 IT 安全团队的成员:具有通过 GCP Console 管理 Cloud KMS 所需的最小权限的两个角色是预定义的项目编辑者 (editor) 角色或基于 Cloud KMS Admin (cloudkms.admin) 角色且具有以下权限的自定义角色

    • serviceusage.quotas.get
    • serviceusage.services.get
    • resourcemanager.projects.get

    如需了解如何创建自定义角色,请参阅创建自定义角色。如果用户仅使用 gcloud 命令行工具和 Cloud KMS API 管理 Cloud KMS,则预定义 Cloud KMS 管理员角色具有足够的权限,无需具备 serviceusage.quotas.getserviceusage.services.getresourcemanager.projects.get 权限。

  • 对于使用密钥进行加密和解密操作的用户或服务:使用具有加密者/解密者 (cloudkms.cryptoKeyEncrypterDecrypter) 的 Cloud KMS 项目级服务帐号。如果服务只需要写入或读取数据的权限,可以进一步限制使用仅具有加密者 (cloudkms.cryptoKeyEncrypter) 或解密者 (cloudkms.cryptoKeyDecrypter) 的角色。

使用单独的 Cloud KMS 项目和上述推荐角色,您可以解决若干关于职责分离的安全问题:

  • 任何需要项目级别初始角色以使用其他 Google Cloud 服务的用户都无法使用该权限来访问 Cloud KMS。
  • 用户均不需要具备 owner 角色,该角色可能会授予他们使用密钥的过多权限。在没有 owner 时,默认情况下,任何用户都无法直接管理和使用密钥来加密或解密数据。请注意,如果未启用数据访问日志,则 owner 可能具有未经审核的使用密钥材料的权限。
此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Cloud KMS