GRCのドメインセパレーション
ここではドメインセパレーションと ガバナンス、リスク、コンプライアンス アプリケーションの概要を示します。 ドメインセパレーションでは、データ、プロセス、および管理タスクをドメインと呼ばれる論理的なグループに分けることができます。どのユーザーがデータを表示できるか、データにアクセスできるかなど、このアプリケーションのいくつかの側面を制御できます。
- ビジネスエンティティ間で絶対的なデータ分離を適用する必要がある (データ分離)。
- 各ドメインのビジネスプロセス定義とユーザーインターフェイスをカスタマイズする (委任管理)。
- 単一のインスタンスでグローバルなプロセスとグローバルなレポートを維持します。
サポートレベル：ベーシック
- アプリケーションサービスプロバイダーのユースケースに合わせてデータが適切なドメインに送られるようにするビジネスロジックが存在します。
- このアプリケーションは、ドメインセパレーションを完全にサポートしています。ドメインセパレーションには、ユーザーインターフェイス、キャッシュキー、レポート、ロールアップ、および集計からのドメインの分離が含まれます。
- インスタンスのオーナーは、複数のテナント間で正常に機能するようにアプリケーションをセットアップする必要があります。
サンプルユースケース：サービスプロバイダーがチャットを使用してテナント顧客のメッセージに応答する場合、お客様がサービスプロバイダーの応答を確認できるようにする必要があります。
サポートレベルの詳細については、「アプリケーションでのドメインセパレーションのサポート)」を参照してください。
GRC におけるドメインセパレーションの仕組み
- GRC はデータの分離をサポートしていますが、ロジックおよびプロセスの分離を完全にはサポートしていません。
-
GRC アプリケーション内のタイプのレコードの多くは、ユーザープロセスによって自動的に生成されます。エンティティ、コントロール、リスク、インジケーター、およびコントロールテストはすべて、自動的に生成できるフィールドです。自動的に生成されるレコードの場合、レコードのドメインは、ジョブに構成されたドメイン反復子によって決定されます。それ以外の場合は、デフォルトドメイン (定義されている場合) またはグローバルドメインがデフォルトになります。手動で生成されたレコードの場合、ドメインはレコードを作成するユーザーのドメインから派生します。
ドメインセパレーションされた GRC 実装で作業する場合は、自動生成を念頭に置いておく必要があります。ユーザーは、適切なドメインレベルでレコードを作成および生成して、それらが適切なユーザーセットに表示されるようにする必要があります。
たとえば、次のようなドメインがあるとします。- グローバル
- トップ
- ドメイン A
- ドメイン B
- ドメイン A および B のユーザーによって評価されるリスクまたはコントロールがある場合は、リスクまたはコントロールをグローバルレベルで生成するか、手動で作成する必要があります。リスクまたはコントロールがドメイン B で作成された場合、インデックス作成が原因で、ドメイン A でリスクまたはコントロールを再作成することはできません。
- トップおよびドメイン A のユーザーによって評価されるリスクまたはコントロールがある場合は、ドメイン A でリスクまたはコントロールを作成できます。
リスクとコントロールがグローバルドメイン内にない限り、ユーザーは上位のドメイン内にあるリスクまたはコントロールケースを、下位のドメインのユーザーにアサインできません。上記の例では、トップドメインにコントロールがある場合、証明書のために、そのコントロールをドメイン A または B のユーザーにアサインしないでください。これらのユーザーはコントロールにアクセスできないため、証明書またはアセスメントのアンケートは生成されません。
同様に、ユーザーは、上位ドメインのコントロール目標とリスクステートメントを下位ドメインの証明書とアセスメントにアサインしないでください。アサインすると、証明書またはアセスメントアンケートが生成されません。
ユースケース
IT 用の GRC データを他の部門の GRC データから分離できます。GRC アプリケーションを使用している各ビジネスエリアは、他の部門と共有できない分離データを保有できます。そのため、各部門には独自のエンティティ、ポリシー、コントロール、リスクなどがあります。
IT ドメインからのコントロールを調べる場合、ユーザーはドメインスコープを展開してファイナンスドメインの値を表示するか、ドメインスコープを折りたたんで IT ドメインに一致するコントロールのみを表示するかを選択できます。
デフォルトでは、ドメインセパレーションは、タスク [task] および構成アイテム [cmdb_ci] テーブルとその拡張に、ドメインフィールドを追加します。
sys_domain フィールドをテーブルの辞書定義に追加することで、作成する任意の新しいテーブルにドメインセパレーションを拡張することができます。デフォルトでは、システム専用ドメインは、適切な場合に、プラットフォームとベースラインアプリケーションテーブルを分離します。
[sys_dictionary] や辞書エントリの上書き [sys_dictionary_override] テーブルなど、sys_prefix を持つテーブル) は推奨されません。このユースケースでは、クライアントスクリプト、ビジネスルール、ワークフロー、プロセスなどをドメインセパレーションできます。
ドメインセパレーションでの動作がマルチテナントのサポートを提供している間は、マルチテナントはまだ単一のインスタンス内に含まれています。つまり、一部のグローバルプロパティ、グローバルデータ、およびグローバルプロセスは、すべてのドメインで共有されます。たとえば、ログインページのシステムの [記憶する] オプションはグローバルであり、ドメインごとに指定できません。
すべてのシステムのプロパティを完全に分離する必要があり、グローバルレポートまたはグローバルプロセスを必要としない場合、インスタンスの分離が最適なオプションです。
ドメイン値を GRC オブジェクトに割り当てる方法
自動的に生成されるレコード。レコードのドメインは、ジョブに構成されたドメイン反復子によって決定されます。次の表は、ドメイン値がさまざまな GRC オブジェクトにどのように割り当てられるかを示しています。
| GRC オブジェクト | ドメインソース |
|---|---|
| エンティティ | Applies_to からドメイン値を取得します。 |
| エンティティからエンティティタイプ (Entity to entity type) | エンティティタイプからドメイン値を取得します。 |
| アイテムアセスメント | アイテム (リスクまたはコントロール) からドメイン値を取得します。 |
| イシュー | アイテム (リスクまたはコントロール) からドメイン値を取得します。 |
| エンティティから情報オブジェクト | エンティティからドメイン値を取得します。 |
| インジケーター | コントロールまたはリスクからドメイン値を取得します。 |
| インジケータータスク | インジケーターからドメイン値を取得します。 |
| サポートデータ | インジケーターからドメイン値を取得します。 |
| インジケーターの結果 | インジケーターからドメイン値を取得します。 |