採取有效授權管理機制　強化敏感資料安全(上)

有別於一般的用戶授權機制，資料安全與資料授權已成為企業業務架構中不可或缺的關鍵要素，且隨著AI技術快速發展，其重要性正不斷提升。如今，生成式AI能結合內部資料與大型語言模型（LLM）和多模態基礎模型（FM）來強化模型輸出，企業更應審慎了解生成式AI在工作負載中產生的資料安全與授權需求，特別是使用基礎模型微調、檢索增強生成（RAG）、AI代理（AI Agents）與生成式AI工具的過程中，涉及敏感資料時的潛在風險。這些敏感資料包含第一方資料（如客戶、病患、供應商、員工）、智慧財產權（IP）、個人身分識別資訊（PII）以及個人健康資訊（PHI）等等。

生成式AI的資料風險

大部分傳統的AI解決方案（如機器學習與深度學習）依賴企業內部的標記資料來建構模型。相較之下，生成式AI不只運用這些既有的標記資料，更進一步結合其他私人與公開來源的資料，或來自資料庫、物件儲存、資料倉儲等資料來源的半結構化與非結構化資料。

以軟體公司為例，使用生成式AI能透過自然語言簡化理解系統日誌的流程。為了實現這個目標，公司建立RAG管道來分析日誌，並讓事件應變人員能針對資料提出問題。同時，組織建立另一套應用代理生成式AI的系統，將自然語言查詢轉換為API調用，進而搜尋來自客戶的警報訊息、整合不同資料來源的內容，並協助分析人員快速鎖定目標的日誌檔案。

然而，負責設計系統的工程師必須確保只有擁有授權的使用者（無論是人類用戶或應用程式）能夠存取資料。一般來說，使用者進入資料服務時，都會被各種授權機制驗證存取權限。然而，在使用LLM與生成式AI時，有三個需要特別注意的資料授權議題，分別是輸出穩定性（Output Stability）、授權（Authorization）以及混淆代理人問題（Confused Deputy Problem）。

輸出穩定性

由於LLM具有不確定性（Non-determinism），輸出結果難以保持可預測性與一致性，並會受到多種因素影響。例如，切換模型版本、將隨機數值設定為接近1以追求更具創意的輸出、在對話中提出額外的問題來影響LLM的回應，這些因素都會導致模型在每次請求時產生不同的輸出結果。傳統的機器學習輸出格式通常遵循特定的模式，但生成式AI的輸出會因為不同的設計而生成文字、圖片、影片、聲音，或其他沒有特定模式的內容。

對於企業而言，若在訓練、微調模型過程中導入敏感資料，或是在提示詞中加入額外的上下文（例如RAG或其他工具），資料外洩的風險也隨之提高。特別是如果攻擊者利用提示注入（Prompt Injection）等手法，企圖繞過防護機制來存取敏感資料時，模型回應的不確定性將使風險更加複雜與難以預測。因此，企業在應用生成式AI時，必須建立一套明確的資料授權流程，以有效管控生成式AI和LLM中資料的存取與使用方式。

舉例來說，圖1為使用者透過LLM搭配工具或函數進行查詢時的範例流程。

在「查詢文本模型」的步驟中，如果LLM輸出時要求生成式AI應用程式透過工具或函數取得額外資料，生成式AI應用程式便會在「模型輸入參數調用工具」的步驟中，使用來自LLM的資訊來獲得所需的額外資料。如果不實施適當的資料驗證機制，直接以LLM的輸出結果作為工具或函數的授權依據，將可能讓攻擊者或未經授權的使用者更改其他系統，或存取未獲授權的資料。從工具或函數回傳的資料，則會作為額外的資訊，在「以工具資料強化使用者查詢」的步驟中被納入提示詞。

資安產業已經觀察到攻擊者試圖使用進階的提示注入技術，繞過敏感資料偵測機制。即使企業導入敏感資料偵測功能，攻擊者仍可能透過LLM取得敏感資料，例如要求以其他語言回應、反轉字母順序，或採用其他變形方式規避敏感資料偵測工具的辨識機制。

這些情境皆反映難以預測LLM為了完成任務會使用哪些資料，即使已經導入敏感資料保護機制，LLM在進行推論時仍可能透過RAG或其他工具，將敏感資料加進輸出結果。因此，若沒有建立完善的資料安全與授權機制，組織在導入LLM時，可能提高敏感資料未經授權就被存取的風險。

授權

不同於以角色或身分為基礎的存取控管，一旦資料被納入LLM中進行訓練或微調，或作為提示詞的一部分提供給LLM時，使用者（無論是人類使用者或應用程式）就能透過LLM或提示詞接觸到這些資料。回到上述日誌分析的例子，若企業使用內部資料集訓練用於警示關聯（Alert Correlation）的LLM，模型要如何判斷使用者（如透過生成式AI應用程式進行互動的用戶）是否有權限存取資料集的特定內容？在透過RAG為LLM提供額外的上下文資訊時，模型如何判斷提示詞中包含的RAG資料是否被授權提供給該使用者？

進階提示技術（Advanced Prompting）與防護機制（Guardrails）雖然可以用於過濾內容或進行模式比對，但它們並非授權機制。對於推論過程中「哪些使用者可以存取哪些資料」，LLM本身不具備進行授權判斷的能力。由於無法在模型推論過程中實施授權判斷，因此需要將資料授權機制設計在應用生成式AI的其他環節。

舉例來說，圖2展示執行RAG時，資料授權如何成為流程中的一環。在執行RAG時，授權決策並非來自LLM，而是來自生成式AI應用程式的層級。應用程式會在API調用時，將額外的身分識別控制資訊傳送給向量資料庫，進而過濾出符合該使用者授權範圍的輸出結果。同時，應用程式也會將這些資訊（Key/Value）作為提示詞內容提供給LLM，但會透過中繼資料過濾（Metadata Filtering）這種安全的旁通道（Side Channel）與使用者的提示詞內容進行隔離。

混淆代理人問題

如同其他工作負載，只有經過授權的使用者能存取資料，且必須由具備授權資格的使用者授予權限。例如，當某個使用者請求存取某個工作負載或資料來源時，系統必須建立使用者與資料資源之間的信任關係，藉此驗證該使用者是否擁有存取權限。在導入生成式AI應用程式時，組織必須格外留意，避免落入混淆代理人問題。混淆代理人問題指的是一個本身不具備執行某項操作或存取特定資料權限的使用者，卻透過具有較高權限的代理人，間接取得這些資料。

回到前面的例子，假設某位使用者無權存取內部資料，因此被資料庫或物件儲存服務Amazon Simple Storage Service（Amazon S3）的儲存貯體阻擋。然而，如果這名使用者有權使用生成式AI應用程式，而此應用程式有權存取這些敏感資料，該使用者就可能透過應用程式間接存取原本無權接觸的資料。圖3是這種混淆代理人問題的示意圖。為避免這樣的風險，企業在建構生成式AI應用程式時，必須使用正確的資料授權架構，來確保資料先經過授權才提供給LLM。

隨著規範生成式AI的法律和監管要求不斷增加，導入生成式AI的企業與組織應深入理解這三個領域。建構使用公開與私人資料的生成式AI應用程式時，掌握這些風險是確保安全的第一步。

從理解風險到有效因應

對於積極導入生成式AI並希望確保資料安全的企業，這不代表要停止在應用程式中使用第一方資料、智慧財產以及其他敏感資訊，但必須充分理解風險，並採取因應措施加以控管。在進行模型微調或建立RAG資料庫時所選用的資料，應該要基於生成式AI應用程式的業務需求。新型態生成式AI應用程式的優勢，很大一部分便是來自同時運用公開與私人資料，為客戶創造更多的附加價值。

這意味著企業在導入生成式AI時，必須在系統架構中加入適當的資料安全與授權機制，並掌握資料經過的每個階段應該設置什麼樣的控管措施。同時，導入AI時應遵循授權管理的基本原則：只有使用者有權存取的資料，才能納入推論過程，或作為LLM訓練、微調的資料集。若敏感資料是作為推論過程（例如RAG）的一部分傳送給LLM，那麼輸出結果只能提供給互動中有權存取的使用者，且生成式AI應用程式應透過安全的旁通道傳送這些額外資訊。相對地，若敏感資料傳送到LLM的訓練或微調資料集，則任何能夠調用這個模型的使用者，都可能取得這些敏感資料，因此生成式AI應用程式應限制僅有經授權的使用者能調用模型。

然而，談論如何在生成式AI應用程式中實施適當的授權機制之前，必須先探討「資料治理（Data Governance）」這個主題。由於生成式AI應用程式通常會整合結構化與非結構化資料，因此企業在實施資料授權機制前，必須清楚掌握組織擁有什麼樣的資料。舉例來說，若在生成式AI應用程式中導入RAG，並使用內部的日誌、文件以及其他非結構化資料，要先思考是否清楚掌握這些來源中包含哪些資料、每位使用者具備的存取權限。若答案尚不明確，那麼在將這些資料用於生成式AI之前，應該先釐清這些問題，因為無法對尚未分類的資料進行正確的授權控管。因此，組織需要建構完善的資料整理流程，進而對用於生成式AI的資料進行收集、標記、清理、處理與互動等動作。

運用Amazon Bedrock Agents強大的授權機制

當希望生成式AI系統能夠連接即時的資料，或存取情境專用和敏感的資訊，或讓AI能代表使用者執行某些動作時，可以考慮採用基於代理的架構（Agent-based Architecture）。這種架構賦予LLM一定程度的自主性，能判斷應該採取的行動、需要取得的資料、該執行的API調用。然而，前提是必須明確劃清LLM的行動界線，避免過度賦予自主權限，導致LLM對安全造成風險，或將敏感資訊提供給未經授權的使用者。特別是在生成式AI工作負載需要透過代理與API互動時，更需要審慎評估LLM擁有的操作權限，因為這些API可能會根據LLM產出的參數執行各種動作。

在決定賦予LLM多少自主權時，可以採用一個簡單的原則：模型輸入只包含使用者有權存取的資料。以基於代理的架構來說，當代理要存取敏感的業務資訊時，應提供可信任的身分（Trusted Identity），讓代理在獲取資料前，能先進行授權檢查。代理應過濾使用者無權存取的資料欄位，僅將該使用者有權存取的資料子集提供給LLM用於回應提示詞的上下文。

透過這樣的設計，能將傳統的資料安全控管機制，與可信任的身分整合運用，有效篩選能提供給LLM的資料。如此一來，即使遭遇提示詞注入或越獄（Jailbreaking）等攻擊，也能夠避免LLM存取未經授權的資料。

在基於代理的架構中，代理能代表使用者執行操作，因此這也伴隨更多潛在風險與挑戰。一種常見的情況是讓AI工作負載透過代理傳送資料給第三方，例如發送電子郵件，或將結果發布到網路服務，如果LLM擁有決定傳送對象的自主權，或第三方能將資料加入提示詞或指令引用的來源，那麼LLM就可能無意間將敏感資料傳送給未經授權的第三方。這類資安問題其實並不新穎，本質上是混淆代理人問題的另一種形式。雖然這種風險早已存在，但企業必須了解這些風險在生成式AI工作負載中會如何發生，以及可以採取什麼因應機制有效降低風險。

無論採用哪一種基於代理的架構，最佳實踐建議是透過非同步（Out-of-band）且安全的方式，將提出查詢的使用者身分資訊傳送給後端的代理API。雖然LLM能根據使用者查詢產生對應的API查詢參數，但不該讓LLM控制會影響後端代理API授權判斷的上下文。這些上下文通常指的是使用者的身分資訊，但也可能包含其他重要參數，例如裝置狀態、加密憑證（Cryptographic Tokens），或其他影響底層資料存取授權判斷的資訊。

Amazon Bedrock Agents提供一種機制，透過「工作階段屬性（Session Attributes）」這樣安全的旁通道，將敏感的身分識別上下文資料傳送至後端的AWS Lambda代理群組。工作階段屬性是一組JSON格式的Key/Value，會在使用者提出InvokeAgent API請求時，與查詢內容一併提交，而這些工作階段屬性不會被分享給LLM。

當InvokeAgent API請求執行時，若代理的編排引擎預測需要觸發某項動作，LLM將根據代理在建置時設定的OpenAPI規格，生成對應的API參數。這些由LLM生成的API參數中，不會包含用於授權判斷的輸入資料，授權所需的資訊會透過工作階段屬性傳送。圖4提供這種資料流程的範例，以及工作階段屬性在代理架構中所扮演的角色。

工作階段屬性可以包含多種不同類型的資料，從單純的使用者ID或群組名稱，到應用於零信任（Zero Trust）架構的JSON Web Token（JWT），或要傳送至後端系統的可信任身分。如圖4所示，若在InvokeAgent API請求中加入工作階段屬性時，代理在觸發動作時，會透過安全的旁通道將這些屬性傳送給後端的工具與函數。

如此一來，系統便可以在提示詞之外，將身分識別的上下文安全地傳送給後端工具與函數。

結語

透過導入適當的資料安全與資料授權機制，企業便可以安心地在生成式AI應用程式中使用敏感資料。許多新興的生成式AI應用程式，正是透過整合公開與私人資料，提供客戶更高的附加價值。

為了協助企業妥善建構生成式AI應用程式的基礎架構，AWS深入探討生成式AI工作負載中，與資料安全與資料授權有關的關鍵風險與對應的防護機制。也分析了使用第一方資料（如客戶、病患、供應商、員工）、智慧財產權以及其他敏感資料時，可能面臨的潛在風險。為生成式AI應用程式中使用的資料建置有效的資料授權機制，或是透過Amazon Bedrock Agents這類工具建立合適的安全政策與授權政策，以強化整個架構的存取控管與安全性。

＜本文作者：本文由謝世衡潤譯。謝世衡目前就職於亞馬遜旗下Amazon Web Services（AWS），擔任AWS台灣解決方案架構部的部門負責人。其致力於為客戶提供良好的雲端運算體驗，並曾成功協助多家大型企業導入雲端運算技術。擁有超過十八年的資訊科技產業經驗，曾擔任其他外商公司雲端架構師、行銷科技公司技術顧問，以及新創公司營運長等職務。除了雲端運算、數據分析和機器學習等技術領域，也對零售科技、軟體服務和企業IT營運等領域具有廣泛的知識和經驗。＞