まず、「フェデレーション（Federation）」に「ネットワークドメインをまたいだ」IDの連携ソリューションとただし書きを付けると、よりイメージがつかみやすくなるだろう。

　従来の統合ID管理やSSOのソリューションは、主に社内ネットワークにある業務システムやWebアプリケーションのIDを統合管理したり、あるいは認証基盤を集約して一度のログイン操作で複数のWebアプリケーションへのアクセスを可能にしたりするものだ。

　一方クラウドサービスをはじめ、社外のサービスやアプリケーションを業務利用するケースが増えるにつれ、社内だけでなく社外のアプリケーションでもSSOを実現したいというニーズが持ち上がってきた。しかし従来のSSO製品は社内ネットワークでの利用に特化しており、インターネットの異なるネットワークドメインをまたいだSSOを実現するには適していなかった。また、他社が運営するクラウドサービスやWebアプリケーションのIDを、1つの体系に統合するのも現実的ではない。

　そこでIDを「統合」するのではなく、それぞれのID管理基盤はそのままに、ネットワークドメインをまたいで互いに“連携”させるための手段として、IDフェデレーションの技術が使われるようになった。

IDフェデレーションが求められるようになった背景

　IDフェデレーションが求められるようになった主な背景としては、Office365やGoogle Apps、salceforce.comをはじめとしたビジネス向けクラウドサービスの普及が挙げられる。これらを利用するたびに、個別にIDとパスワードを入力してログインしなければならないとなると、ユーザーの利便性が低下するだけでなく、パスワード漏れによるセキュリティリスクを招き入れかねない。

　また企業合併やM＆Aにより、異なる企業のシステムを統合する必要に迫られた場合も、ネットワークドメインをまたいだIDの管理や認証の問題が発生する。同様に、世界中に拠点や現地法人を構えるグローバル企業では通常、拠点ごとに独自にID管理基盤や認証基盤を構築・運用しているため、グループ全体でITガバナンスを効かせにくいという課題を抱えていることが多い。

　こうした課題を解決する上で、IDフェデレーションが有効であることが徐々に認知されるようになってきた。IDフェデレーションの手法を使えば、異なるクラウドサービス同士、異なる拠点同士、あるいは異なる企業同士が、それぞれのID管理基盤や認証基盤に手を加えることなくIDを連携させ、共通のID管理基盤や認証基盤を実現できる。

セキュリティプラットフォームとしてのIDフェデレーション

　IDフェデレーションを導入することで、システム管理者はより効率的にID管理を遂行できるとともに、エンドユーザーも1度のログインで複数のクラウドサービスを利用できるようになる。しかし、こうした利便性や管理性のメリットのみならず、近年ではセキュリティ対策の一環としてIDフェデレーションに着目する企業が出てきている。

　従来のセキュリティ対策は、社内ネットワークと社外ネットワークの境界にファイアウォールをはじめとした防御壁を設ける「ネットワークセキュリティ」の考え方が主流だった。しかしビジネスにおけるクラウドサービスの利用が一般的となり、モバイル端末を使って社外からインターネット経由でクラウドサービスや社内ネットワークにアクセスするワークスタイルが普及するにつれ、ネットワーク境界上での防御だけでは十分な対策が行えなくなってきた。

　そこで、ネットワークセキュリティに変わる考え方として提唱されるようになってきたのが、IDを中心としたセキュリティ対策の考え方だ。ガートナーが2012年に打ち出した「Identity is the New Perimeter」（IDこそが新たなセキュリティ境界である）というコンセプトに象徴されるように、ネットワークではなくID情報を基点としてシステム利用の認証・認可やアクセスを厳格に制御するという手法だ。これを具現化するための「クラウド時代のIDプラットフォーム技術」として、IDフェデレーションが現在大きな期待を集めている。

認証基盤としてのIDフェデレーション

　IDフェデレーションには、大きく分けて「SSO（認証基盤）」と「ID管理基盤」の2つのソリューション領域がある。このうち、早くから発展を遂げてきたのは前者のSSOの方で、「フェデレーションSSO」という名前で呼ばれることも多い。

　フェデレーションSSOが発展した最大の理由は、ネットワークドメインをまたいだ認証のための標準プロトコル「SAML（Security Assertion Markup Language）」が早くから普及し、現在ではビジネス向けクラウドサービスのほとんどがこれを実装しているためだ。このSAMLに対応したSSO製品を使うと、これらクラウドサービスをまたいだ広範なSSOを比較的簡単に実現できる。

　また現在、「OpenID Connect」と呼ばれるプロトコルも急速に普及が進んでいる。OAuthをベースにしており、Web APIとの親和性が極めて高いため、特にコンシューマー向けサービスにおいて採用される例が多い。

　従来はそれぞれのアプリケーション側でユーザーの所属＆役割情報をデータベースに持ち、ログインしてくるユーザーが営業か経理か部長か担当かデータベースを参照した上で、必要な機能メニューを表示していたため、人事異動の際にそれぞれのアプリケーションのデータベースのメンテナンスが必要になっていた。

　一方でIDフェデレーションを導入すると、ログインのタイミングでアプリケーションは属性情報が記載されたアサーション（属性情報＋署名）を受け取ることができる。そのため、その属性（営業や経理、部長や担当など）の内容を判別してメニュー表示が可能になり、データベースが不要な分、アプリケーション開発も容易になり、かつメンテナンスが楽になる。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図1　フェデレーション認証（SAMLの場合）。アサーションとは属性情報＋署名のこと（出典：ユニアデックス）

　SAMLとOpenID Connectはどちらも、連携先サービスとの間でクレデンシャル（認証情報）、つまりパスワードを直接やりとりすることはない。パスワード漏えいによるなりすまし攻撃が猛威を振るう昨今において、この点もIDフェデレーションの普及を後押ししているといえる。

ID管理基盤としてのIDフェデレーション

　一方、IDフェデレーション製品・サービスの中には、ID管理基盤の機能を含むものもある。連携先サービスのID管理基盤との間でID情報の同期を取るIDプロビジョニングの機能を有し、連携先サービスのWeb APIを介してプロセス連携することでこれを実現する。

　現時点では、クラウドサービスにおけるIDプロビジョニングの標準API仕様が普及していないため、各クラウドサービス向けに個別に連携インタフェースを実装する必要がある。しかし、ID管理基盤の機能を含むIDフェデレーション製品・サービスには連携インタフェースがあらかじめ実装されているため、ユーザーが自ら連携インタフェースを開発することなく、クラウドサービスとの間のIDプロビジョングを容易に実現できる。

　現在、製品・サービスとも、連携先クラウドサービスの数を競い合っている状況だ。ただし同期できる情報の種類や範囲などは、サービスや製品ごとに異なるため、注意が必要だ。また、連携先クラウドサービスが予告なくAPIの仕様を変更する可能性もあるため、そうした際の対応をあらかじめ考慮しておく必要もあるだろう。

日本でもようやく立ち上がってきた「IDaaS」

　近年注目を集めるIDフェデレーションの提供形態に、「IDaaS（IDentity as a Service）」がある。これは、IDフェデレーションの機能をクラウドサービスとして提供するというものだ。米国では既に多くのIDaaSが存在していたが、日本でもここに来てようやく幾つか有力なIDaaSが立ち上がってきた。例えば、IIJが2016年3月からサービス提供を開始した「IIJ IDサービス」もその1つで、SSOとID管理基盤の機能をクラウドサービスとして提供している。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図2　日々進化するクラウドへのID管理／認証基盤をIDaaSとして提供。クラウドに対してID管理／認証管理を提供するIDaaS（IDentity as a Service）。IIJがISPとしてこれまで培ってきた運用ノウハウを基に、国内の複数のデータセンター間で冗長化運用し、高い可用性とセキュリティを実現。（出典：IIJ）

　IDaaSを利用すれば、自社でIDフェデレーションのためのシステム基盤を構築・運用する必要がないため、より低コスト・短期間でIDフェデレーションを導入できるほか、連携先クラウドサービスのAPIの仕様変更や、新サービスへの対応、新技術の取り込みといった技術革新にいち早く対応してくれるメリットもある。

　またIDaaSの多くは、ベンダー独自の付加価値を提供することで他社サービスとの差別化を図っている。例えばIIJ IDサービスでは、IIJがこれまで長年に渡るデータセンター運営やクラウドサービス運営の中で培ってきたさまざまなノウハウを生かして、独自の多要素認証サービスや、高いサービス可用性などを実現しているという。

IDフェデレーション製品・サービスの選定ポイント

　ここまで紹介してきた内容を踏まえ、IDフェデレーション製品・サービスを選定する際のポイントを幾つか挙げてみたい。

自社で必要とするIDフェデレーションの機能は何か？

　まずは、自社におけるIDフェデレーションのニーズを正確に踏まえた上で、必要な機能を過不足なくそろえた製品を選びたい。IDフェデレーションの機能をうたった製品やサービスは数多く存在するが、SSOに特化したもの、ID管理に特化したもの、両方をまとめて提供するものなど、カバーする機能の範囲はそれぞれ異なる。

　例えば日本CAの「CA Single Sign-On」はSSOに特化した製品として広く知られるが、同社はID管理やAPIマネジメントの分野でも実績が豊富な製品をそろえている。SSOやID管理のプラットフォームは企業システムの中核を担う重要な仕組みだけに、既存の仕組みがある場合にはそれらとの連携の相性も考慮しながら、必要な機能を実装した個別製品をアドオンする形で追加導入するのが最もリスクの少ない方法かもしれない。

自社で利用するクラウドサービスとの連携がサポートされているか？

　IDフェデレーション導入の動機が「クラウドサービスのID連携」にある場合、導入する製品・サービスが、自社で利用するクラウドサービスとの連携をサポートしていることが大前提となる。SSO基盤として利用する場合には、SAML、OpenID Connet、WS-Federationといった標準プロトコルをどこまでサポートしているかが判断材料となろう。一方、ID管理基盤としてクラウドサービスと連携する場合には、特定のクラウドサービスとの連携がサポートされているのか、事前に個別調査する必要があるので、注意が必要だ。

オンプレ型とクラウド型のどちらを選ぶか？

　IDフェデレーションをクラウドサービスとして提供するIDaaSのメリットは先ほど紹介した通りだが、企業によってはそもそもID情報を社外に出すことがセキュリティポリシー上許されない場合もある。また、社内のWebアプリケーションと社外のクラウドサービスが混在したSSOを実現するには、オンプレミス製品を使って社内ネットワーク内にIDフェデレーション基盤を構築する方が、現時点では比較的ハードルが低い。このようにクラウド型とオンプレミス型、それぞれ一長一短があるため、どちらが自社の要件を満たす上で適しているか、慎重に見極めたい。

パスワードに代わる新たな認証方式をサポートしているか？

　一度のログインで複数のアプリケーションやサービスへアクセスできるというSSOのメリットは、利便性の面でエンドユーザーに大きなメリットをもたらす半面、セキュリティ面ではより注意が必要だ。そのため、IDフェデレーションでクラウドサービスも含めたより広範囲なSSOを実現する場合、あわせて認証手段も強化しておくことが望ましい。

　例えば、前出のIIJ IDサービスは新たにスマートフォンアプリを使った二段階認証サービスとの連携追加を予定しており、CA Single Sign-Onは生体認証を含むさまざまな多要素認証技術との連携をサポートしている。今後、パスワードに代わる認証技術が続々と実用化されるであろうことを踏まえれば、認証方式の拡張性の有無はぜひチェックしておきたい。