保護一個你沒有建置的雲端環境

你剛拿到一個三年來無人打理、不斷成長的雲端帳戶的鑰匙。沒有人留下文件。IAM 有 40 個角色含有萬用符號權限,有人不記得建立過的 S3 值區,最後一個理解網路拓樸的人在 2022 年離開公司。這比大多數職位公告所承認的還常見,而第一個月決定了之後的一切。

接觸任何東西之前先做好清單

抵住立刻開始鎖定的衝動。你需要一份地圖。執行 aws resourcegroupstaggingapi get-resources 跨越每個區域,不只 us-east-1 — 團隊喜歡在 ap-southeast-2 啟動測試資源然後忘記它們。搭配已啟用的 AWS Config,或如果沒有就現在開啟。在 Azure,az resource list --output table 導入試算表對首次通過就可以。在 GCP,Cloud Asset Inventory 的 gcloud asset search-all-resources 給你相同的檢視。

根據帳單交叉參照。任何花費金錢的東西都應該出現在你的資源清單;清單中零近期活動的任何東西都是歸檔的候選。這裡的差異通常是可怕的東西藏身之處 — 帶有公開 IP 的孤立 EC2 執行個體、未加密的忘記 RDS 快照、指向虛無的負載平衡器。

像審查犯罪現場一樣審查 IAM

提取每個 IAM 政策並查找 "Action": "*" 結合 "Resource": "*"。那個組合不應該存在於少數幾個緊急管理角色之外,即使這些也應該有 MFA 強制執行和 CloudTrail 警報。使用 IAM Access Analyzer 尋找授予外部帳戶存取權的角色 — 這會捕捉有意的跨帳戶信任關係和某人對錯誤帳戶 ID 測試 Terraform 模組的錯誤。

用 aws iam generate-credential-report 檢查超過 90 天的存取金鑰。繼承的環境幾乎總是有長期金鑰連附到服務帳戶,有時硬編碼在 Lambda 環境變數或 Jenkins 工作中。輪換它們,但分階段進行 — 殺死夜間批次工作在上午 2 點依賴的金鑰是你在第一週被呼叫的方式。

在攻擊者之前找到公開暴露

執行跨 VPC 的網路可達性檢查。安全群組在 80/443 以外的任何東西上有 0.0.0.0/0 需要正當理由,不是假設。ScoutSuite 或 Prowler 之類的工具會在幾分鐘內處理完帳戶並輸出按嚴重程度排名的報告 — 從那裡開始,而不是從頭建置你自己的檢查清單。

S3 值區值得特別注意,因為它們是繼承環境地雷的經典例子。檢查值區政策和帳戶層級的區塊公開存取設定;某人可能多年前為了一次性靜態網站停用帳戶預設,從未將其轉回。aws s3api list-buckets 結合在每個值區上迴圈檢查 get-bucket-acl 和 get-bucket-policy-status 對大多數帳戶在十分鐘內給你清晰的圖片。

在建立信任之前先建立日誌

如果 CloudTrail、VPC Flow Logs 或 GuardDuty 還沒有到處執行,現在就開啟,在你做任何其他改變之前。你想要一份從這點開始發生的事的記錄,而你想要它在開始刪除之前,因為刪除正是錯誤發生並歸咎於新人的時候。如果完全可能,將日誌寄到單獨的帳戶或訂閱,所以受侵害的工作負載也不能清除自己的證據。

設定 GuardDuty 或 Azure Defender for Cloud 並將警報路由到人類實際檢查的地方 — 不是有 400 條未讀訊息的 Slack 頻道。偵測工具的價值接近零,如果警報落入虛無。

先修復最吵的問題,記錄一切

你不會在一次衝刺中修復繼承的環境。根據爆炸半徑分類:公開資料暴露優先,然後是過度授權的身份,然後是網路區隔,然後是一切其他。寫下你找到和改變的東西,即使在純文字 Google Doc 中,因為下一個從你這裡繼承這個的人值得比你得到的更好。

當你收緊安全群組而開發人員的整合測試開始失敗時,預期會有反對。那很正常 — 這表示審查有效。在生產中翻轉任何東西之前,與擁有工作負載的團隊交談,並在前兩週準備好回滾計畫。

如需更多關於雲端審查工具和推理,查看 Korra Studio 在 IAM 強化和雲端偵測工程上的段落 — 兩者都與上面的工作流程搭配得很好。