NTTコミュニケーションウェア（NTTコムウェア）は，約9200人の全社員にディジタル証明書を配布し，1回のログイン処理で社内システムすべてにアクセスできるシングル・サインオン・システムを構築した。ファイル単位などのアクセス制御も部分的ながら一元的に設定，管理が可能にした。頻繁な人事異動に効率よく対応するため，人事部門の業務システムとの連携も図った。ユーザーの利便性向上だけでなく，管理コストやシステム開発費も削減できた。
|
|
図1 getAccessを組み込めないアプリケーションへの対応 getAccessのランタイムを組み込めない場合には，「アクセス・フロント・サーバー」とよぶ認証プロキシを用いる。このサーバーがユーザーのアクセス権限を確認し，エンドユーザーの代わりにベーシック認証でWebサーバーにアクセスする。 |
これを実現する核となるシステムがCOM-CAである。ディジタル証明書の発行や，ユーザー認証を一元的に処理するほか，個別のシステムへのアクセス制御機能も可能な限りCOM-CAに集めた。頻繁な人事異動や組織改革に迅速かつ効率的に対応するため，ディジタル証明書の発行とアクセス制御の設定を，人事部門の業務システムと連動させた。
「極力つながない」では済まない
COM-CAを導入したきっかけは，インターネット経由で取引先のシステムと社内システムを連携するといった需要が次第に大きくなってきたことである。
従来NTTコムウェアでは，外部との接続を可能な限り制限するという方針でセキュリティ管理を進めていた。外部のWebサーバーへのアクセスや電子メールなど，一部のプロトコル以外はファイアウォールですべて遮断し，社内システムへのリモート・アクセスも厳禁していた。そのため，個別のサーバーでのセキュリティは，Webサーバーが標準で備えるベーシック認証などを利用した「最小限のアクセス制御」（NTTコムウェア ネットワークサービス事業部 ネットワークビジネス開発PJ スペシャリスト 関 信雄氏）にとどまっていた。
ところが，ファイアウォールの制限を少し緩めて外部と接続するという要望が多くなり，サーバー側のアクセス制御をより安全なものにする必要が出てきたのである。
同時に，数多いパスワードの管理の煩わしさという問題の解決も狙った。「社内システムは主要なものだけでおよそ20種類ある。部署ごとのシステムなどは，多すぎて数を把握できていない。社員全員がすべてのシステムを使うわけではないが，多い人は20個以上のサーバーにアカウントを持っている。このパスワードを全部覚えておくのはまず無理だった」（関氏）。
シングル・サインオンの入り口にディジタル証明書
|
|
図2 人事情報とCOM-CAの連携 人事部門の業務システムから，1日1回社員情報をダウンロードして，シングル・サインオン・システムのアクセス制御リストを自動的に更新する。新しい証明書は管理者が審査してから発行する。エンドユーザーは専用の端末で証明書を取得し，自分のクライアントにインストールする。 |
COM-CAではシングル・サインオンの実現に，日本エンコマース（http://www.encommerce-jp.com/）のgetAccessを導入した。ユーザーがgetAccessの管理下にあるサーバーにアクセスする場合，まずアクセス制御サーバーにログインする。すると，「アクセス・チケット」と呼ぶアクセス制御に関する情報が，クッキーとして送られてきてブラウザに組み込まれる。チケットには，対象サーバー上のアクセス可能なファイルなどのリストが記述されている。ユーザーがサーバーにアクセスした際に，サーバーにインストールしたgetAccessのモジュールが，チケットをチェックしてアクセス制御を実行する（詳細は本誌1999年12月号SURVEYを参照）。
ディジタル証明書を使うのは，getAccessのアクセス制御サーバーからアクセス・チケットを取得するときである。アクセス制御サーバーはセキュリティ上のかなめであり，簡単にログインできてしまうと大きな問題となるからだ。エンドユーザーがSSL（セキュア・ソケッツ・レイヤー）のクライアント認証機能を使ってディジタル証明書を送ると，getAccessのアクセス制御サーバーが証明書のシリアル番号を参照してユーザーを識別し，適切なチケットを発行してくれる。
簡単に組み込めないサーバーも
getAccessは「非常に良くできたシステムだ」（NTTコムウェア ネットワークサービス事業部 ネットワークビジネス開発PJ 磐城 洋介氏）という。実際，COM-CAの対象となっていた社内システムの半数程度は，比較的簡単にgetAccessのモジュールを組み込むことができた。
しかし，それ以外のシステムをgetAccessの環境に組み入れるには工夫が必要だった。ロータスのドミノ，NTTソフトウェアのWebBASE，Apacheなど，getAccessが対応していないWebサーバーを使っていたためである。
これらのシステムには「アクセス・フロント・サーバー（以下，AFサーバー）」と呼ぶ認証プロキシを設置することで対応した。AFサーバーには，getAccessを組み込んだWebサーバーと，クライアントからのアクセスを既存システムに中継するサーバー・モジュールを実装してある。このモジュールは独自に開発した。
アクセス対象のサーバーは，AFサーバーを介して通信するように配置する。AFサーバー側でgetAccessを利用したアクセス制御をかける。対象サーバー側にユーザーIDを渡す必要があるため，従来から利用しているベーシック認証を使った。AFサーバーがユーザーIDをチケットから取り出して，クライアントからのリクエストと一緒に送る（図1[拡大表示]）。
エンドユーザーがアクセスすると，AFサーバーがgetAccess環境でそのユーザーを認証し，アクセス制御情報をチェックする。アクセス対象となるファイルなどのリソースに対して，そのユーザーのアクセス権があれば，AFサーバーが目的のシステムにユーザーのリクエストを中継する。
アクセス制御の集約には限界も
AFサーバーの利用などでシングル・サインオンは実現できたが，アクセス制御まではgetAccessで一元管理できていない。getAccessはWebページやフォルダなどのURL（ユニフォーム・リソース・ロケータ）でアクセスの可否を判断しており，URL単位までしかアクセスを制御できないのである。たとえばドミノのアプリケーションでは，getAccessでサーバー全体へのアクセスの可否だけを判断し，それ以上の細かなアクセス制御は従来通りドミノ側で設定する必要がある。
「既存システムはgetAccessの利用を想定していなかったので仕方がない。今後，getAccessの利用を前提にシステムを開発するので，アクセス制御をgetAccessに任せるのも難しくない。開発コストも2～3割程度削減できるようだ」（磐城氏）という。
頻繁な人事異動に追従する
NTTコムウェアでは社員の人事異動が頻繁にあり，しかも「多いときは1000人単位で動く」（関氏）ほど大規模になることがある。このためCOM-CAでは，人事情報をgetAccessのアクセス制御情報に自動的に反映するシステムを構築している（図2[拡大表示]）。
COM-CAの社員情報管理サーバーが，人員配置などの原本を持つ人事部門の社員情報管理システムから1日1回，最新の社員情報をダウンロードする。次に前日の社員情報と比較して，更新があった社員の情報を抽出する。抽出した社員の所属部署や役職などの情報に基づいて，その社員のアクセス制御情報を更新する。
新しく入社した社員や，人事異動でメール・アドレスが変わった社員など，新しいディジタル証明書が必要なユーザーも併せて抽出する。これらのユーザーに対するディジタル証明書の発行依頼を，ディジタル証明書の発行システムに自動的に送る。
証明書の作成・配布は，セキュリティの観点から，完全には自動化していない。アクセス制御システムの更新プログラムが出した発行依頼は，CAサーバーの管理者が内容を確認して，実際の発行処理に回す。この部分は意図的に自動化しないまま残したという。「プログラムのバグなどでおかしな依頼がまぎれこむこともありうる。そこで社員番号や所属などのデータをある程度確認している」（関氏）という。シングル・サインオン・システムにアクセスする際のキーとなる証明書の発行に細心の注意を払うための措置である。
証明書を作成すると，対象ユーザーにメールで通知し，証明書を証明書配布サーバーに送る。
エンドユーザーは証明書の配布専用の端末で証明書を受け取る。全社員に配布してある社員証兼用のICカードを使って端末にログインして，自分のディジタル証明書と秘密カギを端末にダウンロードする。フロッピなどにこの証明書とカギを移して，自分のクライアント・マシンにインストールする。
証明書を発行する時点で，すでにアクセス制御システムは更新されているので，証明書をインストールすればすぐに新しいアクセス権限で社内システムを利用できる。
実際にアクセスすると，写真1[拡大表示]の左のような，証明書を選択するダイアログが表示される。自分の証明書を選んでパスワードを入力すると，ディジタル証明書がgetAccessのアクセス制御サーバーに送られる。シングル・サインオン環境であるため，ほかのサーバーにもあらためてログインすることなくアクセスできる。アクセス権のないサーバーにアクセスすると，その旨のメッセージが表示される（写真1右）。
開発費や管理コストを削減
|
|
写真1 社内システムへのアクセス 認証の必要なアプリケーションにアクセスしようとすると，証明書を選択するダイアログが表示される。Webアプリケーションはすべてシングル・サインオン環境になっているので，ブラウザを起動し直すまで再認証の必要がない（写真左）。ユーザー認証が済んでも，アクセス権限がないアプリケーションにはアクセスできない（写真右）。 |
導入の結果，システム管理に効果が出ている。「端的な例では『パスワードを忘れた』といった問い合わせが減っている」（NTTコムウェア ネットワークサービス事業部 ネットワークビジネス開発PJ 担当課長の熊谷 聡氏）。
全社員に配布したディジタル証明書の活用はまだこれからである。活用しようにも，必要なソフトがまだ市販されていないということもある。
たとえば，リモート・アクセスのユーザー認証にディジタル証明書を使える製品がなかったため開発した。暗号メールを複数のユーザーに向けて一括送信するソフトや，HTMLフォームへの入力内容にディジタル署名を付けてWebサーバーに送信するといったソフトも「探してみたが満足のいくものが見つからず，結局作らざるを得なかった」（磐城氏）という。全社員分のディジタル証明書を作ろうという段になって，大量の発行処理を連続処理できるソフトがないといった問題もあった（本誌2000年4月号，p.18のニュースを参照）。
現在はディジタル証明書の用途がWebサーバーでのユーザー認証にほぼ限定されているが，暗号メールの利用が広がれば証明書の取り扱いに新たな課題が出てくる。過去のメールを復号化したり，そのディジタル署名を検証したりするのに，古い証明書も保管しておく必要があるからだ。
これに備えて，ドメイン名に事業所名を含まないメール・アドレス体系への移行を始めている。人事異動があってもメール・アドレスが変わらず，証明書を有効期限いっぱいまで使えるので，履歴の管理が楽になる。
このほか，「証明書を再発行するとき，カギ自体を作り直すのか，あるいはディジタル署名だけを新しくするのか考える必要がある。古い証明書をエンドユーザーが簡単に管理できるようなアプリケーションも必要になりそうだ」（関氏）という。
（斉藤 国博＝kuni@nikkeibp.co.jp）
