情報セキュリティ

1. q q 情報セキュリティ 第１３回：２００６年７月１４日（金） q q

2. 本日学ぶこと • 暗号プロトコル • Fiege-Fiat-Shamirの認証プロトコル • 組織におけるセキュリティ • セキュリティポリシー • 規格・制度 • コンピュータ犯罪を取り締まる法律 • 個人情報保護法

3. 暗号プロトコルの具体例 • 鍵配布センターを利用したセッション鍵共有 • RSAの署名を用いた認証プロトコル • Feige-Fiat-Shamirの認証プロトコル 本日

4. Feige-Fiat-Shamirの認証プロトコル • 「FFS方式」「Fiat-Shamir方式」などとも呼ばれる • 証明者が秘密の情報を持っていれば，プロトコルの実行により間違いなくそれを認証者が確認できる． • 秘密の情報は認証者にも知られない…ゼロ知識対話証明（Zero-Knowledge Interactive Proof，ZKIP） • 秘密の情報を持っていない者が，なりすましてプロトコルを実行しても，成功する確率はせいぜい1/2 • 繰り返し実行すると，成功率は指数的に小さくなる． Prover （証明者） Verifier （認証者） ユーザ情報を入力 ＯＫ／ＮＧ

5. FFSプロトコルの前提 • 事前に生成しておく情報 • 素数 p,q は非公開とし，n←pq を公開 • 証明者は整数 s (1≦s＜n)を秘密情報として持つ • 整数 v ← s2 mod n も公開する • 計算の困難さ • 素因数分解は困難 • 大きな整数 m と整数 a (1≦a＜m)が与えられたときに，b2 mod m = a を満たす b （mを法とするaの平方根）を求めるのは • m が素数ならば容易（効率のよいアルゴリズムが存在する） • m が合成数ならば容易ではない

6. FFSプロトコル（記述） • Step 1: 証明者は乱数 r を生成し，x ← r2 mod nを計算して，x を認証者に送る． • Step 2: 認証者は e∈{0,1} をランダムに選び，証明者に送る． • Step 3: 証明者は y ← r・se mod n を計算して認証者に送る． • e=0 ⇒ y ← r mod n • e=1 ⇒ y ← rs mod n • Step 4: 認証者は y2 mod n = x・ve mod n が成り立つか確かめ，成り立たなければ認証しない． • e=0 ⇒ y2 mod n = r2 mod n ？ • e=1 ⇒ y2 mod n = r2s2 mod n = (r2 mod n)(s2 mod n) mod n • 成り立てば，認証者が納得いくまでStep1～4を行う． ？

7. FFSプロトコル（図） n, v(=s2) n, s 認証者 証明者 r を ランダム に選ぶ x は保存しておく x ← r2 mod n x を 計算する e を ランダム に選ぶ e∈{0,1} y を 計算する y ← r・se mod n y2 = x・ve ？

8. なぜFFSプロトコルでうまくいく？ • 攻撃者の目標：整数 sを持たないが，証明者になりすまして認証者から認証されること • 攻撃者があらかじめ x と y の組を生成しておけば？ • yをランダムに生成してから，x ← y・v-1 mod n を作ると，e=1のときは成功するが，e=0のときは失敗する（nを法とするxの平方根は求められない）． • 攻撃者が過去に盗聴した情報を送れば（リプレイ攻撃）？ • 以前の通信とeが異なっていれば失敗する． • すべての(x,e,y)を保存するのが現実的に難しくなるよう，p,qの大きさを決めればよい．

9. プロトコルのまとめ • 基礎となる暗号技術が安全であっても，それを用いた暗号プロトコルが安全であるとは限らない． • 暗号プロトコルに限らず，多数の人が関わるシステムを設計するときは • 実行環境には誰がいて，それぞれ何ができて何ができず，何をしたいかを明確にする． • 「うまくいく」根拠を明確にする． • 悪意のある者や何らかのトラブルも考慮に入れ，それでも安全な環境を維持できるようにする．

10. 組織におけるセキュリティ：学ぶ内容 • セキュリティポリシーとは，組織の情報資産を守るための方針や基準を明文化したものである • 情報セキュリティに関する規格・制度により，セキュリティの水準を客観的に評価できる • 個人情報保護法は，企業・組織が，個人情報を適切に管理・使用するための方針を定めた法律である

11. セキュリティポリシー • セキュリティポリシーとは？ • 組織の情報資産を守るための方針や基準を明文化したもの • あるとどうなる？ • 情報セキュリティレベルの向上 • セキュリティ対策の費用対効果の向上 • 対外的な信頼性の向上 • 何を書く？ • 組織の長の，情報セキュリティに関する方針・考え • 適切な情報セキュリティを確保・維持するために遵守すべきルール

12. セキュリティポリシーの基本構成 概要 Policy 情報セキュリティ基本方針 Standard 情報セキュリティ対策基準 Procedure 情報セキュリティ対策実施手続き，規定類 詳細

13. セキュリティポリシーをだれが作る？どう書く？セキュリティポリシーをだれが作る？どう書く？ • セキュリティポリシー策定担当者の例 • 情報システム部門の責任者 • 総理部門・法務部門・監査部門の責任者 • 人事部門・人材育成部門の責任者 • 組織内システム管理者，組織内ネットワーク管理者 • セキュリティポリシー策定の注意点 • ポリシーを策定する範囲を明確にする • 適用対象者を明確にする • 目的や罰則を明確にする • 運用を意識して，実現可能な内容にする • 「パスワードは毎週変更すること」と書いて，みんなやってくれる？

14. 情報セキュリティに関する規格・制度：背景 • なぜ規格や制度が必要？ • 一体どこまでコストをかけて，セキュリティ対策を実施すればいいのか？ • 自分の組織の情報セキュリティの水準は，同業者や世間一般と比較してどの程度なのだろうか？ • 情報セキュリティの水準を客観的に評価するための基準や制度があればいい！

15. 規格・制度の例 • ISO/IEC 15408 (JIS X 5070) • ＩＴ関連製品のセキュリティ品質を評価・認証 • プライバシーマーク制度 (JIS Q 15001) • 企業における個人情報保護措置の適切性を評価・認定 • ISO/IEC 17799 (BS7799, JIS X 5080, ISMS) • 情報セキュリティマネジメントの適切性を評価・認定 • 国際規格ISO/IEC 27001:2005 (JIS Q 27001:2006)へ • ISO 9000 (ISO 9001:2000, JIS Q 9001:2000) • 品質マネジメントシステム • ISO 14001 (JIS Q 14001:1996) • 環境マネジメントシステム • JABEE • 技術者教育プログラム

16. P A D C ISMS　（Information Security Management System） • 組織の情報マネジメント体制を維持管理していくための管理文書・管理体制・実施記録等からなる一連の仕組み • 情報セキュリティマネジメントのデファクトスタンダード • Plan-Do-Check-Actのサイクル • Plan: 情報セキュリティ対策の計画・方針・目標などを策定 • Do: 計画に基づいて対策を実施 • Check: 対策の実施・運用状況を点検・監視 • Act: 対策の適切性について評価・是正処置 やりっぱなしではいけない

17. ISMS適合性評価制度 • 評価希望事業者の申請により，日本情報処理開発協会（JIPDEC）が指定した審査登録機関が審査・認証する • 予備審査（任意），文書審査，実地審査を受け，合格すれば認証される • 認証後も，半年～１年ごとの継続審査，３年ごとの更新審査がある

18. 新しいISMS • いつ始まった？ • ISO/IEC 27001:2005は2005年10月から • JIS Q 27001:2006は2006年5月から • 新しいISMSの特徴 • 国際規格になった • 「ISMS基本方針」は，事業目的を反映したもの • リスク・アセスメントへの取り組み • 管理策の有効性検証（例：ウイルスや不正アクセスの被害回数などを監視・報告） • 内部監査の重要性

19. コンピュータ犯罪を取り締まる法律 • 電子計算機損壊等業務妨害（刑法第２３４条の２） • コンピュータや電子データの破壊 • コンピュータの動作環境面での妨害 • 電子計算機使用詐欺（刑法第２４６条の２） • 財産権に関する不実の電子データを作成 • 財産権に関する偽の電子データを使用 • 不正アクセス行為の禁止等に関する法律（不正アクセス防止法） • 権限を持たない者がアクセス • そのようなアクセスを助長 • 他人のパスワードを勝手に公開，販売 • 具体的な被害を与えていなくても処罰の対象になる

20. 個人情報保護法 • 目的（第１条） • 個人の権利と利益の保護 • 個人情報は，データ化した企業・組織のものではなく，個人情報の本人のもの • 高度情報通信社会における個人情報の有用性の配慮 • 企業・組織が，個人情報を適切に管理・使用するための方針を定める 可用性 機密性 個人 情報 完全性

21. 個人情報の例 • 氏名 • 生年月日，住所，居所，電話番号，メールアドレス • 会社における所属や職位 • 電話帳や刊行物などで公表されている個人情報 • 名刺 • 電子化するしないに関わらず対象 • 施行前に収集した情報も対象 • 個人情報でないもの • 法人などの団体に関する情報（企業の財務情報など） • 役員氏名などは個人情報になり得る • 特定の個人を識別できない形にした統計情報

22. 個人情報とプライバシーの違い • 個人情報保護 • 事業者の個人情報に対する管理責任に関するもの • プライバシーの保護 • 他人に知られたくないことを秘匿すること

23. 個人情報取扱事業者 • 事業活動を行っていれば，個人でも法人でも非営利団体でも任意団体でも対象となる • 個人情報取扱事業者に該当しないもの • 国の機関，地方公共団体，独立行政法人，独立地方行政法人 • 同じ役割の別の法律がすでに施行 • 個人情報の数が，過去６か月で５０００件以下の事業者 • 「法」には基づかないが，社会的な信頼を考えると，対応しておくべきである

24. 運用上の義務① • 利用目的をはっきりさせ，本人の同意を得る． • 利用目的は具体的に • 利用目的・利用者が変更する場合も，事前に告知と同意を • 適切な方法で個人情報を取得する． • 子供から親の情報を聞き出すのは違法 • 名簿業者から買うのはもってのほか • 個人情報は安全に管理する． • アクセス制限やデータの暗号化も • 委託してもよいが，管理・監督の責任を負う • ノートPCやUSBメモリに入れて，紛失することのないように

25. 運用上の義務② • 本人からの依頼には適切に対処 • 開示・訂正・利用停止など • 問い合わせ窓口を設置 • 本人確認も忘れずに • 個人情報の破棄も細心の注意を払う． • 紙…シュレッダー，溶解処理 • コンピュータ…抹消用ソフトウェア，物理的な破壊 • 個人情報保護への取り組み • プライバシーポリシー・個人情報保護規定を制定し，PDCAのサイクルで運用 • プライバシーマークの取得

26. オプトアウト • 「あらかじめ同意を得る」という原則（オプトイン）の例外規定 • 第三者提供におけるオプトアウト（第２３条第２項） • 第三者への提供にあたり，あらかじめ本人に通知するか，本人が容易に知り得る状態にしておき，本人の求めに応じて第三者への提供を停止すること • 目的・手段・対象のほか，本人の求めに応じて第三者への提供を停止することを明記しておく．

27. 個人情報保護　運用上の注意（１） • メールアドレスは個人情報にならない？ • nihon_taro@abc.co.jpは個人情報になるかも • 個人情報を暗号化しておけば，個人情報としての取り扱い義務が免除される？ • 暗号化しても個人情報であることには変わりない • 電話帳にある氏名や電話番号は個人情報ではない？ • 個人情報であるかどうかは，公にされているかとは関係ない • 社会貢献だけを目的とする団体なら，個人情報取扱事業者にならない？ • 営利であるか，法人であるかに関係なく，社会通念上「事業」と認められる活動をしていれば，なり得る NECネクサソリューションズ: よくわかる「個人情報保護」，東洋経済新報社　より

28. 個人情報保護　運用上の注意（２） • 名刺は社員個人で収集管理するので，個人情報にあたらない？ • 事業に関連して収集するので，会社の責任で管理する（個人情報になり得る） • 学校でクラス名簿を作ってはいけない？ • 生徒がお互いを知るためであれば，作ってよい • 病室の入口に患者の名前を記入してはいけない？ • 緊急援助や患者の取り違い防止のためならば，禁止する必要はない 牧野二郎: 間違いだらけの個人情報保護，インプレス　より

29. まとめ • 組織のセキュリティ • セキュリティポリシー，個人情報保護 • だれのために実施する？ • 組織のため？ • 社会（対外的アピール）のため？ • 情報の持ち主のため？