在 2021 年，超過 4000 萬人的健康數據被泄露，而且這個趨勢并不樂觀。
聯邦學習和分析的主要目標是在不訪問遠程站點原始數據的情況下執行數據分析和機器學習。這就是您不擁有且不應該直接訪問的數據。但是，如何更自信地實現這一點？
想象一個孤立的聯邦學習場景，一家生物技術公司與醫院網絡合作。他們正在根據本地基礎設施中存儲的圖像的 CT 掃描結果，合作開發改進的肺癌檢測模型。
聚合器和生物技術數據科學家均不得直接訪問圖像或下載圖像。他們只能對遠程模型進行聯合學習、訓練和驗證，并構建更好的聚合模型，然后與所有醫院共享這些模型，以提高通用性和檢測準確性。
數據保護的目標一開始似乎顯而易見。這是一個權限、角色的問題，可能還有一些加密問題。遺憾的是，這并不像看上去那么簡單。
聯合隱私默認設置
聯合學習解決方案往往側重于以下方面：
- 傳輸信道安全
- 點對點信任(使用證書)
- 工作流程的效率
- 支持許多現有算法
所有這些都降低了從模型本身推理原始數據的風險。
然而，大多數產品和出版物都忽略了過于好奇的數據科學家的重要威脅。許多產品，無論是設計還是默認，都優先考慮近乎絕對的數據處理自由，讓外部數據科學家能夠針對遠程數據發送任何查詢或操作。
對于參與者之間幾乎無限信任的網絡，或者在不使用敏感數據的情況下，這是完全可以接受的設置。例如，網絡可能用于演示目的，或者一切都可能發生在數據所有者組織的邊界內。
當您想使用自定義訓練和驗證代碼時，默認情況下 NVIDIA FLARE 就是這樣工作的。
無論您使用何種加密方式、傳輸通道安全保證的強大程度，或者所有系統在組件漏洞上的更新程度如何，當您允許數據科學家針對遠程數據發送任何查詢或代碼時，您都無法保證提供數據泄露保護。
相反，您完全依賴于個人或合同的信任級別。或者，您可能會在稍后通過分析針對聯邦網絡中不擁有的數據執行的操作和查詢的日志來擔心。
有一天，一位或多位數據科學家可能會放棄誠實。或者，損害可能是意外的，而不是惡意的。市場數據表明數據攻擊來自內部。遺憾的是，內部威脅也在增加。
適當的員工教育、合同條款、信任、隱私意識和職業道德都很重要，但您應該使用技術措施提供更有力的保證。
應該怎么做
數據所有者應完全掌控：誰在何時對哪些數據執行什么操作。
記錄所有與數據相關的操作通常是多個產品供應商承諾的解決方案。在數據泄漏的潛在損壞完成后，為時已晚。您必須在設計階段主動預防此類情況。
現有權限系統怎么樣？在 NVIDIA FLARE 的情況下，它可以開啟或關閉，使遠程數據科學家能夠在遠程站點上執行任何作業(本地策略)。此外，生物技術管理部門無法集中管理這些權限，因為他們能夠遠程覆蓋本地策略。
其他解決方案基于可以信任任何內容的信任，選擇將二進制 Docker 鏡像從中央存儲庫推送到遠程站點(醫院)。這實際上消除了數據所有者的接受過程，因為他們只能信任圖像的封閉框。從技術上講，他們可以下載圖像、加載圖像并查看文件，但這在規模上是不切實際的。
有一種更實用的方法可用。
使用 NVIDIA FLARE 2.3.2 提升數據保護水平
以下介紹了如何顯著降低數據泄露的風險及其在財務和聲譽方面的所有后果。您可以兌現數據保護的承諾，這是我們卓有成效的合作成果，使用 NVIDIA FLARE 2.3.2 中引入的最新功能，這是聯邦學習和分析的關鍵要素。
作業接受和拒絕要求
您需要一個解決方案，使數據所有者能夠在發生之前審查要根據其數據執行的代碼。實際上，在 NVIDIA FLARE 中，這意味著實現訓練器、驗證和聯合統計數據以及配置設置的 Python 代碼。
數據所有者應能夠自行審查、接受或拒絕代碼，或使用值得信賴的第三方審查者。如果沒有數據所有者的明確接受，任何違反數據的行為都不應發生。
不得在一夜之間將作業代碼從先前接受的代碼更改為惡意代碼。由于內容已發生變化，因此應拒絕作業代碼，并且必須重新審查和重新接受。
解決方案
NVIDIA FLARE 2.3.2 支持自定義事件處理程序，這些處理程序可執行操作，以便在站點創建組件并由站點控制。
但為什么要創建對象？您不能只專注于執行嗎？
由于過于好奇的數據科學家可以輕松地將代碼注入對象初始化(構造函數)，因此對象創建至關重要。盡早采取行動，防止數據所有者不想針對其數據運行的代碼。
以下簡化流程為默認值：
- 由外部數據科學家控制的中央服務器將作業提交給客戶端。
- 客戶端調度并執行這些作業。
- 如果代碼包含向云上傳數據，則實際上會執行 Python 允許的任何內容。
- 更糟糕的是，代碼可能會隨著每次作業提交而更改，并且不會被檢測到或阻止執行。
作業從編排節點發送到本地節點以執行，其中包含代碼和配置。
使用默認的 NVIDIA FLARE 配置構建聯邦網絡后，數據所有者會對外部數據科學家產生無條件的信任。然后，他們可以提交具有本地策略的作業。
更改后，使用自定義實現：
- 由外部數據科學家控制的中央服務器將作業提交給客戶端。
- 數據所有者會審查作業代碼，并從數據泄露風險的角度確定其是否可接受。
- 如果代碼獲得批準，則將哈希值添加到可接受的哈希值列表中。
- 作業代碼(hash、簽名)在站點本地與可接受的作業哈希列表進行檢查。
- 作業在客戶端上執行，結果返回至服務器。
以下是有關作業工作流程變化的更多詳細信息。
圖 2 展示了由一個 BioTech 編排節點和三個醫院節點組成的聯合學習網絡。同一聯合訓練作業從本地節點的編排節點發送。創建該作業甚至不會防止任何惡意代碼作為作業對象初始化或構造函數的一部分。
圖 3 展示了使用新型事件和事件處理程序接受和執行作業的流程。
作業代碼接受策略
得益于 NVIDIA FLARE 2.3.2 中提供的基于事件的開放模型，我們可以實施任何合適的代碼驗證策略。此類策略必須始終在聯合網絡中設計、定義和商定，然后部署在每個節點(客戶端，如醫院)上。
出于演示目的，您可以將代碼內容哈希與存儲在其他目錄中的可接受代碼進行比較。
對于更真實的企業級場景，您還可以根據代碼的數字簽名，甚至由數據所有者信任的第三方提供的聯合簽名來提供實施。這與執行聯合訓練的生物技術無關。
代碼示例
在實例化新組件(即作業)之前， NVIDIA FLARE 會引發 BEFORE_BUILD_COMPONENT 事件。您只需編寫事件處理程序來分析代碼并確定它是否被接受。對此沒有一站式解決方案，因為不同的聯合網絡可能需要不同的策略。以下代碼示例演示了此類處理程序。出于演示目的，此示例僅關注作業的子集。
focuses on a subset of jobs.def handle_event(self, event_type: str, fl_ctx: FLContext): if event_type == EventType.BEFORE_BUILD_COMPONENT: # scanning only too curious data scientist jobs if self.playground_mode: meta = fl_ctx.get_prop(FLContextKey.JOB_META) log.info(f"meta: {meta}") if not "too-curious-data-scientist" in meta["name"]: return workspace: Workspace = fl_ctx.get_prop(key=ReservedKey.WORKSPACE_OBJECT) job_id = fl_ctx.get_job_id() log.debug(fl_ctx.get_prop(FLContextKey.COMPONENT_CONFIG)) log.debug(f"Run id in filter: " + job_id) log.debug(f"rootdir: {workspace.get_root_dir()}, app_config_dir: {workspace.get_app_config_dir(job_id)}, app_custom_dir: {workspace.get_app_custom_dir(job_id)}" ) #making sure that approved_configs hash set is up to date (it's possible to update ) self.populate_approved_hash_set(os.path.join(workspace.get_root_dir(), self.approved_config_directory_name)) log.debug(f"Approved hash list contains: {len(self.approved_hash_set)} items") # check if client configuration json is approved (job configuration) current_hash = self.hash_file(os.path.join(workspace.get_app_config_dir(job_id), JobConstants.CLIENT_JOB_CONFIG)) if current_hash in self.approved_hash_set: log.info(f"Client job configuration in approved list! with hash {current_hash}") else: log.error(f"Client job configuration not in approved list! with hash {current_hash}") log.error("Not approved job configuration! Throwing UnsafeComponentError!") raise UnsafeComponentError("Not approved job configuration! Killing workflow") # check if all classes added to custom directory are approved job_custom_classes = list(Path(os.path.join(workspace.get_app_custom_dir(job_id))).rglob("*.py")) for current_class_file in job_custom_classes: current_class_file_hash = self.hash_file(current_class_file) if current_class_file_hash in self.approved_hash_set: log.info(f"Custom class {current_class_file} in approved list!") else: log.error(f"Class {current_class_file} not in approved list!") log.error("Not approved job! Throwing UnsafeComponentError!") raise UnsafeComponentError(f"Class {current_class_file} not in approved list! with hash {current_class_file_hash}. Not approved job! Killing workflow") |
如前所述，所有必需的上下文數據均由 NVIDIA FLARE 提供，以便能夠執行必要的操作，例如查找自定義代碼文件、計算其哈希值等。
還有更多
這并不能解決與數據保護相關的所有問題。但是，在所有情況下，數據所有者對遠程數據科學家在沒有看到數據的情況下基于數據訓練模型的信任程度有限，因此解決這一問題勢在必行。
雖然此功能不是針對惡意用戶的決定性故障安全措施，但它提供了額外的保護層。它通過分擔責任為節點提供支持，并促進協作研究。
接下來，考慮關注其他重要領域，例如：
- 模型推理攻擊
- 差分隱私
- 傳輸信道安全
- 輸出濾波器
總結
在聯邦學習和分析的情況下，深度防御原則使得有必要保護數據所有者免受外部數據科學家發送的惡意遠程代碼的攻擊。在真正的聯邦場景中，當數據所有者和遠程科學家之間沒有完全信任關系時，這不是可選的。
遠程數據不可訪問的承諾并不能兌現；您必須為數據所有者授權。默認情況下，這并不能保證。
在本文中，我們演示了如何使用 Omniverse NVIDIA FLARE 2.3.2 來實現更好的數據保護，并構建現在和未來更安全的聯邦學習網絡。
?
