翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EMR Serverless での Identity and Access Management (IAM)
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を*認証* (サインイン) し、誰に Amazon EMR Serverless リソースの使用を*承認する* (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで使用できる AWS のサービス です。
**Topics**
+ [オーディエンス](#security_iam_audience)
+ [アイデンティティを使用した認証](#security_iam_authentication)
+ [ポリシーを使用したアクセスの管理](#security_iam_access-manage)
+ [EMR Serverless が IAM と連携する仕組み](security-iam-serverless.md)
+ [EMR Serverless のサービスリンクロールの使用](using-service-linked-roles.md)
+ [Amazon EMR Serverless のジョブランタイムロール](security-iam-runtime-role.md)
+ [EMR Serverless のユーザーアクセスポリシーの例](security-iam-user-access-policies.md)
+ [タグベースのアクセスコントロールのポリシー](security-iam-TBAC.md)
+ [EMR Serverless でのアイデンティティベースのポリシー例](security-iam-id-based-policy-examples.md)
+ [AWS マネージドポリシーに対する Amazon EMR Serverless の更新](#security-iam-awsmanpol-updates)
+ [Amazon EMR Serverless の ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[Amazon EMR Serverless の ID とアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[Amazon EMR Serverless での Identity and Access Management (IAM)](#security_iam_service-with-iam)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[EMR Serverless でのアイデンティティベースのポリシーの例](security-iam-serverless.md#security_iam_id-based-policy-examples)」を参照)
## アイデンティティを使用した認証
認証とは、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。
AWS IAM アイデンティティセンター (IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント ルートユーザー
を作成するときは AWS アカウント、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *root ユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。
*フェデレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID ソースからの認証情報 AWS のサービス を使用して Directory Service にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、 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 を評価します。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプによって付与されるアクセス許可の最大数を設定できる追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.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)」を参照してください。
# EMR Serverless が IAM と連携する仕組み
IAM を使用して Amazon EMR Serverless へのアクセスを管理する前に、Amazon EMR Serverless で使用できる IAM 機能について理解しておく必要があります。
**EMR Serverless で使用する IAM の機能**
| IAM 機能 | Amazon EMR Serverless のサポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#security-iam-resource-based-policies) | なし |
| [ポリシーアクション](#security-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#security-iam-id-based-policies-resources) | あり |
| [ポリシー条件キー](#security-iam-id-based-policies-conditionkeys) | いいえ |
| [ACL](#security-iam-acls) | なし |
| [ABAC (ポリシー内のタグ)](#security-iam-tags) | あり |
| [一時的な認証情報](#security-iam-roles-tempcreds) | あり |
| [プリンシパルアクセス権限](#security-iam-principal-permissions) | あり |
| [サービスロール](#security-iam-roles-service) | いいえ |
| [サービスリンクロール](#security-iam-roles-service-linked) | はい |
EMR Serverless およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要を把握するには、「IAM *ユーザーガイド*」の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## EMR Serverless でのアイデンティティベースのポリシー
**アイデンティティベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、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)」を参照してください。
### EMR Serverless でのアイデンティティベースのポリシーの例
Amazon EMR Serverless のアイデンティティベースポリシーの例にアクセスするには、「[EMR Serverless でのアイデンティティベースのポリシー例](security-iam-id-based-policy-examples.md)」を参照してください。
## EMR Serverless 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** なし
リソースベースのポリシーは、リソースに添付する 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)を参照してください。
## EMR Serverless のポリシーアクション
**ポリシーアクションのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
EMR Serverless アクションのリストについては、「*Service Authorization Reference*」の「[Actions, resources, and condition keys for Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html)」を参照してください。
EMR Serverless のポリシーアクションでは、アクションの前に次のプレフィックスを使用します。
```
emr-serverless
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"emr-serverless:action1",
"emr-serverless:action2"
]
```
Amazon EMR Serverless のアイデンティティベースポリシーの例にアクセスするには、「[EMR Serverless でのアイデンティティベースのポリシー例](security-iam-id-based-policy-examples.md)」を参照してください。
## EMR Serverless のポリシーリソース
**ポリシーリソースのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Amazon EMR Serverless リソースのタイプとその ARN のリストについては、「*サービス認可リファレンス*」の「[Resources Defined by Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html#amazonelasticmapreduce-resources-for-iam-policies)」を参照してください。各リソースの ARN を指定するアクションについては、「[Actions, resources, and condition keys for Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html)」を参照してください。
Amazon EMR Serverless のアイデンティティベースポリシーの例にアクセスするには、「[EMR Serverless でのアイデンティティベースのポリシー例](security-iam-id-based-policy-examples.md)」を参照してください。
## EMR Serverless のポリシー条件キー
**ポリシー条件キーのサポート**
| | |
| --- |--- |
| サービス固有のポリシー条件キーのサポート | いいえ |
管理者は 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)」を参照してください。
Amazon EMR Serverless の条件キーのリスト、および条件キーを使用できるアクションとリソースについては、「*サービス認可リファレンス*」の「[Actions, resources, and condition keys for Amazon EMR Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonemrserverless.html)」を参照してください。
すべての Amazon EC2 アクションは `aws:RequestedRegion` および `ec2:Region` 条件キーをサポートします。詳細については、「[Example: Restricting access to a specific region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)」を参照してください。
## EMR Serverless のアクセスコントロールリスト (ACL)
**ACL のサポート:** なし
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## EMR Serverless での属性ベースのアクセスコントロール (ABAC)
**属性ベースのアクセス制御 (ABAC) のサポート**
| | |
| --- |--- |
| 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)」を参照してください。
## EMR Serverless での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり
一時的な認証情報は、 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)」を参照してください。
## EMR Serverless のクロスサービスプリンシパルのアクセス許可
**転送アクセスセッション (FAS) のサポート:** あり
転送アクセスセッション (FAS) は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストをリクエストする を使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## EMR Serverless のサービスロール
| | |
| --- |--- |
| サービスロールのサポート | いいえ |
## EMR Serverless のサービスにリンクされたロール
| | |
| --- |--- |
| サービスリンクロールのサポート | Yes |
サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携するAWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスにアクセスするには、**[はい]** リンクを選択します。
# EMR Serverless のサービスリンクロールの使用
Amazon EMR Serverless は 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)を使用します。サービスリンクロールは、EMR Serverless に直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは EMR Serverless によって事前定義されており、サービスがユーザーに代わって他の AWS サービスを呼び出すために必要なすべてのアクセス許可が含まれています。
サービスリンクロールを使用すると、必要なアクセス権限を手動で追加する必要がなくなるため、EMR Serverless の設定が簡単になります。EMR Serverless は、サービスリンクロールのアクセス権限を定義します。特に定義されている場合を除き、EMR Serverless のみがそのロールを引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンクロールを削除するには、最初に関連リソースを削除する必要があります。これにより、不注意でリソースにアクセスするアクセス許可の削除が防止され、EMR Serverless リソースは保護されます。
サービスにリンクされたロールをサポートする他のサービスについては、「[IAM と連動するAWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、**[サービスにリンクされたロール]** の列内で **[はい]** と表記されたサービスを確認してください。サービスリンクロールに関するドキュメントをサービスにアクセスするには、リンクで **[はい]** を選択します。
## EMR Serverless のサービスリンクロールのアクセス許可
EMR Serverless は、**AWSServiceRoleForAmazonEMRServerless** という名前のサービスにリンクされたロールを使用して、ユーザーに代わって AWS APIsを呼び出すことを可能にします。
AWSServiceRoleForAmazonEMRServerless サービスリンクロールは、次のサービスを信頼してロールを引き受けます。
+ `ops.emr-serverless.amazonaws.com`
`AmazonEMRServerlessServiceRolePolicy` という名前のロール許可ポリシーによって、EMR Serverless が次のアクションを指定されたリソースで完了できるようになります。
**注記**
マネージドポリシーの内容は変わるため、ここに示すポリシーは古くなっている可能性があります。 AWS マネジメントコンソールで、最新のポリシー [AmazonEMRServerlessServiceRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonEMRServerlessServiceRolePolicy) を確認してください。
+ アクション: `ec2:CreateNetworkInterface`
+ アクション: `ec2:DeleteNetworkInterface`
+ アクション: `ec2:DescribeNetworkInterfaces`
+ アクション: `ec2:DescribeSecurityGroups`
+ アクション: `ec2:DescribeSubnets`
+ アクション: `ec2:DescribeVpcs`
+ アクション: `ec2:DescribeDhcpOptions`
+ アクション: `ec2:DescribeRouteTables`
+ アクション: `cloudwatch:PutMetricData`
以下は `AmazonEMRServerlessServiceRolePolicy` ポリシー全体です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2PolicyStatement",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeRouteTables"
],
"Resource": [
"*"
]
},
{
"Sid": "CloudWatchPolicyStatement",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"cloudwatch:namespace": [
"AWS/EMRServerless",
"AWS/Usage"
]
}
}
}
]
}
```
------
EMR Serverless プリンシパルがこのロールを引き受けることを許可するには、このロールに以下の信頼ポリシーをアタッチします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/aws-service-role/emr-serverless.amazonaws.com/AWSServiceRoleForEMRServerless",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## EMR Serverless のサービスリンクロールの作成
サービスリンクロールを手動で作成する必要はありません。(EMR Studio AWS マネジメントコンソール を使用して) AWS CLI、、または API で新しい EMR Serverless アプリケーションを作成すると AWS 、EMR Serverless によってサービスにリンクされたロールが作成されます。サービスリンクロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。
**IAM を使用して AWSServiceRoleForAmazonEMRServerless サービスリンクロールを作成するには**
サービスリンクロールを作成する必要のある IAM エンティティのアクセス権限ポリシーに、次のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*",
"Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}}
}
```
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成します。新しい EMR Serverless アプリケーションを作成すると、EMR Serverless はサービスリンクロールを再度作成します。
**EMR Serverless** のユースケースでサービスリンクロールを作成する場合も、IAM コンソールを使用できます。 AWS CLI または AWS API で、サービス名を使用して`ops.emr-serverless.amazonaws.com`サービスにリンクされたロールを作成します。詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)」を参照してください。このサービスリンクロールを削除しても、同じ方法でロールを再作成できます。
## EMR Serverless のサービスリンクロールの編集
EMR Serverless では、AWSServiceRoleForAmazonEMRServerless サービスリンクロールを編集できません。さまざまなエンティティがロールを参照している可能性があるためです。EMR Serverless サービスにリンクされたロールが使用する AWS所有の IAM ポリシーは、EMR Serverless に必要なすべてのアクセス許可が含まれているため、編集できません。ただし、IAM を使用してロールの説明を編集することはできます。
**AWSServiceRoleForAmazonEMRServerless サービスリンクロールの説明を IAM を使用して編集するには**
サービスにリンクされたロールの説明を編集する必要のある IAM エンティティの許可ポリシーに次のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": [
"iam: UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*",
"Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}}
}
```
詳細については「*IAM ユーザーガイド*」の「[Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## EMR Serverless のサービスリンクロールの削除
サービスリンクロールを必要とする機能やサービスが不要になった場合は、ロールを削除することを提案します。これは、モニタリングや保守が積極的に行われていない未使用のエンティティを排除するためです。ただし、サービスリンクロールを削除する前に、すべてのリージョンのすべての EMR Serverless アプリケーションを削除します。
**注記**
ロールに関連するリソースを削除しようとする際に、EMR Serverless のサービスでロールが使用されていると、削除に失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
**IAM を使用して AWSServiceRoleForAmazonEMRServerless サービスリンクロールを削除するには**
サービスリンクロールを削除する必要のある IAM エンティティのアクセス権限ポリシーに、次のステートメントを追加します。
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless*",
"Condition": {"StringLike": {"iam:AWSServiceName": "ops.emr-serverless.amazonaws.com"}}
}
```
**サービスリンクロールを IAM で手動削除するには**
IAM コンソール、 AWS CLI、または AWS API を使用して、AWSServiceRoleForAmazonEMRServerless サービスにリンクされたロールを削除します。詳細については、「*IAM ユーザーガイド*」の「[Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## EMR Serverless のサービスリンクロールをサポートするリージョン
EMR Serverless は、このサービスが利用可できるすべてのリージョンで、サービスリンクロールの使用をサポートします。詳細については、[「AWS サービスエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。
# Amazon EMR Serverless のジョブランタイムロール
EMR Serverless ジョブの実行がユーザーに代わって他のサービスを呼び出す際に引き受けることができる、IAM ロールのアクセス許可を指定できます。これには、データソース、ターゲット、Amazon Redshift クラスターや DynamoDB テーブルなどの他の AWS リソースに対する Amazon S3 へのアクセスが含まれます。ロールの作成方法の詳細については、「[ジョブランタイムロールを作成する](getting-started.md#gs-runtime-role)」を参照してください。
**ランタイムポリシーの例**
ジョブランタイムロールには、次のようなランタイムポリシーをアタッチできます。次のジョブランタイムポリシーでは、以下を許可します。
+ EMR サンプルを使用した Amazon S3 バケットへの読み取りアクセス。
+ S3 バケットへのフルアクセス。
+ AWS Glue データカタログへの作成および読み取りアクセス。
DynamoDB などの他の AWS リソースへのアクセスを追加するには、ランタイムロールを作成するときにポリシーにそれらのアクセス許可を含める必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadAccessForEMRSamples",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*.elasticmapreduce",
"arn:aws:s3:::*.elasticmapreduce/*"
]
},
{
"Sid": "FullAccessToS3Bucket",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
},
{
"Sid": "GlueCreateAndReadDataCatalog",
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDataBases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"*"
]
}
]
}
```
------
**ロール権限を渡す**
ユーザーのロールに IAM のアクセス許可ポリシーをアタッチして、ユーザーが承認済みのロールのみを渡すことを許可できます。これにより、管理者は特定のジョブランタイムロールを EMR Serverless ジョブに渡すことができるユーザーを制御できます。アクセス許可の設定の詳細については、[AWS 「 サービスにロールを渡すアクセス許可をユーザーに付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)」を参照してください。
以下は、ジョブランタイムロールを EMR Serverless サービスプリンシパルに渡すことを許可するポリシーの例です。
```
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::1234567890:role/JobRuntimeRoleForEMRServerless",
"Condition": {
"StringLike": {
"iam:PassedToService": "emr-serverless.amazonaws.com"
}
}
}
```
## ランタイムロールに関連付けられた管理アクセス許可ポリシー
EMR Studio コンソールから EMR Serverless にジョブ実行を送信する場合、アプリケーションに関連付ける**ランタイムロール**を選択するステップがあります。コンソールの各選択には、注意すべき重要な基盤となる管理ポリシーが関連付けられています。3 つの選択肢は以下のとおりです:
1. **すべてのバケット** – これを選択すると、すべてのバケットへのフルアクセスを提供する [AmazonS3FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3FullAccess.html) AWS 管理ポリシーが指定されます。
1. **特定のバケット** – 選択した各バケットの Amazon リソースネーム (ARN) 識別子を指定します。基盤となる管理ポリシーは含まれていません。
1. **なし** – マネージドポリシーのアクセス許可は含まれません。
特定のバケットを追加することをお勧めします。すべてのバケットを選択した場合は、すべてのバケットにフルアクセスを設定することに注意してください。
# EMR Serverless のユーザーアクセスポリシーの例
EMR Serverless アプリケーションを操作する際に各ユーザーに実行させるアクションに応じて、ユーザーに対してきめ細かくポリシーを設定できます。次のポリシーは、ユーザーに適切なアクセス許可を設定するのに役立つ可能性のある例です。このセクションでは、EMR Serverless ポリシーのみに焦点を当てます。EMR Studio ユーザーポリシーのサンプルについては、「[Configure EMR Studio user permissions](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-user-permissions.html#emr-studio-advanced-permissions-policy)」を参照してください。IAM ユーザー (プリンシパル) にポリシーをアタッチする方法の詳細については、「IAM ユーザーガイド」の「[IAM ポリシーを管理する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html)」を参照してください。
## パワーユーザーポリシー
EMR Serverless に必要なすべてのアクションを付与するには、`AmazonEMRServerlessFullAccess` ポリシーを作成して必要な IAM ユーザー、ロール、またはグループにアタッチします。
以下の例は、パワーユーザーが EMR Serverless アプリケーションを作成、変更したり、ジョブの送信やデバッグなどのアクションを実行したりできるようにするポリシーです。EMR Serverless がその他のサービスに必要とするすべてのアクションを明らかにします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EMRServerlessActions",
"Effect": "Allow",
"Action": [
"emr-serverless:CreateApplication",
"emr-serverless:UpdateApplication",
"emr-serverless:DeleteApplication",
"emr-serverless:ListApplications",
"emr-serverless:GetApplication",
"emr-serverless:StartApplication",
"emr-serverless:StopApplication",
"emr-serverless:StartJobRun",
"emr-serverless:CancelJobRun",
"emr-serverless:ListJobRuns",
"emr-serverless:GetJobRun"
],
"Resource": [
"*"
]
}
]
}
```
------
VPC へのネットワーク接続を有効にすると、EMR Serverless アプリケーションは VPC リソースと通信するための Amazon EC2 Elastic Network Interface (ENI) を作成します。次のポリシーは、新しい EC2 ENI が EMR Serverless アプリケーションのコンテキストでのみ作成されることを保証します。
**注記**
EMR Serverless アプリケーションを起動する場合を除き、ユーザーが EC2 ENI を作成できないように、このポリシーを設定することを強くお勧めします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEC2ENICreationWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
],
"Condition": {
"StringEquals": {
"aws:CalledViaLast": "ops.emr-serverless.amazonaws.com"
}
}
}
]
}
```
------
EMR Serverless アクセスを特定のサブネットに制限する場合は、各サブネットにタグ条件を付けることができます。この IAM ポリシーにより、EMR Serverless アプリケーションは許可されたサブネット内でのみ EC2 ENI を作成できるようになります。
```
{
"Sid": "AllowEC2ENICreationInSubnetAndSecurityGroupWithEMRTags",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/KEY": "VALUE"
}
}
}
```
**重要**
管理者またはパワーユーザーが最初のアプリケーションを作成している場合は、EMR Serverless サービスにリンクされたロールを作成できるようにアクセス許可ポリシーを設定する必要があります。詳細については、[EMR Serverless のサービスリンクロールの使用](using-service-linked-roles.md) を参照してください。
次の IAM ポリシーでは、アカウントに対して EMR Serverless サービスにリンクされたロールの作成を許可します。
```
{
"Sid":"AllowEMRServerlessServiceLinkedRoleCreation",
"Effect":"Allow",
"Action":"iam:CreateServiceLinkedRole",
"Resource":"arn:aws:iam::account-id:role/aws-service-role/ops.emr-serverless.amazonaws.com/AWSServiceRoleForAmazonEMRServerless"
}
```
## データエンジニアポリシー
以下の例は、EMR Serverless アプリケーションに対する読み取り専用アクセス許可と、ジョブの送信とデバッグをユーザーに許可するポリシーです。このポリシーは明示的にアクションを拒否しないため、別のポリシーステートメントが指定したアクションへのアクセス許可に使用される場合があることに注意してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EMRServerlessActions",
"Effect": "Allow",
"Action": [
"emr-serverless:ListApplications",
"emr-serverless:GetApplication",
"emr-serverless:StartApplication",
"emr-serverless:StartJobRun",
"emr-serverless:CancelJobRun",
"emr-serverless:ListJobRuns",
"emr-serverless:GetJobRun"
],
"Resource": [
"*"
]
}
]
}
```
------
## アクセスコントロールにタグを使用する
きめ細かいアクセスコントロールのためにタグ条件を使用できます。例えば、1 つのチームからユーザーを制限して、チーム名でタグ付けされた EMR Serverless アプリケーションにのみジョブを送信できるようにすることができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EMRServerlessActions",
"Effect": "Allow",
"Action": [
"emr-serverless:ListApplications",
"emr-serverless:GetApplication",
"emr-serverless:StartApplication",
"emr-serverless:StartJobRun",
"emr-serverless:CancelJobRun",
"emr-serverless:ListJobRuns",
"emr-serverless:GetJobRun"
],
"Resource": [
"*"
]
}
]
}
```
------
# タグベースのアクセスコントロールのポリシー
アイデンティティベースのポリシーの条件を使用して、タグに基づいてアプリケーションとジョブ実行へのアクセスをコントロールできます。
次の例では、EMR Serverless 条件キーで条件演算子を使用するさまざまなシナリオと方法について説明しています。これらの IAM ポリシーステートメントは、デモンストレーションのみを目的としており、本稼働環境で使用しないでください。要件に応じて、アクセス権限を付与または拒否するようにポリシーステートメントを組み合わせる複数の方法があります。IAM ポリシーの計画およびテストの詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/)」を参照してください。
**重要**
アクションをタグ付けするための権限を明示的に拒否することは重要な考慮事項です。これにより、ユーザーがリソースをタグ付けして意図せずにアクセス許可を付与することを防ぎます。リソースのタグ付けアクションが拒否されない場合、ユーザーはタグを変更して、タグベースのポリシーの意図を回避できます。タグ付けアクションを拒否するポリシーの例については、「[タグを追加および削除するためのアクセス権限を拒否する](#security-iam-TBAC-deny)」を参照してください。
以下の例では、EMR Serverless アプリケーションで許可されるアクションを制御するために使用するアイデンティティベースの許可ポリシーを説明しています。
## 特定のタグの値があるリソースでのみアクションを許可する
次のポリシーの例では、`StringEquals` 条件演算子は、`dev` をタグ department の値と一致させるように試みます。タグ department がアプリケーションに追加されていない場合、またはタグ department に値 `dev` が含まれていない場合は、ポリシーは適用されず、このアクションはポリシーによって許可されません。アクションを許可するポリシーステートメントが他にない場合は、ユーザーはこの値を持つこのタグを持っているアプリケーションとのみ作業できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"emr-serverless:GetApplication"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/department": "dev"
}
},
"Sid": "AllowEMRSERVERLESSGetapplication"
}
]
}
```
------
条件付き演算子を使用して複数のタグ値を指定できます。例えば、`department` タグに値 `dev` または `test` が含まれるアプリケーションでアクションを許可するには、以下のように、前術の例のような条件ブロックを置き換えます。
```
"Condition": {
"StringEquals": {
"emr-serverless:ResourceTag/department": ["dev", "test"]
}
}
```
## リソースの作成時にタグ付けを要求する
次の例では、アプリケーションの作成時にタグを適用する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"emr-serverless:CreateApplication"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1"
}
},
"Sid": "AllowEMRSERVERLESSCreateapplication"
}
]
}
```
------
次のポリシーステートメントは、任意の値を含めることができる `department` タグがアプリケーションにある場合にのみ、ユーザーにアプリケーションの作成を許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"emr-serverless:CreateApplication"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2"]
}
},
"Sid": "AllowEMRSERVERLESSCreateapplication"
}
]
}
```
------
## タグを追加および削除するためのアクセス権限を拒否する
このポリシーは、ユーザーが、`dev` ではない値の `department` タグを使用して EMR Serverless アプリケーションでタグを追加または削除できないようにします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"emr-serverless:TagResource",
"emr-serverless:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/department": "dev"
}
},
"Sid": "AllowEMRSERVERLESSTagresource"
}
]
}
```
------
# EMR Serverless でのアイデンティティベースのポリシー例
デフォルトでは、ユーザーおよびロールには Amazon EMR Serverless リソースを作成または変更するアクセス権限はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
Amazon EMR Serverless が定義するアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「*サービス認可リファレンス*」の「[Amazon EMR Serverless のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticmapreduce.html)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](#security-iam-policy-best-practices)
+ [自分の権限へのアクセスをユーザーに許可する](#security-iam-id-based-policy-examples-view-own-permissions)
## ポリシーに関するベストプラクティス
**注記**
EMR Serverless は マネージドポリシーをサポートしていないため、以下に記載されている最初のプラクティスは適用されません。
アイデンティティベースのポリシーは、アカウント内で誰が Amazon EMR Serverless リソースを作成、アクセス、または削除できるを決定します。これらのアクションでは、 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) を参照してください。
## 自分の権限へのアクセスをユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を 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 マネージドポリシーに対する Amazon EMR Serverless の更新
このサービスがこれらの変更の追跡を開始してからの Amazon EMR Serverless の AWS マネージドポリシーの更新に関する詳細にアクセスします。このページの変更に関する自動通知を入手するには、Amazon EMR Serverless [ドキュメントの履歴ページ](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/doc-history.html)から、RSS フィードにサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| AmazonEMRServerlessServiceRolePolicy – 既存のポリシーの更新 | Amazon EMR Serverless は、新しい `Sid` の `CloudWatchPolicyStatement` と `EC2PolicyStatement` を [AmazonEMRServerlessServiceRolePolicy ポリシー](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/using-service-linked-roles.html#slr-permissions)に追加しました。 | 2024 年 1 月 25 日 |
| AmazonEMRServerlessServiceRolePolicy – 既存のポリシーの更新 | Amazon EMR Serverless は、Amazon EMR Serverless が `"AWS/Usage"` 名前空間で vCPU 使用状況の集計アカウントメトリクスを発行できるようにする新しいアクセス許可を追加しました。 | 2023 年 4 月 20 日 |
| Amazon EMR Serverless が変更の追跡を開始しました。 | Amazon EMR Serverless は、 AWS 管理ポリシーの変更の追跡を開始しました。 | 2023 年 4 月 20 日 |
# Amazon EMR Serverless の ID とアクセスのトラブルシューティング
Amazon EMR Serverless と IAM の使用時に発生する可能性がある一般的な問題の診断や修正には、次の情報が役立ちます。
**Topics**
+ [Amazon EMR Serverless でアクションを実行する権限がない](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がない](#security_iam_troubleshoot-passrole)
+ [AWS アカウント外のユーザーに Amazon EMR Serverless リソースへのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
+ [EMR Studio からライブ UI/Spark 履歴サーバーを開いてジョブをデバッグできないか、`get-dashboard-for-job-run` を使用してログを取得しようとすると API エラーが発生する](#security_iam_troubleshoot-emr-identity-access)
## Amazon EMR Serverless でアクションを実行する権限がない
がアクションを実行する権限がないと AWS マネジメントコンソール 通知した場合は、管理者に連絡してサポートを依頼してください。担当の管理者はお客様のユーザー名とパスワードを発行した人です。
以下のエラー例は、`mateojackson` ユーザーがコンソールを使用して架空の `my-example-widget` リソースに関する詳細情報にアクセスしようとしているが、架空の `emr-serverless:GetWidget` 許可がないという場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: emr-serverless:GetWidget on resource: my-example-widget
```
この場合、Mateo は、`emr-serverless:GetWidget` アクションを使用して `my-example-widget` リソースにアクセスできるように、管理者にポリシーの更新を依頼します。
## iam:PassRole を実行する権限がない
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Amazon EMR Serverless にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、既存のロールをそのサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
次の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Amazon EMR Serverless でアクションを実行しようとした場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## AWS アカウント外のユーザーに Amazon EMR Serverless リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ Amazon EMR Serverless がこれらの機能をサポートしているかどうかを確認するには、「[Amazon EMR Serverless での Identity and Access Management (IAM)](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/access_policies-cross-account-resource-access.html) を参照してください。
## EMR Studio からライブ UI/Spark 履歴サーバーを開いてジョブをデバッグできないか、`get-dashboard-for-job-run` を使用してログを取得しようとすると API エラーが発生する
ログ記録に EMR Serverless マネージドストレージを使用し、EMR Serverless アプリケーションが Amazon S3 の VPC エンドポイントを持つプライベートサブネットにあり、アクセスを制御するエンドポイントポリシーをアタッチする場合は、「[Logging for EMR Serverless with managed storagein your VPC policy](logging.html#jobs-log-storage-managed-storage)」に記載されているアクセス許可を、EMR Serverless がアプリケーションログを保存して処理するための S3 ゲートウェイエンドポイントに追加します。