第1回 クラウド・サービス連携の基本と最新トレンド：クラウド・サービスと社内システムとのID連携 最新トレンド（1/2 ページ）
IT管理者に求められるGoogle AppsやOffice 356などと社内システムとのID連携の導入。その実現方法は？ まずは最新の概念や用語、技術を解説する。
「Windowsで構築する、クラウド・サービスと社内システムのSSO環境 第1回」で述べているように、クラウド・サービスの普及により企業のIT管理者に求められる役割も変わってきた。すなわち、利便性や安全性を追求する上で、従来の企業内アイデンティティ基盤の管理に加えて、クラウド・サービスの利用に必要なアイデンティティ連携基盤（ID連携基盤）の導入についても検討を求められるようになってきた。
最近はさらに「ITコンシューマライゼーション」という、コンシューマ分野に受け入れられた製品や技術がエンタープライズ分野にも波及するという流れが進む中、特にBYOD（私物デバイス利用による仕事の効率化）というキーワードで、タブレット端末やスマートフォンなどを使った新しいワーク・スタイルが注目を集めている。それは、いつでもどこでも（私物を含む）携帯端末を積極的に活用して仕事を遂行するというもので、社内システムの利用を中心とした従来のワーク・スタイルとは大幅に異なる。その実現のために、企業のIT管理者には従来とは違った技術や手法の検討が求められている。
いつでも、どこでも仕事ができる環境を実現しようとすると、自社の業務システムの拡張だけで対応するより、すでにあるクラウド上のサービスや情報を活用する方が効率的であることは容易に想像できる。その際に必要な要件と実現方法の例をレイヤごとに挙げたのが下表である。
| レイヤ | 要件 | 実現方法の例 |
|---|---|---|
| データ | いつでも、どこからでもアクセスできること | クラウド上へのデータの配備 |
| アプリケーション／サービス | デバイス特性（タッチ、多様な解像度）に対応した操作性を持つこと | 多様なアプリケーションからアクセスできる標準APIの整備 |
| デバイス（作業環境） | デバイスをまたいだ作業環境の引き継ぎ | 端末ログインID（または端末にひも付られたID）の共通化（クラウドIDの利用） |
| BYODを実現する上での要件と実現方法の例 クラウド上のサービスや情報を活用するという前提で、要件と実現方法を整理してみた。 | ||
これらの要件を実現するためにアイデンティティ管理が果たす役割は大きい。例えばクラウド上のデータやサービスAPIへ安全にアクセスするには、前提となるユーザー認証やアクセス範囲の認可を適正に行う必要がある。またデバイスをまたいで作業環境を再現するための鍵となるのは、やはりどこからでもアクセスできるアイデンティティ情報だ。
これらの要件に対する実装はすでにコンシューマでは普及しているが、エンタープライズ分野への適用が進んでいるとはいえない。その一番の障壁となっているのはクラウド上に配置された外部のアイデンティティ情報を利用して業務を行う、という点であろう。例えばYahoo!アカウントやGoogleアカウントのように、一般に広く公開されているコンシューマ向けのアイデンティティ・プロバイダを使って業務システムや業務で利用するデバイスへログオンする、というのは管理や統制、セキュリティなどの面で不安が拭えず、まだまだ考えにくい。ただ、上記のようにクラウド・サービスを有効に活用することで、より生産性を向上させるには、ある程度は外部のアイデンティティ情報を利用せざるを得ない。そのため、どのように社内からクラウド上のアイデンティティ情報を統制・管理するのか？ という課題がIT管理者に突き付けられることになる。
そこで本連載では、社内からクラウド上のアイデンティティ・プロバイダに保管されているアイデンティティ情報を管理するための具体的な方法について、
- Office365
- Google Apps
- Salesforce.com
を例に解説する。
また、「クラウド・サービスと社内ADとのSSOを実現する」で解説した各クラウド・サービスとのシングル・サインオン（SSO）環境の構築方法を、最新情報を基に更新する。さらに、タブレット端末などから各クラウド・サービスをセキュアかつ有効に利用するための方法についても解説する。
察しのよい読者の方ならお気付きかもしれないが、上記のようなことはコンシューマ分野ではすでに実現されており、コンシューマ向けのクラウド・サービスをよく利用している方々ならすでに体験していることである。例えば社内システムをFacebookに置き換えてみると、クラウド・サービスはよくあるFacebookアカウントでログインするサービス、そしてユーザーはPCからでもスマートフォンからでも区別なくそれらのサービスへアクセスする、といった具合だ。そう考えれば、理解しやすいかもしれない。
とはいえ、社内に上記のような仕組みを導入するにあたり、理解すべき用語や基本的な技術要素については広く理解されているわけではない。そこで第1回の本稿では最新トレンドを交えつつ、それらの概念・用語・技術要素を解説する。連携を実現する具体的な方法については、第2回以降で解説する。
アイデンティティ連携技術の基本的な構成要素
アイデンティティ連携（ID連携）の最新トレンドやその実現方法を解説する前に、理解が深まるように「アイデンティティ連携」という言葉を整理してみたい。そのために、まずアイデンティティを管理するとはどのようなことなのか、整理しておく。
●アイデンティティ管理における3つの「A」
一般にアイデンティティ管理とは、以下の3つの「A」を管理することだといわれている。
| 構成要素 | 意味 |
|---|---|
| 認証（Authentication） | ユーザーの正当性を検証すること（ユーザーがデジタル・アイデンティティ＊1を利用する権利があることを検証する） |
| 認可（Authorization） | 認証されたユーザーに権限を与えること（デジタル・アイデンティティに何を許可するかを決定する） |
| 属性（Attribute） | ユーザーを構成する情報 （なぜデジタル・アイデンティティを構成するかを決定する） |
| アイデンティティ管理における3つの「A」 ＊1 デジタル・アイデンティティ： デジタル空間（ネットワーク、コンピュータシステムなど）での人格 | |
各構成要素の管理項目を5W1Hで簡単に整理した例を以下に挙げる。実際にアイデンティティ管理システムを構築する際は、下記のように要件やスコープを整理することが望ましい。
| 5W1H | 認証 | 認可 | 属性 |
|---|---|---|---|
| Who（どのシステムが） | 統合認証システム | 各サービス・システム | ID管理システム |
| What（何を） | 各サービス・システムから認証要求のあったユーザー | アクセスしてきたユーザー | 社内システム利用者の姓、名、部署名、メール・アドレス |
| When（どのタイミングで） | 各サービス・システムからの要求ごと | 認証完了後 | 人事システム上のデータに更新ごと |
| Where（どのシステムで） | 統合認証システム | 各サービス・システム | 各サービス・システム |
| Why（なぜ） | 成りすましを防止するため | 情報漏えいを防止するため | 正しく認可するため |
| How（どのように） | IDとパスワードの一致確認 | ユーザーの部署名属性に入っている値と合致したデータのみにアクセスを許可 | 各サービス・システム上のデータベースを更新 |
| アイデンティティ管理における管理項目を整理した例 例えばシングル・サインオンを実現するには、「認証」の「Where」を1つのシステムにまとめることが必要になる。 | |||
●アイデンティティの連携とは
「A」から始まる3つの構成要素のうち、シングル・サインオンを実現するための要素技術である認証連携（フェデレーション）については、「Windowsで構築する、クラウド・サービスと社内システムのSSO環境 第2回 クラウド・コンピューティング時代の認証技術」で解説した。本稿ではフェデレーションに加えて、残る2つの「A」（認可、属性）の連携についても解説する。
まず、アイデンティティ連携とは具体的に何を連携するのか、という観点で3つの構成要素ごとにまとめると下記のようになる。
| 構成要素 | 連携される情報 | 連携手法（プロトコル）の例 |
|---|---|---|
| 認証 | 認証情報（どこで、いつ、誰が、どうやって、どのサービスに対して認証されたのか？） | SAML WS-Federation OpenID |
| 認可 | 認可情報（誰に対して、どんなアクセスが認可されたのか？） | XACML OAuth |
| 属性 | 属性情報（属性名と属性値） | SPML SCIM |
| アイデンティティ連携において連携される情報と代表的な連携手法 各プロトコルの詳細については、すぐ後で紹介している解説記事を参照していただきたい。 | ||
各プロトコルの詳細は下記の解説記事が詳しいので参照していただきたい。
- SAML
強力なSSOを実現するXML認証・認可サービス（SAML）（Security&Trustフォーラム） - XACML
PKIとPMIを融合させる次世代言語XACML（Security&Trustフォーラム） - OAuth
「OAuth」の基本動作を知る（Security&Trustフォーラム） - SCIM
SCIM（Simple Cloud Identity Management） − 情報セキュリティ技術動向調査（2011 年上期）（IPA）
それぞれの情報の連携（システム間で受け渡し）を行うことで、分散したシステムが協調してセキュアで利便性の高い、大規模のネットワーク・システムを構成するのである。例えば、認証情報を受け渡すことで、各システムは個別に認証機能を保持する必要はなくなり、シングル・サインオンを実現できる。また認可情報を連携することで、各リソースが個別にアクセス権限を付与する必要もなくなる。さらに、属性情報を安全に受け渡すことにより、各サービスが利用者の情報を個別に管理する必要もなくなり、不要なアカウント情報がリアルタイムに消去されるなど不正アクセスの防止にも役立つ環境が構成できる。
■更新履歴
【2013/06/20】表「アイデンティティ管理における3つの『A』」において、当初「認証」のことを次のように説明していました：
「ユーザーが本人であることを証明すること（デジタル・アイデンティティとリアル・アイデンティティのひも付けを行う）」
しかし身元確認と認証は別のプロセスなので、認証で「本人であることを証明」するわけではありません。そこで次のように説明を修正しました：
「ユーザーの正当性を検証すること（ユーザーがデジタル・アイデンティティを利用する権利があることを検証する）」
以上、お詫びして訂正させていただきます。
Copyright© Digital Advantage Corp. All Rights Reserved.