スライド 1

Transcription

1 ID 基盤構築 101( ワン オー ワン ) 伊藤忠テクノソリューションズ株式会社富 榮尚寛 Twitter Blog : IdM 実験室 (

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

4 簡単な答えと最近の ( 個 的な ) テーマ 頑張らないシステム化 SIer 都合と われればそれまでですが 4

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 基盤導 前 問題点 - 認証機能をアプリ毎に開発している (= コスト ) - アプリ毎に認証が発 する (= 産性低下 ) NG ユーザ (PCログオン) WebアプリA Web アプリ B Web アプリ C C/S アプリ 認証機能 認証機能 認証機能 認証機能 Active Directory DataBase1 Database2 Database3 LDAP NG 問題点 - アプリ毎に認証 DBがあり DB 毎に管理者が存在する (=コスト ) - ID 情報の は 動で われている 問題点 - DBが複数存在する為 ID/Passwordがばらばらである 問題点 - アカウントに対する監査が 貫していない NG 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

10 基盤導 プロセス毎の課題 対応 企画フェーズ 10

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

15 基盤導 プロセス毎の課題 対応 要件定義フェーズ 15

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

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

18 的との対応を明確化するための 夫の例 的 課題と原因 対策へのブレークダウンと定量化 18

19 完璧さを求めない リスク発現率 インパクトに応じたシステム化 ( 網羅性 ) 網羅性システム化コストリスク発現率リスク インパクト 19

20 基盤導 プロセス毎の課題 対応 設計フェーズ 20

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

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

23 基盤導 プロセス毎の課題 対応 構築 テストフェーズ 23

24 構築 テストフェーズにおける課題 テスト出来ない! 単体では何の意味もないシステム それが ID 基盤 絶対に発 する設計バグ 製品の制限って意外なところにあったりするもの 24

25 現実解 ( 割り切り ) テスト環境の 意は確実に 企画 提案段階での重要な確認事項の つ 接続先システムについても当然必要 出来れば企画段階でプロトタイプはあった が良い に えないシステムなので イメージが湧きにくい 構築 テスト段階で仕様変更なんてざら ( 特に運 まわり ) 25

26 基盤導 プロセス毎の課題 対応 導 移 運 フェーズ 26

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

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

29 おまけ 29

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

31 まとめ 31

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

33