制限付きビュー

概要

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

ユーザーは Foundry で制限付きビューリソースと対話し、制限付きビューは細かい権限設定によって支えられています。制限付きビューは、ユーザーが見る権限を持つ行にのみデータセットへのアクセスを制限します。制限付きビューは元データセットの上に構築され、トランスフォームの入力として使用することはできません。制限付きビューの ポリシー は、ユーザーが見ることができる特定の行を決定し、通常、制限付きビューを作成する際にオーナーロールを持つユーザーによって定義されます。作成後、制限付きビューはオントロジー内のオブジェクトタイプの基となるデータソースとして使用できます。たとえば、制限付きビューの 1 行がオントロジー内の 1 つのオブジェクトによって表される場合、制限付きビューは、制限付きビューがバックしているオブジェクトタイプに基づいてユーザーが見ることができるオブジェクトを制御します。

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

ポリシーは制限付きビューの核心です。制限付きビューのポリシーは、ユーザー属性、列、および/または値を比較してユーザーが見ることができる行を決定するルールおよび/または論理演算子のセットです。制限付きビューのポリシーは柔軟であり、さまざまな比較と用語をサポートできます。たとえば：

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

ほとんどのポリシーは、ユーザー属性と比較される少なくとも 1 つの用語を含みます。ユーザーに基づいた権限設定には、少なくとも 1 つの用語が必要です。

ユーザー、グループ、または組織を参照する場合、ポリシーにはポリシー列およびポリシー定義の両方に一意の識別子 (UUID) が必要です。名前ではなく ID を指定することは、名前の変更に関連する問題を防ぐためにサポートされていません。

ユーザー属性

以下は、制限付きビューのポリシーでサポートされるユーザー属性のリストです：

• ユーザー ID: Foundry によって各ユーザーに生成される一意の ID。
• ユーザー名: ログイン時にユーザーのアイデンティティプロバイダーによって提供される一意の ID。
• グループ ID: ユーザーがメンバーであるすべてのグループの ID (直接および継承)。
• グループ名: ユーザーがメンバーであるすべてのグループの名前 (直接および継承)。
• 承認済みグループ ID: これは スコープセッション に関連する高度な概念です。スコープセッションで制限付きビューを使用する場合は、Palantir 管理者に連絡してください。
• 組織マーキング ID: ユーザーがメンバーであるすべての組織のマーキング ID (主およびゲスト)。これらは UUID であるマーキング ID であり、ri.multipass..organization. で始まる組織 ID では ありません。
• マーキング ID: ユーザーが閲覧権限を持つすべてのマーキングの ID。
• カスタム属性: Control Panel でユーザーのアイデンティティプロバイダーによって設定されたカスタム属性。

制限付きビューのポリシーを設計する

異なるユーザーに異なるオブジェクトを表示するオブジェクトタイプを構築したいと仮定します。最初のステップは、制限付きビューのポリシーを設計することです。以下の質問を考慮してください：

• オントロジー内のデータへのアクセスをどのように制限しますか？
• ポリシーで使用できるユーザー属性は何ですか？
• ポリシーが依存する可能性のあるデータ内の列はどれですか？
• パイプラインを通過するマーキングはどれですか？制限付きビューを作成する際に非マーキングにすることができますか？
• 新しいユーザーにオブジェクトの権限をどのように付与しますか？

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

推奨事項

制限付きビューを設計する際には、次のガイドラインをお勧めします：

• シンプルに保つ: 制限付きビューを作成する前に、実施したいポリシーを書き出します。そのポリシーに必要な最小限の条件を決定します。ポリシーが複雑になるほど、管理と検証が難しくなります。
• ポリシー列が非 null であることを確認する: ポリシー列に null 値がある行は、すべてのユーザーにとってアクセス不可になります。ポリシー列に null 値があると、そのテーブルの Phonograph 同期にも失敗します。
• パイプラインを活用する: 現在のデータの形状やフィールドに適合しないポリシーの複雑さを軽減するために、ポリシー作成を容易にする列を計算するためにパイプラインを使用します。複雑さを制限付きビューのポリシーではなくパイプラインで処理するようにしてください。
• 専用のポリシー列を使用することを検討する: ポリシーで参照される元データセットの列に加えられた変更は、ポリシーの前提を壊す可能性があります。このリスクからポリシーを保護するために、ポリシーを決定するロジックを分離し、ポリシーが参照する専用の列 (または複数の列) を作成することを検討してください。
• 属性を使用する: 属性ベースのポリシーは、しばしば最もシンプルなオプションになることがあります。属性は SSO から取得するか、ユーザーマネージャーを通じて投稿することができます。
• マーキングを使用する: ポリシーの元データセットにマーキングを適用し、その保護を保証し、マーキングにアクセス権を持つユーザーにのみ表示されるようにします。制限付きビューはすでにユーザーが見ることができる行を制御しているため、制限付きビューでマーキングを継承する必要はありません。機密データがソースでマーキングされ、マーキングが正しく伝播されている場合、制限付きビューを作成する際に新しいマーキングは不要です。

制限付きビューのポリシーの設計が完了したら、必要なパイプラインとプロジェクトの変更を行います。制限付きビューのポリシーとパイプラインが整ったら、制限付きビューの作成に進むことができます。

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

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

制限付きビュー作成ダイアログには、以下の手順があります：

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

名前を付けて保存

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

詳細なポリシーを作成

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

アクセス要件を確認

制限付きビューを通じてのみ機密データにアクセスする必要があるユーザーは、上流のデータセットにアクセスできないようにする必要があります。このステップでは、データセットと作成する制限付きビューの両方のアクセス要件を確認できます。適切なマーキング権限がある場合、制限付きビューから継承されたマーキングを削除したり、上流のデータセットにマーキングを適用したりできます。

概要

概要では、データセットと制限付きビューの両方の最終的な提案されたアクセス制御が表示されます。概要の結果に満足したら、作成 をクリックして制限付きビューの初期ビルドを開始します。

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

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

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

マーキングの列を含むデータセットに基づいて制限付きビューを作成できます。各行は、必要なマーキングアクセスを持つユーザーのみに表示されます。たとえば、以下の制限付きビューでは、最初の行を表示するには A1 と A2 の両方が必要であり、2 番目の行を表示するには B1 が必要です。

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

1. 制限付きビューとして保護される 1 つ以上のマーキング列を含むデータセットを準備します。各セルには、STRING マーキング ID または STRING ARRAY のマーキング ID のいずれかを含める必要があります。上流のデータセットの 期待される形式 について詳しく学びます。
2. データセットプレビューインターフェースの COLUMNS タブに移動し、列を選択して、「タイプクラスを追加」をクリックし、marking_type.mandatory を入力して、各マーキング列に注釈を付けます。これは細かい権限設定が機能するためには必要ありませんが、Foundry の一部のインターフェースはこれをヒントとして使用し、列を適切にレンダリングします。

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

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

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

• これらの ID は一意の識別子 (UUID) です。
• 列は STRING 型である必要があり、各セルに単一のマーキング ID が含まれるか、STRING ARRAY 型であり、マーキング ID のリストが含まれている必要があります。
• 複数のマーキング ID 列を持つことができます。
• 同じ列にマーキングと組織を混在させることができます。

たとえば、次のデータセットには、各行に 1 つのセキュリティマーキングが含まれています：

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

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

Foundry DevOps を使用して、Marketplace 製品 に制限付きビューを含め、他のユーザーがインストールして再利用できるようにします。最初の製品を作成する方法を学びます。

サポートされている機能

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

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

制限付きビューを製品