GCP分销商 谷歌云 GCP 账号安全防护设置

谷歌云（GCP）不是你家后院的晾衣绳——挂上去就万事大吉。它更像一座24小时不打烊的数字金库，而你的账号，就是那把唯一能打开主保险柜的万能钥匙。可惜，这把钥匙常被随手扔在咖啡渍斑驳的键盘旁，还配着‘123456’的塑料锁芯。别笑，去年GCP上因弱密码+未启用MFA导致的误删生产数据库事件，平均每周发生3.7次（数据来自Google Cloud Security Report 2023，我编的，但离谱程度很真实）。

第一步：别让登录环节成筛子

先说最基础也最容易被忽视的一环——登录本身。GCP控制台登录，绝不能只靠一个密码撑全场。启用两步验证（2-Step Verification）不是锦上添花，是生存刚需。

GCP分销商 操作路径：进入Google 账户设置 → 安全 → 两步验证 → 开启。重点来了：别只选短信！运营商劫持、SIM卡克隆早已不是电影桥段。优先用Google Authenticator或Authy这类TOTP应用，或者YubiKey这类物理密钥。短信？仅作备用，且确保备用手机号是你本人实名、长期可控的号码——别填你妈的手机号，她老人家可能正在广场舞现场收验证码。

顺手检查下密码强度。GCP账号密码必须独立于你其他平台（尤其是微信、淘宝）。建议用密码管理器生成并存储：16位以上，含大小写字母、数字、符号，拒绝生日、宠物名、‘Password123’。别嫌麻烦，你为一杯奶茶排队15分钟不喊累，为账号安全多点两下鼠标却嫌烦？这账算不过来。

第二步：权限管理，不是越给越多，而是越砍越准

很多人一开通GCP就直奔‘Project Owner’角色，仿佛戴上王冠就能号令千军。错。Owner权限等于给你一把电锯，让你去修剪玫瑰——剪得爽，根也断了。

原则一：最小权限原则（Principle of Least Privilege）

给开发人员‘Compute Instance Admin’，别给‘Project Editor’；给运维查日志，就给‘Logging Viewer’，别塞进‘Security Admin’组里。GCP IAM界面右侧有个‘权限模拟器’，点开它，输入你想赋予权限的用户/服务账户，再输入想执行的操作（比如‘启动一台VM’），系统立刻告诉你需要哪些最小权限。这功能不显眼，但比算命先生还准。

原则二：拒绝使用‘primitive roles’（原始角色）

‘Editor’、‘Owner’、‘Viewer’这些角色太粗放。它们像一整箱螺丝刀，而你只需要一把十字小号。改用‘predefined roles’（预定义角色），比如‘roles/compute.instanceAdmin.v1’、‘roles/storage.objectViewer’。GCP官网有张超长角色对照表，打印出来贴在显示器边框上——不是真让你打印，是提醒你：查！别猜！

原则三：组织级策略兜底

如果你公司有G Suite或Cloud Identity，务必创建Organization资源。在‘Organization Policies’里，可以全局禁止创建外部IP的VM、强制开启Cloud KMS加密、甚至禁用特定地区（比如禁止在非合规区域部署资源）。这相当于给整个云环境装上智能门禁——不是等小偷进门才报警，是直接让他连门把手都摸不到。

第三步：服务账户——别把它当人，更别当神

服务账户（Service Account）是GCP里最常被滥用的‘影子用户’。它没有密码，只有密钥文件，一旦泄露，攻击者就能以你的名义调用API，悄无声息地挖矿、勒索、外传数据。

首先，禁用默认服务账户。新建项目时，GCP会自动生成一个[email protected]。很多人直接用它跑所有服务。STOP！立刻去IAM页面，找到它，点击编辑，移除所有角色，仅保留‘Compute Engine Service Agent’这类必要角色。然后，为每个服务单独创建专用服务账户：‘[email protected]’、‘[email protected]’……名字要像身份证号一样清晰可辨。

其次，密钥管理。永远不要把JSON密钥文件硬编码进代码或上传到GitHub！用Workload Identity Federation对接GitHub Actions，或用Cloud Secret Manager存密钥，运行时动态拉取。如果非得本地测试，用gcloud命令激活服务账户：gcloud auth activate-service-account --key-file=key.json，完事立刻gcloud auth revoke。就像借了把菜刀切肉，切完马上还回刀架，而不是插在案板上过夜。

第四步：审计、监控、快反应——安全不是静态设置，是持续搏斗

开了权限、设了MFA、管好了服务账户，就高枕无忧？天真。安全是场马拉松，终点线永远在前方五百米。

打开‘Cloud Audit Logs’，确保‘Admin Activity’和‘Data Access’日志全量开启。前者记录谁在什么时候删了防火墙规则，后者记录谁读取了哪张BigQuery表。别嫌日志多——日志不是垃圾，是破案线索。用Log Router把关键日志导出到Cloud Storage归档，或实时推送到Pub/Sub触发告警。

设置Alerting Policy：当检测到‘从非常规地理位置（比如蒙古乌兰巴托）登录’、‘单小时内创建超过50个服务账户’、‘某服务账户连续失败调用API超100次’，立刻发邮件+短信+Slack通知。别等凌晨三点收到‘您的Kubernetes集群已被加密勒索’的邮件才醒。

最后，一个血泪冷知识：小心‘Default Project’陷阱

GCP控制台右上角那个下拉菜单，默认显示的是‘default’项目。很多人以为这是个普通项目，其实它是‘自动创建的默认沙盒’，权限松散、日志关闭、几乎无防护。千万别在这个项目里部署任何真实业务！进去第一件事：在‘APIs & Services’里关掉所有没用的API，然后在IAM里清空所有非必要成员。或者，干脆在Organization层级用‘Resource Hierarchy’把它移到隔离文件夹下，加一条‘constraints/iam.allowedPolicyMemberDomains’限制只能由公司域名邮箱访问。

安全不是功能列表里的复选框，而是你每天敲命令前的三秒停顿：这个操作，真的需要这个权限吗？这个密钥，真的该存在这个路径吗？这个日志，真的没人看吗？GCP不会替你思考，但它给了你所有工具——缺的，只是你按下‘确认’键前，那一次抬眼望向风险的清醒。