當AI能自動查Salesforce、調(diào)Lambda函數(shù)、讀SharePoint文檔時，它到底是你的效率工具，還是攻擊者最想要的跳板？

XM Cyber威脅研究團隊最近完成了對AWS Bedrock的全棧分析，驗證了8條真實攻擊路徑。這些路徑的起點都很卑微——某個被忽視的IAM權(quán)限，某個配置失誤的日志桶——但終點可能是你的核心數(shù)據(jù)庫、AD域控，或者全部客戶數(shù)據(jù)。

攻擊向量1-2：日志系統(tǒng)變成竊聽器和橡皮擦

Bedrock默認會記錄所有模型交互，存進S3供審計。這本是合規(guī)設(shè)計，卻給攻擊者開了兩扇窗。

第一扇窗是竊聽。攻擊者如果能讀取現(xiàn)有的日志桶，直接翻歷史prompt就能 harvest 敏感數(shù)據(jù)。如果讀不了，可以用bedrock:PutModelInvocationLoggingConfiguration把日志重定向到自己控制的桶。配置改完，后續(xù)所有對話實時外流，管理員在控制臺里看不出任何異常。

第二扇窗是滅證。拿到s3:DeleteObject或logs:DeleteLogStream權(quán)限后，攻擊者能精準刪除特定時段的日志——比如自己剛剛完成的越獄嘗試。 forensic 團隊事后只能看到"正常的對話記錄"，攻擊痕跡被抹得干干凈凈。

日志系統(tǒng)的設(shè)計悖論在于：它越全面，被攻破后的損失就越完整。

攻擊向量3-4：知識庫的數(shù)據(jù)源成為繞過后門

Bedrock Knowledge Bases用RAG（檢索增強生成）把企業(yè)數(shù)據(jù)喂給模型。數(shù)據(jù)源可能是S3、Salesforce、SharePoint、Confluence——這些系統(tǒng)對Bedrock開放，攻擊者就能跟著混進去。

最直接的 bypass：有s3:GetObject權(quán)限就能跳過模型，直接從底層桶拉原始數(shù)據(jù)。不需要構(gòu)造prompt，不需要繞過guardrail，API調(diào)用就能拖走全部文檔。

更隱蔽的 lateral movement：Bedrock連接SaaS服務(wù)時需要存憑證。攻擊者如果能retrieve并decrypt這些secret，就能拿到SharePoint的訪問令牌。XM Cyber指出，這些憑證在部分配置下足以橫向移動到Active Directory——從"AI平臺的一個配置項"跳到"整個域控的入口"。

RAG的架構(gòu)讓數(shù)據(jù)流動更順暢，也讓攻擊路徑更短。

攻擊向量5-6：向量數(shù)據(jù)庫的憑證成為萬能鑰匙

數(shù)據(jù)被 ingestion 后，實際存在向量數(shù)據(jù)庫里——Pinecone、Redis Enterprise Cloud是Bedrock的常見搭檔。這些數(shù)據(jù)庫的訪問憑證通常存在Bedrock的StorageConfiguration里。

攻擊者調(diào)用bedrock:GetKnowledgeBase API就能拿到endpoint地址和API key。有了這兩樣，再加上網(wǎng)絡(luò)可達性，就能直接查詢向量數(shù)據(jù)庫的索引內(nèi)容。

這里的關(guān)鍵是：向量數(shù)據(jù)庫的權(quán)限模型往往比源系統(tǒng)更粗粒度。你可能給Bedrock開了只讀權(quán)限，但API key本身對應的是更高權(quán)限的服務(wù)賬號。攻擊者拿到的不是"能查什么"的約束，而是"能查全部"的鑰匙。

攻擊向量7-8：Agent和Flow的劫持與污染

Bedrock Agent能自主執(zhí)行多步驟任務(wù)，Bedrock Flow能編排復雜業(yè)務(wù)邏輯。這兩個功能把AI從"回答問題"升級到"操作業(yè)務(wù)系統(tǒng)"，攻擊面也隨之擴大。

Agent hijacking：Agent的指令集、工具配置、系統(tǒng)prompt都可能成為注入目標。攻擊者如果能修改Agent的action group定義，就能讓它在執(zhí)行任務(wù)時調(diào)用惡意端點，或者把中間結(jié)果外發(fā)到第三方。

Flow injection：Flow的節(jié)點之間有數(shù)據(jù)傳遞，攻擊者如果在某個上游節(jié)點注入惡意內(nèi)容，可能污染整個處理鏈條。更麻煩的是，F(xiàn)low的調(diào)試信息往往包含中間狀態(tài)，這些日志又可能落入攻擊者控制的桶——形成"攻擊-竊聽-再攻擊"的閉環(huán)。

Guardrail的設(shè)計目標是攔截有害輸出，但XM Cyber發(fā)現(xiàn)多個繞過方式：通過精心構(gòu)造的多輪對話逐步degrade guardrail的有效性，或者利用不同模型版本之間的策略差異找到縫隙。

權(quán)限模型的根本困境

這8個向量的共同特征是：都始于某個細粒度權(quán)限的誤配或濫用，終于企業(yè)核心資產(chǎn)的暴露。Bedrock的架構(gòu)決定了它必須廣泛連接——連S3、連數(shù)據(jù)庫、連SaaS、連內(nèi)部API——而每次連接都是潛在的pivot point。

AWS的IAM已經(jīng)細到能控制bedrock:GetKnowledgeBase這種單一動作，但現(xiàn)實中的配置往往是"為了讓它跑起來"而過度授權(quán)。一個能PutModelInvocationLoggingConfiguration的角色，可能本只需要讀權(quán)限；一個能GetKnowledgeBase的服務(wù)賬號，可能永遠不需要看到StorageConfiguration里的明文憑證。

XM Cyber的建議很具體：把Bedrock組件當作infrastructure node而非"AI服務(wù)"來建模，用攻擊路徑分析工具持續(xù)驗證"從Bedrock權(quán)限能走到哪"。

他們的研究團隊在最后備注里寫了一句：「我們測試時發(fā)現(xiàn)的配置問題，在真實客戶環(huán)境里全部存在過。」這不是零日漏洞的戲劇性，而是權(quán)限管理疲勞的日常性——AI平臺只是把舊問題放大了新倍數(shù)。