今天小李哥將開啟全新的技術(shù)分享系列，為大家介紹生成式AI的安全解決方案設(shè)計方法和最佳實踐。近年來生成式 AI 安全市場正迅速發(fā)展。據(jù)IDC預測，到2025年全球 AI 安全解決方案市場規(guī)模將突破200億美元，年復合增長率超過30%，而Gartner則預估到2025年約30%的網(wǎng)絡(luò)攻擊將利用生成式AI技術(shù)。與此同時，Capgemini的調(diào)查顯示，近74%的企業(yè)認為AI驅(qū)動的安全防護至關(guān)重要，加上Cybersecurity Ventures報告指出，與生成式AI相關(guān)的安全事件年增長率超過20%，這充分表明企業(yè)和安全供應(yīng)商正面臨日益嚴峻的安全挑戰(zhàn)，并加大投入以構(gòu)建更全面的防護體系。今天要介紹的就是如何設(shè)計生成式AI應(yīng)用安全解決方案，抵御OWASP Top 10攻擊。未來也會分享更多的AI安全解決方案，歡迎大家關(guān)注。

目前我們生活中有各色各樣的生成式AI應(yīng)用，常見的場景之一就是生成式AI對話助手。然而在部署之前，通常還要對應(yīng)用進行評估，其中包括了解安全態(tài)勢、監(jiān)控和日志記錄、成本跟蹤、彈性等問題。在這些評估中，安全性通常是最高優(yōu)先級。如果存在無法明確識別的安全風險，我們就無法有效解決這些風向，這可能會阻礙生成式AI應(yīng)用向生產(chǎn)環(huán)境部署的進度。

在本文章中，小李哥將向大家展示一個自己設(shè)計的生成式應(yīng)用的真實場景，并演示如何利用 OWASP安全框架，基于大語言模型應(yīng)用常見的Top 10安全攻擊來評估應(yīng)用的安全態(tài)勢，以及實施緩解措施。下圖就是一個生成式AI應(yīng)用的安全解決方案最佳實踐，我們將繼續(xù)從左到右詳細介紹本方案中使用到的安全方案細節(jié)。

應(yīng)用控制層

應(yīng)用層通常容易遭受到諸如LLM01:2025提示注入、LLM05:2025輸出處理不當以及LLM02:2025敏感信息泄露等風險。惡意攻擊者可能會頻繁嘗試惡意的提示詞輸入來操控AI模型，從而可能通過AI模型泄露敏感信息或危及下游的應(yīng)用系統(tǒng)。

在我們開頭的架構(gòu)圖中，應(yīng)用層的服務(wù)器就是亞馬遜云科技無服務(wù)器計算服務(wù)Lambda。它通過從 API Gateway中提取事件的數(shù)據(jù)部分并進行語法和語義校驗，實施嚴格的輸入驗證。通過對輸入請求進行清洗、應(yīng)用白名單和需要組織的關(guān)鍵字黑名單，并預定義合法請求的格式和規(guī)則進行驗證，使用Lambda服務(wù)有助于防止LLM01:2025提示注入攻擊。此外通過將user_id字段傳遞到下游應(yīng)用中，可以使下游應(yīng)用組件降低敏感信息泄露的風險，從而解決了LLM02:2025敏感信息泄露的問題。

同時亞馬遜云科技Bedrock Guardrails提供了額外的大模型輸入輸出保護層，可過濾和攔截敏感內(nèi)容，如個人身份信息（PII）以及通過正則表達式定義的自定義敏感數(shù)據(jù)。Guardrails還有檢測和屏蔽攻擊性語言、競爭對手名稱或其他不希望出現(xiàn)的詞語，確保輸入和輸出均安全。大家還可以利用 Guardrails在有害或操控性的提示詞到達AI模型之前就進行檢測和過濾，從而防止LLM01:2025提示注入攻擊，維護提示詞的完整性。

另一個關(guān)鍵的安全方面是管理AI模型的輸出。由于AI模型可能生成包含可執(zhí)行代碼的內(nèi)容，比如 JavaScript或Markdown，如果這些內(nèi)容處理不當，就存在XSS攻擊的風險。為降低此類風險，我們需要使用輸出編碼技術(shù)，例如HTML實體編碼或JavaScript轉(zhuǎn)義，在將內(nèi)容呈現(xiàn)給用戶前將任何潛在有害內(nèi)容進行無害化轉(zhuǎn)換。此方法解決了LLM05:2025輸出處理不當?shù)娘L險。

我們也可以利用亞馬遜云科技Bedrock的提示管理和版本控制，使得在不斷提升用戶體驗的同時，也能維持整個應(yīng)用的安全性。通過完善管理提示詞及其處理方式的變更，在增強IA模型功能的同時不會引入新的漏洞，并降低LLM01:2025提示注入攻擊的風險。

降低未經(jīng)授權(quán)或非預期的AI模型操作風險的策略的核心就是：“將AI模型視為不受信任的信息來源，并在某些操作上采用人工介入流程”。

亞馬遜云科技Bedrock大語言模型與代理層

AI模型與AI模型代理層經(jīng)常處理與AI模型的交互，面臨諸如LLM10:2025不受限制的使用、LLM05:2025輸出處理不當以及LLM02:2025敏感信息泄露等風險。

拒絕服務(wù)（DoS）攻擊可能會通過大量資源密集型請求使AI模型處理不堪重負，從而降低整體服務(wù)質(zhì)量并增加成本。在與亞馬遜云科技Bedrock托管的AI模型交互時，設(shè)置諸如輸入請求的最大長度等請求參數(shù)，將有助于降低AI模型資源耗盡的風險。此外亞馬遜云科技Bedrock代理對隊列中的最大動作數(shù)量以及完成客戶意圖的總動作數(shù)都有硬性限制，這限制了系統(tǒng)對AI模型代理基于用戶需求所采取的總動作數(shù)量，避免了可能耗盡AI模型資源的異常死循環(huán)或密集任務(wù)。

輸出處理不當會導致遠程代碼執(zhí)行、跨站腳本（XSS）、服務(wù)器端請求偽造（SSRF）以及權(quán)限提升等安全漏洞。對AI模型生成的輸出在發(fā)送到下游服務(wù)前，如果驗證和管理不佳，就可能間接開放漏洞攻擊面，讓這些漏洞有機可乘。為降低這一風險，應(yīng)將模型視為普通的應(yīng)用用戶一樣，對 LLM生成的響應(yīng)進行安全驗證。亞馬遜云科技Bedrock Guardrails利用可配置閾值的內(nèi)容過濾器來過濾各種有害內(nèi)容，并在這些響應(yīng)被其他后端系統(tǒng)進一步處理之前就進行阻攔，從而簡化了這一過程。Guardrails會自動評估用戶輸入和模型響應(yīng)，檢測并幫助防止有害的內(nèi)容。

亞馬遜云科技Bedrock代理在執(zhí)行多步驟任務(wù)時，與亞馬遜云科技原生服務(wù)以及外部的第三方服務(wù)安全集成，從而有效解決輸出處理不安全、過量代理行為和敏感信息泄露的風險。在文章開頭的架構(gòu)圖中，代理下的action group中的Lambda服務(wù)用于對所有輸出文本進行編碼，使其自動無法被 JavaScript或Markdown異常執(zhí)行。此外action group中的Lambda函數(shù)會解析和記錄代理每一步執(zhí)行時從AI模型得到的回復，并根據(jù)恢復內(nèi)容相應(yīng)地控制輸出，確保在下一步處理前輸出內(nèi)容完全安全。

敏感信息泄露是AI模型面臨的另一大風險，因為惡意的提示工程可能會導致AI模型無意中在響應(yīng)中泄露不該公開的細節(jié)，從而引發(fā)AI模型隱私和機密性問題。為緩解這一問題，可以通過亞馬遜云科技 Bedrock Guardrails中的內(nèi)容過濾器實施數(shù)據(jù)清洗措施。

另外還應(yīng)根據(jù)user_id實施自定義、精細化的數(shù)據(jù)過濾策略，并根據(jù)id執(zhí)行嚴格的用戶訪問策略。亞馬遜云科技Bedrock Guardrails可以過濾敏感內(nèi)容，亞馬遜云科技Bedrock代理則通過允許大家在預處理輸入的提示詞模板和處理響應(yīng)的提示詞模板中實施自定義邏輯來去除任何非預期的有害信息，進一步降低了敏感信息泄露的風險。如果大家已為AI模型啟用了模型調(diào)用日志記錄，或者在應(yīng)用中實施了自定義日志邏輯，將 AI模型的輸入和輸出記錄到亞馬遜云科技CloudWatch中，那我們也需要開啟CloudWatch日志數(shù)據(jù)保護等措施，在CloudWatch日志中識別和屏蔽敏感信息，從而進一步降低敏感信息泄露的風險。

代理插件控制層（action group Lambda函數(shù)）

代理插件控制層經(jīng)常需要與內(nèi)部和外部服務(wù)集成，并對內(nèi)部和外部數(shù)據(jù)源以及外部第三方API應(yīng)用授權(quán)。LLM08:2025向量與嵌入薄弱性以及LLM06:2025代理行為過度的風險開始顯現(xiàn)。不受信或未經(jīng)驗證的第三方插件可能會以惡意代碼的形式引入后門或漏洞。

對與外部系統(tǒng)進行集成交互的action group Lambda函數(shù)所使用的IAM角色，應(yīng)使用最小權(quán)限原則原則，有助于解決LLM06:2025代理行為過度和LLM08:2025向量與嵌入薄弱性的風險。從文章開頭的架構(gòu)圖可以看出，代理插件層的Lambda函數(shù)便是關(guān)聯(lián)了一個最小權(quán)限的 IAM 角色，用以安全訪問和與其他內(nèi)部亞馬遜云科技服務(wù)進行交互。

此外在確定用戶身份后，通過將user_id傳遞給下游集成應(yīng)用（如代理插件層），通過基于用戶id身份授權(quán)訪問，從而進一步限制數(shù)據(jù)的訪問。雖然這個user_id參數(shù)可在代理插件控制層的Lambda函數(shù)中用于自定義授權(quán)邏輯，但其主要作用就是用于為外部第三方插件提供基于用戶身份的細粒度的訪問控制。應(yīng)用所有者有責任在action group Lambda函數(shù)中實施自定義授權(quán)邏輯，該自定義邏輯需要將user_id參數(shù)與開發(fā)者預定義授權(quán)規(guī)則相結(jié)合，為第三方API和插件應(yīng)用配置安全的訪問授權(quán)級別。此方法將確定性的訪問控制應(yīng)用于非確定性的AI模型前，使得對哪些用戶可以訪問和執(zhí)行特定外部第三方插件實現(xiàn)了細粒度控制。

將基于user_id的數(shù)據(jù)授權(quán)與IAM角色的最小權(quán)限相結(jié)合，一般可最大限度地降低LLM08:2025向量與嵌入薄弱性以及LLM06:2025代理非預期行為的風險。

RAG知識庫數(shù)據(jù)存儲層

RAG的數(shù)據(jù)存儲層負責安全地從各類亞馬遜云科技上的數(shù)據(jù)源和外部第三方數(shù)據(jù)源中檢索最新、精準且受到訪問控制的數(shù)據(jù)。在默認情況下，亞馬遜云科技Bedrock使用了KMS秘鑰服務(wù)，加密所有與知識庫相關(guān)的數(shù)據(jù)。大家也可以選擇使用Customer managed的KMS密鑰。在為知識庫配置數(shù)據(jù)提取任務(wù)時，還可以使用Custom KMS密鑰對任務(wù)進行加密。

如果大家想選取OpenSearch Service作為知識庫的向量存儲，Amazon Bedrock可將大家選擇好的 KMS密鑰傳遞給它進行向量數(shù)據(jù)加密。此外在生成查詢知識庫響應(yīng)的會話中，也可以使用KMS密鑰對會話進行加密。為了便于安全通信，Amazon Bedrock知識庫在與第三方向量存儲進行數(shù)據(jù)交互時，默認使用TLS加密，前提是該服務(wù)支持并允許TLS加密傳輸。

關(guān)于用戶訪問權(quán)限控制，亞馬遜云科技Bedrock知識庫使用篩選來管理對數(shù)據(jù)的訪問權(quán)限。大家可以利用文件元數(shù)據(jù)和過濾功能，在知識庫上構(gòu)建數(shù)據(jù)隔離訪問解決方案。在運行應(yīng)用時，必須對用戶進行身份驗證和授權(quán)，并在請求中包含該用戶的驗證信息，以保持準確和一致的訪問控制。為了使訪問控制持續(xù)生效，大家應(yīng)定期在篩選配置中重新同步配置，以反映用戶權(quán)限變化。另外用戶組也可以作為一個篩選屬性，對知識庫中的文件進行精細化訪問控制。

這種方法有助于解決LLM02:2025敏感信息泄露和LLM08:2025向量與嵌入薄弱性的風險，確保只有授權(quán)用戶才能訪問相關(guān)數(shù)據(jù)。

總結(jié)

在本文中，小李哥如何利用亞馬遜云科技生成式AI安全合規(guī)框架，從亞馬遜云科技安全共擔責任模型的角度對生成式AI應(yīng)用分為5大類，對于不同類別我們應(yīng)用了不同的安全控制。同時我們回顧了一個常見的生成式AI應(yīng)用的安全架構(gòu)和最佳實踐，再利用OWASP Top 10 for LLM風險評估模型評估了genAI應(yīng)用安全態(tài)勢，同時展示了如何利用亞馬遜云科技服務(wù)有效解決OWASP Top 10 for LLM的常見威脅和風險，從而保護生成式AI應(yīng)用的系統(tǒng)。想了解更多關(guān)于在亞馬遜云科技構(gòu)建安全生成式AI應(yīng)用和AI安全的信息，歡迎大家關(guān)注小李哥不要錯過更多精彩文章。