翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# の Identity and Access Management AWS Clean Rooms
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を*認証* (サインイン) し、誰に AWS Clean Rooms リソースの使用*を許可する* (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。
**Topics**
+ [オーディエンス](#security-iam-audience)
+ [アイデンティティを使用した認証](#security-iam-auth-with-identities)
+ [ポリシーを使用したアクセスの管理](#security-iam-managing-access)
+ [が IAM と AWS Clean Rooms 連携する方法](security_iam_service-with-iam.md)
+ [のアイデンティティベースのポリシーの例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)
+ [AWS の 管理ポリシー AWS Clean Rooms](security-iam-awsmanpol.md)
+ [AWS Clean Rooms ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)
+ [サービス間の混乱した代理の防止](cross-service-confused-deputy-prevention.md)
+ [AWS Clean Rooms ML の IAM 動作](ml-behaviors.md)
+ [クリーンルーム ML カスタムモデルの IAM 動作](ml-behaviors-byom.md)
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[AWS Clean Rooms ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[が IAM と AWS Clean Rooms 連携する方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[のアイデンティティベースのポリシーの例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティを使用した認証
認証は、ID 認証情報 AWS を使用して にサインインする方法です。として、IAM ユーザーとして AWS アカウントのルートユーザー、または IAM ロールを引き受けることによって、*認証 (* にサインイン AWS) される必要があります。
ID ソースを介して提供された認証情報を使用して、フェデレーティッド ID AWS として にサインインできます。 AWS IAM アイデンティティセンター (IAM Identity Center) ユーザーまたは会社のシングルサインオン認証は、フェデレーティッドアイデンティティの例です。フェデレーティッド ID としてサインインする場合、IAM ロールを使用して、前もって管理者により ID フェデレーションが設定されています。フェデレーション AWS を使用して にアクセスすると、間接的にロールを引き受けることになります。
ユーザーのタイプに応じて、 AWS マネジメントコンソール または AWS アクセスポータルにサインインできます。へのサインインの詳細については AWS、「 *AWS サインイン ユーザーガイド*[」の「 へのサインイン AWS アカウント](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)方法」を参照してください。
AWS プログラムで にアクセスする場合、 はソフトウェア開発キット (SDK) とコマンドラインインターフェイス (CLI) AWS を提供し、認証情報を使用してリクエストを暗号化して署名します。 AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。推奨される方法を使用して自分でリクエストに署名する方法の詳細については、「AWS 全般のリファレンス」の「[署名バージョン 4 の署名プロセス](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html)」を参照してください。
使用する認証方法を問わず、追加セキュリティ情報の提供をリクエストされる場合もあります。たとえば、 AWS では、多要素認証 (MFA) を使用してアカウントのセキュリティを強化することをお勧めします。詳細については、「AWS IAM アイデンティティセンター ユーザーガイド」の「[Multi-factor authentication](https://docs.aws.amazon.com//singlesignon/latest/userguide/enable-mfa.html)」(多要素認証) および「IAM ユーザーガイド」の「[AWSでの多要素認証 (MFA) の使用](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_mfa.html)」を参照してください。
### AWS アカウント ルートユーザー
を作成するときは AWS アカウント、アカウント内のすべての AWS のサービス およびリソースへの完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。このアイデンティティは AWS アカウント *ルートユーザー*と呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでサインインすることによってアクセスできます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザーの認証情報を保護し、この認証情報はルートユーザーのみが実行できるタスクに使用します。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、「**AWS 全般のリファレンス」の「[AWS アカウントのルートユーザー の認証情報と IAM ID](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。
*フェデレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID Directory Service ソースの認証情報 AWS のサービス を使用して にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、 AWS IAM アイデンティティセンターをお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスすることを人間のユーザーに要求する AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。[ユーザーから IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用したアクセスの管理
でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは AWS 、アイデンティティまたはリソースに関連付けられているときにアクセス許可を定義する のオブジェクトです。 は、プリンシパル (ユーザー、ルートユーザー、またはロールセッション) がリクエストを行うときに、これらのポリシー AWS を評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
すべての IAM エンティティ (ユーザーまたはロール) は、許可のない状態からスタートします。デフォルトでは、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行する許可をユーザーに付与するには、管理者がユーザーに許可ポリシーをアタッチする必要があります。また、管理者は、必要な許可があるグループにユーザーを追加できます。管理者がグループに許可を付与すると、そのグループ内のすべてのユーザーにこれらの許可が付与されます。
IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、`iam:GetRole` アクションを許可するポリシーがあるとします。そのポリシーを持つユーザーは、 AWS マネジメントコンソール、、 AWS CLIまたは AWS API からロール情報を取得できます。
### アイデンティティベースポリシー
アイデンティティベースのポリシーは、IAM ユーザーグループ、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
アイデンティティベースのポリシーは、さらに*インラインポリシー*または*マネージドポリシー*に分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれます。マネージドポリシーは、 AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。管理ポリシーには、 AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、*IAM ユーザーガイド*の[マネージドポリシーとインラインポリシーの比較](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
### その他のポリシータイプ
AWS は、一般的でない追加のポリシータイプをサポートします。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。
+ **アクセス許可の境界** - アクセス許可の境界は、アイデンティティベースポリシーによって IAM エンティティ (IAM ユーザーまたはロール) に付与できる権限の上限を設定する高度な機能です。エンティティに許可の境界を設定できます。結果として許可される範囲は、エンティティのアイデンティティベースポリシーとその許可の境界の共通部分になります。`Principal` フィールドでユーザーまたはロールを指定するリソースベースのポリシーでは、許可の境界は制限されません。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。アクセス許可の境界の詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCPs)** – SCPsは、 の組織または組織単位 (OU) の最大アクセス許可を指定する JSON ポリシーです AWS Organizations。 AWS Organizations は、ビジネスが所有する複数の をグループ化して一元管理するためのサービス AWS アカウント です。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP は、各 を含むメンバーアカウントのエンティティのアクセス許可を制限します AWS アカウントのルートユーザー。Organizations と SCP の詳細については、*AWS Organizations ユーザーガイド*の「[SCP の仕組み](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html)」を参照してください。
+ **セッションポリシー** - セッションポリシーは、ロールまたはフェデレーションユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果としてセッションの権限は、ユーザーまたはロールのアイデンティティベースポリシーとセッションポリシーの共通部分になります。また、リソースベースのポリシーから権限が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。が複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# が IAM と AWS Clean Rooms 連携する方法
IAM を使用して へのアクセスを管理する前に AWS Clean Rooms、 で使用できる IAM 機能を確認してください AWS Clean Rooms。
**で使用できる IAM 機能 AWS Clean Rooms**
| IAM 機能 | AWS Clean Rooms サポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | 部分的 |
| [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | はい |
| [ポリシー条件キー (サポート固有)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | 部分的 |
| [ACL](#security_iam_service-with-iam-acls) | なし |
| [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | あり |
| [一時的な認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり |
| [転送アクセスセッション (FAS)](#security_iam_service-with-iam-principal-permissions) | あり |
| [サービスロール](#security_iam_service-with-iam-roles-service) | あり |
| [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | いいえ |
AWS Clean Rooms およびその他の がほとんどの IAM 機能と AWS のサービス 連携する方法の概要を把握するには、[AWS のサービス 「IAM ユーザーガイド」の「IAM と連携する ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 **
## のアイデンティティベースのポリシー AWS Clean Rooms
**アイデンティティベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### のアイデンティティベースのポリシーの例 AWS Clean Rooms
AWS Clean Rooms アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)。
## 内のリソースベースのポリシー AWS Clean Rooms
**リソースベースのポリシーのサポート:** 一部
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
この AWS Clean Rooms サービスは、*設定された類似モデルマネージドリソースポリシーと呼ばれる 1 つのタイプのリソースベースのポリシー*のみをサポートします。これは、設定された類似モデルにアタッチされます。このポリシーは、設定済みの類似モデルでアクションを実行できるプリンシパルを定義します。
リソースベースのポリシーを設定済みの類似モデルにアタッチする方法については、「**[AWS Clean Rooms ML の IAM 動作](ml-behaviors.md)**」を参照してください。
## のポリシーアクション AWS Clean Rooms
**ポリシーアクションのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
AWS Clean Rooms アクションのリストを確認するには、*「サービス認可リファレンス*」の「 [で定義されるアクション AWS Clean Rooms](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscleanrooms.html)」を参照してください。
のポリシーアクションは、アクションの前に次のプレフィックス AWS Clean Rooms を使用します。
```
cleanrooms
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"cleanrooms:action1",
"cleanrooms:action2"
]
```
AWS Clean Rooms アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)。
## のポリシーリソース AWS Clean Rooms
**ポリシーリソースのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
AWS Clean Rooms リソースタイプとその ARNs[「 で定義されるリソース AWS Clean Rooms](https://docs.aws.amazon.com/service-authorization/latest/reference/list_your_service.html#your_service-resources-for-iam-policies)」を参照してください。 **どのアクションで各リソースの ARN を指定できるかについては、「[AWS Clean Roomsで定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_your_service.html#your_service-actions-as-permissions)」を参照してください。
AWS Clean Rooms アイデンティティベースのポリシーの例を表示するには、「」を参照してください[のアイデンティティベースのポリシーの例 AWS Clean Rooms](security_iam_id-based-policy-examples.md)。
## のポリシー条件キー AWS Clean Rooms
**サービス固有のポリシー条件キーのサポート:** 部分的
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*「IAM ユーザーガイド*」の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
AWS Clean Rooms ML がポリシー条件キーを使用する方法については、「」を参照してください**[AWS Clean Rooms ML の IAM 動作](ml-behaviors.md)**。
## ACLs AWS Clean Rooms
**ACL のサポート:** なし
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## を使用した ABAC AWS Clean Rooms
**ABAC (ポリシー内のタグ) のサポート:** あり
属性ベースのアクセス制御 (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグをアタッチし、プリンシパルのタグがリソースのタグと一致するときにオペレーションを許可するように ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
## での一時的な認証情報の使用 AWS Clean Rooms
**一時的な認証情報のサポート:** あり
一時的な認証情報は AWS 、リソースへの短期的なアクセスを提供し、フェデレーションまたはスイッチロールの使用時に自動的に作成されます。長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成 AWS することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## の転送アクセスセッション AWS Clean Rooms
**転送アクセスセッション (FAS) のサポート:** あり
転送アクセスセッション (FAS) は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストをリクエストする を使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## のサービスロール AWS Clean Rooms
**サービスロールのサポート:** あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービスに許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
**警告**
サービスロールのアクセス許可を変更すると、 AWS Clean Rooms 機能が破損する可能性があります。 AWS Clean Rooms が指示する場合にのみ、サービスロールを編集します。
## のサービスにリンクされたロール AWS Clean Rooms
**サービスにリンクされたロールのサポート:** なし
サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携するAWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。
# のアイデンティティベースのポリシーの例 AWS Clean Rooms
デフォルトでは、 ユーザーおよびロールには、 AWS Clean Rooms リソースを作成または変更する権限はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
各リソースタイプの ARN の形式など AWS Clean Rooms、 で定義されるアクションとリソースタイプの詳細については、*「サービス認可リファレンス*」の[「 のアクション、リソース、および条件キー AWS Clean Rooms](https://docs.aws.amazon.com/service-authorization/latest/reference/list_your_service.html)」を参照してください。 ARNs
**Topics**
+ [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [AWS Clean Rooms コンソールの使用](#security_iam_id-based-policy-examples-console)
+ [自分の権限の表示をユーザーに許可する](#security_iam_id-based-policy-examples-view-own-permissions)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、アカウント内の AWS Clean Rooms リソースを誰かが作成、アクセス、または削除できるかどうかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## AWS Clean Rooms コンソールの使用
AWS Clean Rooms コンソールにアクセスするには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、 の AWS Clean Rooms リソースの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
ユーザーとロールが AWS Clean Rooms 引き続きコンソールを使用できるようにするには、エンティティに AWS Clean Rooms `FullAccess`または `ReadOnly` AWS 管理ポリシーもアタッチします。詳細については、「*IAM ユーザーガイド*」の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
## 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS の 管理ポリシー AWS Clean Rooms
AWS 管理ポリシーは、 によって作成および管理されるスタンドアロンポリシーです AWS。 AWS 管理ポリシーは、ユーザー、グループ、ロールにアクセス許可の割り当てを開始できるように、多くの一般的なユースケースにアクセス許可を提供するように設計されています。
AWS 管理ポリシーは、すべての AWS お客様が使用できるため、特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることに注意してください。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS 管理ポリシーで定義されているアクセス許可は変更できません。が AWS マネージドポリシーで定義されたアクセス許可 AWS を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS マネージドポリシーを更新する可能性が最も高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS 管理ポリシー: `AWSCleanRoomsReadOnlyAccess`
`AWSCleanRoomsReadOnlyAccess` をIAM プリンシパルにアタッチできます。
このポリシーは、`AWSCleanRoomsReadOnlyAccess` コラボレーションのリソースとメタデータへの読み取り専用のアクセス許可を付与します。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `CleanRoomsRead` - プリンシパルにサービスへの読み取り専用アクセスを許可します。
+ `ConsoleDisplayTables` – プリンシパルに、基盤となる AWS Glue テーブルに関するデータをコンソールに表示するために必要な AWS Glue メタデータへの読み取り専用アクセスを許可します。
+ `ConsoleLogSummaryQueryLogs` - プリンシパルにクエリログの閲覧を許可します。
+ `ConsoleLogSummaryObtainLogs` - プリンシパルにログ結果の取得を許可します。
ポリシーの詳細の JSON リストについては、*AWS 「 マネージドポリシーリファレンスガイド*」の[AWSCleanRoomsReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsReadOnlyAccess.html)」を参照してください。
## AWS 管理ポリシー: `AWSCleanRoomsFullAccess`
`AWSCleanRoomsFullAccess` をIAM プリンシパルにアタッチできます。
このポリシーは、 AWS Clean Rooms コラボレーションのリソースとメタデータへのフルアクセス (読み取り、書き込み、更新) を許可する管理アクセス許可を付与します。このポリシーには、クエリを実行するためのアクセス許可が含まれています。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `CleanRoomsAccess` – すべてのリソースに対するすべてのアクションへのフルアクセスを許可します AWS Clean Rooms。
+ `PassServiceRole` - 名前に「cleanrooms」が含まれるサービスのみにサービスロールを渡すためのアクセス許可 (`PassedToService` 条件) を付与します。
+ `ListRolesToPickServiceRole` – プリンシパルが使用時にサービスロールを選択できるように、すべてのロールを一覧表示できるようにします AWS Clean Rooms。
+ `GetRoleAndListRolePoliciesToInspectServiceRole` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `ListPoliciesToInspectServiceRolePolicy` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `GetPolicyToInspectServiceRolePolicy` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `ConsoleDisplayTables` – プリンシパルに、基盤となる AWS Glue テーブルに関するデータをコンソールに表示するために必要な AWS Glue メタデータへの読み取り専用アクセスを許可します。
+ `ConsolePickQueryResultsBucketListAll` - 使用可能なすべての Amazon S3 バケットのリストから、クエリ結果を書き込む S3 バケットを選択することをプリンシパルに許可します。
+ `SetQueryResultsBucket` – クエリ結果を書き込む S3 バケットを選択することをプリンシパルに許可します。
+ `ConsoleDisplayQueryResults` – S3 バケットから読み取ったクエリ結果を顧客に示すことをプリンシパルに許可します。
+ `WriteQueryResults` – クエリ結果を顧客所有の S3 バケットに書き込むことをプリンシパルに許可します。
+ `EstablishLogDeliveries` – 顧客の Amazon CloudWatch Logs ロググループにクエリログを提供することをプリンシパルに許可します。
+ `SetupLogGroupsDescribe` – Amazon CloudWatch Logs ロググループの作成プロセスを使用することをプリンシパルに許可します。
+ `SetupLogGroupsCreate` – プリンシパルに Amazon CloudWatch Logs ロググループの作成を許可します。
+ `SetupLogGroupsResourcePolicy` – Amazon CloudWatch Logs ロググループにリソースポリシーを設定することをプリンシパルに許可します。
+ `ConsoleLogSummaryQueryLogs` - プリンシパルにクエリログの閲覧を許可します。
+ `ConsoleLogSummaryObtainLogs` - プリンシパルにログ結果の取得を許可します。
ポリシーの詳細の JSON リストについては、*AWS 「 マネージドポリシーリファレンスガイド*」の[AWSCleanRoomsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsFullAccess.html)」を参照してください。
## AWS 管理ポリシー: `AWSCleanRoomsFullAccessNoQuerying`
IAM principals に `AWSCleanRoomsFullAccessNoQuerying` をアタッチできます。
このポリシーは、 AWS Clean Rooms コラボレーションのリソースとメタデータへのフルアクセス (読み取り、書き込み、更新) を許可する管理アクセス許可を付与します。このポリシーでは、クエリを実行するためのアクセス許可は除外されます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `CleanRoomsAccess` – コラボレーションでのクエリを除く AWS Clean Rooms、 のすべてのリソースに対するすべてのアクションへのフルアクセスを許可します。
+ `CleanRoomsNoQuerying` – `StartProtectedQuery` と `UpdateProtectedQuery` を明示的に拒否し、クエリを禁止します。
+ `PassServiceRole` - 名前に「cleanrooms」が含まれるサービスのみにサービスロールを渡すためのアクセス許可 (`PassedToService` 条件) を付与します。
+ `ListRolesToPickServiceRole` – プリンシパルが使用時にサービスロールを選択できるように、すべてのロールを一覧表示できるようにします AWS Clean Rooms。
+ `GetRoleAndListRolePoliciesToInspectServiceRole` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `ListPoliciesToInspectServiceRolePolicy` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `GetPolicyToInspectServiceRolePolicy` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `ConsoleDisplayTables` – プリンシパルに、基盤となる AWS Glue テーブルに関するデータをコンソールに表示するために必要な AWS Glue メタデータへの読み取り専用アクセスを許可します。
+ `EstablishLogDeliveries` – 顧客の Amazon CloudWatch Logs ロググループにクエリログを提供することをプリンシパルに許可します。
+ `SetupLogGroupsDescribe` – Amazon CloudWatch Logs ロググループの作成プロセスを使用することをプリンシパルに許可します。
+ `SetupLogGroupsCreate` – プリンシパルに Amazon CloudWatch Logs ロググループの作成を許可します。
+ `SetupLogGroupsResourcePolicy` – Amazon CloudWatch Logs ロググループにリソースポリシーを設定することをプリンシパルに許可します。
+ `ConsoleLogSummaryQueryLogs` - プリンシパルにクエリログの閲覧を許可します。
+ `ConsoleLogSummaryObtainLogs` - プリンシパルにログ結果の取得を許可します。
+ `cleanrooms` – AWS Clean Rooms サービス内のコラボレーション、分析テンプレート、設定済みテーブル、メンバーシップ、および関連リソースを管理します。これらのリソースに関する情報の作成、更新、削除、一覧表示、取得など、さまざまな操作を実行します。
+ `iam` – `cleanrooms`「」を含む名前のサービスロールを AWS Clean Rooms サービスに渡します。ロール、ポリシーを一覧表示し、サービスに関連する AWS Clean Rooms サービスロールとポリシーを検査します。
+ `glue` – データベース、テーブル、パーティション、スキーマに関する情報を から取得します AWS Glue。これは、 AWS Clean Rooms サービスが基盤となるデータソースを表示して操作するために必要です。
+ `logs` – CloudWatch Logs のログ配信、ロググループ、およびリソースポリシーを管理します。 AWS Clean Rooms サービスに関連するログをクエリして取得します。これらのアクセス許可は、サービス内のモニタリング、監査、およびトラブルシューティングの目的で必要になります。
また、ポリシーは、`cleanrooms:StartProtectedQuery` および `cleanrooms:UpdateProtectedQuery` アクションを明示的に拒否し、ユーザーが保護されたクエリを直接実行または更新できないようにします。これは、 AWS Clean Rooms により制御されたメカニズムを介して実行する必要があります。
ポリシーの詳細の JSON リストについては、*AWS 「 マネージドポリシーリファレンスガイド*」の[AWSCleanRoomsFullAccessNoQuerying](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsFullAccessNoQuerying.html)」を参照してください。
## AWS 管理ポリシー: `AWSCleanRoomsMLReadOnlyAccess`
`AWSCleanRoomsMLReadOnlyAccess` をIAM プリンシパルにアタッチできます。
このポリシーは、`AWSCleanRoomsMLReadOnlyAccess` コラボレーションのリソースとメタデータへの読み取り専用のアクセス許可を付与します。
このポリシーには、以下のアクセス許可が含まれています。
+ `CleanRoomsConsoleNavigation` – AWS Clean Rooms コンソールの画面を表示するアクセス許可を付与します。
+ `CleanRoomsMLRead` – プリンシパルに Clean Rooms ML サービスへの読み取り専用アクセスを許可します。
+ `PassCleanRoomsResources` – 指定された AWS Clean Rooms リソースを渡すためのアクセス許可を付与します。
ポリシーの詳細の JSON リストについては、*AWS 「 マネージドポリシーリファレンスガイド*」の[AWSCleanRoomsMLReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsMLReadOnlyAccess.html)」を参照してください。
## AWS 管理ポリシー: `AWSCleanRoomsMLFullAccess`
`AWSCleanRoomsMLFullAcces` をIAM プリンシパルにアタッチできます。このポリシーは、Clean Rooms ML が必要とするリソースとメタデータへの完全なアクセス (読み取り、書き込み、および更新) を可能にする管理アクセス許可を付与します。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `CleanRoomsMLFullAccess` – すべての Clean Rooms ML アクションへのアクセスを許可します。
+ `PassServiceRole` - 名前に「cleanrooms-ml」が含まれるサービスのみにサービスロールを渡すためのアクセス許可 (`PassedToService` 条件) を付与します。
+ `CleanRoomsConsoleNavigation` – AWS Clean Rooms コンソールの画面を表示するアクセス許可を付与します。
+ `CollaborationMembershipCheck` – コラボレーション内でオーディエンス生成 (類似セグメント) ジョブを開始すると、Clean Rooms ML サービスは `ListMembers` を呼び出して、コラボレーションが有効であること、発信者がアクティブなメンバーであること、設定されたオーディエンスモデル所有者がアクティブなメンバーであることを確認します。このアクセス許可は常に必要です。コンソールナビゲーション SID はコンソールユーザーにのみ必要です。
+ `PassCleanRoomsResources` – 指定された AWS Clean Rooms リソースを渡すためのアクセス許可を付与します。
+ `AssociateModels` – Clean Rooms ML モデルをコラボレーションに関連付けることをプリンシパルに許可します。
+ `TagAssociations` – 類似モデルとコラボレーションの関連付けにタグを追加することをプリンシパルに許可します。
+ `ListRolesToPickServiceRole` – プリンシパルが使用時にサービスロールを選択できるように、すべてのロールを一覧表示できるようにします AWS Clean Rooms。
+ `GetRoleAndListRolePoliciesToInspectServiceRole` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `ListPoliciesToInspectServiceRolePolicy` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `GetPolicyToInspectServiceRolePolicy` - IAM のサービスロールと対応するポリシーを表示することをプリンシパルに許可します。
+ `ConsoleDisplayTables` – プリンシパルに、基盤となる AWS Glue テーブルに関するデータをコンソールに表示するために必要な AWS Glue メタデータへの読み取り専用アクセスを許可します。
+ `ConsolePickOutputBucket` – 設定済みのオーディエンスモデル出力用の Amazon S3 バケットを選択することをプリンシパルに許可します。
+ `ConsolePickS3Location` – 設定済みのオーディエンスモデル出力のバケット内の場所を選択することをプリンシパルに許可します。
+ `ConsoleDescribeECRRepositories` – プリンシパルが Amazon ECR リポジトリとイメージを記述できるようにします。
ポリシーの詳細の JSON リストについては、*AWS 「 マネージドポリシーリファレンスガイド*」の[AWSCleanRoomsMLFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCleanRoomsMLFullAccess.html)」を参照してください。
## AWS Clean Rooms AWS 管理ポリシーの更新
このサービスがこれらの変更の追跡を開始 AWS Clean Rooms してからの の AWS 管理ポリシーの更新に関する詳細を表示します。このページの変更に関する自動アラートについては、 AWS Clean Rooms ドキュメント履歴ページの RSS フィードにサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSCleanRoomsFullAccessNoQuerying](#security-iam-awsmanpol-fullaccess-noquery)– 既存のポリシーの更新 | クリーンルーム:UpdateConfiguredTableAllowedColumns とクリーンルーム:UpdateConfiguredTableReference を に追加しましたCleanRoomsAccess。 | 2025 年 7 月 29 日 |
| [AWSCleanRoomsMLReadOnlyAccess](#ml-read-only) – 既存のポリシーの更新 | PassCleanRoomsResources が AWSCleanRoomsMLReadOnlyAccess に追加されました。PassCleanRoomsResources および ConsoleDescribeECRRepositories が AWSCleanRoomsMLFullAccess に追加されました。 | 2025 年 1 月 10 日 |
| [AWSCleanRoomsFullAccessNoQuerying](#security-iam-awsmanpol-fullaccess-noquery) – 既存のポリシーの更新 | cleanrooms:BatchGetSchemaAnalysisRule が CleanRoomsAccess に追加されました。 | 2024 年 5 月 13 日 |
| [AWSCleanRoomsFullAccess](#security-iam-awsmanpol-fullaccess) – 既存のポリシーの更新 | このポリシーの AWSCleanRoomsFullAccess のステートメント ID を ConsolePickQueryResultsBucket から SetQueryResultsBucket に更新し、アクセス許可をより適切に表現しました。これは、コンソールの有無にかかわらず、クエリ結果バケットの設定にはアクセス許可が必要であるためです。 | 2024 年 3 月 21 日 |
| [AWSCleanRoomsMLReadOnlyAccess](#ml-read-only) - 新しいポリシー [AWSCleanRoomsMLFullAccess](#ml-full-access) - 新しいポリシー | AWS Clean Rooms ML をサポートするために AWSCleanRoomsMLReadOnlyAccessと を追加AWSCleanRoomsMLFullAccessしました。 | 2023 年 11 月 29 日 |
| [AWSCleanRoomsFullAccessNoQuerying](#security-iam-awsmanpol-fullaccess-noquery) – 既存のポリシーの更新 | cleanrooms:CreateAnalysisTemplate、cleanrooms:GetAnalysisTemplate、cleanrooms:UpdateAnalysisTemplate、 cleanrooms:DeleteAnalysisTemplate、cleanrooms:ListAnalysisTemplates、cleanrooms:GetCollaborationAnalysisTemplate、cleanrooms:BatchGetCollaborationAnalysisTemplate、および cleanrooms:ListCollaborationAnalysisTemplates が CleanRoomsAccess に追加され、新しい分析テンプレート機能が有効になりました。 | 2023 年 7 月 31 日 |
| [AWSCleanRoomsFullAccessNoQuerying](#security-iam-awsmanpol-fullaccess-noquery) – 既存のポリシーの更新 | cleanrooms:ListTagsForResource、cleanrooms:UntagResource、および cleanrooms:TagResource が CleanRoomsAccess に追加され、リソースのタグ付けが可能になりました。 | 2023 年 3 月 21 日 |
| AWS Clean Rooms が変更の追跡を開始しました | AWS Clean Rooms は、 AWS 管理ポリシーの変更の追跡を開始しました。 | 2023 年 1 月 12 日 |
# AWS Clean Rooms ID とアクセスのトラブルシューティング
次の情報は、 および IAM の使用時に発生する可能性がある一般的な問題の診断 AWS Clean Rooms と修復に役立ちます。
**Topics**
+ [でアクションを実行する権限がありません AWS Clean Rooms](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がありません](#security_iam_troubleshoot-passrole)
+ [自分の 以外のユーザーに自分の AWS Clean Rooms リソース AWS アカウント へのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
## でアクションを実行する権限がありません AWS Clean Rooms
アクションを実行する権限がないというエラーが表示された場合は、そのアクションを実行できるようにポリシーを更新する必要があります。
以下のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用して架空の `my-example-widget` リソースに関する詳細情報を表示しようとしているが、架空の `cleanrooms:GetWidget` 権限がないという場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: cleanrooms:GetWidget on resource: my-example-widget
```
この場合、Mateo のポリシーでは、`my-example-widget` アクションを使用して `cleanrooms:GetWidget` リソースにアクセスすることを許可するように更新する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン認証情報を提供した担当者が管理者です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して AWS Clean Roomsにロールを渡すことができるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、既存のロールをそのサービスに渡すことができます。そのためには、サービスにロールを渡す権限が必要です。
以下の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して AWS Clean Roomsでアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与された権限が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## 自分の 以外のユーザーに自分の AWS Clean Rooms リソース AWS アカウント へのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。
詳細については、以下を参照してください。
+ がこれらの機能 AWS Clean Rooms をサポートしているかどうかを確認するには、「」を参照してください[が IAM と AWS Clean Rooms 連携する方法](security_iam_service-with-iam.md)。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、[「IAM ユーザーガイド」の「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 **
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド*の[外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)を参照してください。
+ クロスアカウントアクセスでのロールとリソースベースのポリシーの使用の違いの詳細については、*IAM ユーザーガイド*の[IAM ロールとリソースベースのポリシーとの相違点](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)を参照してください。
# サービス間の混乱した代理の防止
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出し元サービスは、本来ならアクセスすることが許可されるべきではない方法でその許可を使用して、別のお客様のリソースに対する処理を実行するように操作される場合があります。これを防ぐため、 AWS では、アカウントのリソースへのアクセス権が付与されたサービスプリンシパルで、すべてのサービスのデータを保護するために役立つツールを提供しています。
リソースポリシーで [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) のグローバル条件コンテキストキーを使用して、 AWSClean Rooms が別のサービスに付与するアクセス許可をそのリソースに制限することをお勧めします。クロスサービスのアクセスにリソースを 1 つだけ関連付けたい場合は、`aws:SourceArn` を使用します。
混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して `aws:SourceArn` グローバル条件コンテキストキーを使用することです。では AWS Clean Rooms、 `sts:ExternalId`条件キーと比較する必要があります。
`aws:SourceArn` の値は、引き受けられたロールのメンバーシップの ARN に設定する必要があります。
次の例では、 AWSClean Rooms で `aws:SourceArn` グローバル条件コンテキストキーを使用して、混乱した代理問題を回避する方法を示します。
**注記**
サンプルポリシーは、 AWS Clean Rooms が設定済みテーブルのデータとメタデータにアクセスするために使用するサービスロールの信頼ポリシーに適用されます。
** の値は、クエリランナーのメンバーシップ ID に設定する必要があります。
コラボレーションのすべてのメンバーは、設定されたテーブルメタデータを表示できるため、各メンバーシップ ARN をメンバーシップ ARNsのリストに含める必要があります。
**注記**
AWS Clean Rooms コンソールを使用してサービスロールを作成すると、コラボレーションの現在のメンバーはすべて、デフォルトで混乱した代理条件に含まれます。
既にテーブルが関連付けられているコラボレーションに新しいメンバーを追加する場合は、サービスロールの混乱した代理条件を新しいメンバーのメンバーシップ ARN で更新してください。
新しいメンバーを追加した後にサービスロールの混乱した代理条件を更新しない場合、その新しいメンバー AWS Clean Rooms はそのロールを使用して取得された の情報にアクセスできなくなります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowIfExternalIdMatches",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"sts:ExternalId": "arn:aws:*:us-east-1:*:dbuser:*/*"
}
}
},
{
"Sid": "AllowIfSourceArnMatches",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ForAnyValue:ArnEquals": {
"aws:SourceArn": [
"arn:aws:cleanrooms:us-east-1:111122223333:membership/",
"arn:aws:cleanrooms:us-east-1:444455556666:membership/"
]
}
}
}
]
}
```
------
# 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 の名前は *\$1accountA-\$1name* です。 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 ](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/Welcome.html)を使用して、true `manageResourcePolicies`に設定された類似モデルを作成する場合、 はこのポリシー AWS Clean Rooms を作成します。
さらに、 AWS アカウント A の発信者の ID ポリシーには、 に対する `StartAudienceGenerationJob` アクセス許可が必要です`arn:aws:cleanrooms-ml:us-west-1:AccountA:audience-generation-job/*`。したがって、A ジョブ、 AWS アカウント B `StartAudienceGenerationJob` AWS アカウント ジョブ、 AWS アカウント B アクションの 3 つの IAM リソースがあります`ConfiguredAudienceModel`。
**警告**
ジョブ AWS アカウント を開始した は、ジョブに関する AWS CloudTrail 監査ログイベントを受け取ります。`ConfiguredAudienceModel` を所有する AWS CloudTrail は AWS アカウント 監査ログイベントを受信しません。
## ジョブのタグ付け
`CreateConfiguredAudienceModel` の `childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE` パラメータを設定すると、設定した類似モデルから作成されたアカウント内のすべての類似セグメント生成ジョブには、設定した類似モデルと同じタグがデフォルトで割り当てられます。設定した類似モデルが親で、類似セグメント生成ジョブが子です。
自身のアカウント内でジョブを作成する場合、ジョブのリクエストタグは親タグよりも優先されます。他のアカウントが作成したジョブが、自身のアカウントにタグを作成することはありません。`childResourceTagOnCreatePolicy=FROM_PARENT_RESOURCE` を設定し、別のアカウントでジョブを作成した場合、そのジョブのコピーは 2 つあります。アカウントのコピーには親リソースタグが付けられ、ジョブ送信者のアカウントのコピーにはリクエストのタグが付けられます。
## 共同作業者の検証
AWS Clean Rooms コラボレーションの他のメンバーにアクセス許可を付与する場合、リソースポリシーには条件キー を含める必要があります`cleanrooms-ml:CollaborationId`。これにより、[StartAudienceGenerationJob](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_StartAudienceGenerationJob.html) リクエストに `collaborationId` パラメータが含まれるように強制されます。`collaborationId` パラメータがリクエストに含まれると、Clean Rooms ML はコラボレーションが存在すること、ジョブの送信者がコラボレーションのアクティブメンバーであること、設定済みの類似モデルの所有者がコラボレーションのアクティブメンバーであることを検証します。
が設定された類似モデルリソースポリシー AWS Clean Rooms を管理する場合 ( `manageResourcePolicies`パラメータは [CreateConfiguredAudienceModelAssociation リクエスト](https://docs.aws.amazon.com/clean-rooms/latest/apireference/API_CreateConfiguredAudienceModelAssociation.html)`TRUE`にあります）、この条件キーはリソースポリシーで設定されます。そのため、[AudienceGenerationJob](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_StartAudienceGenerationJob.html) で `collaborationId` を指定する必要があります。
## クロスアカウントアクセス
アカウント間で呼び出せるのは `StartAudienceGenerationJob` のみです。その他の Clean Rooms ML API はすべて、自身のアカウントのリソースでのみ使用できます。これにより、トレーニングデータ、類似モデルの設定、その他の情報は非公開のままになります。
Clean Rooms ML は、アカウント間で Amazon S3 または AWS Glue ロケーションを公開しません。トレーニングデータの場所、設定済みの類似モデルの出力場所、および類似セグメント生成ジョブシードの場所は、どのアカウントでも表示されません。コラボレーションでクエリログ記録が有効になっていない限り、シードデータが SQL クエリから取得されるかどうかに関わらず、クエリ自体はアカウント間で表示されません。別のアカウントが送信したオーディエンス生成ジョブを `Get` した場合、サービスにはシードロケーションは表示されません。
# クリーンルーム ML カスタムモデルの IAM 動作
## クロスアカウントジョブ
Clean Rooms ML では、あるユーザーが作成したコラボレーションに関連付けられた特定のリソース AWS アカウント に、別のユーザーが自分のアカウントで安全にアクセスできます AWS アカウント。クエリを実行するメンバー権限を持つ AWS アカウント A のクライアント`ConfiguredModelAlgorithmAssociation`は`CreateTrainedModel`、 で作成されたカスタム分析ルールで が許可されている場合、コラボレーション内の別のメンバーが所有する`ConfiguredModelAlgorithmAssociation`リソース`StartTrainedModelInferenceJob`で `CreateMLInputChannel`、、または を呼び出すことができます`CreateConfiguredTableAnalysisRule`。
さらに、コラボレーションのアクティブなメンバーは、 `DeleteTrainedModelOutput`および `DeleteMLInputChannelData` APIs を介して、トレーニングされたモデルまたは ML 入力チャネルに関連付けられたデータを削除できます。
## クロスアカウントアクセス
Clean Rooms ML を使用すると、ユーザーは `GetCollaboration`および `ListCollaboration` APIs。Clean Rooms ML は、KMS キー ARNs、タグ、環境変数、またはハイパーパラメータ ( `TrainedModel`アクション用) を他のアカウントに公開しません。
## メンバーシップとコラボレーションへのアクセス
Clean Rooms ML カスタムモデルのコンテキストでメンバーシップおよびコラボレーションリソースにアクセスする場合、ユーザーの ID ポリシーにはアクション `cleanrooms:PassMembership`、`cleanrooms:PassCollaboration`、またはその両方に対するアクセス許可が必要です。を受け入れるすべての APIsには アクセス`cleanrooms:PassMembership`許可`membershipId`が必要で、 を受け入れるすべての APIsには アクセス`cleanrooms:PassCollaboration`許可`collaborationId`が必要です。コラボレーション ID のコンテキスト`createTrainedModel`で を呼び出すことができるメンバーシップ ID のコンテキスト`GetCollaborationTrainedModel`で を呼び出すことができるロールのサンプル ID ポリシーが提供されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCleanroomsMLActions",
"Effect": "Allow",
"Action": [
"cleanrooms:PassCollaboration",
"cleanrooms:PassMembership"
],
"Resource": [
"*"
]
},
{
"Sid": "AllowMembershipAccess",
"Effect": "Allow",
"Action": [
"cleanrooms:GetMembership"
],
"Resource": [
"arn:aws:cleanrooms:us-east-1:111122223333:membership/memberId"
]
},
{
"Sid": "AllowCollaborationAccess",
"Effect": "Allow",
"Action": [
"cleanrooms:GetCollaboration"
],
"Resource": [
"arn:aws:cleanrooms:us-east-1:111122223333:collaboration/collaborationId"
]
}
]
}
```
------