• <xmp id="om0om">
  • <table id="om0om"><noscript id="om0om"></noscript></table>
  • 對話式人工智能

    加強 LLM 應用安全性的最佳實踐

    ?

    大型語言模型 (LLM) 為幾乎所有處理文本的應用程序提供了各種強大的增強功能。同時,它們也引入了新的風險,包括:

    • 提示注入:這可能允許攻擊者控制 LLM 或啟用了 LLM 的應用程序的輸出。
    • 信息泄露:當用于訓練 LLM 或在運行時使用的私有數據可以被攻擊者推理或提取時,信息泄露便會發生。
    • LLM 可靠性:其中一種威脅是,當 LLM 偶爾會產生錯誤信息時。

    本文將詳細介紹這些安全漏洞,并概述設計或評估支持 LLM 的安全應用程序的最佳實踐。

    提示注入

    提示注入是最常見和眾所周知的 LLM 攻擊。它使攻擊者能夠控制 LLM 的輸出,從而可能影響連接到 LLM 的下游查詢和插件的行為。這可能會給未來用戶帶來額外的下游后果或響應。提示注入攻擊可以是直接的,也可以是間接的。

    直接提示注入

    在直接提示注入攻擊的情況下,攻擊者會直接與 LLM 交互,試圖讓 LLM 產生特定的響應。圖 1 顯示了直接提示注入導致遠程代碼執行的示例。有關直接提示注入的更多詳細信息,請參閱 保護 LLM 系統免受提示注入

    A text listing, showing a request to an LLM that says “please solve the following problem” and then lists some python code invoking an os.system call; the result shows a listing of the /etc/password file on the system hosting the LLM, indicating a successful code execution.
    圖 1.直接提示注入攻擊示例,在此示例中,由 LLM 驅動的應用程序用于執行攻擊者代碼

    間接提示注入

    間接提示注入依賴于 LLM 對其在構建系統查詢時使用的外部數據源的訪問權限。攻擊者可以向這些外部數據源插入惡意內容,LLM 會從中提取數據并將其插入到提示中,從而生成攻擊者所期望的響應。有關間接提示注入的更多信息,請參閱 緩解針對 LLM 應用程序的存儲提示注入攻擊

    信任邊界

    通過直接和間接提示注入,一旦攻擊者能夠成功將其輸入引入 LLM 上下文,它們就會對 LLM 的輸出產生重大影響(如果不是直接控制)。由于 LLM 可能使用的外部來源可能很難控制,而且 LLM 用戶本身可能是惡意的,因此必須將任何 LLM 響應視為潛在的不可信任。

    必須在這些響應與處理這些響應的任何響應之間建立信任邊界。下文列出了實現這種分離的一些實際步驟。

    對插件進行參數化:嚴格限制給定插件可以執行的操作數量。例如,用于操作用戶電子郵件的插件可能需要消息 ID 和特定操作(例如“回復”或“轉發”),或者僅接受插入到電子郵件正文中的自由格式文本。

    在使用插件前清理輸入。例如,可能會在插入之前強制從電子郵件正文文本中刪除任何 HTML 元素。或者,在執行電子郵件轉發操作時,可能會要求收件人必須存在于用戶的通訊錄中。

    請求用戶明確的授權 當插件在敏感系統上運行時,任何此類操作都應導致系統立即重新請求用戶明確授權以執行操作,并提供即將執行操作的摘要。

    在依次調用多個插件時,需要獲得用戶的特定授權。這種模式(允許將一個插件的輸出作為另一個插件的輸入)可能迅速導致意外甚至危險的行為。允許用戶檢查和驗證正在調用的插件以及它們將采取的行動,有助于緩解此問題。

    仔細管理插件授權:將任何服務賬戶與 LLM 服務賬戶分開。如果插件的操作需要用戶授權,則應使用 OAuth2 等安全方法將該授權委托給插件。

    信息泄露

    來自支持 LLM 和 LLM 的應用的信息泄露會產生機密性風險。如果 LLM 是根據隱私數據進行訓練或自定義的,熟練的攻擊者可以執行模型反演或訓練數據提取攻擊,以訪問應用開發者認為隱私的數據。

    記錄提示和完成操作可能會意外地跨權限邊界泄露數據,因為這違反了基于服務端角色的靜態數據訪問控制。如果為 LLM 本身提供了信息訪問權限或存儲日志,則通常會誘導其泄露這些數據。

    來自 LLM 本身的泄露

    LLM 本身可以通過多種方式向攻擊者泄露信息。借助提示提取攻擊,攻擊者可以使用提示注入技術誘使 LLM 泄露其提示模板中包含的信息,例如模型說明、模型角色信息,甚至是密碼等機密信息。

    通過模型反演攻擊,攻擊者可以恢復一些用于訓練模型的數據。具體來說,這些記錄可能是隨機恢復的,或者攻擊者可能會有意將搜索結果偏向他們懷疑可能存在的特定記錄。例如,他們可能能夠提取用于訓練 LLM 的個人身份信息 (PII) 示例。想要了解更多詳情,請參閱 有記憶的算法:模型反演攻擊和數據保護法

    最后,訓練數據成員資格推理攻擊使攻擊者能夠確定他們已經知道的特定信息是否可能包含在模型的訓練數據中。例如,他們可能能夠確定他們的 PII 是否用于訓練 LLM.

    幸運的是,這些攻擊的緩解相對簡單。

    為避免提示提取攻擊的風險,請勿共享當前 LLM 用戶無權在系統提示模板中看到的任何信息。這可能包括從檢索增強一代 (RAG) 架構中檢索的信息。假設提示模板中包含的任何內容對有足夠動機的攻擊者可見。特別是,密碼、訪問令牌或 API 密鑰永遠不應放在提示中,或可直接由 LLM 訪問的任何其他位置。嚴格隔離信息是最好的防御方法。

    為了降低從模型中提取敏感訓練數據的風險,最好的方法是不在其上進行訓練。給定足夠的查詢,LLM 不可避免地會最終將敏感數據的某些元素納入其響應中。如果模型必須能夠使用或回答有關敏感信息的問題,RAG 架構可能是一種更安全的方法。

    在這種架構中,LLM 不在敏感文檔上進行訓練,而是獲得了對文檔存儲的訪問權限,該存儲能夠 1) 識別相關敏感文檔并將其返回至 LLM 以協助生成,以及 2) 驗證當前用戶訪問這些文檔的授權。

    雖然這避免了針對敏感數據訓練 LLM 以產生可接受的結果,但它確實在傳遞授權和跟蹤文檔權限方面給應用程序帶來了額外的復雜性。必須小心處理這一點,以防止其他機密性違規事件。

    如果敏感數據已經訓練到模型中,則仍然可以通過速率限制查詢在一定程度上降低風險,而不是向用戶提供有關 LLM 完成概率的詳細信息,以及在應用程序中添加日志記錄和警報。

    如果將查詢預算限制在與啟用 LLM 的應用程序的功能一致的最低限度,并且不向最終用戶提供任何詳細的概率信息,則執行反演和推理攻擊會變得極其困難和耗時。

    AI 紅隊 評估數據泄露可能有助于量化風險、為特定應用程序設置適當的速率限制,以及識別用戶會話中可能表示嘗試提取應提醒的訓練數據的查詢或查詢模式。

    應用程序相關的泄漏

    除了特定于 LLM 的攻擊之外,LLM 的新穎性還可能在構建支持 LLM 的應用程序時導致更基本的錯誤。記錄提示和響應通常會導致服務端信息泄露。或者是未接受適當教育的用戶將專有或敏感信息引入應用程序,或者 LLM 根據敏感信息提供響應,而這些信息在沒有適當訪問控制的情況下記錄。

    在圖 2 中,用戶向 RAG 系統發出請求,該系統請求授權用戶單獨查看文檔,以便完成請求。遺憾的是,請求和響應(包含與特權文檔相關的信息)登錄在具有不同訪問級別的系統中,從而泄露信息。

    A system diagram showing a ‘user device’ and ‘document store’ within a green confidentiality boundary; they both have a bidirectional connection to an ‘inference service’ that is not within a confidentiality boundary (as it is stateless). There is an arrow from the inference service to a ‘logging and monitoring’ service that is within a red confidentiality boundary.
    圖 2.通過日志記錄泄露數據的示例

    如果使用 RAG 來改進 LLM 響應,則必須跟蹤用戶對檢索文檔的授權,以及回復的記錄位置。LLM 應只能訪問當前用戶有權訪問的文檔。填寫的內容(根據設計,這些填寫內容包含這些受訪問控制文檔中包含的部分信息)應以這樣的方式進行記錄,以便未經授權的用戶無法看到敏感文檔的摘要。

    因此,在 LLM 上下文之外執行身份驗證和授權機制極為重要。如果依賴傳輸用戶上下文作為提示的一部分,技能足夠熟練的攻擊者可以使用提示注入來模擬其他用戶。

    最后,應仔細檢查任何插件的行為,以確保它們不會保持任何可能導致跨用戶信息泄露的狀態。例如,如果搜索插件恰好用于緩存查詢,則其返回信息的速度可能會允許攻擊者推斷應用程序查詢的其他用戶最常見的主題。

    LLM 可靠性

    盡管 LLM 代的可靠性和準確性有了顯著提高,但它們仍然會受到一定程度的隨機誤差的影響。如何從一組可能的后續詞中隨機采樣詞增加了 LLM 的“創造力”,同時也增加了產生錯誤結果的可能性。

    這可能會影響用戶(可能會對不準確的信息采取行動)和下游進程、插件或其他計算(可能會失敗或根據不準確的輸入產生額外的不準確結果)(圖 3)。

    An image displaying two turns of interaction with an LLM. The LLM user requested that the LLM tell a joke without the letter ‘e’. The LLM provides a joke that contains two instances of the letter ‘e’ and then asserts that the letter ‘e’ appears zero times in the joke. The user then asks the LLM to count again, and the LLM correctly identifies that the letter ‘e’ appears twice, but incorrectly states that one of those instances is in the word ‘salad’.
    圖 3.LLM 無法完成任務并正確回答相關問題的示例

    在設計下游進程和插件時,必須考慮到 LLM 錯誤的可能性。與提示注入一樣,預先進行良好的安全設計,包括插件參數化、輸入清理、可靠的錯誤處理,以及確保在執行敏感操作時明確請求用戶授權。所有這些方法都有助于降低與 LLM 相關的風險。

    此外,請確保任何 LLM 編排層都可以提前終止,并在請求或 LLM 生成無效時通知用戶。這有助于避免在調用插件序列時出現復合錯誤。跨 LLM 和插件調用的復合錯誤是為這些系統構建利用向量的最常見方式。此處應使用識別錯誤數據時失敗封閉的標準做法。

    圍繞為應用程序提供支持的 LLM 的范圍、可靠性和適用性對用戶進行教育非常重要。請注意,支持 LLM 的應用程序旨在補充而不是取代他們的技能、知識和創造力。使用任何結果(無論是否由 LLM 衍生)的最終責任在于用戶。

    結束語

    LLM 可以為用戶和部署 LLM 的組織提供重要價值。但是,與任何新技術一樣,新的安全風險也隨之出現。提示注入技術是眾所周知的,任何應用程序(包括 LLM)的設計都應考慮到該風險。

    不太熟悉的安全風險包括 LLM 可能造成的各種形式的信息泄漏,這需要仔細追蹤數據流和管理授權。從用戶可靠性的角度和應用程序的角度來看,LLM 偶爾不可靠的性質也必須考慮在內。

    讓您的應用程序能夠可靠地應對自然和惡意錯誤,可以提高其安全性。通過考慮本文中概述的風險,并應用所述的緩解策略和最佳實踐,您可以降低面臨這些風險的風險,并幫助確保成功部署。

    想要深入了解如何攻擊和維護機器學習模型的相關信息,請參閱 NVIDIA 在 “黑帽歐洲 2023 (Black Hat Europe 2023)” 的內容。

    注冊 LLM 開發者日,這是一個將于 11 月 17 日舉行的免費虛擬活動。歡迎參加我們的會議,主題為“利用 AI 語言模型重塑完整的網絡安全堆棧”。

    ?

    0

    標簽

    人人超碰97caoporen国产