カテゴリー
プライバシー

プライバシーを考慮する上での重要な観点

新型コロナ関連でのトラッキングの話関連で、緊急事態で人命がかかるという思いのせいか、プライバシーに思い至らずシステム開発されるかたも多いと聞いたので、参考までにプライバシーを考える上での重要な観点をまとめておきました。同時に、アイデンティティ管理も当然絡んでくるので、それもちょっとだけ。ご参考になれば幸いです。

プライバシーを考慮する上での重要な観点

  • 目的: そのシステムの目的はなにか?
    • きちんと整理してドキュメント化すること。これがないと始まらない。現状聞くところによると、次の2つが少なくともあるようだ。
      1. 行動変容を促すアプリ:接触を8割減らす(7割ではあまり意味がない?)← 統計的に処理できるので、普及率はそこまでクリティカルではない。
      2. 感染対策:トラッキング ← アプリの普及率がクリティカル ⇢ アプリでは多分意味がない。プラットフォームがやる必要あり。
  • ステークホルダー:そのシステムのステークホルダーは誰か、システムを直接使わない人まで考えて洗い出す。
  • 攻撃者:攻撃者としてだれが考えられるか?
    • システム提供者
    • 観測者
    • 侵入者
    • 知人・家族:人間の幸福度に最も大きなインパクト
    • 地域の人:差別問題に直結
  • データの最小化:最低限取得しなければならないデータはなにか。それぞれの処理で対象にしなければならないデータはなにか。
  • プライバシー・リスクマネジメントに影響を及ぼす要因(JIS X 9250 より)
    • 法令及び規制要因
    • 契約要因
    • ビジネス要因
      • 想定される活用法、利用の背景・状況の具体的特性
      • 業界ガイドライン、行動規範他
    • 他の要因
      • 本人のプライバシー選好
      • 内部統制制度
      • 技術標準
  • 本人の権利確保 etc => ISO/IEC 29100 (JIS X 9250)プライバシー原則
    • 同意及び選択(Consent and choice)
    • 目的の正当性及び明確化(Purpose legitimacy and specification)
    • 収集制限(Collection limitation)
      • 目的を達するために必要最低限のデータしかあつめてはいけない。
    • データの最小化(Data minimization)
      • それぞれの処理において必要最低限のデータしか触ってはいけない。必要に応じてマスキングなど行う。
    • 利用,保持,及び開示の制限(Use, retention and disclosure limitation)
      • 開示先のアクセスコントロールがきちんとできているか。そのポリシーは適切か。
    • 正確性及び品質(Accuracy and quality)
      • 攻撃者がある人をターゲットにデータを入れてくるようなことが考えられる。これは重篤なプライバシーリスクを生むので対処する必要がある。
    • 公開性,透明性,及び通知(Openness, transparency and notice)
      • 信頼性の獲得に重要。
    • 個人参加及びアクセス(Individual participation and access)
      • どのようなデータが保存されているかを本人が見ることができなければならない=>本人が認証してログインしてアクセスできなければならない。(ソーシャルログインなどでも良い。)
    • 責任(Accountability)
      • 何が起きているかを説明し
      • それを第三者が検証するための証拠を提出し
      • 検証の結果説明が間違っていたら責任を取る。
    • 情報セキュリティ(Information security)
    • プライバシーコンプライアンス(Privacy compliance)
  • 対象とすべきデータ≠個人情報
    • 将来的に個人に結びつけ可能になるかも知れない情報まで管理対象にしておかないと、あとではまる。
      • 電話番号とか機器に結びついたUUIDは保護対象ではないというのは無理。
  • これらを鑑みた上でのPIA (ISO/IEC 29134 (JIS X 9251)) ステークホルダーの洗い出しと彼らによるリスクの承認

上記に鑑みたアイデンティティ管理上の観点

  • 電話番号など、変更されたり再利用されるものは一時的な識別子としては良いが、継続的な識別子としては向かない。利用はユーザー主張識別子に留めるべきで、内部識別子は別に採番し、そちらを使って管理すること。
  • 上記本人の権利確保には、本人によるデータアクセスなどがあるから、本人に認証手段を渡さなければならない。
    • 例:アプリで鍵ペアを生成して、サーバに初回データを送るときに一緒に送って登録するなど。

その他、思いつき次第順次書き足していきます。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です