ID管理の導入は内部統制システム構築への第一歩：今、見直されるアイデンティティ管理（2/3 ページ）

[�ﾔ嶋秀規、岡本孝，ITmedia]

◆大学・文教型IDMモデル

　大学などの文教関連ユーザーでのIDM導入では、あくまでアカウント連携に主眼を置いている場合がほとんどである。これは、ユーザーの多くが毎年入学と卒業を繰り返す生徒であり、一般企業のように組織や役職によって連携条件や権限を詳細に管理する必要が少なく、メンテナンスコストの軽減を目的としているためである。システムとしてはUNIX系／Windows系に大別され、その双方でアカウントを連動するパターンが多い（図3）。

図3●大学・文教型IDMモデル

　最近のキャンパスネットワークでは、無線LANなどの認証ネットワーク用の認証サーバであるRADIUSやLDAPサーバとの連携のニーズも増えている。

◆プロバイダー型IDMモデル

　最近、特殊な例として、プロバイダーなどでの各種サーバ管理用アカウントをターゲットとしたIDM構築を検討することがある（図4）。

図4●プロバイダー型IDMモデル

　これらのケースでは、システムにかかわる管理アカウント数は少ない一方でシステム数自体が非常に多く、IDMを構築する上でコスト的に問題が生じる。ユーザー数が少ないためユーザーライセンス数は少なくて済むはずであるが、連携先システムの数だけライセンスが必要となってしまうのだ（各種製品のライセンス体系により異なる）。

　また、ライセンスよりもコストに影響するのが構築コストである。連携システムごとに、連携にかかわる開発コストが掛かる場合がほとんどだからだ。このようなケースにおけるIDM構築は、コンプライアンス対応型とするのか多段階型モデルとするのか、悩ましい問題である。したがって、システム環境とコスト、コンプライアンスの要求をかんがみてその構成を決定していくことが望ましい。

　図4中のシステム数（n）が増えると、メタディレクトリ的にIDMコアが全データを集約していったんストアする「属性情報ストア方式」では、実運用でのパフォーマンスや負荷の問題が懸念される。よって、「バーチャルアカウント方式」のIDM製品の方が有利なケースが多いと考えられる（関連記事参照）。

【コラム】IDMとアプリケーションによる権限管理の「誤解」

　一般的にIDMとアプリケーションの権限管理に関して、誤解される場合があるようだ。IDMではアプリケーション側の権限情報そのものを保持・連携するのではなく、アクセスコントロールに必要となるグルーピング条件と実際のグループ、ロールの参加動作を提供するまでが役割となる。

　例えば、ファイルサーバであればフォルダに「誰が」または「どのグループが」読み書き可能であるといった権限情報、いわゆるアクセスコントロールリスト（ACL）は、あくまでアプリケーション側で保持される。IDMは権限設定されたグループやロールへの参加条件を組織や役職などの属性情報から判定し、判定条件にマッチするグループへの参加動作をコントロールするのである（図5）。

図5●IDMとアプリケーションによる権限管理