實施有效的資料授權機制以保護您在生成式人工智慧應用中使用的資料

資料安全和資料授權，與使用者授權不同，是企業工作負載架構中的關鍵組成部分。隨著人工智慧 (AI) 技術的發展，其重要性不斷提升，生成式 AI 引入了使用內部資料源的新機會，透過大型語言模型 (LLMs) 和多模態基礎模型 (FMs) 增強模型輸出。在這篇部落格文章中，我們詳細探討生成式 AI 工作負載的資料安全和資料授權。我們將分析使用敏感資料作為 FMs 微調、檢索增強生成 (RAG)、AI 代理和工具的風險。敏感資料可能包括第一方資料（客戶、病患、供應商、員工）、智慧財產 (IP)、個人識別資訊 (PII) 或個人健康資訊 (PHI)。我們也會討論如何將資料授權機制實施為生成式 AI 應用程式和 Amazon Bedrock Agents 的一部分。

生成式 AI 的資料風險

大多數傳統 AI 解決方案（機器學習、深度學習）使用企業內部的標記資料來建立模型。生成式 AI 引入了在企業內使用現有資料的新方式，並結合私有和公共資料以及來自資料庫、物件儲存、資料倉庫和其他資料來源的半結構化或非結構化資料。

例如，一家軟體公司可以使用生成式 AI 透過自然語言簡化日誌的理解。為了實施這個系統，公司建立了一個 RAG 管道來分析日誌，並允許事件回應者詢問有關資料的問題。公司還建立了另一個系統，使用基於代理的生成式 AI 應用程式將自然語言查詢轉換為 API 呼叫，以搜尋來自客戶的警報，聚合多個資料集，並幫助分析師識別感興趣的日誌條目。系統設計者如何確保只有授權的主體（如人類使用者或應用程式）可以訪問資料？通常，當使用者訪問資料服務時，各種授權機制會驗證使用者是否有權訪問該資料。然而，當您使用 LLMs 和生成式 AI 時，您應該考慮與資料訪問相關的問題。讓我們來看看三個不同的重點領域。

輸出穩定性

由於非確定性，LLM 的輸出隨時間不會是可預測和可重複的，這取決於多種因素。您是否從一個模型版本更改為另一個？您是否將溫度設置接近 1 以偏好更具創造性的輸出？您是否在當前會話中詢問了其他問題，這可能會影響 LLM 的回應？這些和其他實施考量都很重要，並導致模型的輸出從一個請求到下一個請求發生變化。與傳統機器學習不同，生成 AI 的輸出可以是生成的文本、圖像、影片、音頻或其他不遵循特定架構的內容，這可能對於希望使用敏感資料作為 LLM 訓練和微調的一部分的組織構成挑戰，或在發送給 LLM 的提示中添加額外上下文（RAG、工具）時，當威脅行為者使用提示注入等技術獲取敏感資料時。因此，制定一個明確的授權流程來管理資料在生成式 AI 應用程式和 LLM 本身中的訪問和使用是很重要的。

讓我們來看一個例子。圖 1 顯示了當使用者提出查詢時使用工具或功能的示例流程。

假設在“查詢文本模型”步驟中，LLM 的輸出請求生成式 AI 應用程式提供來自工具或功能調用的額外資料。生成式 AI 應用程式使用來自 LLM 的資訊在“使用模型輸入參數調用工具”步驟中檢索所需的額外資料。如果您沒有實施適當的資料驗證，而是使用 LLM 的輸出來做出工具或功能的授權決定，這可能會允許威脅行為者或未授權的使用者對其他系統造成更改或獲取未授權的資料。從工具或功能返回的資料在“使用工具資料增強使用者查詢”步驟中作為提示的一部分傳遞。

安全行業已經看到威脅行為者嘗試使用高級提示注入技術來繞過敏感資料檢測（如這篇 arXiv 論文所述）。即使實施了敏感資料檢測，威脅行為者也可能要求 LLM 提供敏感資料，但要求以另一種語言、字母反轉或使用其他機制回應，這些機制並非所有敏感資料檢測工具都能捕捉到。

這兩個示例場景都源於 LLMs 在完成任務時使用的資料不可預測，並且即使實施了敏感資料保護，也可能在推理中包含敏感資料。沒有適當的資料安全和資料授權機制，組織可能會增加未授權訪問用於 LLM 實施的敏感資訊的風險。

授權

與基於角色或身份的應用程式或其他資料來源訪問不同，一旦資料通過訓練或微調成為 LLM 的一部分，或作為提示發送給 LLM，主體（人類使用者或應用程式）將可以訪問 LLM 或提示中存在的資料。回到我們之前的日誌分析示例，如果使用內部資料集訓練用於警報關聯的 LLM，LLM 如何知道主體（如與生成式 AI 應用程式交互的使用者）是否被允許訪問資料集中的特定資料？如果您使用 RAG 為 LLM 請求提供額外上下文，LLM 如何知道提示中包含的 RAG 資料是否被授權在回應中提供給主體？

高級提示和防護措施旨在過濾和模式匹配，但它們不是授權機制。LLMs 不會做出授權決定，決定哪些主體將在推理中訪問資料，這意味著要麼不做出資料授權決定，要麼必須由其他系統做出。沒有這些能力作為推理的一部分，授權決定需要存在於生成式 AI 應用程式的其他部分。例如，圖 2 顯示了實施 RAG 時的資料流，以及作為流程一部分的資料授權。在 RAG 實施中，授權決定是在生成式 AI 應用程式本身的層級做出的，而不是 LLM。應用程式將額外的身份控制傳遞給向量資料庫，以過濾 API 呼叫中來自資料庫的結果。這樣做時，應用程式提供了使用者允許用作 LLM 提示的一部分的鍵/值資訊，並通過安全的側通道將鍵/值資訊與使用者提示分開：元資料過濾。

圖 2：在請求時授權資料訪問向量資料庫，而不是離開 LLM 的資料

混淆代理問題

與任何工作負載一樣，資料訪問應僅由授權的主體授予和授予。例如，當主體請求訪問工作負載或資料來源時，主體與持有資料的資源之間需要建立信任關係。這種信任關係驗證主體是否有權訪問資料。組織需要謹慎實施生成式 AI 應用程式，以免其實施遇到混淆代理問題。混淆代理問題發生在一個沒有權限執行操作或獲取資料的實體通過更高特權的實體獲得訪問權限時（有關更多資訊，請參閱混淆代理問題）。

這個問題如何影響生成式 AI 應用程式？回到我們之前的示例，假設一個主體不被允許訪問內部資料來源，並被資料庫或 Amazon 簡單儲存服務 (Amazon S3) 存儲桶阻止。然而，如果您授權同一主體使用生成式 AI 應用程式，生成式 AI 應用程式可能會允許主體訪問敏感資料，因為生成式 AI 應用程式被授權在實施中訪問資料。此場景顯示在圖 3 中。為了幫助避免此問題，確保在將資料提供給 LLM 作為應用程式的一部分時使用正確的授權構造是很重要的。

圖 3：拒絕直接訪問 S3 存儲桶的使用者。但允許訪問 LLM 的使用者訪問使用相同 S3 存儲桶資料的 RAG。

隨著對生成式 AI 使用的法律和監管要求的增加，對於採用生成式 AI 的人來說，了解這三個領域是很重要的。了解這些風險是構建安全生成式 AI 應用程式的第一步，這些應用程式使用公共和私有資料來源。

您需要做什麼

作為希望保持敏感資料安全的生成式 AI 採用者，這對您意味著什麼？您是否應該停止使用第一方資料、智慧財產 (IP) 和敏感資訊作為生成式 AI 應用程式的一部分？不——但您應該了解風險以及如何相應地減輕風險。您選擇在模型調整或 RAG 資料庫填充中使用哪些資料（或基於預期變更頻率等因素的兩者結合）取決於生成式 AI 應用程式的業務需求。新型生成式 AI 應用程式的價值很大一部分來自於使用公共和私有資料來源為客戶提供額外價值。

這意味著您需要在架構中實施適當的資料安全和授權機制，並了解在資料流的每個步驟中放置這些控制的位置。您的 AI 實施應遵循主體授權的基本規則：只有授權的主體允許訪問的資料應作為推理的一部分傳遞，或應作為 LLM 訓練和微調的資料集的一部分。如果敏感資料作為推理（RAG）的一部分傳遞，輸出應限於會話中的主體，生成式 AI 應用程式應使用安全的側通道傳遞有關主體的額外資訊。相反，如果敏感資料是 LLM 中訓練或微調資料的一部分，任何可以調用模型的人都可以訪問敏感資料，生成式 AI 應用程式應限制授權使用者的調用。

然而，在我們討論如何使用生成式 AI 應用程式實施適當的授權機制之前，我們首先需要討論另一個主題：資料治理。隨著生成式 AI 應用程式中使用結構化和非結構化資料，您必須了解在實施選擇的資料授權機制之前，資料來源中存在的資料。例如，如果您在生成式 AI 應用程式中實施 RAG 並使用來自日誌、文件和其他非結構化資料的內部資料，您是否知道資料來源中存在的資料以及每個主體應該對該資料擁有的訪問權限？如果不知道，請在將資料用作生成式 AI 應用程式的一部分之前，專注於回答這些問題。您無法適當授權訪問尚未分類的資料。組織需要實施正確的資料策劃流程，以獲取、標記、清理、處理和與將成為其生成式 AI 工作負載一部分的資料進行交互。為了幫助您完成這項任務，AWS 提供了一些資源和建議，作為我們的 AWS 雲採用框架中的人工智慧、機器學習和生成式 AI 白皮書的一部分。

現在，讓我們來看看 Amazon Bedrock Agents 的資料授權，並通過一個示例進行演示。

使用 Amazon Bedrock Agents 實施強大的授權

當生成式 AI 系統必須與實時資料或上下文專有和敏感資料交互時，或者當您希望生成式 AI 系統能夠代表最終使用者採取行動時，您可能會考慮使用基於代理的架構模式。基於代理的架構為 LLM 提供了決定採取何種行動、請求何種資料或進行何種 API 呼叫的代理權。然而，重要的是要為 LLM 的代理權定義一個邊界，以免為 LLM 提供過多的代理權（請參閱 OWASP LLM08），從而影響系統安全或洩露敏感資訊給未授權的使用者。特別是在生成式 AI 工作負載通過代理與 API 交互時，仔細考慮提供給 LLM 的代理權限量是很重要的，因為這些 API 可能會根據 LLM 生成的參數採取任意行動。

當您決定為 LLM 提供多少代理權時，可以使用一個簡單的模型，即將 LLM 的輸入限制為最終使用者被授權訪問的資料。對於代理控制對敏感業務資訊訪問的基於代理的架構，為代理提供最終使用者的可信身份來源，以便代理在檢索資料之前進行授權檢查。代理應過濾掉最終使用者未被授權訪問的資料欄位，僅將最終使用者被授權訪問的資料子集提供回 LLM 作為回答最終使用者提示的上下文。在此方法中，傳統資料安全控制與最終使用者身份的可信身份來源結合使用，以過濾 LLM 可用的資料，以便嘗試通過提示注入或越獄技術覆蓋系統提示不會導致 LLM 獲得最終使用者未被授權訪問的資料。

代理可以代表使用者採取行動的基於代理的架構可能會帶來額外的挑戰。一個潛在風險的典型例子是允許 AI 工作負載訪問將資料發送給第三方的代理；例如，發送電子郵件或將結果發布到 Web 服務。如果 LLM 有權決定該電子郵件或 Web 地址的目標，或者第三方有能力將資料插入用於形成提示或指令的資源中，那麼 LLM 可能會被愚弄將敏感資料發送給未授權的第三方。這類安全問題並不新鮮；這是混淆代理問題的另一個例子。儘管風險並不新鮮，但了解風險如何在生成式 AI 工作負載中顯現以及可以採取哪些緩解措施來降低風險是很重要的。

無論您選擇的基於代理的架構的細節如何，建議的做法是以帶外方式安全地傳達執行查詢的最終使用者的身份給後端代理 API。LLM 可能會控制從使用者查詢生成的代理 API 的查詢參數，但 LLM 不得控制影響後端代理 API 授權決定的上下文。通常，“上下文”意味著最終使用者的身份，但可能包括其他上下文，例如設備狀態、加密令牌或做出授權決定所需的其他上下文。

Amazon Bedrock Agents 提供了一種機制，將這種敏感身份上下文資料通過安全側通道傳遞到後端代理 AWS Lambda 群組：會話屬性。會話屬性是一組 JSON 鍵/值對，在 InvokeAgent API 請求時與使用者查詢一起提交。會話屬性不會與 LLM 共享。如果在 InvokeAgent API 請求的運行時過程中，代理的編排引擎預測需要調用一個操作，LLM 將根據代理構建時配置中給定的 OpenAPI 規範生成適當的 API 參數。由 LLM 生成的 API 參數不應包含用作授權決定輸入的資料；此類資料應包含在會話屬性中。圖 4 顯示了資料流的圖示以及會話屬性如何用作代理架構的一部分。

圖 4：在 API 請求中添加會話屬性並傳遞給 Lambda 工具的示例 InvokeAgent 呼叫

會話屬性可以包含多種類型的資料，從簡單的使用者 ID 或群組名稱到用於零信任機制或信任身份傳播到後端系統的 JSON Web 令牌 (JWT) 令牌。如圖 4 所示，當您在 InvokeAgent API 請求中添加會話屬性時，代理通過安全側通道將會話屬性用作“調用操作”步驟的一部分的工具和功能。這樣做時，它將身份上下文提供給工具和功能，而不在提示本身中。

讓我們來看一個簡化的生成式 AI 應用程式示例，該應用程式允許醫生和接待員提交有關病患的自然語言查詢。例如，接待員可以要求系統獲取病患的電話號碼，以便他們聯繫病患重新安排約會。醫生可以要求系統總結過去六個月的就診情況，以便為今天的就診做準備。這樣的系統必須包括身份驗證和授權，以保護病患資料不被意外洩露給未授權的各方。在我們的示例應用程式中，使用者交互的 Web 前端具有代表使用者身份的 JWT，可供應用程式使用。

在我們的簡化架構中，我們有一個 OpenAPI 規範，提供 LLM 訪問查詢病患資料庫並檢索病患的 PHI 和 PII 資料。我們的授權規則規定接待員只能查看病患的生物和 PII 資料，但醫生可以查看 PII 資料和 PHI 資料。這些授權規則被編碼到後端 Action Group Lambda 函數中。但 Action Group Lambda 函數不是直接從應用程式調用的，而是作為 Amazon Bedrock Agents 工作流程的一部分調用的。例如，如果當前登錄的使用者是一名名叫 John Doe 的接待員，並嘗試進行提示注入以檢索 ID 為 1234 的病患的完整醫療詳細資訊，則前端 Web 應用程式可以生成以下 InvokeAgent API 請求。

Amazon Bedrock Agents 運行時將評估使用者的請求，確定需要調用 API 以檢索病患 1234 的健康記錄，並調用 Amazon Bedrock Agents 中配置的 Action Group 定義的 Lambda 函數。該 Lambda 函數將接收由 LLM 根據使用者請求生成的 API 參數以及從原始 InvokeAgent API 傳遞的會話屬性：

請注意，JSON 輸入事件中 sessionAttributes 鍵的內容是從原始 InvokeAgent 調用中逐字複製的。Lambda 函數現在使用會話屬性中的 JWT 和最終使用者角色身份資訊來授權使用者對請求資料的訪問。在這裡，即使使用者可以進行提示注入並“說服” LLM 他或她是醫生而不是接待員，Lambda 函數仍然可以訪問最終使用者的真實身份並相應地過濾資料。在這種情況下，使用者使用提示注入或越獄技術獲取未授權查看的資料不會影響工具對使用者的授權，因為授權檢查是由 Lambda 函數使用會話屬性中的可信身份進行的。

在這個示例中，我們的簡化架構通過執行以下步驟減輕了與敏感資訊洩露相關的安全風險：

移除了 LLM 做出授權決定的代理權，將資料過濾任務委託給後端 Lambda 函數和 API
使用安全側通道（在我們的情況下，Amazon Bedrock Agents 會話屬性）將最終使用者的身份資訊傳達給返回敏感資料的 API
使用後端 Lambda 函數中的確定性授權機制，使用步驟 2 中的可信身份
根據步驟 3 中的授權決定在 Lambda 函數中過濾資料，然後將結果返回給 LLM 進行處理

遵循這些步驟並不能防止提示注入或越獄嘗試，但可以幫助您降低敏感資訊洩露事件的可能性。最好在這裡描述的安全機制之上分層添加其他控制和緩解措施，例如 Amazon Bedrock Guardrails。

結論

通過實施適當的資料安全和資料授權，您可以將敏感資料用作生成式 AI 應用程式的一部分。涉及生成式 AI 應用程式的新用例的價值很大一部分來自於使用公共和私有資料來源來幫助客戶。為了正確實施這些應用程式，我們調查了生成式 AI 工作負載的資料安全和資料授權的關鍵風險和緩解措施。我們分析了使用第一方資料（來自客戶、病患、供應商、員工）、智慧財產 (IP) 和敏感資料的生成式 AI 工作負載的風險。然後，我們描述了如何對作為生成式 AI 應用程式一部分使用的資料實施資料授權機制，以及如何為 Amazon Bedrock Agents 實施適當的安全政策和授權政策。欲了解更多有關生成式 AI 安全性的資訊，請查看 AWS 安全部落格頻道和 AWS 部落格文章中涵蓋的生成式 AI。

如果您對本文有任何意見，請在下方的評論區提交評論。

Riggs Goodman III

Riggs 是 AWS 的首席合作夥伴解決方案架構師。他目前專注於 AI 安全和資料安全，為客戶和合作夥伴提供技術指導、架構模式和領導力，以在 AWS 上構建 AI 工作負載。在內部，Riggs 專注於推動 AWS 服務團隊的整體技術策略和創新，以解決客戶和合作夥伴的挑戰。

Jason Garman

Jason 是 AWS 的首席安全專家解決方案架構師，常駐於北弗吉尼亞。Jason 幫助全球最大的組織解決關鍵的安全挑戰。在加入 AWS 之前，Jason 在網路安全行業擔任過多種角色，包括初創公司、政府承包商和私營部門公司。他是一位出版作家，擁有網路安全技術專利，並喜歡與家人一起旅行。