AWS RDS snapshot 短暫公開都可洩資料:管理員點樣堵住掃描盲點
Tech News

AWS RDS snapshot 短暫公開都可洩資料:管理員點樣堵住掃描盲點

圖片:via iThome — https://www.ithome.com.tw/news/177742
TechLab 編輯部(譯)·

研究揭示兩分鐘設定窗口,定時掃描同事後告警未必趕得切

AWS 管理員見到 RDS snapshot 由公開改返私人,可能以為件事已經完咗。不過只要公開過幾分鐘,其他 AWS 帳戶已經有機會開始複製或者還原入面嘅資料。**呢件事係客戶設定出錯,唔係 AWS 服務有漏洞。**麻煩係呢類設定出現得快,消失得仲快,普通定時掃描未必捉到任何異常。

兩分鐘點解已經太耐

雲端保安公司 Aryon Security 連續數日監察公開嘅 RDS、DocumentDB snapshot、AMI 同 SSM document。團隊話,20% 公開 RDS snapshot 喺清單出現後唔夠兩分鐘就消失。攻擊者唔使喺呢兩分鐘內下載成個資料庫。研究人員話,自動程式只要及時啟動複製或還原,就可以之後喺自己帳戶慢慢檢查;原擁有人就算改返私人,亦收唔返已經複製咗嘅版本。

研究團隊另抽查 24 個近期公開嘅 RDS snapshot,成功還原部分樣本,分析後搵到電郵地址、私密金鑰同信用卡號等資料。24 個只係細樣本,證明唔到所有公開 snapshot 都有敏感內容;研究亦冇證據顯示相關資源曾經俾真正攻擊者取得,所以唔應該將結果講成已確認嘅大規模資料外洩。

AWS RDS 管理介面入面設定 snapshot 分享帳戶嘅畫面

圖片:AWS

373 萬係推算,唔好當官方統計

iThome 報道,Aryon 按數日觀察結果推算,AWS 每年約有 373 萬項不同資源一度公開。呢個數涵蓋多種資源,亦係研究團隊將短期數據推展成全年估值,AWS 冇發布同一統計。研究本身由售賣雲端保安產品嘅公司發表,佢主張用預防式政策取代事後掃描,產品立場好鮮明;數據值得管理員查自己環境,但唔適合用嚟估算整個 AWS 有幾多公司已經洩密。

Change-triggered 都可以遲十二個鐘

AWS Security Hub 嘅 RDS.1 control 會用 AWS Config 規則檢查 snapshot 有冇公開,官方亦標明設定轉成公開後,合規結果最長可能要十二個鐘先捕捉到。換句話講,介面寫住 change-triggered 都唔代表即時阻擋。如果 snapshot 兩分鐘內公開再收返,掃描見到嘅可能一直係合規狀態。定時掃描仍然適合搵長期設定錯誤,不過佢擋唔住呢種短窗口。

第一層先由加密封死公開分享

AWS 官方文件寫明,加密 RDS snapshot 唔可以設成 public,所以新 RDS database、cluster 同 snapshot 應預設加密。呢招對新資源最乾脆,但唔會自動修補既有嘅未加密 database;舊系統仍可產生能夠公開分享嘅 snapshot。合法跨帳戶分享亦要留意 KMS:用預設 AWS KMS key 加密嘅 snapshot 唔能夠分享,團隊要預先設計 customer-managed key 同指定帳戶權限。

第二層用 SCP 卡住修改權限

冇公開分享用途嘅 AWS Organizations,可以用 Service Control Policy 拒絕 rds:ModifyDBSnapshotAttributerds:ModifyDBClusterSnapshotAttribute,由 API 入口封住權限改動。Aryon 提醒,AWS 暫時冇合適嘅 SCP condition key,精準分開公開分享同指定帳戶私人分享;一刀切拒絕會連正常跨帳戶備份流程都截停。政策應先放入測試 OU,再按角色、帳戶或備份環境設例外,唔好直接掛上 organization root。

第三層用 CloudTrail 追事件,第四層集中治理

CloudTrail 預設保留每個帳戶、每個 Region 過去 90 日嘅 management event。管理員可搜尋 ModifyDBSnapshotAttribute,再檢查 request 有冇向 ValuesToAdd 加入 all;cluster snapshot 就查相應嘅 cluster API。大型環境應另建 organization trail 或 event data store,集中保存多帳戶紀錄,再將高危修改送去告警或自動改返私人。事件紀錄負責留證同加快回應,SCP 同加密先可以喺動作發生前截停。

同一套盤點亦要伸延去 DocumentDB、AMI 同 SSM。各項服務唔係共用同一個公開分享開關:例如 SSM block public sharing 係逐帳戶、逐 Region 設定,開啟後亦唔會清走原本已公開嘅 document。用 AWS RDS、DocumentDB、自製 AMI 或 SSM automation 嘅公司同開發團隊,都應逐個帳戶、逐個 Region 查一次現況,再決定邊啲分享功能可以直接封鎖。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook