GCP帳號認證服務 谷歌雲 GCP 帳戶安全防護設置

GCP帳號認證服務 前言：你的GCP帳戶，比你的咖啡杯還容易被偷？

你有沒有想過——當你用GCP跑起第一台虛擬機時，那個看似無害的「[email protected]」帳戶，其實正赤腳站在一棟玻璃高樓的邊緣，風一吹就可能滑進雲端深淵？別緊張，這不是恐怖片預告，而是多數GCP新手的日常寫照。Google Cloud Platform（GCP）功能強大、彈性十足，但它的安全模型不像家裡的門鎖——裝上就自動生效。它更像一整套可客製的太空服：零件齊全，但你得自己確認氧氣閥是否關緊、接縫處有無裂痕、頭盔面罩有沒刮花。本文不講理論，只給你一把扳手、一罐潤滑油，和三句真心話：權限不是越多越好，而是越少越穩；日誌不是用來存檔的，是用來尖叫的；安全不是一次設定，而是每天早上的晨間伸展操。

第一步：雙重驗證（2-Step Verification）——別讓帳戶裸奔

想像一下：你把自家鑰匙交給鄰居保管，結果他順手把鑰匙複製了十把，還貼在社區公告欄上。這就是「僅用密碼登入GCP」的現實畫面。GCP官方數據顯示，超過73% 的帳戶入侵事件，源頭都是弱密碼或憑證竊取。啟用雙重驗證（2SV），等於給你的帳戶加裝一道指紋+虹膜的智能門禁。

操作路徑：Google Account → Security → 2-Step Verification → 開啟（推薦使用Google Authenticator或YubiKey，別選簡訊驗證——SIM劫持已成黑產標準配備）。進階技巧：為管理員帳戶綁定硬體金鑰（Hardware Key），它不怕釣魚、不懼中間人攻擊，連你家貓踩到鍵盤都無法繞過它。

⚠️ 真實血淚：某電商團隊曾因未強制2SV，一名實習生用公司Gmail登入Cloud Console後忘記登出，三天後發現其帳號在東京區啟動了200台GPU實例，跑起了加密貨幣挖礦——帳單飆到$12,800。結論：2SV不是選項，是生存必需品。

第二步：IAM權限最小化——別再亂發「宇宙通行證」

GCP的IAM（Identity and Access Management）不是「職稱管理系統」，而是「權限外科手術台」。但很多團隊的操作是這樣的：
gcloud projects add-iam-policy-binding --member='user:[email protected]' --role='roles/owner'
然後對著Alice說：「妳是Owner，放手幹！」——這就像給新進廚師一把消防斧，讓他去切蔥花。

黃金守則三原則：
① 基於角色，而非個人：建立 editor-dev、viewer-prod、db-admin-sql 等自訂角色，而非直接賦予 roles/editor；
② 權限粒度要像芥末醬：需要部署App Engine？給 appengine.applications.deploy，別給整個 appengine.admin；
③ 定期審查，像清理冰箱過期食品：每月執行 gcloud projects get-iam-policy YOUR-PROJECT-ID --format=json | jq '.bindings[] | select(.role == "roles/owner")'，揪出沉睡的Owner。

💡 小技巧：善用「條件式權限」（Conditional IAM），例如：「只有從公司IP網段登入，才能啟動Compute Engine」，指令如下：
gcloud projects add-iam-policy-binding YOUR-PROJ --member='user:[email protected]' --role='roles/compute.instanceAdmin.v1' --condition='expression=request.ip.subnet("203.12.45.0/24") == true, title=office-only, description=Allow only from HQ IP'

第三步：服務帳號（Service Accounts）——給機器發「員工證」，別給「總裁印鑑」

許多團隊讓CI/CD流水線用「專案Owner」服務帳號執行部署，等於讓掃地機器人持有銀行金庫鑰匙。正確做法是：每項服務，一張專屬「員工證」。

實戰清單：
✓ 為Cloud Build建立獨立SA：[email protected]，僅賦予 roles/storage.objectAdmin（存取Artifact Registry）與 roles/run.developer（部署Cloud Run）；
✓ 刪除預設的「App Engine Default Service Account」的額外權限（它天生就有Editor權限！）；
✓ 啟用服務帳號密鑰自動輪替（Key Rotation），設定90天過期——密鑰不是紀念幣，不需要收藏。

🚨 警示：若你在Kubernetes Pod中掛載JSON密鑰檔，請立刻停手！改用Workload Identity——讓GKE Pod「以身分認證」，而非靠一串明文金鑰。

第四步：組織層級防禦——架起企業級防火牆

如果你的GCP環境已有Organisation資源（非Free Tier帳戶），恭喜，你擁有一座「中央安全管制中心」。這裡能下達跨所有專案的鐵律：

• 禁止建立特定地區資源

防止工程師誤建美西資源卻忘記關閉，導致跨區域流量費用暴增：
gcloud resource-manager org-policies enable-enforce compute.restrictRegions --organization=ORG-ID
再設定允許值：["asia-east1", "asia-southeast1"]

• 強制啟用VPC Service Controls

這是你抵禦「資料外洩」的最後一堵牆。設定Perimeter後，即使有人竊取了合法金鑰，也無法將BigQuery資料匯出到外部儲存桶——因為流量根本過不了圍籬。

• 禁用未加密的Cloud Storage

一句指令，讓所有新建立的Bucket自動啟用AES-256加密：
gcloud resource-manager org-policies enable-enforce storage.requireObjectChecksums --organization=ORG-ID

第五步：監控與回應——讓日誌會說話，而且嗓門很大

安全不是「沒事發生」，而是「任何事發生時，你比攻擊者先聽到聲音」。GCP提供Cloud Logging + Cloud Monitoring + Eventarc三合一監控矩陣：

• 建立Log-Based Metric：追蹤 "method:google.iam.admin.v1.CreateServiceAccountKey" 次數，1小時內超3次即觸發警報；
• 用Eventarc監聽 cloudaudit.googleapis.com/activity 事件，一旦檢測到 SetIamPolicy 修改Owner角色，立刻透過Slack通知安全小組；
• 定期導出Access Transparency Logs（需開啟），這是Google內部人員存取你資料的「監視器錄影帶」——雖不能防黑客，但能防內鬼。

結語：安全不是終點，是每天重新繫好的鞋帶

最後送你一個反直覺真相：最危險的GCP帳戶，往往不是那個從未設定過安全規則的新帳號，而是那個「三年前設好2SV、從未更新過密鑰、IAM角色堆積如山、日誌警報全部靜音」的資深管理員帳號。安全不是一張完成的考卷，而是一本每天要翻頁的日記——今天新增了一個API金鑰？記錄它用途與到期日；明天刪掉一個舊服務帳號？補上註解「因MVP已下線」；後天收到異常登入提醒？寫下「已確認為VPN故障導致，已重設2SV」。

所以，別再問「GCP安全怎麼做？」，改問：「我今天，有為我的帳戶繫緊鞋帶嗎？」
——畢竟，在雲端世界，摔一跤，可能不是擦破皮，而是整座資料中心在你眼前慢動作崩塌。