漏れなかったデータも、人を傷つける

架空事例：青葉機材が作業者の訪問履歴と機材の利用状況を分析する。本人の反応、データ利用、損失額は架空であり、特定の法域の適法性判断や法律上の助言ではない。

データは漏れていなかった

予約情報の閲覧権限は厳格だった。通信も保存データも保護され、外部への漏えいは確認されなかった。

それでも、担当者から苦情が寄せられた。機材の返却時刻や訪問先をもとに、作業者の働き方を推測し、取引先へ評価結果を提示していたからだ。本人は、予約システムのデータがその用途に使われるとは考えていなかった。

ここで問題になるのは、外部の攻撃者がデータを盗んだかどうかだけではない。正当な権限を持つ組織が、意図しない目的で人に関する情報を加工し、判断へ使うこともプライバシー上の影響を生み得る。

Privacy by Designは、利用開始の最後に同意画面を追加する話ではない。収集目的、必要な粒度、利用範囲、保持期間、削除、説明を企画から設計するという考え方である。原教材第23章は、その入口を示している。1

最初の目的と、後からできること

青葉機材が返却時刻を集める理由は、機材の在庫計画と返却処理を成立させるためだった。データが蓄積されると、営業は利用頻度の高い取引先を発見し、別の部署は作業者ごとの行動を分析できると考え始めた。

できる分析と、行ってよい分析は同じではない。技術的に計算可能な指標を増やす前に、当初の利用目的と新しい用途の関係、契約条件、本人への説明、必要な根拠を確認する必要がある。

例えば、月別の機材稼働率を計算するためには、作業者個人を恒久的に識別する情報まで必要とは限らない。集計単位を契約先・機材種類・期間へ変更すれば、業務目的を果たしながら個人への結び付きを弱められる場合がある。

ただし匿名化したと宣言するだけでは足りない。希少な作業場所や訪問時刻の組合せから、別データと照合して人物を推測できる可能性が残る。元の名前を削除しただけで再識別のリスクが消えるとは限らない。

データを減らすことと、責任を減らすこと

青葉機材は保存期間を短縮する案を出した。しかし、返品の紛争が発生したときに、どの予約がどう処理されたかを説明できなくなるかもしれない。

必要最小限を考えるとは、保存量を機械的にゼロへ近付けることではない。事業上の必要性、契約・法令上の記録保持、紛争の確認、本人への影響を評価し、目的ごとに保存内容と期間を決めることである。

監査ログも同様だ。操作を追える詳細なログは不正操作の調査に役立つ。一方、検索語や個人情報を無制限に記録すれば、ログ自体が新しい高価値の情報資産になる。閲覧権限、暗号化、保存期間を設定しないままログを増やすのは、別のリスクを作り込む行為である。

NIST Privacy Frameworkは、個人に生じ得るデータ処理上のリスクを、Identify-P、Govern-P、Control-P、Communicate-P、Protect-Pの機能で扱う枠組みを提供する。2 この枠組みは個々の組織に同じ実装を強制するチェックリストではなく、目的とリスクに応じて扱うための道具である。

統制する人と、運用する人が違う

経営者は「この情報を集めて何を実現するのか」「どの程度のリスクを受け入れるのか」を判断する。一方、運用担当者は、定めた方針に基づいて権限を設定し、ログを管理し、問題があれば是正する。

ガバナンスとマネジメントはどちらも必要だが、同じ作業を指すのではない。内部監査で発見した権限設定の欠陥を担当者が修正することと、その事業がそもそも個人別スコアリングを行うべきかを判断することには、責任主体と評価対象の差がある。

規格や制度の識別にもこの観点を使える。Common CriteriaはIT製品等のセキュリティ評価に関係し、CRYPTRECは暗号技術の評価や推奨リストに関係する。ISMSは組織の情報セキュリティマネジメントを扱う。1 どれも「セキュリティの制度」ではあるが、評価の対象は一致しない。

制度に適合しているという記述を見たら、対象となる版、評価範囲、組織やシステムの境界を確認する。認証があるという理由で、利用者に生じるあらゆる影響が消えるとは言えない。

リスクの計算には、事象の定義が要る

仮に、特定の事故が一年間に起こる確率を0.1、発生時の損害を100万円と置く。単純な年間期待損失額は10万円となる。対策で発生確率を0.02へ下げ、損害額が同じなら期待損失額は2万円となる。

これは数学的な期待値の例であり、現実の事故確率を測定した値ではない。損害の大きさや分布が一つの金額へまとめられない問題もある。特に個人に生じる不利益は、組織の金銭損失へすべて還元できるわけではない。

また、対策で発生を防ぐことと、発生を検知することは違う。検知率が80%だから事故の発生確率が80%減った、と計算してはいけない。被害を早く見つける効果と、事故がそもそも発生しない効果は別に評価する。

独立した二事象がどちらか一方でも起きる確率の計算と、両方同時に起きる場合の計算も異なる。原教材第23章の式を用いるには、事象の独立性や関係を明示する必要がある。1

残存リスクをゼロと書かない

すべての対策を実施しても、予期しない経路や人間の判断誤りが残る。そこでシステムアーキテクトに求められるのは、すべてを安全と宣言することではなく、想定した脅威、適用した対策、その効果と限界、残る判断事項を明らかにすることだ。

取引先の行動分析が事業上必要なら、対象データを減らす、集計する、同意や説明の方法を検討する、アクセス権限を絞る、停止できるようにする、といった選択肢がある。これらを実施してもなお残る影響は、適切な責任者へ示して判断を求める。

リスク受容は「対策しなくてよい」という技術的な免罪符ではない。対処方法・意思決定権限・前提を明確にしたうえでの判断である。NIST SP 800-30 Rev.1も、リスク評価を適切な意思決定のための情報として位置付ける。3

青葉機材は、利用状況の集計を認める前に、個人単位で何を推測できるか、契約先へ渡す情報から何が分かるかを確かめる。プライバシーは、セキュリティが破れた後だけに生じる問題ではない。

試験で語る責任の位置

午前Ⅱで、Privacy by DesignやCRYPTREC、CC、JISEC、情報セキュリティガバナンスが出題されるとき、名称に反応するだけでは不十分である。何を評価・統制する制度なのか、その主体は誰かを見分ける。

午後Ⅰでは、問題文に示された業務目的、データの流れ、利害関係者、運用条件を読む。午後Ⅱでは、設計上の選択理由、捨てた代替案、どこまで効果を確かめたかを、実際の経験に即して説明する。セキュリティの責任を「製品の導入」に置き換えないことが、この巻の終着点となる。

知識を答案へ戻す

午前Ⅱ。 プライバシーの目的制限とアクセス制御、ガバナンスとマネジメント、CC・JISEC・CRYPTREC・ISMSの評価対象を区別する。

午後Ⅰ。 個人情報がどの目的で取得され、どの処理・組織・保存領域へ進むかを把握し、本文から読み取れるリスクだけを特定する。

午後Ⅱ。 目的、対策、測定、残存リスク、承認者の判断を一続きで説明する。架空の数値を実際の業務実績として使わない。

立ち止まって考える：個人データを暗号化し、アクセスログを取っている。利用目的は自動的に適切になるか

ならない。暗号化と監査は一定の保護に役立つが、そもそも何のために集め、どう判断へ使ってよいかという目的・説明・必要性の検討とは別である。

出典と照合範囲

[1] コンプリートテキスト第20・21・23・25・27章、IPA SAシラバスVer.5.2：プライバシー・セキュリティ統制・リスク計算の基礎を出発点とする。公式シラバス

[2] NIST Privacy Framework（2020）：データ処理に伴うプライバシーリスクを管理する五つの機能を参照した。組織の適法性を判定するための個別法令とは区別した。公式解説

[3] NIST SP 800-30 Rev.1（2012）：リスク評価と組織の判断を結び付ける考え方を参照した。確率と損害額の例は独自の仮定。公式資料