AI 系統安全需要多層次防禦策略，從架構設計到營維運護，都需納入安全考量。除了基本的授權、加密和最小許可權原則外，還需透過網段隔離和許可權分離，強化系統的防禦能力。資料準備階段，資料完整性、追蹤和安全儲存至關重要。佈署管道中，對抗性示例檢測和資料品質工具有助於及早發現漏洞。構建過程中，保護 CI/CD 管道安全、控管構建工件、妥善管理基礎設施程式碼和秘密至關重要。此外，滲透測試、靜態/動態分析和負面測試，以及 AI 特定的測試，能有效提升系統安全性。營運過程中，則需關注資料攻擊、模型攻擊和系統攻擊的防禦，並留意基礎模型的查詢、供應鏈和交換格式等安全風險。
強化 AI 系統安全的架構方法
在設計 AI 系統時，安全性是首要考量。為了確保系統的安全，需要採用多層次的防禦策略。以下是幾種強化 AI 系統安全的架構方法：
9.2.2 強化安全的架構方法
- 授權：對所有服務請求進行授權檢查，確保使用者和服務只有在必要時才獲得最小許可權。
- 加密：使用 HTTPS 和其他加密通訊協定來保護資料傳輸。
- 最小功能性：組態系統只提供必要的功能，限制非必要功能的使用。
- 限制存取：限制存取點的數量，例如透過限制埠、協定和服務。
- 限制流量：組態防火牆只允許必要的流量透過。
- 網段隔離：使用最小許可權原則控制存取。
- 許可權分離：每個元件只具有執行其功能所需的最小許可權。
- 許可權最小化：除非必要，否則停用許可權。
實施安全措施時，需要在安全性和可用性之間取得平衡。良好的架構、開發和營運需要在安全要求和系統可用性之間取得平衡，確保安全措施不會過度影響系統的功能和使用者經驗。
9.2.3 資料準備方法
在 AI 系統中，資料準備是安全性的關鍵部分。為了確保資料的完整性和安全性，需要採用以下方法：
- 資料完整性：保證資料不被竄改或破壞。
- 資料追蹤：追蹤資料的來源和變化，以確保資料的可靠性。
- 資料儲存：安全地儲存資料，例如使用 Merkle 樹等技術來保護資料的完整性。
透過採用這些方法，可以有效地保護 AI 系統免受各種攻擊和威脅，確保系統的安全性和可靠性。
9.2.4 測試在佈署管道中的應用
在佈署管道的執行過程中，進行測試可以偵測到一些型別的漏洞。主要有兩種工具：
- 對抗性示例檢測：這些工具生成設計用於觸發模型中意外或不正確行為的輸入，基本上模擬了真實世界中的攻擊。它們有助於識別諸如模型中毒、迴避攻擊和公平性問題等漏洞。這些工具建立並輸入模型的合法輸入變體，觀察其反應中的異常或不正確的預測。有些使用根據梯度的方法，而其他人則使用進化演算法或符號推理。
- 資料品質工具：這些工具分析用於訓練模型的資料，檢查是否存在缺失值、不一致性和異常值等問題，這些問題可能會對模型的效能和安全性產生負面影響。這些工具使用統計分析、資料血緣追蹤和異常值檢測演算法來識別可能影響模型安全性和效能的訓練資料中的問題。
9.2.5 加強系統構建過程中的安全性
構建過程中的安全性始於管道安全。CI/CD 管道本身需要被保護。如果攻擊者獲得了 CI/CD 管道基礎設施的寫入存取權，他們可能會修改軟體的許多部分，並在大規模佈署未經授權的程式碼。潛在地，許多服務可能會被滲透，如果攻擊者能夠控制這一關鍵軟體部分。這也可能影響您對攻擊的回應能力——您可能無法回復到早期版本，如果用於回復的軟體已經受到損害。
為了保護管道，措施包括限制對管道的修改，可能需要兩個人授權對管道進行修改。此外，團隊成員應該在管道的任何部分更新時收到通知。
CI/CD 管道可以並且應該用於增加所生成系統的安全性。您可以使用它來控制構建過程中使用的工件，包括框架、函式庫、套件、範本、基礎設施程式碼、組態等。監控任何更改並審查它們，以維持一個狀態，即只有可信任的工件最終出現在您的生產系統中。對於 AI 系統，這延伸到訓練和測試資料。
與傳統系統一樣，基礎設施程式碼必須以與應用程式碼相同的安全實踐進行儲存和管理（儲存在版本控制系統中，應用最小許可權原則，進行徹底測試等）。良好管理實踐的重要性延伸到秘密，例如控制雲生產環境或客戶資料函式庫的憑據。最佳實踐是使用特定的秘密和憑據解決方案，例如 Jenkins 秘密儲存；正確地做到這一點允許確保沒有秘密出現在 VCS 或可見發布部分。絕大多數開發人員不需要存取生產環境的秘密，因此不應授予他們存取權。這些原則從傳統設定延伸到 AI 系統，但由於您可能使用不同的服務來訓練和提供 AI 系統的部分，因此請確保將這些原則應用於它們。
初始投資於組態和可能編寫程式碼（例如，連線新服務到您使用的秘密儲存）會因增加安全性和自動化而得到回報。
CI/CD 管道支援安全性的另一種方式是透過滲透測試、靜態和動態分析、UAT 和整合測試，包括負面測試（嘗試系統互動作用不應允許，並觀察它們確實不允許），以及 AI 特定測試，用於期望和不期望的行為。透過以這種方式使用 CI/CD 管道，您可以提前捕捉漏洞，並確保在安全性方面沒有迴歸，即以前關閉的漏洞在系統開發繼續進行時保持關閉。
AI 基礎系統的一種新做法是使用所謂的資料金絲雀。像傳統 DevOps 實踐中的金絲雀伺服器一樣，資料金絲雀被比作煤礦作業員下井時帶下的金絲雀——一隻在痛苦中的金絲雀是有毒氣體的強烈警告訊號。資料金絲雀是在重新訓練或連續學習期間應用的少量資料樣本：您使用新的資料的一小部分子集，訓練一個模型的測試版本，並檢視其行為是否如預期。所有這些步驟都可以在某種程度上自動化。如果帶有資料金絲雀的系統行為與預期行為不同，這可能是資料漂移（時間上的正常變化）、故障（例如，故障感測器提供資料）或惡意攻擊的指示。使用資料金絲雀進行訓練相比使用整個新資料集的主要優點在於：（i）使用金絲雀進行訓練更便宜，（ii）它也更快，而回應安全事件時速度至關重要。
加強營運過程中的安全性
營運過程中的攻擊可能針對資料、模型或系統。
資料攻擊
根據圖 9.2，我們可以看到針對資料的兩種攻擊型別：規避攻擊和濫用/誤用攻擊。規避攻擊是指稍微修改正常資料以利用 AI 的弱點從而獲得期望的錯誤輸出（例如，修改停車標誌使得自主車無法識別）。濫用/誤用攻擊涉及透過看似合法的來源向 AI 系統提供錯誤資訊以操縱其整體行為，例如在社交媒體上發布假新聞。 目前，還沒有針對這些型別的攻擊的有效對策。
為加強資料安全的一些基本原則包括：
- 資料最小化：使用最少量的資料使 AI 系統正常運作。這減少了攻擊面和資料洩露的可能性。
- 資料加密：加密靜態和傳輸中的資料以保護它免受未經授權的存取。
- 資料匿名化：如果可能，在將資料輸入 AI 模型之前匿名化敏感資料。
- 定期資料稽核：監控資料存取和使用情況以識別任何可疑活動。
模型攻擊
模型攻擊的有效性取決於模型型別。一些更容易受到攻擊的模型具有以下特徵：
- 複雜模型（如深度神經網路）難以解釋（不透明）。這使得理解它們如何做出決策變得困難，並使其容易受到對抗攻擊的影響，攻擊者操縱輸入以獲得期望的輸出（例如，繞過垃圾郵件過濾器）。
- 整合模型結合多個模型——雖然它們可能很強大，但其安全複雜性增加。如果整合中的一個子模型被破壞，則整個系統可能會受到影響。 一些不太容易受到攻擊的模型和特徵包括：
- 決策樹或根據規則的系統通常更容易理解和分析。雖然它們可能不如複雜模型那樣強大，但其透明度使其不太容易受到對抗攻擊。
- 像邏輯迴歸這樣的技術提供了對其如何得出結論的更清晰的視角。這允許更容易地檢測模型邏輯中的潛在偏差或漏洞。 一些提高模型安全性的通用規則包括：
- 實施強大的存取控制以限制誰可以存取、修改或操縱 AI 模型。
- 不斷監控 AI 模型的效能，以檢測效能下降、偏差蔓延或意外行為的跡象。異常檢測可以在這方面提供幫助。
- 保留 AI 模型的版本歷史以跟蹤更改並在必要時回復。
系統攻擊
AI 系統上的攻擊可能採取拒絕服務（DoS）攻擊的形式。AI 比傳統系統更容易受到計算密集型攻擊；攻擊者可能更容易超載您的昂貴 GPU 叢集。限制請求是一種防禦 DoS 攻擊的技術。 日誌記錄和稽核有助於確定攻擊的源頭和後果。記錄所有模型輸入、輸出和相關操作對於潛在的法醫分析和異常檢測很有幫助。隱私法規或契約協定可能禁止此類別做法；如果您遵循此做法，請安全地儲存這些日誌並嚴格限制授權人員的存取。
基礎模型
基礎模型由於其規模、領域獨立性以及難以理解基礎模型的工作原理而容易受到攻擊。基礎模型的一些攻擊向量根據查詢和供應鏈。如果您的基礎模型可以從查詢中學習，這就開啟了另一種攻擊向量。 基礎模型特有的情況是，大多陣列織不會自己訓練基礎模型。因此，供應鏈問題更加普遍。透過 API 使用基礎模型時，基礎模型的消費者需要了解模型和服務基礎設施何時更新以及如何通知他們。服務基礎設施的一部分可能是控制，如防護欄。如果由玄貓管理，對其進行更新可能會不被注意到，但可能會改變基礎模型的行為和效能/準確度。 使用外部提供的基礎模型時，組織必須像使用第三方函式庫一樣採取相同的謹慎措施。一些流行的交換模型格式容易受到從程式碼注入到拒絕服務（DOS）等一系列攻擊，例如由玄貓實施的緩衝區溢位。 建立自己的基礎模型的組織可能會檢索大量資料。根據 NIST AML 報告，在大多數情況下，玄貓不會持久儲存資料；相反，它們持有一份外部源列表。在一個複雜的攻擊中，攻擊者可能會嘗試劫持該列表上的網域名稱，以控制基礎模型接收到的資料。
圖表翻譯：
graph LR
A[開始] --> B[規避攻擊]
B --> C[濫用/誤用攻擊]
C --> D[資料最小化]
D --> E[資料加密]
E --> F[資料匿名化]
F --> G[定期資料稽核]
內容解密：
上述 Mermaid 圖表描述了加強營運過程中的安全性的步驟。首先，我們開始瞭解規避攻擊和濫用/誤用攻擊。然後，我們採取措施實施資料最小化、資料加密、資料匿名化和定期資料稽核，以保護我們的資料。這些步驟有助於防止攻擊並確保我們 AI 系統的安全性。
圖表翻譯：
graph LR
A[開始] --> B[基礎模型]
B --> C[查詢和供應鏈]
C --> D[供應鏈問題]
D --> E[控制機制]
E --> F[更新通知]
F --> G[效能/準確度]
內容解密：
上述 Mermaid 圖表描述了基礎模型及其相關安全問題。首先，我們開始瞭解基礎模型及其工作原理。然後，我們考慮查詢和供應鏈作為潛在的攻擊向量。供應鏈問題可能會出現，因此我們需要實施控制機制並更新通知以確保基礎模型的安全性和效能/準確度。
圖表翻譯：
graph LR
A[開始] --> B[拒絕服務攻擊]
B --> C[計算密集型攻擊]
C --> D[限制請求]
D --> E[日誌記錄和稽核]
E --> F[法醫分析和異常檢測]
內容解密：
上述 Mermaid 圖表描述了系統攻擊及其防禦措施。首先，我們開始瞭解拒絕服務攻擊及其對計算密集型系統的影響。然後，我們採取措施限制請求以防禦這些攻擊。此外，我們實施日誌記錄和稽核以進行法醫分析和異常檢測，從而確保我們 AI 系統的安全性和可靠性。
從系統安全架構的全面視角來看，構建安全的 AI 系統並非單點突破，而是需要涵蓋資料準備、模型訓練、佈署管道與實際營運等全生命週期的系統性工程。本文分析了強化 AI 系統安全的各種方法，涵蓋了授權、加密、最小功能性、存取控制、流量限制、網段隔離、許可權分離及最小化等關鍵導向。然而，技術層面的防禦措施並非萬靈丹，如何在安全性和可用性之間取得平衡，是 AI 系統設計中必須審慎權衡的課題。尤其在模型攻擊方面，複雜模型固有的不透明性使其更易受到對抗性攻擊的影響，而決策樹或根據規則的系統則相對透明且易於分析。此外，本文也深入探討了基礎模型的安全性挑戰，突顯了供應鏈安全和查詢攻擊的風險，並強調了模型格式安全的重要性。對於仰賴外部基礎模型的企業而言，審慎評估供應商的安全措施和更新策略至關重要。AI 安全技術的發展將持續朝向更精細化的模型可解釋性、更強大的對抗性攻擊防禦以及更全面的供應鏈安全管理等方向演進。玄貓認為，唯有將安全性融入 AI 系統設計的每個環節，並持續關注新興威脅與防禦技術，才能有效降低風險，確保 AI 系統的穩健性和可靠性。
