制限付きビュー

概要

マーキング や ロール は強力なアクセス制御を提供しますが、より細かい権限設定が必要な場合もあります。例えば、特定のタイプのオブジェクトすべてにアクセス権を付与するのが不十分であったり、不適切であったりする場合があります。制限付きビューを利用すると、このような追加のアクセス制御が提供されます。

ユーザーは Foundry で制限付きビューのリソースを操作し、制限付きビューはグラニュラーパーミッションによって動作します。制限付きビューは、ユーザーが閲覧することが許可されている行だけをデータセットにアクセスすることができるように制限します。制限付きビューは、元のデータセット上に構築され、変換の入力としては使用できません。制限付きビューの ポリシー は、ユーザーが閲覧できる特定の行を決定し、通常は制限付きビューの作成時にオーナーロールを持つユーザーによって定義されます。制限付きビューが作成されると、オントロジー内のオブジェクトタイプの基となるデータソースとして使用できます。例えば、制限付きビュー内の1行がオントロジー内の1つのオブジェクトに対応している場合、制限付きビューは、制限付きビューがバックアップしているオブジェクトタイプに基づいてユーザーが表示できるオブジェクトを制御します。

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

ポリシーは制限付きビューの核心です。制限付きビューのポリシーとは、ユーザー属性、列、および/または値を比較するルールや論理演算子のセットであり、ユーザーが閲覧できる行を決定します。制限付きビューのポリシーは柔軟で、以下のようなさまざまな比較や用語に対応しています。

• ユーザー属性: ユーザー ID、ユーザー名、グループ ID、グループ名、組織マーキング ID、マーキング、ユーザーのメールアドレスなど。
• 列名: 制限付きビューの元データセット内の列。
• 具体的な値: 文字列、ブーリアン、数値、または配列。

ほとんどのポリシーでは、ユーザー属性と比較される少なくとも1つの用語が含まれます。ユーザーベースの権限付与には、少なくとも1つの用語が必要です。

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

異なるオブジェクトを異なるユーザーに表示するオブジェクトタイプを構築したいとします。まず、制限付きビューのポリシーを設計する必要があります。次の質問を考慮してください。

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

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

おすすめ

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

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

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

制限付きビューの作成

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

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

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

名前を付けて保存

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

グラニュラーポリシーを構成

以下の用語を使用して、ルールベースのポリシーを作成できます。

• ユーザー属性: ユーザー ID、ユーザー名、グループ ID、グループ名、組織マーキング ID、マーキング、ユーザーのメールアドレスなど。
• 列名: 制限付きビューの元データセット内の列。
• 具体的な値: 文字列、ブーリアン、数値、または配列。

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

アクセス要件の確認

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

概要

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

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

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

マーキング対応の制限付きビューを作成する

マーキングの列を持つデータセットを元にした制限付きビューを作成できます。各行は、必要なマーキングアクセスを持つユーザーだけが表示できます。例えば、以下の制限付きビューでは、ユーザーが最初の行を表示するには 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 の列を複数持つことができます。
• 同じ列にマーキングと組織を混在させることができます。

例えば、以下のデータセットには、各行に単一のセキュリティマーキングが含まれています。

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

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

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

サポートされている機能

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

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

制限付きビューを製品に追加するには、まず製品を作成し、次に以下のように制限付きビューコンテンツタイプを選択します。

制限付きビューを製品に追加すると、制限付きビューのポリシーがパッケージ化されますが、データは含まれません。