本文档介绍在设计 Google Cloud 着陆区时要考虑的重要安全决策和建议方案。本文是有关着陆区的系列文章中的一篇，面向希望了解在 Google Cloud 中设计着陆区时需要做出的决策的安全专家、首席信息安全官 (CISO) 和架构师。
在本文档中，假设中心团队（例如安全团队或平台团队）强制实施这些着陆区安全控制。由于本文档的重点是企业级环境的设计，因此它所描述的一些策略可能与小型团队不太相关。
保护 Google Cloud 着陆区的决策点
如需为您的组织选择最佳安全设计，您必须做出以下决策：
架构图
本文档中介绍的示例架构使用常见的安全设计模式。您的特定控制措施可能会因组织的行业、目标工作负载或其他合规性要求等而异。下图展示了按照本文档中的建议在着陆区应用的安全控制架构。
上图显示了以下内容：
- 服务账号密钥管理有助于降低长期有效的服务账号凭据造成的风险。
- VPC Service Controls 定义敏感资源的边界，以帮助限制从边界外的访问。
- Security Command Center 监控环境是否存在不安全的配置和威胁。
- 集中式日志接收器从所有项目收集审核日志。
- Google 默认静态加密对保留在磁盘上的所有数据进行加密。
- Google 默认传输加密适用于第 3 层和第 4 层网络路径。
- Access Transparency 可让您了解和控制 Google 访问您的环境的方式。
确定如何限制服务账号的永久性凭据
服务账号是用于将 IAM 角色授予工作负载并允许工作负载访问 Google Cloud API 的机器身份。服务账号密钥是永久性凭据，而任何永久性凭据都可能存在高风险。 我们不建议让开发者自由创建服务账号密钥。
例如，如果开发者意外将服务账号密钥提交到公共 Git 代码库，外部攻击者可以使用这些凭据进行身份验证。再举一例，如果服务账号密钥存储在内部代码库中，则可以读取密钥的恶意内部人员可以使用凭据来升级自己的 Google Cloud 权限。
如需定义策略来管理这些永久性凭据，您必须提供可行的替代方案，限制永久性凭据激增和管理方式。如需了解服务账号密钥的替代方案，请参阅为您的使用场景选择最佳身份验证方法。
以下部分介绍了限制永久性凭据的方案。对于大多数使用场景，建议采用方案 1。以下部分介绍的其他方案是方案 1 不适用于特定组织时您可以考虑采用的替代方案。
方案 1：限制永久性服务账号密钥的使用
我们建议您不要允许任何用户下载服务账号密钥，因为密钥被泄露是一种常见的攻击途径。限制永久性服务账号密钥的使用是一种有助于降低手动管理服务账号密钥的风险和开销的方案。
如需实现此方案，请考虑以下各项：
- 为了防止开发者创建和下载永久性凭据，请配置组织政策限制条件
constraints/iam.disableServiceAccountKeyCreation。 - 向您的团队提供有关服务账号密钥的更安全替代方案的培训。例如，当 Google Cloud 环境外部的用户和应用需要使用服务账号时，他们可以使用服务账号模拟或工作负载身份联合（而不是服务账号密钥）进行身份验证。
- 设计一个流程，使团队在服务账号密钥是唯一可行的方案时申请此政策的例外情况。例如，第三方 SaaS 产品可能需要使用服务账号密钥从 Google Cloud 环境中读取日志。
如果您已经有适当的工具来为服务账号生成短期有效的 API 凭据，请避免使用此方案。
详情请参阅以下内容：
- Google Cloud 企业基础蓝图中的组织政策限制条件
- 使用服务账号的最佳实践
方案 2：使用其他访问管理工具生成短期有效的凭据
作为限制永久性服务账号密钥的使用的替代方案，您可以为服务账号生成短期有效的凭据。短期有效的凭据造成的风险低于永久性凭据（如服务账号密钥）。您可以开发自己的工具，也可以使用 Hashicorp Vault 等第三方解决方案来生成短期有效的访问凭据。
如果您已投资第三方工具来生成短期有效的凭据进行访问权限控制，或者您有足够的预算和能力来开发自己的解决方案，请使用此方案。
如果您还没有工具来授予短期有效的凭据，或者没有能力来构建自己的解决方案，请避免使用此方案。
如需了解详情，请参阅创建短期有效的服务账号凭据。
确定如何通过 Google API 缓解数据渗漏
Google API 具有可供所有客户使用的公共端点。虽然 Google Cloud 环境中的每个 API 资源都受 IAM 访问权限控制的约束，但是存在以下风险：数据被使用被盗凭据访问、被恶意内部人员泄露或代码被破解或通过配置错误的 IAM 政策公开。
VPC Service Controls 是一种降低这些风险的解决方案。但是，VPC Service Controls 也会让访问模型变得更加复杂，因此您必须设计 VPC Service Controls 以适应您的独特环境和使用场景。
以下部分介绍了通过 Google API 缓解数据渗漏的方案。对于大多数使用场景，建议采用方案 1。以下部分介绍的其他方案是方案 1 不适用于特定使用场景时您可以考虑采用的替代方案。
方案 1：在整个环境中广泛配置 VPC Service Controls
我们建议您在一个或多个限制所有支持的 API 的 VPC Service Controls 边界内设计您的环境。使用访问权限级别或入站流量政策配置边界例外设置，以便开发者可以访问所需的服务，包括在需要时访问控制台。
如果满足以下条件，请使用此方案：
- 您打算使用的服务支持 VPC Service Controls，并且您的工作负载不需要不受限制的互联网访问权限。
- 您将敏感数据存储在 Google Cloud 上，当数据渗漏时可能会造成严重损失。
- 开发者访问权限具有一致的特性，这些特性可配置为边界的例外情况，从而允许用户访问所需的数据。
如果您的工作负载需要不受限制的互联网访问权限或 VPC Service Controls 不支持的服务，请避免使用此方案。
详情请参阅以下内容：
方案 2：为环境的一部分配置 VPC Service Controls
您可以仅对包含敏感数据和仅限内部的工作负载的部分项目配置 VPC Service Controls，而不是在整个环境中配置 VPC Service Controls。此方案可让您对大多数项目使用更简单的设计和操作，同时仍优先针对包含敏感数据的项目进行数据保护。
例如，当有限数量的项目具有包含敏感数据的 BigQuery 数据集时，您可以考虑此替代方案。您可以仅为这些项目定义服务边界，并定义入站和出站规则，以缩小需要使用这些数据集的分析师的例外情况范围。
再举一例，在具有三层架构的应用中，某些组件可能位于边界外。允许来自用户流量的入站流量的演示层级可能是边界外的项目，包含敏感数据的应用层级和数据层可能是服务边界内的单独项目。您需要定义边界的入站和出站规则，以便层级可以通过精细的访问权限跨边界进行通信。
如果满足以下条件，请使用此方案：
- 只有有限且明确定义的项目包含敏感数据。其他项目包含风险较低的数据。
- 某些工作负载仅限内部使用，但某些工作负载需要公共互联网访问权限，或者依赖于 VPC Service Controls 不支持的服务。
- 在所有项目中配置 VPC Service Controls 会产生过多的开销或需要过多的解决方法
如果许多项目可能包含敏感数据，请避免使用此方案。
如需了解详情，请参阅启用 VPC Service Controls 的最佳实践。
方案 3：不配置 VPC Service Controls
作为在整个环境中配置 VPC Service Controls 的另一种替代方案，您可以选择不使用 VPC Service Controls，尤其是在运维开销超过 VPC Service Controls 价值的情况下。
例如，您的组织可能没有一致的开发者访问权限模式，这可能会构成入站政策的基础。您的 IT 运维可能外包给多个第三方，因此开发者没有受管理设备，或者无权从一致的 IP 地址进行访问。在此场景中，您可能无法定义入站规则来允许开发者完成日常运维所需的边界的例外情况。
在以下情况下，请使用此方案：
- 您使用的服务不支持 VPC Service Controls。
- 工作负载面向互联网，且不包含敏感数据。
- 开发者访问权限不具有一致的特性，例如受管设备或已知的 IP 范围。
如果您的 Google Cloud 环境中包含敏感数据，请避免使用此方案。
确定如何持续监控不安全的配置和威胁
与使用本地服务相比，采用云服务带来了新的挑战和威胁。监控长期服务器的现有工具可能不适合自动扩缩或临时服务，并且可能根本不会监控无服务器资源。因此，您应该评估可与您可能采用的所有云服务配合使用的安全工具。您还应持续监控安全云标准，例如 Google Cloud 的 CIS 基准。
以下部分介绍了持续监控的方案。对于大多数使用场景，建议采用方案 1。以下部分介绍的其他方案是方案 1 不适用于特定使用场景时您可以考虑采用的替代方案。
方案 1：使用 Security Command Center 高级方案
我们建议您在组织级层激活 Security Command Center 的高级层级，这有助于通过执行以下操作来强化安全状况：
- 评估您的安全状况和数据攻击面
- 提供资产清点和发现功能
- 识别错误配置、漏洞和威胁
- 帮助您降低并消除风险
在着陆区构建开始时启用 Security Command Center 后，您组织的安全团队可以近乎实时地了解不安全的配置、威胁和修复方案。这种可见性可帮助安全团队评估着陆区是否满足其要求以及是否已准备好供开发者开始部署应用。
如果满足以下条件，请使用此方案：
- 您需要一个与所有 Google Cloud 服务集成的安全状况管理和威胁检测工具，而无需额外的集成工作。
- 您希望使用 Google 保护其自身服务所使用的威胁情报、机器学习和其他高级方法。
- 现有的安全运营中心 (SOC) 缺乏相关技能或能力，无法通过大量云日志生成威胁数据分析。
如果现有的安全工具可以完全处理临时或无服务器云资源、监控不安全的配置以及识别云环境中的规模化威胁，请避免使用此方案。
方案 2：使用现有的安全工具进行云安全状况管理和威胁检测
作为使用 Security Command Center 高级层级的替代方案，您可以考虑使用其他云安全状况管理工具。您可以使用各种与 Security Command Center 功能类似的第三方工具，并且您可能已经投资专注于多云环境的云原生工具。
您还可以同时使用 Security Command Center 和第三方工具。例如，您可能会将发现结果通知从 Security Command Center 注入到其他工具，或者您可能会添加第三方安全服务到 Security Command Center 信息中心。再举一例，您可能需要在现有 SIEM 系统上存储日志，以供 SOC 团队分析威胁。您可以将现有的 SIEM 配置为仅注入 Security Command Center 生成的发现结果通知，而不是注入大量日志并等待 SOC 团队分析原始日志以获得信息资料。
如果现有的安全工具可以完全处理临时或无服务器云资源、监控不安全的配置以及识别云环境中的规模化威胁，请使用此方案。
如果满足以下条件，请避免使用此方案：
- 现有的 SOC 缺乏相关技能或能力，无法通过大量云日志生成威胁数据分析。
- 将多个第三方工具与多个 Google Cloud 服务集成会带来超过价值的复杂性。
详情请参阅以下内容：
确定如何集中聚合必要的日志
大多数审核日志都存储在生成它们的 Google Cloud 项目中。随着您的环境的发展，审核人员检查每个项目中的日志不切实际。因此，您需要确定如何集中和汇总日志，以帮助进行内部审核和安全操作。
以下部分介绍了聚合日志的方案。对于大多数使用场景，建议采用方案 1。以下部分介绍的其他方案是方案 1 不适用于特定使用场景时您可以考虑采用的替代方案。
方案 1：使用汇总日志接收器在 Google Cloud 中保留日志
建议您为审核日志和安全团队所需的其他日志配置集中式组织级日志接收器。您可以参考日志范围限定工具，确定安全团队所需的日志以及这些日志类型是否需要明确启用。
例如，安全团队需要用户创建的所有资源的集中记录，以便安全团队可以监控和调查可疑更改。安全团队还需要针对某些高度敏感的工作负载访问的不可变的数据记录。因此，安全团队可以配置一个日志接收器，将所有项目中的管理员活动审核日志聚合到一个中央项目的日志分析存储桶中，以供他们查看进行即时调查。然后，他们配置第二个日志接收器，将包含敏感工作负载的项目中的数据访问审核日志聚合到 Cloud Storage 存储桶中，以进行长期保留。
如果满足以下条件，请使用此方案：
- 您的安全团队需要所有审核日志或其他特定日志类型的集中记录。
- 您的安全团队需要将日志存储在具有受限访问权限的环境中，而不受工作负载或生成日志的团队的控制。
如果符合以下情况，请避免使用此方案： - 您的组织对工作负载之间的审核日志没有一致的集中管理要求。- 各个项目所有者分别负责管理自己的审核日志。
详情请参阅以下内容：
方案 2：将所需的审核日志导出到 Google Cloud 之外的存储空间
作为仅在 Google Cloud 中存储日志的替代方案，请考虑将审核日志导出到 Google Cloud 之外。将必要的日志类型集中到 Google Cloud 中的聚合日志接收器后，将该接收器的内容注入到 Google Cloud 之外的其他平台以存储和分析日志。
例如，您可以使用第三方 SIEM 聚合和分析多个云服务提供商的审核日志。此工具具有足够的功能来处理无服务器云资源，并且 SOC 团队具备相关技能和能力，能够通过大量日志生成数据分析。
由于 Google Cloud 中的网络出站流量费用以及其他环境中的存储费用和容量，此方案可能非常昂贵。建议您谨慎选择外部环境中所需的日志，而不是导出每个可用日志。
如果您需要将来自所有环境和云服务提供商的日志存储在一个中心位置，请使用此方案。
如果满足以下条件，请避免使用此方案：
- 现有系统没有足够的容量或预算来注入大量额外的云日志。
- 现有系统需要对每种日志类型和格式进行集成。
- 您在收集日志时没有明确如何使用日志的目标。
详情请参阅以下内容：
- 企业基础蓝图中的检测控制措施
- 从 Logging 导出的场景：合规要求
确定如何满足静态加密的合规性要求
Google Cloud 使用一种或多种加密机制自动加密静态存储的所有内容。根据您的合规性要求，您可能承担自行管理加密密钥的义务。
以下部分介绍了静态加密的方案。对于大多数使用场景，建议采用方案 1。以下部分介绍的其他方案是方案 1 不适用于特定使用场景时您可以考虑采用的替代方案。
方案 1：接受使用默认静态加密
默认静态加密足以满足许多对加密密钥管理没有特定合规性要求的使用场景。
例如，在线游戏公司的安全团队要求静态加密所有客户数据。他们对密钥管理没有监管要求，并在审核 Google 的默认静态加密后，确信这可以足够控制其需求。
如果满足以下条件，请使用此方案：
- 您对数据加密方式或加密密钥管理方式没有特定要求。
- 与管理自己的加密密钥的费用和运维开销相比，您更希望使用代管式服务。
如果您对管理自己的加密密钥有合规性要求，请避免使用此方案。
如需了解详情，请参阅 Google Cloud 中的静态加密。
方案 2：使用 Cloud KMS 管理加密密钥
除了默认静态加密之外，您可能还需要更好地控制用于对 Google Cloud 项目中的静态数据进行加密的密钥。Cloud Key Management Service (Cloud KMS) 允许使用客户管理的加密密钥 (CMEK) 来保护数据。例如，在金融服务行业中，您可能需要向外部审核人员报告如何管理敏感数据的加密密钥。
如需额外的控制层，您可以使用 CMEK 配置硬件安全模块 (HSM) 或外部密钥管理 (EKM)。建议不要使用客户提供的加密密钥 (CSEK)；过去，需通过 CSEK 处理的场景现在可通过 Cloud External Key Manager (Cloud EKM) 更好地进行处理，因为 Cloud EKM 支持更多服务且可提供更高的可用性。
此选项会将一些责任转移给应用开发者，以遵循安全团队强制要求的密钥管理。安全团队可以通过使用 CMEK 组织政策阻止创建不合规的资源来强制执行要求。
如果满足以下一个或多个条件，请使用此方案：
- 您需要管理自己密钥的生命周期。
- 您需要使用 FIPS 140-2 3 级认证的 HSM 生成加密密钥材料。
- 您需要使用 Cloud EKM 将加密密钥材料存储在 Google Cloud 之外。
如果满足以下条件，请避免使用此方案：
- 您对数据加密方式或加密密钥管理方式没有特定要求。
- 与管理自己的加密密钥的费用和运维开销相比，您更希望使用代管式服务。
详情请参阅以下内容：
方案 3：先在应用层标记化数据，然后再保留在存储空间中
除了 Google 提供的默认加密之外，您还可以开发自己的解决方案来标记化数据，然后再将其存储在 Google Cloud 中。
例如，数据科学家必须分析包含 PII 信息的数据集，但数据科学家不应有权读取某些敏感字段的原始数据。如需限制对原始数据的控制访问权限，您可以使用敏感数据保护开发注入流水线，以注入和标记化敏感数据，然后将标记化的数据保存到 BigQuery。
标记化数据并非控制措施，您可以在着陆区集中执行。此方案会将责任转移给应用开发者以便他们配置自己的加密，或者将责任转移给开发加密流水线（以将其作为共享服务提供给应用开发者使用）的平台团队。
如果特定工作负载包含不得以原始形式使用的高度敏感数据，请使用此方案。
如果 Cloud KMS 足以满足您的要求，请避免此选项，如使用 Cloud KMS 管理加密密钥中所述。通过额外的加密和解密流水线移动数据会增加应用的费用、延迟时间和复杂性。
详情请参阅以下内容：
确定如何满足传输加密的合规性要求
Google Cloud 采用多种安全措施来确保传输中的数据的真实性、完整性和隐私性。根据您的安全和合规性要求，您还可能配置应用层加密。
以下部分介绍了传输加密的方案。对于大多数使用场景，建议采用方案 1。以下部分介绍的其他方案是方案 1 不足以满足特定使用场景要求时您可以考虑采用的附加功能。
方案 1：评估默认传输加密是否足够
许多流量模式都受益于 Google 的默认传输加密，无需额外配置。VPC 网络与连接 VPC 网络中的所有虚拟机之间的流量在第 3 层或第 4 层进行加密。从互联网到 Google 服务的流量在 Google Front End (GFE) 处终止。GFE 还会执行以下操作：
- 终止传入 HTTP(S)、TCP 和 TLS 代理流量的流量
- 提供 DDoS 攻击对策
- 将流量路由到 Google Cloud 服务并进行负载均衡
例如，如果您要使用 Google API 设计内部无服务器应用，则这些服务的网络路径会自动使用默认传输加密。您无需配置其他传输加密即可加密流量。
如果 Google 默认传输加密足以满足您的内部工作负载需求，请使用此方案。
如果满足以下条件，请避免使用此方案：
- 您需要加密通过 Cloud Interconnect 的所有流量。
- 允许互联网入站流量进入您的 VPC 网络。
- 您需要在所有内部计算资源之间执行第 7 层传输加密。
在这些情况下，您应该配置其他控制，如方案 2：要求应用配置第 7 层传输加密中所述。如需了解详情，请参阅 Google Cloud 中的传输加密。
方案 2：要求应用配置第 7 层传输加密
除了默认传输加密之外，您还可以为应用流量配置第 7 层加密。Google Cloud 提供了代管式服务，可支持需要应用层传输加密的应用，包括代管式证书、Anthos Service Mesh 和 Traffic Director。
例如，开发者要构建接受来自互联网的入站流量的新应用。他们将外部应用负载均衡器与 Google 管理的 SSL 证书结合使用，在单个 IP 地址后面运行和扩缩服务。
应用层加密并非控制措施，您可以在着陆区集中执行。此方案会将一定的责任转移给应用开发者来配置传输加密。
如果应用需要组件之间的 HTTPS 或 SSL 流量，请使用此方案。
在将计算工作负载迁移到云端（如果之前当应用在本地时，不需要对内部流量应用传输加密），请考虑允许此方案有一些例外情况。在大规模迁移期间，强制旧应用在迁移前进行现代化改造可能会导致程序出现不可接受的延迟。
详情请参阅以下内容：
确定管理云服务提供商访问权限所需的其他控制措施
采用云期间需要审核云服务提供商 (CSP) 访问权限可能会产生问题。Google Cloud 提供了多层控制，可以验证云服务提供商的访问权限。
以下部分介绍了管理 CSP 访问权限的方案。对于大多数使用场景，建议采用方案 1。以下部分介绍的其他方案是方案 1 不足以满足特定使用场景要求时您可以考虑采用的附加功能。
方案 1：启用 Access Transparency 日志
Access Transparency 日志会记录 Google Cloud 员工在您的环境中执行的操作，例如，对支持请求进行问题排查时。
例如，您的开发者向 Cloud Customer Care 提出了问题排查问题，并请支持人员帮助排查其环境问题。系统会生成 Access Transparency 日志，以显示支持人员执行的操作，包括证明其合理的支持请求编号。
如果满足以下条件，请使用此方案：
- 您需要验证 Google Cloud 员工是否仅因正当业务原因（如修复服务中断或处理您的支持请求）而访问您的内容。
- 您对跟踪对敏感数据的访问有合规性要求。
方案 2：启用 Access Transparency 日志和提供商访问权限管理
如果您的企业有合规性要求，需在 CSP 可以访问您的环境之前授予明确批准，则除了方案 1 之外，您还可以将 Access Transparency 与其他控制措施结合使用，以便您明确批准或拒绝对您数据的访问。
Access Approval 是一种手动解决方案，可确保 Customer Care 和 Google 工程师在每次需要访问您的内容时要求获得您的明确批准（通过电子邮件或网络钩子）。
Key Access Justifications 是一种程序化解决方案，可向对使用 Cloud EKM 配置的加密密钥发出的所有请求添加一个理由字段。
如果满足以下条件，请使用此方案：
- 您希望中心团队直接管理 Google 员工对您的内容的访问权限。
- 对于 Access Approval，您可以接受以下风险：批准或拒绝每个访问请求的集中能力比运营权衡更重要，这可能会导致支持请求的解决速度变慢。
- 对于 Key Access Justifications，您的企业已经将 Cloud External Key Manager 用作加密策略的一部分，并希望以编程方式控制对加密数据的所有类型的访问（而不仅仅是 Google 员工对数据的访问）。
如果满足以下条件，请避免使用此方案：
- 当具有 Access Approval 授权的中心团队必须响应时可能导致的操作延迟对于需要高可用性和快速获得 Customer Care 响应的工作负载来说是不可接受的风险。
详情请参阅以下内容：
Google Cloud 着陆区的安全性方面的最佳实践
除了本文档中介绍的决策之外，请考虑以下安全性方面的最佳实践：
- 在您的环境中预配身份。如需了解详情，请参阅确定如何将身份添加到 Google Cloud。
- 设计符合贵组织用例的网络。如需了解详情，请参阅确定 Google Cloud 着陆区的网络设计。
- 实现企业基础蓝图中定义的组织政策限制条件。这些限制条件有助于防止常见的安全问题，例如创建不必要的外部 IP 地址或向所有服务账号授予 Editor 角色。
- 查看组织政策限制条件的完整列表，以评估其他控制措施是否与您的要求相关。
后续步骤
- 查看企业基础蓝图。
- 阅读 Google Cloud 架构框架中更多安全性方面的最佳实践。
- 阅读 Google Cloud 安全性方面最佳实践中心中提供的蓝图和技术白皮书。