自 2022 年 ChatGPT 發布以來，大語言模型（LLM）作為人工智慧領域的關鍵技術趨勢，驅動各行各業加速推進系統智能化升級。企業積極嘗試將 LLM 整合至自身系統，以期提升效率並優化用戶體驗。然而，LLM 的引入不僅帶來技術革新，也伴隨顯著的安全風險。由於缺乏系統性的安全指導與最佳實踐，其潛在威脅尚未得到充分重視。為幫助各行各業安全應用 LLM 技術，雲安全聯盟大中華區發布《基於大語言模型（LLM）的系統安全：關鍵授權實踐》，依照常見的整合 LLM 的系統設計模式，提出了一系列最佳實踐，並針對每種模式提出了相應的建議、注意事項和常見誤區。
本報告從授權的角度，探討 LLM 帶來的安全風險和應對方案。報告指出，LLM 有兩個特點：非確定性和缺乏獨立控制和數據平面。這兩個特點使得系統在整合 LLM 時面臨授權和安全控制的挑戰。
LLM 的非確定性體現在 LLM 的輸出是不確定的，這意味著，即使提供相同的輸入，整合了 LLM 的系統也有可能得到不同的輸出。這種不確定性意味著我們無法依賴 LLM 的輸出來做授權決策的依據。
缺乏獨立控制和數據平面體現在模型中，LLM 並沒有 “代碼” 和 “數據” 的區分，因此，我們無法對模型權重中包含的信息提供細粒度的訪問控制。報告提出了幾點原則性的設定，作為後續探討的基礎：
- LLM 產生的結果並不可靠
- 授權策略的決策點和執行點應始終位於 LLM 之外
- LLM 永遠不應負責執行認證檢查
- 針對 LLM 的攻擊（如越獄和提示注入）始終成立
- 應執行最小權限原則和按需訪問
基於這些原則，報告從基於 LLM 的系統的組成部分入手，首先展開說明了 LLM 帶來的相關挑戰及注意事項，接下來，報告便從以下常見的基於 LLM 系統的架構設計模式出發，討論了相關的最佳實踐、注意事項、常見誤區以及錯誤示例。
本報告旨在幫助工程師、架構師以及隱私和安全專業人士理解使用 LLM 構建系統時，與授權相關的獨特風險和挑戰。它強調了由於 LLM 的特性而需要做出的特殊考慮，並探討了這些系統可能面臨的挑戰和常見誤區。
基於 LLM 的系統的組成部分#
如下圖所示，通常情況下，基於 LLM 的系統包括了編排器、向量數據庫、LLM 緩存、驗證器以及代表了系統內現存的各類服務的 “內部服務” 模塊。這些模塊承擔不同的職責，也具有不同的安全風險。
編排器負責協調 LLM 的輸入輸出、管理其與其他服務的互動。它具有確定性，能清晰劃分訪問邊界，為授權決策提供依據。向量數據庫作為 LLM 的 “外腦”，可補充模型不具備的信息，也可用關係數據庫或外部 API 替代。由於外腦信息敏感，需在檢索前進行授權判斷。LLM 緩存雖能加速查詢、節省成本，但可能引發信息洩露或被用於緩存投毒攻擊。驗證器可驗證、篩查甚至重寫 LLM 數據流，是縱深防禦體系的一部分，但不能替代嚴格的輸入輸出控制。
從基於 LLM 的系統的組成部分，我們可以直觀地看到將 LLM 整合到系統中所帶來獨特的安全和控制問題。
挑戰和注意事項#
因為 LLM 本質上的概率特性（不確定性），惡意用戶的攻擊方式也變得多樣化。攻擊者可以利用 LLM 的能力繞過傳統的訪問控制訪問敏感信息；或者引導 LLM 輸出危害性或高風險的操作。這些都可能導致嚴重後果，如完整性受損、數據洩露、違反合規要求等。
提示注入攻擊是 LLM 面臨的一大挑戰。攻擊者通過在用戶提示中加入如 “忽略先前指令” 等內容以直接繞過系統限制，或把惡意指令注入外部數據源，再經 RAG 等機制輸入 LLM。由於 LLM 無法區分 “指令” 與 “數據”，這類攻擊風險劇增。儘管 LLM API 提供 “系統”、“用戶” 等角色以助力開發，但這些角色並無實際安全意義，均作為提示詞交由 LLM 處理。因此，授權控制必須置於 LLM 外部，同時要驗證和管控 LLM 的所有輸出。
通常建議避免使用含敏感信息的數據集進行模型訓練或微調。如有必要，可通過 RAG 獲取敏感信息，並通過適當的訪問控制確保僅有授權用戶能訪問。在必須使用敏感數據訓練的場景下，應嚴格限制與模型互動的用戶權限以降低風險。
鑑於 LLM 的特性，它不適合自主做出關鍵決策。從授權角度看，我們不能依賴 LLM 處理過的身份信息或訪問控制決策。設計基於 LLM 的系統時，應始終遵循前文提出的五項原則，以確保系統的安全性。
使用 LLM 的系統的常見架構設計模式#
使用向量數據庫的 RAG 訪問#
當我們談起 RAG 的時候，多數情況下，是使用向量數據庫的 RAG 訪問。用戶輸入的查詢信息，被首先送往向量數據庫，查找上下文相似的結果，從而實現語義搜索功能。然後相關的上下文和用戶的原始查詢被一起送給 LLM，LLM 再根據這些信息生成回應（如下圖所示）。由於作為 RAG 的數據多數是實時甚至敏感的數據，我們並不會希望所有用戶都能通過 RAG 的能力訪問這些數據。因此，授權判斷是必須的。
最佳實踐是通過在相關向量存儲或數據庫中引入文檔級安全，並在檢索點強制執行訪問控制來實現最小特權原則。
- 文檔會標記元數據，用於標識哪些角色或屬性有權訪問它們。
- 元數據與文檔及其相關嵌入內容一起存儲。
- 根據元數據，查詢可以根據用戶的授權級別來過濾文檔。
- 當編排器代表用戶發起搜索時，首先需要驗證用戶的角色。
- 在用戶角色中的任何相關查詢過濾器，以定制搜索結果，僅包含用戶有權查看的記錄。
然而，並非所有向量數據庫都具備行級或文檔級的 ACL，而且從數據源中提取的原始 ACL 可能會隨時間在源與向量數據庫之間產生偏差。這兩點容易出現的誤區。
使用關係數據庫的 RAG 訪問#
當回答查詢需要結構化數據時，RAG 可以通過關係數據庫來獲取數據。編排器可以通過與任何其他系統組件在與數據庫互動之前驗證授權屬性的相同方式執行帶有權限檢查的查詢。這是一個多階段流程：第一個提示的目的是生成適當的 SQL 查詢；第二個提示則是要回答的初始問題與從數據庫檢索得到的上下文。在這種場景下，作為最佳實踐，特別需要注意的是：
- 使用參數化查詢，避免 SQL 注入攻擊的發生。
- LLM 只生成 SQL 語句的部分內容。
- 應用最小權限，限定查詢格式，限制查詢速率。
- 完整的日誌記錄和異常警報。
相應的，在沒有任何驗證以確保正確性的情況下運行 SQL 查詢，不使用參數化查詢，或者缺乏適當的過濾機制都是常見的錯誤示例。
使用 API 調用外部系統的 RAG#
除了數據庫，LLM 可以與一系列 API 集成，以執行操作和 / 或從數據存儲中檢索數據。與 API 互動時，授權自然至關重要：一方面，調用 API 的用戶必須經過身份驗證和鑑權；另一方面，API 的輸出結果必須經過過濾，僅包含最終用戶有權查看的數據。報告推薦了以下要點，作為最佳實踐：
- 身份信息應該從編排組件直接傳遞給 API，避免通過 LLM 中轉。
- 授權操作應該盡可能接近數據訪問的地方。
- 使用安全 API 網關進行清理和驗證，確保詳細記錄所有 API 調用。
- 基於訪問控制模型（如 RBAC/ABAC），實施最小特權原則。
相應的，這種情況下，最常見的誤區便是依靠 LLM 將身份信息傳達給後端 API。由於 LLM 的不確定性，無法保證後端 API 收到的身份信息與真實的用戶相同。這可能導致未經授權的數據訪問和操作，從而引發數據洩露。依賴可能導致間接提示注入攻擊的外部數據源，以及未經驗證的 API 調用，同樣是常見的錯誤示例。
LLM 系統編寫和執行代碼#
AI 編寫連貫且可工作代碼的能力不斷增強，這成為基於 LLM 的系統的新的用例。人們期望在工作過程中，LLM 能在運行時編寫代碼，然後動態執行以解決特定問題。然而，與之相伴的安全風險也無法忽視。
由於 LLM 並不會自主地對代碼進行安全審計，而且即使安全審計也無法完全排除代碼可能存在的問題或漏洞。因此，報告認為，許多常見的安全實踐可以應用於這一場景，包括但不限於對高風險過程進行沙箱隔離、遵循最小特權原則以及生成和使用審計日誌。此外，報告特別提出了通過使用自定義解釋器在語言本身中限制授權使用的方法。包括了：
- 通過自定義受限解釋器限制語言的執行能力
- 防止利用
- 惡意代碼檢測
- 有限的訪問和權限
- 避免授予寫權限或修改數據的訪問權限
- 人工參與
基於 LLM 的自主智能體#
AI 智能體借助 LLM 理解環境並執行任務，將用戶請求拆解成子任務，選擇工具並調用系統資源完成任務。其關鍵組件有記憶系統（含短期和長期記憶）、知識庫、工具集成 / 插件，以及任務分解和規劃能力。
為確保安全，需對編排器進行授權檢查，對知識庫實施訪問控制，並對插件進行沙箱隔離。目前，基於 LLM 的自主智能體系統及訪問控制仍在發展中，需深入理解交互點和信任邊界以設計合理的訪問控制措施。
寫在最後#
LLM 的爆發式發展，讓基於 LLM 的系統的安全性問題變得嚴峻。哪怕整個系統只有一小部分功能使用了 LLM，它依然能帶來意想不到的安全風險。報告中或多或少的提到，LLM 帶來的安全風險很大程度是由於其自身特性的導致的，而且，這些問題目前依然無解。我們當然不能因噎廢食，放棄 LLM 這個強大的工具。因此，做好相應的安全規劃和防護是每一位從業者都要時刻謹記的。
報告中有一句話：“LLM 的表現就如同一個非常聰明但過於自信、容易被愚弄，沒有街頭智慧的青少年一樣”。這句話非常形象，也從另一個角度詮釋如何應對 LLM 帶來的安全風險的方法論。
通俗地說，應對 LLM 為系統帶來的風險的關鍵思想是將其視作 “不可信的人”—— 它有能力，但不可靠。我們在日常工作和生活中，應對這樣的夥伴，建立好與之相處的邊界幾乎是下意識的，而所有進出該邊界的信息，我們都會再三核實 —— 這和我們應對 LLM 的方式如出一轍：審視其能力，確定其邊界，明確其權限，最後通過控制策略，實現對其的應用與監管，這就是我們為 LLM 為系統帶來的安全風險的基本步驟。