使用OWASP十大防範措施保障生成式AI助手

許多客戶在評估生成式人工智慧的生產應用時，常常會考慮使用生成式人工智慧助手。然而，在部署之前，通常需要進行生產準備評估，這包括了解安全性、監控和記錄、成本追蹤、韌性等問題。在這些生產準備評估中，安全性通常是最重要的優先事項。如果有安全風險無法明確識別，那麼就無法解決這些問題，這可能會阻礙生成式人工智慧應用的生產部署。

在這篇文章中，我們將展示一個生成式人工智慧助手應用的例子，並演示如何使用 OWASP 前十名 (OWASP Top 10) 來評估其安全性，特別是針對大型語言模型 (Large Language Model, LLM) 應用的安全性，以及如何應對常見威脅。

生成式人工智慧範疇框架

首先，了解你的生成式人工智慧應用在管理型和自定義型之間的定位。使用 AWS 生成式人工智慧範疇框架來了解適用於你應用的安全控制的具體責任分配。例如，範疇 1 的「消費者應用程式」如 PartyRock 或 ChatGPT 通常是面向公眾的應用程式，大部分內部安全由提供者負責，而你的安全責任則在於使用端。相比之下，範疇 4/5 的應用程式，不僅需要你自己構建和保護生成式人工智慧應用，還需要你負責微調和訓練底層的大型語言模型 (LLM)。範疇 4/5 應用的安全控制範圍會更廣，涵蓋前端到 LLM 模型的安全性。這篇文章將重點討論範疇 3 的生成式人工智慧助手應用，這是現場中較為常見的用例之一。

以下是 AWS 生成式人工智慧安全範疇矩陣的圖示，總結了每個範疇的模型類型。

LLM 的 OWASP 前十名

使用 OWASP 前十名來了解應用程式的威脅和應對措施是評估應用安全性最常見的方法之一。LLM 的 OWASP 前十名將一個經過驗證的框架應用於生成式人工智慧應用，幫助我們發現、理解和減輕生成式人工智慧的新威脅。

解決方案概述

讓我們從一個典型的生成式人工智慧助手應用的邏輯架構開始，並將其與 LLM 威脅的 OWASP 前十名進行對照，如下圖所示。

在這個架構中，最終用戶的請求通常會經過以下幾個組件：

認證層 – 此層驗證連接到應用程式的用戶是否為他們所聲稱的身份。這通常通過某種身份提供者 (IdP) 功能來完成，例如 Okta、AWS IAM 身份中心或 Amazon Cognito。
應用程式控制器 – 此層包含大部分應用程式的業務邏輯，並決定如何處理進來的用戶請求，生成 LLM 提示並在發送回用戶之前處理 LLM 回應。
LLM 和 LLM 代理 – LLM 提供助手的核心生成式人工智慧能力。LLM 代理是一組步驟的協調者，這些步驟可能是完成所需請求所必需的。這些步驟可能涉及使用 LLM 和外部數據源及 API。
代理插件控制器 – 此組件負責與外部數據源和 API 的 API 整合。此組件還持有 LLM 代理可能參考的外部組件的邏輯名稱與物理名稱之間的映射。
RAG 數據存儲 – 檢索增強生成 (Retrieval Augmented Generation, RAG) 數據存儲從各種數據源（如數據倉庫、數據庫和其他軟體即服務 (SaaS) 應用）通過數據連接器提供最新、準確和受控的知識。

LLM 的 OWASP 前十名風險映射到應用程式堆疊的各個層面，突顯了從用戶界面到後端系統的漏洞。在接下來的部分中，我們將討論每一層的風險，並提供一個在 AWS 上的生成式人工智慧助手應用的設計模式，以減輕這些風險。

以下圖示展示了 AWS 上的助手架構。

認證層 (Amazon Cognito)

常見的安全威脅如暴力破解攻擊、會話劫持和拒絕服務 (DoS) 攻擊可能會發生。為了減輕這些風險，實施最佳實踐，如多因素身份驗證 (MFA)、速率限制、安全會話管理、自動會話超時和定期令牌輪換。此外，部署邊緣安全措施，如 AWS WAF 和分佈式拒絕服務 (DDoS) 緩解，有助於阻止常見的網路攻擊並在攻擊期間保持服務可用性。

在前面的架構圖中，AWS WAF 與 Amazon API Gateway 整合，以過濾進來的流量，阻止不必要的請求，並保護應用程式免受 SQL 注入、跨站腳本 (XSS) 和 DoS 攻擊等威脅。AWS WAF 機器人控制進一步增強了安全性，提供對機器人流量的可見性和控制，允許管理員阻止或限制不需要的機器人。此功能可以通過 AWS 防火牆管理器在多個帳戶中集中管理，提供一致且強大的應用保護方法。

Amazon Cognito 補充了這些防禦，通過用戶身份驗證和數據同步來增強安全性。它支持用戶池和身份池，實現跨設備的用戶身份無縫管理，並與第三方身份提供者整合。Amazon Cognito 提供安全功能，包括 MFA、OAuth 2.0、OpenID Connect、安全會話管理和基於風險的自適應身份驗證，幫助防止未經授權的訪問，通過評估登錄請求的可疑活動並以 MFA 或阻止登錄等額外安全措施作出反應。Amazon Cognito 還強制執行密碼重複使用預防，進一步保護免受被盜憑證的風險。

AWS Shield Advanced 提供額外的防禦層，增強對複雜 DDoS 攻擊的保護。與 AWS WAF 整合，Shield Advanced 提供全面的邊界保護，使用量身定制的檢測和健康評估來增強對攻擊的反應。它還提供來自 AWS Shield 反應團隊的全天候支持，並包括 DDoS 成本保護，使應用保持安全且具成本效益。Shield Advanced 和 AWS WAF 共同創建了一個安全框架，保護應用免受各種威脅，同時保持可用性。

這個全面的安全設置解決了 LLM10:2025 無限制消耗和 LLM02:2025 敏感信息披露的風險，確保應用保持韌性和安全。

應用控制器層 (LLM 協調 Lambda 函數)

應用控制器層通常容易受到 LLM01:2025 提示注入、LLM05:2025 不當輸出處理和 LLM02:2025 敏感信息披露等風險的影響。外部方可能經常試圖通過製作意外的輸入來利用這一層，操縱 LLM，可能導致其洩露敏感信息或危害下游系統。

在物理架構圖中，應用控制器是 LLM 協調 AWS Lambda 函數。它通過從 API Gateway 提取事件有效載荷並進行語法和語義驗證來執行嚴格的輸入驗證。通過清理輸入、應用關鍵字的允許清單和拒絕清單，以及根據預定格式或模式驗證輸入，Lambda 函數有助於防止 LLM01:2025 提示注入攻擊。此外，通過將 user_id 傳遞到下游，能夠使下游應用組件減輕敏感信息披露的風險，解決與 LLM02:2025 敏感信息披露相關的問題。

Amazon Bedrock Guardrails 提供額外的保護層，通過過濾和阻止敏感內容，如個人識別信息 (PII) 和其他自定義的敏感數據（由正則表達式模式定義）來增強安全性。Guardrails 還可以配置為檢測和阻止冒犯性語言、競爭對手名稱或其他不受歡迎的術語，確保輸入和輸出都是安全的。你還可以使用 guardrails 來防止 LLM01:2025 提示注入攻擊，通過檢測和過濾有害或操縱性的提示，確保它們在到達 LLM 之前保持完整性。

安全的另一個關鍵方面是管理 LLM 的輸出。由於 LLM 可能生成包含可執行代碼（如 JavaScript 或 Markdown）的內容，如果這些內容未得到妥善處理，則可能會面臨 XSS 攻擊的風險。為了減輕這一風險，應用輸出編碼技術，如 HTML 實體編碼或 JavaScript 轉義，以中和任何潛在有害的內容，然後再呈現給用戶。這種方法解決了 LLM05:2025 不當輸出處理的風險。

實施 Amazon Bedrock 提示管理和版本控制可以持續改善用戶體驗，同時保持應用的整體安全性。通過仔細管理提示及其處理的變更，可以在不引入新漏洞的情況下增強功能，並減輕 LLM01:2025 提示注入攻擊的風險。

將 LLM 視為不受信任的用戶，並對某些操作應用人類參與的過程，是降低未經授權或意外操作可能性的策略。

LLM 和 LLM 代理層 (Amazon Bedrock LLMs)

LLM 和 LLM 代理層經常處理與 LLM 的互動，並面臨 LLM10: 無限制消耗、LLM05:2025 不當輸出處理和 LLM02:2025 敏感信息披露等風險。

DoS 攻擊可能會用多個資源密集型請求淹沒 LLM，降低整體服務質量，同時增加成本。在與 Amazon Bedrock 托管的 LLM 互動時，設置請求參數，如輸入請求的最大長度，將最小化 LLM 資源耗盡的風險。此外，Amazon Bedrock 代理可以執行的排隊動作和總動作的最大數量有硬性限制，這限制了系統對 LLM 回應的反應動作數量，避免不必要的循環或密集任務，從而耗盡 LLM 的資源。

不當輸出處理會導致遠程代碼執行、跨站腳本、伺服器端請求偽造 (SSRF) 和權限提升等漏洞。在將 LLM 生成的輸出發送到下游之前，對其進行不充分的驗證和管理可能會間接授予額外功能的訪問權限，有效地使這些漏洞得以利用。為了減輕這一風險，應將模型視為任何其他用戶，並對 LLM 生成的回應進行驗證。這一過程通過 Amazon Bedrock Guardrails 的過濾器（如具有可配置閾值的內容過濾器）來促進，以過濾有害內容並防止提示攻擊，防止其進一步被其他後端系統處理。Guardrails 自動評估用戶輸入和模型回應，以檢測並幫助防止落入限制類別的內容。

Amazon Bedrock 代理執行多步任務，並安全地與 AWS 原生和第三方服務整合，以降低不安全輸出處理、過度代理和敏感信息披露的風險。在架構圖中，代理下的行動組 Lambda 函數用於編碼所有輸出文本，使其自動不被 JavaScript 或 Markdown 執行。此外，行動組 Lambda 函數在代理執行的每一步中解析 LLM 的每個輸出，並根據需要控制輸出的處理，確保它們在進一步處理之前是安全的。

敏感信息披露是 LLM 的一個風險，因為惡意的提示工程可能會導致 LLM 在其回應中意外洩露不必要的細節。這可能會導致隱私和保密的違反。為了減輕這一問題，通過 Amazon Bedrock Guardrails 的內容過濾器實施數據清理實踐。

此外，根據 user_id 和嚴格的用戶訪問政策實施自定義數據過濾策略。Amazon Bedrock Guardrails 有助於過濾被認為敏感的內容，而 Amazon Bedrock 代理則進一步降低敏感信息披露的風險，通過允許你在預處理和後處理模板中實施自定義邏輯來剔除任何意外信息。如果你已啟用 LLM 的模型調用日誌，或在應用中實施自定義日誌邏輯以記錄 LLM 的輸入和輸出到 Amazon CloudWatch，則 CloudWatch 日誌數據保護等措施對於掩蓋在 CloudWatch 日誌中識別的敏感信息非常重要，進一步減輕敏感信息披露的風險。

代理插件控制器層 (行動組 Lambda 函數)

代理插件控制器經常與內部和外部服務整合，並對內部和外部數據源及第三方 API 應用自定義授權。在這一層，LLM08:2025 向量和嵌入弱點及 LLM06:2025 過度代理的風險正在發生。不受信任或未經驗證的第三方插件可能會引入後門或漏洞，形式為意外的代碼。

對行動組 Lambda 函數的 AWS 身份和訪問管理 (IAM) 角色應用最小權限訪問，以幫助減輕 LLM06:2025 過度代理和 LLM08:2025 向量和嵌入弱點的風險。在物理架構圖中，代理插件層 Lambda 函數與最小權限 IAM 角色相關聯，以安全訪問和與其他內部 AWS 服務進行接口。

此外，在確定用戶身份後，通過將 user_id 傳遞到下游層（如代理插件層）來限制數據平面。雖然這個 user_id 參數可以在代理插件控制器 Lambda 函數中用於自定義授權邏輯，但其主要目的是為第三方插件啟用細粒度的訪問控制。應用擁有者的責任是在行動組 Lambda 函數中實施自定義授權邏輯，將 user_id 參數與預定義規則結合使用，以對第三方 API 和插件應用適當的訪問級別。這種方法為非確定性 LLM 周圍包裝了確定性訪問控制，並使得對哪些用戶可以訪問和執行特定第三方插件的細粒度訪問控制成為可能。

將基於 user_id 的數據授權與行動組 Lambda 函數的 IAM 角色最小權限結合，通常會最小化 LLM08:2025 向量和嵌入弱點及 LLM06:2025 過度代理的風險。

RAG 數據存儲層

RAG 數據存儲負責安全地檢索來自各種第一方和第三方數據源的最新、準確且受用戶訪問控制的知識。默認情況下，Amazon Bedrock 使用 AWS 管理的密鑰加密所有知識庫相關數據。或者，你可以選擇使用客戶管理的密鑰。在為你的知識庫設置數據攝取作業時，你還可以使用自定義 AWS 密鑰管理服務 (AWS KMS) 密鑰加密該作業。

如果你決定在 Amazon OpenSearch 服務中使用向量存儲作為你的知識庫，Amazon Bedrock 可以將你選擇的 KMS 密鑰傳遞給它進行加密。此外，你可以使用 KMS 密鑰加密生成回應的會話，這些會話是通過查詢知識庫生成的。為了促進安全通信，Amazon Bedrock 知識庫在與第三方向量存儲互動時使用 TLS 加密，前提是該服務支持並允許傳輸中的 TLS 加密。

在用戶訪問控制方面，Amazon Bedrock 知識庫使用過濾器來管理權限。你可以利用元數據和過濾功能在知識庫上構建分段訪問解決方案。在運行時，你的應用必須對用戶進行身份驗證和授權，並在查詢中包含此用戶信息，以保持準確的訪問控制。為了保持訪問控制的更新，你應定期重新同步數據，以反映權限的任何變更。此外，組可以作為可過濾的屬性存儲，進一步細化訪問控制。

這種方法有助於減輕 LLM02:2025 敏感信息披露和 LLM08:2025 向量和嵌入弱點的風險，確保只有授權用戶可以訪問相關數據。

總結

在這篇文章中，我們討論了如何從安全共享責任的角度使用 AWS 生成式人工智慧安全範疇矩陣來分類你的生成式人工智慧應用。我們回顧了一個常見的生成式人工智慧助手應用架構，並使用 OWASP 前十名框架評估其安全性，展示了如何使用 AWS 服務控制和服務來加強生成式人工智慧助手應用的架構，並應用 OWASP 前十名的威脅緩解措施。了解更多關於使用 AWS Bedrock 構建生成式人工智慧應用的資訊。