6. セキュリティに関する考慮事項
セキュリティ上の問題は本文書全体で論じられている. 驚くにはあたらない結論だが, セキュリティは LDAP の不可分かつ必要な一部である. 本節では, LDAP に関連するいくつかのセキュリティ上の考慮事項を論じる.
6.1. LDAP 全般のセキュリティに関する考慮事項
LDAP 自体は, LDAP プロトコル以外の手段によるディレクトリへのアクセスや更新 (例えばデータベース管理者によるサーバーのデータベースファイルの閲覧) に対するセキュリティや保護を提供しない.
機微なデータはほとんど任意の LDAP メッセージで運ばれうるし, その開示は多くの国においてプライバシー法その他の法的規制の対象となりうる. 実装者は, 機微なデータが権限のない実体に開示されることを防ぐための適切な措置を講ずべきである.
クライアントがデータ完全性とプライバシーのサービスを確立していないセッション (例えば StartTLS, IPsec, または適切な SASL メカニズムを介していないもの) は, 転送中の情報を閲覧・改変する中間者攻撃の対象となる. クライアントとサーバーの実装者は, 本文書で論じるデータ保護サービスを用いて, LDAP セッション内の機微なデータをこれらの攻撃から保護する措置を講ずることが望ましい (SHOULD). クライアントとサーバーは, これらの保護を必須とするよう構成できる機能を提供すべきである. resultCode の
confidentialityRequired は, 要求された操作を実行するために (より強力な) データ機密性保護の確立をサーバーが要求していることを示す.
機微な情報を読む場合やディレクトリ情報を更新する場合には, 常にアクセス制御を適用すべきである.
認証・認可情報やデータセキュリティサービスを含む種々のセキュリティ要因は, LDAP セッションの進行中に, あるいは特定の操作の実行中にさえ, 変化しうる. 実装は, 変化するセキュリティ要因の扱いにおいて堅牢であるべきである.
6.2. StartTLS のセキュリティに関する考慮事項
StartTLS 操作の使用によって得られるセキュリティは, すべて TLS 自体の使用によって得られるものである. StartTLS 操作それ自体は, 追加のセキュリティを何ら提供しない.
TLS の使用によって提供されるセキュリティの水準は, 使用される TLS 実装の品質と, その実装の使用の仕方の両方に直接依存する. さらに, 中間者攻撃者は, ルート DSE の 'supportedExtension' 属性から StartTLS 拡張操作を削除することができる. 両当事者は, TLS が確立された後, TLS で保護されたセッションの使用を始める前に, 達成されたセキュリティレベルを独立に確認し, それに同意することが望ましい (SHOULD). 例えば, TLS 層のセキュリティレベルが平文まで引き下げてネゴシエートされている可能性がある.
クライアントは, 達成されたセキュリティレベルが許容できる水準のデータ機密性および/またはデータ完全性保護を提供しない場合にユーザーに警告するか, 許容できる水準のセキュリティがなければ続行を拒否するよう構成可能でなければならない (MUST).
3.1.2 項に述べたとおり, サーバーはローカルのセキュリティポリシーを用いて, TLS ネゴシエーションを正常に完了させるか否かを決定してよい. 認証局によって発行または検証されたユーザー証明書内の情報は, 識別と認可のポリシーを構成する際にポリシー管理者が用いるべきである.
サーバー実装者は, データの機密性と完全性を要求するか否か, そしていつ要求するかをサーバー管理者が選択できるようにし, さらに TLS ハンドシェイク中のクライアント認証を要求するか否かも選択できるようにすることが望ましい (SHOULD).
実装者は, TLS 仕様 [RFC4346] で論じられている TLS のセキュリティ上の考慮事項を認識し理解すべきである.
6.3. Bind 操作のセキュリティに関する考慮事項
本節では, Bind 操作を介した LDAP 認証に関連するいくつかのセキュリティ上の考慮事項を論じる.
6.3.1. 未認証メカニズムのセキュリティに関する考慮事項
運用経験によれば, クライアントは simple Bind 方式の未認証認証メカニズム (5.1.2 節参照) を誤用することがある (そしてしばしば実際に誤用する). 例えば, クライアントプログラムが, Bind 操作の正常完了を根拠に, ディレクトリ以外の情報へのアクセスを許可する判断を下すことがある. LDAP サーバー実装は, 未認証の Bind 要求に対して成功応答を返すことがある. これは, 実際には匿名認可状態が確立されているにもかかわらず, サーバーが識別名で表されるアイデンティティの認証に成功したという誤った印象をクライアントに与えかねない. simple Bind 操作の結果を認可の判断に用いるクライアントは, 未認証の Bind 要求を能動的に検出し (提供されたパスワードが空でないことを検証することにより), 適切に対処すべきである.
6.3.2. 名前/パスワードメカニズムのセキュリティに関する考慮事項
simple Bind 方式の名前/パスワード認証メカニズムはサーバーにパスワードを開示するため, これは本質的なセキュリティリスクである. SASL DIGEST-MD5 [DIGEST-MD5] のように, サーバーにパスワードを開示しないメカニズムもある.
6.3.3. パスワード関連のセキュリティに関する考慮事項
LDAP は多値のパスワード属性を許す. エントリがパスワードをちょうど 1 つだけ持つことが期待されるシステムでは, この挙動を強制するための管理上の制御を提供すべきである.
下位のトランスポートサービスが機密性を保証できない場合, 開放されたネットワーク上で平文パスワードその他の保護されていない認証資格情報を用いることは強く推奨されない. LDAP 実装は, セッション上のデータが TLS その他のデータ機密性・データ完全性保護を用いて保護されていない限り, 平文パスワードその他の保護されていない認証資格情報を用いる認証方式を既定でサポートすべきではない (SHOULD NOT).
一般に認証や変更のために行われる, 平文でのパスワードの送信は重大なセキュリティリスクをもたらす. このリスクは, パスワードを平文で送信しない SASL 認証 [RFC4422] メカニズムを用いるか, パスワード値を送信する前にトランスポート層またはセッション層のデータ機密性サービスをネゴシエートすることによって回避できる.
パスワードの転送に伴うセキュリティリスクを軽減するため, パスワードを平文で送信するパスワードベースの認証メカニズムをサポートするサーバー実装は, 認証時またはパスワード変更時に次を要求するポリシーメカニズムをサポートしなければならない (MUST):
TLS 層が正常に導入されていること.
または
盗聴からパスワード値を保護する他のデータ機密性メカニズムが提供されていること.
または
パスワード値が正しい場合であっても, サーバーがその操作 (すなわち, パスワード値を伴う名前/パスワード Bind, パスワード値を平文で送信する SASL Bind, userPassword 値を含む add や modify など) に対して resultCode の confidentialityRequired を返すこと.
サーバー実装はさらに, あるアカウントのパスワードが平文で送信されたことをサーバーが検出した状況において, そのアカウントを無効化するなどして保護するためのポリシーメカニズムを提供したいと考えるかもしれない.
6.3.4. ハッシュ化パスワードのセキュリティに関する考慮事項
一部の認証メカニズム (例えば DIGEST-MD5) は, オフライン辞書攻撃に対して脆弱でありうるパスワード値のハッシュを送信する. 実装者は, そのようなハッシュ化パスワード値を TLS その他の機密性メカニズムを用いて送信中に保護するよう注意すべきである.
6.4. SASL のセキュリティに関する考慮事項
LDAP セッションにデータ完全性サービスが導入されるまでの間, 攻撃者は 'supportedSASLMechanisms' 属性応答の送信値を改変し, 利用可能な SASL メカニズムの一覧を最も安全性の低いメカニズムだけを含むように格下げすることができる. この種の攻撃を検出するため, クライアントは, LDAP セッションにデータ完全性サービスが導入される前と後の両方で, サーバーが利用可能とする SASL メカニズムを取得してよい. 完全性によって保護された一覧 (データ完全性サービス導入後に取得した一覧) が, 先に取得した一覧よりも強力なメカニズムを含む場合, クライアントは先に取得した一覧が攻撃者によって改変されたものと見なすべきである. この状況では, クライアントは下位のトランスポート接続を閉じ, その後再接続してセッションを再確立することが推奨される.
6.5. 関連するセキュリティに関する考慮事項
本文書で論じた種々の認証方式とメカニズムに関連する追加のセキュリティ上の考慮事項が適用され, [RFC4422], [RFC4013], [RFC3454], [RFC3629] に見いだせる.