制限付きビューの管理

オブジェクトタイプのバックアップに制限付きビューを使用する

特定のオブジェクトタイプの特定のオブジェクトへのアクセスを提供するために、Object Explorerでオントロジーマネージャーの元データセットとして制限付きビューを設定します。制限付きビューにバックアップされたオブジェクトタイプを正しく設定し、保存するには、制限付きビューの入力データセットに View アクセスが必要です。

制限付きビューファイルの権限

制限付きビューを作成し、編集するには、RolesインターフェースのGranular Permissions Administrationワークフローで以下の基準が満たされている必要があります。Rolesインターフェースにアクセスするには、設定に移動し、サイドバーのPlatform Settingsセクションで Roles を選択します。Rolesインターフェースへのアクセスには特別なプラットフォーム権限が必要です。このレベルのアクセスが必要な場合は、Palantir代表者にお問い合わせください。

制限付きビューを構築するには、入力データセットにビューアクセスがあり、出力制限ビューに編集権限が必要です。

Contour解析で制限付きビューを使用するには、制限付きビューを読み取る 権限が必要です。

制限付きビューにバックアップされたオブジェクトタイプを設定し、保存するには、以下が必要です：

• 制限付きビューの入力データセットへのビューアクセス。
• 制限付きビューへの編集アクセス（ポリシーの表示/設定/変更）。
• オントロジー管理グループのメンバー（オントロジーマネージャーへのアクセス用）。

Object Explorerでデータセットにバックアップされたオブジェクトにグラニュラポリシーを使用するには、このタイプのオブジェクトを見るためにデータセットに対する オントロジーデータソースを表示する 権限が必要です。

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

ポリシーの比較

制限付きビューのポリシーは、以下の比較タイプをサポートしています：

• Less Than: 比較の左側と右側は単一値（コレクションではない）で、同じタイプである必要があります。
• Less Than or Equal: 比較の左側と右側は単一値（コレクションではない）で、同じタイプである必要があります。
• Equal: 比較の左側と右側は単一値（コレクションではない）で、同じタイプである必要があります。
• Greater Than or Equal: 比較の左側と右側は単一値（コレクションではない）で、同じタイプである必要があります。
• Greater Than: 比較の左側と右側は単一値（コレクションではない）で、同じタイプである必要があります。
• Intersects: 少なくとも一方がコレクションで、両方が同じタイプ（またはそのタイプのコレクション）である必要があります。

ポリシーは、ユーザー属性、グループメンバーシップ、データ値をテンプレートに埋め込む形で定義されます：

グラニュラパーミッション付きリソースの消費アプリケーションがデータを要求するとき（Contourなど）、ポリシーテンプレートはユーザーの属性と権限に特定の行だけを返すクエリに変換されます。

ポリシーの制限

1つのポリシーには最大10の比較があります。制限付きビューのポリシーは、ポリシーがコレクションとフィールドを比較しているか、定数とフィールドを比較しているかによって、ポリシー内の各比較を重み付けします：

• 定数とフィールドの比較は、重み1が与えられます。
• コレクションとフィールドの比較は、重み1,000が与えられます。
• ポリシー内のすべての比較の重みの合計は10,000未満でなければなりません。

例えば、基本ポリシーでは：

• ルール（1）は、定数（ユーザーのID）とフィールドをマッチングしているので、重み1が与えられます。
• ルール（2）は、コレクション（ユーザーがメンバーであるすべてのグループ）と特定のPlatform Administrators groupをマッチングしているので、重み1,000が与えられます。
• このポリシーの重みの合計は1,001（10,000の制限をはるかに下回っています）。

現在のポリシー構築制限は、特定のポリシーデザインに最小限の制約を設けることを目指して設計されており、重み制限を超過する可能性のあるポリシーに対する保護はほとんど提供していません。

ポリシーを構築する際に重み制限のエラーが発生した場合は、Palantir代表者に連絡して支援を求めてください。

ポリシー管理

ポリシーの変更は、制限付きビューの新たなトランザクションとして記録されますが、一部のユーザーはポリシー変更管理に関して追加の制御を必要とするかもしれません。

制限付きビューポリシーを管理する際には、以下の2つの目標を考慮してください：

• 透明性: データアクセスを管理する責任者は、ポリシーとポリシーがプラットフォーム内のデータとどのように相互作用するかを理解しているべきです。
• 堅牢な変更管理: ポリシー管理は、整然とした、組織的なプロセスであるべきです。常に変更をレビューし、適用する前に管理してください。

データパイプラインの整合性の管理

制限付きビューポリシーは、それらをバックアップするデータについての一連の仮定を導入します。したがって、制限付きビューポリシーは、これらの仮定が真実である限り、データへのアクセスを正しく制御します。仮定が破られた場合でもデータが安全に保たれるように、それらの仮定が保持される機械を構築する必要があるかどうかを考慮してください。

この問題を解決する一つの方法は、制限付きビューの直上流のパイプラインに、データに対して行われた仮定をチェックするステップを導入することです。これらのチェックには以下が含まれます：

• 不変条件: event_occurred_in_state が NY の値を持つ場合、データセットの別の行 state_name は New York の値を持つべきだと仮定します。ユーザーにこのデータを提示する 前に Transformがこれが真実であることを確認します。
• 統計: 統計のセットと、それらが常に範囲内にあるべきであることを定義します。例えば、制限付きビューは、組織階層を反映したアクセス制御を実施するために使用されるかもしれません。各ユーザーは、自分より下の階層にある人々についてのデータだけを見ることができます。Transformは、階層の20％以上が一日のビルドから次のビルドに変更された場合、何かが間違っていると主張します。この時点で、ポリシー管理を担当するユーザーは、すべてが正しいことを確認した上で、このデータをユーザーに提示すべきです。

制限付きビューの制限

制限付きビューはデータセットに似ていますが、いくつかの重要な違いがあります。制限付きビューの内容は、2つの動的要素を組み合わせます：（1）ポリシー定義と（2）特定の時間点で制限付きビューにアクセスする特定のユーザーの属性とグループメンバーシップです。ポリシー定義の履歴は制限付きビューのトランザクション履歴で維持されますが、すべてのユーザー属性とグループメンバーシップの完全な履歴をトランザクション履歴で維持することは不可能です。

制限付きビューは、個々のユーザーがパイプラインを分析的に消費することを簡略化するように設計されており、データ変換の入力としては使用できません。Foundryで構築されたパイプラインは、それを実行する特定のユーザーに関係なく再現可能でなければならず、これは制限付きビューがユーザー属性に依存する行レベルの権限を提供する性質とは互換性がありません。

• 制限付きビューを持つパイプラインで協力しようとするユーザーは、ポリシー文にアクセスできないかもしれませんし、同じユーザー属性とグループメンバーシップのセットを持っていないかもしれません。そのため、各ユーザーが制限付きビューで異なる行や集計を見る可能性があります。したがって、ユーザーは、グラニュラパーミッション付きデータに基づくワークフローがFoundryの通常のデータセットリソースに基づくワークフローと同様に振る舞うとは限らないと考えるべきです。
• 下流変換では、後続の下流変換がポリシー行を保持することを保証するための強制がありません。それに対して、制限付きビューは読み取り専用であり、制限されたデータの露出につながる可能性のある方法でスキーマや行の変更を保護するためです。

以下のリストは、制限付きビューの現在の制限をまとめたものです：