ACL のしくみ
あるアクセス制御規則で定義されている参加者のアクセス許可と、ほかの規則で定義されているアクセス許可との間に矛盾が起きることがあります。たとえば、「/Acme」ドメインに属する「レビュー中」状態のすべてのインシデントレポートに対する「削除」アクセス許可を Team 1 グループの全員に与えるアクセス制御規則を定義したとします。ただし、別のアクセス制御リストでユーザー Audrey.Carmen に対し、Team 1 のメンバーシップにかかわらず、このアクセス許可を明示的に拒否しているとします。この場合、参加者の最終的なアクセス許可は ACL メカニズムにより計算されます。
次の表に、アクセス許可の組み合わせを簡単に示します。詳細は、表の後で説明しています。
 | ACL を計算するとき、疑似役割「オーナー」のアクセス許可を拒否するアクセス制御規則は無視されます。 |
参加者の最終的なアクセス許可は、次の規則に従って計算されます。
• 各参加者 (ユーザー、ユーザー定義グループ、システムグループ、または組織) に設定できる付与 ACL エントリ、拒否 ACL エントリ、および拒否 (オーバーライド不可) ACL エントリは、多くても 1 つです。つまり、アクセス許可タイプが同じである複数の ACL エントリは、いずれの参加者でも許可されていません。各エントリは、付与、拒否、またはオーバーライド不可で拒否されるアクセス許可のセットを指定します。疑似役割には、付与 ACL エントリと拒否 ACL を 1 つまで設定できます。拒否 (オーバーライド不可) アクセス許可は、疑似役割には指定できません。
| | ACL が生成される前に、ダイナミック役割は特定のシステムグループに関連付けられます。規則でダイナミック役割を解決する際の考慮事項を参照してください。 |
• 指定した参加者を除くすべての参加者に対する付与、拒否、または拒否 (オーバーライド不可) のアクセス許可は、管理者ユーザー、選択したユーザー、または選択したグループ、ダイナミック役割、組織のユーザーを除く、すべてのユーザーがメンバーとなるグループに指定されたアクセス許可のように処理されます。
• 特定のユーザー、グループ、疑似役割、または組織に ACL エントリがない場合、その参加者には Null アクセス許可セットが与えられます。事実上、Null アクセス許可セットが与えられた参加者はオブジェクトにアクセスできません。
• 参加者に対してあるアクセス許可を与える付与エントリがあるときに、同じアクセス許可を拒否またはオーバーライド不可で拒否するエントリがある場合、そのアクセス許可は付与されません。
• 疑似役割「オーナー」に明示的に付与 (+) されたアクセス許可は、各ユーザーまたはそのユーザーが属するグループや組織の拒否エントリによって、所有可能なオブジェクトのオーナーであるユーザーに対して拒否 (-) されたアクセス許可をオーバーライドします。
• 疑似役割「オーナー」に明示的に付与 (+) されたアクセス許可は、各ユーザーまたはそのユーザーが属するグループや組織の拒否 (オーバーライド不可) エントリによって、所有可能なオブジェクトのオーナーであるユーザーに対してオーバーライド不可で拒否 (!) されたアクセス許可をオーバーライドしません。
• 所有可能なオブジェクトのオーナーであるユーザー、またはユーザーが属するグループまたは組織に明示的に付与 (+) されたアクセス許可は、疑似役割「オーナー」に対して拒否 (-) されたアクセス許可によってオーバーライドされません。疑似役割「オーナー」に対して拒否されたアクセス許可は無視されます。
• 各ユーザーに明示的に付与 (+) されたアクセス許可は、疑似役割「すべて」で拒否されたアクセス許可と同様、そのユーザーのグループまたは組織のアクセス許可で拒否 (-) されたアクセス許可をオーバーライドします。たとえば、ユーザー ReneN が Group 1 のメンバーであるとします。Acme ドメインのアクセス制御規則に従い、Group 1 のすべてのメンバーは、ライフサイクル状態が「レビュー中」であるインシデントレポートの「修正」アクセス許可が拒否されます。ただし、別のアクセス規則で ReneN に対してインシデントレポートの「修正」アクセス許可が明示的に付与されている場合は、グループ 1 のメンバーであっても、ReneN に「修正」アクセス許可が付与されます。
• ユーザーに対する拒否 (オーバーライド不可) (!) または拒否 (-) のアクセス許可は、そのユーザーのグループまたは組織に付与 (+) されたアクセス許可をオーバーライドします。たとえば、Acme ドメインのアクセス制御規則に従い、Group 1 のすべてのメンバーに、ライフサイクル状態が「レビュー済み」である変更通知の「修正」アクセス許可が付与されるとします。また、別のアクセス制御規則で、ReneN は変更通知の「修正」アクセス許可が拒否されているとします。この場合、ReneN は Group 1 のメンバーですが、「修正」アクセス許可を拒否されます。
• グループまたは組織に対する拒否 (オーバーライド不可) (!) のアクセス許可は、そのグループまたは組織のメンバーである各ユーザーに明示的に付与 (+) されたアクセス許可によってオーバーライドできません。たとえば、Acme ドメインのアクセス制御規則に従い、Group 1 のすべてのメンバーは、ライフサイクル状態が「完了」である変更リクエストに対して、管理アクセス許可をオーバーライド不可で拒否されているとします。別の規則で ReneN に変更リクエストを管理するアクセス許可が明示的に付与されていても、ReneN は管理アクセス許可を拒否されます。
• ユーザーの実質的な付与のグループアクセス許可セットは、そのユーザーが属する各グループおよび組織のすべての付与アクセス許可の和集合になります。これには、疑似役割「すべて」に付与されたアクセス許可が含まれます。たとえば、ReneN が Group 1、Group 2、および Group 3 のグループに属している場合、付与のグループアクセス許可には、各グループのメンバーとして付与されたすべてのアクセス許可が含まれます。
• ユーザーの実質的な拒否のグループアクセス許可セットは、そのユーザーが属する各グループおよび組織のすべての拒否アクセス許可 (-) の和集合になります。これには、疑似役割「すべて」で拒否されるアクセス許可が含まれます。たとえば、ReneN が Group 1、Group 2、および Group 3 のグループに属している場合、拒否のグループアクセス許可には、各グループで拒否されるすべてのアクセス許可が含まれます。
• ユーザーの実質的な拒否 (オーバーライド不可) のグループアクセス許可セットは、そのユーザーが属する各グループおよび組織のすべての拒否 (オーバーライド不可) アクセス許可の和集合になります。たとえば、ReneN が Group 1、Group 2、および Group 3 のグループに属している場合、拒否のグループアクセス許可には、各グループで拒否されるすべてのアクセス許可が含まれます。疑似役割「すべて」のアクセス許可をオーバーライド不可で拒否することはできません。
ACL でアクセス許可が計算されるときに、ユーザー ReneN の付与、拒否、および拒否 (オーバーライド不可) のアクセス許可セットがマージされて、アクセス許可が決定されます。たとえば、Group 1 のメンバーである ReneN に、「/Acme」ドメインの、ライフサイクル状態が「レビュー中」であるすべてのインシデントレポートに対する「読み取り」アクセス許可が付与されているとします。ただし、ReneN は、同じドメインのインシデントレポートに対する「読み取り」アクセス許可が拒否される Group 2 のメンバーでもあります。計算の際、「/Acme」ドメインのインシデントレポートに関する ReneN の「読み取り」アクセス許可は Null に設定されます。したがって、ReneN はアクセスを拒否されます。
以下の表で、アクセス許可計算の詳しい例を示します。管理者として、複数のドメインのアクセス制御ポリシーを作成していると仮定します。ユーザー Ann は、グループ G1 に属していますが、G2 には属していません。表に示されているアクセス許可を割り当てると、Ann のアクセス許可は、一番右の列に記載されているアクセス許可となります。
G1 のアクセス許可 | G2 を除くすべてのアクセス許可 | G1 と、G2 を除くすべての和集合 | 個別のアクセス許可 | 最終的なアクセス許可 | |
|---|---|---|---|---|---|
+ - ! | 修正 (M) Null セット Null セット | 作成 (C) Null セット Null セット | (C)+(M) Null セット Null セット | 削除 (D) + 管理 (A) Null セット Null セット | (C) + (M) + (D) + (A) |
+ - ! | (M) (D) (A) | (C) (M) Null セット | (C)+(M) (D) + (M) (A) | (D) Null セット Null セット | (C)+(D) |
+ - ! | (M) + (A) (D) Null セット | (D) (C) Null セット | (M) + (A) + (D) (C)+(D) Null セット | (C) (M) (A) | (C) |
+ - ! | (M) Null セット Null セット | (C) Null セット (A) | (M)+(C) Null セット (A) | (D) + (A) (M) Null セット | (C)+(D) |
ドメインのアクセス制御規則を定義すると、特定の状態にある、作成した規則を適用する対象となる同じドメインに属するオブジェクトタイプのすべてのインスタンスによって、ACL が共有されます。こうした、ACL とオブジェクトタイプ、状態、およびドメインの関係は、これ以降も保持されます。参加者が表示または修正目的でオブジェクトにアクセスしようとすると、関連する ACL が読み込まれ、ポリシーが適用されます。ACL は、1 度計算されるとキャッシュされるので、次にアクセスが要求されたときに、すぐに読み込まれます。
たとえば、「/Acme」ドメインで、ユーザー Audrey Carmen は、状態が「クローズ」である WTObject タイプのすべてのオブジェクトに対して「読み取り」と「削除」のアクセス許可を付与されたグループのメンバーであると仮定します。また、「/Acme/Support」ドメインでは、Audrey Carmen は、状態が「クローズ」であるすべてのインシデントレポートに対して「修正」アクセス許可が付与されたグループのメンバーであるとします。IncidentReport は WTObject のサブタイプとします。ただし、「/Acme」ドメインでは、個人ユーザーとしての Audrey Carmen に、「クローズ」状態のインシデントレポートに対する「削除」アクセス許可を拒否する別の規則が定義されています。
「/Acme/Support」ドメインの「クローズ」状態のインシデントレポートに関連付けられる、Audrey Carmen の ACL エントリは以下のとおりです。
Audrey.Carmen + 読み取り、+ 修正、- 削除
この ACL エントリが「/」、「/Acme」、および「/Acme/Support」ドメインのアクセス制御ポリシーから作成されたときに、Audrey.Carmen には「読み取り」と「修正」のアクセス許可が付与されています。IncidentReport は WTObject のサブタイプなので、WTObject タイプのオブジェクトに対する Audrey の「読み取り」と「削除」のアクセス許可は、インシデントレポートにも適用されます。ただし、別のアクセス制御規則で「クローズ」状態のインシデントレポートに対する「削除」アクセス許可が拒否されているので、結果としてアクセス許可は「読み取り」および「修正」となり、Audrey は「/Acme/Support」ドメインに属する WTObject タイプの「クローズ」状態のオブジェクトを削除できません。