制限付きビュー

マーキングとロールは、強力なアクセス制御を提供します。ただし、状況によっては、より細かな権限設定が必要です。たとえば、特定のタイプのすべてのオブジェクトへのアクセスを許可するだけでは不十分、または不適切な場合があります。企業が営業担当者に対し、担当支店の顧客のみを閲覧できるように制限する場合のように、オブジェクトタイプによっては、ユーザーごとに異なるオブジェクトを表示する必要があります。制限付きビューは、この追加のアクセス制御を提供できます。

ユーザーは Foundry で制限付きビューのリソースを操作し、制限付きビューは Granular Policy に基づいて動作します。制限付きビューは、データセットへのアクセスを、ユーザーが閲覧権限を持つ行のみに制限します。制限付きビューは元データセットの上に構築され、新しいデータセットを生成するトランスフォームやその他のバッチ派生ジョブの入力には使用できません。制限付きビューのポリシーは、ユーザーが閲覧できる具体的な行を決定します。通常、制限付きビューの作成時に、所有者ロールを持つユーザーが定義します。作成後は、制限付きビューをオントロジーのオブジェクトタイプの元データソースとして使用できます。たとえば、1行が1個のオブジェクトを表す場合、制限付きビューは、それを元データソースとするオブジェクトタイプに基づいて、ユーザーが閲覧できるオブジェクトを制御します。

制限付きビューのポリシーは、ユーザーが読み取れるデータを絞り込みます。関数、アクション、AIP Logic、オントロジー SDK のレスポンス、ライトバック操作、エクスポートには適用されません。モデル全体については、アクセス制御の伝播を参照してください。

制限付きビューのポリシー

ポリシーは制限付きビューの中核です。制限付きビューのポリシーは、Granular Policyを使用して、ユーザーが閲覧できる行を決定します。Granular Policy は、ユーザー属性、列、値を比較するルールと論理演算子で構成されます。

• ユーザー属性： データを閲覧するユーザーのプロパティです。
• 列名： 制限付きビューの元データセットにある列です。
• 固定値： 文字列、ブール値、数値、または配列です。

すべてではないにしても、ほとんどのポリシーには、ユーザー属性と比較される語句が1つ以上含まれます。ユーザーに基づく権限設定には、このような語句が1つ以上必要です。

ユーザー、グループ、または組織を参照する場合、ポリシーの列とポリシー定義の両方に一意の識別子（UUID）が必要です。名前変更に伴う問題を防ぐため、ID の代わりに名前を指定することには対応していません。

以下の例では、制限付きビューのポリシーに、適用可能な2つのルールが含まれています。

推奨事項やベストプラクティスを含め、Granular Policy の設計については、詳しくはこちらを参照してください。ユーザー属性、ポリシーの比較、ポリシーの制限事項に関する情報も確認できます。

制限付きビューのポリシーの設計を決めたら、そのポリシーを機能させるために必要なパイプラインとプロジェクトの変更を行います。制限付きビューのポリシーとパイプラインが整ったら、制限付きビューの作成に進めます。

制限付きビューを作成する

所有者ロールまたは必要な権限を持つユーザーは、右クリックのコンテキストアクションを使用して、データセットの下流に制限付きビューを作成できます。

制限付きビューの作成ダイアログには、次のステップがあります。

1. 名前を付けて保存： 制限付きビューの名前と、ファイルシステム内での保存場所を選択します。
2. Granular Policy の作成： 制限付きビューまたはオブジェクトにアクセスするときに、ユーザーが閲覧できる行やオブジェクトを決定するポリシーステートメントを定義します。
3. アクセス要件の確認： 上流データセットと下流の制限付きビューの両方について、既存のファイルレベルおよびトランザクションレベルのマーキングを確認します。適切な権限があれば、制限付きビューからマーキングを外す（削除する）ことができます。
4. 概要： 制限付きビューの作成と初回ビルドの前に、選択内容を確認します。

名前を付けて保存

制限付きビューに名前を付け、保存場所を選択します。通常は、入力データセットとは異なるプロジェクトに制限付きビューを保存します。これにより、制限付きビューを利用するユーザーが、下流のプロジェクトに対する閲覧権限を持てるようになります。また、入力データセットと同じプロジェクトに制限付きビューを保存することもできます。マーキングを使用して入力データセットを保護します。

Granular Policy を作成する

ユーザー属性、列名、特定の値を使用して、ルールに基づくポリシーを作成できます。詳細については、制限付きビューのポリシーを参照してください。

アクセス要件を確認する

機密データに制限付きビューを通じてのみアクセスすべきユーザーには、上流データセットへのアクセス権を与えないでください。このステップでは、データセットと作成中の制限付きビューの両方について、アクセス要件を確認できます。適切なマーキング権限があれば、制限付きビューから継承されたマーキングを外したり、上流データセットにマーキングを適用したりできます。

概要

概要には、データセットと制限付きビューの両方について、最終的に提案されたアクセス制御が表示されます。概要の内容に問題がなければ、作成を選択すると、制限付きビューの初回ビルドが開始されます。

制限付きビューが作成されると、入力データセットが更新されるたびに再ビルドするビルドスケジュールが、バックグラウンドで自動的に作成されます。

制限付きビューをオブジェクトタイプの元データソースとして使用する方法については、管理ドキュメントを確認してください。

マーキングを元にした制限付きビューを作成する

マーキングの列を含むデータセットを元に、制限付きビューを作成できます。各行は、必要なマーキングへのアクセス権を持つユーザーのみが閲覧できます。たとえば、以下の制限付きビューでは、1行目を閲覧するには A1 と A2 の両方が必要で、2行目を閲覧するには B1 が必要です。

マーキングを元にした制限付きビューを作成するには、次の手順に従います。

1. 制限付きビューとして保護する、1列以上のマーキング列を含むデータセットを用意します。各セルには、マーキングIDの STRING ARRAY を含める必要があります。上流データセットの期待される形式について詳しくはこちら。
2. データセットプレビューのインターフェースで「列」タブに移動し、列を選択して「タイプクラスを追加」を選択し、marking_type.mandatory を入力して、各マーキング列にアノテーションを付けます。この手順は Granular Permissions が機能するために必須ではありませんが、Foundry の一部のインターフェースでは、列をより適切に表示するためのヒントとして使用されます。

3. データセットを元に制限付きビューを作成します。ポリシールールの左側は「ユーザーのマーキング」にします。右側では「列」を選択し、マーキング列を選択します。列が複数ある場合は、列ごとにルールを作成し、必要に応じて AND または OR ルールで組み合わせます。

上流データセットの期待される形式

制限付きビューの作成元となるデータセットには、マーキングIDの列が含まれている必要があります。

• これらの ID は、汎用一意識別子（UUID）です。
• 列のデータ型は STRING ARRAY である必要があります（マーキングIDのリストを含めます）。
• マーキングIDの列は複数あってもかまいません。
• 同じ列にマーキングと組織を混在させることもできます。

たとえば、このデータセットにはマーキングのリストが含まれています。以下のサンプル CSV は Foundry に直接アップロードできます。ただし、推論されたスキーマを手動で変更する必要があります。詳細 > スキーマに移動し、"type": "STRING" を "type": "ARRAY", "arraySubtype": { "type": "STRING" } に変更します。

制限付きビューを Marketplace 製品に追加する

Foundry DevOps を使用すると、制限付きビューを Marketplace 製品に含めて、ほかのユーザーがインストールして再利用できるようにできます。初めての製品を作成する方法について詳しくはこちら。

サポートされる機能

string と boolean の定数のみがサポートされます。定数は、フィールド（列）または「ユーザーのグループ」というユーザープロパティとのみ比較できます。Marketplace は現在、同じフィールドを使用する複数のフィールドと定数の比較条件に対応していません。

制限付きビューを製品に追加する

制限付きビューを製品に追加するには、まず製品を作成し、次に出力を追加します。ファイルを追加… を選択して、Compass のファイルシステム内で制限付きビューに移動し、製品に追加します。

制限付きビューを製品に追加すると、制限付きビューのポリシーがパッケージ化されます。データはパッケージ化されません。ポリシー定義は宛先環境に適用され、読み取り時に、その環境のユーザー属性とグループ所属に照らして評価されます。Marketplace は、ポリシーが依存するユーザー属性やグループ所属の状態をパッケージ化しません。また、パッケージ化することもできません。ポリシーが意図どおりに動作するために必要な属性とグループが宛先環境に存在することを確認する責任は、インストール担当者にあります。ポリシーは、宛先環境でユーザーが読み取れる内容を絞り込みますが、制限付きビューから派生した下流の作成物には適用されません。モデル全体については、アクセス制御の伝播を参照してください。