More Related Content
![AIシステムのセキュリティ：脅威となりつつあるAIの現状と課題 [English] Security of AI Systems: The Current...](https://cdn.slidesharecdn.com/ss_thumbnails/20241023css2024-250829030738-876ce56e-thumbnail.jpg?width=560&fit=bounds)
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