谷歌云账号出售 GCP 谷歌云账号云端加固方案
别让GCP账号变成裸奔的Wi-Fi热点
朋友，你有没有试过登录GCP控制台，点开IAM页面，发现列表里飘着十几个‘Editor’角色、三个‘Owner’、还混着一个叫‘legacy-admin-2019’的账号？更绝的是——它最后活跃时间是去年双十二，密码重置邮件发了三轮，没人点。
这不是段子，是上周我帮某跨境电商做安全巡检时的真实截图。GCP不是法拉利，买了就自动防撞；它是乐高——拼得越快，塌得越响。账号加固不是给服务器贴金箔，而是给整个云环境装上指纹锁、防撬门、震动警报和24小时保安巡逻队。
第一步：把‘默认’两个字，从你的GCP字典里永久删除
干掉默认服务账号（别怕，它真没你想的那么重要）
GCP创建项目时，会自动生成一个[email protected]——它叫‘默认Compute服务账号’，名字温柔，权限凶悍。默认带Editor权限，且几乎所有GCE实例都悄悄绑着它。相当于你家大门钥匙，配了50把，全塞在物业传达室抽屉里。
加固动作：
① 登控制台 → IAM → 筛选‘Default Compute Service Account’→ 点铅笔图标 → 移除‘Editor’，仅保留roles/compute.viewer；
② 进入‘Compute Engine’→ ‘Metadata’ → 关闭‘Allow full access to all Cloud APIs’；
③ 所有新实例，显式绑定专用服务账号（哪怕只是roles/logging.logWriter），绝不走默认通道。
⚠️ 血泪提示：别直接删！先查gcloud compute instances list --format='value(serviceAccounts.email)'确认没实例还在赖着它。曾有客户删完，K8s节点集体失联，重启花了四小时——不是云的问题，是人忘了自己写的startup script里硬编码了那个邮箱。
根账号？不存在的。组织级账号才是亲爹
如果你还在用个人gmail注册GCP玩，恭喜，你已站在悬崖边。GCP真正的加固起点，是把账号纳入‘Organization’层级。没有Org？立刻建——哪怕只挂一个项目。这是唯一能统一管控的地方。
关键Policy三板斧：
• 禁止创建新项目：constraints/resourcemanager.allowedLocations设为空数组，或限定region；
• 强制MFA：constraints/iam.allowedPolicyMemberDomains限制仅允许公司域名邮箱；
• 阻断外部API调用：constraints/serviceuser.services关闭cloudfunctions.googleapis.com等高危API，除非白名单明确放行。
命令行一句到位：gcloud resource-manager org-policies enable-enforce constraints/iam.allowedPolicyMemberDomains --organization=YOUR_ORG_ID
第二步：权限不是越多越好，是‘刚好够用，一秒都不多留’
别信‘Viewer/Editor/Owner’，那是新手村装备
Editor角色=167个权限点，Owner=229个。而你部署一个Node.js应用，真正需要的可能只有：logging.logEntries.create、storage.objects.get、run.services.invoke——加起来不到10个。
谷歌云账号出售 实操建议：
① 用gcloud projects get-iam-policy YOUR_PROJECT --format=json导出当前策略；
② 拿jq '.bindings[] | select(.role == "roles/editor")' 揪出所有Editor；
③ 对每个成员，运行gcloud projects test-iam-permissions YOUR_PROJECT --permissions=... --flatten=permissions反向验证——哪些权限他三个月根本没用过？删。
我们给财务系统单独建了finance-report-reader@账号，只赋予bigquery.jobs.list和bigquery.tables.getData——连dataset列表都不让看。财务总监问‘为啥看不到表名’？答：‘您要的数据在报表里，表名属于基础设施细节，按ISO27001第7.3条，非必要不暴露。’
临时权限？用Access Approval+短时效Token
开发半夜要调API排障？别给长期Editor权限。正确姿势：
① 在Org Policy中启用constraints/iam.accessApprovalEnforced；
② 他提交Access Approval请求，审批人（比如SRE轮值）收到邮件，点击链接，输入YubiKey二次认证后批准；
③ 系统自动发放2小时有效期的roles/iam.securityAdmin，超时秒撤，日志留痕。
这比口头说‘你只能看十分钟’靠谱一万倍——毕竟，人会忘，机器不会。
第三步：日志不是摆设，是你的云上监控摄像头+审讯记录本
不只开Audit Log，要让它‘说话’
GCP Audit Log默认开，但90%的人不知道它分三类：
• Admin Activity（谁改了什么策略，不可关闭）
• Data Access（谁读了敏感数据，需手动开启，但必须开！）
• System Event（GCP自己干的维护操作）
加固动作：
① 进入‘Logging’→ ‘Logs Router’→ 创建Sink，目标选‘BigQuery dataset’，过滤器写：logName : "cloudaudit.googleapis.com" AND (resource.type="project" OR resource.type="organization")；
② 在BQ里建视图，实时聚合：SELECT protopayload_auditlog.authenticationInfo.principalEmail, COUNT(*) FROM `your_dataset.cloudaudit_googleapis_com_activity` WHERE timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR) GROUP BY 1 ORDER BY 2 DESC——一小时谁操作最猛，一目了然。
我们曾在该视图里抓到某外包员工每晚23:00准时导出users_table，持续7天。报警规则？就一行SQL。
第四步：网络层加固——别让VPC变成敞开的菜市场
Cloud Armor不是高级玩具，是基础门槛
别再说‘我们没公网服务’。只要开了Cloud Load Balancing，你就暴露在互联网——哪怕后端是私有集群。Cloud Armor免费层就能防CC、IP黑名单、地理围栏。
实操配置：
① 创建Security Policy：gcloud compute security-policies create block-bots --description="Block known bad IPs and scanners"；
② 加入预定义规则：gcloud compute security-policies rules create 1000 --security-policy=block-bots --expression="evaluatePreconfiguredExpr('xss-protection')" --action="deny-403" --description="XSS protection"；
③ 绑定到Backend Service：gcloud compute backend-services update YOUR_SERVICE --security-policy=block-bots。
效果？上线当天拦截了327次Shodan扫描、41次SQLi试探。成本？$0。理由？因为Google说‘基础WAF免费’——而多数人直到被黑才想起翻文档。
最后一步：自动化，才是真正的24小时守夜人
写个Cloud Function，每天凌晨2点自动执行：
• 扫描所有项目，列出未启用2SV的用户；
• 发邮件+Slack告警，并冻结其账号（gcloud iam service-accounts disable）；
• 抓取所有compute.instances.list调用，若来自非运维IP段，触发PagerDuty。
代码不用多，核心就三行Python：clients = [compute.Client(), logging.Client()]
for client in clients:
if not client.is_healthy(): alert_via_pagerduty()
加固不是一次性大扫除，是每天早上的咖啡——闻着苦，喝着稳。当你某天突然发现，连续30天IAM页面里再没出现过红色‘Warning: High-risk role assignment’，那一刻，你才算把GCP账号，真正穿上了防弹衣。
