翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のセキュリティ AWS Clean Rooms
のクラウドセキュリティが最優先事項 AWS です。お客様は AWS 、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを活用できます。
セキュリティは、 AWS お客様とお客様の間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウドのセキュリティおよびクラウド内のセキュリティと説明しています。
+ **クラウドのセキュリティ** – AWS クラウドで AWS サービスを実行するインフラストラクチャを保護する AWS 責任があります。 AWS また、 では、安全に使用できるサービスも提供しています。サードパーティーの監査者は、[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)コンプライアンスプログラムの一環として、当社のセキュリティの有効性を定期的にテストおよび検証。が適用されるコンプライアンスプログラムの詳細については AWS Clean Rooms、「コンプライアンスプログラム[による AWS 対象範囲内のサービスコンプライアンスプログラム](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** – お客様の責任は、使用する AWS サービスによって決まります。また、お客様は、データの機密性、会社の要件、適用される法律や規制など、その他の要因についても責任を負います。
このドキュメントは、 を使用する際の責任共有モデルの適用方法を理解するのに役立ちます AWS Clean Rooms。セキュリティとコンプライアンスの目的を達成する AWS Clean Rooms ように を設定する方法を示します。また、 リソースのモニタリングや保護に役立つ他の AWS サービスの使用方法についても AWS Clean Rooms 説明します。
**Topics**
+ [データ保護](data-protection.md)
+ [サービスにリンクされたロールの使用](using-service-linked-roles.md)
+ [データ保持](data-retention.md)
+ [ベストプラクティス](best-practices.md)
+ [Identity and Access Management](security-iam.md)
+ [コンプライアンス検証](SERVICE-compliance.md)
+ [耐障害性](disaster-recovery-resiliency.md)
+ [インフラストラクチャセキュリティ](infrastructure-security.md)
+ [AWS PrivateLink](vpc-interface-endpoints.md)
# でのデータ保護 AWS Clean Rooms
責任 AWS [共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)、 でのデータ保護に適用されます AWS Clean Rooms。このモデルで説明されているように、 AWS はすべての を実行するグローバルインフラストラクチャを保護する責任があります AWS クラウド。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「 AWS のサービス 」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」のブログ記事を参照してください。
データ保護の目的で、認証情報を保護し AWS アカウント 、 AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーを設定することをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須ですが、TLS 1.3 を推奨します。
+ で API とユーザーアクティビティのログ記録を設定します AWS CloudTrail。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「 *AWS CloudTrail ユーザーガイド*」の[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS 暗号化ソリューションと、 内のすべてのデフォルトのセキュリティコントロールを使用します AWS のサービス。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API AWS を介して にアクセスするときに FIPS 140-3 検証済み暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール AWS Clean Rooms 、API、または SDK を使用して AWS CLIまたは他の AWS のサービス を操作する場合も同様です。 AWS SDKs タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
## 保管中の暗号化
AWS Clean Rooms は、追加の設定を必要とせずに、保管中のすべてのサービスメタデータを常に暗号化します。この暗号化は、 の使用時に自動的に行われます AWS Clean Rooms。
Clean Rooms ML は、保管中のサービスに保存されているすべてのデータを で暗号化します AWS KMS。独自の KMS キーを提供することを選択した場合、類似モデルと類似セグメント生成ジョブの内容は KMS キーで保存時に暗号化されます。
AWS Clean Rooms カスタム ML モデルを使用する場合、サービスは保管時に保存されているすべてのデータを で暗号化します AWS KMS。 は、ユーザーが作成、所有、管理する対称カスタマーマネージドキーを使用して、保管中のデータを暗号化すること AWS Clean Rooms をサポートします。カスタマーマネージドキーが指定されていない場合は、デフォルトで AWS 所有のキー が使用されます。
AWS Clean Rooms は、権限とキーポリシーを使用してカスタマーマネージドキーにアクセスします。グラントへのアクセスの取り消しや、カスタマーマネージドキーに対するサービスのアクセスの取り消しは、いつでもできます。その場合、カスタマーマネージドキーによって暗号化されたデータにはアクセス AWS Clean Rooms できず、そのデータに依存するオペレーションに影響します。たとえば、 AWS Clean Rooms がアクセスできない暗号化された ML 入力チャネルからトレーニング済みモデルを作成しようとすると、 オペレーションは`ValidationException`エラーを返します。
**注記**
Amazon S3 の暗号化オプションを使用して、保管中のデータを保護できます。
詳細については、「**Amazon S3 ユーザーガイド」の「[Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) の指定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/specifying-s3-encryption.html)」を参照してください。
内で ID マッピングテーブルを使用する場合 AWS Clean Rooms、サービスは保管時に保存されているすべてのデータを で暗号化します AWS KMS。独自の KMS キーを提供することを選択した場合、ID マッピングテーブルのコンテンツは保管時に を介して KMS キーで暗号化されます AWS Entity Resolution。ID マッピングワークフローで暗号化を使用するために必要なアクセス許可の詳細については、「*AWS Entity Resolution ユーザーガイド*」の「[AWS Entity Resolutionのワークフロージョブロールを作成する](https://docs.aws.amazon.com/entityresolution/latest/userguide/create-workflow-job-role.html)」を参照してください。
## 転送中の暗号化
AWS Clean Rooms は転送中の暗号化に Transport Layer Security (TLS) を使用します。との通信 AWS Clean Rooms は常に HTTPS 経由で行われるため、データは Amazon S3、Amazon Athena、Snowflake のいずれに保存されているかに関係なく、転送中に常に暗号化されます。これには、Clean Rooms ML を使用するときに転送中のすべてのデータが含まれます。
## 基になるデータの暗号化
基になるデータを暗号化する方法の詳細については、「[Cryptographic Computing for Clean Rooms](crypto-computing.md)」を参照してください。
## キーポリシー
キーポリシーは、カスタマーマネージドキーへのアクセスを制御します。すべてのカスタマーマネージドキーには、キーポリシーが 1 つだけ必要です。このポリシーには、そのキーを使用できるユーザーとその使用方法を決定するステートメントが含まれています。キーポリシーは、カスタマーマネージドキーの作成時に指定できます。詳細については、「 AWS Key Management Service デベロッパーガイド」の「カスタマーマネージドキーへのアクセスの管理」を参照してください。
AWS Clean Rooms カスタム ML モデルでカスタマーマネージドキーを使用するには、キーポリシーで次の API オペレーションを許可する必要があります。
+ `kms:DescribeKey` – がキー AWS Clean Rooms を検証できるように、カスタマーマネージドキーの詳細を提供します。
+ `kms:Decrypt` – 暗号化されたデータを復号し、関連するジョブで使用する AWS Clean Rooms ための へのアクセスを提供します。
+ `kms:CreateGrant` - Clean Rooms ML は、Amazon ECR の許可を作成することで、Amazon ECR の保管中のトレーニングイメージと推論イメージを暗号化します。詳細については、[「Amazon ECR での保管時の暗号化](https://docs.aws.amazon.com/AmazonECR/latest/userguide/encryption-at-rest.html)」を参照してください。Clean Rooms ML は、Amazon SageMaker AI を使用してトレーニングジョブと推論ジョブを実行し、SageMaker AI に許可を作成して、インスタンスにアタッチされた Amazon EBS ボリュームと Amazon S3 の出力データを暗号化します。詳細については、[Amazon SageMaker AI で暗号化を使用して保管中のデータを保護する](https://docs.aws.amazon.com/sagemaker/latest/dg/encryption-at-rest.html)」を参照してください。
+ `kms:GenerateDataKey` - Clean Rooms ML は、サーバー側の暗号化を使用して Amazon S3 に保存されている保管中のデータを暗号化します AWS KMS keys。詳細については、[「Amazon S3 での AWS KMS keys (SSE-KMS) によるサーバー側の暗号化の使用Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)」を参照してください。
以下は、次のリソースの AWS Clean Rooms に追加できるポリシーステートメントの例です。
**合成データを含む ML 入力チャネル**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow access to principals authorized to use AWS Clean Rooms ML",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::666666666666:role/ExampleRole"
},
"Action": [
"kms:GenerateDataKey",
"kms:CreateGrant",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com"
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt",
"Encrypt",
"GenerateDataKeyWithoutPlaintext",
"ReEncryptFrom",
"ReEncryptTo",
"CreateGrant",
"DescribeKey",
"RetireGrant",
"GenerateDataKey"
]
},
"BoolIfExists": {
"kms:GrantIsForAWSResource": true
}
}
},
{
"Sid": "Allow describe key for principals authorized to use AWS Clean Rooms ML",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/ExampleRole"
},
"Action": [
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com"
}
}
},
{
"Sid": "Allow grant operations for AWS Clean Rooms ML service principal",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms-ml.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:CreateGrant",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt",
"Encrypt",
"GenerateDataKeyWithoutPlaintext",
"ReEncryptFrom",
"ReEncryptTo",
"CreateGrant",
"DescribeKey",
"RetireGrant",
"GenerateDataKey"
]
}
}
},
{
"Sid": "Allow describe key for AWS Clean Rooms ML service principal",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms-ml.amazonaws.com"
},
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**合成データのない ML 入力チャネル**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow access to principals authorized to use AWS Clean Rooms ML",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::666666666666:role/ExampleRole"
},
"Action": [
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com"
}
}
},
{
"Sid": "Allow access to AWS Clean Rooms ML service principal",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms-ml.amazonaws.com"
},
"Action": [
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```
------
**トレーニング済みモデルジョブまたはトレーニング済みモデル推論ジョブ**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow grant operations for principals authorized to use AWS Clean Rooms ML",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::666666666666:role/ExampleRole"
},
"Action": [
"kms:GenerateDataKey",
"kms:CreateGrant",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com"
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt",
"Encrypt",
"GenerateDataKeyWithoutPlaintext",
"ReEncryptFrom",
"ReEncryptTo",
"CreateGrant",
"DescribeKey",
"RetireGrant",
"GenerateDataKey"
]
},
"BoolIfExists": {
"kms:GrantIsForAWSResource": true
}
}
},
{
"Sid": "Allow describe key for principals authorized to use AWS Clean Rooms ML",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/ExampleRole"
},
"Action": [
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "cleanrooms-ml.us-east-1.amazonaws.com"
}
}
},
{
"Sid": "Allow grant operations for AWS Clean Rooms ML service principal",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms-ml.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:CreateGrant",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt",
"Encrypt",
"GenerateDataKeyWithoutPlaintext",
"ReEncryptFrom",
"ReEncryptTo",
"CreateGrant",
"DescribeKey",
"RetireGrant",
"GenerateDataKey"
]
}
}
},
{
"Sid": "Allow describe key for AWS Clean Rooms ML service principal",
"Effect": "Allow",
"Principal": {
"Service": "cleanrooms-ml.amazonaws.com"
},
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
------
Clean Rooms ML は、カスタマーマネージドキーポリシーでのサービス暗号化コンテキストまたはソースコンテキストの指定をサポートしていません。サービスによって内部的に使用される暗号化コンテキストは、CloudTrail の顧客に表示されます。
# のサービスにリンクされたロールの使用 AWS Clean Rooms
AWS Clean Rooms は AWS Identity and Access Management (IAM) [サービスにリンクされたロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)を使用します。サービスにリンクされたロールは、直接リンクされた一意のタイプの IAM ロールです AWS Clean Rooms。サービスにリンクされたロールは によって事前定義 AWS Clean Rooms されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。
サービスにリンクされたロールを使用すると、必要なアクセス許可を手動で追加する必要がなくなるため、 の設定 AWS Clean Rooms が簡単になります。 は、サービスにリンクされたロールのアクセス許可 AWS Clean Rooms を定義し、特に定義されている場合を除き、 のみがそのロールを引き受け AWS Clean Rooms ることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、最初に関連リソースを削除する必要があります。これにより、 AWS Clean Rooms リソースへのアクセス許可が誤って削除されないため、リソースが保護されます。
サービスにリンクされたロールをサポートする他のサービスの詳細については、[AWS 「IAM と連携するサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、「サービス**にリンクされたロール**」列で**「はい**」を持つサービスを探します。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。
## のサービスにリンクされたロールのアクセス許可 AWS Clean Rooms
AWS Clean Rooms は、**AWSServiceRoleForAWSCleanRooms** という名前のサービスにリンクされたロールを使用して、Clean Rooms 関連の CloudWatch メトリクスを AWS アカウントに発行します。
AWSServiceRoleForAWSCleanRooms サービスにリンクされたロールは、次のサービスを信頼してロールを引き受けます。
+ `cleanrooms.amazonaws.com`
AWSCleanRoomsServiceRolePolicy という名前のロールアクセス許可ポリシーにより AWS Clean Rooms 、 は指定されたリソースに対して次のアクションを実行できます。
+ アクション: `cloudwatch:PutMetricData`。対象リソース: `all AWS resources, restricted to the AWS Clean Rooms namespace`
ユーザー、グループ、またはロールにサービスリンクロールの作成、編集、または削除を許可するには、アクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## のサービスにリンクされたロールの作成 AWS Clean Rooms
IAM コンソールを使用して、**AWSServiceRoleForAWSCleanRooms** ユースケースでサービスにリンクされたロールを作成できます。 AWS CLI または AWS API で、サービス名を使用して`cleanrooms.amazonaws.com`サービスにリンクされたロールを作成します。詳細については、*IAM ユーザーガイド*の「[サービスリンクロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)」を参照してください。このサービスリンクロールを削除しても、同じ方法でロールを再作成できます。
## のサービスにリンクされたロールの編集 AWS Clean Rooms
AWS Clean Rooms では、AWSServiceRoleForAWSCleanRooms サービスにリンクされたロールを編集することはできません。サービスリンクロールの作成後は、さまざまなエンティティがロールを参照する可能性があるため、ロール名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については、「*IAM ユーザーガイド*」の「[サービスリンクロールの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## のサービスにリンクされたロールの削除 AWS Clean Rooms
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することをお勧めします。そうすることで、積極的にモニタリングまたは保守されていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンクロールのリソースをクリーンアップする必要があります。
**AWSServiceRoleForAWSCleanRooms** を削除するには、まず [のすべてのコラボレーション](https://docs.aws.amazon.com/clean-rooms/latest/userguide/delete-collaboration.html)と[メンバーシップ](https://docs.aws.amazon.com/clean-rooms/latest/userguide/leave-collab.html)を削除する必要があります AWS アカウント。
**注記**
リソースを削除しようとしたときに AWS Clean Rooms サービスがロールを使用している場合は、削除が失敗する可能性があります。その場合は、数分待ってからオペレーションを再試行してください。
**IAM を使用してサービスリンクロールを手動で削除するには**
IAM コンソール、 AWS CLI、または AWS API を使用して、AWSServiceRoleForAWSCleanRooms サービスにリンクされたロールを削除します。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## AWS Clean Rooms サービスにリンクされたロールでサポートされているリージョン
AWS Clean Rooms は、サービスが利用可能なすべてのリージョンでサービスにリンクされたロールの使用をサポートしています。詳細については、「[AWS リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/clean-rooms.html#clean-rooms_region)」を参照してください。
# のデータ保持 AWS Clean Rooms
一時的に AWS Clean Rooms コラボレーションに読み込まれたデータは、クエリの完了後に削除されます。
類似モデルを作成すると、Clean Rooms ML はトレーニングデータを読み取り、ML モデルに適した形式に変換し、トレーニング済みのモデルパラメータを Clean Rooms ML 内に保存します。Clean Rooms ML はトレーニングデータのコピーを保持しません。 AWS Clean Rooms SQL クエリは、クエリの実行後にデータを保持しません。次に、Clean Rooms ML はトレーニング済みのモデルを使用して全ユーザーの行動を要約します。Clean Rooms ML は、類似モデルがアクティブである限り、各ユーザーのユーザーレベルのデータセットをデータに保存します。
類似セグメント生成ジョブを開始すると、Clean Rooms ML はシードデータを読み取り、関連する類似モデルから動作概要を読み取り、 AWS Clean Rooms サービス内に保存される類似セグメントを作成します。Clean Rooms ML はシードデータのコピーを保持しません。Clean Rooms ML は、ジョブがアクティブである限り、ジョブのユーザーレベルの出力を保存します。
シードデータが SQL クエリから取得された場合、そのクエリの出力はジョブの期間中のみサービスに保存されます。クエリの結果は、保管中および転送中に暗号化されます。
類似モデルまたは類似セグメント生成ジョブデータを削除する場合は、API を使用して削除します。Clean Rooms ML は、モデルまたはジョブに関連するすべてのデータを非同期的に削除します。このプロセスが完了すると、Clean Rooms ML はモデルまたはジョブのメタデータを削除し、API には表示されなくなります。Clean Rooms ML は、ディザスタリカバリ対策のため、削除されたデータを 3 日間保持します。ジョブまたはモデルが API に表示されなくなり、3 日が経過すると、モデルまたはジョブに関連するすべてのデータが完全に削除されます。
# でのデータコラボレーションのベストプラクティス AWS Clean Rooms
このトピックでは、 AWS Clean Roomsでデータコラボレーションを行うときのベストプラクティスについて説明します。
AWS Clean Rooms は、コラボレーションで機密データを保護する機能を強化するために設定できる [AWS 責任共有 Model](https://aws.amazon.com/compliance/shared-responsibility-model/). AWS Clean Rooms offers [分析ルール](analysis-rules.md)に従います。で設定した分析ルール AWS Clean Rooms は、設定した制限 (クエリコントロールとクエリ出力コントロール) を適用します。制限の決定とそれに応じた分析ルールの設定はユーザーの責任となります。
データコラボレーションには、単に を使用する以上のものが含まれる場合があります AWS Clean Rooms。データコラボレーションの利点を最大化するために、 を使用し、 AWS Clean Rooms 特に分析ルールを使用して、次のベストプラクティスを実行することをお勧めします。
**Topics**
+ [を使用したベストプラクティス AWS Clean Rooms](#best-practices-with-clean-rooms)
+ [で分析ルールを使用するためのベストプラクティス AWS Clean Rooms](#best-practices-for-analysis-rules)
## を使用したベストプラクティス AWS Clean Rooms
各データコラボレーションのリスクを評価し、それを外部および内部のコンプライアンスプログラムやポリシーなどのプライバシー要件と比較する責任はユーザーにあります。を使用する場合は、追加のアクションを実行することをお勧めします AWS Clean Rooms。これらの措置によって、リスクをさらに管理し、第三者がデータを再特定しようとする試み (差分攻撃やサイドチャネル攻撃など) を防止できる場合があります。
例えば、コラボレーションを開始する前に、相手のコラボレーターに対してデューデリジェンスを実施し、法的契約を結ぶことを検討してください。**自社データの使用状況を監視するために、 AWS Clean Roomsの使用に際して他の監査メカニズムを採用することも検討してください。
## で分析ルールを使用するためのベストプラクティス AWS Clean Rooms
の分析ルール AWS Clean Rooms では、設定されたテーブルにクエリコントロールを設定することで、実行できるクエリを制限できます。例えば、設定済みテーブルを結合する方法や、選択できる列に関するクエリコントロールを設定できます。また、出力行の集約しきい値などのクエリ結果コントロールを設定して、クエリ出力を制限することもできます。クエリに含まれる設定済みテーブルでメンバーが設定した分析ルールを満たしていない行については、クエリが一切拒否され、結果から除外されます。
設定済みテーブルで分析ルールを使用する際には、次の 10 のベストプラクティスに従うことをお勧めします**。
+ クエリのユースケース (オーディエンスプランニングやアトリビューションなど) ごとに、個別の設定済みテーブルを作成します。同じ AWS Glue テーブルを基に、複数の設定済みテーブルを作成できます。
+ コラボレーションでのクエリに必要な列 (ディメンション列、リスト列、結合列など) を分析ルールに指定します。これにより、差分攻撃や、他のメンバーによってデータのリバースエンジニアリングが行われるリスクを軽減できる可能性があります。**許可リスト列**の機能を使用して、今後クエリを実行できるようにしたい他の列を記録しておきます。特定のコラボレーションに使用できる列をカスタマイズするには、同じ基盤となるテーブルを持つ追加の設定済み AWS Glue テーブルを作成します。
+ コラボレーションでの分析に必要な関数を分析ルールに指定します。これにより、個々のデータポイントの情報が提示されるまれな関数エラーによるリスクを軽減できます。特定のコラボレーションに使用できる関数をカスタマイズするには、基になる同じ AWS Glue テーブルを使用して追加の設定済みテーブルを作成します。
+ 行レベルの値が機密であるすべての列に集約制約を追加します。これには、設定済みテーブル内の列のうち、コラボレーションの他のメンバーのテーブル、および集約制約として分析ルールにも存在する列が含まれます。また、設定済みテーブル内のクエリを実行できない列、つまり、設定済みテーブルには存在するが分析ルールには存在しない列も含まれます。集約制約により、クエリ結果がコラボレーション外部のデータに関連付けられるリスクを軽減できます。
+ テスト用のコラボレーションと分析ルールを作成して、指定された分析ルールで作成した制限をテストします。
+ コラボレーターが設定したテーブルと、設定済みテーブルにあるメンバーの分析ルールを確認して、コラボレーションに際して合意された内容と一致していることを確認します。これにより、他のメンバーが独自のデータを設計して、合意されていないクエリを実行するリスクを軽減できます。
+ 分析ルールの設定後に、設定済みテーブルで有効になっている、提示されているクエリの例 (コンソールのみ) を確認します。
**注記**
提示されているクエリの例以外に、分析ルールや、他のコラボレーションメンバーのテーブルと分析ルールに基づいて、その他のクエリも利用できます。
+ コラボレーションの設定済みテーブルの分析ルールは、追加または更新が可能です。追加や更新を行う際は、設定済みテーブルが関連付けられているすべてのコラボレーションと、その結果生じる影響を確認してください。これにより、すべてのコラボレーションで古い分析ルールが使用されることを回避できます。
+ コラボレーションで実行されるクエリを確認して、そのクエリがコラボレーションに際して合意されたユースケースまたはクエリと一致していることを確認します (**[クエリログ記録]** 機能がオンになっている場合は、クエリがクエリログに表示されます)。これにより、合意されていない分析をメンバーが実行するリスクや、サイドチャネル攻撃などの潜在的な攻撃のリスクを軽減できます。
+ コラボレーションメンバーの分析ルールやクエリで使用される設定済みテーブルの列を確認して、コラボレーションに際して合意された内容と一致していることを確認します (クエリのログ記録機能がオンになっている場合は、クエリがクエリログに表示されます)。これにより、他のメンバーが独自のデータを設計して、合意されていないクエリを実行するリスクを軽減できます。
# の 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"
]
}
]
}
```
------
# のコンプライアンス検証 AWS Clean Rooms
AWS のサービス が特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「コンプライアンス[AWS のサービス プログラムによる対象範囲内](https://aws.amazon.com/compliance/services-in-scope/)」の「コンプライアンス」を参照し、関心のあるコンプライアンスプログラムを選択します。一般的な情報については、[AWS 「コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
を使用して、サードパーティーの監査レポートをダウンロードできます AWS Artifact。詳細については、[「Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
を使用する際のお客様のコンプライアンス責任 AWS のサービス は、お客様のデータの機密性、貴社のコンプライアンス目的、適用される法律および規制によって決まります。を使用する際のコンプライアンス責任の詳細については AWS のサービス、[AWS 「 セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
# の耐障害性 AWS Clean Rooms
AWS グローバルインフラストラクチャは、 AWS リージョンとアベイラビリティーゾーンを中心に構築されています。リージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立および隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、フォールトトレランス、および拡張性が優れています。
AWS リージョンとアベイラビリティーゾーンの詳細については、[AWS 「 グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
# のインフラストラクチャセキュリティ AWS Clean Rooms
マネージドサービスである AWS Clean Rooms は、 AWS グローバルネットワークセキュリティで保護されています。 AWS セキュリティサービスと がインフラストラクチャ AWS を保護する方法については、[AWS 「 クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して環境を AWS 設計するには、*「Security Pillar AWS Well‐Architected Framework*」の[「Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS が発行した API コールを使用して、ネットワーク AWS Clean Rooms 経由で にアクセスします。クライアントは次をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
## ネットワークセキュリティ
クエリの実行中に が S3 バケットから AWS Clean Rooms 読み取ると、 と Amazon S3 間の AWS Clean Rooms トラフィックは AWS プライベートネットワークを介して安全にルーティングされます。処理中のトラフィックは Amazon Signature Version 4 プロトコル (SIGv4) を使用して署名され、HTTPS を使用して暗号化されます。このトラフィックは、設定済みテーブルに設定した IAM サービスロールに基づいて承認されます。
エンドポイント AWS Clean Rooms を介してプログラムで に接続できます。サービスエンドポイントのリストについては、「**AWS 全般のリファレンス」の「[AWS Clean Rooms のエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/clean-rooms.html#clean-rooms_region)」を参照してください。
すべてのサービスエンドポイントは HTTPS 限定です。VPC AWS Clean Rooms から に接続し、インターネット接続を希望しない場合は、Amazon Virtual Private Cloud (VPC) エンドポイントを使用できます。詳細については、「 *AWS PrivateLink ガイド*」の「 [を通じて AWS サービスにアクセスする AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)」を参照してください。
[aws:SourceVpce コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpce)を使用する IAM プリンシパルに IAM ポリシーを割り当てて、インターネットではなく VPC エンドポイント AWS Clean Rooms を介してのみ を呼び出すことができるように IAM プリンシパルを制限できます。
# インターフェイスエンドポイント (AWS PrivateLink) AWS Clean Rooms を使用して AWS Clean Rooms または ML にアクセスする
AWS PrivateLink を使用して、仮想プライベートクラウド (VPC) と AWS Clean Rooms または ML AWS Clean Rooms の間にプライベート接続を作成できます。インターネットゲートウェイ、NAT デバイス、VPN 接続、 AWS Clean Rooms または Direct Connect 接続を使用せずに、VPC 内にあるかのように または AWS Clean Rooms ML にアクセスできます。VPC 内のインスタンスは AWS Clean Roomsにアクセスするためにパブリック IP アドレスを必要としません。
このプライベート接続を確立するには、 AWS PrivateLinkを利用した*インターフェイスエンドポイント*を作成します。インターフェイスエンドポイントに対して有効にする各サブネットにエンドポイントネットワークインターフェイスを作成します。これらは、 AWS Clean Rooms宛てのトラフィックのエントリポイントとして機能するリクエスタ管理型ネットワークインターフェイスです。
詳細については「*AWS PrivateLink ガイド*」の「[Access AWS のサービス through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)」を参照してください。
## に関する考慮事項 AWS Clean Rooms
のインターフェイスエンドポイントを設定する前に AWS Clean Rooms、「 *AWS PrivateLink ガイド*」の[「考慮事項](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)」を参照してください。
AWS Clean Rooms および AWS Clean Rooms ML は、インターフェイスエンドポイントを介したすべての API アクションの呼び出しをサポートしています。
VPC エンドポイントポリシーは、 AWS Clean Rooms または ML AWS Clean Rooms ではサポートされていません。デフォルトでは、インターフェイスエンドポイントを介して AWS Clean Rooms および AWS Clean Rooms ML へのフルアクセスが許可されます。または、セキュリティグループをエンドポイントネットワークインターフェイスに関連付けて、インターフェイスエンドポイントを介して AWS Clean Rooms または AWS Clean Rooms ML へのトラフィックを制御することもできます。
## のインターフェイスエンドポイントを作成する AWS Clean Rooms
Amazon VPC コンソール AWS Clean Rooms または AWS Command Line Interface () を使用して、 または AWS Clean Rooms ML のインターフェイスエンドポイントを作成できますAWS CLI。詳細については、「*AWS PrivateLink ガイド*」の「[インターフェイスエンドポイントを作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。
次のサービス名 AWS Clean Rooms を使用して のインターフェイスエンドポイントを作成します。
```
com.amazonaws.region.cleanrooms
```
次のサービス名を使用して、ML AWS Clean Rooms のインターフェイスエンドポイントを作成します。
```
com.amazonaws.region.cleanrooms-ml
```
インターフェイスエンドポイントのプライベート DNS を有効にすると、リージョンのデフォルト DNS 名を使用して、 AWS Clean Rooms への API リクエストを実行できます。例えば、`cleanrooms-ml.us-east-1.amazonaws.com`。