サーバー構成 > アクセス制御リスト権限 > 権限の計画の策定 > サンプル ACL 実装
サンプル ACL 実装
管理者が特定のサイトでポリシーと権限を実装する方法を説明するために、2 つの主要なソフトウェア プロジェクトを開発中の xyzBusiness 社の例を使用します。
xyzBusiness の DemoApp チームは、企業の健全性のために不可欠なアプリケーションを開発する既存の部門です。一方、DemoDotCom プロジェクトは、将来の多角化のために新しいオンライン製品や領域を実験的に調査しています。これら 2 つのプロジェクトには、別々の管理手法と運営ポリシーが必要です。
• 主要な収益源であることから、DemoApp が予定通りの進捗であることを確認し、確実に期日に出荷できるように管理する必要があります。DemoApp の制御は比較的厳しく行う必要があります。
• DemoDotCom プロジェクトは未知の領域を調査するよう設計されているため、それほど厳格なポリシーは必要ありません。実際には、誤りの訂正や開発の変更は簡単なものにします。
次の項では、xyzBusiness の管理者が DemoApp の重要な局面を考慮する一方で DemoDotCom に必要な自由と革新性を許容する、コンフィギュレーション管理の ACL を設定する方法を説明します。
XyzBusiness の環境では、大きく異なる 2 つの開発業務をサポートしています。管理者が最初に実施する必要があるのは、サイト全体の制御パラメータを設定することです。ただし、xyzBusiness の管理チームは、価値あるデータの保護を強化するために、開発環境に厳重なロックを適用したいと考えています。その結果、リビジョンコントロール プロセスの整合性を維持するために、すべてのメンバー ファイルを書き込み保護にします。
この規則を実装するために、管理者は、グローバルコンフィギュレーション管理ポリシー オプションの排他的ロック ポリシーを有効にして強制的に適用します。詳細については、コンフィギュレーション管理ポリシー オプションを参照してください。
次に、各プロジェクトの開発者に適切な権限を与え、セキュリティ違反を招く可能性のある重複がないことを保証します。
さまざまなユーザーのニーズを調査した後で、管理者は登録されたすべてのユーザーが次のアクションを実行できるようする必要があると判断します。
• プロジェクト、サンドボックス、およびメンバー履歴を開く
• プロジェクト メンバーまたはアーカイブされたリビジョンの読み取り専用のコピーをチェックアウトする
• プロジェクトのサマリー レポートを表示し、アクティビティをアーカイブする
これを実現するために、管理者は最初に mks:si ACL の everyone グループに次の ACL 権限のセットを定義して、サイト全体の権限を制限します。
• Login
• FetchRevision
• OpenProject
この権限で管理者は、プロジェクト ACL で追加の権限が割り当てられない限り、サイトに登録されたユーザーが必要な操作だけを実行できるようにします。登録されていないユーザーは、Windchill RV&S のコンフィギュレーション管理機能にアクセスできません。
最後に、各プロジェクト チームのメンバーに適切な権限を割り当てます。
xyzBusiness のプログラマの大多数はいずれか一方のプロジェクトに取り組んでいますが、一部は両方にかかわっています。管理者の課題は、各チームのプログラマに重複しないように異なる権限を付与する ACL エントリを設定することです。
一部のプログラマは両方のプロジェクトにかかわっているため、管理者はネットワーク認証システムに DemoApp 開発者というロールと DemoDotCom 開発者というロールを作成することにします。各プロジェクトの ACL のロールに異なる権限を定義することで、管理者は同じプログラマにプロジェクトごとに異なる権限を割り当てることができます。
xyzBusiness の管理者は、各プロジェクトの開発者グループに許可の権限を定義します。
DemoApp 開発者mks:si:project:id:DemoApp
DemoDotCom 開発者mks:si:project:id:DemoDotCom
CheckIn
ApplyLabel
FetchRevision
AddMember
Lock
CheckIn
Login
Checkpoint
OpenProject
CreateProject
CreateSubproject
Demote
DropMember
FetchRevision
Lock
Login
OpenProject
Promote
次に、管理者は各ロールのユーザーを割り当てます。DemoApp チームのプログラマは DemoApp プロジェクトの開発者ロールに定義された権限だけを付与され、DemoDotCom のプログラマは DemoDotCom プロジェクトの開発者ロールに定義された権限だけを付与されます。
この結果、DemoApp のプログラマはプロジェクトとそのメンバー ファイルを自由に操作できます。サンドボックスの作成、チェックイン、チェックアウトなどができますが、次の操作を行うことはできません。
• プロジェクト メンバーの昇格または降格
• メンバーの追加または削除
• 新しいプロジェクトまたはアーカイブの作成
• ラベルの追加
これらの権限は、管理上の制御要件を満たしながら、プログラマが必要なファイルを自由に更新できるようにします。
コンフィギュレーション管理の権限の詳細な説明については、コンフィギュレーション管理の権限を参照してください。
DemoDotCom プロジェクトの開発者グループでは状況が異なります。この権限では、すべてのチーム メンバーにプロジェクトへのよりオープンなアクセスを許可します。DemoDotCom プロジェクトには調査を目的とする創造的な性質があり、DemoApp ほど厳格な制限セットは必要ありません。
これは役に立ちましたか?