AWS Clean Rooms ML の IAM 動作 - AWS Clean Rooms

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Clean Rooms ML の IAM 動作

クロスアカウントジョブ

Clean Rooms ML を使用すると、ある によって作成された特定のリソース AWS アカウント に別の によってアカウントで安全にアクセスできます AWS アカウント。 AWS アカウント A のクライアントが AWS アカウント B が所有するConfiguredAudienceModelリソースStartAudienceGenerationJobで を呼び出すと、Clean Rooms ML はジョブに 2 つの ARNs を作成します。A の ARN AWS アカウント と AWS アカウント B の ARN。ARNsは、ARN を除いて同一です AWS アカウント。

Clean Rooms ML は、両方のアカウントがそれぞれ独自の IAM ポリシーをジョブに適用できるように、ジョブ用に 2 つの ARN を作成します。たとえば、両方のアカウントでタグベースのアクセスコントロールを使用し、 AWS 組織からのポリシーを適用できます。ジョブは両方のアカウントのデータを処理するため、どちらのアカウントでもジョブとそれに関連するデータを削除できます。どちらのアカウントも、もう一方のアカウントによるジョブの削除をブロックすることはできません。

ジョブの実行は 1 つだけで、どちらのアカウントも ListAudienceGenerationJobs を呼び出してジョブを確認できます。どちらのアカウントもGet、独自の AWS アカウント ID を持つ ARN を使用して、ジョブで 、Delete、および Export APIs を呼び出すことができます。

他の AWS アカウント ID で ARN を使用する場合、 はジョブにアクセス AWS アカウント できません。

ジョブの名前は AWS アカウント内で一意である必要があります。 AWS アカウント B の名前は $accountA-$name です。 AWS アカウント A によって選択された名前は、ジョブが AWS アカウント B で表示されるときに A という AWS アカウント プレフィックスが付けられます。

クロスアカウントStartAudienceGenerationJobを成功させるには、 AWS アカウント B で次の例のようなリソースポリシーを使用して、 AWS アカウント B の新しいジョブと AWS アカウント B ConfiguredAudienceModelの新しいジョブの両方でそのアクションを許可する必要があります。

JSON
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Clean-Rooms-CAMA-ID", "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": [ "cleanrooms-ml:StartAudienceGenerationJob" ], "Resource": [ "arn:aws:cleanrooms-ml:us-east-1:444455556666:configured-audience-model/id", "arn:aws:cleanrooms-ml:us-east-1:444455556666:audience-generation-job/*" ], "Condition":{"StringEquals":{"cleanrooms-ml:CollaborationId":"UUID"}} } ] }
注記

この AWS Clean Rooms ML リソースポリシーは、クロスアカウントオーディエンス生成をサポートするために 2 つの異なる AWS アカウント IDs を参照します。

  • 111122223333 - これは、オーディエンス生成ジョブを開始する権限を持つプリンシパル (ユーザー、ロール、またはサービス) を含むアカウントです。このアカウントは ML 処理ワークフローを開始します。

  • 444455556666 - これは ML AWS Clean Rooms リソース (設定されたオーディエンスモデルとオーディエンス生成ジョブ) を所有するアカウントです。このアカウントは ML モデルをホストし、ジョブの実行を管理します。

その他の設定に関する注意事項:

  • ステートメント ID (Sid): を実際の AWS Clean Rooms オーディエンスモデルアプリケーション (CAMA) 識別子CAMA-IDに置き換えて、ポリシーステートメントを簡単に識別できるようにします。

  • リソース IDs: ID を設定したオーディエンスモデルの実際の ID に置き換え、UUID を特定のコラボレーション ID に置き換えます。

  • 条件: cleanrooms-ml:CollaborationId条件は、指定された AWS Clean Rooms コラボレーションのコンテキスト内でのみオーディエンス生成ジョブを開始できるようにし、追加のセキュリティ境界を提供します。

このクロスアカウント設定により、1 つの組織が ML モデルとインフラストラクチャを管理し、承認されたパートナーがコラボレーション契約の範囲内でオーディエンス生成プロセスを開始できるようにするシナリオが可能になります。

AWS Clean Rooms ML API を使用して、 を true manageResourcePoliciesに設定して設定された類似モデルを作成する場合、 はこのポリシー AWS Clean Rooms を作成します。

さらに、 AWS アカウント A の発信者の ID ポリシーには、 に対する StartAudienceGenerationJob アクセス許可が必要ですarn:aws:cleanrooms-ml:us-west-1:AccountA:audience-generation-job/*。したがって、アクション には 3 つの IAM リソースがありますStartAudienceGenerationJob。A ジョブ、 AWS アカウント B AWS アカウント ジョブ、 AWS アカウント および B ですConfiguredAudienceModel

警告

ジョブ AWS アカウント を開始した は、ジョブに関する AWS CloudTrail 監査ログイベントを受け取ります。ConfiguredAudienceModel を所有する AWS CloudTrail は AWS アカウント 監査ログイベントを受信しません。

ジョブのタグ付け

CreateConfiguredAudienceModelchildResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE パラメータを設定すると、設定した類似モデルから作成されたアカウント内のすべての類似セグメント生成ジョブには、設定した類似モデルと同じタグがデフォルトで割り当てられます。設定した類似モデルが親で、類似セグメント生成ジョブが子です。

自身のアカウント内でジョブを作成する場合、ジョブのリクエストタグは親タグよりも優先されます。他のアカウントが作成したジョブが、自身のアカウントにタグを作成することはありません。childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE を設定し、別のアカウントでジョブを作成した場合、そのジョブのコピーは 2 つあります。アカウントのコピーには親リソースタグが付けられ、ジョブ送信者のアカウントのコピーにはリクエストのタグが付けられます。

共同作業者の検証

AWS Clean Rooms コラボレーションの他のメンバーにアクセス許可を付与する場合、リソースポリシーには条件キー を含める必要がありますcleanrooms-ml:CollaborationId。これにより、StartAudienceGenerationJob リクエストに collaborationId パラメータが含まれるように強制されます。collaborationId パラメータがリクエストに含まれると、Clean Rooms ML はコラボレーションが存在すること、ジョブの送信者がコラボレーションのアクティブメンバーであること、設定済みの類似モデルの所有者がコラボレーションのアクティブメンバーであることを検証します。

が設定された類似モデルリソースポリシー AWS Clean Rooms を管理する場合 ( manageResourcePoliciesパラメータは CreateConfiguredAudienceModelAssociation リクエストTRUEにあります)、この条件キーはリソースポリシーで設定されます。そのため、AudienceGenerationJobcollaborationId を指定する必要があります。

クロスアカウントアクセス

アカウント間で呼び出せるのは StartAudienceGenerationJob のみです。その他の Clean Rooms ML API はすべて、自身のアカウントのリソースでのみ使用できます。これにより、トレーニングデータ、類似モデルの設定、その他の情報は非公開のままになります。

Clean Rooms ML は、アカウント間で Amazon S3 または AWS Glue ロケーションを公開しません。トレーニングデータの場所、設定済みの類似モデルの出力場所、および類似セグメント生成ジョブシードの場所は、どのアカウントでも表示されません。コラボレーションでクエリログ記録が有効になっていない限り、シードデータが SQL クエリから取得されるかどうかに関わらず、クエリ自体はアカウント間で表示されません。別のアカウントが送信したオーディエンス生成ジョブを Get した場合、サービスにはシードロケーションは表示されません。