スライド 1

ID基盤構築101（ワン・オー・ワン）

伊藤忠テクノソリューションズ株式会社

富⼠榮 尚寛

Twitter : @phr_eidentity

ID基盤構築は難しい？

• 様々な要素が複雑に絡み合って取っ付きにくい？ – 技術⾯

• 様々なシステムとの接続インターフェイス – 業務APL系：Notes API、SAP API

– 基盤系：LDAP、Active Directory（ADSI） • 各種プロトコル – HTTP – SAML／OpenID Connect／OAuth – ポリシー／ガバナンス • セキュリティ • 統制・マネジメント • 経験しにくい？ – 基本的に各社1回しかシステムを⼊れない

本⽇お伝えしたいこと

• 概念 – アイデンティティとは何なのか？ – 認証とは？認可とは？ • 技術 – ID基盤に関連する技術要素の解説（SAML、OpenID Connect、OAuth） • 製品 – プロビジョニング製品、シングルサインオン製品の例・・・ • プロジェクトの進め⽅ – 標準的なプロジェクト推進の⽅法・・・

企業がID基盤を導⼊する際に

直⾯しやすい課題と現実的な解

3

（の例）

＋なんだかIdM案件って進まないよね。。

という時の対応？

簡単な答えと最近の（個⼈的な）テーマ

頑張らないシステム化

※SIer都合と⾔われればそれまでですが

アジェンダ

•

⾃⼰紹介

•

ID基盤とは

•

ID基盤導⼊プロセス毎の課題、対応

–

企画

–

要件定義

–

設計

–

構築・テスト

–

導⼊・移⾏・運⽤

•

おまけ

•

まとめ

⾃⼰紹介

• 実務 – アイデンティティ分野専任部隊（コンサルティング〜システム化） • ガバナンス／ポリシー – ⽇本ネットワークセキュリティ協会(JNSA) アイデンティティ管理WG • ID連携トラストフレームワーク • 内部統制、クラウド、グローバル等の旬なキーワードとID管理 • 技術 – カンターラ・イニシアティブ（標準技術、相互運⽤性）

– OpenIDファウンデーション（OpenID Connect / SCIM / OAuth） • ベンダーリレーションシップ

– Microsoft Most Valuable Professional (MVP) for Forefront Identity Manager (Jan 2010 – Dec 2014)

ID基盤導⼊前

WebアプリA 認証機能 DataBase1 WebアプリB 認証機能 Database2 WebアプリC 認証機能 Database3 C/Sアプリ 認証機能 Active Directory LDAP 問題点 - アプリ毎に認証DBがあり、 DB毎に管理 者が存在する（＝コスト⾼） - ID情報の⼊⼒は⼿動で⾏われている 問題点 - 認証機能をアプリ毎に開発している(=コスト⾼) - アプリ毎に認証が発⽣する（＝⽣産性低下） 問題点 - DBが複数存在する為、ID/Passwordが ばらばらである 問題点 - アカウントに対する監査が⼀貫していない

NG

NG

NG

NG

ユーザ （PCログオン）

ID基盤導⼊後

9 WebアプリA WebアプリB WebアプリC C/Sアプリ

認証機能 Active Directory ユーザ （PCログオン） 統合認証システム 統合 Database (統合 LDAP)

プロビジョニングシステム

⼈事DB 連携 メリット - 統合認証利⽤による開発標準化（＝コスト低下） - SSOの導⼊による⽣産性向上

OK

メリット - ID情報の⾃動連携 （＝運⽤コスト低減） - セキュリティ向上

OK

メリット - ユーザはシングル ID/Passwordになる - 運⽤コストの低減

OK

メリット - IDプロビジョニングシステムか ら⼀貫した監査が可能

OK

キーワード ・統合認証、認証連携 ・統合データベース ・プロビジョニング

基盤導⼊プロセス毎の課題、対応

〜企画フェーズ

企画フェーズにおける課題

• そもそもID基盤が何なのか理解できないし、企画を通す上で説明できない – 検索すると、SAML（さむる、さむえる、さむぉー）やOpenID Connect、OAuth、プロビジョニング、フェデレーションなど謎の⽤語 が出てくる – 認証とか認可とかポリシーとかトラストなどの概念的な話が多い – そもそもID（番号）とアイデンティティって何が違うの？ • そもそもID基盤の導⼊なんて誰もやりたくない – ⽬的がはっきりしない – 誰がプロジェクト・オーナー？ • 結果、予算が取れない（結構簡単に企画が頓挫・スリップする） – 値ごろ感がわからない – 業務システム側への影響（改修）が発⽣するの？

現実解（割り切り）

• テクニカル⽤語は無視、⽬的をはっきりと！ – そもそもID基盤を導⼊したい訳ではないのは真実 – ⼤体のプロジェクトはこんな理由で始まる • アプリケーションをグループ＆グローバルで共同利⽤したい • 監査に引っかかった • クラウド（Office365,GoogleApps,Salesforceなど）を使いたい • BYOD

運⽤効率化

セキュリティ 利便性向上

法令対応／

内部統制

グローバル

クラウド

モバイル

• ⽬的が明確になれば後は⾃然に – プロジェクト・オーナー：課題を抱えている部隊 • クラウドを使いたい部隊 • 監査で引っかかって困っている部隊 • アプリケーションや情報を共有したい部隊 • 複数の⽬的が絡む場合は？ – 本来⼀番いいのはトップダウンでの全社プロジェクト – スモールスタートがおススメ – 値ごろ感：ある程度は定量的に⽐較 • ⼿運⽤ vs システム、リスク vs システム化コスト • RFIレベルでもざっくり⽐較はできるはず • 本当は今後のロードマップも踏まえて検討したい

• スモールスタート（段階導⼊）のススメと留意点 – スモールスタートのメリット・デメリット • メリット – 初期コストが少なく済む – ⽴ち上げスピードが速い • デメリット – ⼿戻りが発⽣する場合も – デメリットを極⼩化するために • ⼿戻りするパターンと事前に考慮しておくべき事項 – ID体系 » グループ企業などへ展開するときに採番体系が⾜りるか？ – 接続したいシステムの技術的制約 » 利⽤インターフェイス、プロトコル、ドメイン名（特にク ラウドの場合）は⼗分検討（最悪CSV） » 技術的な制約事項であればID基盤のリプレイス時に機能追 加が可能な場合も多い

基盤導⼊プロセス毎の課題、対応

〜要件定義フェーズ

要件定義フェーズにおける課題

• そもそも要件定義フェーズは分けられるか – 委託者は総額で発注したい、受託者は刻みたい – そもそも企画フェーズで明確なRFPが書けていないから？ • 夢、膨らむ – 「ついでに」やりたいことが⼀杯出てくる – アクセス権の⾃動付け替えやグループ（ロール）管理までやりたくなる • 夢、破れる – 信頼できるIDソースなんて存在しないことがわかる – 業務システム側のインターフェイス仕様なんて誰も知らない、もしくは 業務システム側にも⼤幅な改修が必要になることが判明する – 現状のID管理業務があまりにも属⼈的なことが判明する

現実解（割り切り）

• 最初から開発プロジェクトのつもりで挑む（これは企業側へのお願い事項） – 単なる物品の調達とは違う（そのつもりでRFPも書く） • ⽬的との対応を定期的に⾏い、お花畑的な発想は早めに消し去る – プロジェクト・ルームに⽬的を張り出しておいてもやり過ぎではない？ • 100%の網羅性を持つ必要が本当にあるのか – 管理対象のグループ会社が10社あったとして3社正しく管理できれば3 割バッター。リスクを定量的に低減できる – 最初から打率をあげるよりも代替⼿段の検討をする – 徐々に打率をあげて⾏けば良い • ID管理に関する業務プロセスを厳密に定義しない – 本来はあるべきプロセスを定義した上でシステム化すべき – ⼤ごとになり先に進まず柔軟性も無くなる。後から変えられる設計の⽅ が重要（DevOps的に）

• ⽬的との対応を明確化するための⼯夫の例

網羅性 システム化コスト リスク発現率 リスク・インパクト

• 完璧さを求めない

基盤導⼊プロセス毎の課題、対応

〜設計フェーズ

設計フェーズにおける課題

• 接続先システムとのインターフェイス仕様がわからない – どうやって接続するのか、を知っている⼈の調達が難航 • プロビジョニング・インターフェイスが分からない • 認証機能の外部化が出来るかどうか分からない – ユーザ企業側担当者がそこまで深くシステムのことを知らない（導⼊時 のベンダに任せていた部分が⼤きい） • 関係者が⼀気に増え、調整が進まない – 知識レベル、技術レベルがバラバラ – 利害・予算・体制⾯での余裕もバラバラ

現実解（割り切り）

• プロジェクト設計は企画・提案時に明確化しておく – プロジェクト内で技術⾯をクリアできるように – ベンダに⽀援を受ける⼯数を⽤意しておく – 関係者の忙しい時期も明確に（本当にアサインできるか？） – 最悪、後回しにする勇気 • 万能プロトコル：CSV – とりあえずCSV⽣成装置としてのID基盤 – 共通インターフェイスとして使える – CSVの後始末は⼤事 – やり過ぎないこと（⼩規模なら⼗分まわる） • 万能プロトコル：パスワード同期 – 接続先システムの認証機能を外部に出せない場合、とりあえずパスワー ドを同期してしまう（Same Sign On≠Single Sign On）

基盤導⼊プロセス毎の課題、対応

〜構築・テストフェーズ

構築・テストフェーズにおける課題

• テスト出来ない！

– 単体では何の意味もないシステム、それがID基盤 • 絶対に発⽣する設計バグ

現実解（割り切り）

• テスト環境の⽤意は確実に – 企画・提案段階での重要な確認事項の⼀つ – 接続先システムについても当然必要 • 出来れば企画段階でプロトタイプはあった⽅が良い – ⽬に⾒えないシステムなので、イメージが湧きにくい。構築〜テスト段 階で仕様変更なんてざら（特に運⽤まわり）

基盤導⼊プロセス毎の課題、対応

〜導⼊・移⾏・運⽤フェーズ

導⼊・移⾏・運⽤フェーズにおける課題

• 移⾏？ – すでにアカウントが存在している接続先システムとの連携（整合性の確 保）は結構難しい – 認証機能の切り替えはそれなりにクリティカル（業務アプリケーション と認証システムの間での障害箇所の切り分けなど） • ⼈事データは意外と荒れている – どこかで⼈が⼊⼒している – 想定（設計）通りにデータが来続けることはありえない • ID基盤上のアイデンティティ情報も荒れてくる – 本当に接続先システムと整合性がとれているのか？ – 使わなくなった⼈の情報が残っていないか？

現実解（割り切り）

• 移⾏⽤ツール、ちょっとしたユーティリティは絶対に必要 – 設計段階では以外と⾒えないもの – 導⼊フェーズ以降でも柔軟に動けるような体制・契約が必要 • データは荒れている前提で – 基本的に製品はデータバリデーションはやってくれない – 予防と対策 • データ取り込み前のチェック • エラー発⽣後にリカバリ出来る仕組み（間違って作ってしまった、 変更してしまった、削除してしまってもアカウント単位で戻せる⼿ 順の確⽴） • 定期的な棚卸し – 監査⽬的以外に運⽤上必要なユーティリティやレポートを出せるように しておく

どこから⼿を付けるか？

• 要件定義〜設計〜開発・・・という儀式は必要か？ – もっとゆるくシステム化してもよいのでは？ – スモールスタート、プロトタイピングも⼀つの⼿段 • 最近はクラウドとの連携がメインということもあり、プロトタイプから始め る⽅がよい？ – 想像以上にクラウド・サービスの仕様が変わる速度は速く、設計しても 無駄になる可能性も – ⽬に⾒えないシステムなので、どれだけ早い段階で運⽤をイメージでき るか、がポイント • 統合ディレクトリの整備、IDライフサイクル管理の整備、認証基盤の整備 、という順番だけが解ではない – キレイなシステム化は不要 – ある程度のカバレージがあれば効果は出る – スピードの⽅が⼤切

まとめ

• ⽬的の明確化と割り切りが⼤事 – ⽬的への合致度合が低いことはしなくても良いはず – 最悪システム化できなくても本来は良いはず – 企画（案件）成⽴のための近道となる場合も • スモールスタートがオススメだが、将来は⾒据えた⽅がベター – 企業では最先端の技術は使わない（ことが多い）ので技術的に将来を⾒ 据えること⾃体がナンセンス（どのみち5年程度でID基盤システムもリ プレイスされる） – それよりも普遍的なもの（IDの利⽤範囲や、M&Aなどを含む事業のロ ードマップ）を押さえておく • やっぱり上流⼯程が⼤切 – 企画・提案の段階で押さえられるところは押さえておく（体制等） – 結局は企画・提案段階でどこまで⾒通せるか、にかかっている – イメージできない場合はプロトタイプ、PoCなども