OpenLDAPの設計：OpenLDAPで始めるディレクトリサーバ構築（1）（3/3 ページ）

そのほかの留意事項

DIT（Directory Information Tree）設計

　ディレクトリ情報を集中管理できるディレクトリサーバですが、一方でデメリットもあります。

　ディレクトリサーバは、ユーザーID、パスワードなどのユーザー情報を一元管理しているため、ディレクトリサーバそのものに障害が発生した場合には、組織内のユーザーはコンピュータにログインすることすらできなくなる可能性があります。コンピュータを中心にして活動している企業では、企業活動が停止してしまいかねません。

　この問題に対して、OpenLDAPはレプリケーションによるディレクトリ情報の冗長化を提供しています。

　OpenLDAPのレプリケーション機能は、DIT（Directory Information Tree：ディレクトリ情報ツリー）の特定の階層以下を指定して、レプリケーションできるというものです。このため、ディレクトリ全体でなく特定の階層から下のみを冗長化させることを予定している場合、DITの設計時には、レプリケーションさせるディレクトリ情報の階層を意識して設計を進める必要があります。

図2　レプリケーションのイメージ

　また、OpenLDAPはディレクトリ情報の一部の管理を、ほかのサーバへ委譲する機能を持ちます。この機能を利用し、サーバ管理者がディレクトリ情報の管理を分担して行えるようになります。

　ディレクトリ情報を切り分ける単位はDITのサブツリーとなるため、この機能を利用する場合も、DITの設計時に、権限を委譲しディレクトリ情報を分散させる階層を意識して設計を進める必要があります。

図3　分散のイメージ

レプリケーション設計

　多くの商用ディレクトリサーバが、マスタ兼スレーブサーバとして動作することができるマルチマスタレプリケーションをサポートしているのに対し、 OpenLDAPは最新のメジャーバージョンである2.4系まで、マルチマスタを正規の機能としてサポートしていませんでした。

　現時点でStable版とされている2.3.xでは、マルチマスタ機能は試験的なサポートにとどまっています。また、2.4系でのマルチマスタ構成はまだ実績が少ないことから、現時点においてのOpenLDAPでのレプリケーション構成はシングルマスタの採用が堅実と考えられます。

　また、OpenLDAPのレプリケーション方式には、slurpd方式とsyncrepl方式の2つがあります。slurpd方式は、信頼性が低く、同期が取れなくなることがあり、その場合は手動での同期が必要になるといった理由で2.4系では削除されています。反対に、syncrepl方式は同期を取るために必要な手間が少ないというメリットがあるため、今後はこちらが主要なレプリケーション方式としての利用、開発が進むことになります。

　さらに、syncrepl方式には非同期的なタイミングで複製を行うrefreshOnlyモードと、同期的なタイミングで複製を行うrefreshAndPersistモードがあります。マスタ-スレーブ間で更新データの複製タイミングの遅れが問題となり得る場合は、refreshAndPersistモードの採用を検討することになります。

負荷への対策

　ディレクトリサーバはディレクトリ情報を一元管理しているが故に、導入前には個々のコンピュータで行われていたユーザーID、パスワードを用いた認証要求や、ユーザー名、グループ名、メールアドレスといったディレクトリ情報の検索要求が集中することになります。この結果、サーバの負荷が大きく高まる可能性もあります。

　この問題に対してOpenLDAPは、レプリケーション機能による冗長化構成を用いてのアクセス負荷の分散や、バックエンドデータベースにIndexを作成したバックエンドデータベース自体の検索処理の高速化といった対策を用意しています（このほか、LDAPクライアント側では、一度取得したディレクトリ情報を一定時間キャッシュすることにより、ディレクトリサーバへのアクセス数を抑制するといった対処が可能です）。

　クライアント数が多く、ディレクトリサーバへのアクセスが多い大規模な組織で利用する場合や、特定時間内でのアクセスが極端に多くなるような利用が見込まれる場合は、ディレクトリサーバに掛かる負荷への対策には特に注意が必要です。

セキュリティ

　ディレクトリサーバは情報を一元管理するが故に、導入前には個々のコンピュータで管理されていたパスワードなどの情報を、ディレクトリサーバは組織内のユーザー数の分、まとめて管理することになります。万一、ディレクトリサーバが侵入を受けてしまうと、組織内のさまざまな情報がまとめて流出することになりかねません。

　このリスクに対して、OpenLDAPはパスワードを平文で保存せずに、ハッシュ関数などで暗号化した状態で保存する機能を提供しています。また、OpenLDAPはクライアントからの通信経路をSSL/TLSで暗号化する機能も備えています。暗号化された経路より受け取ったパスワードを、同じハッシュ関数を利用し比較することで、すでにハッシュ化されて保存されたパスワードと一致するかを確認することができます。

　このほか、OpenLDAPでは、認証に必要な情報をOpenLDAPが持つバックエンドデータベース内に保存せずに、外部のSASL（Simple Authentication and Security Layer）データベースやKerberosデータベースに保存し、利用する機能を提供しています。ディレクトリサーバの設計時には、アクセスコントロールリストの設定も含め、他人に知られたくないパスワードなどの情報をどのように扱うかを検討する必要があります。

運用管理

　前述したとおり、組織内のディレクトリ情報を一元管理するがゆえに、万一ディレクトリサーバに障害が発生するとその影響は甚大です。管理者はサーバの運用に問題が生じていないかを把握し、問題が発生した場合にはその原因を早急に特定し、障害から復旧させるよう努める必要があります。

　一般のサーバプログラムと同様、OpenLDAPにも動作ログをsyslogへ送る機能があり、ログレベルを指定することができます。健全なディレクトリサーバの運用のため、必要な範囲のログを出力させ、管理する必要があります。

　また、一般に更新頻度が少ない情報が格納されるディレクトリサーバですが、管理者は、万一の場合に備えてディレクトリ情報のバックアップを取得する必要があります。データの保全作業は、ディレクトリサーバを適用する組織が大きくなればなるほど重要性も増す作業です。

　OpenLDAPにもバックアップ、リストアを行うコマンドが付属しています。実運用を開始する前に定期的なバックアップのスケジュールを計画し、運用条件に合わせ、これらのコマンドを利用したデータの保全策を確認しておく必要があります。