第12章 アクセス制御手順の管理
Directory Server が要求を受信すると、bind 操作でユーザーによって提供される認証情報、およびディレクトリーに定義されているアクセス制御の手順 (ACI) を使用し、要求されたエントリーまたは属性へのアクセスを許可または拒否します。サーバーは、read、write、search、compare などのアクションのパーミッションを許可または拒否できます。ユーザーに付与されたパーミッションレベルは、指定される認証情報によって異なります。
Directory Server のアクセス制御により、ACI が適用される場合に正確なルールを設定できます。
- ディレクトリー全体、サブツリー、または特定のエントリーの場合
- 特定のユーザー、特定のユーザーまたはグループに属するすべてのユーザー、またはディレクトリー内のすべてのユーザーの場合
IP アドレス、IP 範囲、または DNS 名などの特定の場所。
ロードバランサーは場所固有のルールに影響を及ぼす可能性があることに注意してください。
複雑な ACI の読み取りと理解は難しくなります。1 つの複雑な ACI の代わりに、同じ効果を達成するために複数の単純なルールを作成できます。ただし、ACI が多いほど、ACI 処理のコストも増加します。
12.1. ACI 配置
Directory Server は、アクセス制御命令 (ACI) をディレクトリーエントリーの多値 aci 操作属性に保存します。ACI を設定するには、aci 属性を対応するディレクトリーエントリーに追加します。Directory Server は ACI を適用します。
ACI を含むエントリー (子エントリーがない場合) にのみ適用されます。たとえば、クライアントが
uid=user_name,ou=People,dc=example,dc=comオブジェクトへのアクセスを必要とし、ACI がdc=example,dc=comにのみ設定されており、子エントリーには設定されていない場合は、この ACI のみが適用されます。注記add権限を持つ ACI は、今後作成される子エントリーにも適用されます。ACI を含むエントリーと、(子エントリーがある場合は) その下のすべてのエントリーへ。これにより、サーバーが指定のエントリーに対するアクセスパーミッションを評価すると、リクエストされたディレクトリー接尾辞と、エントリー自体の ACI との間のすべてのエントリーについて ACI を検証します。
たとえば、ACI は
dc=example,dc=comおよびou=People,dc=example,dc=comエントリーに設定されます。ACI が設定されていないuid=user_name,ou=People,dc=example,dc=comオブジェクトにクライアントがアクセスする場合、Directory Server はまずou=People,dc=example,dc=comエントリー上の ACI を検証します。この ACI がアクセスを許可する場合は、評価は停止し、アクセスを許可します。そうでない場合は、Directory Server はou=People,dc=example,dc=com上の ACI を検証します。この ACI がクライアントを正常に承認すると、オブジェクトにアクセスできます。
rootDSE エントリーに設定された ACI はこのエントリーにのみ適用されます。
エントリーで作成された ACI は、そのエントリーに直接適用するのではなく、以下のサブツリーの一部のエントリーまたはすべてのエントリーに適用できます。この方法の利点は、一般的な ACI をディレクトリーツリーの上位において、下位にあるエントリーに影響を与えることができることです。たとえば、inetOrgPerson オブジェクトクラスを含むエントリーをターゲットにする ACI は、organizationalUnit エントリーまたは locality エントリーのレベルで作成できます。
一般的なルールを高レベルのブランチポイントに配置し、ディレクトリーツリー内の ACI の数を最小限にします。より具体的なルールの範囲を制限するには、できるだけ早くリーフエントリーに配置します。
