注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Data Connection の主要な概念であるエージェント、ソース、および Sync は、Foundry でリソースとして管理されています。これにより、プロジェクトとフォルダー間でリソースを柔軟に整理でき、マーキングなどのセキュリティプリミティブを Data Connection リソースに適用できます。
プラットフォームのオーナーは、Data Connection リソースを過剰に共有しないように注意する必要があります。ソースとエージェントの表示および編集権限を持つユーザーは、信頼できるパイプライン開発者である必要があります。Sync によって生成されたデータセットは、必要に応じて下流の Transform プロジェクトにインポートできるため、エージェントやソースへのアクセスを共有せずにデータへのアクセスを許可できます。
このページでは、すべての Data Connection リソースの権限がどのように機能するかを説明しています。これには以下が含まれます。
以下に示す権限はデフォルトです。一部の環境では、カスタムロールを使用してデフォルトの権限動作が変更されている場合があります。
オーナー
エージェントのオーナーは通常、そのエージェントの作成者であり、以下の権限が与えられます。
エディター
エージェントのエディターは以下を行うことができます。
ユーザーがそのプロジェクトのエージェントを作成するには、プロジェクトのエディターである必要がありますが、そのプロジェクトのオーナーである必要があります。つまり、ユーザーがエージェントを作成してから、エージェントに対してダウンロードリンクを生成したり、他の管理タスクを実行したりすることができない場合があります。
ビューアー
エージェントのビューアーは以下ができます。
オーナー
エディター
ソースのエディターは以下ができます。
Sync は、ソースの資格情報がそれを許可する場合、ソースシステムを変更できることに注意してください（たとえば、ディレクトリまたは S3 ソースからファイルを削除したり、任意の SQL を使用してデータベースからデータを削除したりします）。データへのアクセスを許可するアカウントに対しても完全なアクセスを許可するユーザーにのみ、ソース（またはそれを含むプロジェクト）への編集アクセスを許可する必要があります。
ビューアー
Sync の権限は、関連するソースと出力データセットから導き出されます。
オーナー
エディター
ビューアー
Webhook の権限は、関連するソースから完全に継承されます。
デフォルトでは、Webhook を実行するユーザーのみが、Data Connection アプリケーションの履歴タブを使用してレスポンスを表示できます。webhooks:read-privileged-data 権限をカスタムまたはデフォルトのロールに追加することで、そのロールを持つユーザーがアクセスできるすべての Webhook の完全なリクエストおよびレスポンス履歴を表示できるようになります。標準的な推奨設定は、この権限を持つ新しいロール「Webhook Privileged Data Viewer」を追加し、関連するソースで完全な Webhook 履歴を表示する必要があるユーザーにこのロールを与えることです。
上記で説明したように、リソースには組織およびマーキングが適用され、アクセス制御の追加レベルとして機能します。ソースに適用された組織とマーキングは、そのソースの Sync から生成されたデータセットに伝播します。これは、ユーザーがソースから生成されたすべてのデータセットのデータを表示できない限り、そのソースに適用されたすべての組織とマーキングにアクセスする必要があることを意味します。
ソースには、さまざまな感度レベルのデータが含まれる可能性があるため、そのソースで利用可能なデータに適用されるすべての組織とマーキングでソースをマークすることをお勧めします。その後、stop_propagatingおよび/またはstop_requiring機能を使用してデータをクリーンおよびマーク解除するために変換を使用します。マーキング解除の詳細については、マーキングの削除および継承されたマーキングの削除に関するガイドを参照してください。
データが同期された後にデータに組織とマーキングを適用するだけでは十分ではないことに注意してください。ソースへのアクセスはデータへのアクセスと同等であるため、ソースにはそれが含むすべてのものに適用される組織とマーキングでマークする必要があります。
簡単に思い出していただくと、主要な Data Connection リソースはエージェントとソースです。プラグインとドライバーはエージェントにデプロイされて機能が拡張されます。
エージェントの推奨される権限設定は2つあります。すべてのエージェントが 1 つのプロジェクトにまとめられた組織ごと、またはそれぞれのエージェントが独自のプロジェクトにある場合です。上記の図は前者のオプションを示しており、以下のガイダンスは、それぞれのオプションを選択する理由を説明しています。
オプション1：すべてのエージェントを組織ごとに1つのプロジェクトに配置する。
すべてのエージェントを1つのプロジェクトに配置することは、最もクリーンなアプローチであり、すべてのエージェントを管理する1つのユーザーグループがある場合に推奨されます。これにより、エージェントへのアクセスをプロジェクトレベルで制御し、エージェントの下流でソースと Sync を別々に許可できます。
すべてのエージェントマネージャーとすべてのソースエディターがすべてのエージェントにアクセスすることが許容される場合にのみ、このオプションを選択してください。エージェントにソースをデプロイするには、ユーザーはそのエージェントの編集権限を持っている必要があることに注意してください。
オプション2：それぞれのエージェントを独自のプロジェクトに配置する。
このアプローチでは、エージェントの権限を完全に粒度化できます。また、ソース管理の進化の過程でいつでも「グルーピング」から構造が逸脱しないことが保証されます。たとえば、ソースにアクセスするためにエージェントグループ全体にアクセスを許可することなく、エージェントをソースに割り当て/割り当て解除できますし、将来のグループ権限の変更に対してプロジェクトの再構成が不要になります。
エージェントを管理する複数のグループがあり、エージェントへのアクセスを個別に許可したい場合、このアプローチが推奨されます。
エージェントを含むプロジェクトの編集者は、そのエージェントで実行される新しいソースや Sync を作成できます。これを行うために、プロジェクトにエディターの役割を与えていないユーザーに注意してください。
各ソースは、datasourceレイヤー内の独自のプロジェクトに配置する必要があります。ソースで定義された各 Sync は、ソースと同じプロジェクト内のデータセットに出力する必要があります。ソースに PII などの機密データが含まれている場合、ソースにマーキングを適用し、出力データセットに伝播させることができます。
ソースを含むプロジェクトの編集者は、そのソースの新しい Sync を作成し、既存の Sync を編集できます。また、Webhook を作成し、Foundry の他の部分で使用するように設定できます。
Sync がソースシステムを変更できることに注意してください。これには、ソース資格情報が許可する場合、ディレクトリまたは S3 ソースからファイルを削除したり、任意の SQL を使用してデータベースからデータを削除したりすることが含まれます。
データへのアクセスを許可するアカウントに対しても完全なアクセスを許可するユーザーにのみ、ソース（またはそれを含むプロジェクト）への編集アクセスを許可する必要があります。
プラグインと JDBC ドライバーには、2つの推奨される権限設定があります。すべてのリソースが 1 つのプロジェクトにまとめられた組織ごと、またはそれぞれの JDBC /ドライバーがそれを必要とする 1 つ以上のエージェントと共にプロジェクトにある場合です。
オプション1：すべてのプラグインとドライバーを組織ごとに1つのプロジェクトに配置する。
すべてのエージェントを管理する1つのユーザーグループがある場合に推奨されます。これにより、エージェントマネージャーは、アップロードされたすべてのプラグインとドライバーにアクセスできます。すべてのエージェントマネージャー間でプラグインとドライバーへのアクセスが均等である場合にのみ、このアプローチを選択する必要があります。
このアプローチを実装するための推奨される手順は次のとおりです。
オプション2：それぞれのプラグインとドライバータイプを独自のプロジェクトに配置する。
このアプローチでは、特定の「センシティブ」なプラグインやドライバーを、他のものとは別に許可できます。このアプローチを採用する場合は、必要なエージェントオーナーに適切な権限を各プロジェクトに付与し、エージェントで使用できるようにする必要があります。