GRC:ポリシーとコンプライアンス管理のドメインセパレーション
ドメインセパレーションでは、データ、プロセス、および管理タスクをドメインと呼ばれる論理的なグループに分けることができます。どのユーザーがデータを表示できるか、データにアクセスできるかなど、このアプリケーションのいくつかの側面を制御できます。
サポートレベル:ベーシック
- アプリケーションサービスプロバイダーのユースケースに合わせてデータが適切なドメインに送られるようにするビジネスロジックが存在します。
- このアプリケーションは、ドメインセパレーションを完全にサポートしています。ドメインセパレーションには、ユーザーインターフェイス、キャッシュキー、レポート、ロールアップ、および集計からのドメインの分離が含まれます。
- インスタンスのオーナーは、複数のテナント間で正常に機能するようにアプリケーションをセットアップする必要があります。
サンプルユースケース:サービスプロバイダーがチャットを使用してテナント顧客のメッセージに応答する場合、お客様がサービスプロバイダーの応答を確認できるようにする必要があります。
サポートレベルの詳細については、「アプリケーションでのドメインセパレーションのサポート)」を参照してください。
ポリシーとコンプライアンス管理 でドメインセパレーションテーブルを使用するメリット
- ビジネスエンティティ間で絶対的なデータ分離を適用する必要がある (データ分離)。
- 各ドメインのビジネスプロセス定義とユーザーインターフェイスをカスタマイズする (委任管理)。
- 単一のインスタンスでグローバルなプロセスとグローバルなレポートを維持します。
GRC でのドメインセパレーションの処理方法
GRC はデータの分離をサポートしていますが、ロジックおよびプロセスの分離を完全にはサポートしていません。
- GRC アプリケーション内のタイプのレコードの多くは、ユーザープロセスによって自動的に生成されます。エンティティ、コントロール、リスク、インジケーター、およびコントロールテストはすべて、自動的に生成できるレコードです。自動で生成されたレコード (および手動で生成された GRC レコード) の場合、レコードのドメインは、レコードの作成または生成を担当するユーザーのドメインと同じです。
- ドメインセパレーションされた GRC 実装で作業する場合は、自動生成を念頭に置いておく必要があります。ユーザーは、適切なドメインレベルでレコードを作成および生成して、それらが適切なユーザーセットに表示されるようにする必要があります。たとえば、次のドメインがあるとします。
* Global * Top * Domain A * Domain 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 を持つテーブル) は推奨されません。このユースケースでは、クライアントスクリプト、ビジネスルール、ワークフロー、プロセスなどをドメインセパレーションできます。
ドメインセパレーションでの動作がマルチテナントのサポートを提供している間は、マルチテナントはまだ単一のインスタンス内に含まれています。つまり、一部のグローバルプロパティ、グローバルデータ、およびグローバルプロセスは、すべてのドメインで共有されます。たとえば、ログインページのシステムの [記憶する] オプションはグローバルであり、ドメインごとに指定できません。
すべてのシステムのプロパティを完全に分離する必要があり、グローバルレポートまたはグローバルプロセスを必要としない場合、インスタンスの分離が最適なオプションです。
ポリシーとコンプライアンス管理オブジェクトへのドメイン値の割り当て
スケジュール済みジョブまたはバックグラウンドスクリプトのいずれかによって自動的に生成されたレコードは、すべてのポリシーとコンプライアンスオブジェクトの親オブジェクトまたはユーザードメインに基づいてドメイン分離されます。同様に、エンティティに基づいて自動生成されるコントロール、リスク、またはリスクアセスメントもドメイン分離する必要があります。
| ポリシーとコンプライアンス管理 のオブジェクト | ドメインソース |
|---|---|
| ポリシー | ユーザードメイン |
| 確認応答キャンペーン | ポリシードメイン |
| コントロール目標に対するポリシー | ポリシードメイン |
| 各種法令・基準等 | ユーザードメイン |
| 信頼できるソースコンテンツ | ドキュメントドメイン |
| コントロール目標 | ユーザードメイン |
| 引用するコントロール目標 | 引用ドメイン |
| ポリシー例外 | ユーザードメイン |
| ポリシー例外の承認 | ポリシー例外ドメイン |
| ポリシー例外関連レコード | ポリシー例外ドメイン |
| 確認応答 | KB 記事ドメイン |
| ポリシーのカテゴリ | ユーザードメイン |
| ポリシー例外統合レジストリー | ユーザードメイン |
| ポリシー例外リスク評価マッピング | ユーザードメイン |
| ポリシー/規制コンプライアンスステータス | ドキュメントドメイン |
| 理由の選択リスト | ユーザードメイン |
| 理由の選択肢 | ポリシー例外統合レジストリドメイン |
| 分類に対する各種法令・基準等 | 各種法令・基準等ドメイン |
| 分類に対する引用 | 引用ドメイン |
| コントロール | エンティティドメイン |
| エンティティコンプライアンスステータス | エンティティドメイン |
| エンティティへのコントロール | Control.Entity ドメイン |
| アイテムに対するコントロール目標 | コントロール目標ドメイン |
| エンティティタイプに対するコントロール目標 | エンティティタイプドメイン |
| ポリシーからエンティティタイプ | エンティティタイプドメイン |
| 記事テンプレート | ユーザードメイン |
| コンプライアンスデータソースレジストリ | ユーザードメイン |