プライバシー脅威モデリング：LINDDUN
LINDDUNは、システム設計に潜むプライバシー侵害のリスクを体系的に洗い出すための
プライバシー侵害のリスク発見に特化した脅威モデリング手法
であり、GDPRなどで求められる「プライバシー・バイ・デザイン」を実現するための具体的なツールです。
LINDDUNは、頭字語が示す7つのカテゴリで脅威を分析します。
L - Linkability (関連付け可能性)
脅威
異なる目的で収集された個人情報を、本来の目的外で不正に関連付けられてしまうリスク。
例
ECサイトの購買履歴データと、系列のSNSのプロフィールデータが、ユーザーの同意なく内部で結合され、詳細な個人プロファイルが作成されてしまう。
I - Identifiability (識別可能性)
脅威
匿名化されたはずのデータから、特定の個人が識別・特定されてしまうリスク。
例
匿名化された位置情報データでも、自宅や職場の場所といった特異なパターンから、個人が特定されてしまう。
N - Non-repudiation (否認防止)
脅威
ユーザーが「その操作は自分ではない」と主張（否認）できないほど、強力な証拠が記録されてしまうリスク。
セキュリティではメリットですが、プライバシー観点では脅威になり得ます。
例
従業員のPC操作ログが、本人の同意なく、全てのキーストロークまで記録されており、後からあらゆる操作の責任を問われる可能性がある。
D - Detectability (検知可能性)
脅威
ある個人に関する情報が、システム内に存在するかどうかを不正に検知されてしまうリスク。
例
攻撃者が、特定のメールアドレスを使って会員登録を試み、「このアドレスは既に使用されています」というエラーメッセージを得ることで、その人がサービスの会員であることを検知する。
なんかよくあるような、、、というのは置いておきます・・・
D - Disclosure of information (情報漏洩)
脅威
個人情報が、意図しない相手に公開・漏洩してしまうリスク。最も古典的で分かりやすい脅威です。
例
アプリケーションのバグにより、他のユーザーのプロフィール情報が見えてしまう。
U - Unawareness (不認知)
脅威
ユーザーが、自身の個人情報が収集・処理されていることに気づいていない、あるいは理解していないリスク。
例
アプリの利用規約の非常に分かりにくい場所に、第三者への情報提供に関する記述があり、ユーザーが知らないうちに情報が共有されている。
N - Non-compliance (不遵守)
脅威
プライバシー保護に関する法規制や、組織内のポリシーが遵守されていないリスク。
例
法律で定められた保存期間を過ぎた後も、ユーザーデータを削除せずに保持し続けている。
LINDDUNの実行ステップ
ステップ1：システムの理解とDFDの作成
目的
分析対象のシステムが、「どのようなデータを」「どこで」「どのように」扱っているかを可視化する。
活動
システムのアーキテクチャ図、コンポーネント、外部システムとの連携点を洗い出します。
データフロー図（DFD）を作成し、データの流れ（Data Flow）、処理プロセス（Process）、データ保存場所（Data Store）、外部エンティティ（External Entity）を明確にします。
これは STRIDEの準備段階と共通 です。
ステップ2：個人データ（PII）のマッピング
目的
DFD上で、特にプライバシー上センシティブなデータがどこにあるかを特定する。
活動
DFD上のデータストアやデータフローに含まれるデータ項目を棚卸しします。
「氏名」「メールアドレス」「行動履歴」などの個人情報（PII）が含まれる箇所に印をつけ、分析の焦点を絞ります。
ステップ3：脅威の洗い出し（LINDDUNカテゴリの適用）
目的
ステップ2で特定した箇所に対し、LINDDUNの7つの脅威カテゴリを適用して、具体的なプライバシーリスクをブレインストーミングする。
活動
チームでDFDを見ながら、各カテゴリについて問いかけます。
Linkability（関連付け可能性）
「この匿名化されたログと、別のデータベースを突合すると、個人が特定できてしまわないか？」
Identifiability（識別可能性）
「このデータ単体で、個人を識別できてしまわないか？」
Non-repudiation（否認防止）
「ユーザーにとって過剰なログを取得しており、後で『やっていない』と言えない状況になっていないか？」
Detectability（検知可能性）
「攻撃者が、特定のユーザーがこのシステムに存在するかどうかを調べられないか？」
Disclosure of information（情報漏洩）
「権限のない人が、このデータストアにアクセスできてしまわないか？」
Unawareness（不認知）
「ユーザーは、自分のデータがこの目的で利用されることを認識し、同意しているか？」
Non-compliance（不遵守）
「このデータの保存期間は、当社のプライバシーポリシーや法律（GDPRなど）に準拠しているか？」
ステップ4：リスク評価と優先順位付け
目的
洗い出した脅威の中から、対策すべき優先順位を決定する。
活動
各脅威について、「発生可能性」と「プライバシー侵害の深刻度（インパクト）」 を評価します。
リスクマトリクスなどを用いて、優先度の高い脅威（例：「可能性が高く、インパクトも大きい」）を特定します。
ステップ5：緩和策の検討
目的
優先度の高い脅威に対する具体的な対策を設計する。
活動
LINDDUNが提供する緩和戦略のカタログ（例: 最小化、抽象化、隠蔽、制御など）を参考に、技術的・組織的な対策を検討します。
例: データの匿名化手法の強化、アクセス制御の厳格化、ユーザーへの同意取得プロセスの改善など。
STRIDEとの統合アプローチの手順
STRIDE（セキュリティ脅威）とLINDDUN（プライバシー脅威）は、排他的なものではなく、1つのDFDに対して、2つの異なるレンズを順番に適用することで効率的に実施できます。
1. 共通の準備 (DFD作成)
まず、分析対象システムのデータフロー図（DFD）を1つ作成します。
これが両者の共通の土台となります。
2. 分析パス1：STRIDEによるセキュリティ脅威分析
レンズ
システム管理者・攻撃者の視点
問い
「システムはどのように攻撃され、破壊されうるか？」
分析
DFDの各要素に対してSTRIDEの6項目（なりすまし、改ざん、否認、情報漏洩、サービス拒否、権限昇格）を適用し、セキュリティ上の脆弱性を洗い出します。
3. 分析パス2：LINDDUNによるプライバシー脅威分析
レンズ
データ主体（ユーザー）・プライバシー保護の視点
問い
「システムはどのように個人のプライバシーを侵害しうるか？」
分析
同じDFD上で、特に個人データを扱う部分に焦点を当て、LINDDUNの7項目を適用し、プライバシー上の問題を洗い出します。
4. 統合と対策
STRIDEとLINDDUNの両方で発見された脅威を、一つのリスク一覧表にまとめます。
片方のみでは、上記で触れたように、
セキュリティではメリットですが、プライバシー観点では脅威
ということが起こりかねません。
必ず、両方の観点からリスクの優先順位を評価し、対策を計画します。
なぜ、異なる観点で脅威を捉える必要があるか
システムを「攻撃から守る」というセキュリティの観点
「個人の権利を守る」というプライバシーの観点
これらは、また違った観点です。
網羅的にカバーした統合アプローチで、総合的にリスクを認識する必要があるからです。
STRIDEの観点 🛡️：システムのセキュリティ
STRIDEが主に問うのは、「このシステムは、どのように攻撃され、破壊されうるか？」です。
情報漏洩（Information Disclosure）もカバーしますが、あくまで攻撃者の視点から見た、システムへの脅威が中心です。
LINDDUNの観点：個人のプライバシー
LINDDUNが問うのは、「このシステムは、どのように個人のプライバシーを侵害しうるか？」です。
攻撃の有無だけでなく、システムの正常な動作そのものが、プライバシー上のリスクを生まないかを分析します。
比較表
データ分析基盤への異なる観点で脅威を捉える
では、上記でなんで２つの異なる観点で脅威をとらえるべきか？を抑えたので、
データ基盤への統合アプローチで、脅威を出してみましょう。
シナリオとして、ユーザーの行動ログを「匿名化」して、データ基盤に保存する場合
を考えてみましょうか。
STRIDEの分析
ここでは、アクセス制御やシステムの可用性が主な関心事です。
・「匿名化されたデータが、権限のない者に情報漏洩しないか？」
・「ログ収集パイプラインがサービス拒否攻撃を受けないか？」
・「ログデータが改ざんされないか？」
LINDDUNの分析
ここでは、STRIDEでは見逃されがちな、プライバシー侵害そのものをリスクとして洗い出します。
・「この匿名ログは、他のデータと関連付けられて、個人が識別できてしまわないか？ (Linkability, Identifiability)」
・「ユーザーは、このログが収集・分析されていることを、正しく認知しているか？ (Unawareness)」
・「このログは、データ保持ポリシーに従って、適切に削除されているか？ (Non-compliance)」
まとめ
データ基盤は個人情報の宝庫となりがちです。
そのため、システムを攻撃から守るSTRIDEと、データの扱い方そのものがプライバシーを侵害しないかを検証するLINDDUNを両方実施することで、初めて包括的なリスク分析が実現できるのです。