データリレーションシップフレームワーク
データリレーションシップフレームワーク アプリケーション (sn_grc_rel_config) は、CMDB、BIA、BCP などのさまざまなソースから BIA、計画、およびイベントの依存関係をフェッチするための基礎となるフレームワークを備えた BCM アプリケーションをサポートします。オーストラリア リリース以降、データリレーションシップフレームワーク (sn_grc_rel_config) アプリケーションは BCM アプリケーションとともにデフォルトでインストールされます。
依存関係を取得するためのフレームワーク
データリレーションシップフレームワーク (sn_grc_rel_config) には、メインオブジェクトタイプを他のオブジェクトタイプに関連付ける方法の設定が保存されます。これにより、ユーザーは依存関係の更新のソース (メインノード) を構成し、子ノードとの関係を構成し、選択したオブジェクトの依存関係をフェッチできるようになります。
スケジュール済みジョブは、オブジェクト構成データを定期的にスキャンし、依存関係が更新されているかどうかをチェックします。依存関係に変更が見られる場合、スケジュール済みジョブは、設定されたソース (BIA、BCP、CMDB など) のいずれかから選択されたオブジェクトの依存関係をフェッチします。
データリレーションシップフレームワーク のメリット
- さまざまなソースから依存関係をフェッチするための単一の API を提供します。
- メインノード (ソース) の構成をサポートし、資産やリスクなどの子ノードとの関係を維持します。
- ユーザーがさまざまなソースを選択してパフォーマンスを制御できるようにします。
データリレーションシップフレームワーク に関連付けられたロール
| ロール | 説明 |
|---|---|
| データリレーションシップフレームワーク アドミニストレーター [sn_grc_rel_config.admin] | メインノードと子ノードの関係など、オブジェクトタイプの関係を構成します。 |
| データリレーションシップフレームワーク リーダー [sn_grc_rel_config.reader] | データリレーションシップフレームワークで定義されているオブジェクトタイプのデータを表示します。 注: すべての BCM アプリケーションユーザーには、データリレーションシップフレームワーク のリーダーロールがあります。 |
フレームワークのテーブル
| 新規および既存のテーブル | テーブル | 説明 |
|---|---|---|
| 新規テーブル | メインノード構成 [sn_grc_rel_config_main_node_confi] | 依存関係のフェッチ元であるメインノードの構成を保存するテーブル。 |
| 新規テーブル | ノード関係構成 [sn_grc_rel_config_node_rel_config] | メインノードと子ノードの依存関係を決定する構成を保存するテーブル。また、メインノード構成への参照も保持します。 |
| 既存のテーブル | 関係のレジストリ [sn_data_registry_relationship] | オブジェクトと他のオブジェクトの関係を決定するテーブル。 |
関係を構成するためのモジュール
BCM アプリケーションユーザーは、アプリケーションナビゲーターでデータ関係フレームワークに移動し、そのモジュールにアクセスして関係を構成できます。
メインノード構成：次の例に示すように、名前、ソース、テーブル名、ファイラー条件などのメインノードの詳細を設定します。
次の例に示すように、次のメインノード構成がベースシステムのソースとして提供されます。
- BIA アップストリーム依存関係
- BIA ダウンストリーム依存関係
- CMDB
- プライマリ資産の計画
- 関連資産の計画
BCM アドミニストレーターは、メインノード構成を使用して、次のタスクを実行します。- 影響分析依存関係の更新構成モジュールを構成し、これらのソースから依存関係の更新を BIA にフェッチします (依存関係の更新を BIA に追加します)。
- 計画依存関係の更新構成モジュールを構成し、これらのソースから依存関係の更新を計画にフェッチします (更新された関連資産を計画に追加します)。
- イベント依存関係のソース構成モジュールを構成し、イベント依存関係の更新のソースを構成します (更新された影響を受ける資産を復旧イベントに追加します)。
注:データのプル方法に関するすべての情報は、レコードに添付されているメインノード構成に保存されます。この構成によって、データがプルされる順序が決まります。プルされるデータの量とそのプル方法を減らすには、メインノード構成とレコードの両方で条件を設定する必要があります。これにより、必要なデータのみが取得されます。計画のメインノード構成レコードと CMDB を次の例に示します。
メインノード構成レコードの作成については、「メインノード設定レコードの作成」を参照してください。
関係のレジストリ：メインノードの関係のレジストリを構成します。関係レジストリは GRC の360 度構成の一部であり、ユーザーは 1 つのオブジェクトがどのように関連オブジェクトを持つかを定義できます。名前、テーブル、関係タイプ、関係テーブルなど、関係レジストリレコードの構成の詳細がフォームに表示されます。
BIA および BIA テンプレートの関係レジストリレコードのサンプルを次の例に示します。
関係レジストリレコードの作成については、「関係レジストリレコードの作成」を参照してください。
プロパティ：データリレーションシップフレームワーク のプロパティを次の例に示すように構成します。
プロパティの構成方法については「データリレーションシップフレームワーク のプロパティ設定」を参照してください。
データリレーションシップフレームワーク のユースケース
データリレーションシップフレームワーク は、メインノードをその子ノードにマッピングしたり、資産をリスクにマッピングしたりするなど、ノードと資産の関係を構成するために使用されます。
メインノード構成とその関係を示す次のようなユースケースを考えてみましょう。
- 資産 A：資産 A の影響を受ける構成アイテムはリスク A です。
- INC1011：INC1011の影響を受ける構成アイテム (CI) は資産 B と資産 C です。資産 B に関して影響を受ける構成アイテムはリスク B です。
- メインノード：
- INC1010 -> 資産 A
- INC1010 -> INC1011
- ノードの関係：
- 資産 A -> リスク A
- INC1011 -> 資産 B
- INC1011 -> 資産 C
- 資産 B -> リスク B
- 入力ノード：
- ソース = インシデント
- レコード = INC1010
- 最大レベル = 5
- 最大ノード数 = 1000
- 出力ノード：
- INC1010
- 資産 A
- INC1011
- リスク A
- 資産 B
- 資産 C
- リスク B
- エッジ：
- INC1010 -> 資産 A
- INC1010 -> INC1011
- 資産 A -> リスク A
- INC1011 -> 資産 B
- INC1011 -> 資産 C
- 資産 B -> リスク B
データリレーションシップフレームワーク の使用制限
- オブジェクトに対してフェッチされたデータを別の目的で再利用することはできません。
- フレームワークで提供されるソースは、依存関係の更新をオブジェクトにフェッチするために使用する必要があります。データをフェッチするための独自のソースを設定することはできません。
設定レコードの管理セットアップの詳細については、「 依存関係構成情報レコード」を参照してください。