安全的 GCP 基础设施
面向中小型团队的 GCP 安全强化清单
为没有专职安全部门、在 Google Cloud 上运行生产工作负载的团队提供的实用基准。先从最可能导致严重事件、同时又最容易降低风险的路径入手。
常见的 GCP 威胁路径
大多数云安全事件都始于责任归属或配置上的小疏漏。请抢在攻击者之前排查这些路径。
- 权限过大的用户、服务账号或工作负载身份，可能让一个被盗的凭据变成跨多个项目的广泛访问权限。
- 暴露的管理端点、调试端口或过于宽松的防火墙规则，可能绕过为正常应用流量设计的所有控制措施。
- 公开的存储桶或范围过宽的签名网址，可能在应用没有明显被入侵迹象的情况下泄露客户数据。
- 当旧映像、被遗忘的命名空间、未使用的服务账号和无人负责的资源仍可部署时，陈旧的工作负载会带来长期风险。
- 审核证据缺失或保留时间过短，会让人难以确定谁更改了策略、访问何时开始以及哪些数据被访问。
- 未经测试的备份只是一种希望。恢复失败、保留不完整以及无法访问的加密密钥，都可能让一次安全事件变成永久性损失。
身份和访问权限
将身份视为主要的控制平面。每个人员、自动化流程和工作负载都应拥有各自独立、用途有限的身份。
明确资源边界
使用组织和文件夹设置护栏，并将开发、预发布和生产环境分离到不同项目或更强的信任边界中。在切实可行的最高层级应用组织政策，限制服务使用，并避免在不相关的产品之间共享生产项目。
在最小范围内授予最低限度的角色
优先使用预定义角色或自定义角色，而不是宽泛的基本角色；将角色授予群组和工作负载身份，并在可以通过资源名称或标记缩小访问范围时使用 IAM 条件。审查未使用的权限，并移除仅应通过紧急访问（break-glass）流程获得的常设生产访问权限。
移除长期有效的凭据
使用 Workload Identity Federation for GKE，让 Pod 无需导出服务账号密钥即可获得短期有效的凭据。尽可能通过组织政策禁止创建和上传密钥，清点所有剩余密钥，并针对 Cloud Audit Logs 中的高风险 IAM 更改发出告警。
网络和边缘
假设某个应用缺陷终将可以从网络访问到，并限制该缺陷能够访问的范围。
默认拒绝，仅添加明确指定的路径
使用遵循最小权限原则的 VPC 防火墙规则，并对 Pod 流量使用 Kubernetes NetworkPolicies。将各环境划分到不同的网络中，记录每条入站路径，并删除允许大范围地址访问管理端口或所有协议的宽泛调试规则。
将节点和控制平面保持为私有
停用 GKE 节点上的外部 IP 地址。优先使用基于 DNS 的私有控制平面端点；当无法避免使用 IP 端点时，通过授权网络加以限制。为工作负载提供经过规划的出站路径，而不是宽泛的互联网访问。
仅发布经过规划的公共服务
通过经过审查的网关或负载均衡器公开应用，而不是通过附带暴露的 Pod 或节点地址。使用托管证书终止 TLS，限制入站主机和路径，应用请求限制和速率限制，并将管理界面置于身份感知访问控制之后。
数据和密钥
保护静态、传输中和使用中的数据，然后证明您能够恢复这些数据。数据发现也是控制措施的一部分。
防止意外公开访问
在 Cloud Storage 上强制执行禁止公开访问和统一存储桶级访问权限。按敏感程度对存储桶分类，限制对对象和密钥的访问，为高价值数据启用日志记录，并在风险或合规模型有要求时使用客户管理的加密密钥。
不要将密钥放入映像和源代码
将凭据存储在 Secret Manager 中，并仅向特定的工作负载身份授予特定密钥版本的访问权限。有计划地轮换密钥，避免将其复制到 Git 或容器映像中，也不要把普通的 Kubernetes Secrets 视为完整的保护边界。
测试恢复，而不仅仅是创建备份
定义恢复点目标（RPO）和恢复时间目标（RTO），在生产故障域之外保留副本，并防止工作负载身份访问备份和加密密钥。按计划恢复到隔离环境中，验证数据，并记录所用时间和所有手动步骤。
GKE 安全强化
GKE 负责保护托管的控制平面，但集群配置、命名空间、准入策略和工作负载仍需由您自行管理。
以命名空间作为隔离约定
将团队和环境划分到不同的命名空间或集群中，在其中绑定范围精确的 Kubernetes RBAC 角色，并应用资源配额和 NetworkPolicies。避免为应用交付授予集群范围的写入权限；当工作负载需要独立身份时，为每个工作负载分配专属服务账号。
仅准入您信任的映像和配置
强制执行 Restricted 级别的 Pod Security 标准或等效的 Policy Controller 规则。按不可变摘要部署映像，扫描漏洞，在需要确认来源时使用 Binary Authorization，并拒绝意外的主机访问、权限提升和 cluster-admin 绑定。
移除不必要的容器权限
以非 root 用户身份运行，丢弃 Linux capabilities，尽可能使用只读根文件系统，并应用 RuntimeDefault seccomp 配置文件。如无必要，不要挂载服务账号令牌；避免使用特权容器和主机命名空间，将节点服务账号的权限保持在最低限度，并使用 Shielded Nodes 和 Container-Optimized OS。
检测与恢复
控制措施总会失效。要依靠证据和经过演练的行动，而不是相信没有人犯错。
收集您需要的证据
将 Cloud Audit Logs 以及 GKE 系统日志和工作负载日志集中存储到一个目标位置，并设置符合调查需求的保留期限。为敏感数据有选择地启用数据访问审核日志，限制日志访问权限，并记录对 IAM、防火墙、存储和集群配置的管理更改。
针对具有安全意义的更改发出告警
针对存储公开暴露、宽泛的防火墙或 IAM 更改、意外的服务账号密钥、准入拒绝、控制平面暴露、反复的身份验证失败、日志记录被停用、备份失败以及即将过期的证书发出告警。将每条告警转给相应负责人，并附上确认或排除该告警的步骤。
演练响应
针对凭据泄露、数据公开、工作负载被入侵以及区域或项目丢失编写简短的运行手册，内容应包括谁有权批准遏制措施、如何撤销访问权限、如何保全证据以及如何恢复服务。与将要使用这些运行手册的人员一起测试它们。
按优先级排列的 30 天、60 天和 90 天清单
如果您的基准尚不完善，请合理安排工作顺序：先减少暴露面，再让后续审查可以重复进行。
第 1 至 30 天：封堵明显的路径
清点项目及其负责人，移除未使用和长期有效的凭据，确认审核日志记录已启用，阻止公开存储桶，审查权限最宽泛的防火墙规则和 IAM 授权，找出生产备份的缺口，并修复所有无人负责的公共端点。为每项发现指定负责人和截止日期。
第 31 至 60 天：让基准可重复
将网络、身份和工作负载配置迁移到经过审查的基础设施即代码和 GitOps 交付中。采用 Workload Identity、私有节点、受限的 Pod Security、可信映像检查、集中式日志，以及针对最重要更改的告警。
第 61 至 90 天：验证并持续保持
执行恢复测试和事件桌面演练，审查特权访问和例外的到期情况，重新扫描映像和依赖项，验证负责人能否收到告警，并衡量仍存在的缺口。在证据过时之前，将这些检查纳入定期审查周期。
请将本清单作为起点。Snow Tree 可以通过托管平台运营或专项咨询服务来落实这一基准。
官方参考资料
当平台默认设置或产品功能发生变化时，请以 Google 最新的指南作为技术上的权威依据。
托管平台