注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
プロジェクトは、Foundry で作業を整理するための主要な手段であり、任意アクセス制御によるロール付与の主要な境界でもあります。パイプラインは、複数のプロジェクトで構成するとよいでしょう。他のユーザーと共同作業を行うには、各プロジェクトでさまざまなユーザーやグループにロールを付与します。Foundry 全体の任意アクセス制御は、プロジェクトとロールを組み合わせて管理します。強制アクセス制御(マーキング、機密情報区分ベースのアクセス制御、組織)は、プロジェクトをまたいでも、データの派生を通じても有効なままです。下流への派生を通じてデータの保護を維持することが目的の場合は、強制アクセス制御を使用してください。モデルの全体像については、アクセス制御の伝播を参照してください。
Foundry でのデータ基盤の保護について、詳しくはこちらをご覧ください。
プロジェクトは、Foundry で任意アクセス制御によるロール付与を行うための主要なコンテナであり、共有作業をまとめる単位と考えることができます。プロジェクトの境界は、内部のリソースを誰が読み取り、変更できるかを決定します。強制アクセス制御(マーキング、機密情報区分ベースのアクセス制御、組織)は、ロール付与に置き換わるものではなく、それと並行して適用されます。プロジェクトは、データを整理し、安全なスペース内で開かれた共同作業を実現するための重要な手段です。
各プロジェクトは、特定の目的に合わせてユーザー、ファイル、フォルダーを整理する共同作業用のスペースです。プロジェクトは、内部で共同作業を行うユーザーがコンテンツにほぼ一様にアクセスできる一方、そのコンテンツに対する権限は異なるように設計する必要があります。たとえば、プロジェクトの全ユーザーにデフォルトで閲覧者ロールを付与し、特定の 1 グループのみにすべてのプロジェクトリソースに対する編集者ロールを付与することができます。プロジェクトはセキュリティ境界を強制し、作業をスペース内に収められるようにします。作業(データの変換、分析など)はプロジェクト内で行い、その作業の出力はプロジェクト内のロジックと同じ場所に保存します。

作業とその出力は同じプロジェクト内に配置する必要があるため、他のプロジェクトの作業を再利用したり、それを基に作業を進めたりするには、参照を使用する必要があります。
権限管理を容易にするため、プロジェクトレベルでグループにロールを付与することをお勧めします。グループを使用してプロジェクトの権限を管理すると、同じ権限を持つユーザーをまとめて管理でき、個別のロール付与による煩雑さを軽減できます。プロジェクトの内容は、プロジェクトレベルで付与されたロールを継承するため、ユーザーはプロジェクト内のコンテンツに一様にアクセスできます。
スペース内にプロジェクトを作成するには、そのスペースに対する Editor または Owner 権限が必要です。
スペースの権限は、スペース設定ページから管理できます。
ユーザーは、アクセスする権限がないプロジェクトへのアクセス権をリクエストできます。アクセス権のリクエストには、必要なマーキングを含め、ユーザーがプロジェクトにアクセスできるようにするために必要なすべての変更が含まれます。
プロジェクトへのアクセス権のリクエストは、Foundry のファイルシステム表示にある複数の場所から送信できます。
上記のいずれかの場所から選択すると、アクセス権のリクエストポップアップが表示されます。ユーザーは、アクセスが必要な理由、アクセス権を付与するユーザーとグループ(他のユーザーに代わってリクエストする場合)、およびアクセス権の付与方法を指定する必要があります。
前述のとおり、プロジェクトの権限はグループを通じて管理することをお勧めします。アクセス権のリクエストポップアップでは、プロジェクトに対して適切なロールを持つグループへのアクセス権の取得を選択できます。Foundry 内部で管理されるグループの場合、ユーザーは参加するグループを選択できます。リクエストは、そのグループの管理者に承認のために送られます。グループのカスタムリクエストフローを設定することで、リクエストするユーザーが適切な参加先グループを選択できるように支援できます。カスタム承認のアクセス権リクエスト設定については、プラットフォームセキュリティ管理のドキュメントを参照してください。また、グループを非表示にして、ユーザーがそのグループへのアクセス権をリクエストできないようにすることもできます。方法については、グループ管理のドキュメントを参照してください。

Foundry 外部で管理されるグループの場合、Foundry プラットフォーム外で必要なグループへのアクセス権をリクエストするよう案内するメッセージと URL が表示されます。このメッセージと URL の設定方法については、外部グループのドキュメントを参照してください。
プロジェクトにグループが割り当てられていない場合、ユーザーは指定したロールでプロジェクトに直接追加されるようリクエストできます。これにより、プロジェクトへのアクセス権のリクエストタスクが作成され、プロジェクトに対して所有者ロールを持つユーザーによる承認が必要になります。
ユーザーがリクエストを作成すると、リクエストに成功したことを示すメッセージが表示されます。作成したリクエストを閲覧するには、メッセージの詳細を表示を選択するか、Foundry ワークスペースのサイドバーにある Approvals の受信トレイに移動して、左側のフィルターから自分のリクエストを選択します。
ユーザーがプロジェクト内のファイルまたはフォルダーでアクセス権をリクエストを選択すると、アクセス権のリクエストは特定のリソースではなく、プロジェクト自体に対して送信されます。リクエストを確認する際には、追加のコンテキストとして、リクエストの送信元となったファイルまたはフォルダーが表示されます。

プロジェクトをセキュリティ境界として徹底するため、個人フォルダから直接共有するのではなく、ユースケースに合わせて権限が設定されたプロジェクトにリソースを移動することをお勧めします。これにより、アクセス権が明確になり、誰が何にアクセスできるかを把握しやすくなります。プロジェクトへのアクセス権を持つユーザーとグループは、アクセスパネルをクリックして管理できます。

プロジェクトは Foundry の中心的なセキュリティ境界であり、Foundry のビルドシステムにも適用されます。ビルドは任意の数の入力データセットを受け取り、任意の数の出力データセットを生成します。これらの入力と出力は、必ず同じプロジェクト内に配置する必要があります。ただし、有用なパイプラインを構築するには、他のプロジェクトのデータセットを使用することが多いでしょう。他のプロジェクトのデータセットを使用する場合は、ファイル参照を適用することをお勧めします。

ファイル参照を追加すると、そのユースケースに必要なロールを持っている限り、プロジェクト内で上流データセットを使用できます。インポート後は、データセットに適用された組織とマーキングの要件を満たしていれば、共同作業者は上流プロジェクトへのアクセス権がなくても、プロジェクト内で派生したデータセットを閲覧できます。

上の画像では、Flight Control System [Datasource] プロジェクトの flights データセットを、Flight Delays [Transform] プロジェクトから参照しています。トランスフォーム用のプロジェクトにユーザーを追加すると、そのユーザーは delays データセットを閲覧し、それを基に追加のトランスフォームを作成できます。ただし、生の flights データセットを閲覧したり、それを基に追加のデータ変換を作成したりするには、引き続き上流プロジェクトに対する Viewer ロールが必要です。
プロジェクトと参照は、共同作業を整理するうえで役立ちます。プロジェクト所有者は、自分のプロジェクトにユーザーを容易に追加し、そのユーザーに適切な権限を付与できます。
プロジェクトにファイル参照を追加するには、通常、ソースプロジェクトに対する Viewer ロールと、保存先プロジェクトに対する Editor ロールが必要です。プロジェクトに参照を追加するために必要な権限については、プロジェクト参照と権限を参照してください。
参照は、Code Repositories、Code Workbook、Pipeline Builder、Fusion、Contourなど、Foundry のさまざまな場所から追加できます。
個人フォルダ内のファイルには、権限に関する問題が生じる可能性があるため、参照を追加できません。個人フォルダ内のファイルを参照するには、まずそのファイルをプロジェクトに移動し、共同作業者が閲覧できるようにしてください。
状況によっては、特定のカテゴリーのデータへのアクセスを、より一元的に制御したい場合があります。たとえば、あらゆる種類のフライトデータにアクセスするユーザーに、事前に必須のトレーニングを受けてもらう場合です。生の flights データセットにマーキングを適用すると、ユーザーは flights およびそこから派生したすべてのデータ(たとえば delays データセット)へのアクセス権を取得するために、中央の管理部門を通す必要があります。マーキングの使用については、マーキングを参照してください。
ロールは、リソースへのさまざまなレベルのアクセス権を付与する権限の集合です。ロールは任意に付与する権限であり、通常はプロジェクトレベルで付与して、プロジェクト内のすべてのリソースに対して一様な機能を提供します。ただし、強制アクセス制御(組織、マーキング、機密情報区分ベースのアクセス制御)は、ユーザーのロールに関係なく、要件を満たさないユーザーによるリソースへのアクセスを常に防ぎます。これらの制御はデータの派生を通じても伝播するため、下流リソースも同じ要件を継承します。一方、ロールが制御するのはリソース自体へのアクセスです。リソースから読み取られた後のデータには適用されません。
Foundry のデフォルトロールは、権限が強い順に、所有者、編集者、閲覧者、発見者です。各ロールは、他のユーザーに同じロールまたはそれより権限の弱いロールを割り当てることができます。たとえば、所有者は他のユーザーに所有者、編集者、閲覧者、発見者のいずれのロールも付与できますが、発見者は他のユーザーに発見者ロールのみを付与できます。これらのデフォルトは、まったく新しいロールを含めるようにカスタマイズできます。ロールは厳密な階層ではなく、それぞれが独立した操作権限の集合です。カスタマイズしたロールセットでは、権限の強いロールが、他のロールに付与されたすべての操作権限を含むとは限りません。
重要な点として、ロール付与は強制アクセス制御と同様に、子リソースに継承されます。たとえば、プロジェクトまたはフォルダーに対する閲覧者ロールをユーザーに付与すると、そのプロジェクトまたはフォルダー内のすべてのリソースに対する閲覧者ロールが付与されます。また、通常はユーザーのグループに対して、プロジェクト上のロールを付与します。

組織のロールの設定について、詳しくはこちらをご覧ください。
前述のとおり、プロジェクト内のすべてのリソースに対して一様な機能を提供するため、ロールはプロジェクトレベルでのみ付与することをお勧めします。この動作を徹底するには、プロジェクト表示の設定セクションにある切り替えを使用して、フォルダーとファイルへのロール付与を無効にできます。この設定を無効にすると、ロールはプロジェクトレベルでのみ付与でき、フォルダーやファイルのレベルでは付与できなくなります。この切り替えは、プロジェクトに対して Owner ロールを持つユーザーが設定できます。

すでにロールが付与されたリソースを含むプロジェクトでロール付与の設定を無効にすると、これらの個別リソースに対するロール付与は削除されます。既存のロール付与を削除すると、設定を再度有効にするまで再追加できません。同様に、ロールが付与されたリソースを、ロール付与の設定が無効なプロジェクトに移動すると、リソースレベルのロール付与は削除されます。ロール付与の設定を無効にする際、およびロール付与の設定が無効なプロジェクトにリソースを移動する際には、この動作についてユーザーに警告が表示されます。
また、リンク共有はリンクの受信者に個別のフォルダーまたはファイルに対するロールを直接付与するため、プロジェクトのリンク共有機能も無効になります。
フォルダーとファイルへのロール付与は、デフォルトで無効になっています。スペース管理者は、スペースレベルでデフォルトの動作を変更できます。フォルダーとファイルへのロール付与は、無効のままにすることをお勧めします。
