ディレクトリサービス製品選択のポイント：ディレクトリサービスの仕組みと活用（1）

» 2000年05月22日 00時00分公開

　ITの世界では一般的に知られるようになってきた「ディレクトリサービス」。ディレクトリの機能は広範囲に渡り、その設置、選択にはさまざまな面からの検討が必要です。本稿では、その運用と選択にあたって重要となるポイントを押さえながら解説していきます。

　さらに、具体的な利用方法をいくつか示し、その中で関連項目に触れながら、ディレクトリに対する理解を深め、実際の製品の検討、導入に役立てることを目的にしています。

ディレクトリの生い立ち

　今ではかなり一般的になってきたディレクトリシステムではありますが、最初に簡単にその生い立ちから振り返ってみましょう。

図1　ディレクトリサービスに必要とされる機能を移り変わり

（1）ネットワークOSの誕生とユーザー管理

　かつてパーソナルコンピュータがスタンドアロンで使われていた時代から、ネットワークで接続されるようになった80年代ごろになると、ネットワークOSが普及していきました。当時のネットワークの目的は、ファイルとプリンタの共有がおもなものであり、当然ながら他人のファイルを読み書きする危険性が出てきました。そこでユーザーを識別して、読み書き、作成、削除などといった権限を管理する必要に迫られました。そのような背景から「ユーザーの管理」を目的としたディレクトリが使用され始めました。

　そして、複数のサーバー間でもこのディレクトリ情報を共有することで、どのサーバーにアクセスしても一貫したアクセス権限でサーバーにアクセス可能な仕組みができ上がりました。個々のサーバーごとにユーザーを管理する方法と比べ、

管理工数が減少
一貫したユーザー管理
ミスの排除

　など非常に大きなメリットを管理者は手にすることができるようになりました。

（2）アプリケーションのユーザー管理とネットワークの複雑化と

　ネットワークに対応したアプリケーションが増えてきた90年代でディレクトリを活用したもっとも一般的なアプリケーションといえば、メールサーバーではないでしょうか。メールサーバーには各ユーザーやパスワードが登録されていますので、これもディレクトリの1つといえるでしょう。

　またLANの普及にともない、ネットワークに接続する機器が増加したため、そのネットワーク資源の管理が非常に負担となってきました。そのため、ユーザーの管理に加えて、「ネットワーク資源の管理」の目的がディレクトリサービスに加わることとなりました。ユーザー管理ではパスワードなどを格納していたディレクトリですが、この場合には機器の種類、名称、各種属性などを格納します。

（3）標準化と相互運用の時代へ

　以上のように変遷を遂げたディレクトリサービスですが、最近の動きとしては「相互運用」と「標準化された認証サービス」がいちばんの話題です。

　各社からディレクトリ製品が提供されている中で、ユーザー側の切実な問題として、相互運用性が大きな問題となってきました。具体的には以下のような問題です。

ファイルサーバーとメールサーバーの2つのディレクトリを別々に管理しているため、管理者はユーザーの二重管理、エンドユーザーにとっては複数パスワード管理が重荷となっている。
企業の統合や提携にともなうディレクトリの相互運用やブラウザアクセスに対するユーザー認証のニーズが出ている。

　このような流れを踏まえて、以下の本文ではディレクトリサービスを選択、運用するうえでポイントとなる部分を列記しました。これらから、各自の環境を踏まえて製品を選択する際の勘所が見えてくるかと思います。

図2　シングルサインオンがある場合、ログインサーバーで一度認証されてしまえば、そこで管理される他のサーバーにも以後は自由にアクセスできる

ディレクトリサービスの選択のポイント

　ディレクトリサービスはネットワークにおけるインフラサービスですので、サービスが中断したり、他のディレクトリサービスへ頻繁に移行することは避けることが賢明です。そのため、構築する以前に十分に検討をすることがポイントとなってきます。ここでは、そのポイントについて解説していきます。

（1）拡張可能なオブジェクトストアとしてのディレクトリ

　ディレクトリ発展の歴史の中でユーザー管理から始まりネットワーク資源の管理が加わったように、今後もさまざまなものがディレクトリで管理されることになりうるでしょう。その場合には、これまでとは異なる種類の属性情報が格納されることが考えられます。また、ユーザー管理においても企業独自の属性情報を追加したい場合もあるでしょう。

　ディレクトリの情報はデータベースとして格納されていますが、ポイントとなるのは、このような拡張に対応できるかどうかということです。単に“拡張できる”だけでなく、簡単に設定できるか否かも確認する必要があります。

（2） LDAP対応

　LDAPとは、Lightweight Directory Access Protocolの略で、ディレクトリサービスにアクセスするプロトコルです。元々はX.500と呼ばれるディレクトリ標準のアクセスプロトコルでしたが、X.500が複雑であるため実装が難しく普及しませんでした。それを基本として文字通り軽量化しTCP/IPで動作するようにしたものがLDAPで広く受け入れられています。

　このLDAPはディレクトリサービスへの標準的なアクセス手段ですので、どのディレクトリサービスでも基本的に対応しています。ただし、LDAP v3に対応していることが必須です。v3ではUnicode対応となり、日本語を始めとしたダブルバイトキャラクタへの対応がされたためです。

（3）参照・検索機能

　エンドユーザーのもっとも一般的なディレクトリの使用方法として、メールクライアントからLDAPでディレクトリにアクセスして、ユーザーを検索することがあげられます。ここで問題となるのは、検索性能と日本語対応です。検索性能とは、単純な応答速度と“＊”や“？”を使った柔軟な検索への対応度です。企業では数万人のディレクトリになることもまれではありません。それは、退職者のエントリもセキュリティ上の理由から簡単に削除することができないからです。今後も増え続けていくことから大規模なエントリがあっても十分な検索応答速度が得られることが必要となってきます。

　また、日本語対応とは、「検索するユーザー名」に日本語を入れた場合に適切に検索ができるか、ということです。

　LDAPでは、検索条件を柔軟に設定することは技術的に可能です。例えば、「漢字の姓が山田」という条件を送信することはできますが、一般のメーラーではこのような細かな設定はできません。検索文字列として入力できるのは「名前」だけしかありません。

　このような運用を見越して、漢字姓とローマ字姓を両方検索するといった機能が入っているかどうかで使い勝手が多分に異なってきます。これはクライアントとサーバーそれぞれの実装方法により異なるため一概には判断できません。そのため事前の評価が重要です。

（4）分散データベースモデルと複製

　ディレクトリが大規模になった場合のパフォーマンスや、事業所など物理的に離れた場所が複数存在する場合のことを考慮しておく必要があります。

　具体的には、分散してディレクトリサーバーを運用できるかどうかです。1台では十分なパフォーマンスを出せなくなった場合や、わざわざ遠隔地にあるディレクトリサーバーまでアクセスする必要がないようにするためです。

　また、複製のシステムについても考慮が必要です。複数台のディレクトリサーバーに分散して運用する場合には、各ディレクトリサーバーで発生したエントリの追加、削除、変更が他のサーバーにも反映される必要があります。WANの環境で運用する場合には、コストも考慮して、複製する際にトラフィックを最小限に抑える仕組みを持っているかどうかの確認をしておきます。

（5）耐障害性

　前項で触れた複製機能や分散データベースモデルのように総合的な耐障害性とは異なり、単一のディレクトリサーバーとして如何に障害に対しての対策が整っているかということもポイントになります。具体例としては、トランザクションシステムやクラスター化がこれにあたります。

　トランザクションでは、データの読み書きの際に何らかの理由でサーバーが停止した場合に、それまでコミットしたデータを正確に書き込む作業を保証するロールバックの機能がついています。これによりデータロスや不整合といった問題を避けることができます。

（6）分散管理

　先ほどの分散データベースモデルと関連しますが、ここでは管理機能に特化した部分を指しています。組織が大規模、あるいは地理的に分散している場合などではユーザー管理を分散して行うことが一般的です。

　このような場合に、分散管理ができないようでは管理が困難になりますので確認をしておく必要があります。この内容はドメイン設計などとも関係してくるので事前の検討を要するところです。

（7）相互運用性

　単一ベンダーが提供するディレクトリサービスだけでディレクトリシステムが完結している場合は問題ないのですが、往々にして混在環境となります。このような場合の解決策としては現在いくつかの方法が提供されています。

　例えば、管理者が行った1つのディレクトリの更新内容を自動的に他のディレクトリに反映する機能や、「シングルサインオン」と呼ばれる1回だけのログイン作業で他のログイン処理を済ませてしまう機能により徐々に解消しつつあります。

　別の解決策として「メタディレクトリサービス」と呼ばれる製品が使われる場合があります。これは複数のディレクトリを束ねて、1つのディレクトリサービスとして提供する機能を持っています。いずれかの方法が用意されていない場合には管理者はディレクトリの多重管理、ユーザーは多重ログインを強いられることになり作業効率が下がってしまいますので注意が必要です。

　なお、中長期的には複製のプロトコルについて現在標準化作業が進行中であり、やがては相互運用性の問題も小さくなっていくものと期待されています。

（8）データ互換性

　企業の合併などで急きょディレクトリを他のシステムに、あるいは他のシステムから移行、統合する必要性に直面することがないとはいえません。

　そのような場合には、データの移行など膨大な作業が待っています。ディレクトリサービスでは、LDIFと呼ばれるデータのインポート、エキスポート用のファイル型式が用意されています。これはバイナリデータにも対応しています。

（9）認証サーバー機能

　ここでいう「認証」とは、これまでのアプリケーションごとの個別のユーザー認証などではなく、電子認証の標準となっているX.509証明書の発行機能などを備えたPKIシステムとしての意味での機能を指します。

　ただし、ディレクトリサーバー自体が証明書を発行する必要は必ずしもありません。VeriSignなどの認証機関から発行された証明書を格納でき、効率よく管理できれば十分な場合もあります。特にブラウザを中心としたアプリケーションの展開を考えている場合には、ユーザー認証として今後確実に必要となる機能ですので注意が必要です。

次回予告

今回は、ディレクトリの歴史と基本的な選択のポイントを説明しました。次回では、実際の運用を、ロータスドミノを例に解説していきます。　

「次回」へ

「ディレクトリサービスの仕組みと活用」バックナンバー