ML 工程師的 AI 風險評估
儘管有力地保護 ML 系統, 但 Microsoft 的 28 家企業調查 發現,大多數行業從業者尚未接受對立機器學習 (ML) 的術語。 28家企業中有25家表示,他們沒有適當的工具來保護ML系統。 更重要的是,他們正在明確尋找指引。 我們發現缺乏準備並不限於較小的組織,它們的範圍從財富500強公司、政府到非營利性組織。 客戶承認需要保護 AI 系統,但根本不知道如何。
本檔是組織評估其 AI 系統安全性狀態的第一個步驟。 但是,我們嘗試以可擷取現有傳統安全性風險評估架構的方式提供內容,而不是為組織新增另一個要遵循的架構。
本檔有三個目標:
- 提供 AI 系統安全性的完整觀點。 我們已在生產環境中查看 AI 系統生命週期的每個元素:從數據收集、數據處理到模型部署。 我們也考慮 AI 供應鏈,以及與 AI 系統相關的備份、復原和應變規劃的相關控制和原則。
- 概述重要 AI 資產的威脅,以及保護它們的安全指引。 為了直接協助工程師和安全性專業人員,我們在 AI 系統建置程式的每個步驟中列舉了威脅聲明。 接下來,我們提供一組指導方針,以重迭並強化 AI 系統內容中的現有做法。
- 讓組織能夠進行 AI 安全性風險評估。 此架構可協助收集組織中 AI 系統目前安全性狀態的相關信息、執行差距分析及追蹤安全性狀態的進度。
我們已與整個 Microsoft 的利害關係人一起制定,以及來自 Azure 安全性、工程中負責任 AI 策略、Microsoft 安全性回應中心、Azure 安全性與 AI、工程與研究中的道德與效果的代表(Aether)。
簡介
我們建議使用本文件開始討論如何保護 AI 系統,以配合進行中的資訊安全性工作和商務目標。 本檔著重於 AI 系統,並包含傳統控件,因為 AI 系統是以傳統 IT 基礎結構為基礎所建置。
我們涵蓋下列與 AI 系統相關的領域。
管理員 控制措施 | 描述 |
---|---|
機器學習安全策略 | 控管機器學習、人工智慧和資訊安全性之記載原則的相關控制與原則。 |
技術控制件 | 描述 |
---|---|
數據採集 | 與用於機器學習和人工智慧的數據集合、儲存和分類相關的控件和原則。 |
數據處理 | 與用於機器學習和人工智慧的數據處理和工程相關的控制和原則。 |
模型定型 | 與模型設計、定型和驗證相關的控件和原則。 |
模型部署 | 與模型部署和支援基礎結構相關的控制和原則。 |
系統監視 | 與機器學習系統持續監視相關的控制和原則。 |
事件管理 | 與 AI 系統相關事件的處理方式相關的控件和原則。 |
商務持續性和災害復原 | 透過模型竊取、服務降低或其他 AI 特定弱點,控制與遺失智慧財產權相關的控制和原則。 |
我們已從熱門 的 ISO27001:2013 標準 調整了現有的控件和原則架構,並跨 AI 系統建置程式對應至從數據收集階段到回應 AI 系統的威脅。 組織可能會從 ISO27001:2013 實作一些或所有現有的控制措施,或已經符合數個風險架構(NIST 800-53、PCI-DSS、FedRamp 等)作為現有資訊安全工作的一部分。
無法充分保護 AI 系統,不僅會提高此評量中解決的 AI 系統的風險,而且更普遍地會提高整個資訊技術和合規性環境的風險。
本文件的目標是不取代上述任何現有工作,而是要描述從現有工具和架構的優勢保護 AI 系統,並將其延伸至 AI 建置程式的所有部分。
此處所列的指導方針並不具規範性,因為需要更多內容,例如基礎平臺、基礎數據類型和演算法的選擇。 如果您是 Azure 機器學習 客戶,請參閱企業安全性和治理一文。
建議的嚴重性、可能性、影響
並非所有控件對 AI 系統的安全性都很重要。 因此,若要適當地排定工作優先順序,每個控件都應該由組織評等嚴重性評等,這與未實作指定控件的業務影響有關。 組織可能會選擇接受關鍵控件的風險,並改為實作補償控件以降低風險。 歸根結底,這些評等有助於引導風險型決策,而不是規定活動。
嚴重性
入侵的嚴重性將取決於 AI 模型使用案例。 幸運的是,如果在整合機器學習之前,使用的數據或系統是關鍵考慮,它應該維持不變。 同樣地,如果使用的模型是「現成」且沒有其他輸入,視模型所使用的內容而定,入侵的嚴重性可能會較低。 差異隱私權等技術可以降低入侵的潛在影響。 不過,此內容不會減少系統、數據或模型的關鍵性。 我們建議使用深度防禦策略來保護模型,而不是依賴任何防禦實作。
建議的嚴重性層級
建議為重大
- 如果 AI 模型已定型,或擷取敏感數據、機密數據,或受 PCI、HIPAA、GLBA 等合規性需求控管的數據。
- 如果 AI 模型用於業務關鍵性應用程式或系統中,讓入侵會對商務營運產生很大負面影響
- 如果 AI 模型用於實體或傷害或死亡是可能的結果的應用程式
- 如果 AI 模型用於支援重要基礎結構的系統(例如水、電力、健康情況)
建議為高
- 如果 AI 模型已定型或內嵌敏感數據、機密資訊,或組織視為重要數據的數據
- 如果入侵此 AI 模型會對商務營運造成很大但有範圍的影響
- 如果 AI 模型用於業務關鍵應用程式或系統中
建議為中型
- 如果 AI 模型是在包含敏感數據類型的定型數據子集上定型
- 如果入侵此 AI 模型會影響部署到生產環境的模型
- 如果 AI 模型用於非關鍵但面向業務的應用程式
- 如果 AI 模型未用於生產環境,但有生產模型的相關信息
建議為低
- 如果 AI 模型是以生產環境中未使用的數據進行定型
- 如果 AI 模型未用於生產環境,且沒有生產模型的相關信息
建議為參考
- 如果數據從經過審查的來源未分類
- 如果 AI 模型未用於生產環境
可能性
可能性有兩個主要元件:模型的可用性,以及技術的可用性。 若要降低攻擊的可能性,組織應該實作下列控件:
- 拿掉受攻擊面或使受攻擊面更難列舉。
- 請確定記錄和警示已如設計般運作,以確保問題的快速解決。
- 請確定所有支援系統都具備安全性需求的最新狀態。
控制端點、網路分割或速率限制。 應特別注意流量和網路或管線圖,例如攻擊者入侵和外部面向端點,並透過管線向後運作。
影響
影響與對組織的影響有關。 建議您先熟悉 ML 系統受到攻擊的不同方式,並考慮生產模型如何影響組織的方式。 如需詳細資訊,請參閱 機器學習 中的失敗模式一文。 完成此熟悉之後,即可對應至嚴重性矩陣。
嚴重性矩陣
下表是讓組織開始的基本風險和弱點嚴重性矩陣。 我們建議藉由召集安全性架構師、機器學習工程師和 AI 紅色小組成員來填滿類似的分類。
攻擊類型 | 可能性 | 影響 | 惡意探索 |
---|---|---|---|
擷取 | 高 | 低 | 高 |
規避 | 高 | 中 | 高 |
推理 | 中 | 中 | 中 |
反 演 | 中 | 高 | 中 |
中毒 | 低 | 高 | 低 |
「設計和開發安全 AI 是 BCG AI 產品開發的基石。 隨著保護 AI 系統的社會需求變得越來越明顯,Microsoft AI 安全性風險管理架構等資產可能是基礎性貢獻。 我們已在我們為客戶開發的 AI 系統中實作此架構中找到的最佳做法,並很高興 Microsoft 已開發並 開放原始碼 此架構,以利於整個產業。 —波士頓諮詢集團高級安全工程師傑克·莫洛伊
基本用法
檔案的其餘部分會遵循此結構:
- 風險控制包含控制控制控制包含控制的描述。
- 控件的目標及其應該完成的工作。
- 威脅 聲明 ,提供風險降低的描述。
- 實作控件的指引 。 我們了解,並非所有指導方針都基於合法的商業原因而得以實作。 建議您記錄無法實作的指導方針。
下表是從 AI 系統風險評估提取的控件,會新增附注來描述風險類別結構的每個部分。
範例控件
如何閱讀
1. 資料收集
主要類別
控制與從機器學習和人工智慧使用之所有來源收集數據和儲存相關的原則。
描述此類別中的哪些控件涵蓋在高階。
2.數據源
控件類別
目標:確保針對定型模型所收集的數據完整性。
應該描述控件所減輕的風險。
威脅聲明:數據會從可能包含敏感數據、可能影響模型安全性的其他不想要數據,或向組織呈現合規性風險的不受信任來源收集數據。
描述不實作 控件結果的語句。
控制:應該從信任的來源收集數據。 應保留並更新受信任的來源清單。 收集不受信任的數據 核准,應該依案例來考慮。
描述控制項最佳做法的特定動詞。
指引:
- 在定型模型之前,應盡一切合理的努力確保數據可以信任。 未受信任或未知的數據可能會在稍後的管線中引入安全性弱點。
- 包含敏感數據的數據,無論是用於數據科學目的,還是應該適當地進行清理或儲存和存取。
- 在不考慮其內容的情況下收集數據可能會導致包含非法數據的數據集。 數據收集工作應注意版權數據、數據外洩、意外洩漏數據的不安全端點。
指引是滿足上述準則的建議。 我們以產品與廠商無可知的方式提供它們,讓組織能夠以有意義的方式解決問題。
機器學習安全性評估
開始使用之前
此評估的目的是協助組織表達、追蹤及補救 AI 系統所引進之商務營運的風險。 此評量應該用來:
- 收集組織內 AI 安全性目前狀態的相關信息。
- 執行差距分析,並建立實作建議的藍圖。
- 透過每年或每年執行此評定來追蹤安全性進度。
如果組織沒有安全性計劃,此評定就不是開始的地方。 組織在實作此評量的建議之前,應該要有正常運作的資訊安全性計劃。 如需詳細資訊,請參閱 雲端採用架構 中的 Azure 安全性指引一文。
資料集合
控制與從機器學習和人工智慧使用之所有來源收集數據和儲存相關的原則。
目標:確保 AI 系統中所收集的數據完整性。
資料來源
控制:應該從信任的來源收集數據。 應保留並更新受信任的來源清單。 收集不受信任的數據的管理核准應該以案例為基礎進行考慮。 如果核准了不受信任的來源,則應該記錄它。
威脅聲明:數據會從可能包含敏感數據、可能影響模型效能的其他不良數據,或向組織呈現合規性風險的不受信任來源收集數據。
指引:
- 在 AI 系統中使用之前,應該先透過管理核准來驗證和信任輸入數據。
- 在使用或儲存之前,應該先檢閱針對 AI 系統收集的數據。
- 如果適用,應該清除不想要的專案,收集的數據。
- 應記錄並保留數據的來源。
- 用來定型模型的推斷數據不應該隱含信任,而且應該被視為新數據。
- 數據收集工作應記錄並稽核。 收集的數據應該擁有負責遵守記載原則的擁有者。
敏感數據類型
控制:為了確保 AI 系統的預存數據會根據其敏感度和使用案例正確保護、追蹤和分類。 此控件包含適當的數據分類標籤、存取原則、授權資訊、描述性統計數據、原始來源和收集日期。
威脅聲明:AI 系統中使用、儲存或存取的數據因缺乏必要的屬性、元數據或檔而不當存取。
指引:
- 開發數據原則,其中包含敏感數據類型的隱私權和保護,並將原則傳達給所有參與 AI 系統使用或建立的人員。
- 實作訓練和部署管線,以保護 AI 系統所用數據的機密性和完整性。
資料存放區
控制:數據應根據記載的分類程序適當儲存。 數據集應編製索引,並視為受資產管理和訪問控制原則約束的資產。
威脅聲明:數據會不安全地儲存,並可遭到未經授權的合作對象或系統竄改或改變。 數據未正確分類,導致機密資訊或敏感數據洩漏。
指引
- 確定開發或 AI 研究系統或帳戶無法存取生產資料庫,反之亦然。
- AI 系統中使用的數據應該根據記載的分類原則進行分類和保護。
- AI 系統中使用的數據會根據記載的資產管理原則進行追蹤。
- 用於敏感性 AI 使用案例的數據會儲存在已核准和受控系統上。
- 應稽核數據存取權,而要求存取權的用戶應該通過包含管理核准的正式訪問控制程式。
- 機器學習程式中使用的數據不應公開至因特網。
- 從因特網提取的數據(或其他不受信任的來源)應該經過包含管理核准的篩選程式。
- 數據集應該使用正式變更控制程式進行版本設定。
資料存取
控制:使用之前,應該透過密碼編譯哈希適當地追蹤和驗證數據集。
威脅語句:數據集未經授權變更。
指引:
- 應強制執行數據集的角色型訪問控制。
- 執行一般存取稽核,以確保具有數據集存取權的帳戶應該可以存取數據集。 確定每個帳戶在正常範圍內運作。
- 如果未使用中央追蹤平臺,應該檢閱透過原始存取記錄存取數據的目的。 確定每個帳戶在正常範圍內運作。
- 第三方資源提供者、承包商或其他外部方不應在沒有合約的情況下,過度或不當存取公司的訓練/測試數據資產。
資料完整性
控制:數據集應該受到信任,而且在整個 AI 系統生命週期中仍保持信任。
威脅聲明:數據集會在 AI 生命週期期間改變,而無法稽核或追蹤變更。
指引:
- 數據集應該唯一識別,如此一來,未經授權的核准數據集變更將會導致檢閱數據集。
- 數據集及其密碼編譯描述應追蹤在中央位置。 應該稽核數據集的存取權。
- 數據集的變更應該包含更新的密碼編譯描述和管理核准,再提交至中央追蹤服務。
資料處理
與用於機器學習和人工智慧之數據處理相關的控制和原則。
目標:確保數據從原始形式到準備定型的中繼窗體的安全處理。
處理管線
控制:處理管線應受到適當保護。
威脅聲明:威脅執行者可以藉由變更數據處理管線,對系統進行未經授權的變更。
指引:
- 並非所有透過生產系統行動的數據都與數據科學工作有關。 請務必只剖析所需的數據,並確保已適當地追蹤從安全生產環境設定移至開發設定的所有數據。 請考慮某些類型的數據可能無法移至開發環境。 數據科學可能需要在安全的中繼環境中發生。
- 在整個數據處理生命週期中正確稽核數據存取很重要。 如果沒有個別帳戶,就不能進行足夠的存取稽核。 此外,在不影響商務程序的情況下,無法發生回應事件的能力。 單一帳戶遭到入侵會導致所有數據都遭到入侵,而讓安全的生產環境保持安全。
- 數據科學程式可能需要超出嚴格合規性界限的資源。
- 數據科學程式應一律符合現有的需求。 此程式可能包括將數據科學資源和程式移至相容的環境。
- 數據應該在整個生命周期中追蹤;此追蹤包含較大數據集的子集。 模型應該必須追蹤回其定型的數據。 此外,該數據的複本應該完全存在。
數據集光圈
控制:為了確保模型建置所包含的數據子集(例如時態性、類別配量),以及如何通過過度強調意見反應等方式來提供安全性危害(隱私權洩漏、中毒/完整性)。
威脅聲明:威脅執行者可以藉由重建/復原數據子集來復原部分數據。
指引:
- 數據的子集本身是數據集。 這些子集必須與父數據集連結相同的元數據,而且應該針對敏感數據類型進行類似的檢閱。
- 根據機器學習做法(SLA、偏差計量等)的相關原則,任何指定的數據集(包括子集)都應該符合這些計量的最小記載標準,如果他們要用於模型建置。 元數據應該一律附加至數據集。
- 違反現有原則的所有數據集都應該有經管理核准的文件例外狀況。 除了必要的元數據之外,例外狀況中包含的原因應該是例外狀況的記載原因。
- 用於模型建置的所有數據都應該在中央位置進行追蹤。 數據隨時都應該可稽核。 此外,在未追蹤的數據上定型的模型應該從生產環境提取,直到它們與具有必要元數據的已知數據集相符為止。
- 數據集應該適當地設定版本,讓所有元數據都更新,而數據的使用者了解內容和統計屬性。 如有必要,應需要敏感性使用案例的管理核准。
模型訓練
與模型和演算法定型相關的控件和原則。
模型設計
控件:由責任方檢閱模型定型程序代碼。
威脅聲明:模型程序代碼中的不當程式代碼或弱點會產生可用性、完整性或機密性風險。
指引:
- 模型設計和研究應該發生在適當的環境中。 模型設計和架構可能會對模型的有效性產生很大的影響。 生產環境不是研究或測試關於設計有效性的非可證明宣告的地方。
- 生產系統的模型選取應經過管理檢閱和核准。 此程式應該在開發階段早期發生,並應透過任何可用的機制來追蹤(Excel、DevOps、Git 等)。 應該記錄例外狀況。
- 模型通常是特定領域,而且應該有適當的文件伴隨模型在整個組織中使用。
- 確定使用者可存取模型元數據,並記錄並強制執行模型未經核准的使用。 使用者只要適當地附加和追蹤新的元數據,使用者就可接受微調現有的模型。
模型訓練
控制:模型選取準則(計量和鑒效組集)會模擬自然漂移,以及任何可能在部署時間預期的對抗條件。
威脅語句:在理想條件下定型的模型,在對立設定中部署時可能會很脆弱。
指引
- 定型和驗證集應遵守自然時態相依性。 例如,針對惡意代碼分類器,驗證集應該只包含比定型集中所含版本還晚的軟體版本。
- 藉由透過在野外合理探索的常見損毀來增強數據集,以明確新增模型健全性。
- 使用對抗性重新訓練,明確訓練最壞的情況。
- 追蹤實驗和相關聯的中繼。
模型選取
模型選取包括從一組候選項目中選擇一個模型,其中每個候選專案都有一組唯一的模型參數、定型演算法和定型超參數。 獲勝模型的選取準則通常是以單一可量化計量(例如,最小損失、最大偵測率)為基礎,以一般鑒效數據集來測量,或以 K 折驗證集的平均表示。
控件:模型設計和定型演算法包含明確或隱含的模型正規化。
威脅語句:模型會過度適應定型和/或單一驗證數據集,而且更容易遭受失敗模式。
指引:
- 在計算可行的情況下,應該使用 K 折交叉驗證來防止過度學習到單一鑒效組。
- 確認選取的模型在不同的鑒效組上表現良好,以驗證它們是否不適合。
- 請確定進程存在。
模型版本設定
控制:當新的定型數據流入定型管線時,模型會持續重新定型。
威脅聲明:發生事件,但涉及的模型無法找到進行調查。
指引:
- 每次將模型定型時,版本模型都會指派新版本。 my_model_dev_1.1 或 my_model_prod_1.1 等限定符應該用來將生產前模型劃定。 此版本控制可協助將問題隔離至生產階段或生產階段前問題。 參考現有的安全 SDL 程式或原則。
模型部署
與模型、演算法和支援基礎結構部署相關的控制和原則。
安全性測試
控制:投入生產的模型已得到充分保護。
威脅聲明:AI 系統在部署前未充分測試弱點。
指引:
- 尚未針對新的 AI 系統、升級和新版本定義並記載正式驗收測試準則。
- 新的 AI 系統、升級或新版本應該使用正式測試來實作。
- 自動化工具應該用於測試資訊系統、升級或新版本。
- 測試環境應該與最終生產環境類似。
- 應記載獨立安全性檢閱的頻率、範圍和方法。
安全性與合規性檢閱
控制:基礎網路的健全管理是保護ML系統和基礎結構的關鍵。
威脅聲明:存取不安全的網路來入侵ML系統。
指引:
- 應將閘道裝置設定為篩選網域之間的流量,並封鎖未經授權的存取。
- 應明確定義和記錄相關法定、法規和合同要求,並處理具體控制和個人責任。
- 也應該記錄、實作或檢閱安全設定指導方針。
- 將 ML 網路隔離到網域的準則應該與組織的訪問控制原則或存取需求一致。
- 應充分實作安全網關、VPN、ML 系統的路由等機制,以啟用一組已畢業的控件。
- 使用者和 ML 工程師應採用或遵循實作控件的需求,以適當隔離和限制使用可公開存取的系統、內部網路和重要資產。
系統監視
與持續監視機器學習系統和支援基礎結構相關的控制和原則。
記錄和記錄檢閱
控制:基於安全性考慮,記錄和監視對於ML系統至關重要。
威脅聲明:在調查期間,找不到 ML 系統的記錄。
指引:
- 記錄和監視應該在所有 AI 系統及其元件上一致發生,包括記憶體、管線、生產伺服器等。
- 事件和安全性記錄應該定期檢閱是否有異常行為。
- 管理或安全性代表應該產生並檢閱系統活動的合併報告和警示。
事件管理
角色和責任
控制:安全性記錄應該收集到中央位置。
威脅聲明:在調查期間,安全性分析師沒有正式的劇本。
指引:
- 的組織必須遵循正式程式,在服務遺失、設備遺失、設備遺失、系統故障、系統超載、人為錯誤、不符合原則或指導方針、違反實體安全性、不受控制的系統變更、軟體故障、硬體故障和存取違規的情況下報告 AI 系統事件。
- 應制定正式事件回應和呈報程式,以記錄收到資訊安全事件報告時所採取的動作。
- 事件回應程式應該定期測試,追蹤回應計量。
商務持續性規劃
規劃、檢閱和結果
控制:確定可以在事件發生後補救和復原ML系統。
威脅聲明:事件會導致重大 ML 系統的持續性機密性、完整性或可用性問題。
指引:
- 應識別並清查重要的 AI 資產。
- 組織應針對 AI 系統的攻擊,開發商務持續性計畫(BCP)或災害復原(DR)程式。
- 組織必須找出與失去重要 AI 系統給攻擊影響相關的風險優先順序。
- 組織必須針對重要 AI 系統,以重複的排程運作商務持續性測試。
參考資料
- ISO 27001 附錄 A 控制器 - 概觀 (isms.online)
- 官方PCI安全性標準委員會網站
- 機器學習 中的失敗模式
- 威脅模型化 AI/ML 系統和相依性
- AI/ML 樞紐至安全性開發生命週期 Bug 列
- 企業安全性和治理
如果您有問題、意見或意見反應,請連絡 atml@microsoft.com。
從 GitHub 存放庫下載此檔的 PDF。