注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Granular Policy を使用すると、データセットとオブジェクトに行レベルのセキュリティを設定できます。制限付きビューとオブジェクトセキュリティポリシーは、Granular Policy を使用して、ユーザーがアクセスする権限を持つ行やオブジェクトのインスタンスを特定します。
Granular Policy は、ユーザー属性、列またはプロパティ、および値を比較して、ユーザーが閲覧できるデータを決定するルールと論理演算子で構成されます。Granular Policy は柔軟で、さまざまな比較や語句に対応しています。
Granular Policy を作成する前に、次の点を検討してください。
Granular Policy を設計する際は、次のガイドラインを推奨します。
Granular Policy で使用できるユーザー属性は次のとおりです。
ri.multipass..organization. で始まる組織IDではありません。ユーザー、グループ、または組織を参照する場合、ポリシー列とポリシー定義の両方に一意の識別子 (UUID) が必要です。名前の変更に伴う問題を防ぐため、ID の代わりに名前を指定することはできません。
グループ、マーキング、または組織のメンバーシップに対して NOT 条件を使用しないでください。これらの状況で NOT 条件を使用することは設定ミスに該当します。プラットフォームは、ユーザーの権限の一部のみを含むスコープ付きトークンに対応しています。これらのトークンには、NOT 条件が確認する属性が含まれていない場合があり、その結果、条件を満たして意図した以上のアクセスが許可される可能性があります。
Granular Policy は、次の比較の種類に対応しています。
オブジェクトセキュリティポリシーは、「より小さい」および「より大きい」の比較演算子に対応していません。
ポリシーは、ユーザー属性、グループメンバーシップ、およびデータ値を埋め込めるテンプレートとして定義されます。ポリシーを利用するアプリケーションがデータをリクエストすると（Contour など）、テンプレートはクエリに変換されます。このクエリは、ユーザーの属性と権限に合致する行またはオブジェクトのみを返します。
1つのポリシーに含められる比較は最大10個です。Granular Policy では、フィールドに対して集合と定数のどちらを比較するかに応じて、ポリシー内の各比較に重みを割り当てます。
たとえば、基本的なポリシーでは次のようになります。
現在のポリシー構築時の制限は、個々のポリシー設計への制約をできるだけ控え目にするよう設計されています。重みの上限を超える可能性のあるポリシーに対しては、ほとんど保護機能がありません。
ポリシーの構築時に重みの上限に関するエラーが発生した場合は、Palantir サポートにお問い合わせください。
Granular Policy を管理する際は、次の2つの目標を考慮してください。
Granular Policy は、その元となるデータについていくつかの前提を導入します。そのため、Granular Policy がデータへのアクセスを正しく制御できるのは、これらの前提が成立している間だけです。前提が成立することを保証し、前提が崩れた場合にもデータの保護を維持する仕組みを構築する必要があるかどうかを、ユースケースに応じて検討してください。
この問題を解決する方法の1つは、リソースの直上流にあるパイプラインに、データに関する前提をチェックするステップを導入することです。これらのチェックには、次のようなものが考えられます。
event_occurred_in_state の値が NY のときは常に、データセット内の state_name という別の列の値が New York であるべきだとします。このデータをユーザーに公開する前に、この条件が成立していることをトランスフォームでチェックします。これらの整合性チェックは、Granular Policy が依存する上流のデータを保護し、ポリシーが引き続き行を正しく絞り込めるようにします。ポリシーを下流の出力やエクスポートに拡張するものではありません。データが下流に流れる際にも保護を維持するには、Granular Policy と併せて、基となるデータにマーキングまたは機密情報区分に基づくアクセス制御を適用します。モデル全体については、アクセス制御の伝播を参照してください。