谷歌云账单号 GCP谷歌云账号安全加固
话说某天凌晨三点，你正裹着毯子刷手机，突然收到一封邮件——「您的GCP项目已被用于挖矿，费用飙升至$12,847.63」。你猛灌一口冷咖啡，手抖着点开控制台，发现一个叫 svc-backup-legacy 的服务账号，权限高得像CEO，却连密码都没改过；另一个叫 default 的账号，居然被绑在了三个外部CI/CD流水线里，还开着 roles/editor……别慌，这不是惊悚片预告，是上周我帮客户救火时的真实开场。
谷歌云（GCP）好用是真的，但它的安全，默认不是「铁桶」，而是「敞篷跑车」——引擎轰鸣，风很大，但没顶棚。你得自己装上防滚架、系紧四点式安全带、再给油箱加个指纹锁。今天这篇，不聊ISO 27001条款编号，也不背IAM策略语法树，就当咱俩坐在工位上，泡杯茶，打开GCP控制台，一项一项动手加固。全程真实路径、真实按钮位置、真实容易踩的坑——比如那个让你以为「已启用」其实根本没生效的两步验证，我们待会儿就把它揪出来打一顿。
第一步：把你的主账号变成「门禁森严的故宫」
谷歌云账单号 别笑——很多人还在用邮箱+密码直通GCP控制台。这相当于把家门钥匙挂在门口信箱上，还贴张纸条：「备用钥匙在花盆底下」。
必须立刻做三件事：
- 启用两步验证（2-Step Verification）：不是「应用专用密码」，不是「短信验证码」（GCP官方已不推荐短信），而是用Google Authenticator或支持TOTP的硬件密钥（如YubiKey）。路径：右上角头像 → Manage your Google Account → Security → 2-step verification。⚠️重点来了：开启后，必须点击「Verify it’s working」并成功生成并输入一次动态码，否则系统默认「挂起状态」，你以为开了，其实没开。
- 关闭「允许不安全应用访问」：路径同上 → Security → Less secure app access → 确保为OFF。很多老脚本爱用这个通道，但它是裸奔通道，关掉它，逼自己改用OAuth或服务账号密钥——虽然麻烦点，但值。
- 设置「登录异常提醒」：同一账号在巴西、哈萨克斯坦、深圳同时登录？GCP不会自动锁你，但会发邮件。路径：Security Checkup → 开启 Email alerts for suspicious sign-in attempts。别嫌烦，这是你账户的「夜间保安」。
第二步：砍掉默认服务账号的「尚方宝剑」
GCP每个新项目都会自动生成一个 [email protected] 的默认服务账号。它默认拥有 Editor 权限，且项目内所有Compute Engine实例、Cloud Functions都默认用它运行——等于给每一台虚拟机配了一把万能钥匙。
危险操作请同步执行：
- 进入 IAM & Admin → IAM，找到该账号，点击右侧铅笔图标 → 移除
roles/editor，换成最小必要角色，比如roles/compute.viewer（仅查看）或roles/storage.objectViewer（仅读对象）。 - 进 Compute Engine → Metadata，检查所有实例的「Service account」字段——如果还是默认账号，赶紧换！新建专用服务账号，只授所需权限。
- 终极建议：在组织层级启用组织策略
constraints/iam.disableDefaultServiceAccount。一旦启用，新项目将不再创建默认服务账号。路径：Resource Manager → Organization Policies → 搜索该约束 → 设置为 Enforce。
第三步：给服务账号「立家规」——最小权限 + 生命周期管控
别再写 roles/owner 了，那不是权限，是「信任状」。你要的是「螺丝刀」，不是「瑞士军刀」。
实操清单：
- 按功能建账号，不按人建账号：
svc-db-backup只给 Cloud SQL 和 Storage Reader；svc-ci-deploy只给特定目录的 Artifact Registry Writer + Cloud Run Deployer。命名带业务前缀，一眼看懂用途。 - 禁用长期密钥，拥抱短期凭证：别再下载JSON密钥文件存Git里了！改用 Workload Identity Federation（K8s/GitHub Actions友好）或 Service Account Keys with 90-day expiry（路径：IAM → Service Accounts → Keys → Add Key → Create new key → JSON → Set expiration）。
- 定期清理「幽灵账号」：每月跑一次
gcloud iam service-accounts list --format="table(displayName, email, disabled)"，把三个月没调用过的、名字含test/dev-old的账号直接禁用。留着？等于在墙上多凿一扇窗。
第四步：让日志说话，而不是等报警
安全不是「不出事」，而是「出事前5分钟就知道哪扇门被撬了」。
三类日志必须盯死：
- Admin Activity 日志：谁删了防火墙规则？谁给服务账号加了Owner？路径：Logging → Logs Explorer，查询：
resource.type = "project" AND log_id("cloudaudit.googleapis.com/activity")。建议导出到BigQuery，设告警：30分钟内出现5次失败的SetIamPolicy请求？立马微信轰炸你。 - Data Access 日志（需手动开启）：默认关闭！但它记录谁读了你的敏感数据（如Secret Manager、Cloud SQL）。开启路径：Logging → Log Router → Create Sink → 目标选BigQuery → 过滤条件加
log_id("cloudaudit.googleapis.com/data_access")。 - VPC Flow Logs：不是查「谁连了数据库」，而是查「谁连了不该连的端口」。尤其关注
connection_dest_port:22（SSH）或connection_dest_port:3306（MySQL）来自陌生IP段的流量。
第五步：组织级兜底——用策略堵住团队的「捷径」
开发小哥说：「我就开个临时防火墙，测试完就关！」结果他休假了，防火墙开着半年……组织策略就是给他戴上的「电子手铐」。
推荐三条必启策略：
constraints/compute.vmExternalIpAccess：禁止所有VM申请外部IP（除非白名单项目）；constraints/iam.allowedPolicyMemberDomains：只允许@yourcompany.com邮箱加入IAM，堵死个人Gmail乱加权限；constraints/storage.publicAccessPrevention：强制所有新Bucket启用publicAccessPrevention = enforced，再也不会因一个错配的ACL导致百万文件裸奔。
最后送一句大实话：GCP安全没有「一劳永逸」，只有「持续拧螺丝」。每周花15分钟，检查一次IAM成员列表，扫一眼关键日志，确认下服务账号密钥是否快过期——这比半夜爬起来处理挖矿告警，体面多了。
对了，文末彩蛋：把这段命令复制粘贴进Cloud Shell，一键生成当前项目所有高危权限报告：gcloud projects get-iam-policy YOUR_PROJECT_ID --flatten="bindings[].members" --format="table(bindings.role, bindings.members, bindings.condition.expression)" --filter="bindings.role:(Owner OR Editor OR SecurityAdmin)"
现在，去关掉那个还在用默认服务账号的测试实例吧。你离「凌晨三点不接告警电话」，只差这一次保存。
