PR

 筆者は,セキュリティ・コンサルタントを生業にしているので,さまざまな企業からセキュアなネットワークの構築に関する相談を受けている。最近では,「認証サーバー」に関する相談が増えている。その中でも多いのが,「認証サーバーの一元化(あるいは一元管理)」に関する相談だ。そこで今回の記事では,認証サーバーの一元管理の必要性ならびに課題について考えてみたい。

ネットワーク認証の“実態”

 現在,多くの企業ネットワークには,業務システム用やリモート・アクセス用などの認証サーバーが設置されているだろう。そして,システムごとに認証サーバーを用意しているケースが少なくない。このような運用では,システムを増やすたびに,そのシステム用の認証サーバーを設置することになる。

 認証サーバーの台数が少ないうちは,管理者が頑張れば対応できたので大きな問題にはならなかった。しかし最近では,管理すべき認証サーバーの台数が増えて,多くの企業管理者は悲鳴を上げていると聞く。例えば,人事異動があれば,その変更データをすべての認証サーバーへ反映させなくてはならない。

 また,データの設定方法などもシステムごとに異なるので手間がかかる。情報システム部門の負荷は大きい。この負荷は,認証サーバーの台数が増えれば増えるほど増大する。今までは,システム部門の“努力”に一任されていたが,それだけでは対応できないほどになっているのが現状だ。

 そこで検討され始めたのが,「認証サーバーの一元化」あるいは「一元管理できる認証システムの構築」である。認証に必要なデータを一元管理し,そのデータをそれぞれのシステムが参照するようにすれば,システム部門の負荷は劇的に減少するだろう。「人事異動の時期に,システム部門が徹夜でデータを入力/移行する」といった事態も避けられる。複数の認証サーバーを運用している企業では,真剣に検討すべき時期に来ていると考える。

相互接続性がカギ

 しかしながら,一元管理への移行には困難も伴う。一元管理を実現するには,まずは認証情報の“棚卸し”から始めなくてはならない。認証を適用すべきシステムを洗い出し,そのシステムの認証に必要な情報(社員番号やユーザーID,パスワード,所属部署,利用PCの管理情報など)を整理する必要がある。

 また,連携させる機器/システムの相互接続性も考慮しなければならない。スイッチやアクセス・ポイントといった機器や業務システムの認証アプリケーションなどが,(一元化した)認証サーバーときちんと連携できることを導入前に検証する必要がある。

 というのも,現状では独自の仕様に基づいた認証システムが少なくないからだ。また,ある仕様に基づいているとうたっていても,実際には,異なるベンダー同士の製品では接続できないことがよくある。このため認証サーバーの統合には,事前にユーザーやインテグレータが検証しなくてはならないのが現状なのだ。

 認証システムのベンダーには,一般的な仕様(例えばIEEE802.1X認証)に対応した製品を開発してもらいたい。併せて,他ベンダー製品との相互接続実験を積極的に実施して,その結果を公表してもらいたい。

 そうすることにより,今回取り上げた「認証サーバーの一元化」ばかりではなく,前回の記事で述べた「検疫システム」などの導入も進み,ネットワーク認証の市場も大きくなると思う。




小杉 聖一 (KOSUGI Seiichi) kosugiアットマークmxd.nes.nec.co.jp
NECソフト株式会社 プラットフォームシステム事業部
ブロードバンドシステムG


 「IT Pro Security」が提供する「今週のSecurity Check [一般編]」は,セキュリティ全般の話題(技術,製品,トレンド,ノウハウ)を取り上げる週刊コラムです。システム・インテグレーションやソフト開発を手がける「NECソフト株式会社」の,セキュリティに精通したスタッフの方を執筆陣に迎え,分かりやすく解説していただきます。