シナリオ 3: 内部ユーザー データベースへの共用クエリーを使用した顧客アクセス権限

このシナリオの目的は、顧客の問題に対応するレコードの表示、 新しい問題の登録、他の共用情報の表示をするために、ClearQuest 内部データベースに顧客アクセス権を許可することです。

顧客の問題に関連するレコードの表示、 新しい問題の登録、特定の顧客に特有ではない他の共用情報の参照が顧客からできるようにするために、 ClearQuest 内部データベースに顧客アクセス権を許可することが有効であることがよくあります。

シナリオ 3 の背景事情

この機能の重要な点は、顧客が自分以外の顧客情報の存在を 確認したり、検索したりすることができないという点です。内部ユーザーや 内部情報の存在についても、確認したり検索したりすることはできません。

ワークスペース フォルダ権限は、上記で述べた目的を実現するための 解決法の一部にすぎないことに注意してください。多くの ClearQuest スキーマには、 顧客から確認できることは望ましくないデータが含まれているレコードがあります。

Rational ClearQuest のセキュリティ コンテキスト機能を使用して、 クエリーから戻るレコードの可視性を制限しなければなりません。 ワークスペース フォルダ権限は、クエリーから戻るデータには どのような制限もつけません。さらに、ワークスペース フォルダ権限は、 プライベート クエリーを作成することのできるユーザー機能にも制限をつけません。 Rational ClearQuest のセキュリティ コンテキスト機能は、 クエリーから戻るレコードの制限のみが可能です。

スキーマ作成者は、スキーマから提供されるレコード タイプを変更しなくては なりません。この変更は、セキュリティ コンテキスト レコードを参照に追加し、さらに論理レコード タイプを複数のレコードに分割して実施されます。 レコードが複数に分割されると、個々のレコードの論理内容を別々に管理することができます。 この変更によって、内部のユーザー データベースにも顧客がアクセスできるようになります。(例えば、製品レコードが、 製品の説明、価格、生産コストを論理レコード内に持っている場合、 セキュリティ コンテキスト機能は、レコード全体へのアクセス権限のみ制限します、個々のレコードについては制限しません。したがって、 顧客がその製品の生産コストを知らない場合、その情報は別のレコードに 置かれなければなりません。)このような レコードの分割は非常に複雑であり、他の問題が発生する恐れがありますので、お勧めすることはできません。

シナリオ 3 のワークフロー

セキュリティ管理者は次の手順を実行します。

  1. CustUsers という顧客ユーザーのグループを作成します。
  2. 顧客用に作成されるユーザーは、顧客グループ CustUsers のみのメンバになります。
  3. 共用クエリー フォルダで、CustUsers に読み取り制限権限を認可します。
  4. 共用クエリーに顧客用フォルダの CustFolder を作成します。
  5. CustFolder で CustUsers に読み取り専用または読み書き可能権限を認可します。

顧客ユーザーには、ユーザー固有の個人用クエリー フォルダと、 CustFolder のみが、これらのフォルダ内の要素とともに表示されます。 読み取り専用権限が CustFolder に認可されていると、 顧客ユーザーは内容を作成したり変更したりすることはできません。このフォルダに 読み書き可能権限を持つ他のグループによって、このフォルダが管理されることになります。

CustFolder に読み書き可能権限も持っていると、 サブフォルダの作成を含む作成や変更が、このフォルダで可能です。 したがって、固有の管理をこのフォルダ内で実施することができます。

代替シナリオ 3a: 固有フォルダの顧客管理

前のシナリオでは、顧客ユーザーを 通常ユーザーと、顧客フォルダの内容を管理できるユーザーの 2 つの グループに別けています。この結果、共用クエリーのデフォルト設定 (ユーザーの大半は 読み取り専用アクセス権を持ち、選択されたユーザーにのみ読み取り書き込みアクセス権が 与えられる) に類似した方法で、CustFolder を使用できます。

これを達成するには、 セキュリティ管理者は、上記で概説した手順に次の手順を追加して実施します。

  1. CustAdmin という顧客管理者のグループを作成します。顧客向けに作成された ユーザーは、その役割に応じて CustUsers または CustAdmin のいずれかの メンバとなります。一部のユーザーは、両方のグループのメンバとなることも あります。
  2. 共用クエリー フォルダの CustAdmin と CustUsers の両方に読み取り制限権限を認可します。
  3. CustFolder フォルダで、CustUsers への読み取り専用権限を認可します (前のシナリオで説明しているように、 読み書き可能のオプションはありません)。
  4. CustFolder フォルダで CustAdmin に読み書き可能権限を認可します。

この場合、 CustAdmin のメンバは CustFolder の内容を変更できますが、CustUsers のみのメンバであるユーザーは、これができません。

代替シナリオ 3b: 複数の顧客グループ

規模の大きい顧客は、ClearQuest 内部データベースへの アクセス権が必要な内部グループを複数持っていることがあります。 この場合、顧客グループには独立グループと協力グループという 2 つのケースが あります。

最初のケースでは、2 つの顧客グループは独立していて、 互いのグループについて関知する必要がありません。 これは、完全に独立した 2 件の顧客と同様に扱われます。 ただ 1 つの実際問題は、 グループが複数あることを間違いなく示すように、ClearQuest グループと顧客フォルダにどのような名前を使用するかということです。 これは、必須セキュリティ ポリシーでは最重要である場合とそうでない場合があります。 例えば、「Acme1」と「Acme2」を名前に使用すると、 ただ 1 つのユーザーまたは「AcmeN」グループの数だけのユーザーを示します。 この場合の適切な命名は、読者の課題として残されます。

2 番目のケースでは、グループは協力関係にあり、それぞれが同じデータベースを 使用していることを認識しています。この場合、グループ名とフォルダ名は あまり重要ではありません。このケースに使用できる名前のバリエーションは、 グループ間でどの程度の共有が望ましいのかによりいくつか考えられます。標準的ケースでは、 個々のグループまたはグループの管理者が、それぞれ固有の顧客フォルダを 管理しますが、他のグループが読み取り専用アクセス権を持つことができます。 この場合、個々のグループに管理対象のグループが別にあるかどうか ( 代替シナリオ 3a: 固有フォルダの顧客管理 で概説しています) により、2 グループまたは 4 グループを必要とします。 別のバリエーションとして、グループが管理者役割を共有することが考えられます。これは、 前の代替ケースが使用される場合にのみ有効です。この場合に使用する ClearQuest グループ数は 4 ではなく 3 (顧客グループ用が 2 と、 共通管理者用が 1) ですみます。

代替シナリオ 3c: 協力関係の顧客

これは、 複数の顧客がシングル プロジェクトに関与しており、ClearQuest 内部データベース で同じデータを参照する必要があるという状態です。 この状態には次の 2 つの方法で対処できます。



フィードバック