統合ID管理入門
- 1. Copyright © 2012 NTT DATA Corporation (株）NTTデータ 山田 達司 統合ID管理入門
- 2. 2Copyright © 2012 NTT DATA Corporation 本日の内容 ◼自己紹介 ◼統合ID管理とは ◼主要概念の説明 ◼統合ID管理における課題 – アカウント管理 – 認証 – 認可 – 属性情報管理 – ライフサイクル管理 – 証跡管理
- 3. 3Copyright © 2012 NTT DATA Corporation 自己紹介 山田 達司 NTTデータ 技術開発本部 エボリューショナルITセンタ AR/VR エバンジェリスト、セキュリティプリンシパル お仕事 ⚫専門は情報セキュリティとモバイルコンピューティン グによるワークスタイルイノベーション ⚫現在はテレワーク、AR/VRに関するR&D、コンサルティングに 従事 ⚫東京大学、名古屋大学、筑波大学非常勤講師 ライフワーク ⚫ 電子手帳ブームの際にPalm,Clieで動作する日本語OSを 開発 ⚫ 書籍執筆、メディア出演、開発者支援サイト運営 ⚫ 2chで「神降臨」というフレーズを生み出す
- 4. 4Copyright © 2012 NTT DATA Corporation ◼自己紹介 ◼統合ID管理とは ◼主要概念の説明 ◼管理の統合 – アカウント管理 – 認証 – 認可 – 属性情報管理 – ライフサイクル管理 – 証跡管理
- 5. 5Copyright © 2012 NTT DATA Corporation なぜ統合ID管理が必要なのか 情報の改ざん、漏洩などに よる事件、事故が多発 ITによる内部統制の必要性 J-SOX法など法規制強化 適切な人と権限の管理 コンプライアンスの動向 C/S、Webの普及 汎用機による中央処理型 IT運用の分散化、負担増加 利便性、運用効率低下 情報の信頼性、安全性低下 ITシステムの動向 統合ID管理 管理すべき項目の増加 管理対象システムの増加 全体最適化が必要
- 6. 6Copyright © 2012 NTT DATA Corporation ログ情報 組織情報 文書管理システム ファイルサーバ 購買システム 人事システム 統合ID管理とは 利用者情報 権限情報 利用者 ID・アカウント管理 認証/情報提供 証跡取得 統合ID管理とは、必要な証跡を取得しつ、企業内のポリシーに基づき定義されたプロ セスに沿ってID・アカウント情報の管理を行い、業務システムに認証機能及び情報提 供を行うこと
- 7. 7Copyright © 2012 NTT DATA Corporation 統合ID管理を構成する６つの機能 tokei.bmp システム ID情報 システム システム ｸﾚﾃﾞﾝｼｬﾙ 属性情報 ライフサイクル管理 利 用 者 の 識 別 と 本 人 確 認 証跡情報証跡管理 アカウント管理認証 認可 統合ID管理を実現するためには「アカウント管理」、「認証」、「認可」、「属性情報管理」、 「ライフサイクル管理」、「証跡管理」からなる6機能が必要である。統合ID管理とシステ ムはID情報の更新時とユーザのシステム利用時に連携を行う。 シ ス テ ム の 利 用 範 囲 の 特 定 属性情報管理
- 8. 8Copyright © 2012 NTT DATA Corporation 統合ID管理の代表的な機能構成 利用者 情報 情報 権限 情報 申請 PW変更 情報参照・変更 ｾﾙﾌｻﾎﾟｰﾄ 申請情報 レポート／ ログ情報 外部データ 連動機能 人事システム Active Directory LDAP Radius Web SSO ｸﾗｲｱﾝﾄｼｽﾃﾑ API 利用者 購買システム ﾒﾝﾃﾅﾝｽ 管理者 Identity Management Access Management CSV/XML Agent Library 証跡管理 利用者
- 9. 9Copyright © 2012 NTT DATA Corporation • 自己紹介 • 統合ID管理とは • 主要概念の説明 • 管理の統合 – アカウント管理 – 認証 – 認可 – 属性情報管理 – ライフサイクル管理 – 証跡管理
- 10. 10Copyright © 2012 NTT DATA Corporation IDとは？ ■IDには２つの意味があり、混同されることが多い。 Digital IDentity（デジタルアイデンティティ） ・・・ITシステムにおける利用者の投影のこと 。ID管理のIDはこちら IDentifier(アイデンティファイア） ・・・利用者を特定するための識別子のこと。用途に応じて複数持つことも可能 ログインID：1001234 公開ID：yamadatts システムID:P012341 パスワード：secret01! 名前：山田 達司 電話：050-5547-1799 所属：BS事業本部 役職：課長 Digital IDentity IDentifier（識別子） このほか、システムの利用権、資格情報、 顔写真などが含まれることもある。 Credentials（本人確認のための情報） Attrubutes(属性）
- 11. 11Copyright © 2012 NTT DATA Corporation 使い分けられるID ２つのIDはコンテキストにより使い分けられているが、誤解の元となることも多い。 「IDを入力してください」 IDentifier 「システム上にIDを作りました」 Digital IDentity 「社員番号をIDとして使っています」 IDentifier 「あなたのIDは無効になりました」 Digital IDentity 「社員と協力会社社員は異なるIDを使います」 IDentifier 「IDの払い出しをお願いします」 ???? 「人事システムと連動してIDを管理しています」 ???? ログイン ユーザID パスワード IDentifier 本資料ではデジタル・アイデンティティを「アカウント」と呼ぶ
- 12. 12Copyright © 2012 NTT DATA Corporation IDentity アカウント（Digital Identity）の用途 アカウント（Digital Identity）の主な用途はシステム内の機能や情報を利用させることである。 利用者は以下のプロセスを経てシステム内の機能や情報を利用する ⚫ 識別：Identification ⚫ 認証：Authentication ⚫ 認可: Authorization 電子文書 電子文書 電子文書 アプリケーション 識別 認証 認可
- 13. 13Copyright © 2012 NTT DATA Corporation 識別(Identification)とは 利用者がITシステムにアクセス → 誰？ （「識別」） ID （アカウント） ID （アカウント） ID （アカウント） アカウント ID ログイン ユーザID パスワード ID 利用者が誰であるか見分けること PW
- 14. 14Copyright © 2012 NTT DATA Corporation 認証(Authentication)とは ※ 認証にはパスワード以外にもICカード認証や生体認証など様々な方式がある ID （アカウント） ID （アカウント） ID （アカウント） アカウント ID PW ログイン ユーザID パスワード PW 「識別」により誰がアクセスしてきたか判明 → 本人か？ （「認証」） 利用者の「識別」を行った上で利用者が本人であるか確かめること ID
- 15. 15Copyright © 2012 NTT DATA Corporation 認可(Authorization)とは 電子 文書 アプリケーション 参照 ○ 更新 × 機能A × 機能B ○ 「認証」により本人だと判明 → 何でもやらせていいか？ （「認可」） 「認証」された利用者がシステムを利用する際に、機能・情報をどこまで利用させ るかを決定すること
- 16. 16Copyright © 2012 NTT DATA Corporation 連携するシステム 利用者 権限 統合ID管理システム 情報提供システム 人事システム 社員情報 クライアントシステム 文書管理 システム ファイル サーバ IP電話 システム 提供 「統合ID管理」システムは利用者や組織に関する基本情報を人事システムなどから取得 ID管理情報の源泉となるシステム → 情報提供システム 「統合ID管理」システムはアカウント情報や認証・認可などを各システムに提供 ID管理情報や認証、認可の提供先となるシステム → クライアントシステム
- 17. 17Copyright © 2012 NTT DATA Corporation プロビジョニング 統合ID管理の管理情報の流れ 人事・組織に関するイベントにより統合ID管理システムが管理するアカウントや各 種情報の更新を行い、クライアントシステムへ自動反映を行うこと 利用者情報権限 文書管理システム ファイルサーバ IP電話システム 人事システム 統合ID管理システム アカウント アカウント アカウント 入社 登録 アカウント 作成 反映
- 18. 18Copyright © 2012 NTT DATA Corporation まとめ：アカウント・IDとは？ 利用者：ID統合を行う組織において、正当な理由 で社内システムを利用する可能性のある者 アカウント(Digital Identity)：利用者を電子的に表 現したもの。識別子（Identifier)、クレデンシャル（パ スワード）、属性情報などを含む。 ID(Identifier)： 利用者を一意に識別する情報。 アカウントのキーとなる情報。用途に応じて複数存 在する場合がある クレデンシャル：本人確認(認証）に利用される情 報。パスワード、ICカード、生体情報などがある。 属性情報：利用者に付随して管理される情報 （例：役職、所属、名前、電話番号等） 利用者 アカウント 実世界 ITシステムログインID：1001234 公開ID：yamadatts システムID:P012341 パスワード：secret01! 名前：山田 達司 電話番号：050-5547-1799 所属：BS事業本部
- 19. 19Copyright © 2012 NTT DATA Corporation まとめ：識別/認証/認可 識別：Identification ある利用者が特定の個人であることを伝えること。 認証：Authentication 利用者が識別により伝えられた個人であることを 確認し、利用者の正当性を証明すること。 認可：Authorization 認証された利用者のシステムの利用可否、利用 可能な機能、利用可能な情報の範囲等を定める こと。 NTTデータの 山田です。 これが社員証 です 伺っております。 お入りください 識別(Identification)と認証(Authentication)はあわせて認証と呼ばれることも多い。 認証(Authentication)、認可（Authorization)に課金（Accounting)を加えAAAと呼ばれることもある。
- 20. 20Copyright © 2012 NTT DATA Corporation まとめ：システムと連携 利用者情報 権限情報 文書管理システム ファイルサーバ IP電話システム 人事システム 統合ID管理システム アカウント アカウント アカウント アカウント 作成/変更/削除 反映 情報提供システム クライアントシステム プロビジョニング
- 21. 21Copyright © 2012 NTT DATA Corporation • 自己紹介 • 統合ID管理とは • 主要な概念の説明 • 管理の統合 – アカウント管理 – 認証 – 認可 – 属性情報管理 – ライフサイクル管理 – 証跡管理
- 22. 22Copyright © 2012 NTT DATA Corporation アカウント管理の統合化とは ◼アカウント管理とは システムの利用者の変更に伴い、アカ ウントの作成、修正、削除等を行うこ と。 ◼アカウント管理の統合化とは 業務システムにおいて個別に行われ ていたアカウント管理を複数システム 間で連動して実施すること。 アカウントの 作成/変更/削除 アカウントの 作成/変更/削除 アカウント管理の 統合化 アカウント アカウント アカウント
- 23. 23Copyright © 2012 NTT DATA Corporation アカウント管理の統合における課題 ◼統合方式 ◼ID体系 ◼利用者の分類 ◼利用者を管理する期間 アカウント管理の統合においては、以下の課題を検討し、方針を策定し、システム 上に実装する必要がある。
- 24. 24Copyright © 2012 NTT DATA Corporation アカウント統合 統合方式 （１／３） 「アカウント管理の統合」には３つの方式がある 集約 ・・・ 統合ID管理がアカウントを一元管理し、必要に応じて情報を提供 配布 ・・・ 統合ID管理がアカウントを一元管理し、コピーをｸﾗｲｱﾝﾄｼｽﾃﾑに配布 連携 ・・・ 統合ID管理とｸﾗｲｱﾝﾄｼｽﾃﾑが異なるアカウントを保持し、相互を関連 付ける アカウント アカウント 統合された アカウント 連携 統合ID管理 クライアントシステム クライアントシステム アカウント 配布 クライアントシステム 集約
- 25. 25Copyright © 2012 NTT DATA Corporation 統合方式 （２／３） アカウント アカウント アカウント 人事システム 統合ID管理 人事システム 統合ID管理 アカウント アカウント コピー配布 関連付け 人事システム 統合ID管理 アカウント 情報提供 アカウント アカウント アカウント 集約 配布 連携 各システムはその特徴に従い、「集約」、「配布」、「連携」のうち適切な方式によりアカ ウント統合されている必要がある。 LDAP/ActiveDirectory Web SSO FTP CSV/XML SAML
- 26. 26Copyright © 2012 NTT DATA Corporation 統合方式 （３／３） 方式 集約 配布 連携 メリット 情報漏洩リスクが低い 情報の変更が即座にシ ステムに反映される 技術的な難易度が低く適用 可能なシステムが多い。 管理ポリシー、ID体系など が異なるシステム群の統合 が可能 デメ リット システムの構造によって は技術的に実現困難。 統合ID管理システムが 停止するとシステム全体 が停止 システム管理者による利用 者情報盗難・悪用のリスクあ り。 盗難・悪用時の影響範囲が 大きい。 システムごとの管理ポリ シーの違いに個別対応が必 要。 適した 環境 クライアントシステムも含 めて再構築する場合な ど。 連携するクライアントシステ ムが独自にアカウント管理 が必要であるが、カスタマイ ズが可能な場合。 イントラのシステムとSaaSな ど同一ポリシーの適用が困 難な場合 統合方式それぞれの特徴は以下の通り。
- 27. 27Copyright © 2012 NTT DATA Corporation ID体系 （１／３） ログイン メール ログ ID ID ID @xxx.co.jp IDの用途はシステム利用時の認証、利用者による他利用者の識別、システム間での 利用者の識別など様々なものがある、異なる用途に対してひとつのIDを用いると、利 便性の低下、セキュリティリスクの増大などの問題が懸念される 成りすましを防ぐため、ID は非公開が望ましい 変更することも有効 IDは人に伝えることが目的 識別が容易な体系が望ま しい システムで利用が容易な 固定桁数が望ましい 変更は不可
- 28. 28Copyright © 2012 NTT DATA Corporation ID体系 （２／３） 利用者A システム管理者 クライアントシステム ログインID 公開用ID システム連携用ID 用途に応じて適切な特徴を持つ最小限の種類のIDが各アカウントごとに定義され ている必要がある。 利用者A アカウント
- 29. 29Copyright © 2012 NTT DATA Corporation ID体系 （３／３） IDの 種類 用途 公開 可能性 変更 可能性 ID体系・例 ログイ ンID システムへのログイン時 にパスワードと組み合わ せて利用者を識別・認証 する 非公開 可変 それ自身が意味を持たない、あま り長くない半角英数字 「U123456」、 「7654321」など 公開 ID システムの利用者、管理 者および外部の人が利用 者を一意に特定可能とす る（メールアドレス等） 公開 可変 それ自体である程度利用者を特 定できる、可変長の半角英数字 「suzuki.taro」、 「tanaka-hanako02」など シス テム 用ID 連携するシステム間で認 証情報、属性情報などを 受け渡す際に利用者を識 別する（DB上のキー） 公開 不変 固定長で生成した半角英数字な ど（利用者が識別できる必要はな い） 「xU23i041Z」など アカウント毎に３種類のIDを付与する例
- 30. 30Copyright © 2012 NTT DATA Corporation アルバイト社員にある システムを使用させたい 利用者の分類 （１／３） 社員 統合ID管理 ポリシー： 誰でも利用可 クライアントシステムA 社員 アルバイト クライアントシステムB どのシステム に反映？ 管理者 社員 ポリシー： 正社員のみ 利用可能 アルバイト システムが利用対象となる利用者を明確に決めない場合、新たな種類の利用者を 統合ID管理に追加することが難しくなる。
- 31. 31Copyright © 2012 NTT DATA Corporation 利用者の分類 （２／３） 統合ID管理として、管理対象外とするものも含めて、利用者の範囲・分類を定義し、 システムごとの利用ポリシーに従って適切にプロビジョニング（反映）を行うことが 必要 クライアントシステム 利用者情報 統合ID管理システム 社員 協働者 社員 社員 社員 協働者 協働者
- 32. 32Copyright © 2012 NTT DATA Corporation 利用者の分類 （３／３） 利用者の 分類 扱い方 社員 基本的には会社と何らか雇用関係にある利用者。「社員」の範囲 は企業の規定やポリシーによる。 役員 社員の役職の延長線上として扱う。 協働者 社員とは区別する。協働先の会社や組織との関係を管理する。 退職者 無効な利用者として扱う。再度利用権付与する場合は所定の手続 きを必要とする。 その他利 用者 例外的に扱う利用者として、取引先営業担当、保険勧誘員、ショー ルーム来訪者なども対象とすることが考えられる。 システム クライアントシステムによっては他システムとの連携のためにIDを 必要とするケースが考えられる。これらの連携システムを個別に特 殊な利用者として扱う。 利用対象者の分類例は以下のとおり
- 33. 33Copyright © 2012 NTT DATA Corporation 利用者の管理期間 （１／２） 利用者不在となってから発覚するセキュリティインシデントへの対応が困難 ◼ 退職、契約終了などで利用者不在となった場合は即座にアカウントを削除する ◼ 退職、契約終了などで利用者不在となった後もアカウント管理を継続する 契約 契約期間終了 再契約 契約期間終了 個人情報漏洩のリスクを軽減 契約 契約期間終了 再契約 契約期間終了 管理期間終了 不在となった利用者の個人情報を保持することで情報漏洩のリスク ○ ○ × × 利用者不在となってから発覚するセキュリティインシデントの証跡トレースに有効 統合ID管理として、利用者を管理する期間を定めないと、セキュリティリスク、運用 負荷の増大を招く恐れがある。
- 34. 34Copyright © 2012 NTT DATA Corporation 利用者情報の管理期間 利用者の管理期間 （２／２） 利用者アカウントを管理する期間は関連法規と企業のセキュリティポリシーに従い 適切に設定されており、期間中は安全に管理され、満了時は全システムの該当ア カウントが確実に削除されることが必要 インシデント発生時の 証跡トレース 個人情報漏洩リスク回避 安全性 運用効率
- 35. 35Copyright © 2012 NTT DATA Corporation • 自己紹介 • 統合ID管理とは • 主要な概念の説明 • 管理の統合 – アカウント管理 – 認証 – 認可 – 属性情報管理 – ライフサイクル管理 – 証跡管理
- 36. 36Copyright © 2012 NTT DATA Corporation 認証の統合化とは ◼認証とは 利用者がシステムを利用する際に、利 用者が誰か、本人であるかどうかを確 認すること(識別+認証） ◼認証の統合化とは 業務システムにおいて個別に行われ ていた認証を同一の情報、機能、ユー ザインタフェースなどにより実現するこ と ID/PWの入力 一回のID/PW 入力で全システム 利用可能 認証の 統合化 ID/PWの入力 ID/PWの入力 U321123 ****** USER ID PASSWORD ログイン
- 37. 37Copyright © 2012 NTT DATA Corporation 認証統合の課題 ◼認証統合パターン ◼シングルサインオン ◼認証方式 認証の統合においては、以下の課題を検討し、方針を策定し、システム上に実装 する必要がある。
- 38. 38Copyright © 2012 NTT DATA Corporation 認証統合パターン （１／２） 未統合 ID/PW配布 認証サービス シングルサインオン ID/PW 認証 ID/PW 認証 ID/PW 認証 証跡 証跡 証跡 - FTP LDAP/Active Directory Web SSO 認証 認証 認証 証跡 証跡 証跡 ID/PW 認証 証跡 ID/PW ID/PWで認証依頼 ﾛｸﾞｲﾝ画面 ﾛｸﾞｲﾝ画面 ﾛｸﾞｲﾝ画面 認証 証跡 ID/PW 利用時認証依頼のみ ID/PW ID ﾛｸﾞｲﾝ画面 ﾛｸﾞｲﾝ画面 ﾛｸﾞｲﾝ画面 ﾛｸﾞｲﾝ画面 ﾛｸﾞｲﾝ画面 ﾛｸﾞｲﾝ画面 ID/PW配布 ID/PW ID/PW ID/PW ID/PW ﾛｸﾞｲﾝ画面 適用される技術 システムの運用形態やセキュリティポリシーに基づき、最適な方式で認証を統合する ことが必要である。認証を統合するおもな方式は以下の通り。
- 39. 39Copyright © 2012 NTT DATA Corporation 認証統合パターン （２／２） 観点 未統合 ID/PW配布 認証サービス ｼﾝｸﾞﾙｻｲﾝｵﾝ 利便性 C B B A システム毎個別の ID/PW 統合されたID/PW。 システム毎のログ イン 同左 １回のログインのみ 安全性 B C B+ A なりすまし、漏洩など のリスクが大きいが、 影響はシステムにと どまる 業務システム管理者 による盗難のリスクが ある ID/PW盗難時の被害 範囲が大きい 各業務システム間で ID/PWが流れ、各シ ステムがその蓄積が 可能 ID/PWは１箇所でのみ 管理、システム間も流 れない。認証方式の変 更・追加にも柔軟に対 応 内部統 制 C B A A 利用者の証跡管理 が各システムに分散 され、IDもばらばらで 問題発生時の調査・ 分析が困難 問題発生時の利用者 の特定はしやすくなる が、認証ログが分散 管理される分、調査・ 分析の効率はよくな い 利用者の認証に関す る証跡も一元管理さ れ、問題発生時の対 応も効率的に行うこと ができる 同左
- 40. 40Copyright © 2012 NTT DATA Corporation シングルサインオン １回のログイン操作 システムA システムB システムC U321123 ****** USER ID PASSWORD ログイン 一回のログイン操作だけで、認証を必要とする複数のシステムを利用できることをシ ングルサインオンと呼ぶ。主なメリットは「ユーザの利便性向上」「ID/PWの集中管理、 証跡の集中取得によるセキュリティ向上」など。 認証情報 統合ID管理システム 複数システムを 利用
- 41. 41Copyright © 2012 NTT DATA Corporation シングルサインオンの実現方式 対象となるシステムの種類により、シングルサインオンの実現方式は大きく3種類に 分けられる。 方式名 方式の概要 特徴 WebSSO プロキシー、フィルターなどにより、 Webサーバ全体に認証をかける方 式。 認証と同時にACLに基づく認可を制御 可能。 静的なコンテンツのアクセス制御が可 能 ライブラリ 型SSO アプリケーションにライブラリの形式 でSSO機能を付加する方式 アプリケーション単位でのSSOが可能 認証機能を持つAPのみSSO化可能。 静的コンテンツは制御付加 Enterpris eSSO 利用者のPCにｲﾝｽﾄｰﾙしたﾓｼﾞｭｰﾙ がｱﾌﾟﾘｹｰｼｮﾝが表示するログイン 画面を監視し、ID、パスワードを自 動的に入力する方式 既存ｱﾌﾟﾘｹｰｼｮﾝの改造が不要 認証機能を持つAPのみSSO化可能 PCへのﾓｼﾞｭｰﾙｲﾝｽﾄｰﾙが必須
- 42. 42Copyright © 2012 NTT DATA Corporation シングルサインオン-Web SSO 利用者 WebサーバA 認証サーバ WebサーバB ｴｰｼﾞｪﾝﾄ ｴｰｼﾞｪﾝﾄ 利用者 WebサーバA リバース・プロキシサーバ WebサーバB 認証サーバ エージェント型 リバース・プロキシ型 Webサーバにｲﾝｽ ﾄｰﾙされたｴｰｼﾞｪﾝ ﾄがCookieに格納 されたログイン状 態、属性等により アクセス制御を実 行 利用者のリクエス トリバースプロキシ サーバが受信し、 認証及びアクセス 制御を実行 バックエンドに ある各サーバ に直接アクセ スできないた め安全性が高 い Webサーバの 制限がない ボトルネックに なる箇所が少 ないためパ フォーマンス に優れる リバースプロ キシーサーバ がパフォーマ ンスのボトル ネックになる 可能性がある。 各サーバに エージェント （プラグイン） が必要 タイプ 説明 メリット デメリット Web SSOの主な２方式は以下のとおり
- 43. 43Copyright © 2012 NTT DATA Corporation シングルサインオン-ライブラリ型 利用者 OpenID SAML2.0 OpenID Foundationに より規定 認証サーバ (OP:OpenID Provider)、 アプリケーション （RP:Relaying Party)と もに自由な利用が可能。 OASISが規定。 Trusted Circleと呼ば れる関係付けられた認 証サーバ（IdP：Identity Provider)、アプリケー ション（SP:Service Provider)間でのSSOが 可能 認証情報と通信手段 が独立している。 仮名により、異なるID 体系のサービス間の SSOが可能 セキュリティの高さから SaaSなどでの実績多 実装がシンプルであり、 オープンなモジュール が多数存在 インターネット上には多 くのOP(Yahoo!、mixi、 google等）が存在 説明 特徴 ライブラリ型SSOの主な２方式は以下のとおり 認証サーバ IdP/OP SP/RP アプリケーション OpenID SAML2.0 方式
- 44. 44Copyright © 2012 NTT DATA Corporation シングルサインオン-EnterpriseSSO 利用者 利用者 クライアント システム 同期プロセス ID/PW読み取り型 ID/PW同期型 利用者がクライアント システムに登録した パスワードを統合ID管 理が読み取って記憶 する パスワード同期プロセ スが対象システムの パスワードを自動生 成し、ｸﾗｲｱﾝﾄｼｽﾃﾑと 統合ID管理の両者に 登録する ｸﾗｲｱﾝﾄｼｽﾃﾑには同期ﾌﾟﾛ ｾｽが生成するパスワード を設定する仕組みが必要 パスワード更新の頻度を 上げることでセキュリティ 向上が可能 クライアントシステムに一 切の改造、機能追加が不 要 ｸﾗｲｱﾝﾄｼｽﾃﾑが表示する すべてのﾛｸﾞｲﾝ画面、パス ワード変更画面を登録す る必要あり 方式 説明 特徴 統合ID管理 クライアント システム 統合ID管理 Enterprise SSOではｸﾗｲｱﾝﾄｼｽﾃﾑ用ID/PWの管理方法に大きく2種類が存在する U321123 ****** USER ID PASSWORD ログイン
- 45. 45Copyright © 2012 NTT DATA Corporation シングルサインオン 方式 適した環境 対象システ ム方式 業務システムへの要件 Web SSO リバースプ ロキシ型 インターネット 企業内 Web APサーバが集約されていること 業務システムのログイン機能が改造可 能であること エージェント 型 企業内 Web エージェントモジュールのインストールが 可能であること 業務システムのログイン機能が改造可 能であること ライブラリ型 ID連携 インターネット SaaS/クラウド Web ライブラリの組み込みが可能であること Enterprise SSO ID/PW同期 型 企業内 Web、C/S 外部からID/PW書き換え可能なインタ フェースを持っていること ID/PW読み 取り型 企業内 Web、C/S ログイン画面、パスワード変更画面が特 定可能なこと。Java/Flash不可などの制 限あり SSOを実現する方式はそれぞれ特徴があり、適切なものの選択が必要
- 46. 46Copyright © 2012 NTT DATA Corporation 認証方式 認証(本人確認）には精度、利便性などで異なる様々な方式が用いられる。最も 広く用いられているのはパスワードである。複数の方式を組み合わせることで、よ り確実な認証を行うことを二因子認証、二要素認証、多要素認証と呼ぶ。 種類 説明 主な認証方式 知識 本人しか知り得ない情 報・知識の確認 パスワード、PIN 質問 身体的特徴 本人のみが持つ身体 的特徴の確認 （バイオメトリクス認証） 指紋、虹彩 声紋、網膜 所有 本人のみが所有する ものの確認 ICカード、USBトークン 認証カード、OTPトークン 携帯固有ID
- 47. 47Copyright © 2012 NTT DATA Corporation 認証方式ーその他 方式 説明 特徴 リスクベース 認証 初回認証時にPC、ブラウザ、OS等の環境を記憶 。次回以降それらの環境が変更された場合、再 度より強固な（第二、第三パスワード、証明書等） 認証を実施 アタックを検出することは可能だが、アタックが 疑われる際の本人確認の手段を別途用意する 必要がある。 イメージマトリ クス認証 画面上に毎回ことなるイメージ、数字列を表示。 ユーザごとに決められたルールに基づき、その中 から情報を読み取る方式 物品、ファイルなどの配布は不要。セキュリティ 強度はほどほど USBメモリー 認証 USBメモリー（USBトークンではない）のIDを利用 して認証 USBメモリーは汎用品の利用が可能 クライアントへのソフトのインストールが必要 発番号認証 Webでのログインと並行してユーザに電話をかけ させ、サーバ側で発番号にて確認。 ユーザが手持ちの電話、携帯電話を利用でき るため、デバイスの配布などが不要。クライア ントにソフトの追加も不要 SMS認証 あらかじめ登録された携帯電話・スマートフォン へSMSによりOTPを送信。Web画面からOTPを入 力させる方式 ユーザが手持ちの電話、携帯電話を利用でき るため、デバイスの配布などが不要。クライア ントにソフトの追加も不要 その他の認証方式の例
- 48. 48Copyright © 2012 NTT DATA Corporation • 自己紹介 • 統合ID管理とは • 主要な概念の説明 • 管理の統合 – アカウント管理 – 認証 – 認可 – 属性情報管理 – ライフサイクル管理 – 証跡管理
- 49. 49Copyright © 2012 NTT DATA Corporation 認可の統合化とは ◼認可とは 利用者がシステムを利用可能か、どの範囲を利用可能かを判断すること。 ◼認可の統合化とは 業務システムにおいて個別に行われていた認可を、統合管理された情報及び統合ID 管理機能上に用意されたメカニズムに基づき、実現すること
- 50. 50Copyright © 2012 NTT DATA Corporation 認可統合の検討課題 ◼認可モデル ◼認可の分担 認可の統合においては、以下の課題を検討し、方針を策定し、システム上に実装 する必要がある。
- 51. 51Copyright © 2012 NTT DATA Corporation 認可モデル 認可を実現する代表的なメカニズムは以下のとおり。 アクセス制御マトリクス ACL (Access Control List) RBAC (Role Based Access Control)
- 52. 52Copyright © 2012 NTT DATA Corporation 認可モデル-アクセス制御マトリックス 利用者に対してリソースごとの利用権と利用レベルを割り当てるメカニズム。 利用権付与の状況が把握しやすく、利用者数やリソース数が少ない環境ではメン テナンスも容易で適しているが、利用者数、リソース数の多い環境では管理負担 が増大する。 リソース 利用者 電子メール 文書管理シス テム 人事システム 会計システム ユーザA ○ Admin × × ユーザB ○ 一般 登録・参照 × ユーザC ○ 一般 参照 ○
- 53. 53Copyright © 2012 NTT DATA Corporation ユーザとパーミッションの関係 認可モデル- ACL (Access Control List) ABAC(Attribute Based Access Control) リソースに対して「誰に」「どのような操作を許可／拒否」という属性を定義して認 可を行うメカニズム。 複数リソースに対してきめ細やかな利用権設定ができるため、リソース中心に記 述した方が効率の良いWebサーバ、ファイルサーバ、文書管理システムなどに適 しているが、複雑なルールを記述するとメンテナンス負担が大きくなる恐れあり Resources Permissions Users 人事部・田中 システム部・加藤 リソース 人事部所属 その他 許可 拒否 アクセス可能 アクセス不可 ACL
- 54. 54Copyright © 2012 NTT DATA Corporation 認可モデル-RBAC （Role Based Access Control） 特定の「役割」に対してリソースの利用権を割り当てることで認可を行うメカニズム。 役割により多くの利用者を集約して管理可能で、利用者の変化にも柔軟に対応で きるため大規模な組織でも効率的に利用権の管理が可能。また、リソースに対し て登録や参照といった操作そのものに対する認可が可能であるため、ACLよりも 厳密に認可ルールを設定可能 利用者 役割 利用権 リソース 青木 青山 人事担当 登録/参照 HRシステム 参照 営業担当小中 顧客情報参照
- 55. 55Copyright © 2012 NTT DATA Corporation 認可モデル-RBAC （Role Based Access Control） RBACにおける役割は階層構造をとることが可能（階層的RBAC） 上位の役割に割り当てられたユーザは自動的に下位の役割も付与され、下位の 役割に割り当てられた権限が自動的に上位の役割にも割り当てられるといった半 順序関係を許可することが可能。 開発者デザイナー 技術部門 従業員 利用者太郎 利用者太郎にデザイナーの役 割を付与すると自動的に技術部 門、従業員の役割も付与される 自動付与 旅費精算システム利用権 自動付与 従業員に旅費精算システム利 用権を付与すると自動的に技 術部門、開発者、デザイナー にも利用権が付与される
- 56. 56Copyright © 2012 NTT DATA Corporation 認可モデル-主要モデルの比較 モデル メリット デメリット 適した用途 アクセス制 御マトリクス 利用者ごとの権限が明確で理 解しやすい。実装が容易 利用者、リソースの増加ごとに個別 に利用権を決定する必要がある 小規模な企業 例外の管理 ACL リソースに対するアクセス権設 定を行えば良いので大規模な 組織でも効率よくルール設定が 可能 情報の増加に伴い、ACLのメンテナ ンスが困難に 効率的にACLをメンテナンスするに は、情報のグループ化、RBACとの 組み合わせなどが必要 対象リソース が多い RBAC 融通が利き、きめ細かな認可 ルール設定が可能 人・組織や認可ルールの変更 に柔軟に対応できる 組織が複雑になると理解が困難とな り、管理負担が大きい 開発コストも大きくなる 対象利用者が 多い、組織体 系が複雑 厳密なポリシーの適用、効率的な管理、拡張性などの観点から最適な方式で認可 モデルが選択され、利用する必要がある。
- 57. 57Copyright © 2012 NTT DATA Corporation 認可の分担 （１／２） ◼ 統合ID管理において全ての認可を行う システム統合ID管理 認可利用者 ◼ 認可は統合しない システム認可 利用者 システム認可 システム認可 企業として一貫性のない認可 利用者や組織に関する情報変更が 反映しきれない 認可情報管理が分散し、信頼性を 確保できない システム システム システム固有の認可ポリシーの変 更が困難 システム固有の運用パターンの適 用が困難/時間がかかる 認可はｸﾗｲｱﾝﾄｼｽﾃﾑと統合ID管理で分担の境界を適切に設定する必要がある
- 58. 58Copyright © 2012 NTT DATA Corporation 認可の分担 （２／２） クライアントシステム統合ID管理 機能 利用者 役割 グループ 利用権 役割 グループ 認可 認可 利用者はどの役割・グ ループに属するのか どの役割・グループにどの ような利用権を与えるか 以下の観点で分担を考慮 管理情報のメンテナンス システム固有のポリシー対応 分担の一例として、利用者と役割、グループの紐月を統合ID管理側で実施し、役 割グループと機能、リソースの紐付けをｸﾗｲｱﾝﾄｼｽﾃﾑで行うモデルがある。
- 59. 59Copyright © 2012 NTT DATA Corporation • 自己紹介 • 統合ID管理とは • 主要な概念の説明 • 管理の統合 – アカウント管理 – 認証 – 認可 – 属性情報 – ライフサイクル – 証跡管理
- 60. 60Copyright © 2012 NTT DATA Corporation 属性情報の統合化とは ◼属性情報管理の統合化とは アカウントとひもづけて管理する属性情報(名前、所属、メールアドレス、顔写真）を定 義し、様々な情報提供システムから取得し、統合ID管理システム内で管理し、クライア ントシステムへ提供すること。
- 61. 61Copyright © 2012 NTT DATA Corporation 属性情報管理の統合の検討課題 属性情報管理の統合においては、以下の課題を検討し、方針を策定し、システム上 に実装する必要がある。 ◼属性情報の範囲 ◼属性情報の形式
- 62. 62Copyright © 2012 NTT DATA Corporation 属性情報の範囲 システムの構築、運用コストを低減するため、統合ID管理にて管理すべき属性情報 の管理は以下の観点から決定する必要がある。 ◼情報の機敏度、セキュリティレベル ◼情報の活用度合い 統合ID管理情報提供システム クライアントシステム 人事システム等の機 密情報の確実な管理 が求められるシステム 情報提供を前提とした オープンなシステム 目的に応じて必 要な情報の範囲 を定めて取得 必要に応じて 情報提供
- 63. 63Copyright © 2012 NTT DATA Corporation 属性情報の範囲 管理対象とする属性情報として、「認可情報」、「コミュニケーション用情報」、「表示用 情報」の3種類を対象するという例 管理 対象 種類 説明 例 ○ 認可情報 各システムのアクセス制御において必要となる 情報 所属組織 所属プロジェクト 役職 ○ コミュニケー ション用情報 利用者同士、システムとのコミュニケーションに おいて必要となる人や資源の識別情報として 使用する情報 メールアドレス 電話番号 ○ 表示用情報 連携するクライアントシステム上でおもに利用 者に関する表示のために必要となる情報 氏名 役職名 所属部署名 × 人事考課情報 給与支給情報 機密性が高く、かつ、クライアントシステムが 必要とする可能性が少ないため、管理対象と すべきではない情報 振り込み口座 保有資格 保有スキル
- 64. 64Copyright © 2012 NTT DATA Corporation 属性情報の形式 （１／２） 情報提供システムから取得した情報をそのままクライアントシステムに提供すると、 文字種、字体、フォーマットなどの違いによる不具合・トラブルが発生する可能性が ある 情報提供システム （じんじシステム） クライアントシステム （Windowsサーバ）統合ID管理 髙田 「髙」が表示できない ベンダー外字 JIS X0208 （JIS第一第二水準） JIS X0208 （JIS第一第二水準） 配送
- 65. 65Copyright © 2012 NTT DATA Corporation 属性情報の形式 （２／２） 情報提供システム クライアントシステム統合ID管理 統合ID管理における共通情報の管理形式が明確化されており、システムの要求する 形式に従って適切な場所で変換され、配送される必要がある。特に外字については 開発コスト、クライアントシステムでの使い勝手の点から管理すべきではない 利用者氏名の字体など 情報の管理元が責任を 持つべき情報 電話番号やEメールなどの表示 フォーマット等複数システムに対 する共通の要件 文字種、文字コード等全システ ムに対する要件 髙田 090-9999-9999 高田 090-9999-9999 09099999999 高田
- 66. 66Copyright © 2012 NTT DATA Corporation • 自己紹介 • 統合ID管理とは • 主要な概念の説明 • 管理の統合 – アカウント管理 – 認証 – 認可 – 属性情報管理 – ライフサイクル管理 – 証跡管理
- 67. 67Copyright © 2012 NTT DATA Corporation ライフサイクル管理の統合化とは ◼ライフサイクル管理とは 利用者の状態の変化（入社、異動、退職等）に合わせてアカウントの状態を定義し、状 態、および状態の変化に合わせて様々な処理、アクセス制御をおこなうこと。 ◼ライフサイクル管理の統合化とは 統合ID管理システムにおいてアカウントの状態を定義、管理し、クライアントシステムへ 提供する。統合ID管理システム内においてもアカウントの状態の変化に伴い自動的に 処理を行うこともある。(権限の付与・はく奪、通知他）
- 68. 68Copyright © 2012 NTT DATA Corporation ライフサイクル管理の検討課題 ライフサイクル管理の統合化を行う上では以下の課題を検討する必要がある ◼ライフサイクルモデル ◼ライフサイクルの同期
- 69. 69Copyright © 2012 NTT DATA Corporation シンプルなライフサイクルモデル 利用 不可 契約終了 発行 契約更新 有効期限延長 利用 不要となったアカウントは迅速に削除し、個人情報を廃棄する（情報漏洩防止） ライフサイクル管理がシンプル（管理負担減少、開発コスト低減） 期限延長申請忘れでもアカウントが削除され、発行手続きからやり直し 利用者不在となってから発覚するインシデントの証跡トレースが困難 インシデントが疑われる際の一時的なアカウント停止が困難 削除 退社 契約開始 入社 利点 欠点 最もシンプルなライフサイクルモデルを以下に示す
- 70. 70Copyright © 2012 NTT DATA Corporation ライフサイクルモデル-詳細なモデル 停止 停止準備 利用可能 削除 猶予期限切れ ↑有効期限延長 有効期限切れ↓ 停止 停止 有効期限延長 アカウント申請 管理期間満了 以下はセキュリティの改善、利便性の向上などを実現するライフサイクルモデルの 例 復帰
- 71. 71Copyright © 2012 NTT DATA Corporation ライフサイクルモデル-詳細なモデル ステータス 説明 認証可否 アカウント 利用可能 正式なアカウントが発行された状態。アカウントの信頼性によるシス テム利用制限はなし。 （承認済） 可 有効 停止準備 一時的に当該アカウントの認証を行わない状態。（手動設定、PW入 力誤りによるロックなど） 否 有効 停止 アカウントが無効となった状態。（手動停止、再申請への猶予期限切 れなど） 否 無効 削除 物理的にアカウントが削除された状態。（期間内に正式なアカウント 申請がなかった場合、規定の管理期間が終了した場合など） ー ー 前頁のライフサイクルモデルにおける各ステータスの意味と状態の例
- 72. 72Copyright © 2012 NTT DATA Corporation ライフサイクルの同期 統合ID管理で定義したライフサイクルモデルは必ずしもクライアントシステムにおいて 実現可能ではない。統合ID管理でのアカウント状態をシステムへどう反映するかはク ライアントシステム/レポジトリごとに検討する必要がある。 統合ID管理 クライアントシステム 利用 削除 利用 一時停止 削除 停止準備 利用準備
- 73. 73Copyright © 2012 NTT DATA Corporation ライフサイクルの同期 統合ID管理 クライアントシステム 利用 削除 利用 削除 停止準備 利用準備 一時停止 PW強制変更 統合ID管理と各システムのライフサイクルの違いは状態の意味に従って適切にマッピ ングする必要がある。以下の例では一時停止、停止準備などアカウント削除には至ら ないが利用を停止させる必要がある場合はパスワードをランダムに変更することで同 様の状況を用意している。
- 74. 74Copyright © 2012 NTT DATA Corporation • 自己紹介 • 統合ID管理とは • 主要な概念の説明 • 管理の統合 – アカウント管理 – 認証 – 認可 – 共通情報 – ライフサイクル – 証跡管理
- 75. 75Copyright © 2012 NTT DATA Corporation 証跡管理の統合化とは ◼証跡管理とは 様々な目的（業務の正当性証明、システムの正常動作の確認、システムの異常動作時 の原因究明等）のため、アカウント管理、認証、認可等統合ID管理にかかわる様々な 作業、処理における実施内容、実施者を記録し、統計的な処理を行い、必要な組織に 報告すること。 ◼証跡管理の統合化とは 従来システム個別に実施されていた証跡管理をシステム全体で実施すること
- 76. 76Copyright © 2012 NTT DATA Corporation 証跡管理の検討課題 証跡管理の統合化を行う上では以下の課題を検討する必要がある ◼証跡管理の分担（業務） ◼証跡管理の分担（ID管理） ◼統合ID管理で取得する情報
- 77. 77Copyright © 2012 NTT DATA Corporation 証跡管理の分担（業務） 統合ID管理では利用者の識別、認証、認可を行うがクライアントシステムのファイル 操作や業務アプリケーションの利用などには関与しないため、統合ID管理とは別に 各システムの業務ログを統合管理する仕組みがある クライアントシステム 統合ID管理 識別・認証・認可 業務 業務 ログ統合管理 業務ログ
- 78. 78Copyright © 2012 NTT DATA Corporation 証跡管理の分担（ID管理） 必要な証跡は統合ID管理のみで取得できるとは限らない。ID管理に関する監査証 跡は統合ID管理と各システムで役割に基づいた適切な分担で効率的に記録・保管 されている必要がある。 統合ID管理 クライアントシステム アカウント、共通情報の配送 アカウント、共通情報の受信 PW変更・初期化 PW反映 認証 認証依頼 ◼ ID管理の証跡管理分担例
- 79. 79Copyright © 2012 NTT DATA Corporation 取得するログ カテゴリ 内容 アカウント管理 プロビジョニング アカウント申請、承認 認証 認証操作 パスワード同期履歴 認可 権限付与 認可ルール設定 システムへのアクセス 共通情報管理 情報収集 情報提供 メンテナンス ライフサイクル管理 アカウント生成・状態変化・削除 取得するログには監査証跡等必要な情報が漏れなく含まれている必要がある。 以下のような内容について、「いつ」 「誰が」 「何に対して」 「何をした」が確実に記 録されることが必要です。