プロジェクトとロール

プロジェクトは、Foundryで作業を組織化する主要な方法であり、主要なセキュリティ境界でもあります。おそらく、パイプラインを一連のプロジェクトとして設定したいでしょう。他の人と協力して作業を進めるために、各プロジェクトで様々なユーザーやグループにロールを付与します。プロジェクトとロールを組み合わせることで、Foundry全体での任意アクセス制御が管理されます。

Foundryでデータ基盤をセキュアにする方法について詳しく学ぶ。

プロジェクトとリソース

プロジェクトは、Foundryでの主要なセキュリティ境界であり、共有作業のバケットと考えることができます。プロジェクトの境界がセキュリティを強制するため、プロジェクトはデータの整理とセキュアなスペースでのオープンなコラボレーションを可能にする主要な手段です。

各プロジェクトは、特定の目的のためにユーザー、ファイル、フォルダーを整理する共同作業スペースです。プロジェクトは、各プロジェクト内で協力するユーザーがおおよそ一様なアクセス権を持つように設計されるべきですが、そのコンテンツに対する権限は異なります。例えば、プロジェクト内の全員がデフォルトでビューワーロールを持ち、特定のグループだけがすべてのプロジェクトリソースに対してエディターロールを持つことができます。プロジェクトはセキュリティ境界を強制し、作業をスペースに収容することができます。作業（変換、分析など）はプロジェクトで行われ、その作業の出力はプロジェクト内のロジックと共に配置されます。

作業とその出力は同じプロジェクト内に存在しなければならないため、他のプロジェクトの作業を再利用したり、それをベースに構築したりする場合は、リファレンスを使用する必要があります。

許可管理を簡単にするために、プロジェクトレベルでグループにロールを付与することをお勧めします。プロジェクトのアクセス許可をグループで管理することで、同じ許可を持つユーザーのセットを一緒に管理できるため、個々のロール付与の clutter を減らすことができます。プロジェクトの内容は、プロジェクトレベルで付与されたロールを継承し、ユーザーにプロジェクト内のコンテンツへの一様なアクセスを提供します。

プロジェクトの作成

ユーザーは、名前空間の所有者またはエディターである必要があります。そうでなければ、そのユーザーには新しいプロジェクトボタンが表示されません。

名前空間の権限は、名前空間の設定ページから管理できます。

プロジェクトへのアクセスをリクエストする

ユーザーは、アクセスが許可されていないプロジェクトに対してアクセスリクエストを提出できます。アクセスリクエストには、ユーザーがプロジェクトにアクセスするために必要なすべての変更が含まれます。これには、必要なマーキングも含まれます。

プロジェクトへのアクセスリクエストは、Foundryのファイルシステムビューで複数のアクセスポイントから提出できます。

• アクセスをリクエストする
  • プロジェクトとファイルビューのプロジェクト名の隣にあります。
  • ユーザーが閲覧許可がないリソースを開くときに表示されます（例：直接リンク）。
• プロジェクトへのアクセスをリクエストする
  • ユーザーがプロジェクトに対してディスカバラーロールしか持っていない場合、プロジェクトビューにあります。
• 追加のアクセスをリクエストする
  • ユーザーがプロジェクトにアクセスできる場合、プロジェクトビューのアクションドロップダウンにあります。

上記のいずれかのエントリーポイントを選択すると、ユーザーにはアクセスをリクエストするポップアップが表示されます。アクセスの理由、アクセスを許可すべきユーザーやグループ（他者の代わりにリクエストする場合）、どのようにアクセスを許可するかを提供する必要があります。

上記で説明したように、プロジェクトのアクセス許可はグループを通じて管理することをお勧めします。アクセスをリクエストするポップアップでは、ユーザーは、プロジェクトに適切なロールを持つグループにアクセスすることができます。Foundry内部で管理されているグループの場合、ユーザーは参加するグループを選ぶことができ、リクエストがグループ管理者に承認されるようにルーティングされます。

Foundryの外部で管理されているグループの場合、ユーザーはメッセージとURLが表示され、Foundryプラットフォームの外部で必要なグループへのアクセスをリクエストするように誘導されます。このメッセージとURLの設定方法については、外部グループのドキュメントを参照してください。

プロジェクトに割り当てられたグループがない場合、ユーザーは直接プロジェクトに追加して特定のロールを持つようにリクエストできます。これにより、プロジェクトアクセスリクエストタスクが作成され、プロジェクトのオーナーロールを持つユーザーからの承認が必要となります。

リクエストを作成すると、リクエストが成功したことを示すメッセージが表示されます。メッセージの詳細を表示を選択するか、Foundryワークスペースのサイドバーにある承認の受信トレイに移動し、左側のフィルターから自分のリクエストを選択して、作成されたリクエストを表示します。

ファイルとフォルダーへのアクセスリクエスト

ユーザーがプロジェクト内のファイルやフォルダーにアクセスをリクエストするを選択した場合、アクセスリクエストはプロジェクト自体に提出されます（特定のリソースではありません）。リクエストを確認する際に、リクエストが提出されたファイルやフォルダーが表示され、追加のコンテキストが提供されます。

リソースの共有と移動

プロジェクトをセキュリティ境界として強制するために、自分のファイルから直接共有するのではなく、ユースケースに対して許可されたプロジェクトにリソースを移動することをお勧めします。これにより、アクセスの明確さと、誰が何にアクセスできるかの可読性が向上します。プロジェクトへのアクセスを持つユーザーやグループは、アクセスパネルをクリックして管理できます。

リファレンス

プロジェクトは、Foundryの中心的なセキュリティ境界であり、Foundryのビルドシステムにも及びます。ビルドでは、任意の数の入力データセットを取り込み、任意の数の出力データセットを生成します。これらの入力と出力は、同じプロジェクトに存在しなければなりません。ただし、有用なパイプラインを作成するために、他のプロジェクトからのデータセットを使用したい場合があります。他のプロジェクトからのデータセットを使用する場合は、ファイルリファレンスを適用することをお勧めします。

ファイルリファレンスを追加すると、プロジェクトで上流のデータセットを使用できるようになります。インポートすると、同僚はその上流プロジェクトにアクセスすることなく、あなたとの変換や、プロジェクト内で派生したデータセットを閲覧したり協力したりすることができます（ただし、組織とマーキングを満たしている場合のみです）。

上記の画像では、Flight Control System [Datasource]プロジェクトからのフライトデータセットを参照し、Flight Delays [Transform]プロジェクトにインポートしました。変換プロジェクトにユーザーを追加すると、delaysデータセットを表示できるだけでなく、上流のデータソースプロジェクトにアクセスせずに新しい変換で生のflightsデータセットを使用することができます。

プロジェクトとリファレンスは、プロジェクトオーナーが自分のプロジェクトにユーザーを簡単に追加し、適切なアクセス権を確保できるように、協力を組織化するのに役立ちます。

リファレンスは、Foundryのさまざまな場所で追加できます。たとえば、Code Repositories、Code Workbook、Pipeline Builder、Fusion、Contourなどです。Editorロールを持つユーザーは、プロジェクトにファイルリファレンスを追加できます。

自分のファイルにあるファイルにリファレンスを追加することはできません。これは、アクセス許可の問題が発生する可能性があるためです。自分のファイルにあるファイルを参照したい場合は、まずファイルを移動してプロジェクトに配置し、同僚が見ることができるようにしてください。

マーキングを使った集中的なデータ管理

場合によっては、データのカテゴリに対してアクセスをより集中的に制御したいことがあります。例えば、あらゆる種類のフライトデータにアクセスできる人は、まず必須のトレーニングを受けるべきかもしれません。生のflightsデータセットにマーキングを適用すると、ユーザーはflightsやそれから派生したもの（例：delaysデータセット）にアクセスするために、まず集中的な管理体制を通じてアクセスを許可しなければなりません。マーキングの使用に関する詳細は、マーキング)を参照してください。

ロール

ロールとは、リソースへのアクセスレベルを異なるレベルで付与する権限のセットです。ロールは裁量権限であり、一般的にプロジェクトレベルで付与され、プロジェクトの範囲内のすべてのリソースに対して一様な機能を提供します。ただし、強制的な制御である組織とマーキングは、常に対象となるユーザーがリソースにアクセスできないようにします。これは、ユーザーのロールに関係なく適用されます。

最も強力なものから最も弱いものまで、Foundryのデフォルトのロールは、オーナー、エディター、ビューアー、ディスカバラーです。各ロールは、他のユーザーに同等または低いロールを割り当てることができます。例えば、オーナーは他のすべてのユーザーにオーナー、エディター、ビューアー、またはディスカバラーのロールを付与できますが、ディスカバラーは他のユーザーにディスカバラーのロールしか付与できません。これらのデフォルトは、完全に新しいロールを含めてカスタマイズできます。

重要なことに、強制制御と同様に、ロール付与は子リソースに継承されます。例えば、プロジェクトやフォルダーでユーザーにビューアーを付与すると、そのプロジェクトやフォルダーに含まれるすべてのリソースにビューアーが付与されます。通常、ユーザーグループはプロジェクトにロールが付与されます。

組織のロールの設定について詳しく学ぶ。

フォルダーとファイルへのロール付与

前述の通り、プロジェクトの範囲内のすべてのリソースに対して一様な機能を提供するために、ロールはプロジェクトレベルでのみ付与されることをお勧めします。この動作を強制するために、プロジェクトビューの詳細設定セクションに、フォルダーとファイルのロール付与を無効にするトグルがあります。この設定が無効になっている場合、ロール付与はプロジェクトレベルでのみ行われ、フォルダーやファイルレベルでは行われません。このトグルは、プロジェクトのオーナーロールを持つユーザーが設定できます。

既存のロール付与が無効になっているプロジェクトで、ロール付与があるリソースが既に含まれている場合、これら個別のリソースに対するロール付与は削除されます。既存のロール付与が削除されると、設定が再有効化されるまで、再度追加することはできません。同様に、ロール付与が無効になっているプロジェクトにロール付与があるリソースを移動すると、リソースレベルのロール付与が削除されます。ロール付与設定の無効化や、ロール付与設定が無効なプロジェクトへのリソースの移動時に、この動作についてユーザーに警告されます。

さらに、プロジェクトのリンク共有機能も削除されます。リンク共有は、受信者に個別のフォルダーやファイルに直接ロールを付与するためです。

フォルダーとファイルへのロール付与はデフォルトで無効になっています。名前空間の管理者は、名前空間レベルでデフォルトの動作を変更できます。フォルダーやファイルへのロール付与は無効にしておくことをお勧めします。