Directory Service

ディレクトリサービス（Directory Service）とは、ネットワーク上のユーザー、グループ、デバイス、アプリケーションなどのリソース情報を階層構造で一元管理し、高速な検索・参照を可能にするサービスです。組織内のID管理やアクセス制御の基盤として、認証・認可プロセスの中核を担います。

LDAP（Lightweight Directory Access Protocol）は、ディレクトリサービスにアクセスするための標準プロトコルであり、ITU-T勧告X.500のDAP（Directory Access Protocol）を軽量化した規格です。TCP/IPネットワーク上で動作し、ディレクトリ情報の検索・追加・変更・削除といった操作を効率的に行うことができます。現在、ほぼすべてのディレクトリサービス製品がLDAPをサポートしています。

ディレクトリサービスは企業のITインフラにおいて不可欠な存在であり、Active Directory Domain Services（AD DS）やOpenLDAPなどの実装が広く利用されています。しかし、ディレクトリサービスには組織の全ユーザー情報や認証情報が集約されるため、LDAPインジェクションや不正アクセスによる情報漏洩リスクが常に存在し、適切なセキュリティ対策が不可欠です。

X.500とLDAPの関係

X.500はITU-TとISOが策定したディレクトリサービスの国際標準規格であり、ディレクトリ情報のデータモデルやアクセスプロトコル（DAP）を定義しています。しかし、X.500のDAPはOSI参照モデル全層のプロトコルスタックを必要とし、実装が複雑で重量級でした。

この課題を解決するために、1993年にミシガン大学でLDAPが開発されました。LDAPはTCP/IP上で直接動作し、X.500のデータモデル（DN: Distinguished Name による階層構造）を継承しつつ、プロトコルを大幅に簡素化しました。現在はLDAP v3（RFC 4511）が標準として広く利用されています。

LDAPのデータモデルと構造

LDAPのディレクトリはDIT（Directory Information Tree）と呼ばれるツリー構造で情報を格納します。各ノードはエントリと呼ばれ、DN（Distinguished Name）で一意に識別されます。例えば「cn=tanaka,ou=sales,dc=example,dc=com」のように、ツリーの末端から根に向かって構成要素を記述します。

各エントリは属性（Attribute）と値（Value）のペアで構成されます。属性の種類や必須/任意の区分はスキーマで定義され、オブジェクトクラスによってエントリの種別（ユーザー、グループ、組織単位など）が決まります。この柔軟なスキーマ設計により、組織固有の情報も管理可能です。

Active Directory Domain Services（AD DS）との関係

Active Directory Domain Services（AD DS）はMicrosoftが開発したディレクトリサービスであり、Windows Server環境における認証・認可・ポリシー管理の中核です。AD DSはLDAPを主要なアクセスプロトコルとして採用しつつ、Kerberos認証、グループポリシー（GPO）、DNSとの統合など、独自の機能を大幅に追加しています。

AD DSは単なるLDAPサーバーではなく、ドメインコントローラー間のマルチマスターレプリケーション、フォレスト・ドメイン・OU（組織単位）による多層管理、信頼関係（Trust）による組織間連携など、エンタープライズ規模の要件に対応する包括的なディレクトリサービスです。

OpenLDAPとその他の実装

OpenLDAPはオープンソースのLDAPサーバー実装であり、Linux/Unix環境で広く利用されています。軽量で柔軟なカスタマイズが可能であり、バックエンドデータベースの選択（MDB、BDB等）やオーバーレイ機構によるモジュール拡張をサポートしています。

その他の主要な実装としては、Red Hatが提供する389 Directory Server、OracleのOracle Unified Directory、クラウドネイティブなAzure Active Directory Domain Servicesなどがあります。近年ではクラウドベースのディレクトリサービスが増加しており、オンプレミスとの連携（ハイブリッド構成）が重要な設計ポイントとなっています。

LDAPインジェクションの脅威

LDAPインジェクションは、Webアプリケーションがユーザー入力を適切にサニタイズせずにLDAPクエリに組み込むことで発生する脆弱性です。SQLインジェクションと同様の原理で、攻撃者がLDAPフィルタ式に悪意のある文字列を挿入し、認証バイパスや不正な情報取得を行います。

例えば、ログインフォームのユーザー名に「*)(uid=*))(|(uid=*」のような文字列を入力することで、LDAPフィルタの論理構造を改変し、全ユーザーの認証をバイパスできる可能性があります。ディレクトリには組織全体のユーザー情報が格納されているため、被害は甚大です。

LDAPS・StartTLSによる通信の暗号化

標準のLDAPはポート389で平文通信を行うため、通信経路上でのパスワードや個人情報の傍受リスクがあります。LDAPS（LDAP over SSL/TLS）はポート636を使用してSSL/TLSで通信全体を暗号化する方式であり、StartTLSはポート389上でTLS接続にアップグレードする方式です。

いずれの方式も、LDAPバインド（認証）時のパスワードやディレクトリデータの機密性を保護するために必須です。特にWAN経由でのレプリケーションやリモートアクセス環境では、暗号化されていない通信は絶対に許容してはなりません。

• 01
  LDAPインジェクション対策の徹底：ユーザー入力をLDAPクエリに組み込む際は、必ずLDAP特殊文字（*, (, ), \, NULなど）のエスケープ処理を行ってください。パラメータ化クエリやLDAPフレームワーク標準のエスケープ関数を使用し、入力値の検証とサニタイズを多層的に実施しましょう。
• 02
  LDAPS/StartTLSによる通信暗号化の強制：すべてのLDAP通信をLDAPS（ポート636）またはStartTLSで暗号化し、平文のLDAP（ポート389）を無効化してください。サーバー証明書の検証を省略せず、信頼された認証局から発行された証明書を使用することが重要です。
• 03
  匿名バインドと未認証バインドの無効化：ディレクトリサーバーの匿名アクセス（Anonymous Bind）を無効にし、すべてのアクセスに認証を要求してください。特にインターネットに公開されるLDAPサーバーでは、匿名バインドによるディレクトリ列挙攻撃のリスクが極めて高くなります。
• 04
  最小権限の原則に基づくアクセス制御：LDAP ACL（Access Control List）を適切に設定し、各アカウントやアプリケーションが必要最低限のディレクトリ情報のみにアクセスできるよう制限してください。サービスアカウントには読み取り専用の権限を付与し、書き込み権限は管理者に限定しましょう。
• 05
  ディレクトリサーバーの監査ログ有効化：LDAP操作（バインド、検索、変更、削除）の監査ログを有効化し、不審なアクセスパターン（大量の検索クエリ、権限昇格の試行、深夜の管理者ログインなど）をSIEMで監視してください。
• 06
  レプリケーションとバックアップの安全確保：ドメインコントローラー間のレプリケーション通信を暗号化し、ディレクトリデータベースのバックアップを暗号化して安全に保管してください。バックアップからのリストア手順を定期的にテストし、災害復旧計画に組み込みましょう。