Interstage Application Server セキュリティシステム運用ガイド

5.2.3 アクセス制御リスト定義の評価

　クライアントからアクセスするユーザに、エントリや属性に対するアクセス権を与えるかどうかの評価は、以下の順序で行われます。

1. アクセス対象の評価

   クライアントから指定されたエントリや属性を、アクセス制御リストで指定されている <アクセス対象> と比較します。
   各エントリや属性について、アクセス制御リストの先頭行から順に access ディレクティブを調べます。リポジトリサーバは、アクセス制御リストで指定されているエントリや属性と一致する、最初の <アクセス対象> を見つけたところで調査をやめます。

   たとえば、以下のようにアクセス制御リストを定義した場合、telephoneNumber 属性へのアクセス要求があると、(1)でアクセス対象と一致するので、(3)の調査はしません。

   access to attr=telephoneNumber     ・・・(1)
           by self write              ・・・(2)
   access to attr=telephoneNumber     ・・・(3)
           by users read              ・・・(4)

   　

2. アクセスユーザの評価

   次に、リポジトリサーバは、手順1で選択された access ディレクティブの <アクセスユーザ> を、by 節の出現順に、アクセスを要求するクライアントのバインドDNと比較します。リポジトリサーバは、クライアントのバインドDNと一致する、最初の <アクセスユーザ> を見つけたところで比較をやめます。

   手順1のアクセス制御リストで、クライアントのバインドDNとエントリのDNとが一致するエントリの telephoneNumber 属性へのアクセス要求があると、(2)で一致するので、比較を終了します。クライアントのバインドDNとエントリのDNとが一致するエントリではなく、他のエントリの telephoneNumber 属性へのアクセス要求の場合は、(2)では一致しません。また、アクセス対象の評価を(1)で終了するので、(3)、および(4)のアクセス対象、およびアクセスユーザの評価はされず、アクセスを拒否します。

3. アクセス権の評価

   最後に、リポジトリサーバは、手順2で選択された <アクセスユーザ> の <アクセス権> に与えられているアクセス権を、クライアントによって要求されたアクセス(操作)と比較します。アクセス権が、実際のアクセス(操作)以上のものであれば、アクセスが認められます。そうでない場合は、アクセスが拒否されます。

　また、上記の各手順で、どの <アクセス対象> とも一致しない場合、あるいはどの <アクセスユーザ> とも一致しない場合には、アクセスが拒否されます。
　あらゆる access ディレクティブの by 節は、暗黙の「by * none」で終わっていて、あらゆるアクセス制御リストは、暗黙の「access to * by * none」で終わっているためです。

　このため、access ディレクティブの評価順序により、アクセス制御リスト定義ファイル中での access ディレクティブの出現位置がとても重要となります。
　ある access ディレクティブの <アクセス対象> が、別の access ディレクティブの <アクセス対象> よりも限定的な <アクセス対象> であった場合、定義ファイルの中では、より前に出現するように定義しなければなりません。同様に、ある <アクセスユーザ> が、別の <アクセスユーザ> よりも限定的な <アクセスユーザ> であった場合、access ディレクティブの中で、より前に出現するように定義しなければなりません。

■間違った定義例 1

access to attr=telephoneNumber
        by users read     ・・・ここで、評価をやめてしまうので、次の文の意味がなくなる。
        by self write

　この例では、エントリとして登録されているユーザが、自身のエントリの telephoneNumber 属性を更新できるように定義しようとしています。しかし、アクセスユーザの「self」は、「users」に含まれるため、リポジトリサーバは、「by users read」で評価をやめてしまいます。その結果、エントリして登録されているユーザがアクセスしようとした時に、アクセス対象が自身のエントリであっても、エントリの更新ができなくなります。
　これに対して、以下の正しい定義例のように、by 節の記述順序を逆にすることで、意図した定義となります。

■正しい定義例 1

access to attr=telephoneNumber
        by self write
        by users read

■間違った定義例 2

access to attr=mail by self write     ・・・ここで、mail属性の評価をやめてしまう。
access to attr=mail by users read
access to attr=userPassword by self write     ・・・ここで、userPassword 属性の評価
access to attr=userPassword by * auth               をやめてしまう。

　この例では、同一のアクセス対象に、アクセスユーザごとに access ディレクティブを分けて記述しています。これでは、各アクセス対象の1つ目のaccess ディレクティブで評価をやめてしまいますので、意図したアクセス制御になりません。
　これに対して、以下の正しい定義例のように、同一のアクセス対象に対して、複数回 by 節を指定してまとめることで、意図した定義となり、定義内容も確認しやすくなります。

■正しい定義例 2

access to attr=mail
        by self write
        by users read
access to attr=userPassword
        by self write
        by * auth

　access ディレクティブは、<アクセス対象> や <アクセスユーザ> の指定を工夫し、少ない数で簡潔に定義することを強く推奨します。大量の access ディレクティブを定義した場合、リポジトリの起動時や、クライアントからのアクセス(操作)要求時などの、運用性能に影響を与える可能性があります。

■悪い定義例

access to attr=mail
        by dn="cn=User001,ou=User,o=fujitsu,dc=com" write
        by dn="cn=User002,ou=User,o=fujitsu,dc=com" write
        by dn="cn=User003,ou=User,o=fujitsu,dc=com" write
        by users read
 access to attr=userPassword
        by dn="cn=User001,ou=User,o=fujitsu,dc=com" write
        by dn="cn=User002,ou=User,o=fujitsu,dc=com" write
        by dn="cn=User003,ou=User,o=fujitsu,dc=com" write
        by * auth

　この例では、エントリとして登録されているユーザが、自身のエントリのmail 属性、およびuserPassword 属性を更新できるように、ユーザごとに定義しています。
　これに対して、以下の良い定義例のように、<アクセスユーザ> を「self」で定義することで、簡潔に少ない行で定義することができます。

■良い定義例

access to attr=mail
        by self write
        by users read
access to attr=userPassword
        by self write
        by * auth