プロジェクトとロール

プロジェクトはFoundryで作業を整理する主要な方法であり、主要なセキュリティの境界です。パイプラインを一連のプロジェクトとして設定することをお勧めします。他のユーザーと共同作業するために、各プロジェクトに対してさまざまなユーザーやグループにロールを付与します。プロジェクトとロールは、Foundry全体で任意アクセス制御を管理する方法です。

Foundryにおけるデータ基盤のセキュリティ確保について詳しく学びましょう。

プロジェクトとリソース

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

各プロジェクトは特定の目的のためにユーザー、ファイル、フォルダーを整理する共同作業スペースです。各プロジェクト内で共同作業するユーザーがコンテンツに対してほぼ均一なアクセスを持ち、コンテンツに対してさまざまな権限を持つようにプロジェクトを設計すべきです。たとえば、プロジェクト内のすべてのユーザーがデフォルトのViewerロールを持ち、特定のグループのみがすべてのプロジェクトリソースに対してEditorロールを持つ場合などです。プロジェクトはセキュリティの境界を強制し、作業をスペース内に閉じ込めることができます。作業（変換、分析など）はプロジェクト内で行われ、その作業の出力はロジックと共にプロジェクト内に存在します。

作業とその出力は同じプロジェクト内に存在する必要があるため、他のプロジェクトでの作業を再利用または構築するにはリファレンスを使用する必要があります。

権限管理を容易にするために、プロジェクトレベルでグループロールを付与することをお勧めします。グループを使用してプロジェクト権限を管理することで、同じ権限を持つユーザーセットを一緒に管理でき、個別のロール付与の煩雑さを減らすことができます。プロジェクトのコンテンツは、プロジェクトレベルで付与されたロールを継承し、ユーザーにプロジェクト内のコンテンツへの均一なアクセスを提供します。

プロジェクトの作成

ユーザーは、そのスペースでプロジェクトを作成するためにEditorまたはOwnerの権限が必要です。

スペースの権限はスペース設定ページから管理できます。

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

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

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

• アクセスリクエスト
  • プロジェクトとファイルビューのプロジェクト名の横にあります。
  • ユーザーが閲覧権限を持たないリソース（たとえば、直接リンク）を開くと表示されます。
• プロジェクトアクセスのリクエスト
  • ユーザーがプロジェクトでDiscovererロールのみを持っている場合、プロジェクトビューに表示されます。
• 追加アクセスのリクエスト
  • ユーザーがプロジェクトにアクセス権を持っている場合、プロジェクトビューのアクションドロップダウンに表示されます。

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

上記で述べたように、プロジェクトの権限をグループを通じて管理することをお勧めします。アクセスリクエストポップアップでは、プロジェクトに適切なロールを持つグループにアクセスするように選択できます。Foundry内で管理されているグループの場合、ユーザーは参加するグループを選択でき、リクエストはグループの管理者に承認を求めるためにルートされます。カスタムリクエストフローを設定して、リクエストするユーザーが適切なグループを選択するのを支援できます。カスタム承認アクセスリクエストの設定に関する詳細は、プラットフォームセキュリティ管理ドキュメントで確認できます。

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

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

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

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

ユーザーがプロジェクト内のファイルやフォルダーでアクセスリクエストを選択すると、アクセスリクエストは特定のリソースではなくプロジェクト自体に対して提出されます。リクエストをレビューするとき、リクエストが提出されたファイルやフォルダーが表示され、追加のコンテキストが提供されます。

リソースの共有と移動

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

リファレンス

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

ファイルリファレンスを追加すると、上流のデータセットをプロジェクト内で使用できるようになります。インポートされると、同僚は上流プロジェクトへのアクセスなしにユーザーと共同作業を行い、ユーザープロジェクト内で生成されたすべてのデータセットを確認できます（組織やマーキングの要件を満たす限り）。

上の画像では、Flight Control System [Datasource]プロジェクトからFlight Delays [Transform]プロジェクトにフライトデータセットをリファレンスしました。ユーザーをトランスフォームプロジェクトに追加すると、そのユーザーはdelaysデータセットを表示し、新しいトランスフォームで生のflightsデータセットを使用することができます。

プロジェクトとリファレンスは共同作業を整理するのに役立ちます。プロジェクトの所有者は簡単にユーザーをプロジェクトに追加し、適切な権限を持っていることを確認できます。

リファレンスは、Code Repositories、Code Workbook、Pipeline Builder、Fusion、およびContourなど、Foundryの多くの場所から追加できます。Editorロールを持つユーザーは、プロジェクトにファイルリファレンスを追加できます。

ユーザーのファイルにあるファイルにリファレンスを追加することはできません。これは権限の問題を引き起こす可能性があるためです。ユーザーのファイルにあるファイルをリファレンスする場合は、最初にファイルをプロジェクトに移動して、同僚がアクセスできるようにします。

マーキングによる中央データガバナンス

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

ロール

ロールはリソースへのアクセスレベルを付与する権限のセットです。ロールは任意の権限であり、一般的にプロジェクトレベルで付与され、プロジェクトの範囲内のすべてのリソースに対して均一な機能を提供します。ただし、必須の制御である組織とマーキングは、ユーザーのロールに関係なく、資格のないユーザーがリソースにアクセスするのを常に防ぎます。

Foundryのデフォルトロールは、最も強力なものから最も弱いものまで次の通りです：Owner、Editor、Viewer、およびDiscoverer。各ロールは他のユーザーに同じまたはそれ以下のロールを付与できます。たとえば、Ownerは他のユーザーにOwner、Editor、Viewer、またはDiscovererロールを付与できますが、Discovererは他のユーザーにDiscovererロールのみを付与できます。これらのデフォルトは完全に新しいロールを含むようにカスタマイズできます。

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

組織のロールの設定について詳しく学びましょう。

フォルダーおよびファイルに対するロール付与

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

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

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

フォルダーおよびファイルに対するロール付与はデフォルトで無効になっています。スペース管理者はスペースレベルでデフォルトの動作を変更できます。フォルダーおよびファイルに対するロール付与は無効にしておくことをお勧めします。