データ配置ルールの設計（実験的および廃止予定） ( IBM Knowledge Catalog )

最終更新: 2025年1月29日

データ・ロケーション・ルールの設計には、データがあるロケーションから別のロケーションに移動する方向、ルールを適用するための基準、および対応する適用アクションが含まれます。

Experimental これは試験的リリースであり、実稼働環境での使用はまだサポートされていません。

重要:

データロケーションと主権に関するルールは、試験的な機能であり、廃止予定であり、2025年3月に削除される可能性があります。非推奨通知の詳細については、 Data Privacy のデータ保存場所と主権に関する規定の非推奨化をご覧ください。

ルールが適用されるデータの方向は、着信、発信、またはその両方にすることができます。ルールのデータ方向を着信として指定すると、ロケーションに入るデータが制限されます。ルールのデータ方向を発信として指定すると、その場所から出るデータは制限されます。この基準には、影響を受けるユーザー、データ資産の分類、またはデータ資産に割り当てられたその他のメタデータを含めることができます。適用アクションは、資産内のすべてのデータへのアクセスを拒否または許可したり、一部のデータをマスクして資産内の残りのデータへのアクセスを許可したりすることができます。

必要な権限

以下のユーザー権限が必要です。

データ・ロケーション・ルールを作成するには、 データ保護ルールの管理 権限が必要です。
ルールにガバナンス成果物を含めるには、 ガバナンス成果物へのアクセス 権限を持っている必要があります。また、ルールで使用したいガバナンス成果物のカテゴリーのコラボレーターでなければなりません。

権限がない場合は、プラットフォーム管理者に権限を付与するよう依頼してください。

データ・ロケーション・ルールの設定

データ・ロケーション・ルールの設定は、プラットフォーム内のすべてのデータ・ロケーション・ルールに影響します。データ・ロケーション・ルールの設定を構成するには、 https://api.dataplatform.cloud.ibm.com/v3/enforcement/settings API を呼び出します。データ保護ルールを作成するための前提条件を参照してください。

データ・ロケーション・ルールの有効化: デフォルトでは、データ・ロケーション・ルールは無効になっています。 enable_data_location_rules 設定を true に変更します。
データ・アクセス規則: デフォルトのデータ・アクセス規則は、以下のいずれかのオプションに設定できます。

AEAD: デフォルト。「すべての作成者の拒否を許可」規則に従います。ルールによって拒否されない限り、データへのアクセスを許可します。データへのアクセスを拒否するルールを作成します。
DEAA: 「Deny いろいろ作成者が許可する」規則に従います。ルールで許可されていない限り、データへのアクセスを拒否します。データへのアクセスを許可するルールを作成します。

データ・ロケーション・ルールのプロパティー

データ・ロケーション・ルールのプロパティーと動作は、他のガバナンス成果物とは大きく異なります。

プロパティーまたは動作	サポートしますか?	説明
固有の名前が必要ですか?	はい	各データ保護ルールには固有の名前が必要です。
説明?	はい	理解しやすいように、自然言語でルールが何を行うかを記述します。このルールの検索を容易にするために、標準的な用語を含めるようにしてください。
他のルールに関係を追加しますか?	いいえ	データ・ロケーション・ルールは相互に関係がありません。
他のガバナンス成果物に関係を追加しますか?	はい	データ・ロケーション・ルールの定義にガバナンス成果物を追加できます。データ・ロケーション・ルールは、その定義に含まれているガバナンス成果物の関連コンテンツタブに表示されます。データ・ロケーション・ルールをポリシーに追加することもできます。ただし、データ・ロケーション・ルールは、パブリッシュされたポリシーに含まれているかどうかに関係なく適用されます。
資産に関係を追加しますか?	はい	カタログ内の資産関係を参照してください。
カスタム属性を追加しますか?	いいえ	データ・ロケーション・ルールでは、カスタム属性はサポートされません。
カスタム関係を追加しますか?	いいえ	データ・ロケーション・ルールは、カスタム関係をサポートしません。
カテゴリーに編成しますか?	いいえ	データ・ロケーション・ルールはカテゴリーによって制御されません。これらは、プラットフォーム上のすべての管理対象カタログに適用され、すべてのユーザーに表示されます。
ファイルからインポートしますか?	いいえ	各データ・ロケーション・ルールは個別に作成する必要があります。
ファイルにエクスポートしますか?	いいえ	データ・ロケーション・ルールはエクスポートできません。
ワークフローによる管理しますか？	いいえ	データ・ロケーション・ルールは、作成後に公開され、アクティブになります。
開始日と終了日を指定しますか?	いいえ	データ・ロケーション・ルールは、作成後、削除されるまでアクティブになります。
スチュワードを割り当てますか?	いいえ	データ・ロケーション・ルールはスチュワードを持っていません。
タグを追加しますか?	はい	タグをプロパティーとしてデータ・ロケーション・ルールに追加することはできませんが、データ・ロケーション・ルールの定義にタグを含めることはできます。
資産に割り当てますか?	はい	資産にデータ・ロケーション・ルールを手動で割り当てることはできませんが、資産がルールの基準に一致すると、資産に対してルールが適用されます。
データ資産内の列に割り当てますか?	はい	資産内の列にデータ・ロケーション・ルールを手動で割り当てることはできませんが、データ・ロケーション・ルールは、列がルールの基準およびアクション・ブロック・ディレクティブと一致する場合に、列の値をマスクすることができます。
プロファイル作成中またはエンリッチ中の自動割り当て	いいえ	ユーザーがデータ資産にアクセスしようとすると、データ・ロケーション・ルールが適用されます。
[uncategord] カテゴリーの事前定義成果物	いいえ	すべてのデータ・ロケーション・ルールを作成する必要があります。

データ・ロケーション・ルールは、以下の 3 つのコンポーネントで構成されます：

データの方向

ルールを適用する方向を指定するか、両方向のデフォルトを受け入れることができます。データの方向は、データが物理ロケーションまたはソブリン・ロケーションに出入りするときに、データの制限が必要かどうかを決定します。データ方向が着信であることを指定すると、データへのアクセスを、データの移動先の場所に基づいて制限または許可することができます。データ方向を発信として指定すると、データの発信元の場所に基づいて、データへのアクセスを制限または許可することができます。

例えば、米国のユーザーがドイツに物理的に存在するデータにアクセスする必要があるとします。この例では、着信方向を選択した場合、米国に送られるデータを制御するルールを定義します。発信方向を選択する場合は、ドイツからのデータを制御するルールを定義します。

基準

この基準は、データ・ロケーション・ルールを適用するための条件を識別します。基準は、1 つ以上の条件で構成されます。条件は、データ資産のプロパティーを記述する 1 つ以上の述部、または演算子によって結合されるユーザーを識別する 1 つ以上の述部で構成されます。

述部のタイプとして、 全てを含む または 演算子を含まないのいずれかと、述部の特定の値を選択します。その後、 AND または OR ブール演算子を使用して述部と条件を結合し、正確な基準を使用してネストされた論理構造を作成できます。

述部	説明	特定の値
ターゲットの主権者	データの移動先のソブリン・ロケーションです。例えば、日本からのデータはドイツに送られます。ドイツは主権の対象だ。	ソブリンの追加をクリックして、1 つ以上のターゲット・ロケーションを選択してください。
ソースの主権者	データの送信元からのソブリン・ロケーションです。例えば、日本からのデータはドイツに送られます。日本は主権のソースである。	ソブリンの追加をクリックして、1 つ以上のソース・ロケーションを選択してください。
資産所有者	カタログ内の資産を所有するユーザーの E メール・アドレス (例えば、 jblue@example.com)。	1 つ以上のメール・アドレスを検索して選択します。
ビジネス用語	資産または列に割り当てられているビジネス用語。	公開されたビジネス用語を検索して選択します。
データ・クラス	顧客番号、生年月日、都市名など、データの内容を分類するカラムに割り当てられるデータクラスです。	公開されたデータ・クラスを検索して選択します。
タグ	資産または列に割り当てられているタグ。	1 つ以上のタグをコンマで区切って入力します。
ユーザー名	既存のカタログ・コラボレーターの名前または E メール・アドレス (例えば、 jred@example.com)。	1 つ以上のメール・アドレスを検索して選択します。
ユーザー・グループ	カタログ・コラボレーターになっているユーザー・グループの名前です。	1 つ以上のユーザー・グループを検索して選択します。
分類	資産に割り当てられている分類成果物です。	公開された分類を検索して選択します。

例えば、日本に到着する前に「PII」列と「住所」列にある英国のデータ資産を難読化するように設計された述部は、データ方向が着信すると以下のようになります：

If source sovereignty contains any United Kingdom
And
If the target sovereignty contains any Japan
Then
Obfuscate data in columns containing Column name
PII Address

アクション

データ・ロケーション・ルールのアクションにより、ルールを適用する効果が定義されます。このアクションにより、影響を受けるカタログ・メンバーは、条件によって指定された元のデータにアクセスしたり、表示したりすることができなくなります。ルールの評価時にソースとターゲットのソブリン・ロケーションが同じである場合、ルールは適用されず、データ・アクセスが許可されます。

3 つのタイプのアクションから選択します。

アクション	有効範囲 (Scope)	結果
データへのアクセスの拒否	データ資産のすべての列のすべてのデータ値	影響を受けるユーザーは、データ値をプレビューしたり、アセット・プロファイルを表示したり、アセット・データを使用したりすることはできません。
データへのアクセスを許可する	データ資産のすべての列のすべてのデータ値	影響を受けるユーザーは、データ値をプレビューしたり、アセット・プロファイルを閲覧したり、データを使用したり、アセットに対してアクションを実行したりすることができます。ユーザーは、アセットをダウンロードしたり、プロジェクトに追加したりすることもできます。
列の編集	マスキング基準に一致する列の値です	影響を受けるユーザーには、1 つの反復文字のストリングに置き換えられた値が表示されます。マスキングはプロジェクトに拡張できます。プロジェクトでのマスキングを参照してください。
列の難読化	マスキング基準に一致する列の値です	影響を受けるユーザーには、類似した値に同じ形式で置き換えられたデータが表示されます。マスキングはプロジェクトに拡張できます。プロジェクトでのマスキングを参照してください。
列の置換	マスキング基準に一致する列の値です	影響を受けるユーザーには、ハッシュ値に置き換えられたデータが表示されます。マスキングはプロジェクトに拡張できます。プロジェクトでのマスキングを参照してください。

マスキング

データをマスクするには、データが以下の要件に準拠している必要があります：

データは構造化されています。データは、リレーショナル表、CSV、Avro、パーティション・データ、または Parquet ファイル内になければなりません。
列ヘッダーには、英数字 (a から z、A から Z、0 から 9) のみが含まれます。列ヘッダーには、マルチバイト文字や特殊文字など、サポートされない文字を含めることはできません。

マスキング・アクションを選択する場合は、マスキング基準とマスキング方式を指定する必要があります。

マスキング基準

マスキング基準は、マスクする列を識別します。列プロパティーのタイプを選択し、そのプロパティーの 1 つ以上の特定の値を指定します。これらの値は、 OR 演算子と論理的に結合されます。

列プロパティーのタイプ	説明	特定の値
ビジネス用語	この列に割り当てられているビジネス用語です。	1 つ以上の公開済みビジネス用語を検索して選択します。
データ・クラス	列に割り当てられているデータ・クラスです。	1 つ以上の公開済みデータ・クラスを検索して選択します。
タグ	資産内の列に割り当てられているタグです。	1 つ以上のタグをコンマで区切って入力します。
列名	列の名前。	1 つ以上の列名をコンマで区切って入力します。

例えば、データ・クラスの列プロパティーと、カリフォルニア州の運転免許証およびネバダ州の運転免許証の特定の値を選択したとします。その後、値は、「カリフォルニア州の運転免許証」または「ネバダ州の運転免許証」のいずれかのデータ・クラスが割り当てられている列でマスクされます。

マスキング・メソッド

マスキング方式の主な違いは、データの元の特性がどの程度残っているかということです。データのオリジナル性が保たれれば保たれるほど、マスクされたデータの有用性は高まるが、安全性は低くなります。マスキング方式を選択する場合は、以下の要因を考慮してください：

データ整合性: 表の間の参照整合性を維持するために、反復元の値に対して同じマスク値を繰り返すかどうかのこと。
データ形式: 元のデータのフォーマットを保持するかどうかのこと。形式を保持するということは、文字が同じの大/小文字に置き換えられ、数字が数字に置き換えられ、文字数が同じであることを意味します。

以下の表では、各マスキング方式がこれらの特性にどのように影響するかを説明します。

方法	説明	整合性を保持しますか?	データ・フォーマットを保持しますか?
編集	値を 10 文字の X で置き換えます。最も安全な方法。	いいえ	いいえ
置換	値を、参照整合性を保持するランダムに生成された値に置き換えます。	はい	いいえ
難読化	値を、参照整合性および元のデータ・フォーマットを保持する値に置き換えます。最もセキュア度の低い方式。	はい	はい

仮想データの場合、マスキングの動作は、データ・フィールド定義によって若干異なります。仮想データのマスキングを参照してください。

編集

redact メソッドは、各データ値をちょうど 10 文字の X のストリングに置き換えます。リダクションされたデータでは、データのフォーマットとデータ保全性は保持されません。 Redact は最もセキュアなマスキング方式ですが、結果として、最も役に立たないマスク・データになります。

例えば、電話番号 510-555-1234 は XXXXXXXXXX に置き換えられます。その他の電話番号はすべて同じ値に置き換えられます。

拡張データ・マスキングを使用して、データ・クラスに基づく条件の拡張リダクション・オプションを指定できます。ただし、拡張データ・マスキングは自動的には適用されません。プロジェクト内の選択したデータ資産に適用してから、マスクされた資産をカタログに公開する必要があります。

置換

置換文字メソッドは、データを元の形式と一致しない値に置き換えます。ただし、カタログ内のすべての資産の反復値の参照整合性は保持されます。置換された値は無意味であり、値の元の形式は判別できません。置換文字は、Redact メソッドと Obfuscate メソッドの間のセキュリティーとデータの有用性を提供します。

例えば、電話番号 510-555-1234 は常に 500ddcc98133703531re3456 に置き換えられます。