ユーザー認証が必要なシステムが複数ある企業では，ユーザー・アカウントの管理に苦労していることだろう。異動や組織変更のたびに，それぞれのシステムでアカウントを再設定しなければならない。ユーザーの利便性も低い。複数のIDやパスワードを覚えていなくてはならず，結果的に「パスワード書いた付せん紙を画面に貼る」といった行為を招き，セキュリティを低下させることにもなる。そこで今回の記事では，ユーザー・アカウントの一元管理について，「認証ディレクトリ」を中心に解説する。
シングル・サインオンの限界
「ユーザー・アカウントの一元管理」というと，まず思い浮かぶのがシングル・サインオン（SSO）だろう。筆者は以前，この連載でSSOについて解説した。SSOは数年前から話題になっており，SSOを実現する製品は多数市場に出ている。しかしながら，筆者の予想よりは導入が進んでいないようだ。実際に導入した企業においても，「それほど便利になったとは思えない」というエンドユーザーの声を聞くことがある。
その理由として考えられるのは，SSOがWebシステムだけを対象にしていたことにある。新旧のさまざまなアプリケーション・システムを利用している環境では，すべてのユーザー認証をSSOでカバーできないのである。SSOが対象としない旧来のクライアント／サーバー（C/S）システムやWindowsログオン，電子承認などでは，SSO導入前と同様に，その度ごとユーザー認証を要求される。このため，エンドユーザーにとっては，あまり使い勝手がよくなったと感じられない。筆者自身も，一ユーザーとして同じ思いだ。
一方，社内の情報システム管理部門においても，SSOが対応していないシステムがあれば，これまで通り，異動や組織変更のたびに，そのメンテナンスに大きな労力を費やすことになる。多くの企業では，Webシステムだけを対象にしたSSOでは不十分なのである。
WebもC/Sも一元管理できる「認証ディレクトリ」
WebシステムやC/Sシステムなどが混在した環境でアカウントの一元管理をするにはどうすればよいのか。その解の一つが，これから説明する「認証ディレクトリ」である。認証ディレクトリとは，一元化したユーザー情報（ディレクトリ）とアプリケーション・システムを連携して運用する仕組みのことだ。
認証ディレクトリを実現するには，ユーザー全員のアカウント情報を一元的に管理する「統合ディレクトリ」を構築する必要がある。統合ディレクトリでは，すべてのIDやパスワードなどのアカウント情報を管理する。
ただし，統合ディレクトリを構築しなくても，ユーザー全員のアカウント情報を一元的に管理する方法はある。それが，「メタディレクトリ」だ。メタディレクトリは，いくつにも分散しているディレクトリやユーザー管理用データベースを連携した，“仮想的”な一つのディレクトリである。メタディレクトリを使っても，一元化したユーザー管理を実現できる（以降，「統合ディレクトリ」と書いた場合には，この「メタディレクトリ」も含まれると考えてほしい）。
統合ディレクトリと連携して認証を実現するのが，「クライアント・エージェント」だ。その名の通り，各クライアント・マシンにインストールしておくエージェント・プログラムである。
クライアント・エージェントは，クライアント・マシンを起動したときに一度だけユーザー認証を行う（例えば，ユーザーIDとパスワードを要求する）。そして，そのときの認証情報を記憶しておく。その後，認証を要求するアプリケーション・システムにユーザーがアクセスすると，クライアント・エージェントは，そのシステムに対応したアカウント情報（IDとパスワード）を統合ディレクトリから取得する。そして，現在アクセスしているアプリケーション・システムの認証機能にそのアカウント情報を送信する。このとき，すべてのやり取りは自動的に行われるので，ユーザーが意識する必要はない。
例えば，C/Sシステムへログインする場合には，認証ディレクトリの具体的な動作は次のようになる。
（1）クライアントPCを起動すると，あらかじめインストールしてあるクライアント・エージェント（ここでは「C/S連携プラグイン」とする）が起動され，ユーザーにIDとパスワードの入力を要求する。ユーザーがID／パスワードを入力すると，C/S連携プラグインがこの情報をキャッシュする
（2）C/Sシステムのログイン画面が表示されると，C/S連携プラグインはキャシュされている認証情報を使って，統合ディレクトリからC/Sシステムのアカウント情報を取得する。そして，その情報をC/Sシステムへ送信する。C/Sシステムからは，今までと同じようにユーザーがIDやパスワードを入力しているように見える
C/Sシステムへのログインに限らず，クライアント・エージェントの作りこみ次第でさまざまな認証が可能となる。例えば，Windowsログオンと連携させることもできる。
認証ディレクトリはWebシステム以外にも適用でき，なおかつアプリケーション・システムに手を加える必要がほとんどない。クライアントにエージェントをインストールするだけでよい。これらの利点から，企業への導入が進んでいるようである。
なお，用語の使い方はベンダーによってさまざまである。「SSO」といってもWebシステムだけを対象としているのではなく，「認証ディレクトリ」の機能を含む場合もある。製品を選択する際には注意していただきたい。
また，認証ディレクトリを“進化”させた「統合ID管理」というものもある。これは，認証ディレクトリに「ID・プロビジョニング（Provisioning）」を取り込んだものだ。ID・プロビジョニングとは，ユーザー・アカウントのライフサイクル（生成／配布／更新／廃棄あるいは失効）を管理／運用する機能のこと。この機能により，統合ID管理では，情報システムのアカウント管理を自動化できる。
導入前に“現状”を確認する
認証ディレクトリや統合ID管理でアカウントを一元管理すれば，エンドユーザーの異動や組織変更にともなうメンテナンス作業を軽減できる。また，現在はユーザー任せになっているアカウント管理に一定のポリシー（例えば，「推測しにくいパスワードを付ける」）を適用しやすくなる。加えて，アプリケーション・システムへのアクセスも一元管理できるので，「誰が／いつ／どこに」アクセスしたのかをトレースしやすくなる。これにより，今話題の“内部情報漏えい”が発生した場合にも対応できる。
このように，メリットが多い認証ディレクトリや統合ID管理ではあるが，いきなり導入することは難しい。いくつかの“ステップ”を踏む必要がある。
まずは，自社の情報セキュリティ・ポリシーに基づいてユーザー・アカウントがきちんと管理されているかどうかを確認する必要がある。次に，各アプリケーション・システムの認証機能を整理して，認証ディレクトリを実現するためのスキームを明確にする。その上で，ユーザー・アカウントを一元管理するための統合ディレクトリを設計ならびに構築する。
現在，各ベンダーでは，これまでのSSO製品の“発展系”として，統合ID管理の製品ラインアップを強化している。ID・プロビジョニングまで実現できる製品としては，Netegrityの「Identity Minder」などがある。
このような製品を活用することが近道ではあるが，統合ID管理製品が発展途上であることを考えると，ベンダーが提供するディレクトリ製品や統合ID管理製品だけでは不十分な場合も多い。自社に必要な連携プログラムなどを開発し，それを市販の統合ID管理製品と組み合わせてシステム化することが現実的だろう。
NECソフト株式会社 MCシステム事業部セキュリティ部
IT Pro Securityが提供する「今週のSecurity Check [一般編]」は，セキュリティ全般の話題（技術，製品，トレンド，ノウハウ）を取り上げる週刊コラムです。システム・インテグレーションやソフト開発を手がける「NECソフト株式会社」の，セキュリティに精通したスタッフの方を執筆陣に迎え，分かりやすく解説していただきます。
