技術共有

マルチパーティ SQL コンピューティング シナリオで、両パーティ間で合意に達し、マルチパーティ コンピューティング操作のセキュリティを確認する方法

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

SQL シナリオにおける安全なマルチパーティ計算の制限事項

MPC やプライバシー コンピューティングなどの概念の人気に伴い、多くの政府機関や金融会社は、データのアプリケーション価値を拡大するためにマルチパーティ コンピューティング シナリオへの参加を検討し始めています。

次のシナリオを例に挙げると、銀行は、各企業の信用スコアを総合的に計算するために、水道局と電気局および国税局からデータを取得したいと考えます。

TEE、MPCなどの戦略により、計算プロセス中の中間データの漏洩を防ぐことができます。

ただし、計算結果は最終的にジョブの開始者に返されます。たとえば、開始者が [エンタープライズ ID、水の消費量 + 電力消費量] をクエリしようとした場合、プライバシー コンピューティング プラットフォームは、電力消費量と水の消費量のみを確認することしかできません。水道使用量や電気使用量が漏れていないことを保証するものではなく、電気使用量の付加価値はあくまで計算結果として提示されるものです。

したがって、「計算結果から機密データが漏洩するかどうか」という問題は、TEEやMPCなどの戦略では解決できません。

一般的な解決戦略

1. デフォルトのプライバシーポリシー

プライバシー コンピューティング プラットフォームは、複雑なプライバシー ポリシーを設定し、いくつかの SQL シナリオを指定することにより、機密データの使用を強制的に制限します。

たとえば、ID フィールドは直接拒否され、機密データ フィールドはプレーン テキストで公開されます。

2. プライバシーアルゴリズムを使用して機密データの集計結果を保護する

このタイプのアルゴリズムは機密データの集計結果を推測から保護できますが、ジョブの開始者がアルゴリズムの適用を超えるニーズがある場合は、他の手動の方法に依存する必要があります。予防のために。

3. 承認に基づく運用合意

ただし、複雑なビジネス シナリオのため、ルールが厳しすぎると通常のロジック操作がブロックされる可能性があり、制限が弱すぎると機密データが悪意を持ってアクセスされ、失われる可能性があります。

したがって、マルチパーティ SQL 計算では、各データ プロバイダーとジョブ開始者は次のことができる必要があります。合意に達する、オペレーションによるデータの使用が正常かつ合理的であることを確認します。

ただし、承認メカニズムを使用するには、次の問題を解決する必要があります。

1. 参加者が自身のデータ使用状況を確認する際に、開始者のビジネス機密情報が漏洩しないように、マルチパーティ共同 SQL ステートメントから各参加者が必要とする重要な情報を解析する方法。

2. イニシエーターが特定の SQL を構築して、表示すべきではないフィールドを取得するのを防ぐ方法。

計算上の合意形成を実現するTICSジョブ承認機能

Huawei ticsトラステッド・インテリジェント・コンピューティング・サービスは、フェデレーテッドSQLジョブの承認機能をサポートし、上記の問題を解決しました。

SQL マルチパーティ ジョブを開始しようとすると、データ プロバイダーはそれを承認して、このデータの使用が許可されているかどうかを確認できます。

具体的な手順は次のとおりです。

  1. アライアンス管理者は TICS コンソールにログインします。
  2. TICS コンソールに入ったら、ページの左側にある「アライアンス管理」をクリックします。アライアンス管理ページに入ったら、アライアンス名をクリックしてアライアンスの詳細ページに移動します。
  3. アライアンス管理者は、アライアンスの詳細ページの右上隅にある「ジョブの承認を開く」をクリックします。有効にすると、すべてのジョブを実行する前に承認される必要があります。
  4. ジョブの開始者は、自分が所属するエージェントに入り、ジョブの完了後、「承認のために送信」をクリックします。ページの下部で承認者と承認の進行状況を確認できます。

    図1承認のために提出してください

    現時点では、TICS が分析ジョブの SQL ステートメントを実行するとき、プライバシー ルールの構文制限の影響を受けなくなります。この時点で、プロバイダーは SQL ステートメントを続行する前にフィールドの目的を確認する必要があります。処刑される。承認中または承認後に SQL が変更および保存された場合は、承認のために再送信する必要があります。

    送信が完了すると、ページの下部に承認者と承認の進行状況が表示されます。

    図2承認の進捗状況

  5. データプロバイダーは、データセットが置かれているエージェントに入り、ページの左側にある「承認管理」をクリックして、保留中の承認アイテムを探します。詳細はこちら"。

    画像3承認管理

    詳細ページで承認レポートを確認できます。レポートの内容には、ジョブの開始者、プロキシ コネクタで実行される SQL ステートメント、各フィールドの役割の説明、結果に表示されるかどうか (つまり、) が含まれます。 、平文で表示されます)など。

    図4詳細

    例証します:
    • ジョブ開始者のビジネス上の機密性を保護するために、承認者に関係のないすべてのフィールド情報はここでブロックされます。たとえば、ID フィールドの説明では、このフィールドが JOIN 計算に使用される特定の開始者フィールドがブロックされます。ブロックされる。
    • 承認レポートの「フィールドが結果に表示されるかどうか」は、フィールドの値が平文で表示されるかどうかを直接決定します。フィールドのビジネス タイプに基づいて、表示されるかどうかを慎重に判断してください。
  6. データ提供者がリスクを確認した後、詳細ページで承認意見を記入し、「同意する」をクリックしてください。
  7. ジョブ開始者がジョブを実行します。実行が完了すると、ページの下部に実行結果が表示されます。

    図5ジョブの実行

  8. ジョブの結果により、承認で「非表示」と確認された機密フィールドが明らかになる可能性がある場合、それが検出され、開始者は SQL を変更してより完全な承認情報を追加するように求められます。

    このような tics の結果検出アルゴリズムは、承認情報と内容の信頼性を高め、運用の安全性を向上させるために継続的に更新されます。