mcpField
S
selecting-privacy-enhancing-technologies

selecting-privacy-enhancing-technologies

github.com/mukul975セキュリティ32335 回インストール32 週間前に更新
リポジトリ

selecting-privacy-enhancing-technologies について

プライバシー要件、処理シナリオ、運用上の制約に基づき、プライバシー強化技術を選ぶためのガイドです。6種類の技術の特性やトレードオフ、組み合わせ、GDPRとの整合性を扱います。

主な機能

  1. 016種類のPETカテゴリの比較
  2. 02プライバシー特性と性能のトレードオフ
  3. 03ユースケース別の技術選定表
  4. 04技術の組み合わせガイド
  5. 05GDPRとの整合性チェック

活用シーン

  1. 01集計分析向けPETの選定
  2. 02病院間のプライバシー保護型モデル学習の計画
  3. 03クラウドでの暗号化データ処理の評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill selecting-privacy-enhancing-technologies

インストール後、Claude Code で/selecting-privacy-enhancing-technologiesを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

詳細

プライバシー強化技術の選択

概要

プライバシー強化技術(PET)は、収集、処理、保存、共有の過程で個人データを保護する技術的な対策です。GDPRは特定の技術を規定していませんが、データ保護の原則を実施するために「適切な技術的措置」(第25条第1項、第32条第1項)を求めています。PETに関する欧州委員会の2025年2月の通達と、PETを用いたプライバシー・バイ・デザインの実装に関するENISAの2023年レポートは、PET導入の規制上の背景を示しています。

適切なPETの選択は、処理のシナリオ、データの機密性、計算要件、必要とするプライバシー特性(機密性、匿名性、連結不可能性、透明性)によって異なります。

PETの分類

1. 差分プライバシー(DP)

プライバシー特性: 統計的な識別不能性 — 分析結果は、特定の個人のデータが含まれている場合と含まれていない場合とで、ほぼ同じになります。

特徴詳細
アプローチクエリ結果またはモデルの勾配に、調整済みのノイズを追加します
プライバシー保証数学的に証明可能な(epsilon、delta)境界
データの有用性epsilonで調整できます。epsilonが小さいほどプライバシーは強くなり、有用性は低下します
パフォーマンスのオーバーヘッドクエリ時のノイズ追加では最小限、DP-SGDの学習では中程度
成熟度本番環境での利用が可能(Apple、Google、US Census Bureau)
GDPRとの関連性epsilonが十分に小さい場合は前文26の匿名化を支援します。第25条第1項に基づく設計上の措置です

最適な用途: 統計分析、集計レポート、機密データを用いたMLモデルの学習。

ライブラリ: Google DP Library、OpenDP、IBM diffprivlib、PyDP。

2. 準同型暗号(HE)

プライバシー特性: 暗号化データ上での計算 — 結果を復号できるのはデータ所有者のみです。

特徴詳細
アプローチ暗号文上の数学演算を復号すると、有効な結果が得られるようにデータを暗号化します
プライバシー保証暗号学的保証(格子に基づく計算困難性の仮定)
データの有用性正確な結果(ノイズは追加されません)
パフォーマンスのオーバーヘッド大きい:方式と演算に応じて、平文処理より1,000~1,000,000倍遅くなります
成熟度本番環境での利用が広がりつつあります。パフォーマンス最適化の研究が活発に進められています
GDPRとの関連性セキュリティ対策としての第32条第1項(a)の暗号化に該当します。処理者に平文を公開せずに処理できます

方式:

  • BFV(Brakerski/Fan-Vercauteren): 整数演算で、結果は正確です。カウントや照合に適しています。
  • BGV(Brakerski-Gentry-Vaikuntanathan): モジュラス切り替えを伴う整数演算です。深い回路で効率的です。
  • CKKS(Cheon-Kim-Kim-Song): 実数または複素数の近似演算です。ML推論に適しています。
  • TFHE(Torus FHE): 高速なブートストラップとゲート単位の評価が特徴です。ブール回路に適しています。

ライブラリ: Microsoft SEAL、IBM HELib、Google FHE(Fully Homomorphic Encryption transpiler)、TFHE-rs、OpenFHE。

3. セキュアなマルチパーティ計算(SMPC)

プライバシー特性: 個々の入力を開示せずに共同計算を行い、各参加者が知るのは最終結果のみです。

特徴詳細
アプローチ秘密分散、秘匿回路、または秘匿転送プロトコル
プライバシー保証情報理論的(秘密分散の場合)または計算量的(秘匿回路の場合)
データの有用性正確な結果
パフォーマンスのオーバーヘッド中程度から大きく、回路の複雑さと参加者数によって異なります
成熟度金融サービスや医療コンソーシアムで本番環境に導入されています
GDPRとの関連性データを共有せずに共同管理者(第26条)による分析を可能にし、データ最小化(第5条第1項(c))を支援します

フレームワーク: MP-SPDZ、CrypTen(Meta)、MOTION、ABY/ABY3、Sharemind。

4. 連合学習(FL)

プライバシー特性: データを一元化せずにモデルを学習します。生データがデータ所有者の環境から外に出ることはありません。

特性詳細
アプローチデータ所有者にモデル学習を分散し、モデルの更新(勾配)のみを集約します
プライバシー保証データのローカル保持(生データはデバイス上にとどまります)。安全な集約と DP により強化されます
データの有用性参加者間のデータ分布(IID 対 non-IID)によって異なります
パフォーマンスのオーバーヘッド勾配交換に伴う通信オーバーヘッドと、複数回の学習ラウンドが発生します
成熟度Google(Gboard)、Apple(Siri)、病院(NVIDIA FLARE)で本番運用されています
GDPR との関連性第 5 条第 1 項(c)のデータ最小化を支援し、越境移転要件(第 V 章)を軽減します

フレームワーク: TensorFlow Federated、PySyft(OpenMined)、NVIDIA FLARE、Flower、FedML。

5. ゼロ知識証明(ZKP)

プライバシー特性: 基盤となるデータを明らかにせずに、ある命題が真であることを証明します。

特性詳細
アプローチ証明者は、秘密(生年月日)を明かさずに、秘密(例:年齢が 18 歳以上)を知っていることを示します
プライバシー保証健全性(偽の命題は証明できません)とゼロ知識性(検証者は命題が真であること以外、何も知りません)
データの有用性二値検証(証明の有効/無効)。データは開示されません
パフォーマンスのオーバーヘッド証明の生成:中程度から高い。証明の検証:高速
成熟度ブロックチェーンの本人確認で本番運用されており、エンタープライズの本人確認でも普及が進んでいます
GDPR との関連性データの最小化を極限まで実現し、データを開示せずにコンプライアンスを証明します。第 5 条第 1 項(c)、第 25 条を支援します

システム: zk-SNARKs(Groth16、PLONK)、zk-STARKs、Bulletproofs。

6. 信頼実行環境(TEE)

プライバシー特性: 隔離されたコンピューティング。システム管理者でさえアクセスできない、ハードウェアで保護されたエンクレーブ内でデータを処理します。

特性詳細
アプローチセキュアエンクレーブ(Intel SGX、AMD SEV、ARM TrustZone、AWS Nitro)を用いたハードウェア強制の隔離
プライバシー保証ハードウェアベースのアテステーションとメモリ暗号化
データの有用性エンクレーブ内であらゆる計算が可能
パフォーマンスのオーバーヘッド低〜中程度。エンクレーブのメモリが限られるため、データのストリーミングが必要になる場合があります
成熟度本番運用:Azure Confidential Computing、AWS Nitro Enclaves、Google Confidential VMs
GDPR との関連性処理中の暗号化に関する第 32 条第 1 項(a)、処理者の保証に関する第 28 条に対応し、内部関係者の脅威から保護します

ユースケース対応マトリクス

ユースケースDPHESMPCFLZKPTEE主な推奨技術
顧客データの集計分析523213差分プライバシー
分散した病院データを用いた ML モデルの学習312513連合学習
財務記録を共有せずに行う信用スコアリング235223セキュア MPC
生年月日を明かさずに行う年齢確認111152ゼロ知識証明
サードパーティのクラウドでの暗号化された顧客データの処理252114準同型暗号
銀行間のマネーロンダリング対策225323セキュア MPC
プライバシーを保護したゲノム解析343314HE と TEE の組み合わせ
クラウドでホストされる ML モデルの機密推論242115信頼実行環境
プライバシーを保護したアンケートと投票513121差分プライバシー
暗号化データベースでの安全なキーワード検索141114準同型暗号

スコア:1 = 適合性が低い、5 = 適合性が非常に高い

PET 選定の意思決定フレームワーク

ステップ 1:プライバシー要件を定義する
  • 主なデータ保護の原則は何ですか?(最小化、機密性、匿名化、リンク不可能性)
  • データの転送中、保存中、処理中のどの段階で保護することが目標ですか?
  • 想定する敵対者モデルは、正直だが好奇心旺盛なものですか、それとも悪意のあるものですか?
  • 組織をまたぐ境界(複数の管理者/処理者)はありますか?
ステップ 2:制約を評価する
  • 許容できるパフォーマンスのオーバーヘッドはどの程度ですか?(リアルタイム処理とバッチ処理)
  • 計算予算はどの程度ですか?(HE は大幅に多くのリソースを必要とします)
  • 関与する当事者は何者ですか?(SMPC の処理能力は当事者数に応じて変わります)
  • ハードウェアの信頼アンカーを利用できますか?(TEE には特定のハードウェアが必要です)
  • チームの暗号技術エンジニアリングに関する専門知識はどの程度ですか?
ステップ 3:組み合わせを評価する

本番環境への導入では、多層防御のために複数の PET を組み合わせることがよくあります。

組み合わせメリット
FL + DP差分プライバシーを適用した勾配更新を用いる連合学習により、勾配反転攻撃を防止します
FL + Secure Aggregation集約サーバーが個々の勾配を一切参照できません
HE + TEE暗号化されたデータをエンクレーブ内で処理し、二重に保護します
SMPC + DPSMPC の出力にノイズを加え、形式的な匿名化保証を実現します
ZKP + TEE入力を明かさずに、エンクレーブ内で計算が正しく実行されたことを証明します
ステップ 4:GDPR との整合性を確認する
  • 選択した PET は、第 25 条第 1 項のデータ保護バイデザインの要件を満たしていますか?
  • 第 32 条第 1 項の具体的なセキュリティ対策を実施していますか?
  • 第 5 条第 1 項(c)のデータ最小化の原則をサポートしていますか?
  • 匿名化を主張する場合、特定、リンク可能性、推論に対する前文 26 の基準を満たしていますか?
  • DPIA(第 35 条)に向けて、PET のプライバシー保証は十分に文書化されていますか?

主な規制上の参照資料

  • GDPR 第 25 条第 1 項 — データ保護バイデザイン
  • GDPR 第 32 条第 1 項(a) — セキュリティ対策としての暗号化と仮名化
  • GDPR 第 5 条第 1 項(c) — データ最小化の原則
  • GDPR 前文 26 — 匿名情報
  • ENISA レポート:Data Protection Engineering(2022)
  • PET に関する欧州委員会のコミュニケーション(2025 年 2 月)
  • 第 25 条のデータ保護バイデザインおよびデフォルトに関する EDPB ガイドライン 4/2019

コメント