注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
Data Connection の主要な概念である Agent、ソース、同期は、すべて Foundry でリソースとして管理されます。これにより、プロジェクトやフォルダーにわたってこれらのリソースを柔軟に整理でき、マーキングなどのセキュリティプリミティブを Data Connection リソースに適用できます。
プラットフォームの所有者は、Data Connection リソースを過度に共有しないよう注意してください。ソースや Agent の閲覧権限および編集権限を持つユーザーは、信頼できるパイプライン開発者である必要があります。同期によって生成されたデータセットは、必要に応じて下流の Transforms プロジェクトにインポートできます。これにより、Agent やソースへのアクセスを共有せずに、データへのアクセスを付与できます。
このページでは、次のものを含むすべての Data Connection リソースの権限の仕組みについて説明します。
このセクションで説明する権限はデフォルトのものです。一部の環境では、カスタムロールを使用してデフォルトの権限の動作が変更されている場合があります。
所有者
Agent の所有者は通常、その作成者であり、次の権限を持ちます。
編集者
Agent の編集者は、次の操作を実行できます。
プロジェクト内に Agent を作成するには、そのプロジェクトの編集者である必要がありますが、そのプロジェクト内の Agent を管理するには、プロジェクトの所有者である必要があります。このため、Agent を作成できても、その Agent のダウンロードリンクの生成や、その他の管理タスクを実行できない場合があります。
閲覧者
Agent の閲覧者は、次の操作を実行できます。
所有者
デフォルトでは、ソースの所有者は編集者の権限を継承します。
ソースの所有者は、次の操作も実行できます。
エクスポート可能なマーキングまたは組織を追加する際に、情報セキュリティ責任者ロールは必要ありません。
編集者
ソースの編集者は、次の操作を実行できます。
ソースの資格情報で許可されている場合、同期によってソースシステムを変更できることに留意してください（たとえば、ディレクトリや S3 ソースからのファイルの削除、任意の SQL によるデータベースからのデータの削除など）。ソース（またはそれを含むプロジェクト）への編集アクセスは、そのソースがデータへのアクセスに使用するアカウントへのフルアクセスも許可できるユーザーにのみ付与してください。
閲覧者
ほとんどの環境では、ネットワークエグレスポリシーを使用して、Foundry から送信されるトラフィックを管理します。エグレスポリシーは、許可される宛先とそれを使用できるユーザーを制御するため、ユーザーは組織レベルの追加制限なしにソースやワークフローを作成できます。
ロールベースのソース作成は、組織内でソースを作成できるユーザーを制限するための、任意の追加制御です。この設定は Control Panel で有効または無効にできます。
この設定は組織全体に適用されます。どちらの場合も、既存のソースには引き続きプロジェクトの権限が適用されます。この設定はソースの作成を制御するものであり、エグレスポリシーによる管理に代わるものでも、既存のソースの権限を変更するものでもありません。
この設定を変更するには、該当する組織に対するソース作成の認可方法の管理ワークフローが必要です。組織管理者ロールには、デフォルトでこのワークフローが含まれています。
ロールベースのソース作成を有効にする場合は、まず、ソースを作成する必要があるユーザーまたはグループに、Data Connection ソースの作成ワークフローを含むロールを付与してください。このワークフローを付与するには、カスタムロールを含む組織ロールを使用できます。
同期の権限は、関連するソースと出力データセットの権限によって決まります。
所有者
編集者
閲覧者
Webhook の権限は、関連付けられたソースからすべて継承されます。
デフォルトでは、Webhook を実行したユーザーのみが、Data Connection アプリケーションの履歴タブでレスポンスを閲覧できます。カスタムまたはデフォルトのロールに webhooks:read-privileged-data 権限を追加すると、そのロールを持つユーザーは、アクセス可能なすべての Webhook のリクエストとレスポンスの全履歴を閲覧できます。標準的な推奨セットアップは、この権限を持つ「Webhook 特権データ閲覧者」という新しいロールを追加し、Webhook の全履歴を閲覧する必要があるユーザーが、関連するソースに対してこのロールを持つようにすることです。
ソースがコードリソースにインポートされると、リポジトリへの編集アクセスを持つユーザーは、そのソースに設定された接続情報を使用してカスタムコードを記述でき、シークレット値にもアクセスできます。
このため、ソースをコードにインポートする機能と、ソースへの編集者アクセスの付与は慎重に管理し、信頼できるユーザーにのみソースとリポジトリへのアクセスを許可してください。
関数リポジトリで Webhook を使用する際の権限の詳細については、外部関数の権限に関するドキュメントを参照してください。
前述のとおり、リソースにはアクセス制御の追加レイヤーとして組織とマーキングを適用できます。ソースに適用された組織とマーキングは、そのソースの同期によって生成されるデータセットに伝播します。つまり、そのソースに適用されたすべての組織とマーキングへのアクセス権がなければ、そのソースから生成されるどのデータセットのデータも閲覧できません。
ソースには機密性のレベルが異なるデータが含まれる可能性が高いため、そのソースで利用可能なデータに適用されるすべての組織とマーキングをソースにつけることを推奨します。そのうえで、トランスフォームを使用してデータをクレンジングし、stop_propagating や stop_requiring の機能を使用してマーキングを削除します。マーキングの削除については、マーキングの削除と継承されたマーキングの削除のガイドを参照してください。
同期後のデータに組織とマーキングを適用するだけで十分とは考えないでください。ソースへのアクセスは実質的にデータへのアクセスを意味するため、ソースに含まれるあらゆるデータに適用される組織とマーキングをソースにつける必要があります。
簡単におさらいすると、Data Connection の主要なリソースは Agent とソースです。プラグインとドライバーは、機能を拡張するために Agent にデプロイされます。
Agent の権限設定には、組織ごとにすべての Agent を1つのプロジェクトに配置する方法と、Agent ごとに専用のプロジェクトに配置する方法の2つが推奨されます。上の図は前者を示しています。以下では、それぞれの選択肢を選ぶ理由を説明します。
選択肢1：組織ごとにすべての Agent を1つのプロジェクトに配置する。
すべての Agent を1つのプロジェクトに配置する方法は最もシンプルで、1つのユーザーグループがすべての Agent を管理している場合に推奨されます。この方法では、Agent へのアクセスをプロジェクトレベルで制御し、Agent の下流にあるソースと同期の権限を個別に設定できます。
この選択肢は、すべての Agent 管理者とすべてのソース編集者が、すべての Agent にアクセスできても問題ない場合にのみ選んでください。Agent にソースをデプロイするには、その Agent に対する編集者権限が必要です。
選択肢2：Agent ごとに専用のプロジェクトに配置する。
この方法では、Agent の権限を細かく制御できます。また、ソース管理が変化しても、構造が「グループ分け」からずれないことが保証されます。たとえば、ユーザーに Agent のグループ全体へのアクセス権を付与することなく、ソースへの Agent の割り当てや割り当て解除を安全に行えます。また、将来グループの権限が変更されても、それに対応するためにプロジェクトを再編成する必要はありません。
この方法は、複数のグループが Agent を管理しており、グループごとに Agent へのアクセス権を個別に設定したい場合に推奨されます。
Agent が含まれるプロジェクトの編集者は、その Agent 上で実行される新しいソースと同期を作成できます。この操作を許可すべきでないユーザーに、プロジェクトの編集者ロールを付与しないようにしてください。
各ソースは、datasource レイヤーの専用プロジェクトに配置する必要があります。ソースで定義される各同期は、そのソースと同じプロジェクト内のデータセットに出力する必要があります。ソースに PII などの機密データが含まれる場合は、ソースにマーキングを適用すると、出力データセットに伝播します。
ソースが含まれるプロジェクトの編集者は、そのソースの新しい同期を作成し、既存の同期を編集できます。また、Webhook を作成し、Foundry のほかの場所で使用するための設定も行えます。
ソースの資格情報で許可されている場合、同期はソースシステムを変更できます。たとえば、Directory ソースや S3 ソースからファイルを削除したり、任意の SQL を実行してデータベースからデータを削除したりできます。ソース（またはそのプロジェクト）への編集アクセス権は、そのソースが使用するアカウントへのフルアクセスも付与してよいユーザーにのみ付与してください。
プラグインと JDBC ドライバーの権限設定には、組織ごとにすべてのリソースを1つのプロジェクトに配置する方法と、各 JDBC / ドライバーを、それを必要とする1つ以上の Agent と同じプロジェクトに配置する方法の2つが推奨されます。
選択肢1：組織ごとにすべてのプラグインとドライバーを1つのプロジェクトに配置する。
この方法は、1つのユーザーグループがすべての Agent を管理している場合に推奨されます。Agent 管理者は、アップロードされたすべてのプラグインとドライバーにアクセスできます。この方法は、すべての Agent 管理者にプラグインとドライバーへの同じアクセス権を付与する必要がある場合にのみ選択してください。
この方法を実施するための推奨手順は次のとおりです。
選択肢2：プラグインとドライバーの種類ごとに専用のプロジェクトに配置する。
この方法では、特定の「機密性の高い」プラグインやドライバーの権限を、ほかのものとは別に設定できます。この方法を採用する場合は、それらを必要とする Agent の所有者が Agent 上で使用できるよう、各プロジェクトで十分な権限を付与してください。