第1章 アクセス制御手順の管理
Directory Server が要求を受信すると、bind 操作でユーザーによって提供される認証情報、およびディレクトリーに定義されているアクセス制御の手順 (ACI) を使用し、要求されたエントリーまたは属性へのアクセスを許可または拒否します。サーバーは、read
、write
、search
、compare
などのアクションのパーミッションを許可または拒否できます。ユーザーに付与されたパーミッションレベルは、指定される認証情報によって異なります。
Directory Server のアクセス制御により、ACI が適用される場合に正確なルールを設定できます。
- ディレクトリー全体、サブツリー、または特定のエントリーの場合
- 特定のユーザー、特定のユーザーまたはグループに属するすべてのユーザー、またはディレクトリー内のすべてのユーザーの場合
IP アドレス、IP 範囲、または DNS 名などの特定の場所。
ロードバランサーは場所固有のルールに影響を及ぼす可能性があることに注意してください。
複雑な ACI の読み取りと理解は難しくなります。1 つの複雑な ACI の代わりに、同じ効果を達成するために複数の単純なルールを作成できます。ただし、ACI が多いほど、ACI 処理のコストも増加します。
1.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 の数を最小限にします。より具体的なルールの範囲を制限するには、できるだけ早くリーフエントリーに配置します。