ところが、これらの検討を行うに当たり、システム全体に大きな問題があることが露呈しているのだ。まずは、その問題について例を挙げる。図1はよくあるパターンの企業システムの状態だ。

図1●部門ごとに運用されるシステム

　一見、問題なく稼働しそうなシステムだが、次のような問題を抱えている。

NTドメイン時代の制約から生まれた分散管理型の運用体系

　まず大きな課題は、Active Directoryの構成だ。図1のシステムでは、部門ごとにActive Directoryが運用されている。

　Active Directoryは、Windows NT時代のNTドメインから発展してきたマイクロソフトのネットワーク資源管理システムだ。ネットワーク上のWindowsクライアントとそれを利用するユーザーを管理していく上で、単なるLDAPディレクトリにとどまらない管理機能や利便性を提供する。今日では、少なくとも7割以上の企業がActive Directoryを導入しているという。インフラシステムとしてはかなりのペネトレーションだが、9割を超えるといわれるWindowsクライアントの企業導入率を考えれば、うなずける数字だ。無論、Active Directoryですべての統合管理を実現できるわけではないが、Windowsクライアントで構成されたネットワーク、それを利用するユーザーを管理する上では最も適したソリューションといえるだろう。

　Active Directoryの本来のメリットは、社内のWindowsクライアントやネットワーク上のリソース、ユーザーなどを統合的に管理できること。「1フォレスト、1ドメイン」、つまり統合された環境を構築することが理想だ。しかし、特に過去にNTドメインを導入した企業において、図1のように部門ごとに複数のActive Directoryが乱立しているケースは多い。これは、NTドメイン時代の制約に端を発している。このようなActive Directoryの乱立環境では、部門をまたがったリソース共有が困難な上、人事異動などに伴うユーザーアカウント管理も大変な作業となる。

　それでは、現在の企業システムにおいて、NTドメインが後のActive Directory構築、システム全体の運営体系に最も大きく影響したと思われる原因について考えてみる。

　まず、NTドメインのユーザー管理データベースであるSAM（Security Account Manager）データベースでは、約40Mバイトの容量でしかユーザー登録ができなかった。つまり、安全な範囲でのユーザー格納数は約1万人程度と判断された。このキャパシティーを考慮すると、事業部単位でのユーザー収容が設計的にも正しい構成だった。また、NTドメインでは、全社統合ドメインで運用してしまうと、管理権限を部門単位に限定した管理者を設定することができなかった。遠隔拠点など、部門単位での運用管理を行う場合には、部門ごとにドメインを構成する必要があったのだ。

　さらには、複数の大規模拠点を持つ企業において、NTドメインを本社中心の統合環境にした場合、拠点のDC（ドメインコントローラー）へ常にレプリケーションが行われることになるが、当時は拠点間のネットワーク回線の帯域が十分ではなく、レプリケーションで発生するトラフィックが社員の業務を阻害する要因となるケースも多かった。その回避のために、拠点単位でのドメイン構成を取る企業も少なくなかった。やがてNTドメインからActive Directoryに移行する際に、NTドメインの構成のまま単純なアップグレードを行ったユーザーも多く、NTドメイン同様に乱立した状態、つまり複数のドメインでActive Directoryが構成されているケースが増えてしまった。図1に示すシステムがまさにそれである。このNTドメインに端を発する運用体系、つまり事業部、部門単位でのシステム運用による分散管理体制により、アプリケーションの乱立、セキュリティポリシーの不整合などが起きているのだ。

アプリケーションの問題

　そして、アプリケーションの問題だ。分散管理型の運用をしてきた企業では特に顕著に表れているのがアプリケーションの乱立である。図1でも各部門にアプリケーションが構築されている様子がうかがえるが、各部門の裁量で次々とアプリケーションが導入され、その度に認可レイヤー側にACL（Access Control List：アクセス制御リスト）が増えていく。気が付くと全社でたくさんのID／パスワード管理が発生し、ユーザーも複数のIDとパスワードをアプリケーションごとに使い分けるようなことになっている。極端な例を挙げると、全社で100を超えるアプリケーションが導入され、エンドユーザーは平均して10を超えるID／パスワードを使い分ける必要性から、メモに書いてPCに張っておくといったずさんな管理をしているケースもあった。

認証システムの問題

　ID／パスワードのはんらんは、セキュリティレベルを著しく下げるだけなく、ユーザビリティと業務効率を低下させる要因となる。そこで、今度は各部門が選定したデバイス認証などの認証方式が採用される。部門Aでは指紋認証、部門BではICカード、などといった形で導入されると、認証方式ごとにユーザーデータベースが必要となる。つまり、認証レイヤーにおいても乱立が生じてしまうのだ。

認証・認可基盤の統合こそセキュリティ統制の第一歩

　例示したこれらの状況は、内部統制などの要件を検討する際に、根本的な問題として一気に露呈したというのが実情だろう。例えば業務統制において、部門をまたがる業務プロセスを定義する際、現実的には部門ごとに業務アプリケーションを使って業務遂行している場合が多いため、部門をまたがる業務プロセス＝システムにおけるワークフローの構築が必要となる。このワークフロー構築が、前述のような乱立システムにおいては困難なのである。

　また、さらに大きな課題となるのは、セキュリティ面でも数多くの問題が存在することだ。前述のID／パスワードの問題もさることながら、システムとセキュリティポリシーが部門ごとにばらばらであるために、全社的なリスクマネジメントを講じようとすると、さまざまな矛盾が生じてしまう。

　こうした問題を解決するには、以下のような4つの基盤統合を必要に応じて実施していくとよい。

（1）Active Directoryの統合

　まずActive Directoryを再構築し、「1フォレスト、1ドメイン」の環境へ移行していくといった大規模な統合作業を行う。これにより、コンピュータやユーザーの一元管理と統合的なセキュリティ管理、そしてWindows統合認証基盤の整備を実現できる。

（2）社内アプリケーション群のID統合

　Active DirectoryやアプリケーションなどのACLを有する認可システムのIDを統一することで、すべてのシステムに対してユーザーごとのアカウントを一意にする。ID統合のケースでは、ID統合製品を導入し、すべてのアプリケーションのID／パスワードを共通のものにしてしまうことが多い。統合後はユーザーアカウントの管理が一元化されるため、メンテナンス性が飛躍的に向上し、ユーザーも統一されたID／パスワードをすべてのアプリケーションに利用することができるようになる。

（3）SSOの実現（認可統合）

　アプリケーションの利用を含む業務プロセス統合において検討されるのがSSOの実現だ。ユーザーが一度の認証で複数のシステムへアクセスできるようにするのがSSOだが、大きく分けて2つの方法がある。1つはWindows統合認証を利用したSSOだ。Windows統合認証を利用可能なアプリケーションであれば、Active Directoryの認証を受けるだけでアプリケーションの認証も通過できるというものだ。これは、Active Directoryの統合環境を実現していれば、比較的低コストで実現する。

　もう1つは、Windows統合認証を利用できないアプリケーションが存在する場合は、SSO製品を導入し、認可統合のエンジンとして利用する方法だ。SSO製品自体がWindows統合認証に対応しているものもある。

（4）認証基盤統合

　認可システムのID統合やSSOなどが実現すると、アクセスセキュリティの重要性はさらに増す。（2）のように一意のID／パスワードがあれば、すべてのシステムを一気に利用できてしまうからだ。この際、よりクレデンシャル強度の高い認証手段を採用する必要がある。特に生体認証は、前回紹介したように本人認証を行う上で最適な手段といえる。また、図1のように既にさまざまな認証方式が乱立しており、継続して複数の手段を利用し続ける場合は、認可システム同様に認証管理の統合を行うべきである。

　その方法の1つは、どれか1つの認証方式に統一して全社に展開すること。そして2つ目は、認証基盤の統合だ。認証基盤統合の場合は多要素認証に対応した認証製品を利用し、いずれの場合もすべての認可システムに対して認証を提供するための統合を行う。

図2●認証・認可各基盤の統合イメージ

　図2は上記4つの「統合」を行ったシステムの概念図だが、こうした認証・認可基盤統合はコストが掛かるため、ちゅうちょする企業も少なくない。しかし、ガバナンスの実行度、永続的に発生する莫大な運用管理コストをはじき出してみれば、決して高い投資ではないはずだ。また、認可システムの統合環境において、アクセスセキュリティは重要だ。採用する認証基盤は、高いレベルでの本人認証が可能な生体認証を中心に検討することをお勧めする。