オントロジーの構築オブジェクトの権限設定Ontologyの権限

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

オントロジーの権限

オントロジーリソースの閲覧、編集、管理の権限は、Palantir プラットフォームのファイルシステムである Compass で管理されます。オントロジーリソースはプロジェクトに保存され、選択したプロジェクトによって、誰が閲覧、編集、管理できるかが決まります。

この機能は、新しいオントロジーでは有効になっています。既存のオントロジーでは、オントロジーの所有者が手動で機能を有効にする必要があり、既存のオントロジーリソースの移行が必要になります。

このプロジェクトベースの権限管理は、従来の権限モデルであるオントロジーロールとデータソース由来の権限に代わるものです。次のような利点があります。

  • 統一された権限モデル: オントロジーリソースはほかのリソースタイプと同じ権限システムを使用するため、権限の仕組みの学習と管理を1か所で行えます。
  • 一括管理: プロジェクトまたはフォルダーレベルで権限を設定することで、複数のリソースへのアクセスを一度に制御でき、項目ごとに権限を設定する必要がなくなります。
  • 権限の説明機能:****セキュリティタブには、オブジェクトタイプの閲覧と編集に必要な権限、およびインスタンスの閲覧やアクションの実行に必要な権限が表示されます。
  • 追加のプライバシー制御: マーキングを適用するか、ユーザーにロールが付与されていないプロジェクトに配置することで、機密性の高いオントロジーリソースを非表示にできます。
  • Compass の整理機能: ポートフォリオとタグを使ってオントロジーリソースを整理し、ロールの付与やマーキングを使ってユーザーに無関係なリソースを非表示にできます。

プロジェクトへの移行によって、元データソースにアクセスできるユーザーが変わることはありません。データソースを元にするオブジェクトタイプでは、オブジェクトを閲覧するために、引き続きオブジェクトタイプとデータソースの両方に対する権限が必要です。

元データソースを持たないオブジェクトタイプは、プロジェクトに保存し、プロジェクトベースの権限を使用する必要があります。また、誰がオブジェクトを閲覧できるかを決めるために、オブジェクトセキュリティポリシーも必要です。

プロジェクトベースの権限の例

プロジェクト A にファイルとして保存された Building というオブジェクトタイプを考えます。Building を閲覧、編集、管理できるかどうかは、プロジェクト A でのロールによって決まります。プロジェクト A の編集者であれば、Building オブジェクトタイプを編集できます。特定の Building オブジェクト(Empire State Building など)を閲覧するには、オブジェクトタイプに対する閲覧者ロールに加えて、オブジェクトタイプのセキュリティ設定に応じて、元データソースへのアクセス、またはオブジェクトとプロパティのセキュリティポリシーによって付与されるアクセスが必要です。

プロジェクト内のオントロジーリソース。

オブジェクトタイプに対する閲覧権限しかない場合、スキーマや連絡先情報などの情報のみを閲覧でき、実際のデータは閲覧できません。必要な権限を確認するには、Compass のプロジェクトサイドパネルを参照してください。

オブジェクトタイプとオブジェクトを閲覧する

オブジェクトタイプとオブジェクトでは、権限の設定方法が異なります。オブジェクトタイプを閲覧するには、オブジェクトタイプに対する閲覧権限が必要ですが、元データソースに対する閲覧権限は必要ありません。

オブジェクトを閲覧するには、オブジェクトタイプに対する閲覧権限と、データへのアクセスが必要です。基になるデータへのアクセスは、オブジェクトタイプのセキュリティ設定によって決まります。

  • オブジェクトとプロパティのセキュリティポリシー: オブジェクトを閲覧できるかどうかは、元データソースの権限とは独立して、オブジェクトタイプに直接設定されたポリシーによって制御されます。
  • データソースポリシー: オブジェクトを閲覧できるかどうかは、元データソースの権限によって制御されます。オブジェクトを閲覧するには、元データソースに対する閲覧権限が必要です。

オブジェクトセキュリティの設定について詳しくは、オブジェクトセキュリティの管理に関するドキュメントを参照してください。オブジェクトタイプ(スキーマ)とオブジェクト(データ)の違いについて詳しくは、オブジェクトの権限に関するドキュメントを参照してください。

プロジェクト内の、データソースを元にするオブジェクトタイプでは、オブジェクトをインデックス化するために元データソースをプロジェクトにインポートする必要があります。元データソースがまだプロジェクトに含まれていない場合、オブジェクトの作成時にインポートを求めるプロンプトが表示されます。

リンクとアクションの編集権限

編集するリソースに応じて、適切な編集権限が必要です。

  • リンクの場合: リンクタイプと、リンクされたオブジェクトタイプの両方に対する編集権限が必要です。
  • アクションの場合: アクションタイプと、そのアクションによって編集されるすべてのオントロジーリソースタイプに対する編集権限が必要です。

異なる権限モデルでパッケージ化してインストールする

Marketplace 製品は、パッケージ化されたときと同じ権限モデルを使用してインストールされます。オントロジー設定の新しいオントロジーリソースをプロジェクトに保存することを必須にするトグルは、新しいオントロジーリソースの作成にのみ影響します。ソース環境(製品がパッケージ化された環境)の権限モデルに基づいて Marketplace が対象環境(製品がインストールされる環境)に製品をインストールする方法は変わりません。

  • オントロジーロールでパッケージ化済み: オントロジーロールを使用してインストールされます。
  • プロジェクトベースの権限管理でパッケージ化済み: プロジェクトベースの権限管理を使用してインストールされます。
  • 公開後にソースをプロジェクトベースの権限管理に移行: 次回のアップグレード時に、対象環境のオントロジーリソースがプロジェクトベースの権限管理に移行されます。

機密情報区分ベースのアクセス制御(CBAC)

オントロジーリソースが 機密情報区分ベースのアクセス制御(CBAC) で管理されるプロジェクトに保存されている場合、次のルールが適用されます。

  • リソースの作成時に、ファイルの機密情報区分を指定する必要があります。
  • ファイルの機密情報区分は、 プロジェクトの最大機密情報区分以下である必要があります。
  • 機密情報区分が指定されていない場合、オブジェクトタイプの実体化に失敗します。

Marketplace とファイルの機密情報区分

ファイルの機密情報区分は、オントロジー固有のものではなく、すべてのファイルに適用されます。以下のルールは、プロジェクトベースの権限管理と機密情報区分ベースのアクセス制御の連携に影響するため、ここで取り上げています。Marketplace は、製品自体にファイルの機密情報区分を含めません。

  • 公開時: Marketplace はファイルの機密情報区分を追跡しません。Marketplace ストアの機密情報区分が、除外される機密情報区分のいずれかより低い場合、ユーザーがそれらのマーキングを解除する権限を持っているかを確認します。
  • インストール時: インストールされた各ファイルには、対象プロジェクトの機密情報区分が適用されます。対象プロジェクトの機密情報区分が Marketplace ストアの機密情報区分より低い場合、インストールするユーザーは、それらのマーキングを解除する権限を持っている必要があります。
  • アップグレード時: ファイルの機密情報区分は変更されません。インストール時に設定された機密情報区分は手動で編集でき、その編集内容は以降のアップグレードでも保存されます。

ソースプロジェクトと対象プロジェクトに異なる機密情報区分のマーキングが付いている場合、Marketplace はマーキングを解除する権限を求めるプロンプトを表示します。

以前の権限モデル

以前は、オントロジーリソースの権限設定は、オントロジーの認可モデルによって異なっていました。以下のテーブルは、各モデルで現在リソースがどのように管理されているかをまとめたものです。これらのレガシー権限システムについて詳しくはこちらのドキュメントを参照してください。

レガシーのオントロジー権限モデル説明
オントロジーロール- オントロジーリソースの権限は、Ontology Manager でオントロジー固有のロール(オントロジー閲覧者、オントロジー編集者、オントロジー所有者)を使用して設定されます。これらはプロジェクトのリソースではありません。
データソース由来- オントロジーリソースの権限は、オブジェクトの元データソースから継承されます。たとえば、元データソースの編集者である場合に限り、オブジェクトタイプに対する編集者権限を持ちます。