次の各ヒントを参考にすれば、ディレクトリのセキュリティーモデルの単純化とパフォーマンスの改善を図れる可能性があります。
ディレクトリ内の ACI の数を最小化し、可能であればマクロ ACI を使用する。
Directory Server は 50,000 件を超える ACI を評価可能ですが、多数の ACI 文を管理するのは容易ではありません。また、過剰な ACI はメモリー消費にも悪影響を及ぼす可能性があります。
許可権限と拒否権限のバランスを図る。
デフォルトの規則は、アクセスを具体的に許可されていないすべてのユーザーのアクセスを拒否することです。ただし、ツリーのルートの近くでアクセスを許可する 1 つの ACI を使用し、リーフエントリの近くで少数の拒否 ACI を使用すれば、ACI の数を減らすことができます。このようにすると、最下位のエントリの近くでアクセスを許可する ACI が必要以上に多くなることがなくなります。
ACI では最小の属性セットを指定する。
オブジェクトの属性の一部でアクセスを許可または拒否する場合、許可または拒否する属性の最小リストを決めます。次に、最小の属性リストを管理するように ACI を表します。
たとえば、ユーザーオブジェクトクラスに多くの属性が含まれている場合を考えます。いくつかの属性だけをユーザーが更新できるようにするには、その少数について書き込み権限を許可する ACI を作成します。1 つか 2 つの属性以外のすべてをユーザーが更新できるようにする場合は、それらの 1 つか 2 つの属性について書き込み権限を拒否する ACI を作成します。
LDAP 検索フィルタは慎重に使用する。
検索フィルタは、アクセス管理対象のオブジェクトを直接指定しません。したがって、特にディレクトリが複雑になるにつれて、検索フィルタによって予期しない結果が得られる可能性があります。ACI 内で検索フィルタを使用する場合、その同じフィルタを使って ldapsearch 操作を実行してください。このアクションにより、その変更の結果がユーザーのディレクトリにとって何を意味するのかを確認できます。
ディレクトリツリーの別の部分で ACI を重複させない。
オーバーラップしている ACI を探します。グループ書き込みアクセス権を commonName および givenName 属性に対して許可する ACI が、ディレクトリのルート位置に存在するとします。さらに、それと同じグループ書き込みアクセス権を commonName 属性に対してだけ許可する別の ACI も存在するとします。この場合、そのグループに対して 1 つの属性のみの書き込みアクセス権を与えるように、ACI を修正することを検討してください。
ディレクトリが複雑になるほど、ACI のオーバーラップが間違って発生する確率も高くなります。ACI のオーバーラップを回避すれば、セキュリティーの管理が容易になり、ディレクトリ内の ACI の合計数も減少します。
ACI に名前を付ける。
ACI に名前を付けることは省略可能ですが、各 ACI に意味のある短い名前を付ければ、セキュリティーモデルの管理が容易になります。
ユーザーエントリの標準属性を使用して、アクセス権限を決める。
可能なかぎり、すでに標準ユーザーエントリの一部となっている情報を使用して、アクセス権限を決めてください。特別な属性を作成する必要がある場合は、それらの属性をロールまたはサービスクラス (CoS) の定義の一部として作成することを検討します。ロールと CoS の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 8 章「Directory Server Groups and Roles」および『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 9 章「Directory Server Class of Service」を参照してください。
ACI を互いにできるだけ近い位置にまとめる。
ACI の配置をディレクトリのルートポイントとディレクトリの主な分岐点に限定します。ACI を編成してグループにまとめると、ACI リストの全体を管理しやすくなり、ACI の合計数を最小に保つことができます。
二重否定は使用しないようにする (バインド DN が cn=Joe と等しくない場合の書き込みの拒否など)。
サーバーはこの構文を理解できますが、管理者にとっては混乱の元となります。