这篇文章开始宣布在 NVIDIA 技能博客上。
在 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 来完成更好的数据维护，并构建现在和未来更安全的联邦学习网络。
