SCQL作为隐私计算SecretFlow框架中的联合数据分析引擎，大家必然关注其安全性。本篇将对SCQL的安全性进行介绍。
我的SCQL系列文章：
- 隐私计算-SecretFlow/SCQL-如何在不泄漏隐私数据下进行联合数据分析
- 隐私计算-SecretFlow/SCQL-SCQL的两种部署模式架构
- 👉隐私计算-SecretFlow/SCQL-SCQL的安全性说明
- 隐私计算-SecretFlow/SCQL-CCL列控制列表机制
安全保障和威胁模型
对于单次查询，SCQL 在计算过程中提供满足 CCL 权限要求的数据机密性保护（CCL更多细节可查看隐私计算-SecretFlow/SCQL-CCL列控制列表机制）。
SCQL 不保护查询语句，因为查询语句对 SCQL 所有的参与方公开。SCQL 也不保护中间计算结果的大小（维度）信息。
SCQL 构建在 MPC 框架 secretflow/spu 之上，使用的是 semi-honest 半诚实安全模型。SCQL semi-honest 模型假设所有的参与方，包括查询者，数据拥有方(SCQLEngine 部署在数据拥有方) ，和 SCDB 等都严格遵守协议，但有可能会尝试分析自己得到的中间信息以获得额外的其他参与方的隐私信息。
和所有基于密码学的隐私计算系统一样，现阶段 SCQL 无法解决建立在合法查询结果上的反推原始数据隐私的问题。目前学术界解决该问题的方案一般都是通过 DP 加噪音。虽然 CCL 机制可以让数据 owner 对自己的数据进行使用限制授权，能一定程度地缓解风险，但是不能完全杜绝风险。同时，像CCL这样的权限配置机制通常是复杂的，配置错误。SCQL 也不解决参与方篡改自己原始输入从而得到其他参与方隐私信息的问题。
下面的章节会介绍可能存在的结果反推攻击方法，并给出相应的建议。
部署建议
SCDB 是 SCQL 系统中的一个中心协调组件，负责将 query 转换成明密文混合的执行图，然后下发给部署在参与方的 SCQLEngines 执行。SCDB 负责生成执行图，是不能作恶的。建议把 SCDB 部署在可信第三方，打消数据参与方对 SCDB 节点作恶的担忧。
如果可信第三方不存在，建议在P2P模式下部署SCQL系统。 关于部署模式的详细信息可以参阅隐私计算-SecretFlow/SCQL-SCQL的两种部署模式架构。
针对 SCQL 的结果反推攻击风险说明及建议
SCQL 的查询灵活多变，攻击者可以使用多次合法查询或一个复杂查询来构建自适应攻击，以达到反推原始数据的目的。
攻击方法一：多次查询攻击
多次查询攻击方法包含两种攻击方式： (1) 一种方式是查询语句不变，每次查询时篡改输入内容的方式来获取对方信息。比如攻击者可以通过改变自己 join key 的内容，多次枚举查询来获得对方 join key 的全部信息。 (2) 另一种方式是通过改写每次查询语句，对比多次查询结果来推测对方的隐私数据。比如攻击者可以利用 where 条件限制聚合函数的输入，第一次查询获得 N 条数据的聚合结果，第二次通过改变 where 条件，获得其中 N-1 条数据的聚合结果，对比结果可以获得其中 1 条记录的明文数据信息。
攻击方法二：构造复杂查询攻击
该攻击方法和多次查询攻击方法类似，其核心思想是将多个查询语句写成一个复杂查询语句。 举个例子，攻击者可以在一个查询语句里对某一列进行多次比较，缩小数据范围来反推原始数据。
建议
- 数据拥有方在给自己数据设置 CCL 时要慎重考虑；
- 上游平台在集成 SCQL 时，建议在执行查询前加一个人工审批流程。查询语句只有经过所有数据拥有方的审核确认后，才能提交到 SCQL 执行；
- 建议集成事后审计机制，对历史查询的执行情况进行分析，使得可以追踪和发现敏感信息泄露问题。
系统安全配置说明
- SCQL 支持 HTTPS 协议，建议默认开启。有关如何为 SCDB 和 SCQLEngine 启用 HTTPS 的方法详见 SCDB TLS 配置 and SCQLEngine TLS 配置。
对上游集成方的建议
-
在向 SCQL 提交查询前，增加数据参与方审批查询语句的流程。
-
建议集成事后审计机制，对历史查询的执行情况进行分析，使得可以追踪和发现敏感信息泄露问题。
-
建议将 SCQL 的使用过程分为研发态和生产态，并采用不同的安全管控措施。
- 研发态指 query 处于迭代中的研发模式。研发态中使用的数据样本必须是经过脱敏、去标识化、匿名化、加噪等手段处理后的小规模数据集，旨在快速地构建数据分析处理流程。
- 生产态指 query 经过联合分析的多个参与方一起安全审计，确保任务无风险或者风险在多个参与方的接受范围内，并发布在生产上运行。若相关 query 要变更，需要重新走多方审计评审。生产态使用的数据为真实数据，联合分析的多方需要进行：(1) 事前对任务评审与审批；(2) 事中确保任务一致性，若有风险及时中止任务；(3) 事后进行审计，若发生恶意行为，确保可以发现和规避潜在的数据泄漏风险。
