Foundry で B2B および B2C のコラボレーションを管理する：組織、スペース、セキュリティ

Foundry ユーザーとして、厳格なセキュリティ境界を維持しながら、ビジネスパートナー、ベンダー、顧客などのほかの組織とコラボレーションする必要がある場合があります。

多くの場合、次の2つの一般的なシナリオのいずれかに該当します。

• 企業間取引（B2B）： ほかの企業に製品やサービスを提供します。
• 企業対消費者取引（B2C）： 個人の顧客や小規模企業にサービスを提供します。

Foundry は、どちらの状況でも安全なコラボレーションを可能にし、強固なアクセス制御を適用しながら外部の主体を受け入れられます。このガイドでは、Foundry で組織、認証フロー、セキュリティ境界を設定するためのベストプラクティスの概要を説明します。

基本概念

後で説明するコラボレーションのアプローチを理解するために、次の概念を確認してください。各概念の詳細は、リンク先のドキュメントで確認できます。

組織

Foundry では、組織は中核となるセキュリティ概念であり、異なるユーザーグループやリソース群の間でアクセス制御とデータの分離を適用します。詳細は、組織のドキュメントを参照してください。

複数の組織を使用することは、安全なコラボレーションを可能にしながら、データのセキュリティと分離を徹底するうえで最適です。組織を使用すると、パートナー、ベンダー、企業のエコシステムを構築できます。

主な機能：

• ユーザーが所属できる組織は1つだけです。
• ユーザーは、ほかの組織にゲストとして参加できます。
• 組織はいつでも作成できます。
• 専用のスペースやオントロジーがなくても組織を作成できます。

組織を作成するときに、スペースやオントロジーを作成するオプションが表示されます。ただし、これらは別個の概念であり、組織の作成に必須ではありません。

スペース

以前は名前空間と呼ばれていたスペースは、プロジェクトの上位コンテナです。スペースは、共通の目的を中心としたユーザー間のコラボレーションを可能にし、複数の組織で共有できます。

スペースには、常に同じ名前のオントロジーが関連付けられています。たとえば、「Company A」というスペースには、同じく「Company A」という名前のオントロジーが関連付けられます。このオントロジーは、関連付けられたスペースに「含まれて」います。

1つまたは複数の組織が、1つまたは複数のスペースにアクセスできます。このガイドでは、1つの組織にアクセスが制限されたスペースを「プライベートスペース」、複数の組織がアクセスできるスペースを「共有スペース」と呼びます。各スペースを共有する組織の数を除き、これらに技術的な違いはありません。

スペースにアクセスできる組織があると、プロジェクトの所有者は、その組織のメンバーとプロジェクトを共有できます。組織がスペースにアクセスできるからといって、すべてのメンバーがデフォルトですべてのプロジェクトにアクセスできるわけではありません。詳細は、スペースのドキュメントを参照してください。

ユーザーが移動元と移動先のスペースに対する十分な権限を持ち、移動元と移動先のプロジェクトにタグ付けされた組織に対する十分な権限も持つ場合、リソースを別のスペースに移動できます。実質的には、作成されたリソースへのアクセスがほかの組織へと_拡張_されます。これには、移動元の組織に対する高度な権限が必要です。

一部のレガシー Foundry 環境では、スペースごとに異なるファイルシステムを使用しているため、リソースを移動できない場合がありますが、通常はそうではありません。

主な機能：

• スペースはいつでも作成できます。
• スペースには常に独自のオントロジーがあります。
• どの時点でも、スペースには1つ以上の組織がアクセスできる必要があります。
• 組織はいつでもスペースに追加できます。
• プロジェクトにアクセスできる組織は、常にそのプロジェクトのスペースにアクセスできる組織の部分集合でなければなりません。組織がスペース内のどのプロジェクトにもアクセスできない場合、その組織はいつでもスペースから外すことができます。

以下は、プロジェクトとリソースを含むスペースにアクセスできる組織のサンプルです。

複数の組織で共有されるスペースには、そのうち一部の組織だけが利用可能なプロジェクトを含めることができます。詳細は、複数組織のスペースのドキュメントを参照してください。

以下は、スペースにアクセスできる組織とアクセスできない組織の例です。このスペース内では、それらの組織の一部が特定のプロジェクトにアクセスできます。

• 組織 A、B、C はスペース A にアクセスできますが、組織 D はアクセスできません。スペース A に含まれるどのプロジェクトにも、組織 D はアクセスできません。
• 組織 B と C はスペース A の「Project 2」にアクセスできますが、「Project 3」にアクセスできるのは組織 C だけです。

オントロジー

オントロジーは、オブジェクトタイプ、アクション、リンク、グループ、インターフェースなどのリソースをまとめます。これらは、組織全体のすべてのユーザーが意思決定を行い、その意思決定を記録するための、共有された信頼できる情報源として機能します。詳細は、オントロジーのドキュメントを参照してください。

オントロジーは、スペースから独立して存在することはできません。スペースを作成すると、オントロジーも作成されます。スペースの権限と組織は、そのスペースのオントロジーに伝播されます。詳しくは、オントロジーとスペースのドキュメントを参照してください。

リソースは、あるオントロジーから別のオントロジーに移動できます。詳細は、オントロジー移行のドキュメントを参照してください。

重要なポイント：

• オブジェクトタイプ、アクション、リンク、グループ、およびその他のオントロジーリソースは、オントロジーの一部としてのみ存在できます。
• オントロジーを作成できるのは、スペースを作成するときだけです。
• オントロジーのスペースに追加された組織、またはスペースから外された組織は、オントロジーにも追加されるか、オントロジーから外されます。
• リソースはオントロジー間で移行できます。

関数はオントロジーリソースとはみなされません。

プロジェクト

プロジェクトは、標準のフォルダーよりも厳格なセキュリティ境界を適用し、特定の目的に関連するリソースを整理します。たとえば、すべてのデータ変換とその出力はプロジェクト内に含まれます。変換は別のプロジェクトに書き込めませんが、必要な権限があれば、プロジェクトは別のプロジェクトのリソースを利用できます。

ユーザーとグループのプロジェクトアクセスは、プロジェクトレベルで管理し、個別のロール割り当ての必要性を最小限に抑える必要があります。詳細は、プロジェクトとロールのドキュメントを参照してください。

重要なポイント：

• プロジェクトは、厳格なセキュリティ境界を提供しながら、リソースを整理するために使用します。
• プロジェクトは常にスペースに属します。
• 複数の組織がプロジェクトにアクセスできますが、それらの組織がそのプロジェクトの属するスペースにアクセスできる場合に限ります。

リソースのインポート：スペース、プロジェクト、オントロジー

あるプロジェクトのリソースを別のプロジェクトにインポートし、たとえばパイプラインや分析の入力として利用できます。リソースをインポートすると、閲覧者などの適切なロールを持つユーザーは誰でもそのリソースにアクセスできます。

ユーザーがインポートの実行に必要な権限を持っていれば、スペース間でリソースをインポートできます。たとえば、スペース A のデータセットをスペース B にインポートし、スペース B のオントロジーで元データソースとして使用できます。

ユースケース

組織の要件に応じて、組織、スペース、権限の構成を変える必要がある場合があります。

B2B または B2C のシナリオ向けに構築する際は、以下の質問を検討してください。

• 属性管理： ユーザーの属性は、1つ以上の IDプロバイダーを通じて外部で管理されますか、それとも Foundry によって内部で管理されますか？
• 顧客のオンボーディング： オンボーディングする顧客の数と、それぞれの顧客の規模はどの程度ですか？顧客は、1人のユーザー、数人のユーザー、あるいは数千人のユーザーで構成される場合があります。
• 共同作業： ユーザー同士で共同作業を行う必要がありますか？
• データ共有： 顧客間でデータを共有する必要がありますか？
• 使用量の分離： たとえば請求のために、顧客ごとの使用量を分離する必要がありますか？
• プラットフォームへのアクセス： ユーザーが、Workshop モジュールの作成など、Foundry プラットフォームの機能にアクセスできるようにする必要がありますか？
• カスタマイズ： アプリケーションを顧客ごとにカスタマイズしたり、調整したりする必要がありますか？
• アプリケーションのインタラクション： 顧客は主に Workshop アプリケーションなど、プラットフォーム内で構築されたアプリケーションを使用しますか、それともオントロジー SDK（オントロジー SDK）などのツールを使って外部のカスタムアプリケーションを構築しますか？

このガイドでは、顧客は個人、または企業、サプライヤー、購入者などの事業体を指します。

これらの質問への回答は、組織のニーズを把握し、ユースケースに最適な Foundry の設定を理解するうえで役立ちます。一般的なシナリオと、それぞれに応じたスペース、組織、権限の構成方法については、以下のセクションで詳しく説明します。追加情報が必要な場合や、組織固有のニーズがある場合は、Palantir の担当者にお問い合わせください。

単一の組織

最も単純で一般的な構成では、1つの組織と1つのスペースのみを使用します。すべてのプロジェクトは同じスペース内で作成、管理され、ユーザーまたはグループに割り当てられたマーキングとロールを使って、プロジェクトレベルの権限を細かく調整できます。

以下の例では、組織が、1つのオントロジーを含む単一のスペースにアクセスできます。

この構成はシンプルで維持しやすい一方、外部の事業体と安全に共同作業を行うには不十分な場合があります。その場合、厳格なセキュリティ境界を維持するために、複数のスペースと組織を使用する構成が必要です。

B2B：多数のユーザーを抱える多数の顧客をオンボーディングする

B2B 構成では、複数のスペースと組織を使用することで、組織のニーズを満たしながら厳格なセキュリティ境界を維持し、外部の事業体との安全な共同作業を実現します。この構成は、主要な内部組織と、顧客用に分離された追加の組織で構成されます。

B2B の組織には数百の顧客が存在し、各顧客に数百人、あるいは数千人のユーザーがいる場合があります。このようなシナリオでは、大規模な顧客のオンボーディングが可能です。数百の顧客がいる場合、Foundry インスタンスに数百の組織を設けることができます。顧客数とユーザー数には上限がありますが、通常、これらの上限内で、多数のユーザーを抱える大規模な顧客基盤のオンボーディングが可能です。

以下では、共有スペースとプライベートスペースを組み合わせて、顧客が自社やほかの顧客と共同作業を行うための選択肢を紹介します。

選択肢 A：プライベートスペース

共同作業が不要な場合、顧客ごとに独自の組織を設けることができます。各組織は独自のスペースとオントロジーを持ち、リソース共有や共同作業の設定は不要です。ある組織のユーザーをゲストとしてほかの組織に追加し、その組織のリソースで作業できるようにすることもできます。

ただし、ユーザーがゲストとして複数の組織に所属していても、組織間でリソースをインポートすることはできません。これは、リソースに適用された組織マーキングにより、共有されていないスペースへのインポートが禁止されるためです。

以下の例では、複数の組織がそれぞれ独自のスペースとオントロジーを持っています。

デフォルトでは、ある組織のユーザーはほかの組織の存在を確認できません。この動作は Control Panel で設定できます。詳細については、組織間のコラボレーションのドキュメントを参照してください。

以下は、Control Panel で設定できる、組織間での表示と共同作業に関するオプションです。

選択肢 B：共有スペース

共有スペースとそのオントロジーを作成して、組織間で共同作業を行えるようにすることができます。スペースに複数の組織がアクセスできるようにすると、組織同士で共同作業を行い、共有リソースにアクセスできます。

共有スペースへのアクセス権があっても、そのスペース内のすべてのプロジェクトへのアクセス権が自動的に付与されるわけではありません。各プロジェクトへのアクセスを特定の組織に制限できます。組織は、アクセス権を持つスペース内のプロジェクトにのみアクセスできます。たとえば、アプリケーションごとに1つのプロジェクトに保存し、許可された組織にのみアクセス権を付与できます。

以下は、複数の組織が共有スペースとオントロジーにアクセスできる例です。

制限付きビューとのインタラクション

共有スペースと制限付きビューを組み合わせると、行レベルのセキュリティを備えた複数組織向けのアプリケーションを実現でき、各組織が許可されたデータにのみアクセスするようにできます。

以下の例では、複数の組織が共有スペース内の共有プロジェクト（プロジェクト2）にアクセスできます。これらの組織は、制限付きビューのポリシーで定義された範囲のデータにのみアクセスできます。

選択肢 C：プライベートスペースと共有スペース

前述のように、組織間で共同作業を行うために、共有スペースとそのオントロジーを作成できます。ただし、各組織が独自のスペースとオントロジーを持つこともできます。

この方法は、共有リソースやアプリケーションをすべての組織からアクセスできるようにする必要があり、_かつ_組織固有のワークフローやカスタマイズが必要な場合に役立ちます。

以下は、プライベートスペースと共有スペースの利用が有効なシナリオの例です。

• 取り込み、コンピューティング、公開データセット（たとえば、気象データ）などのリソースを共有スペースに集約し、各組織が組織固有のカスタムアプリケーションでそれらを異なる方法で利用できるようにします。
• 共通のアプリケーションを共同作業用の共有名前空間でホストし、カスタムアプリケーションを各組織のプライベート名前空間でホストします。

以下の例では、組織は独自のスペースとオントロジーを持ち、共有スペースとオントロジーにもアクセスできます。

複数の組織のデータを組み合わせる

複数の組織のリソースを共有スペースに取り込むことで、組織間の参照や、異なるソースのデータを使った共同作業が可能になります。ただし、権限を管理する際には、リソースのマーキングについて考慮することが重要です。マーキングは、標準のプロジェクトアクセス層に加えて、リソースやそのコンテンツにアクセスできるユーザーを制御します。

マーキングには以下の種類があります。

• 組織のマーキング： プロジェクトに組織が割り当てられている場合、そのプロジェクトには、その組織のマーキングがつけられます。
• 組織以外のマーキング： 組織以外のマーキングの例として、個人を特定できる情報 (PII) や内部マーキングがあります。

これら2種類のマーキングは、いずれも AND と OR を組み合わせてアクセスを定義するなど、さまざまな方法で適用できますが、デフォルトの動作は異なります。ただし、マーキングの種類とプラットフォーム内の適用場所によって、適用方法が異なります。組織のマーキングと組織以外のマーキングは、適用場所と適用方法に応じて、OR 条件、AND 条件、またはより複雑な組み合わせで適用される場合があります。

マーキングは、リソースやそのコンテンツにアクセスできるユーザーを制御します。選言的マーキングと連言的マーキングの動作については、以下のガイドラインを参照してください。

• 選言的マーキング (OR)：必須のマーキングのいずれかを満たすユーザーがアクセスできます。
  • リソースには、保存先の場所の組織のマーキングが自動的につけられます。組織のマーキングは選言的であり、選言的マーキングとしてのみ適用できます。たとえば、組織 A _または_組織 B のメンバーであるユーザーは、組織 A _および_組織 B がアクセスできるスペース内のリソースにアクセスできます。
• **連言的マーキング (AND)：**必須のマーキングを_すべて_満たすユーザーのみがアクセスできます。
  • リソースにマーキングをつけると、マーキングは連言的に適用されます。プラットフォームの UI から組織以外のマーキングを適用する場合、この方法でのみ適用できます。たとえば、組織以外のマーキングである PII がリソースに適用されている場合、PII マーキングへのアクセス権を持つユーザーのみがそのリソースにアクセスできます。
  • 複数の上流リソースからデータを組み合わせる場合、組織のマーキングを含むそれらのマーキングは連言的に適用されます。たとえば、データセット1に [組織 A OR 組織 B] のマーキングがつけられ、データセット2に [組織 A OR 組織 C] のマーキングがつけられている場合、下流のデータセットにアクセスするには、ユーザーが [組織 A OR 組織 B] AND [組織 A OR 組織 C] に所属している必要があります。
• リソースのマーキングを外す： リソースやそのコンテンツからマーキングを外すことができます。マーキングがついたデータへのアクセスを拡大するには、リソースのマーキングを明示的に外す必要があります。これは、トランスフォームや制限付きビューで行えます。たとえば、コードリポジトリでは、stop_propagating または stop_requiring メソッドを使用して、トランスフォーム内でリソースのマーキングを明示的に外すことができます。

詳細については、継承された組織を外すドキュメントを参照してください。

以下は、実際の動作における影響の例です。

• デフォルトの動作： 共有プロジェクトで作成された、上流の依存関係がないリソースには、選言的な組織のマーキングがつけられます。このプロジェクトに割り当てられているいずれかの組織のユーザーが、そのリソースにアクセスできます。たとえば、組織 A と B がプロジェクトにアクセスできる場合、組織 A または B のどのユーザーも、そのプロジェクトのコンテンツにアクセスできることを意味します。「共通アプリケーション」には、組織 A OR B の選言的マーキングがつけられるため、組織 A または B のどのユーザーもアクセスできます。

• 組織 A と組織 B のデータから派生したデータセットでは、データの来歴により、組織 A AND 組織 B が必要になります。このデータセットのマーキングを外すと、その場所により、組織 A OR 組織 B が必要になります。
• 共有プロジェクトで作成された、上流の依存関係がないリソースには、選言的マーキングがつけられるため、組織 A または B のユーザーがアクセスできます。

詳細については、共有スペースとオントロジーのドキュメントを参照してください。

• 制限付きビューを使用して、特定のマーキングを外し、制限付きビューのデータと定義されたポリシーに応じて、行レベルのアクセスにより細かいルールを適用することもできます。たとえば、if user_rid === content of this column, allow access to this row です。

行レベルのアクセスポリシーを適用する前に、制限付きビューのすべてのコンテンツからマーキングを外すことができます。

B2C：すべての顧客に1つの組織

組織数が数千など、非常に多い B2C シナリオでは、別のアプローチが必要になる場合があります。 このガイドでは、次の設定を使用します。

• 単一の組織： すべての外部ユーザーを単一の組織のメンバーとしてオンボーディングします。
• ユーザーの分離： ユーザーの発見可能性を無効にするように組織を設定し、ユーザーが互いを閲覧したり見つけたりできないようにします。同じ設定をグループにも適用する必要があります。ユーザーとグループの表示設定を構成する方法を確認してください。

以下は、メインの内部組織と、すべてのユーザー向けの別の組織を設け、ユーザーの発見可能性を無効にした例です。両方の組織が、共有の顧客スペースとオントロジーにアクセスできます。

Control Panel で、組織内のユーザーとグループが互いを閲覧することを許可または禁止できます。

行レベルの権限を設定する制限付きビュー

B2C シナリオでは、顧客が自分のデータまたは特定のデータのサブセットのみを閲覧できるように、データアクセスを制限することが一般的な要件です。これは制限付きビューを使用して実装できます。

B2C ユースケースの制限付きビューの設定は、B2B ユースケースのプロセスとほぼ同じですが、ビジネスデータを分離するのではなく、顧客が互いのデータにアクセスできないようにします。

以下の例は、複数の顧客が同じアプリケーションを使用し、各顧客が自分のオブジェクトのインスタンスのみを閲覧できることを示しています。制限付きビューのポリシーは、ユーザーがアクセスできる行を定義し、それによって閲覧できるオブジェクトも決まります。

制限付きビューのポリシーは、さまざまな方法で実装できます。よくある要件は、ユーザーが自分で作成したオブジェクトのみを閲覧できるようにすることです。これは、制限付きビューに基づくオブジェクトタイプに新しいオブジェクトを作成するアクションを設定することで実装します。ポリシーは、ユーザーの ID がオブジェクトのプロパティにあるユーザーID列と一致する場合にのみ、オブジェクトのインスタンスへのアクセスを許可します。新しいオブジェクトが作成されると、ユーザーID列には現在のユーザーの ID が自動的に入力され、ユーザーが自分のオブジェクトのみにアクセスできるようになります。

認証

組織とスペースの作成に加えて、ユーザーが自分のアカウントにアクセスするには、IDプロバイダーで認証する方法が必要です。このガイドでは、「事業体」、「顧客」、「サードパーティー」といった用語はすべて、オンボーディング対象の外部組織という同じ概念を指します。

戦略1：各組織が独自の IDプロバイダーを持ち込む

各顧客を個別の組織としてオンボーディングし、各顧客の IDプロバイダーを Foundry と統合します。この方法は、顧客数が少ないシナリオや、各顧客のユーザーベースが大きく、独自にグループとアクセス制御を管理したい場合に最適です。詳細については、グループの外部レルムのドキュメントを参照してください。

このアプローチでは、手動での作業が複数回必要です。顧客の IDプロバイダーの情報を収集して設定する自動化プロセスはありません。各顧客の IDプロバイダーの詳細を取得し、SAML のはじめにおよび IDプロバイダーの設定のドキュメントに記載されているセットアップに沿って進める必要があります。

戦略2：パススルーとして IDプロバイダーを提供する

オンボーディングする各顧客について、属性または SSO フェデレーションを通じて IDプロバイダーを同期することを目指します。これは SaaS B2B のセットアップで一般的なアプローチであり、IDプロバイダーが互いを信頼することでシームレスな認証を可能にします。この方法は、多数の顧客組織をオンボーディングする場合に特に有用です。この場合、IDプロバイダーのインフラストラクチャを自分で管理するため、オンボーディングがより円滑になります。プロセスの大部分は、Okta や Auth0 などのツールを使用してスクリプト化または完全に自動化できます。

各ユーザーには、所属組織を示す属性が必要です。この属性は IDプロバイダーから Foundry に渡され、ログイン時にユーザーを正しい組織に振り分けます。これにより、制限付きビューのワークフローをサポートでき、ユーザー属性に基づくポリシーによって、ユーザーが許可されたデータのみを閲覧できるようになります。

Control Panel で、ユーザー属性に応じてユーザーを組織に割り当てることができます。詳細については、ユーザールールを参照してください。

戦略3：内部で IDプロバイダーを提供する

このアプローチでは、IDプロバイダーを提供して管理し、その IDプロバイダー内でユーザーアカウントを直接作成します。この戦略は、特に B2C シナリオに適しています。

主な利点：

• 認証フロー全体を管理できます。
• Foundry と IDプロバイダーの統合は、1回だけセットアップすれば済みます。
• ユーザーアカウントの作成と認証方法を一元管理できます。

戦略4：異なるアプローチを組み合わせる

顧客のさまざまなニーズに合わせて、複数の戦略を組み合わせることができます。

• 大規模な顧客については、その顧客独自の IDプロバイダーと統合します。
• 小規模な顧客については、メインの IDプロバイダーでユーザーを作成するか、属性のフェデレーションを使用します。

この柔軟なアプローチにより、各顧客の規模と要件に基づいて、オンボーディングと認証のワークフローを調整できます。

製品の配布

Foundry のビルダーは、データセット、パイプライン、オブジェクト、アプリケーションなどのリソースを作成できます。これらのリソースは、パッケージ化してほかのユーザーにデプロイできます。たとえば、ほかのプロジェクトやスペース、同じ組織や異なる組織にリソースをデプロイできます。これにより、アプリケーションとワークフローを一元的に開発し、ほかの事業や組織に配布できます。また、1つの開発環境から、組織間で共有される環境へのリリースを管理できます。

詳細については、次のリソースを参照してください。

• デプロイについては、Marketplace の概要
• パッケージ化については、Foundry DevOps の概要
• リリース管理については、DevOps リリース管理の概要

Marketplace 製品としてパッケージ化済みのリソースは、新しいプロジェクトとスペースにインストールできます。リソースは複数回インストールでき、異なるプロジェクトや組織にインストールすることで、組織がそれぞれのパッケージのインストールにアクセスできるようにすることもできます。これは「一元的に構築し、多くの場所にデプロイする」シナリオに最適で、インストール後に必要に応じてワークフローを調整できる柔軟性も備えています。

開発環境に関する考慮事項：

• パッケージ化するリソースと開発環境は、単一の専用開発組織に属するプロジェクト内に配置する必要があります。
• リソースをパッケージ化する開発者は、リソースへのアクセスをほかの組織に拡張するため、この組織に対する拡張権限を持つ必要があります。

Marketplace ストアの配置に関する考慮事項：

• すべての対象組織がアクセスできるスペース内のプロジェクトに Marketplace ストアを配置します。そのようなスペースがまだない場合は、ストア専用のスペースを作成し、関連するすべての組織を含めることを検討してください。
• 組織のユーザーが誰もストアのプロジェクトにアクセスできない場合でも、すべての組織がそのプロジェクトにアクセスできるようにしてください。

この製品配布のセットアップでは、次の考慮事項に留意してください。

• Marketplace 製品をインストールするユーザーに、組織マーキングに対する追加の権限は必要ありません。
• 権限の問題が発生する場合、インストール時ではなく、パッケージ化時に発生します。これにより、プロセスの早い段階で問題を解決できます。

次のように組織が構成されている下図を例に考えます。

• ユーザーが所属する主要な内部組織には、独自のプライベートスペースとオントロジーがあります。
• 開発組織には独自のスペースとオントロジーがあり、内部組織のユーザーがゲストとして参加します。
• 共有スペースと共有オントロジーがあり、Marketplace ストアはそこに配置されています。
• 独自のスペースとオントロジーを持つ組織が N 個あります。これらの組織には、Marketplace ストアを含むプロジェクトへのアクセス権を持つユーザーが製品をインストールします。このプロジェクトは共有スペース内にあります。

詳細については、ストアの権限のガイダンスを参照してください。

製品配布のアクセス戦略については、次のセクションを参照してください。

戦略1：エンドユーザー向けセルフサービスストア

ユーザーが自分で Marketplace 製品をインストールできるようにする場合は、ストアから特定の場所にインストールするために必要な権限を付与する必要があります。

• 特定のストアから特定の製品をセルフサービスでインストールする必要があるユーザーは、ストアを含むプロジェクトに対する marketplace:install-from-local-marketplace 権限を持つ必要があります。この権限は、顧客がロールを手動で変更していない限り、通常は閲覧者ロールに付与されています。
• 特定のストアから特定の製品をセルフサービスでインストールする必要があるユーザーは、Marketplace 製品を特定の場所にインストールするために、対象のスペースとオントロジーに対する marketplace:install-in 権限を持つ必要があります。この権限は、顧客がロールを手動で変更していない限り、通常は編集者または所有者ロールに付与されています。
• 製品またはインストールで必要な場合は、追加の権限を付与します。たとえば、入力やリンクされた製品に対する閲覧者権限などです。

詳細については、ストアの権限を参照してください。

これにより、前述のセットアップに従ったセルフサービスのインストールが可能になります。

戦略2：主要な主体によるインストールの管理

収益化などの目的でインストールプロセスを管理したい場合は、プラットフォーム管理者または指定された内部開発者にのみ、Marketplace ストアのプロジェクトへのアクセス権を付与する必要があります。これにより、エンドユーザーのために製品のインストールを行い、プロセスを引き続き管理できます。

開発者が顧客に代わってインストールを管理するには、通常、次の2つのアプローチのいずれかが必要です。

• 開発組織と顧客組織の両方がアクセスできる共有スペースをセットアップし、必要なすべての入力データをその共有スペースで利用可能にします。
• 開発者に顧客組織へのゲストアクセス権を付与します。これには、必要な入力データへのアクセスと、顧客のプライベートスペース内への製品のインストールに十分な権限を含めます。