 |
広範なアクセス許可の要件に対応するには、コンテキストから独立した参加者を使用してください。これによってチームのサイズが最適なレベルに維持され、システムの処理リソースへの影響が小さくなります。アクセス許可に関するニーズがコンテキストによって異なる場合は、コンテキスト固有の参加者を使用します。
|
|
|
広範なアクセス許可の要件に対応するには、コンテキストから独立した参加者を使用してください。これによってチームのサイズが最適なレベルに維持され、システムの処理リソースへの影響が小さくなります。アクセス許可に関するニーズがコンテキストによって異なる場合は、コンテキスト固有の参加者を使用します。
|
|
システムリソースの効率
|
 |
|
使用に最適なケース
|
一定の参加者グループのアクセス許可要件が、アプリケーションコンテキストごとに変化しない場合。
|
|
使用方法
|
チームには、参加者を一切追加しません。代わりに、必要なアクセス許可をアクセス制御規則を通じて付与します。
|
|
例
|
例 1
組織内のあらゆるパブリック製品の特定タイプのデータに対する読み取りアクセスが組織全体に付与されている必要があります。この場合に考えられる選択肢の 1 つは、組織のすべてのユーザーを、あらゆる製品のゲスト役割に追加することです。これは、処理能力を大量に消費するアプローチになります。これに代えて、適切な管理ドメイン (組織の「/Default/PDM」ドメインなど) 内で、特定のオブジェクトタイプへの読み取りアクセスを、アクセスポリシー規則を通じてユーザーに提供するという方法があります。
例 2
特定のユーザーグループが、公開されているあらゆるアプリケーションコンテキストでコンプライアンスレビューの機能を実行します。コンプライアンスレビューの役割を確立し、グループに含まれているユーザーをあらゆるアプリケーションコンテキストのこの役割に追加すると、不要なオーバーヘッドが増大します。これに代えて、適切な管理ドメイン (サイトの / (ルート) ドメインなど) 内で、コンプライアンスレビューユーザー定義グループのアクセスポリシー規則を通じて、必要なアクセス許可をユーザーのグループに提供するという方法があります。
|
|
その他の検討事項
|
アプリケーションコンテキストチームのメンバーではないユーザーの場合、ユーザーインタフェースの製品、ライブラリ、プログラム、またはプロジェクトリストのページには、アプリケーションコンテキストが表示されません。ただし、ユーザーはアプリケーションコンテキストをサーチできます。適切なアクセス許可をユーザーが持っていれば、アプリケーションコンテキストが見つかります。アプリケーションコンテキストは、アクセスされるとナビゲータの「最近アクセス」リストにロードされ、以降に使用するときは、これらのリストで見つけることができます。
こういったユーザーが、チームメンバー以外には自動的に表示されない操作にアクセスする必要がある場合、チームの「役割の操作を設定」設定を使用すると、それらの操作がチームメンバー以外に表示されるようになります。このような規則は、コンテキストテンプレートを通じて新しいコンテキストに自動的に提供できます。ワークフローへの参加など、一部の操作も、チームメンバー以外のユーザー向けに別途でセットアップしなければならない場合があります。
アプリケーションコンテキストに含まれているさまざまなタイプのデータにナビゲートする、こうしたユーザーに関して必要になるアクセスポリシー規則は、ケースバイケースで異なります。それらのアクセス許可を特定して、適切に付与する必要があります。
|
|
関連情報
|
アクセス制御規則によるデータへのアクセスの管理を参照してください。
|
|
システムリソースの効率
|
 |
|
使用に最適なケース
|
• 参加者が、アプリケーションコンテキスト内にあるオブジェクトに、コンテキストにおける役割に基づいてアクセスする必要があります。
• 変更点がほとんどあるいはまったくない、互いに類似する多数のアプリケーションコンテキストに対しては、同一のチーム構造を適用できます。
• 同一のユーザーまたはグループが、それらのアプリケーションコンテキストすべてで同一の役割を担います。
• ローカルで拡張することにより、追加的なニーズに応えることができます (下記の「その他の検討事項」を参照)。
|
|
使用方法
|
• 共有チームは、汎用的な性質のアクセス許可がユーザーに提供されることから、多くの場合、ライブラリチームに使用されます。
• その他の場合は、複数の共有チームを作成することにより、一連の多様な製品やプロジェクトに対応できます。
|
|
その他の検討事項
|
共有チームは、ローカルで拡張されない場合に最も効率が高まります。チームをローカルで拡張することによって作成されるローカルチームインスタンスは、共有チームがもたらすと期待されている、パフォーマンス上の利点のいくつかを目減りさせるものになります。あらゆるローカルチームで共有チームがどの程度まで修正されているかによっては、共有チームの真価がまったく発揮されないこともあり得ます。
|
|
関連情報
|
チームメンバーシップによるデータアクセス管理を参照してください。
|
|
システムリソースの効率
|
 |
|
使用に最適なケース
|
• 参加者が、アプリケーションコンテキスト内にあるオブジェクトに、コンテキストにおける役割に基づいてアクセスする必要があります。
• チーム構造は、アプリケーションコンテキストごとに固有です。
• チーム役割で機能する参加者は、アプリケーションコンテキストごとに固有です。
|
|
使用方法
|
• 責任範囲に基づいて、概略的なユーザーグループを作成します。
• チームの特定の役割にグループを追加します。
• コンテキストごとにそれぞれ固有のユーザーグループを作成しないでください。再利用可能なユーザーグループの使用を検討します。
|
|
その他の検討事項
|
理想的には、ローカルチームに配置しなければならない参加者の数は、最適な数にします。
|
|
関連情報
|
チームメンバーシップによるデータアクセス管理を参照してください。
|
|
チームの設計に際しての非効率的な慣行
|
欠点
|
ベストプラクティス
|
|
あらゆるチームのゲスト役割 (またはその他の役割) に、組織内のあらゆるユーザーを追加することで、アプリケーションコンテキストのデータに対する読み取りアクセス許可を付与する。
|
チーム構造を非常に大きなものにすると、システムリソースの需要が大幅に増大します。
|
ポリシー規則を使用して、基本的なアクセス許可を提供します。チームに直接関連付けなければならないユーザーの数は、適正な数にします。
|
|
あらゆるチーム用に何百もの役割を作成することで、アクセス許可を非常にきめ細かく制御する。
|
チーム構造を非常に大きなものにすると、システムリソースの需要が大幅に増大します。
|
特殊な役割を数多く定義すると、パフォーマンス上のトレードオフとなることに留意してください。チームの役割の数は適正な数にします。
|
|
製品テンプレートまたはライブラリテンプレートを使用して、すべての製品またはライブラリ内のチーム役割に作成する必要がある同じポリシーアクセス制御規則を指定する。
|
この結果、あらゆる製品の同じ役割向けに、同じポリシーアクセス制御規則を作成するという不要な重複が生じます。
|
可能な場合、ポリシーアクセス制御規則は、あらゆるアプリケーションコンテキスト内で同じものを作成するのではなく、組織レベルでダイナミック役割を対象として作成します。詳細については、アクセス制御規則でのダイナミック役割の使用を参照してください。
|
|
製品の役割の割当用に、固有のユーザーグループをその場で作成する。グループは再利用されず、単一の製品に固有のものです。
|
参加者のメンバーシップが互いに類似した、多数のユーザーグループが作成される可能性があります。それに伴って、ユーザーグループの維持管理が複雑化し、LDAP に過大な負荷がかかります。
|
コンテキストごとに固有のユーザーグループを作成するのではなく、再利用可能なユーザーグループにユーザーを整理します。または、ユーザーグループを作成してそれらのグループを役割に関連付けるのではなく、ユーザーをチームに直接関連付けます。2 番目の方法は、最初の方法ほど効率的ではありません。
|