Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Id基盤構築101
Ähnlich wie Id基盤構築101 (20)
Mehr von Naohiro Fujie
Mehr von Naohiro Fujie (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (7)
Id基盤構築101
- 1. ID基盤構築101（ワン・オー・ワン） 伊藤忠テクノソリューションズ株式会社 富士榮 尚寛 Twitter : @phr_eidentity Blog : IdM実験室（http://idmlab.eidentity.jp）
- 2. ID基盤構築は難しい？ • 様々な要素が複雑に絡み合って取っ付きにくい？ – 技術面 • 様々なシステムとの接続インターフェイス – 業務APL系：Notes API、SAP API – 基盤系：LDAP、Active Directory（ADSI） • 各種プロトコル – HTTP – SAML／OpenID Connect／OAuth – ポリシー／ガバナンス • セキュリティ • 統制・マネジメント • 経験しにくい？ – 基本的に各社1回しかシステムを入れない 2
- 3. 本日お伝えしたいこと • • • • 概念 – アイデンティティとは何なのか？ – 認証とは？認可とは？ 技術 – ID基盤に関連する技術要素の解説（SAML、OpenID Connect、OAuth） 製品 – プロビジョニング製品、シングルサインオン製品の例・・・ プロジェクトの進め方 – 標準的なプロジェクト推進の方法・・・ 企業がID基盤を導入する際に 直面しやすい課題と現実的な解 （の例） ＋なんだかIdM案件って進まないよね。。 という時の対応？ 3
- 5. アジェンダ • 自己紹介 • ID基盤とは • ID基盤導入プロセス毎の課題、対応 – 企画 – 要件定義 – 設計 – 構築・テスト – 導入・移行・運用 • おまけ • まとめ 5
- 6. 自己紹介 • 実務 – アイデンティティ分野専任部隊（コンサルティング～システム化） • ガバナンス／ポリシー – 日本ネットワークセキュリティ協会(JNSA) アイデンティティ管理WG • ID連携トラストフレームワーク • 内部統制、クラウド、グローバル等の旬なキーワードとID管理 • 技術 – カンターラ・イニシアティブ（標準技術、相互運用性） – OpenIDファウンデーション（OpenID Connect / SCIM / OAuth） • ベンダーリレーションシップ – Microsoft Most Valuable Professional (MVP) for Forefront Identity Manager (Jan 2010 – Dec 2014) 6
- 7. ID基盤とは 7
- 8. ID基盤導入前 問題点 - 認証機能をアプリ毎に開発している(=コスト高) - アプリ毎に認証が発生する（＝生産性低下） ユーザ （PCログオン） NG WebアプリB WebアプリC C/Sアプリ 認証機能 Active Directory WebアプリA 認証機能 認証機能 認証機能 DataBase1 Database2 Database3 問題点 NG - アプリ毎に認証DBがあり、 DB毎に管理 者が存在する（＝コスト高） - ID情報の入力は手動で行われている LDAP 問題点 NG - DBが複数存在する為、ID/Passwordが ばらばらである 問題点 NG - アカウントに対する監査が一貫していない 8
- 9. ID基盤導入後 メリット OK - 統合認証利用による開発標準化（＝コスト低下） - SSOの導入による生産性向上 ユーザ （PCログオン） WebアプリA WebアプリB キーワード ・統合認証、認証連携 ・統合データベース ・プロビジョニング WebアプリC C/Sアプリ 認証機能 Active Directory 人事DB 連携 統合認証システム 統合 Database (統合 LDAP) プロビジョニングシステム メリット OK - ユーザはシングル ID/Passwordになる - 運用コストの低減 メリット OK - ID情報の自動連携 （＝運用コスト低減） - セキュリティ向上 メリット OK - IDプロビジョニングシステムか ら一貫した監査が可能 9
- 11. 企画フェーズにおける課題 • そもそもID基盤が何なのか理解できないし、企画を通す上で説明できない – 検索すると、SAML（さむる、さむえる、さむぉー）やOpenID Connect、OAuth、プロビジョニング、フェデレーションなど謎の用語 が出てくる – 認証とか認可とかポリシーとかトラストなどの概念的な話が多い – そもそもID（番号）とアイデンティティって何が違うの？ • そもそもID基盤の導入なんて誰もやりたくない – 目的がはっきりしない – 誰がプロジェクト・オーナー？ • 結果、予算が取れない（結構簡単に企画が頓挫・スリップする） – 値ごろ感がわからない – 業務システム側への影響（改修）が発生するの？ 11
- 12. 現実解（割り切り） • テクニカル用語は無視、目的をはっきりと！ – そもそもID基盤を導入したい訳ではないのは真実 – 大体のプロジェクトはこんな理由で始まる • アプリケーションをグループ＆グローバルで共同利用したい • 監査に引っかかった • クラウド（Office365,GoogleApps,Salesforceなど）を使いたい • BYOD 運用効率化 グローバル セキュリティ 利便性向上 クラウド 法令対応／ 内部統制 モバイル 12
- 13. • 目的が明確になれば後は自然に – プロジェクト・オーナー：課題を抱えている部隊 • クラウドを使いたい部隊 • 監査で引っかかって困っている部隊 • アプリケーションや情報を共有したい部隊 • 複数の目的が絡む場合は？ – 本来一番いいのはトップダウンでの全社プロジェクト – スモールスタートがおススメ – 値ごろ感：ある程度は定量的に比較 • 手運用 vs システム、リスク vs システム化コスト • RFIレベルでもざっくり比較はできるはず • 本当は今後のロードマップも踏まえて検討したい 13
- 14. • スモールスタート（段階導入）のススメと留意点 – スモールスタートのメリット・デメリット • メリット – 初期コストが少なく済む – 立ち上げスピードが速い • デメリット – 手戻りが発生する場合も – デメリットを極小化するために • 手戻りするパターンと事前に考慮しておくべき事項 – ID体系 » グループ企業などへ展開するときに採番体系が足りるか？ – 接続したいシステムの技術的制約 » 利用インターフェイス、プロトコル、ドメイン名（特にク ラウドの場合）は十分検討（最悪CSV） » 技術的な制約事項であればID基盤のリプレイス時に機能追 加が可能な場合も多い 14
- 16. 要件定義フェーズにおける課題 • そもそも要件定義フェーズは分けられるか – 委託者は総額で発注したい、受託者は刻みたい – そもそも企画フェーズで明確なRFPが書けていないから？ • 夢、膨らむ – 「ついでに」やりたいことが一杯出てくる – アクセス権の自動付け替えやグループ（ロール）管理までやりたくなる • 夢、破れる – 信頼できるIDソースなんて存在しないことがわかる – 業務システム側のインターフェイス仕様なんて誰も知らない、もしくは 業務システム側にも大幅な改修が必要になることが判明する – 現状のID管理業務があまりにも属人的なことが判明する 16
- 17. 現実解（割り切り） • 最初から開発プロジェクトのつもりで挑む（これは企業側へのお願い事項） – 単なる物品の調達とは違う（そのつもりでRFPも書く） • 目的との対応を定期的に行い、お花畑的な発想は早めに消し去る – プロジェクト・ルームに目的を張り出しておいてもやり過ぎではない？ • 100%の網羅性を持つ必要が本当にあるのか – 管理対象のグループ会社が10社あったとして3社正しく管理できれば3 割バッター。リスクを定量的に低減できる – 最初から打率をあげるよりも代替手段の検討をする – 徐々に打率をあげて行けば良い • ID管理に関する業務プロセスを厳密に定義しない – 本来はあるべきプロセスを定義した上でシステム化すべき – 大ごとになり先に進まず柔軟性も無くなる。後から変えられる設計の方 が重要（DevOps的に） 17
- 19. • 完璧さを求めない – リスク発現率 × インパクトに応じたシステム化（網羅性） 網羅性 システム化コスト リスク発現率 リスク・インパクト 19
- 21. 設計フェーズにおける課題 • 接続先システムとのインターフェイス仕様がわからない – どうやって接続するのか、を知っている人の調達が難航 • プロビジョニング・インターフェイスが分からない • 認証機能の外部化が出来るかどうか分からない – ユーザ企業側担当者がそこまで深くシステムのことを知らない（導入時 のベンダに任せていた部分が大きい） • 関係者が一気に増え、調整が進まない – 知識レベル、技術レベルがバラバラ – 利害・予算・体制面での余裕もバラバラ 21
- 22. 現実解（割り切り） • プロジェクト設計は企画・提案時に明確化しておく – プロジェクト内で技術面をクリアできるように – ベンダに支援を受ける工数を用意しておく – 関係者の忙しい時期も明確に（本当にアサインできるか？） – 最悪、後回しにする勇気 • 万能プロトコル：CSV – とりあえずCSV生成装置としてのID基盤 – 共通インターフェイスとして使える – CSVの後始末は大事 – やり過ぎないこと（小規模なら十分まわる） • 万能プロトコル：パスワード同期 – 接続先システムの認証機能を外部に出せない場合、とりあえずパスワー ドを同期してしまう（Same Sign On≠Single Sign On） 22
- 25. 現実解（割り切り） • テスト環境の用意は確実に – 企画・提案段階での重要な確認事項の一つ – 接続先システムについても当然必要 • 出来れば企画段階でプロトタイプはあった方が良い – 目に見えないシステムなので、イメージが湧きにくい。構築～テスト段 階で仕様変更なんてざら（特に運用まわり） 25
- 27. 導入・移行・運用フェーズにおける課題 • 移行？ – すでにアカウントが存在している接続先システムとの連携（整合性の確 保）は結構難しい – 認証機能の切り替えはそれなりにクリティカル（業務アプリケーション と認証システムの間での障害箇所の切り分けなど） • 人事データは意外と荒れている – どこかで人が入力している – 想定（設計）通りにデータが来続けることはありえない • ID基盤上のアイデンティティ情報も荒れてくる – 本当に接続先システムと整合性がとれているのか？ – 使わなくなった人の情報が残っていないか？ 27
- 28. 現実解（割り切り） • 移行用ツール、ちょっとしたユーティリティは絶対に必要 – 設計段階では以外と見えないもの – 導入フェーズ以降でも柔軟に動けるような体制・契約が必要 • データは荒れている前提で – 基本的に製品はデータバリデーションはやってくれない – 予防と対策 • データ取り込み前のチェック • エラー発生後にリカバリ出来る仕組み（間違って作ってしまった、 変更してしまった、削除してしまってもアカウント単位で戻せる手 順の確立） • 定期的な棚卸し – 監査目的以外に運用上必要なユーティリティやレポートを出せるように しておく 28
- 29. おまけ 29
- 30. どこから手を付けるか？ • 要件定義～設計～開発・・・という儀式は必要か？ – もっとゆるくシステム化してもよいのでは？ – スモールスタート、プロトタイピングも一つの手段 • 最近はクラウドとの連携がメインということもあり、プロトタイプから始め る方がよい？ – 想像以上にクラウド・サービスの仕様が変わる速度は速く、設計しても 無駄になる可能性も – 目に見えないシステムなので、どれだけ早い段階で運用をイメージでき るか、がポイント • 統合ディレクトリの整備、IDライフサイクル管理の整備、認証基盤の整備 、という順番だけが解ではない – キレイなシステム化は不要 – ある程度のカバレージがあれば効果は出る – スピードの方が大切 30
- 31. まとめ 31
- 32. まとめ • 目的の明確化と割り切りが大事 – 目的への合致度合が低いことはしなくても良いはず – 最悪システム化できなくても本来は良いはず – 企画（案件）成立のための近道となる場合も • スモールスタートがオススメだが、将来は見据えた方がベター – 企業では最先端の技術は使わない（ことが多い）ので技術的に将来を見 据えること自体がナンセンス（どのみち5年程度でID基盤システムもリ プレイスされる） – それよりも普遍的なもの（IDの利用範囲や、M&Aなどを含む事業のロ ードマップ）を押さえておく • やっぱり上流工程が大切 – 企画・提案の段階で押さえられるところは押さえておく（体制等） – 結局は企画・提案段階でどこまで見通せるか、にかかっている – イメージできない場合はプロトタイプ、PoCなども 32