グループと属性を特定した後には、セキュリティー・ニーズに対応するルール・セット、つまりアクセス制御リスト (ACL) をマップします。
ACL は、読み取り許可と書き込み許可を制御するルールの集合です。ACL を使用することで、ユーザーのグループに対して特定のルールを定義できます。
各 ACL には以下の 3 つのコンポーネントがあります。
スコープ
各ルールでは、ルールのスコープを定義する必要があります。
つまり、当該ルールがどの CR、タスク、またはオブジェクトに対して適用可能かどうかを定義します。
特定のオブジェクトに対して ACL を定義する他のアプリケーションとは異なり、IBM® Rational® Change は、すべての CR に対して 1 つのグローバル ACL、タスクに対して 1 つの ACL、そしてオブジェクトに対して 1 つの ACL を定義します。
ただし、ACL 内の各ルールは、それぞれのサブセットに適用されます。スコープは、単純な等式 attribute = value によって設定されます。
この条件を満たすすべての CR、タスク、またはオブジェクトが、当該ルールによって制御されます。
デフォルト・ルールは、ルールのいずれにも一致しないすべての CR、タスク、およびオブジェクトに対する読み取り/書き込みアクセスを拒否します。
デフォルト・ルールは必要に応じて修正できます。
許可
各ルールは、許可のタイプ、および当該許可を付与するか拒否するかを定義する必要があります。
ユーザーが、権限付与ルールと拒否ルールの両方を適格とする場合は、拒否ルールが適用されます。
使用可能な許可は以下のとおりです。
- 読み取り: CR、タスク、またはオブジェクトを表示する権限。
ユーザーは、読み取りアクセスを備えていない場合は、当該 CR または タスクが存在しないという通知を受けます。
レポートおよび検索の場合は、当該 CR またはタスクは結果セットから削除されます。
- 書き込み: CR を編集する権限。
ただし、書き込みアクセスを付与しても、CR が修正可であることを必ずしも意味するわけではありません。
以下のように、その他の要因によって、最終的に書き込みアクセスが許可されない可能性があります。
- CR 表示フォーム (ダイアログ・ボックス) が読み取り専用のコントロールを使用して定義できる。
- IBM Distributed Rational Change によって適用されるルールが原因で、CR が当該データベースで修正可ではない。
例えば、CR C#123 の制御が、C データベースから W データベースに転送されている場合です。
C データベースで修正できなくなっています。
- ライフサイクル・セキュリティーが、ユーザーに属性修正権限を一切付与しなかった。
例えば、CR が IBM Rational Synergy グループによって修正可であり、ユーザーが Synergy グループに属しているとします。
しかし、ライフサイクル・セキュリティーで、割り当て状態の CR の属性 x、y、および z を修正するにはユーザーは assigner 権限を備える必要があると記述されています。
ユーザーが assigner 権限を備えていません。
- 読み取り/書き込み: CR を読み取りおよび書き込みする権限。
この組み合わせの許可により、その他のすべてのコンポーネントが等しい場合に読み取りおよび書き込みのルールを分ける必要がなくなり、ACL 保守が軽減されます。
ユーザーまたはグループ
スコープおよび許可を定義した後には、各ルールでは、当該ルールが適用される 1 つ以上のユーザーまたはグループ、あるいはその両方を指定する必要があります。
- グループ: ルールは一般的に、1 つ以上のグループに適用されます。
- ユーザー: ルールは、特定のユーザーに固有のものにすることができます。
こうしたルールは、該当グループに属していないユーザーに対して許可を一時的に付与または拒否する必要が生じた場合に便利です。
例えば、短期契約のコンサルタントに対して権限を付与する必要が生じる場合があります。
ルールには、ユーザーとグループの両方を混合して含めることができます。
- {everyone}: すべての Rational Change ユーザーを表すために使用される特殊目的の ID。
この ID は、拒否セキュリティー・モデルを実装する際に便利です。
つまり、{everyone} に権限を付与してから、拒否するユーザーまたはグループ、あるいはその両方をリストします。
例えば、以下の表に、5 つの製品を使用している会社の CR ACL を示します。
製品のうち 4 つは 2 つの製品ライン内にあり、1 つの製品は 2 つの製品ラインにまたがっています (統合)。
この例では、DOORS® 製品ラインに最も制限の強いセキュリティーが設定されており、
次に IBM Rational Synergy、そして統合に最も低いセキュリティーが設定されています。
表 1. CR
ACL の例| スコープ属性値 |
アクセス |
許可 |
ユーザー、グループ |
| Product_Line |
Synergy |
権限付与 |
読み取り |
{everyone} |
| Product_Line |
Synergy |
拒否 |
読み取り |
Contractor、Guest |
| Product_Line |
DOORS |
権限付与 |
読み取り |
DOORS、CCB |
| Product |
CM |
権限付与 |
書き込み |
Synergy Dev、CCB |
| Product |
Change |
権限付与 |
書き込み |
Synergy Dev、CCB |
| Product |
RM |
権限付与 |
書き込み |
RM Dev Leads、CCB |
| Product |
XT |
権限付与 |
書き込み |
XT Dev Leads、CCB |
| Product |
統合 |
権限付与 |
読み取り/書き込み |
Development、Contractor、CCB |
| 条件と一致しない変更依頼 |
拒否 |
読み取り/書き込み |
適用外 |