20110929 クラウド連携において企業内ID管理基盤に求められるもの

富士榮 尚寛@phr_eidentity

IdM 実験室（http://idmlab.eidentity.jp）

アイデンティティ管理の変遷

クラウド環境におけるアイデンティティ管理

システム化のポイント

まとめ

入り乱れるキーワード•運用効率化•セキュリティ強化•法令対応／内部統制•利便性向上

運用効率化

セキュリティ強化

利便性向上

法令対応／内部統制

部門内

単一企業内

企業グループ内

企業間

企業／クラウド間クラウド／クラウド間

第1世代 第２世代 第３世代 第４世代 第５～n世代

提供者利用者

コンシューマ

エンタープライズ

サービス提供先

ニーズ発生元

ニーズ 課題 関連キーワード

プライバシ 個人情報の保護は確実か同意なき個人情報利用はないか

本人同意に基づくIdentity利用・Liberty ID-WSF・OpenID CX・OAuth

利便性 複数システムへのIdentity登録都度のログイン

グローバル・シングルサインオン・SAML-P・WS-Federation・OpenID

ハウスリストの拡充

自身の提供するサービスへの登録ユーザ数だけでは顧客母数が増えない

Identity 連携・Social Provider連携・Windows Azure AppFabric ACS・OpenID

運用効率 サービスやIdentity情報を極力自身で管理しない、もしくは自動管理する

Identity Provisioning・Federation ProviderによるJIT Provisioning・Identity Lifecycle Management

セキュリティ 外部サービスへIdentity情報を渡したくない（大切な情報は自身で管理したい）

Identity連携・オンプレミス／クラウド連携・SAML-P・WS-Federation

マッシュアップによるサービス充実

如何にセキュアかつ簡潔に API 連携を行うか

RESTful Web Service・OAuth

管理モデル（どうやって管理するか） 集中管理モデル

信頼できるソース（人事システム等）からのアイデンティティ情報の配布（プロビジョニング。ID ライフサイクル管理）

分散管理モデル アイデンティティ情報の連携／紐付け（クレームベース、フェデレーション）

利用モデル（どうやって使うか） システムを利用するため

システム毎の認証・認可

サービスを利用するため サービスが公開している API を利用する（マッシュアップ）

クラウド環境の特長• パブリックなネットワークを介してア

イデンティティ情報をやり取りする必要がある

• サービス利用者・提供者との関係にビジネス的な契約関係がある

利用者側の考慮点• サービス利用時にアイデンティティ情報

を安全にやり取りすることができるか？• 不特定多数からの脅威に対するセキュリ

ティの考慮• サービス移行などを考慮した汎用的技術

の利用• サービス提供者の信頼性

提供者側の考慮点• 主に SaaS 型サービスにおいて、他のク

ラウド・サービスとの間でアイデンティティの相互運用性を確保したサービス基盤を保持することができるか？

• アイデンティティ情報の安全性を利用者にどのように証明することができるか？

• 利用者に割り当てるアイデンティティに対してどのような権限を付与するのか？

• サービスの不正利用をどのように検知するのか？または、防ぐか？

一般的に考えられているシステム構成パターン

パターンA）クラウド・サービス側でアイデンティティ情報をすべて格納し管理する

パターンB）オンプレミスの認証機能を利用する

パターンC）オンプレミスで大部分のアイデンティティ情報を管理する

実装パターン メリット デメリット

A)認証クラウド

情報クラウド

クラウド・サービスのビルトインの機能をそのまま使うことができるため、オンプレミス側に特別なインフラの構築を含めた改変が尐ない

パブリック・ネットワークをクレデンシャル情報が流れるクラウド・サービスが攻撃された場合にアイデンティティ情報の盗難・不正利用が発生しやすいクラウド・サービスの認証機能やユーザリポジトリを利用するのでサービス提供者側の信頼性について十分考慮する必要がある

B)認証ｵﾝﾌﾟﾚﾐｽ

情報クラウド

認証がオンプレミス側で実行されるため、クレデンシャル情報がパブリック・ネットワークを流れない認証機能がオンプレミス側にあるため、クラウド・サービスが攻撃を受けた際にもなりすまし等の不正利用が発生しにくい

クラウド・サービスのユーザリポジトリを利用するのでサービス提供者側の信頼性について十分考慮する必要があるオンプレミス側にもアイデンティティ連携用のインフラを構築する必要がある

C)認証ｵﾝﾌﾟﾚﾐｽ

情報ｵﾝﾌﾟﾚﾐｽ

認証がオンプレミス側で実行されるため、クレデンシャル情報がパブリック・ネットワークを流れない認証機能がオンプレミス側にあるため、クラウド・サービスが攻撃を受けた際にもなりすまし等の不正利用が発生しにくいクラウド・サービスのユーザリポジトリをには最低限の情報しか置かないので不正利用時の影響が尐ない

アプリケーションの大幅改修が必要になる可能性が高いオンプレミス側にもアイデンティティ連携用のインフラを構築する必要がある

Google Apps

Office 365

企業での Google Apps / Gmail の利用

構成パターンB

認証

社内の Active Directory で認証

利用

社内のアイデンティティ情報を Google へプロビジョニング

インターネット社内

人事システム Forefront Identity Manager

AD FS 2.0Active Directory

Google Apps

取込み 同期（Google MA）

同期（AD MA）

ログオン

信頼

シングルサインオン

１．Outlook（Google Apps Sync）起動Google へのサインイン

２．AD FS2.0 へリダイレクト、社内 Active Directory で認証（Windows 統合認証）

３．Google アカウントへのアクセス許可

４．アイテムの同期 ５．メールの利用

コンポーネント 構成要素 構成内容

Active Directory（AD DS）

各ユーザのメールアドレス属性

Google Apps のログオンID（メールアドレス）

Active Directory Federation Service（AD FS）

証明書利用者信頼（Relying Party）

Google Apps の SSO サービス URL の設定

Google Apps SSO サービス AD FS のサービス URL の設定AD FS のトークン署名用証明書のインポート

Forefront IdentityManager

Google MA（Open Source）

Google Apps の URLアカウントの作成

AD MA アカウントの作成

参考）Google MA ： http://sourceforge.net/projects/fim2010mas/files/

企業での Office365 の利用

構成パターン

A、B のパターンで構成可能連携なし パターン A パターン B

MS Online ID の利用 MS Online ID + ディレクトリ同期

ID フェデレーション + ディレクトリ同期

適用先AD を持たない小企業

メリット社内にサーバが不要

デメリットSSO は不可ID / PWD 管理が必要

適用先中～大企業

メリットID は社内で管理可

デメリットSSO は不可PWD の2重管理社内にサーバが必要

適用先大企業

メリットSSO が可能ID / PWD を社内管理

デメリット社内にサーバが必要

利用企業

システム構成イメージ

AD

MS Online Directory Sync

FederationGateway

Active Directory Federation Server 2.0

Trust

DirectoryStore

Authentication platform

Service connector

Microsoft Office 365 Services

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Exchange Online or

SharePoint Online

Active Directory

Customer Microsoft Online Services

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Lync Online

Active Directory

Customer Microsoft Online Services

`

Client

(joined to CorpNet)

Authentication platformAD FS 2.0 Server

Exchange Online

Active Directory

Customer Microsoft Online Services

コンポーネント 構成要素 構成内容

Active Directory（AD DS）

各ユーザの UPN 属性 Office365 のログオンID（メールアドレス）※Office365 に設定したドメインと同一サフィックスが必要

Active Directory Federation Service（AD FS）

証明書利用者信頼（Relying Party）

Office365 とのフェデレーション設定（ツールで自動設定）

Office365 SSO 設定 AD FS とのフェデレーション設定（ツールで自動設定）

ディレクトリ同期ツール（ILM2007FP1）

OS Windows Server 2008（32bit版）ドメインコントローラ不可

構成 説明 注意点

ドメイン名が一致している

内部ドメイン名と外部ドメイン名（Office365用のドメイン名）が一致している

特になし

サブドメインとなっている

内部ドメイン名が外部ドメインのサブドメインとなっている例）外部：hoge.com

内部：intra.hoge.com

Office365へトップドメイン、サブドメインの順でドメイン登録する必要がある

ローカルドメイン 内部ドメイン名が外部に公開されていない例）hoge.local

ドメイン名を変更するもしくは全ユーザの UPN 属性を外部ドメインに変更する（外部ドメインの取得は必要）

シングルフォレストだが UPN サフィックスが複数

ユーザが複数の UPN 属性を保持している例）[email protected] & [email protected]

各 UPN サフィックス毎に AD FS サーバを構成する必要がある

マルチフォレスト Active Directory フォレストが複数存在する

現状サポートされていない

Forefront Identity Manager 2010 への移行 現状は Identity Lifecycle Manager 2007 FP1 ベース

64bit のみサポート

パフォーマンス向上

マルチフォレスト環境のサポート Microsoft Online MA（ディレクトリ同期ツールとしてではな

く、Forefront Identity Manager 用の MA としてリリース）

SOA への移行 ディレクトリ同期ツールではなく、クラウド上のオブジェクトを

直接管理する

論理削除のサポート

DirSync appliance

アイデンティティ情報が信頼できる正しい状態であることを担保することが必要 情報の格納先に依存する話ではないが、クラウドにおく場合は、一般により厳密な管理が必要

最適なクラウド連携のシステム構成パターンを選択することが必要 自社の状況、既存インフラへの影響度

利用するサービス自体の信頼性

プロビジョニング ユーザエントリ自体のライフサイクルを適正に管理する方法

認可とユーザプロファイル管理 ユーザ属性や権限を適正に管理する方法

認証とアイデンティティ連携 シングルサインオン方法、連携方法

コンプライアンス対応 セキュリティ・ポリシーへの対応方法 利用地域毎の対応法規制への対応方法

特に上流工程での十分な検討が重要

企画

要件定義

設計

実装・テスト

移行

評価

以下の視点でシステムを分析・設計

システム

利用者（ポリシー）

業務プロセス

プロジェクト

設計

システム調査

設計

• ID管理の目標設定

• プロジェクト推進体制確立

• スケジュールとタスクの確認

• システム棚卸

• システム問題点調査

改善計画 運用

利用者調査現状システム

可視化

• ID管理業務の流れと、対象部署と、対象システムの明確化

プロジェクト計画書

• システム利用対象者調査

• 各種規約調査

システム設計書 手順書/マニュアル

導入 運用 プロジェクト編成時の目標設定によって明確化• 問題点分析

• 管理対象システム決定

• 管理対象利用者決定

• 現状ID管理業務可視化

ゴール導入設計

業務調査

• 開発

• テスト

• ジョブ管理

• リソース監視

• システム設計

• インフラ構成設計

・・・・・・現状調査目標設定

新システム要件定義

フェーズ1 フェーズ2

要件定義/導入計画書

• 最終システムイメージ作成

• 構築ステップ決定

フェーズ3

ステップ 目標設定 現状調査 課題抽出 改善案 改善計画

視点

システム

• ID管理の目標設定

• プロジェクト推進体制確立

• スケジュールとタスクの確認

• 現状システム棚卸• ID命名規約調査

• 現状システムの問題点抽出

• リスク評価

• 管理対象システム決定

• 新システム方針決定 • 最終システムイ

メージ作成• 構築ステップ決定• 認証連携イメージ

作成• 物理構成イメージ

作成• 情報基盤グランド

デザイン作成

利用者

• 現状システム利用対象者調査

• 利用者権限調査• 各種ルール調査

• 現状システム利用対象者の権限等の問題点抽出

• リスク評価

• 管理対象利用者決定

業務プロセス

• 現状ID管理業務の流れと、対象部署と、連携システムの明確化

• 現状ID管理業務の問題点抽出

• リスク評価

• 新ID管理業務定義

成果物例プロジェクト計画書

• 現状調査シート• 問題点一覧表• 利用者一覧表• ID管理業務フロー

• 問題構造図（親和図）

• 新システム要件定義書

• 新利用者一覧表• 新ID管理業務フ

ロー

要件定義/導入計画書

運用導入設計改善計画改善策課題抽出現状調査目標設定 ゴール

システムの視点 利用するサービスの信頼性

情報を伝搬するに値するか？（SAS70 などの取得状況など）

利用するサービスの技術標準への追従状況 システムとの I/F の変化の度合（利用企業の都合ではなく、サービス提供者の都合での I/F 変更）

ベンダ・ロックインが発生しないか

利用者（ポリシー）の視点 利用者の所在地域の問題（例：Google Apps は中国から利用できない、など）

サービス提供者の所在地域の問題（例：米国愛国者法。当局へのデータ開示の可能性）

アイデンティティ管理はその目的を明確にすることが大切 時代によりニーズが変遷

ニーズにより適用する技術も変遷

適切なシステム化プロセスが必要 特に上流工程で何をするか？が成功の鍵

クラウドサービスをセキュア且つ利便性良く利用するためには適切なアーキテクチャ選択が必要 制限事項などを含め事前サービス調査が不可欠

• CSAガイドラインにおけるアイデンティティ管理の位置づけと推奨事項• アイデンティティ・プロビジョニングに関する推奨事項• 認証に関する推奨事項• ID連携に関する推奨事項• 認可とユーザプロファイル管理に関する推奨事項

• ENISAガイドラインにおけるアイデンティティ管理の位置づけと推奨事項• 権限付与、IDの割当、個人データの管理、鍵管理、暗号化、認

証、クレデンシャルの危殆化または盗難、クラウド利用者に提供されるID管理およびアクセス管理システム

• 各ガイドラインにおけるアイデンティティ管理についての考察• 「標準仕様への対応」が強調• ID連携（フェデレーション）への着目• 国内外の標準化推進団体（GICTF etc）

日本マイクロソフト エバンジェリスト 安納氏blog http://blogs.technet.com/b/junichia/

@IT記事：Windows で構築する、クラウド・サービスと社内システムの SSO 環境 http://www.atmarkit.co.jp/fwin2k/operation/adsf2sso01/adsf2sso01_01.html

FIM Tech Center http://technet.microsoft.com/ja-jp/forefront/cc470030.aspx

私のblog：IdM実験室 http://idmlab.eidentity.jp/

「クラウド環境におけるアイデンティティ管理ガイドライン」（インプレスR&D 発行。日本ネットワークセキュリティ協会 アイデンティティ管理 WG 著）

https://store.libura-pro.com/purchase/index/id/1j05hhywem8h/pageNo/1