Google ACE: 安全性、合规性和数据保护 — 学习指南
属于 Google Associate Cloud Engineer — 学习指南. 使用经过验证的答案练习: Google 考试中心, 或参加限时模拟考试: ExamRoll.io.
概览
Google Cloud 上的安全性、合规性和数据保护依赖于责任共担模型以及默认安全、纵深防御的方法。Google 负责保护物理基础设施、基础服务和默认加密,而您负责保护身份和访问、数据分类和保留、应用配置以及操作流程。在整个资源层次结构中设计最小权限,优先使用群组而非个人,首选托管身份和短期凭证,并分层设置控制措施,以确保任何单一控制的失效都不会导致安全泄露。从一开始就构建可观测性和响应工作流,以便能够持续衡量和改进安全态势。
身份和访问基础
责任共担和最小权限
- 将项目组织在单个组织下,使用文件夹来反映信任边界。应用组织策略约束来强制执行安全默认设置(例如,禁止公共 IP、限制位置、阻止创建服务账号密钥)。
- 将 IAM 角色授予 Google 群组而非用户,并优先使用预定义角色而非基本角色。定期审查角色绑定并移除未使用的权限。
- 启用可审计性和归因性。对于虚拟机的管理员操作系统访问,请使用带有每个用户 SSH 密钥的 OS Login;将 roles/compute.osLogin 或 roles/compute.osAdminLogin 角色授予群组。例如:
- gcloud compute project-info add-metadata –metadata enable-oslogin=TRUE
- gcloud projects add-iam-policy-binding PROJECT_ID –member=‘group:ops@example.com’ –role=‘roles/compute.osAdminLogin’
- 常见的失败模式:向用户授予所有者或编辑者角色、使用项目范围的 SSH 密钥以及创建长期有效的服务账号密钥。
使用 BeyondCorp 和 Identity-Aware Proxy (IAP) 保护应用访问
- IAP 在 Google 的边缘为 HTTPS 应用和 TCP 转发(SSH/RDP)终止身份感知型访问,从而无需将应用或堡垒机暴露到互联网。与情境感知访问策略 (Access Context Manager) 结合使用,以要求设备状态、IP 范围或用户群组。
- 优点:集中的身份验证/授权 (authN/Z)、强大的归因性、减少的攻击面以及简化的防火墙策略(拒绝除负载均衡器/IAP 之外的所有入站流量)。
- 权衡:配置错误可能会锁定管理员;保留一个紧急访问路径(受限的项目所有者、带外控制台访问)。一些旧版协议或非 HTTP 服务可能需要 IAP TCP 转发或其他控制措施。
服务账号和工作负载身份
- 首选将服务账号附加到 Compute Engine、使用 Workload Identity 的 GKE、Cloud Run 和 Cloud Functions,以便工作负载自动获取短期令牌。避免嵌入密钥;使用组织策略禁用服务账号密钥的创建。严格限制服务账号的 IAM 范围(最小权限原则)。
- 失败模式:广泛授予 roles/iam.serviceAccountUser 角色,这允许模拟;权限过大的服务账号成为横向移动的目标。
数据保护和密钥管理
加密、Cloud KMS、CMEK 和信封加密
- Google 默认加密所有静态数据和传输中数据。为了实现额外的控制和职责分离,请使用 Cloud KMS 中的客户管理的加密密钥 (CMEK)。许多服务(BigQuery、Cloud Storage、Pub/Sub、Compute Engine 磁盘)都支持 CMEK;这些服务使用信封加密,即您的 CMEK 包装每个对象或每个数据块的数据加密密钥 (DEK)。
- 规划密钥层次结构:每个区域一个密钥环,每个数据域一个加密密钥,并根据风险每 90-365 天进行一次轮替。轮替示例:
- gcloud kms keys update KEY_NAME –keyring=KR –location=REGION –rotation-period=90d –next-rotation-time=YYYY-MM-DDT00:00:00Z
- 访问控制:仅在所需的密钥上将 Cloud KMS CryptoKey Encrypter/Decrypter 角色授予服务账号。使用 Cloud KMS 使用日志进行监控。
- 失败模式和权衡:禁用或删除 CMEK 会使相关数据无法读取;规划事件应急手册,在轮替前仔细检查 IAM,并在不同部署中保持密钥的可用性。如果您需要在 Google Cloud 之外持有密钥,请考虑使用 External Key Manager;但要考虑到增加的延迟和外部依赖风险。
Secret Manager 和消除硬编码凭证
- 将 API 密钥、数据库密码和令牌存储在 Secret Manager 中,该服务提供自动版本控制和基于 IAM 的访问。通过 Cloud Scheduler → Pub/Sub → Cloud Functions/Run 集成轮替流程,以更新上游系统并写入新的密文版本。应用程序在启动时或按需获取密文,并进行最少的缓存。
- 最佳实践:切勿将密文提交到代码或镜像中;避免将密文打印到日志中;将 roles/secretmanager.secretAccessor 角色授予工作负载身份;使用标签标记敏感度。
- 失败模式:将密文嵌入到环境变量中,导致在崩溃时被记录到日志;轮替后忘记更新下游应用;对密文授予过宽的 IAM 权限。
数据分类、保留和隐私
- 对数据进行分类(公开、内部、机密、受监管),并使用标签标记资产。使用 BigQuery 列级安全性和行访问策略进行精细控制。对于发现和脱敏,请使用 Sensitive Data Protection (DLP)。
- 实施保留策略:Cloud Storage 对象生命周期管理(基于存在时间的存储类别转换、删除)、带锁定的存储桶保留策略以及 BigQuery 表或分区的 TTL。使保留策略与法律需求保持一致;更长的保留时间会增加风险和成本。
- 隐私和驻留:使用组织策略限制资源位置;根据主权和延迟要求选择多区域存储或区域存储。通过审计日志和 SCC 安全态势信息中心生成证据。
安全运营与合规性
Security Command Center (SCC) 与安全状况管理
- 使用 SCC 作为风险可见性的控制平面。Standard 层级汇总了配置错误发现项和漏洞数据;Premium 层级增加了威胁检测(例如,Event Threat Detection、VM and Container Threat Detection)和攻击路径洞察。
- 按严重性对发现项进行分类处理,分配负责人,并跟踪至问题关闭。将发现项导出到 BigQuery 或 Pub/Sub,用于 SIEM 集成和证据留存。根据组织策略持续衡量安全状况,并针对状况退步设置警报。
Shielded VM、安全启动、vTPM、完整性监控和操作系统强化
- 启用 Shielded VM 功能以阻止 rootkit 和启动篡改:使用安全启动 (Secure Boot)、vTPM 和完整性监控 (Integrity Monitoring) 来检测引导加载程序和内核中的变更。某些自定义内核或未签名的模块可能会导致安全启动失败;在启用前请验证镜像。
- 使用 OS Config 强化操作系统,以实现补丁合规性、遵循 CIS 的基线、最小化软件包安装、禁止密码 SSH 登录,并记录 sudo 和身份验证事件。优先使用 IAP TCP 转发进行 SSH 连接,并限制 0.0.0.0/0 的入站流量。
取证日志记录、事件分类、遏制与修复
- 用于取证的日志记录:管理员活动 (Admin Activity) 和数据访问 (Data Access) 审计日志、VPC 流日志 (VPC Flow Logs)、防火墙规则日志 (Firewall Rules Logging)、Cloud DNS 日志、负载均衡器日志,以及 Cloud KMS 和 Secret Manager 访问日志。将日志导出到具有适当保留策略和访问控制的集中式日志项目和 BigQuery 中。
- 分类和遏制手册:
- 使用 SCC 发现项和相关日志验证指标。
- 通过撤销可疑令牌、禁用被入侵的服务账号、添加拒绝防火墙规则或使用标签临时隔离实例等方式进行遏制。
- 保存证据:对磁盘进行快照、导出日志、在需要时使用经批准的工具捕获内存,并记录监管链。
- 修复:轮换密钥和凭证、修补漏洞、从已知的良好镜像重建、添加检测以防止复发,并进行事件后复盘以加强控制。
实际问题场景
Nimbus Finance 公司在外部 HTTP(S) 负载均衡器后运行 Web 和 API 工作负载,在 BigQuery 和 Cloud Storage 中处理受监管的数据,并允许工程师进行远程管理访问。最近的一次红队演练揭示了通过被盗用的凭证和横向移动导致数据外泄的风险。运维团队必须在不中断交付的情况下,强化访问权限、保护数据并改进检测能力。
- 强制使用 OS Login 并实现管理员归因
- 步骤:在项目范围内启用 OS Login;将
compute.osAdminLogin权限添加到工程师用户组;移除项目范围的 SSH 密钥。 - 理由:基于用户的 SSH 密钥和基于 IAM 的角色授予提供了清晰的归因和简单的撤销方式。消除共享密钥可减少横向移动。
- 使用 IAP 和情境感知访问来控制远程访问
- 步骤:将管理后台 UI 置于受 IAP 保护的 HTTPS 负载均衡器之后;通过 Access Context Manager 要求用户必须是运维组成员,并且满足公司 IP/设备状态要求。
- 理由:零信任访问消除了公网暴露,并集中强制执行身份和设备条件,从而降低了网络钓鱼和凭证填充攻击的风险。
- 分阶段实施 Cloud Armor WAF
- 步骤:创建 Cloud Armor 策略;在预览 (preview) 模式下启用针对 SQLi/XSS 的预配置 WAF 规则;为 /login 添加速率限制规则;监控日志;然后强制执行。
- 理由:预览模式可减少误报;有针对性的速率限制可以有效阻止凭证填充攻击和机器人程序,而不会损害合法流量。
- 使用 VPC Service Controls 包裹数据服务
- 步骤:为 BigQuery 和 Cloud Storage 项目创建服务边界 (service perimeter);为已批准的 CI/CD 和分析作业定义出站规则;要求访问级别基于用户组和网络。
- 理由:服务边界通过限制受保护数据的访问位置和方式,来缓解使用有效凭证进行数据外泄的风险。
- 使用 Cloud KMS 应用 CMEK 并安排轮换
- 步骤:为 BigQuery 和 Storage 创建区域级密钥环 (key rings) 和加密密钥 (crypto keys);仅向服务账号授予
roles/cloudkms.cryptoKeyEncrypterDecrypter角色;设置 180 天的轮换计划;监控密钥使用日志。 - 理由:CMEK 强制实行职责分离和受控的加密边界;密钥轮换可在密钥泄露时限制其爆炸半径。
- 使用 Secret Manager 集中管理密钥并自动轮换
- 步骤:将数据库和第三方令牌移至 Secret Manager;向工作负载授予最小权限访问;实现一个 Cloud Scheduler → Pub/Sub → Cloud Run 作业来轮换密钥并创建新版本。
- 理由:消除了硬编码凭证;版本控制和自动化确保了可预测、可审计的轮换,且停机时间极短。
- 通过 Shielded VM 和操作系统强化来增强主机安全
- 步骤:在所有 Compute Engine 实例上启用 Secure Boot、vTPM 和 Integrity Monitoring;强制执行无密码 SSH;使用 OS Config 每周打补丁并应用 CIS 基线。
- 理由:防止启动级别的篡改,检测配置漂移,并减少计算节点上的可利用攻击面。
- 使用 SCC 增强可观察性和安全状况管理
- 步骤:在整个组织中启用 SCC Premium;配置到 Pub/Sub 的实时通知;将发现项和日志导出到 BigQuery;为关键 KPI(例如,未解决的高危发现项数量、平均修复时间)构建仪表板。
- 理由:统一的可见性缩短了从检测到响应的时间窗口,并提供了合规性证据。
- 准备并测试事件响应手册
- 步骤:记录分类处理步骤、特权应急账号 (break-glass accounts) 和遏制措施(禁用 IAM、防火墙隔离、撤销令牌);每季度进行演练;在证据项目中强制执行日志保留和对象锁定。
- 理由:经过演练的工作流程可以减少压力下的操作失误,并为根本原因分析和监管报告保留取证完整性。
- 验证变更并最大限度地减少中断
- 步骤:使用 VPC SC 的试运行 (dry run) 模式和 Cloud Armor 的预览模式来检测潜在问题;通过金丝雀部署按环境逐步推出;维护回滚计划和变更窗口。
- 理由:受控的发布方式可以降低因收紧安全策略而带来的可用性风险,同时实现减少数据外泄和访问风险的目标。
← 监控、日志记录和运维排障 · 所有领域 · 可靠性、备份和灾难恢复 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →