計画

プロジェクト・セキュリティーの計画には 4 つの基本的なステップがあります。
  1. Rational® Change ユーザーのロールを特定します。ロールには、テスター、開発者、チーム・リーダーなどのタイトルが含まれることがあります。

    これらのタイトルは、ユーザーの職能に大まかに対応しています。 ただし、ユーザーが複数のロールを備えること、さらには異なるプロジェクトで異なるロールを備えることが許容されます。

  2. 提出、検証、レビュー、割り当て、完了、および特定の属性を修正するための許可などのロールを実行するために必要な権限を判別します。

    これらの権限を使用して、変更依頼プロセスを定義します。 次に、必要とされる権限の観点からロールを定義します。

  3. IBM® Rational Directory Server ユーザーをグループに分割します。

    既にグループがある場合もありますが、ロールとプロジェクトの組み合わせ (例えば、特定のプロジェクトに対する開発者) に基づいて、プロジェクト固有の追加グループを作成します。

  4. 製品別、リリース別、チーム別など、論理的に関連した CR セットを特定します。

    これらの関連セットをグループ・メンバーおよびそのロールに結合して、プロジェクトを形成します。

セキュリティー・モデルのマイグレーション

従来のデータベース・セキュリティー・モデルからプロジェクト・セキュリティーを使用した動的権限へのマイグレーションは、手動プロセスです。 このプロセスは、以下の 2 つのハイレベル・ステップから成ります。
  1. プロジェクト・セキュリティーを定義します。
  2. Rational Change だけで使用されていたすべてのデータベース権限を Rational Synergy から削除します。

複数サーバーの影響

プロジェクト・セキュリティー、ロール、およびグローバル割り当ては、Rational Directory Server に保管され、グローバルになります。 同じ Rational Directory Server を共有する 2 つの Rational Change サーバーが、プロジェクト・セキュリティーおよびロールの定義を共有します。 同様に、既存の Rational Change サーバーが異なる Rational Directory Server を指すようにした場合は、異なるプロジェクト・セキュリティー・セットアップになります。

注: プロジェクト・セキュリティーおよびロールの定義は、Rational Change サーバーから定義されている場合でも、Rational Change サーバーではなく、Rational Directory Server に従います。

段階デプロイメント

実稼働環境でプロジェクト・セキュリティーを変更する代わりに、分離したステージング環境で変更を行います。 結果を実稼働環境にデプロイできます。その後、実稼働前に、システムを実験および検証できます。

このタイプのデプロイメントが必要になるのは、ステージング環境と実稼働環境が別個の Rational Directory Server を使用する場合のみです。 そうではない場合は、プロジェクト・セキュリティー定義は Rational Directory Server に保持されていて、両方の Rational Change サーバーに共通のものであるため、データは既に共有されています。

この目的のために、以下の 2 つの Perl API が提供されています。
  • ExportProjectSecurityData
  • ImportProjectSecurityData

インポートは、デフォルトでは非破壊的です。つまり、既存データをオーバーライドするのではなく、増強します。 詳しくは、Perl API ヘルプを参照してください。


フィードバック