2018-02-26 Akamai主催「人材サイト成功事例セミナー」のキーノートセッションで使用したスライドです。

1. 個人情報の観点から見る
サイトセキュリティの重要性
弁護士ドットコム株式会社
太田 良典

2. 自己紹介
太田 良典
弁護士ドットコム株式会社 技術統括部
エキスパートエンジニア
Webアクセシビリティ、情報セキュリティ分野が専門
第二回IPA賞(情報セキュリティ部門)受賞
ウェブアクセシビリティ基盤委員会 翻訳作業部会 主査
著書「デザイニングWebアクセシビリティ」他

3. Amazonにて「アクセシビリティ」で検索!

6. 今日のお話
● 個人情報のお話
● セキュリティのお話
● 個人情報の観点から見るセキュリティの重要性
● 具体的にどう対応するのか
● まとめ

7. 個人情報のお話

8. 個人情報保護法における「個人情報」の定義を要約
個人を識別できる情報を含む
「個人に関する情報」
識別できる情報 = 個人情報、ではなく
それを含む「個人に関する情報」全体が個人情報

9. 個人情報 = 住所氏名ではない

10. 情報の例
● 六本木の弁護士ドットコムの太田という人物が、
● 転職サイトのXXXに登録していた
どこからどこまでが個人情報なのか?
何を知られるとまずいのか?

11. 個人を識別できる情報
● 六本木の弁護士ドットコムの太田という人物が、
● 転職サイトのXXXに登録していた
○ この情報は個人を特定できる
○ こういう人物が存在すること自体は
知られても困らない

12. プライバシーに関する情報
● 六本木の弁護士ドットコムの太田という人物が、
● 転職サイトのXXXに登録していた
○ 転職サイトが存在すること自体は公知
○ もちろん登録者は存在するであろう
○ 誰が登録しているかわからなければ問題ない

13. プライバシーに関する情報 + 個人を識別
● 六本木の弁護士ドットコムの太田という人物が、
● 転職サイトのXXXに登録していた
単独では問題ない情報だが、結びつくと問題になる

14. 電話番号は個人情報?

15. ● 公衆電話の番号は個人情報とは考えにくい
● 携帯電話の番号は安易に知られたくない上、
個人に結びつきやすい
● 名前などと一緒に電話番号を取得すれば、
容易に個人に結びつく
電話番号は個人情報になることもある

16. https://www.cloudsign.jp/media/20180219-mudancancel/

17. 「個人は特定できません」の落とし穴

18. 「この情報から個人を特定することはできません」
という説明はよく見かける
● 本当に特定できませんか?
● 「氏名はわかりません」にすぎないのでは?
特定できないと言い切って良いのか

19. 個人が特定できない例
「東京都 会社員 Aさん」
誰だかよくわからない
● 氏名の情報がないから?
● 氏名がない = 特定できない、と考えて良い?

20. 氏名がなくても特定できるかもしれない例
「東京都 内閣総理大臣 Aさん」
特定の人が思い浮かびませんか?
● 該当者が少ないと特定できる可能性がある
○ 先の例で特定できないのは該当者が多いから

21. 2013年のSuica情報提供問題

22. http://www.jreast.co.jp/press/2013/20130716.pdf

23. ● 独自の識別番号 (Suica IDそのものではない)
● 生年月日、性別
● 乗降駅名、乗降日時
● 鉄道利用額
氏名は削除。しかし再識別の可能性はないか?
提供された情報

24. 乗降データと個人識別
● 乗降駅と乗降日時で個人が識別できないか?
○ 同じ時間に改札を通る人は多いため、
一見識別できないように思える
● 複数集まったらどうか?
○ 例: 8:00にA駅、9:00にB駅、10:00にC駅

25. http://in-law.jp/archive/taikai/2013/bunkakai1-Kikuchi.pdf

26. ● 個人を識別できなくすると、
「匿名加工情報」として扱うことができる
● 特定できても素直に個人情報として扱えば良い
○ 「特定できない」と言い張る必要があるか?
識別できてはダメなのか?

27. ここまでのまとめ

28. 個人情報のお話 まとめ
● 住所氏名 = 個人情報、ではない
○ 知られては困る情報が結びつくのがまずい
● 特定できないから個人情報ではない、
という主張をするのは案外難しい
○ 個人情報として扱えば良い

29. セキュリティのお話

30. 情報セキュリティ10大脅威

31. https://www.ipa.go.jp/security/vuln/10threats2018.html

33. 「情報セキュリティ人材の不足」は脅威なのか?
10大脅威選考会の一部メンバーからの意見
「情報セキュリティ人材の不足」は
「脅威」とは言えないのではないか?

34. そもそも「脅威」とは何か?

35. 情報セキュリティの3大要素 : CIA
● 機密性 (Confidentiality)
○ 秘密にすべき情報が漏れてはダメ
● 完全性 (Integrity)
○ 情報を改ざんされてはダメ
● 可用性 (Availability)
○ サービスが使えなくなってはダメ

36. 個人情報の観点から見る
セキュリティの重要性

37. 個人情報の保護は重要だと思いますか?

38. JNSA「2016年 情報セキュリティインシデントに関する調査報告書」

39. http://www.security-next.com/088071

40. 本当に重要ですか?

41. 守ろうとしない組織もある
「電話番号は個人情報ではないから守らない」
と明言する組織も存在する

42. なぜ守る必要があるのか?
● 法で義務づけられているから守る?
● 法的義務がなければ守らない?
何を、何のために守るのか、整理できていますか?

43. 答えは一つではない
● 事業の性質によってリスクは異なる
● 組織によってポリシーやミッションは異なる
リスクの分析とポリシーの策定が重要
それは他組織のコピーではあり得ない

44. 3大要素でリスクを考える

45. 機密性 (Confidentiality)
秘密にすべき情報が漏れてはダメ
● 秘密にすべき情報は何か?
○ 何を守るべきか?
● 漏れたらどうなるか?
○ 経営にどういうインパクトがあるか?

46. 完全性 (Integrity)
情報を改ざんされてはダメ
● 改ざんされると困るものは何か?
○ 昔と今では状況が異なるものも
● 改ざんされたらどうなるか?
○ 経営にどういうインパクトがあるか?

47. 可用性 (Availability)
サービスが使えなくなってはダメ
● サービスが停止すると誰が困るか?
● サービスが停止したらどうなるか?
○ 経営にどういうインパクトがあるか?

48. 時代によるリスクの変遷

49. https://webmaster-ja.googleblog.com/2015/12/inde
xing-https-pages-by-default.html

50. ● Webにある情報の多くは公開情報
● 重要な操作だけピンポイントで保護
○ IDとパスワードの入力
○ 個人情報やカード番号の入力
○ 管理画面の操作
昔の考え: 機密性のための暗号化

51. ● 公開情報でも改ざんには大きなリスクがある
○ ユーザーに対する偽情報の提示
○ 偽の入力フォームによる情報摂取
● モバイルとWi-Fiの普及で改ざんリスクは上昇
○ 偽のアクセスポイントを用意して改ざん
最近の考え: 完全性のための認証

52. ここまでのまとめ

53. セキュリティの話 まとめ
● セキュリティは重要だとよく言われるが、
本当に重要なのかきちんと考えておく
○ リスク分析、ポリシーの策定
● 見直しも必要
○ 時代によって環境も考え方も変わる

54. 具体的にどう対応するのか

55. よくある対応
● 製品を導入する
○ ウィルス対策ソフト、ファイアウォール、etc.
● プロに見てもらう
○ 脆弱性診断、コンサルティング、etc.
● 社内教育
○ ポリシーとルールの策定、定期的な研修、etc.

56. 製品を導入すれば解決するのか?
解決することもあるし、そうでないこともある
● 適切な製品を適切に運用すれば有効
● 適切な製品が選べるのか
● 運用できるのか

57. プロに頼れば解決するのか?
解決することもあるし、そうでないこともある
● 定期的な診断などは有効
● サービス開始前後の相談などは有効
● ただし社外のプロにできることには限界もある
○ 経営判断までは踏み込めない

58. 結局は「人」の問題
● 社内教育が重要とされる理由
● 「情報セキュリティ人材の不足」が
「脅威」としてあげられる理由

59. 「運用」のその次へ

60. https://landing.google.com/sre/

61. ユーザーと向き合う

62. ユーザーという要素
ユーザーに起因するセキュリティ問題
● セキュリティ設定を無効にする
● 弱いパスワードを設定しようとする
● 他のサイトと同じパスワードを使いまわす
→「パスワードリスト攻撃」が深刻化

63. よくある考え
ユーザーに厳しい制約を課す
● セキュリティ設定を無効にできないようにする
● 複雑なパスワードを強制する
● パスワードを定期的に変更させる

64. https://www.newsweekjapan.jp/stories/world/2017/05/-----2.php

65. ● 定期変更には思われているほどの効果はない
● 定期変更を強制すると、
ユーザーは弱いパスワードを使うようになる
○ 変更する都度考えなければならない
○ どうせすぐ変更するものなので深く考えない
パスワード定期変更が推奨されない理由

66. ユーザーに不便を強いてはならない
● ユーザーに過剰な負担を課すと、
サービスが使いにくくなる
● その結果、ユーザーが「工夫」をしはじめて
逆に安全性が低下することもある

67. https://connpass.com/event/55559/

68. まとめ

69. 今日のまとめ
● 「個人に関する情報」全体が個人情報になる
○ 住所氏名 = 個人情報、ではない
● セキュリティがなぜ重要なのか考える
○ リスク分析を行う、「人」を大切にする
● ユーザーのことも考えましょう!

70. ありがとうございました