Repository のセキュリティの確立
Repository コンテンツのセキュリティは、Repository の管理者がセキュリティ センターを使用して、特定のグループ、ロール、および権限を作成してユーザーに割り当てることによって管理します。
メモ： 予想外のロックアウトを避けるため、Admin ユーザーは削除できません。
たとえば、JimB というユーザーを作成し、DBA というロールを割り当てます。この DBA ロールには多くの権限が付与されていますが、どの権限でも論理モデルの変更は許可されていません。Repository の管理者は Repository 内の任意のモデルを JimB に関連付けることができ、それにより JimB は、ダイアグラムの論理モデルの変更はできませんが、表示はできるようになります。
管理者は、Repository 項目に対するユーザーおよびグループのアクセスを、プロジェクト、ダイアグラム、モデル、サブモデル、およびデータ ディクショナリのレベルで制限することができます。Repository へのアクセスを制限するには、管理者がユーザーを作成し、そのユーザーにデフォルトのロールを割り当てるか、そのユーザー固有の権限を付与するか、新しいロールを作成してユーザーに割り当てます。または、ユーザー グループを作成して、その特定のグループにロールを割り当てることもできます。管理者はこれらの方法で、一部の Repository 項目に対するフル アクセスを許可し、その他の項目へのアクセスを制限または拒否することができます。
ユーザー、グループ、およびロールを作成する前に、管理者は Repository に関する次の概念を理解しておく必要があります。
- カスケード セキュリティ： Repository に多数のダイアグラムがある場合、たとえばユーザーがダイアグラムの多くに対して同じ権限を必要とする場合などに、管理者がユーザーに対してグローバルにロールを簡単に割り当てられるようにするために、管理者は ER/Studio Repository のさまざまな「レベル」に対してユーザーやロールを割り当てることができます。
たとえば、多数のダイアグラムを含むプロジェクトを ER/Studio Repository に作成することができます。このプロジェクトに対するロールをユーザーに割り当てる場合、プロジェクトに含まれるすべてのダイアグラムに同じ権限のセットが付与されます。Repository そのものは、下位レベルにカスケードされる権限を割り当てるための最上位レベルのポイントとして機能します。
下位のレベルで同じユーザーに別のロールを割り当てることで、上位レベルを上書きすることができます。たとえば UserA に、Repository レベルでは［ビューア］ロールを割り当て、特定のダイアグラムまたはサブモデルについては［モデル作成者］ロールを割り当てることができます。
- クライアント側セキュリティ キャッシュ： 切断モデリング連携（たとえば ER/Studio Repository からログアウトし、場合によってはネットワークから切断されている状態）の概念を推進するために、ユーザーが ER/Studio Repository にログインしたときに、ダイアグラムによってユーザーに関連付けられているすべてのセキュリティがクライアント上にキャッシュされます。
メモ： セキュリティが変更されたときには、ユーザーはログインし直して権限を更新する必要があります。
- スーパー ユーザー： ［スーパー ユーザー］は、ER/Studio Repository のインストール時に作成されるデフォルトのロールの 1 つです。［スーパー ユーザー］ロールは、デフォルトの Admin ユーザーに割り当てられます。このユーザーにはすべての権限が付与されているため、ER/Studio Repository で管理されるダイアグラム、ユーザー、およびロールに対してあらゆる操作を実行できます。スーパー ユーザーは削除も編集もできず、セキュリティ センターの［Repository のセキュリティ］領域でのみ確認できます。
- アクセス権なし： ［アクセス権なし］ロールは、Repository のプロジェクト レベルおよびダイアグラム レベルでのみ適用できます。これは、特定のプロジェクトで管理されるダイアグラムまたは個別のダイアグラムに対する任意のアクセスを防ぐための、便利で汎用的なメカニズムです。たとえば、グループを作成し、あるプロジェクトに対する［アクセス権なし］ロールを割り当てると、そのグループに追加されるどのユーザーもそのプロジェクトにアクセスできません。
- 累積的な権限： グループ メンバシップによってユーザーに付与される権限は累積的なものです。ユーザーは、自身に付与されたすべての権限に加えて、グループ メンバシップによって与えられる権限を持つことになります。
メモ
- ユーザーが Repository からファイルを取得するときに、ER/Studio Data Architect は、その特定のファイルについてユーザーとマシンの組み合わせを追跡します。さらに、オフライン状態のときまたは Repository Server に接続できないときにユーザーがモデリングを行えるように、ER/Studio Data Architect は、ユーザーおよびダイアグラムのセキュリティ権限に関する情報をファイルとともに保存します。これにより、次のような効果があります。
- ユーザーが Repository にログインし、現在ログインしているユーザー以外のユーザー/マシンの組み合わせが Repository から取得した DM1 ファイルを開こうとすると、ER/Studio Data Architect によって、競合のためファイルを開けないというメッセージが表示されます。これにより、別のユーザーが先に取得したダイアグラムに対して、ユーザーが操作したり変更をチェックインしたりするのを防ぎます。Repository は、ユーザーとマシンに基づいてオブジェクトのチェックアウトを追跡するので、オブジェクトをチェックアウトしたマシン上のユーザーだけがオブジェクトを再びチェックインすることができます。
- ユーザーが Repository にログインしていない場合でも、ER/Studio Data Architect で Repository DM1 ファイルを開いて作業することができます。Repository からファイルを取得したユーザーに関するセキュリティ権限データを ER/Studio Data Architect が読み込み、ユーザーが Repository にログインするかファイルを閉じるまでの間、作業セッションの残りの部分はそのセキュリティ データによって制御されます。ユーザーが Repository にログインしていないときに複数のファイルを開く場合は、すべてのファイルを同じユーザーが取得する必要があります。このことは、ユーザーがログインしているときにも適用されます。
- 各ダイアグラムとともに保存されるキャッシュされたセキュリティ データは、Repository にログインしている間、開いている Repository ファイルを保存するたびに更新されますが、ファイルを閉じる前に保存しなかった場合、そのユーザーとダイアグラムに対するセキュリティ権限に対する変更があっても、変更はファイルとともにキャッシュされません。このため、オフラインで作業する予定があり、ファイルを最後に保存してからセキュリティ設定を変更した場合には、Repository にログインしている間に各ファイルを開いて、オフライン作業に入る前にファイルを保存する必要があります。
- 権限の設定はプロジェクト レベルまたは Repository レベルで適用できるため、ユーザーがオフラインの間に 2 つのファイルを開くと競合が発生する可能性があります。開かれた 2 つのファイルの両方に、Repository レベルまたは同じプロジェクトについてキャッシュされたセキュリティ情報があり、それらのキャッシュされたデータが異なっている場合、保存の日時が新しいほうのデータが使用され、ファイルを保存するときに両方のファイルに保存されます。
- 管理者がセキュリティ センターで変更を加えた場合、たとえばフォルダの権限を変更してアクセス権の付与または取り消しを行ったり、異なる権限が設定されたプロジェクト間でダイアグラムを移動したりした場合は、ユーザーは Repository にログインし直して、アクセス許可を更新する必要があります。
このセクションには、次のトピックも含まれています。