# IAM をトラブルシューティングする
この情報を使用して、AWS Identity and Access Management (IAM) を使用する際に一般的な問題の診断と修正を行います。
**Topics**
+ [自分の AWS アカウントにサインインできません](#troubleshoot_general_cant-sign-in)
+ [アクセスキーを紛失した](#troubleshoot_general_access-keys)
+ [ポリシーの変数が機能していない](#troubleshoot_general_policy-variables-dont-work)
+ [行った変更がすぐに表示されないことがある](#troubleshoot_general_eventual-consistency)
+ [iam:DeleteVirtualMFADevice を実行することを認可されていません](#troubleshoot_general_access-denied-delete-mfa)
+ [IAM ユーザーを安全に作成するにはどうすればよいですか?](#troubleshoot_general_securely-create-iam-users)
+ [その他のリソース](#troubleshoot_general_resources)
+ [アクセス拒否エラーメッセージをトラブルシューティングする](troubleshoot_access-denied.md)
+ [ルートユーザーに関する問題をトラブルシューティングする](troubleshooting_root-user.md)
+ [IAM ポリシーをトラブルシューティングする](troubleshoot_policies.md)
+ [FIDO セキュリティキーをトラブルシューティングする](troubleshoot_mfa-fido.md)
+ [IAM ロールをトラブルシューティングする](troubleshoot_roles.md)
+ [IAM および Amazon EC2 をトラブルシューティングする](troubleshoot_iam-ec2.md)
+ [Amazon S3 と IAM をトラブルシューティングする](troubleshoot_iam-s3.md)
+ [SAML と IAM とのフェデレーションをトラブルシューティングする](troubleshoot_saml.md)
## 自分の AWS アカウントにサインインできません
正しい認証情報を持っていること、およびサインインに正しい方法を使用していることを確認します。詳しい情報については、「AWS サインイン ユーザーガイド」の「[サインインに関する問題のトラブルシューティング](https://docs.aws.amazon.com/signin/latest/userguide/troubleshooting-sign-in-issues.html)」を参照してください。
## アクセスキーを紛失した
アクセスキーは 2 つのパートで構成されます。
+ **アクセスキー識別子**。これはシークレットではなく、ユーザー概要ページなど、IAM コンソールでアクセスキーがリストされるすべての場所に表示されます。
+ **シークレットアクセスキー**。これは最初にアクセスキーペアを作成するときに提供されます。パスワードと同じように、***後で取得することはできません***。シークレットアクセスキーを紛失した場合は、新しいアクセスキーペアを作成する必要があります。[アクセスキーの最大数](reference_iam-quotas.md#reference_iam-quotas-entities)に達している場合は、既存のペアを削除してから新しいものを作成する必要があります。
シークレットアクセスキーを紛失した場合は、そのアクセスキーを削除し、新しく作成する必要があります。詳細な手順については、「[アクセスキーを更新する](id-credentials-access-keys-update.md)」を参照してください。
## ポリシーの変数が機能していない
ポリシー変数が機能しない場合は、次のいずれかのエラーが発生しています。
**Version ポリシー要素の日付が間違っています。**
変数のあるすべてのポリシーで、バージョン番号: `"Version": "2012-10-17"` がポリシーに含まれていることを確認します。正しいバージョン番号がないと、評価時に変数は置き換えられません。代わりに、変数は逐語的に評価されます。変数が含まれていないポリシーは、最新のバージョン番号が含まれていれば正常に機能します。
`Version` ポリシー要素は、ポリシーバージョンとは異なります。`Version` ポリシー要素は、ポリシー内で使用され、ポリシー言語のバージョンを定義します。ポリシーバージョンは、IAM でカスタマー管理ポリシーを変更すると作成されます。変更されたポリシーによって既存のポリシーが上書きされることはありません。代わりに、IAM は管理ポリシーの新しいバージョンを作成します。`Version` ポリシー要素の詳細については、「[IAM JSON ポリシー要素Version](reference_policies_elements_version.md)」を参照してください。ポリシーのバージョンの詳細については、「[IAM ポリシーのバージョニング](access_policies_managed-versioning.md)」を参照してください。
**変数文字の大文字と小文字が間違っています。**
お客様のポリシーの変数が正しく設定されていることを確認してください。詳細については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。
## 行った変更がすぐに表示されないことがある
世界中のデータセンター内のコンピューターを介してアクセスされるサービスとして、IAM は、[結果整合性](https://wikipedia.org/wiki/Eventual_consistency)と呼ばれる分散コンピューティングモデルを採用しています。[属性ベースのアクセス制御 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) タグなど、IAM (または他の AWS サービス) で変更を行った場合、その変更が関係するすべてのエンドポイントに反映されるまでに時間がかかります。その要因には、サーバー間、レプリケーションゾーン間、リージョン間でのデータの送信に時間がかかるということがあります。IAM ではパフォーマンス向上のためにキャッシュも使用しているため、これが原因で遅延が発生することがあります。変更は、以前にキャッシュされたデータがタイムアウトになるまで反映されない場合があります。
発生する可能性のあるこれらの遅延を考慮して、グローバルなアプリケーションを設計する必要があります。ある場所で行われた変更が他の場所で直ちに表示されない場合でも、正常に動作することを確認します。このような変更には、ユーザー、グループ、ロール、またはポリシーの作成や更新が含まれます。アプリケーションの重要で高可用性のコードパスには、このような IAM の変更を含めないことをお勧めします。代わりに、実行頻度が低い別の初期化またはセットアップルーチンに IAM の変更を加えます。また、本番稼働ワークフローが依存する前に、変更が伝達済みであることを確認します。
AWS の他のいくつかのサービスがこの遅延からどのような影響を受けるかの詳細については、以下のリソースを参照してください。
+ **Amazon DynamoDB**:「DynamoDB デベロッパーガイド」の「[読み込み整合性](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html)」と「Amazon DynamoDB デベロッパーガイド」の「[読み込み整合性](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html)」。
+ **Amazon EC2**: [Amazon EC2 API リファレンス](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#eventual-consistency)の* EC2 結果整合性*。
+ **Amazon EMR**:「AWS ビッグデータブログ」の「[Ensuring Consistency When Using Amazon S3 and Amazon EMR for ETL Workflows](https://aws.amazon.com/blogs/big-data/ensuring-consistency-when-using-amazon-s3-and-amazon-elastic-mapreduce-for-etl-workflows/)」
+ **Amazon Redshift**: [Amazon Redshift Database デベロッパーガイド](https://docs.aws.amazon.com/redshift/latest/dg/managing-data-consistency.html)の* データの一貫性の管理*
+ **Amazon S3**: [Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com//AmazonS3/latest/userguide/Welcome.html#ConsistencyModel)の* Amazon S3 データ整合性モデル*
## iam:DeleteVirtualMFADevice を実行することを認可されていません
自分または他のユーザーに仮想 MFA デバイスを割り当てるまたは削除しようとすると、次のエラーが表示されることがあります。
```
User: arn:aws:iam::123456789012:user/Diego is not authorized to perform: iam:DeleteVirtualMFADevice on resource: arn:aws:iam::123456789012:mfa/Diego with an explicit deny
```
これは、誰かが以前に IAM コンソールでユーザーに仮想 MFA デバイスの割り当てを開始し、プロセスをキャンセルした場合に発生する可能性があります。これにより、IAM でユーザー用の仮想化 MFA デバイスが作成されますが、ユーザーに決して割り当てられません。新しい仮想化 MFA デバイスを同じデバイス名で作成する前に、既存の仮想化 MFA デバイスを削除します。
この問題を修正するために、管理者はポリシーのアクセス許可を編集**しないでください**。代わりに、管理者は AWS CLI または AWS API を使用して、既存のしかし割り当てられていない仮想化 MFA デバイスを削除する必要があります。
**既存の未割り当て仮想化 MFA デバイスを削除するには**
1. アカウントの仮想 MFA デバイスを表示します。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html)
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html)
1. レスポンスで、修正しようとしているユーザーの仮想化 MFA デバイスの ARN を見つけます。
1. 仮想化 MFA デバイスを削除します。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html)
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html)
## IAM ユーザーを安全に作成するにはどうすればよいですか?
AWS へのアクセスを必要とする従業員がいる場合は、IAM ユーザーを作成するか、[認証に IAM Identity Center を使用する](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)かを選択できます。IAM を使用する場合、AWS では、IAM ユーザーを作成し、その認証情報を従業員に安全に伝達することを推奨しています。従業員の隣に物理的に配置されていない場合は、安全なワークフローを使用して、従業員に認証情報を伝達します。
IAM で新しいユーザーを作成するには、次の安全なワークフローを使用します。
1. AWS マネジメントコンソール を使用して[新しいユーザーを作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html)します。生成されたパスワードを使用してAWS マネジメントコンソールへのアクセスを付与することを選択します。必要に応じて、[**Users must create a new password at next sign-in**] (ユーザーは次回サインイン時に新しいパスワードを作成する必要があります) のチェックボックスをオンにします。ユーザーがパスワードを変更するまで、アクセス許可ポリシーをユーザーに追加しないでください。
1. ユーザーを追加したら、新しいユーザーのサインイン URL、ユーザー名、およびパスワードをコピーします。パスワードを表示するには、[**Show**] (表示) を選択します。
1. E メール、チャット、チケットシステムなど、社内の安全な通信方法を使用して、従業員にパスワードを送信します。別途、IAM ユーザーコンソールのリンクおよびユーザー名をユーザーに提供します。アクセス許可を付与する前に、正常にサインインできることを確認するよう従業員に伝えます。
1. 従業員が確認したら、必要なアクセス許可を追加します。セキュリティのベストプラクティスとして、認証情報を管理するために MFA を使用した認証をユーザーに要求するポリシーを追加します。ポリシーの例については「[AWS: MFA で認証された IAM ユーザーが [セキュリティ認証情報] ページで自分の認証情報を管理できるようにします](reference_policies_examples_aws_my-sec-creds-self-manage.md)」を参照してください。
## その他のリソース
AWS を使用する際のトラブルシューティングに役立つリソースを以下に示します。
+ **[AWS CloudTrail ユーザーガイドユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)** – AWS CloudTrail を使用して、AWS への API コールの履歴を追跡し、その情報をログファイルに保存します。この情報は、どのユーザーおよびアカウントがお客様のアカウントのリソースにアクセスしたか、いつその呼び出しが行われたか、どのアクションがリクエストされたかなどを調べるために役立ちます。詳細については、「[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)」を参照してください。
+ **[AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)** — 問題のトラブルシューティングに役立つ FAQ やその他のリソースへのリンクを検索できます。
+ **[AWS サポートセンター](https://console.aws.amazon.com/support/home#/)** — テクニカルサポートを利用できます。
+ **[AWS プレミアムサポートセンター](https://aws.amazon.com/premiumsupport/)** – プレミアムテクニカルサポートを利用できます。
# アクセス拒否エラーメッセージをトラブルシューティングする
AWS Identity and Access Management で発生したアクセス拒否エラーを識別し、診断して解決する場合は、以下の情報を参照すると便利です。アクセス拒否エラーは、AWS が認可リクエストを明示的または暗黙的に拒否した場合に表示されます。
+ *明示的な拒否*は、特定の AWS アクションに対する `Deny` ステートメントがポリシーに含まれている場合に発生します。
+ 該当する `Deny` ステートメントがなく、該当する `Allow` ステートメントもない場合に、暗黙的な拒否が発生します。IAM ポリシーはデフォルトで IAM プリンシパルを拒否するため、ポリシーではプリンシパルにアクションの実行を明示的に許可する必要があります。それ以外の場合、ポリシーは暗黙的にアクセスを拒否します。詳細については、「[明示的な拒否と暗黙的な拒否の違い](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md)」を参照してください。
サービスやリソースにリクエストを送信するときに、複数のポリシーがそのリクエストに適用されることがあります。エラーメッセージで指定されたポリシーだけでなく、適用可能なポリシーをすべて確認してください。
+ ポリシータイプが同じである複数のポリシーがリクエストを拒否した場合、アクセス拒否エラーメッセージには評価されたポリシーの番号が指定されません。
+ 複数のポリシータイプが原因で認可リクエストが拒否された場合、AWS は、これらのポリシータイプのうち 1 つだけをエラーメッセージに含めます。
**重要**
**AWS へのサインインに問題がある場合** ユーザーのタイプに応じて正しい [AWS サインインページ](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)が表示されていることを確認します。AWS アカウントのルートユーザー (アカウント所有者) の場合は、AWS アカウント の作成時に設定した認証情報を使用して AWS にサインインできます。IAM ユーザーの場合、アカウント管理者から AWS サインイン認証情報を付与してもらうことができます。サポートをリクエストする必要がある場合は、このページのフィードバックリンクを使用しないでください。フォームは、サポート ではなく AWS ドキュメントチームに届きます。代わりに、「[お問い合わせ](https://aws.amazon.com/contact-us/)」ページで **[AWS アカウントにまだログインできない]** を選択してから、表示されているサポートオプションのいずれかを選択します。
## AWS サービスに要求を送信すると "アクセス拒否" が発生する
+ エラーメッセージに、アクセスを拒否するポリシーの種類と [Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) が含まれているかどうかを確認します。このケースでは、指定されたポリシーでこのアクションの拒否ステートメントをチェックします。ポリシータイプは指定されているもののポリシー ARN がない場合は、そのポリシータイプのトラブルシューティングの問題に焦点を当てます。指定されたタイプのポリシーで、このアクションの拒否ステートメントをチェックします。エラーメッセージに、アクセスを拒否するポリシーの種類が記載されていない場合は、このセクションの残りのガイドラインを参考にして、さらにトラブルシューティングを行ってください。
+ リクエストしたアクションとリソースを呼び出すアイデンティティベースのポリシーのアクセス許可を持っていることを確認します。条件が付けられている場合、要求を送信するにはそれらの条件も満たしている必要があります。IAM ユーザー、グループ、ロールのポリシーの表示や修正の詳細については、「[IAM ポリシーを管理する](access_policies_manage.md)」を参照してください。
+ AWS マネジメントコンソール から、アクションを実行する権限がないと通知された場合、管理者に問い合わせ、サポートを依頼する必要があります。管理者からサインイン資格情報またはサインインリンクが提供されました。
以下のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用して架空の `my-example-widget` リソースに関する詳細情報を表示しようとしているが、架空の `widgets:GetWidget` 許可がないという場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: widgets:GetWidget on resource: my-example-widget
```
この場合、Mateo は、`my-example-widget` アクションを使用して `widgets:GetWidget` リソースにアクセスできるように、ポリシーの更新を管理者に依頼する必要があります。
+ Amazon S3、Amazon SNS、Amazon SQS などの[リソースベースのポリシー](access_policies_identity-vs-resource.md)をサポートするサービスにアクセスしようとしていますか。その場合は、ポリシーでお客様がプリンシパルに指定されていて、アクセス権限を付与されていることを確認します。アカウント内のサービスにリクエストする場合は、アイデンティティベースのポリシーまたはリソースベースのポリシーを使用して、アクセス許可を付与することができます。別のアカウントのサービスにリクエストする場合は、アイデンティティベースのポリシーとリソースベースのポリシーの両方でアクセス許可を付与する必要があります。リソースベースのポリシーをサポートするサービスを確認するには、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。
+ キーバリューのペアを持つ条件がポリシーに含まれている場合は、そのポリシーを慎重に確認します。この例には、[`aws:RequestTag/tag-key`](reference_policies_condition-keys.md) グローバル条件キー、AWS KMS [kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context](kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context)、および複数のサービスでサポートされている `ResourceTag/tag-key` 条件キーが含まれます。キー名が複数の結果に一致しないことを確認します。条件キー名では大文字と小文字が区別されないため、`foo` というキーを確認する条件は、`foo`、`Foo`、または `FOO` に一致します。リクエストに複数のキーバリューのペアが含まれていて、キー名の大文字と小文字のみが異なる場合、アクセスは予期せず拒否される可能性があります。詳細については、「[IAM JSON ポリシー要素Condition](reference_policies_elements_condition.md)」を参照してください。
+ [アクセス許可の境界](access_policies_boundaries.md)が設定されている場合は、アクセス許可の境界として使用されているポリシーでリクエストが許可されるかどうかを確認します。リクエストがアイデンティティベースのポリシーでは許可されるが、アクセス許可の境界では許可されない場合、リクエストは拒否されます。アクセス許可の境界は、IAM プリンシパル (ユーザーまたはロール) に付与できるアクセス許可の上限を設定します。リソースベースのポリシーは、アクセス許可の境界では制限されません。アクセス許可の境界は一般向けの機能ではありません。AWS によるポリシーの評価方法の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
+ 手動でリクエストに署名する ([AWS SDK](https://aws.amazon.com/developer/tools/) を使用しない) 場合は、正確に[リクエストに署名](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)していることを確認します。
+ [Amazon VPC エンドポイントポリシー](https://docs.aws.amazon.com//vpc/latest/privatelink/vpc-endpoints-access.html)を使用していて、AWS CloudTrail にログインしていないアクセス拒否エラーが発生した場合は、VPC エンドポイント所有者アカウントが呼び出し元のアカウントまたはターゲットロールアカウントと異なる可能性があります。
## 一時的な認証情報を使用して要求を送信すると "アクセス拒否" が発生する
+ まず、一時的な認証情報とは別の理由でアクセスが拒否されていないことを確認してください。詳細については、「[AWS サービスに要求を送信すると "アクセス拒否" が発生する](#troubleshoot_general_access-denied-service)」を参照してください。
+ サービスが一時的セキュリティ認証情報を受け入れることを確認します。「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。
+ リクエストが正しく署名されており、そのリクエストの形式が整っていることを確認します。詳細については、[ツールキット](https://aws.amazon.com/developer/tools/)ドキュメントまたは「[AWS リソースで一時的な認証情報を使用する](id_credentials_temp_use-resources.md)」を参照してください。
+ 一時的な認証情報が失効していないことを確認します。詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」を参照してください。
+ IAM ユーザーまたはロールに正しいアクセス権限があるかどうかを確認します。一時的なセキュリティ認証情報のアクセス許可は IAM ユーザーまたはロールから取得されます。その結果、アクセス許可は、一時的な認証情報を引き受けたロールに付与されているものに制限されます。一時的なセキュリティ認証情報に対するアクセス許可の決定方法の詳細については、「[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)」を参照してください。
+ ロールを引き受ける場合は、ロールセッションはセッションポリシーによって制限される場合があります。AWS STS を使用してプログラムで[一時的なセキュリティ認証情報をリクエストする](id_credentials_temp_request.md)場合は、オプションでインラインまたは管理[セッションポリシー](access_policies.md#policies_session)を渡すことができます。セッションポリシーは、ロールの一時認証情報セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。`Policy` パラメータを使用して単一の JSON インラインセッションポリシードキュメントを渡すことができます。`PolicyArns` パラメータを使用して、最大 10 個の管理セッションポリシーを指定できます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。または、管理者またはカスタムプログラムから一時的な認証情報が提供されている場合は、アクセスを制限するためのセッションポリシーが含まれている可能性があります。
+ AWS STS フェデレーションユーザーの場合、セッションはセッションポリシーによって制限される場合があります。IAM ユーザーとして AWS にサインインしてフェデレーショントークンをリクエストすることで、フェデレーションユーザーのセッションを作成します。詳細については、「[カスタム ID ブローカーを通じた認証情報のリクエスト](id_credentials_temp_request.md#api_getfederationtoken)」を参照してください。フェデレーショントークンをリクエスト中に ID ブローカーがセッションポリシーに合格した場合、セッションはそれらのポリシーによって制限されます。結果として得られるセッションのアクセス許可は、IAM ユーザーの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーの詳細については、「[セッションポリシー](access_policies.md#policies_session)」を参照してください。
+ ロールを使用してリソースベースのポリシーのあるリソースへアクセスする場合は、ポリシーからロールにアクセス権限が付与されていることを確認します。例えば、次のポリシーではアカウント `MyRole` からの `111122223333` の `amzn-s3-demo-bucket` へのアクセスを許可しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "S3BucketPolicy",
"Effect": "Allow",
"Principal": {"AWS": ["arn:aws:iam::111122223333:role/MyRole"]},
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/*"]
}]
}
```
------
## Access Troubleshooter
**注記**
Access Troubleshooter は、単一アカウントおよび単一組織のシナリオで、すべてのリージョンのすべての AWS サービスで利用可能になりつつあります。データの豊富さは進化します。
Access Troubleshooter を使用して、アクセス拒否エラーをデバッグおよび解決できます。
Access Troubleshooter の機能は次のとおりです。
+ [リクエストと評価の詳細を表示する](#access-troubleshooter-request-details): プリンシパル、アクション、リソース、コンテキスト、評価結果。
+ [個々の認可評価を表示する](#access-troubleshooter-individual-evaluation): 個々のアクションとリソースペアの認可評価。
+ [すべてのポリシーと個々のステートメントを確認する](#access-troubleshooter-policy-statements): 評価されたすべてのポリシーと個々のステートメント、およびそれぞれの評価結果。
### Access Troubleshooter のアクセス許可
Access Troubleshooter を使用するには、プリンシパルに `iam:TroubleshootAccess` アクセス許可がアタッチされている必要があります。このアクションを許可すると、評価されたすべてのポリシーのコンテキストキーとステートメントを含む、すべての認可コンテキストの詳細をプリンシパルが表示できるようになります。
次のポリシーの例では、必要なアクセス許可を付与します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:TroubleshootAccess",
"Resource": "*"
}
]
}
```
### Access Troubleshooter の使用
アクセス拒否エラーを受け取ると、Access Troubleshooter で使用できるリンクと AuthorizationID を含むエラーメッセージが届きます。次の例は、アクセス拒否エラーメッセージを示しています。
```
An error occurred (AccessDenied) when calling the RestoreTableFromBackup operation: User: arn:aws:sts:012345678901:assumedRole/DatabaseDev/RestoreBackupSession is not authorized to perform: dynamodb:RestoreTableFromBackup with an explicit deny in an identity policy. Go to https://console.aws.amazon.com/iam/home#/access-troubleshooter for complete details, or call the iam:GetAuthorizationDetails API with the following authorization id: 67f1576b-af29-4c66-9b2b-10fd67516713
```
適切なアクセス許可がある場合は、コンソールで **[IAM でトラブルシューティング]** を選択し、新しい Access Troubleshooter タブを開くことができます。
または、AuthorizationID を使用して `iam:GetAuthorizationDetails` API を呼び出すこともできます。
```
aws iam get-authorization-details --authorization-id 67f1576b-af29-4c66-9b2b-10fd67516713
```
管理者で、開発者が AuthorizationID を提供する場合は、IAM コンソールに移動して AuthorizationID を入力して、認可コンテキストの詳細を取得できます。
### リクエストと評価の詳細を表示する
Access Troubleshooter は、評価で考慮されたリクエストの詳細を提供します。試行したオペレーションまたは API コール、認可 ID、呼び出しを行ったプリンシパル、アクセスを試みたリソース、評価結果を確認できます。
### 個々の認可評価を表示する
オペレーションを正常に呼び出すには、依存アクションを実行するための追加のアクセス許可が必要になる場合があります。例えば、DynamoDBで `RestoreTableFromBackup` を実行するには、`dynamodb:BatchWriteItem`、`dynamodb:DeleteItem`、`dynamodb:GetItem`、`dynamodb:PutItem`、`dynamodb:Query`、`dynamodb:Scan`、`dynamodb:UpdateItem` のアクセス許可が必要です。これらのアクションは、アクセスするリソースに対して評価されます。詳細については、「[サービス認可リファレンス](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)」を参照してください。
### すべてのポリシーと個々のステートメントを確認する
多くの場合、複数のポリシーが認可に影響し、各ポリシーに複数のステートメントを含めることができます。Access Troubleshooter は、オペレーションの実行時に評価されるすべてのポリシーを一覧表示します。これらのポリシー内の個々のステートメントとそれぞれの評価結果を確認し、問題を効率的に解決するための完全なビューを提供できます。
## アクセス拒否エラーメッセージの例
ほとんどのアクセス拒否のエラーメッセージは、`User user is not authorized to perform action on resource because context` の形式です。この例では、*ユーザー*は、アクセスを拒否されたプリンシパルの ARN、*アクション*はこのポリシーが拒否するサービスアクション、*リソース*はこのポリシーが対象とするリソースの ARN です。*コンテキスト*フィールドには、アクセスを拒否されたポリシータイプについての追加のコンテキストが表示されます。アクセスを拒否したポリシーの ARN が含まれている場合もあります。
ポリシー内の `Deny` ステートメントによって明示的にポリシーが拒否された場合、AWS はアクセス拒否エラーメッセージに `with an explicit deny in a type policy` を含めます。このフレーズでは、次のようにポリシーの ARN を指定することもできます。`with an explicit deny in a type policy: policy ARN`
ポリシーが暗黙的に拒否された場合は、AWS はアクセス拒否エラーメッセージに文字列 `because no type policy allows the action action` を含めます。
**注記**
AWS のサービスによっては、このアクセス拒否エラーメッセージ形式をサポートしていません。アクセス拒否エラーメッセージの内容は、認可リクエストを行うサービスによって異なる場合があります。
次の例では、アクセス拒否エラーメッセージの形式のタイプを示します。
### サービスコントロールポリシーによるアクセスの拒否 – 暗黙的な拒否
1. サービスコントロールポリシー (SCP) のアクションで、`Allow` ステートメントが欠けていないかを確認します。次の例では、`codecommit:ListRepositories` がアクションです。
1. `Allow` ステートメントを追加して、ポリシーを更新してください。詳細については、「*AWS Organizations ユーザーガイド*」の「[SCP の更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_create.html#update_policy)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codecommit:ListRepositories
because no service control policy allows the codecommit:ListRespositories action
```
### サービスコントロールポリシーによるアクセスの拒否 – 明示的な拒否
1. ポリシー ARN がエラーメッセージで指定されている場合は、指定されたサービスコントロールポリシー (SCP) でアクションの `Deny` ステートメントをチェックします。以下の例では、アクションは `codecommit:ListRepositories` です。
1. エラーメッセージでポリシー ARN が指定されていない場合は、SCP でアクションの `Deny` ステートメントをチェックします。
1. `Deny` ステートメントを削除して、SCP を更新してください。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシーの更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy)」を参照してください。
ポリシー ARN を含むエラーメッセージ
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codecommit:ListRepositories
with an explicit deny in a service control policy: arn:aws:organizations::777788889999:policy/o-exampleorgid/service_control_policy/p-examplepolicyid123
```
ポリシー ARN を含まないエラーメッセージ
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codecommit:ListRepositories
with an explicit deny in a service control policy
```
### リソースコントロールポリシーによるアクセスの拒否 – 明示的な拒否
1. ポリシー ARN がエラーメッセージで指定されている場合は、指定されたリソースコントロールポリシー (RCP) でこのアクションの `Deny` ステートメントをチェックします。以下の例では、アクションは `secretsmanager:GetSecretValue` です。
1. エラーメッセージでポリシー ARN が指定されていない場合は、RCP でアクションの `Deny` ステートメントをチェックします。
1. `Deny` ステートメントを削除して、RCP を更新してください。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP) の更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy-rcp)」を参照してください。
ポリシー ARN を含むエラーメッセージ
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: secretsmanager:GetSecretValue
on resource: arn:aws:secretsmanager:us-east-1:123456789012:secret:*
with an explicit deny in a resource control policy: arn:aws:organizations::777788889999:policy/o-exampleorgid/resource_control_policy/p-examplepolicyid456
```
ポリシー ARN を含まないエラーメッセージ
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: secretsmanager:GetSecretValue
on resource: arn:aws:secretsmanager:us-east-1:123456789012:secret:*
with an explicit deny in a resource control policy
```
### VPC エンドポイントポリシーによるアクセスの拒否 – 暗黙的な拒否
1. 仮想プライベートクラウド (VPC) エンドポイントポリシーのアクションで、`Allow` ステートメントが欠落していないかを確認してください。次の例では、`codecommit:ListRepositories` がアクションです。
1. `Allow` ステートメントを追加して、VPC エンドポイントポリシーを更新します。詳細については、「*AWS PrivateLink ガイド*」の「[Update a VPC endpoint policy](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#update-vpc-endpoint-policy)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codecommit:ListRepositories
because no VPC endpoint policy allows the codecommit:ListRepositories action
```
### VPC エンドポイントポリシーによるアクセスの拒否 – 明示的拒否
1. 仮想プライベートクラウド (VPC) エンドポイントポリシーにあるアクションに対する明示的 `Deny` ステートメントがあるのかを確認してください。次の例では、`codedeploy:ListDeployments` がアクションです。
1. `Deny` ステートメントを削除して、VPC エンドポイントポリシーを更新してください。詳細については、「*AWS PrivateLink ガイド*」の「[VPC エンドポイントポリシーを更新する](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#update-vpc-endpoint-policy)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codedeploy:ListDeployments
on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:*
with an explicit deny in a VPC endpoint policy
```
### アクセス許可の境界によりアクセスの拒否 – 暗黙的な拒否
1. アクセス許可の境界にあるアクションで、`Allow` ステートメントが欠落してないかを確認してください。次の例では、`codedeploy:ListDeployments` がアクションです。
1. IAM ポリシーに `Allow` ステートメントを追加して、アクセス許可の境界を更新してください。詳細については、「[IAM エンティティのアクセス許可境界](access_policies_boundaries.md)」および「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codedeploy:ListDeployments
on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:*
because no permissions boundary allows the codedeploy:ListDeployments action
```
### アクセス許可の境界によりアクセスの拒否 – 明示的拒否
1. ポリシー ARN がエラーメッセージで指定されている場合は、指定されたアクセス許可の境界でこのアクションの `Deny` ステートメントをチェックします。以下の例では、アクションは `sagemaker:ListModels` です。
1. ポリシー ARN がエラーメッセージで指定されている場合は、プリンシパルにアタッチされたアクセス許可の境界でこのアクションの `Deny` ステートメントをチェックします。
1. IAM ポリシーから `Deny` ステートメントを削除して、アクセス許可の境界を更新してください。詳細については、「[IAM エンティティのアクセス許可境界](access_policies_boundaries.md)」および「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
ポリシー ARN を含むエラーメッセージ
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: sagemaker:ListModels
with an explicit deny in a permissions boundary: arn:aws:iam::123456789012:policy/DeveloperPermissionBoundary
```
ポリシー ARN を含まないエラーメッセージ
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: sagemaker:ListModels
with an explicit deny in a permissions boundary
```
### セッションポリシーによるアクセスの拒否 – 暗黙的な拒否
1. セッションポリシーにあるアクションで、`Allow` ステートメントが欠落していないかを確認してください。次の例では、`codecommit:ListRepositories` がアクションです。
1. `Allow` ステートメントを追加して、セッションポリシーを更新してください。詳細については、「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」と「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codecommit:ListRepositories
because no session policy allows the codecommit:ListRepositories action
```
### セッションポリシーによるアクセスの拒否 – 明示的拒否
1. ポリシー ARN がエラーメッセージで指定されている場合は、指定されたセッションポリシーでこのアクションの `Deny` ステートメントをチェックします。以下の例では、アクションは `codedeploy:ListDeployments` です。
1. エラーメッセージでポリシー ARN が指定されていない場合は、セッションポリシーでこのアクションの `Deny` ステートメントをチェックします。
1. `Deny` ステートメントを削除して、セッションポリシーを更新してください。詳細については、「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」と「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
ポリシー ARN を含むエラーメッセージ
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codedeploy:ListDeployments
on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:*
with an explicit deny in a session policy: arn:aws:iam::123456789012:policy/DeveloperSessionPolicy
```
ポリシー ARN を含まないエラーメッセージ
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: codedeploy:ListDeployments
on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:*
with an explicit deny in a session policy
```
### リソースベースのポリシーによるアクセスの拒否 – 暗黙的な拒否
1. リソースベースのポリシーにあるアクションで、`Allow` ステートメントが欠落してないかを確認してください。次の例では、`secretsmanager:GetSecretValue` がアクションです。
1. `Allow` ステートメントを追加して、ポリシーを更新してください。詳細については、「[リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)」と「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: secretsmanager:GetSecretValue
because no resource-based policy allows the secretsmanager:GetSecretValue action
```
### リソースベースのポリシーによるアクセスの拒否 – 明示的拒否
1. リソースベースのポリシーにあるアクションで、明示的な `Deny` ステートメントがあるのかを確認してください。次の例では、`secretsmanager:GetSecretValue` がアクションです。
1. `Deny` ステートメントを削除して、ポリシーを更新してください。詳細については、「[リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)」と「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: secretsmanager:GetSecretValue
on resource: arn:aws:secretsmanager:us-east-1:123456789012:secret:*
with an explicit deny in a resource-based policy
```
### ロール信頼ポリシーによるアクセスの拒否 – 暗黙的な拒否
1. ロール信頼ポリシーにあるアクションで、`Allow` ステートメントが欠落していないかを確認してください。次の例では、`sts:AssumeRole` がアクションです。
1. `Allow` ステートメントを追加して、ポリシーを更新してください。詳細については、「[リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)」と「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: sts:AssumeRole
because no role trust policy allows the sts:AssumeRole action
```
### ロール信頼ポリシーによるアクセスの拒否 – 明示的拒否
1. ロール信頼ポリシーにあるアクションで、明示的な `Deny` ステートメントがあるのかを確認してください。次の例では、`sts:AssumeRole` がアクションです。
1. `Deny` ステートメントを削除して、ポリシーを更新してください。詳細については、「[リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)」と「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
```
User: arn:aws:iam::123456789012:user/John is not authorized to perform: sts:AssumeRole
with an explicit deny in the role trust policy
```
### ID ベースのポリシーによるアクセスの拒否 – 暗黙的な拒否
1. ID にアタッチされた ID ベースのポリシーにあるアクションに対して、`Allow` ステートメントが欠落していないかを確認してください。次の例では、ロール `HR` にアタッチされた `codecommit:ListRepositories` がアクションです。
1. `Allow` ステートメントを追加して、ポリシーを更新してください。詳細については、「[アイデンティティベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based)」と「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
```
User: arn:aws:iam::123456789012:role/HR is not authorized to perform: codecommit:ListRepositories
because no identity-based policy allows the codecommit:ListRepositories action
```
### ID ベースのポリシーによるアクセスの拒否 – 明示的な拒否
1. ポリシー ARN がエラーメッセージで指定されている場合は、指定されたポリシーでこのアクションの `Deny` ステートメントをチェックします。以下の例では、アクションは `codedeploy:ListDeployments` です。
1. エラーメッセージでポリシー ARN が指定されていない場合は、この ID にアタッチされた ID ベースのポリシーでこのアクションの `Deny` ステートメントをチェックします。
1. `Deny` ステートメントを削除して、ポリシーを更新してください。詳細については、「[アイデンティティベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based)」と「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。
ポリシー ARN を含むエラーメッセージ
```
User: arn:aws:iam::123456789012:role/HR is not authorized to perform: codedeploy:ListDeployments
on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:*
with an explicit deny in an identity-based policy: arn:aws:iam::123456789012:policy/HRAccessPolicy
```
ポリシー ARN を含まないエラーメッセージ
```
User: arn:aws:iam::123456789012:role/HR is not authorized to perform: codedeploy:ListDeployments
on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:*
with an explicit deny in an identity-based policy
```
# ルートユーザーに関する問題をトラブルシューティングする
ここに記載する情報は、AWS アカウント のルートユーザーに関係する問題のトラブルシューティングに役立ちます。
**注記**
AWS Organizations を使用した AWS アカウント の管理により、メンバーアカウントのために[一元的なルートアクセス](id_root-user.md#id_root-user-access-management)が有効になる場合があります。これらのメンバーアカウントはルートユーザー認証情報を持っておらず、ルートユーザーとしてサインインできず、ルートユーザーのパスワードをリカバリできません。ルートユーザー認証情報を必要とするタスクを実行する必要がある場合は、管理者に問い合わせてください。
## アカウントルートユーザーとしてサインインしたときに実行できると期待されるタスクを実行できない
アカウントは、AWS Organizations 内の組織のメンバーになることができます。組織の管理者は、サービスコントロールポリシー (SCP) を使用してアカウントのアクセス許可を制限できます。SCP は、ルートユーザーを含めすべてのユーザーに影響を与えます。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_type-auth.html)」を参照してください。
## AWS アカウント のルートユーザーパスワードを忘れてしまった
ルートユーザーであり、AWS アカウント アカウントのパスワードを紛失または忘れた場合は、パスワードをリセットできます。AWS アカウント の作成に使用した E メールアドレスを把握し、E メールアカウントへのアクセス権限を持っている必要があります。詳細については、「[紛失または忘れたルートユーザーのパスワードをリセットする](reset-root-password.md)」を参照してください。
## AWS アカウント アカウントの E メールにアクセスできない
AWS アカウント を作成する際に E メールアドレスとパスワードを指定します。これらは、AWS アカウントのルートユーザー の認証情報です。AWS アカウント に関連付けられているメールアドレスが不明な場合、`@signin.aws` または `@verify.signin.aws` から、AWS アカウント を開くために使用された可能性のある、組織のメールアドレスとの間で送受信されたメッセージを検索します。
E メールアドレスがわかっているのにその E メールにアクセスできなくなった場合は、E メールへのアクセスを回復してみます。次のいずれかのオプションを使用して、E メールへのアクセスを回復します。
+ E メールアドレスのドメインを所有している場合は、削除した E メールアドレスを復元できます。または、E メールアカウントのキャッチオールをセットアップできます。キャッチオールは、メールサーバーに存在しなくなった E メールアドレスに送信されたすべてのメッセージを収集して、別の E メールアドレスにリダイレクトします。
+ アカウントの E メールアドレスが企業 E メールシステムの一部である場合は、IT システム管理者に連絡することをお勧めします。管理者は、E メールへのアクセス許可の回復を支援できる可能性があります。
それでも AWS アカウント にサインインできない場合、[[Contact us]](https://aws.amazon.com/contact-us/) (お問い合わせ) で代替サポートオプションを見つけることができます。
# IAM ポリシーをトラブルシューティングする
[ポリシー](access_policies.md)は、ID やリソースにアタッチされるとそれらのアクセス許可を定義する、AWS のエンティティです。AWS は、ユーザーなどのプリンシパルがリクエストを行うときに、これらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。ポリシーは*アイデンティティベースのポリシー*としてプリンシパルにアタッチされるか、*リソースベースのポリシー*としてリソースにアタッチされた JSON ドキュメントとして AWS に保存されます。IAM グループ、ユーザー、ロールなどのプリンシパル (またはアイデンティティ) に、アイデンティティベースのポリシーをアタッチできます。アイデンティティベースのポリシーには、AWS 管理ポリシー、カスタマー管理ポリシー、およびインラインポリシーがあります。AWS マネジメントコンソール で、[**Visual**] および [**JSON**] エディタオプションの両方を使用してカスタマー管理ポリシーの作成と編集ができます。AWS マネジメントコンソールでポリシーを表示すると、そのポリシーによって付与されたアクセス許可の概要を表示できます。ビジュアルエディタとポリシー概要を使用して、IAM ポリシーの管理中に発生した一般的なエラーの診断と修正に役立てることができます。
すべての IAM ポリシーは、[JavaScript Object Notation](http://www.json.org) (JSON) のルールで始まる構文を使用して保存されることに注意してください。ポリシーを作成または管理するために、この構文を理解する必要はありません。AWS マネジメントコンソールのビジュアルエディタを使用してポリシーを作成または編集できます。IAM ポリシーでの JSON 構文の詳細については、「[IAM JSON ポリシー言語の文法](reference_policies_grammar.md)」を参照してください。
**IAM ポリシーのトラブルシューティングに関するトピック**
+ [ビジュアルエディタを使用したトラブルシューティング](#troubleshoot_policies-viseditor)
+ [ポリシーの再構成](#troubleshoot_viseditor-restructure)
+ [ビジュアルエディタでのリソース ARN の選択](#troubleshoot_policies-resource-arn)
+ [ビジュアルエディタでのアクセス許可の拒否](#troubleshoot_policies-switch-deny)
+ [ビジュアルエディタで複数のサービスの指定](#troubleshoot_policies-multiple-services)
+ [ビジュアルエディタでのポリシーサイズの縮小](#troubleshoot_policy-size)
+ [ビジュアルエディタでの認識されないサービス、アクション、またはリソースタイプの修正](#troubleshoot_policies-unrecognized-visual)
+ [ポリシーの概要に関するトラブルシューティング](#troubleshoot_policies-polsum)
+ [欠落しているポリシーの概要](#missing-policy-summary)
+ [ポリシー概要に認識されないサービス、アクション、リソースタイプが含まれる](#unrecognized-services-actions)
+ [サービスが IAM ポリシー概要をサポートしていない](#unsupported-services-actions)
+ [使用するポリシーが予期するアクセス許可を付与しない](#policy-summary-not-grant-permissions)
+ [ポリシー管理のトラブルシューティング](#troubleshoot_policies-policy-manage)
+ [IAM アカウントでのポリシーのアタッチまたはデタッチ](#troubleshoot_roles_cant-attach-detach-policy)
+ [アクティビティに基づいて IAM アイデンティティのポリシーを変更する](#troubleshoot_change-policies-based-on-activity)
+ [JSON ポリシードキュメントのトラブルシューティング](#troubleshoot_policies-json)
+ [ポリシーの検証](#usepolicyvalidation)
+ [JSON エディタでポリシー検証のアクセス許可がありません](#nopermsforpolicyvalidation)
+ [複数の JSON ポリシーオブジェクト](#morethanonepolicyblock)
+ [複数の JSON Statement 要素](#morethanonestatement)
+ [JSON Statement 要素内の複数の Effect、Action、Resource 要素](#duplicateelement)
+ [JSON Version 要素の欠落](#missing-version)
## ビジュアルエディタを使用したトラブルシューティング
カスタマー管理ポリシーを作成または編集するときには、[**ビジュアル**] エディタの情報を使用して、ポリシーのエラーのトラブルシューティングに役立てることができます。ビジュアルエディタを使用してポリシーを作成する方法の例については、「[アイデンティティへのアクセスコントロール](access_controlling.md#access_controlling-identities)」を参照してください。
### ポリシーの再構成
ポリシーを作成すると、AWS はポリシーを検証、処理、変換してから保存します。AWS は、ポリシーを取得すると、アクセス許可を変更することなく、人が読める形式に戻します。そのため、ポリシービジュアルエディタや **[JSON]** タブに表示される内容に違いが生じることがあります。
+ ビジュアルエディタでアクセス許可ブロックの追加、削除、または順序変更ができるほか、ブロック内のコンテンツを最適化できます。
+ [**JSON**] タブで、重要でない空白は削除でき、JSON マップ内の要素は順序を変更できます。さらに、プリンシパル要素内の AWS アカウント ID は AWS アカウントのルートユーザー の Amazon リソースネーム (ARN) に置き換えることができます。
このような変更の可能性があるため、JSON ポリシードキュメントを文字列として比較しないでください。
AWS マネジメントコンソール でカスタマー管理ポリシーを作成するときに、[**JSON**] エディタで操作が完結するように選択できます。**[Visual]** エディタでポリシーを変更することなく、**[JSON]** エディタから **[次へ]** を選択すると、ポリシーが再構成される可能性は低くなります。**[Visual]** エディタを使用すると、IAM が外観に合わせてポリシーを再構築する可能性があります。この再構成は編集セッション内のみに存在するものであり、自動的には保存されません。
編集セッションでポリシーが再構成された場合、IAM は次の状況に基づいて再構成を保存するかどうかを決定します。
| このエディターオプションの使用 | ポリシーを編集する場合 | 次に、このタブから [**次へ**] を選択します | [***変更の保存***] を選択する場合 |
| --- | --- | --- | --- |
| Visual | 編集されます | Visual | ポリシーが再構成されます |
| Visual | 編集されます | JSON | ポリシーが再構成されます |
| Visual | 編集されません | Visual | ポリシーが再構成されます |
| JSON | 編集されます | Visual | ポリシーが再構成されます |
| JSON | 編集されます | JSON | ポリシー構造は変更されません |
| JSON | 編集されません | JSON | ポリシー構造は変更されません |
IAM は、複雑なポリシーや、複数のサービス、リソースタイプ、または条件キーを許可するアクセス許可ブロックまたはステートメントを持つポリシーを再構成する場合があります。
### ビジュアルエディタでのリソース ARN の選択
ビジュアルエディタを使用してポリシーを作成または編集するときは、最初にサービスを選択し、そのサービスからアクションを選択する必要があります。選択したサービスとアクションが[特定のリソース](access_controlling.md#access_controlling-resources)の選択をサポートしている場合、ビジュアルエディタに、サポートされるリソースタイプが一覧表示されます。次に、[**Add ARN (ARN の追加)**] を選択して、リソースの詳細を提供できます。リソースタイプの ARN を追加するために、以下のオプションから選択できます。
+ **ARN ビルダーの使用** – リソースタイプによっては、ARN の構築に必要な各種フィールドが表示されます。[**Any (任意)**] を選択して、指定した設定の任意の値に対するアクセス許可を付与することもできます。たとえば、Amazon EC2 の [**Read (読み取り)**] アクセスレベルグループを選択した場合、ポリシーのアクションは `instance` リソースタイプをサポートします。リソースの **[リージョン]**、**[アカウント]**、**[インスタンス ID]** の値を指定します。アカウント ID を指定し、[リージョン] と [インスタンス ID] に **[任意]** を選択した場合、このポリシーに従ってアカウント内のインスタンスにアクセス許可が付与されます。
+ **ARN の入力または貼り付け** – [Amazon リソースネーム (ARN)](reference_identifiers.md#identifiers-arns) によりリソースを指定できます。ワイルドカード文字 (**\$1**) を ARN の任意のフィールドに含めることができます (コロンの各ペアの間)。詳細については、「[IAM JSON ポリシー要素Resource](reference_policies_elements_resource.md)」を参照してください。
### ビジュアルエディタでのアクセス許可の拒否
デフォルトでは、ビジュアルエディタを使用して作成するポリシーにより、選択したアクションが許可されます。その代わりに選択したアクションを拒否するには、[**Switch to deny permissions (アクセス許可の拒否に切り替え)**] を選択します。リクエストがデフォルトでは拒否されるため、ユーザーが必要とするアクションとリソースにのみアクセス許可を付与することをお勧めします。別のステートメントまたはポリシーによって個別に許可されるアクセス許可をオーバーライドする場合にのみ、拒否ステートメントを作成する必要があります。これにより、アクセス許可のトラブルシューティングがより困難になる可能性があるため、拒否ステートメントの数は最小限に制限することをお勧めします。IAM がポリシーのロジックを評価する方法の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。
**注記**
デフォルトでは、AWS アカウントのルートユーザー のみが、そのアカウントのすべてのリソースにアクセスできます。ワイルドカード文字 () を ARN の任意のフィールドに含めることができます (コロンの各ペアの間)。
### ビジュアルエディタで複数のサービスの指定
ビジュアルエディタを使用してポリシーを作成するときに、一度に 1 つのサービスのみを選択できます。これは、その後ビジュアルエディタではその 1 つのサービス用のアクションから選択できるため、ベストプラクティスとなります。次に、そのサービスと選択されたアクションでサポートされているリソースから選択できます。これにより、ポリシーの作成とトラブルシューティングが容易になります。
また、ワイルドカード文字 (\$1) を使用して、複数のサービスを手動で指定することもできます。たとえば、「**Code\$1**」と入力すると、`CodeBuild` や `CodeCommit` など、`Code` で始まるすべてのサービスに対するアクセス許可を付与できます。ただし、次にアクションとリソースの ARN を入力して、ポリシーを完了する必要があります。さらに、ポリシーを保存すると、各サービスが別のアクセス許可ブロックに含まれるように、ポリシーが[再構成](#troubleshoot_viseditor-restructure)される場合があります。
または、JSON 構文 (ワイルドカードなど) をサービスに使用するには、[**JSON**] エディタオプションを使用してポリシーを作成、編集、保存します。
### ビジュアルエディタでのポリシーサイズの縮小
ビジュアルエディタを使用してポリシーを作成する場合、IAM はポリシーを保存する JSON ドキュメントを作成します。このドキュメントを表示するには、[**JSON**] エディタオプションに切り替えます。この JSON ドキュメントがポリシーのサイズ制限を超える場合、ビジュアルエディタにエラーメッセージが表示されます。ポリシーを確認してから保存することはできません。管理ポリシーのサイズの IAM 制限を表示する方法については、「[IAM 文字制限および STS 文字制限](reference_iam-quotas.md#reference_iam-quotas-entity-length)」を参照してください。
ビジュアルエディタでポリシーのサイズを減らすには、ポリシーを編集するか、アクセス許可ブロックを別のポリシーに移動します。エラーメッセージには、ポリシードキュメントに含まれている文字の数が記載されています。この情報を使用すると、ポリシーのサイズを小さくすることができます。
### ビジュアルエディタでの認識されないサービス、アクション、またはリソースタイプの修正
ポリシーに認識されないサービスやアクションやリソースタイプが含まれているという警告が、ビジュアルエディタに表示されることがあります。
**注記**
IAM は、ポリシー概要をサポートするサービスの名前、アクション、リソースタイプを確認します。ただし、ポリシー概要には、存在しないリソース値または条件が含まれる可能性があります。必ず [Policy Simulator](access_policies_testing-policies.md) でポリシーをテストしてください。
ポリシーに認識されないサービス、アクション、またはリソースタイプが含まれている場合は、以下のいずれかのエラーが発生しています。
+ **プレビューサービス** – プレビュー中のサービスはビジュアルエディタをサポートしていません。プレビューに参加している場合、ポリシーを完了するには、アクションとリソースの ARN を手動で入力する必要があります。警告を無視して操作を続けてもかまいません。または、[**JSON**] エディタオプションを選択して、JSON ポリシードキュメントを入力または貼り付けることができます。
+ **カスタムサービス** – カスタムサービスはビジュアルエディタをサポートしていません。カスタムサービスを使用している場合、ポリシーを完了するには、アクションとリソースの ARN を手動で入力する必要があります。警告を無視して操作を続けてもかまいません。または、[**JSON**] エディタオプションを選択して、JSON ポリシードキュメントを入力または貼り付けることができます。
+ **サービスがビジュアルエディタをサポートしていない** – ポリシーにビジュアルエディタをサポートしていない一般公開された (GA) サービスが含まれている場合、ポリシーを完了するには、アクションとリソースの ARN を手動で入力する必要があります。警告を無視して操作を続けてもかまいません。または、[**JSON**] エディタオプションを選択して、JSON ポリシードキュメントを入力または貼り付けることができます。
一般公開されたサービスとは、プレビューやカスタムサービスではない、一般にリリースされたサービスです。認識されないサービスが一般公開されていて、名前のスペルが正しくない場合、そのサービスはビジュアルエディタをサポートしません。GA サービスに対するビジュアルエディタまたはポリシー概要のサポートをリクエストする方法については、「[サービスが IAM ポリシー概要をサポートしていない](#unsupported-services-actions)」を参照してください。
+ **アクションがビジュアルエディタをサポートしていない** – ポリシーに含まれるサービスがサポートされていても、アクションがサポートされていない場合、ポリシーを完了するには、リソースの ARN を手動で入力する必要があります。警告を無視して操作を続けてもかまいません。または、[**JSON**] エディタオプションを選択して、JSON ポリシードキュメントを入力または貼り付けることができます。
ポリシーに含まれるサービスがサポートされていても、アクションがサポートされていない場合、そのサービスはビジュアルエディタを一部サポートしません。GA サービスに対するビジュアルエディタまたはポリシー概要のサポートをリクエストする方法については、「[サービスが IAM ポリシー概要をサポートしていない](#unsupported-services-actions)」を参照してください。
+ **リソースタイプがビジュアルエディタをサポートしていない** – ポリシーに含まれるアクションがサポートされていても、リソースタイプがサポートされていない場合は、警告を無視して続行できます。ただし、IAM は、選択したすべてのアクションのリソースを含めたことを確認できないため、追加の警告が表示されることがあります。
+ **タイプミス** – ビジュアルエディタでサービス、アクション、またはリソースを手動で入力するときに、タイプミスを含むポリシーを作成する可能性があります。サービスとアクションのリストからビジュアルエディタを選択して使用することをお勧めします。次に、画面の指示に従ってリソースセクションを完了します。サービスがビジュアルエディタを完全にサポートしていない場合は、ポリシーの一部を手動で入力しなければならないことがあります。
ポリシーに、確実に上記のエラーが含まれていない場合は、ポリシーにタイプミスが含まれている可能性があります。次の点を確認します。
+ `s3` ではなく `s2`、`ListAllMyBuckets` ではなく `ListMyBuckets` というように、サービス、アクション、リソースタイプの名前にスペルミスがある
+ `arn:aws:s3: : :*` のように ARN に不要なテキストがある
+ `iam.CreateUser` のようにアクションにコロンがない
タイプミスの可能性があるポリシーを評価する場合は、**[次へ]** を選択してポリシーの概要を確認します。次に、ポリシーで目的のアクセス許可が付与されるかどうかを確認します。
## ポリシーの概要に関するトラブルシューティング
ポリシー概要に関連する問題を診断して解決できます。
### 欠落しているポリシーの概要
IAM コンソールには、ポリシー内の各サービスに対して許可または拒否されるアクセスレベル、リソース、条件を定義する*ポリシー概要*テーブルが含まれます。ポリシーは、[ポリシー概要](access_policies_understand-policy-summary.md)、[サービス概要](access_policies_understand-service-summary.md)、[アクション概要](access_policies_understand-action-summary.md)の 3 つのテーブルにまとめられています。*ポリシー概要*テーブルには、選択したポリシーによって定義されているサービスとアクセス許可の概要のリストが含まれます。エンティティにアタッチされているポリシーの[ポリシーの概要](access_policies_understand.md)は、そのポリシーの [**ポリシーの詳細**] ページで表示できます。[**ポリシー**] ページで、管理ポリシーのポリシー概要を表示できます。AWS がポリシーの概要を示すことができない場合は、JSON ポリシードキュメントと次のエラーが表示されます。
**[A summary for this policy cannot be generated.] (このポリシー概要を生成できません。) [You can still view or edit the JSON policy document.]** (JSON ポリシードキュメントは引き続き表示または編集できます。)
ポリシーに要約が含まれていない場合は、次のいずれかのエラーが発生しています。
+ **サポート対象外のポリシー要素** – IAM では、以下の[ポリシー要素](reference_policies_elements.md)のうちいずれかを含むポリシー概要の生成がサポートされていません。
+ `Principal`
+ `NotPrincipal`
+ `NotResource`
+ **ポリシーのアクセス許可なし** – ポリシーによって有効なアクセス許可が付与されない場合、ポリシー概要を生成できません。たとえば、ポリシーに含まれる 1 つのステートメントでエレメント `"NotAction": "*"` がある場合です。この場合、すべてのアクション (\$1) を除くすべてのアクションへのアクセスを許可しています。つまり、`Deny` または `Allow` のいずれにもアクセスを付与しません。
**注記**
`NotPrincipal`、`NotAction`、`NotResource` など、これらのポリシー要素は慎重に使用してください。ポリシーエレメントの使用に関する詳細については、「[IAM JSON ポリシー要素のリファレンス](reference_policies_elements.md)」を参照してください。
サービスとリソースが一致していないと、せっかくポリシーを作成しても効果的なアクセス許可を付与できません。例えば、アクションとリソースをそれぞれの別のサービスから指定した場合です。この場合は、ポリシー概要が表示されます。概要のリソース列に別のサービスのリソースが含まれていることからしか、問題があることはわかりません。この列に不一致のリソースが含まれる場合は、ポリシーのエラーを確認する必要があります。ポリシーの理解が深まるよう、[Policy Simulator](access_policies_testing-policies.md) でポリシーをテストします。
### ポリシー概要に認識されないサービス、アクション、リソースタイプが含まれる
IAM コンソールの[ポリシー概要](access_policies_understand.md)に警告記号 (![\[Warning hazard sign icon with yellow triangle background.\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/console-alert-icon.console.png)) が表示されている場合、認識されないサービスやアクションやリソースタイプがポリシーに含まれている可能性があります。ポリシー概要内での警告については、「[ポリシー概要 (サービスの一覧)](access_policies_understand-policy-summary.md)」を参照してください。
**注記**
IAM によって、ポリシー概要をサポートするサービスの名前、アクション、リソースタイプが確認されます。ただし、ポリシー概要には、存在しないリソース値または条件が含まれる可能性があります。必ず [Policy Simulator](access_policies_testing-policies.md) でポリシーをテストしてください。
ポリシーに認識されないサービス、アクション、またはリソースタイプが含まれている場合は、以下のいずれかのエラーが発生しています。
+ **プレビューサービス** – プレビュー中のサービスはポリシー概要をサポートしていません。
+ **カスタムサービス** – カスタムサービスはポリシー概要をサポートしていません。
+ **サービスが概要をサポートしていない** – Iポリシー概要をサポートしていない一般公開された (GA) サービスがポリシーに含まれる場合、そのサービスはポリシー概要テーブルの [**Unrecognized services (認識されないサービス)**] セクションに含まれます。一般公開されたサービスとは、プレビューやカスタムサービスではない、一般にリリースされたサービスです。認識されないサービスが一般公開されていて、名前のスペルが正しくない場合、そのサービスは IAM ポリシー概要をサポートしません。GA サービスに対するポリシー概要のサポートをリクエストする方法については、「[サービスが IAM ポリシー概要をサポートしていない](#unsupported-services-actions)」を参照してください。
+ **アクションが概要をサポートしていない** – ポリシーに含まれるサービスがサポートされていても、アクションがサポートされていない場合、そのアクションはサービス概要テーブルの [**Unrecognized actions (認識されないアクション)**] セクションに含まれます。サービス概要内での警告については、「[サービス概要 (アクションのリスト)](access_policies_understand-service-summary.md)」を参照してください。
+ **リソースタイプが概要をサポートしていない** – ポリシーに含まれるアクションがサポートされていても、リソースタイプがサポートされていない場合、そのリソースはサービス概要テーブルの [**認識されないリソースタイプ**] セクションに含まれます。サービス概要内での警告については、「[サービス概要 (アクションのリスト)](access_policies_understand-service-summary.md)」を参照してください。
+ **タイプミス** – AWS は、JSON が構文的に正しいこと、およびポリシーにタイプミスや[ポリシーの検証](access_policies_policy-validator.md)の一部としてのその他のエラーが含まれていないことをチェックします。
**注記**
[ベストプラクティス](best-practices.md)として、IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保することをお勧めします。既存のポリシーを開き、ポリシーの検証レコメンデーションを確認して解決することをお勧めします。
### サービスが IAM ポリシー概要をサポートしていない
IAM ポリシーの概要やビジュアルエディタが一般公開されている (GA) サービスやアクションをサポートしていない可能性があります。一般公開されたサービスとは、プレビューやカスタムサービスではない、一般にリリースされたサービスです。認識されないサービスが一般公開されていて、名前のスペルが正しくない場合、そのサービスはこれらの機能をサポートしません。ポリシーに含まれるサービスがサポートされていても、アクションがサポートされていない場合、そのサービスは IAM ポリシー概要を一部サポートしません。
**IAM ポリシー概要またはビジュアルエディタのサポートがサービスに追加されるようにリクエストするには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. サポートされていないサービスを含むポリシーを特定する
+ ポリシーが管理ポリシーの場合は、ナビゲーションペインの [**ポリシー**] を選択します。ポリシーの一覧で、表示するポリシーの名前を選択します。
+ ポリシーが、ユーザーにアタッチされているインラインポリシーの場合は、ナビゲーションペインの [**ユーザー**] を選択します。ユーザーのリストから、ポリシーを表示するユーザーを選択します。ユーザーのポリシーのテーブルで、表示するポリシー概要のヘッダーを展開します。
1. AWS マネジメントコンソール のフッターの左側にある [**Feedback (フィードバック)**] を選択します。[**IAM へのフィードバック**] ボックスに、**I request that the service add support for IAM policy summaries and the visual editor** と入力します。複数のサービスで概要をサポートする場合は、「**I request that the , , and services add support for IAM policy summaries and the visual editor**」と入力します。
**サービスの欠落したアクション向けに IAM ポリシー概要のサポートが適用されるようにリクエストするには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. サポートされていないサービスを含むポリシーを特定する
+ ポリシーが管理ポリシーの場合は、ナビゲーションペインの [**ポリシー**] を選択します。ポリシーの一覧で、表示するポリシーの名前を選択します。
+ ポリシーが、ユーザーにアタッチされているインラインポリシーの場合は、ナビゲーションペインの [**ユーザー**] を選択します。ユーザーのリストから、ポリシーを表示するユーザーを選択します。ユーザーのポリシーのテーブルで、ポリシー概要を展開するために表示するポリシー名を選択します。
1. ポリシー概要で、サポートされていないアクションを含むサービスの名前を選択します。
1. AWS マネジメントコンソール のフッターの左側にある [**Feedback (フィードバック)**] を選択します。[**IAM へのフィードバック**] ボックスに、**I request that the service add IAM policy summary and the visual editor support for the action** と入力します。サポートされていない複数のアクションをレポートする場合は、「**I request that the service add IAM policy summary and the visual editor support for the , , and actions**」と入力します。
不足しているアクションを別のサービスに含めるようにリクエストするには、最後の 3 つの手順を繰り返します。
### 使用するポリシーが予期するアクセス許可を付与しない
ユーザー、グループ、ロール、リソースにアクセス許可を割り当てるには、*ポリシー*を作成します。このポリシーは、アクセス許可を定義したドキュメントです。ポリシードキュメントには以下の要素が含まれます。
+ **Effect** – ポリシーがアクセスを許可または拒否するかどうか
+ **Action** – ポリシーによって許可または拒否されるアクションのリスト
+ **Resource** – アクションを起こすことができるリソースのリスト
+ **Condition** (オプション) ポリシーがアクセス許可を付与する状況
これらのポリシーのエレメントの詳細または他のエレメントについては「[IAM JSON ポリシー要素のリファレンス](reference_policies_elements.md)」を参照してください。
アクセスを許可するには、サポートされたリソースでポリシーにアクションを定義する必要があります。ポリシーに条件も含まれている場合は、条件に[グローバル条件キー](reference_policies_condition-keys.md)が含まれている必要があります。または、条件をアクションに適用する必要があります。アクションでサポートされているリソースを確認するには、サービスの [AWS ドキュメント](https://docs.aws.amazon.com/)を参照してください。アクションでサポートされている条件については、「[AWS のサービスのアクション、リソース、および条件キー](reference_policies_actions-resources-contextkeys.html)」を参照してください。
アクセス許可を付与しないアクション、リソース、または条件をポリシーに定義しているかどうかを確認します。[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを使用して、ポリシーの[ポリシー概要](access_policies_understand-policy-summary.md)を表示します。ポリシー概要を使用すると、ポリシーの問題を特定して解決することができます。
次のような理由により、IAM ポリシーで定義されているにもかかわらず、要素がアクセス許可を付与しない場合があります。
+ [**該当するリソースのないアクションが定義されている**](#mismatch_action-no-resource)
+ [**該当するアクションのないリソースが定義されている**](#mismatch_resource-no-action)
+ [**該当するアクションのない条件が定義されている**](#mismatch_condition-no-match)
警告を含むポリシー概要の例を表示するには、「[ポリシー概要 (サービスの一覧)](access_policies_understand-policy-summary.md)」を参照してください。
#### 該当するリソースのないアクションが定義されている
以下のポリシーは、すべての `ec2:Describe*` アクションを定義し、特定のリソースを定義します。すべての `ec2:Describe`アクションにはサポートされるリソースレベルのアクセス許可がないため、アクセスが付与されません。リソースレベルのアクセス許可とは、ポリシーの [`Resource`](reference_policies_elements_resource.md) 要素で [ARN](reference_identifiers.md#identifiers-arns) を使用するリソースをアクションがサポートしていることを意味します。アクションがリソースレベルのアクセス許可をサポートしない場合、ポリシーのステートメントは `*` エレメントでワイルドカード (`Resource`) を使用する必要があります。リソースレベルのアクセス許可をサポートするサービスを確認するには、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "arn:aws:ec2:us-east-2:111122223333:instance/*"
}
]
}
```
------
このポリシーはアクセス許可を指定せず、ポリシー概要には次のエラーが表示されます。
`This policy does not grant any permissions. To grant access, policies must have an action that has an applicable resource or condition.`
このポリシーを修正するには、`*` エレメントに `Resource` を使用する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
}]
}
```
------
#### 該当するアクションのないリソースが定義されている
以下のポリシーは Amazon S3 バケットリソースを定義していますが、そのリソースで実行可能な S3 アクションは含まれていません。このポリシーはすべての Amazon CloudFront アクションに対するフルアクセスも供与しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "cloudfront:*",
"Resource": [
"arn:aws:cloudfront:*",
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
このポリシーではすべての CloudFront アクションに対するアクセス許可が与えられています。しかし、ポリシーが S3 アクションを定義せずに S3 `amzn-s3-demo-bucket` リソースを定義しているために、ポリシー概要では次のように警告されます。
`This policy defines some actions, resources, or conditions that do not provide permissions. To grant access, policies must have an action that has an applicable resource or condition.`
このポリシーを修正して S3 バケットのアクセス許可を与えるために、バケットリソースで実行可能な S3 アクションを定義する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudfront:*",
"s3:CreateBucket",
"s3:ListBucket*",
"s3:PutBucket*",
"s3:GetBucket*"
],
"Resource": [
"arn:aws:cloudfront:*",
"arn:aws:s3:::amzn-s3-demo-bucket"
]
}
]
}
```
------
あるいは、CloudFront アクセス許可のみが提供されるように、S3 リソースを削除してこのポリシーを修正してください。
#### 該当するアクションのない条件が定義されている
以下のポリシーは、S3 プレフィックスが `custom` でバージョン ID が `1234` の場合に、すべての S3 リソースに対して 2 つの Amazon S3 アクションを定義しています。しかし、`s3:VersionId` 条件キーは、オブジェクトバージョンのタグ付けに使用され、定義済みのバケットアクションではサポートされていません。アクションでサポートされている条件については、「[AWS のサービスのアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)」を参照し、条件キーのサービスドキュメントを表示するサービスを選択してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucketVersions",
"s3:ListBucket"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:prefix": [
"custom"
],
"s3:VersionId": [
"1234"
]
}
}
}
]
}
```
------
このポリシーでは `s3:ListBucketVersions` アクションに対するアクセス許可が与えられ、さらに、バケット名に `s3:ListBucket` プレフィックスが含まれている場合、`custom` アクションに対するアクセス許可が与えられています。しかし、定義済みのアクションでは `s3:VersionId` 条件がサポートされていないために、ポリシー概要には次のエラーが表示されます。
`This policy does not grant any permissions. To grant access, policies must have an action that has an applicable resource or condition.`
S3 オブジェクトのバージョンをタグ付けできるようにこのポリシーを修正するには、`s3:VersionId` 条件キーをサポートする S3 アクションを定義する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucketVersions",
"s3:ListBucket",
"s3:GetObjectVersion"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:prefix": [
"custom"
],
"s3:VersionId": [
"1234"
]
}
}
}
]
}
```
------
このポリシーでは、ポリシー内のすべてのアクションと条件に対するアクセス許可が提供されています。それにもかかわらず、ポリシーからはどのアクセス許可もいまだに指定されていません。これは、1 つのアクションで両方の条件に一致しているケースがないためです。この場合は、適用する条件付きの専用アクションが含まれている、個別のステートメントを 2 つ作成する必要があります。
このポリシーを修正するには、次のようにステートメントを 2 つ作成します。最初のステートメントには `s3:prefix` 条件をサポートするアクションが含まれるようにし、2 番目のステートメントには `s3:VersionId` 条件をサポートするアクションが含まれるようにします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucketVersions",
"s3:ListBucket"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:prefix": "custom"
}
}
},
{
"Effect": "Allow",
"Action": "s3:GetObjectVersion",
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:VersionId": "1234"
}
}
}
]
}
```
------
## ポリシー管理のトラブルシューティング
ポリシー管理に関連する問題を診断して解決できます。
### IAM アカウントでのポリシーのアタッチまたはデタッチ
一部の AWS 管理ポリシーはサービスにリンクされています。これらのポリシーは、そのサービス用に作成した[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)でのみ使用されます。IAM コンソールで、**[ポリシー詳細]** ページを表示すると、そのポリシーがサービスにリンクされていることを示すバナーが、そのページに表示されます。このポリシーは IAM 内でユーザー、グループ、またはロールにアタッチできます。サービスにリンクされたロールをサービス用に作成すると、このポリシーは新しいロールに自動的にアタッチされます。ポリシーは必須であるため、サービスにリンクされたロールからポリシーをデタッチすることはできません。
### アクティビティに基づいて IAM アイデンティティのポリシーを変更する
IAM アイデンティティ (ユーザー、グループ、ロール) のポリシーは、アクティビティに基づいて更新することができます。これを行うには、CloudTrail **イベント履歴**でアカウントのイベントを表示します。CloudTrail イベントログには、ポリシーのアクセス許可の変更に使用できる詳細なイベント情報が含まれます。
**ユーザーまたはロールが AWS でアクションを実行しようとしたものの、そのリクエストが拒否されています。**
ユーザーまたはロールにアクションを実行するためのアクセス許可が必要かどうかを検討します。その場合、アクションだけでなく、ポリシーにアクセスしようとしたリソースの ARN を追加することができます。
**ユーザーまたはロールに未使用のアクセス許可があります。**
こうしたアクセス許可をポリシーから削除することを検討してください。ポリシーにより、必要なアクションのみの実行に必要な[最小限の権限](best-practices.md#grant-least-privilege)が付与されていることを確認します。
CloudTrail の使用の詳細については、[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html)の「* CloudTrail コンソールでの CloudTrail イベントの表示*の」を参照してください。
## JSON ポリシードキュメントのトラブルシューティング
JSON ポリシードキュメントに関連する問題を診断して解決できます。
### ポリシーの検証
JSON ポリシーを作成または編集するときに、IAM はポリシー検証を実行し、効果的なポリシーを作成するのに役立ちます。IAM は JSON 構文エラーを識別します。一方、IAM Access Analyzer は、ポリシーをさらに絞り込むのに役立つ推奨事項を含む追加のポリシーチェックを提供します。ポリシーの検証の詳細については、「[IAM ポリシーの検証](access_policies_policy-validator.md)」を参照してください。。IAM Access Analyzer のポリシーチェックと実用的な推奨事項の詳細については、「[IAM Access Analyzer ポリシーの検証](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)」を参照してください。
### JSON エディタでポリシー検証のアクセス許可がありません
AWS マネジメントコンソール で、IAM Access Analyzer ポリシーの検証結果を表示するアクセス許可がない場合、次のエラーが表示されることがあります。
`You need permissions. You do not have the permissions required to perform this operation. Ask your administrator to add permissions.`
このエラーを解決するには、自分に `access-analyzer:ValidatePolicy` アクセス許可を追加するよう管理者に依頼します。
### 複数の JSON ポリシーオブジェクト
IAM ポリシーは、1 つの JSON オブジェクトのみで構成する必要があります。オブジェクトは括弧（\$1 \$1）で囲んで示します。外側のペア内に中括弧 \$1 \$1 を追加で埋め込むことで、JSON オブジェクト内に他のオブジェクトをネストできます。ポリシーでは、中括弧 \$1 \$1 のペアを最も外側に 1 つだけ含める必要があります。以下の例は、最上位に 2 つのオブジェクト (*赤*で示した箇所) が含まれているので誤りです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
{
"Effect":"Allow",
"Action":"ec2:Describe*",
"Resource":"*"
}
}
{
"Statement": {
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
}
```
------
ただし、正しいポリシーの文法を使用して、前述の例の目的を果たすことができます。それぞれに独自の `Statement` エレメントを含む 2 つのポリシーオブジェクトを含める代わりに、1 つの `Statement` エレメントに 2 つのブロックを組み合わせて使用することができます。`Statement` 要素には、以下の例 (**太字**で示した箇所) に示すように 2 つのオブジェクトの配列を値として指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource":"*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
------
### 複数の JSON Statement 要素
このエラーは、一見、前のセクションのバリエーションのように見えますが、構文上はエラーの種類が異なります。次の例には、最上位の 1 ペアの \$1 \$1 で示された 1 つのポリシーオブジェクトのみが存在します。そのオブジェクト内に 2 つの `Statement` 要素が含まれています。
IAM ポリシーには、名前 (`Statement`) の後にコロン、その後に値という形式で構成される 1 つの `Statement` 要素のみを指定する必要があります。`Statement` 要素の値は、\$1\$1 で示され、1 つの `Effect` 要素、1 つの `Action` 要素、および 1 つの `Resource` 要素を含むオブジェクトである必要があります。以下の例は、ポリシーオブジェクト (*赤* で示した箇所) に 2 つの `Statement` 要素が含まれているので誤りです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
},
"Statement": {
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
}
```
------
値のオブジェクトは複数の値がオブジェクトの配列でもかまいません。この問題を解決するには、以下の例 (**太字**で示した箇所) に示すように、2 つの `Statement` 要素を 1 つの要素に合わせます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource":"*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
------
`Statement` 要素の値はオブジェクト配列です。この例の配列は 2 つのオブジェクトで構成され、各オブジェクトに `Statement` エレメントの正しい値が指定されています。配列内の各オブジェクトはカンマで区切ります。
### JSON Statement 要素内の複数の Effect、Action、Resource 要素
`Statement` の名前と値のペアの値側のオブジェクトは 1 つの `Effect` エレメント、1 つの `Action` エレメント、1 つの `Resource` エレメントのみで構成する必要があります。以下のポリシーは、`Statement` 内に `Effect` 要素が 2 つあるので誤りです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Effect": "Allow",
"Action": "ec2:* ",
"Resource": "*"
}
}
```
------
**注記**
ポリシーエンジンでは、新規ポリシーまたは編集済みのポリシーでそのようなエラーを許可することはできません。ただし、ポリシーエンジンは、エンジンが更新される前に保存されたポリシーを引き続き許可します。エラーが存在する既存のポリシーの動作は次のとおりです。
複数の `Effect` エレメント: 最後の `Effect` エレメントのみが確認され、それ以外は無視されます。
複数の `Action` 要素: すべての `Action` 要素が内部的に結合され、単一のリストとして処理されます。
複数の `Resource` 要素: すべての `Resource` 要素が内部的に結合され、単一のリストとして処理されます。
ポリシーエンジンでは、構文 エラーのあるポリシーを保存することはできません。保存する前にポリシー内のエラーを修正してください。[ポリシーの検証](access_policies_policy-validator.md)に関する推奨事項を確認し、それに合わせてポリシーを修正します。
いずれの場合も、解決策は誤って追加した要素を削除することです。`Effect` 要素の場合は簡単です。前述の例で Amazon EC2 インスタンスへのアクセス許可を*拒否*するには、以下のように、ポリシーから `"Effect": "Allow",` の行を削除する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*"
}
}
```
------
重複しているエレメントが `Action` または `Resource` の場合、解決法はより複雑になることがあります。アクセス権限を許可（または拒否）するアクションが複数存在したり、複数のリソースへのアクセスを制御したりすることが必要な場合があります。たとえば、以下の例 (*赤*で示した箇所) は、複数の `Resource` 要素が含まれているので誤りです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
}
```
------
`Statement` エレメントの値オブジェクトに必要なエレメントは、それぞれ 1 つだけ含めることができます。この問題を解決するには、各値を配列に指定します。以下の例は、値オブジェクト形式の配列 (**太字**で示した箇所) を使用して 2 つの異なるリソース要素を 1 つの `Resource` 要素として扱う方法を示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
### JSON Version 要素の欠落
`Version` ポリシー要素は、ポリシーバージョンとは異なります。`Version` ポリシー要素は、ポリシー内で使用され、ポリシー言語のバージョンを定義します。これに対して、ポリシーバージョンは IAM でカスタマー管理ポリシーを変更すると作成されます。変更されたポリシーによって既存のポリシーが上書きされることはありません。代わりに、IAM は管理ポリシーの新しいバージョンを作成します。`Version` ポリシー要素の詳細については、「[IAM JSON ポリシー要素Version](reference_policies_elements_version.md)」を参照してください。ポリシーのバージョンの詳細については、「[IAM ポリシーのバージョニング](access_policies_managed-versioning.md)」を参照してください。
AWS 機能の拡張にともない、この機能をサポートする新しい機能が IAM ポリシーに追加されました。ポリシー構文を更新すると、新しいバージョン番号が含まれている場合があります。ポリシーでポリシー文法の新しい機能を使用する場合は、使用しているバージョンをポリシー解析エンジンに通知する必要があります。デフォルトのポリシーのバージョンは "2008-10-17" です。後から導入されたポリシー機能を使用する場合は、使用する機能をサポートするバージョン番号を指定する必要があります。*必ず*最新のポリシー構文のバージョン番号 (現時点では `"Version": "2012-10-17"`) を指定することをお勧めします。たとえば、次のポリシーは、リソースの ARN でポリシー変数 `${...}` を使用しているので誤りです。ただし、ポリシー変数をサポートするポリシー構文のバージョンが指定されていません (*赤*で表示されています)。
```
{
"Statement":
{
"Action": "iam:*AccessKey*",
"Effect": "Allow",
"Resource": "arn:aws:iam::123456789012:user/${aws:username}"
}
}
```
ポリシーの先頭に `Version` エレメントとその値 `2012-10-17` (ポリシー変数をサポートする IAM API の最初のバージョン) を追加することで、この問題 (**太字**で示した箇所) を解決します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
{
"Action": "iam:*AccessKey*",
"Effect": "Allow",
"Resource": "arn:aws:iam::123456789012:user/${aws:username}"
}
}
```
------
# FIDO セキュリティキーをトラブルシューティングする
この情報を使用して、FIDO2 セキュリティキーを操作するときに発生する可能性がある一般的な問題の診断を行います。
**Topics**
+ [FIDO セキュリティキーを有効にできない](#troubleshoot_mfa-fido-cant-enable)
+ [自分の FIDO セキュリティキーを使用してサインインできない](#troubleshoot_mfa-fido-signin)
+ [FIDO セキュリティキーの紛失または破損した場合](#troubleshoot_mfa-fido-lost)
+ [その他の問題](#troubleshoot_mfa-fido-other-issues)
## FIDO セキュリティキーを有効にできない
IAM ユーザーまたはシステム管理者としてのステータスに応じて、以下の解決策を確認します。
### IAM ユーザー
FIDO セキュリティキーを有効にできない場合は、以下の点を確認します。
+ サポートされている設定を使用しているか?
IAM では、USB、Bluetooth、または NFC 経由でデバイスに接続する FIDO2 セキュリティデバイスをサポートしています。IAM は、TouchID や FaceID などのプラットフォーム認証機能もサポートしています。IAM は Windows Hello のローカルパスキー登録をサポートしていません。パスキーを作成して使用するには、Windows ユーザーは、モバイルデバイスやハードウェアセキュリティキーなどのデバイスのパスキーを使用して別のデバイス (ラップトップなど) にサインインする[クロスデバイス認証](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda)を使用する必要があります。
WebAuthn と AWS で使用できるデバイスとブラウザについては、「[パスキーとセキュリティキーを使用するためのサポートされる設定](id_credentials_mfa_fido_supported_configurations.md)」を参照してください。
+ 任意のブラウザプラグインを使用しているか?
AWS は、WebAuthn ブラウザのサポート WebAuthn を追加するためのプラグインの使用をサポートしていません。代わりに、WebAuthn 標準のネイティブサポートを提供するブラウザを使用します。
サポートされているブラウザを使用している場合でも、そのプラグインが WebAuthn と互換性のない可能性があります。互換性のないプラグインにより、FIDO 準拠のセキュリティキーを有効にして使用できなくなる場合があります。互換性のないプラグインを無効にして、ブラウザを再起動します。その後、FIDO セキュリティキーを再び有効にしてみます。
+ 適切なアクセス許可があるか?
上記の互換性の問題がない場合は、適切なアクセス許可がない可能性があります。システム管理者に連絡してください。
### システム管理者
サポートされている設定を使用しているにかかわらず、IAM ユーザーが FIDO セキュリティキーを有効にできない場合は、そのユーザーのアクセス許可を確認します。詳細例については、「[IAM チュートリアル: ユーザーに自分の認証情報および MFA 設定を許可する](tutorial_users-self-manage-mfa-and-creds.md)」を参照してください。
## 自分の FIDO セキュリティキーを使用してサインインできない
FIDO セキュリティキーを使用して AWS マネジメントコンソールにサインインできない場合は、まず「[パスキーとセキュリティキーを使用するためのサポートされる設定](id_credentials_mfa_fido_supported_configurations.md)」を参照してください。サポートされている設定を使用していてもサインインできない場合は、システム管理者に連絡してください。
## FIDO セキュリティキーの紛失または破損した場合
[現在サポートされている MFA タイプ](https://aws.amazon.com/iam/features/mfa/)を任意に組み合わせた最大 **8** 台の MFA デバイスを 1 人のユーザーに割り当てることができます。複数の MFA デバイスがあっても、AWS マネジメントコンソール にサインインするのに必要なのは 1 台の MFA デバイスだけです。FIDO セキュリティキーを入れ替えることは、ハードウェア TOTP トークンを入れ替えることに似ています。任意のタイプの MFA デバイスを紛失または損傷した場合は、「[IAM 内で MFA で保護された ID を復元する](id_credentials_mfa_lost-or-broken.md)」を参照してください。
## その他の問題
ここで説明されていない FIDO セキュリティキーの問題がある場合は、以下の対処を行います。
+ IAM ユーザー: システム管理者にお問い合わせください。
+ AWS アカウント ルートユーザ: [AWS サポート](https://aws.amazon.com/premiumsupport/)にお問い合わせください。
# IAM ロールをトラブルシューティングする
この情報を使用して、IAM ロールを操作するときに発生する可能性がある一般的な問題の診断や修復を行います。
**Topics**
+ [ロールを引き受けることができない](#troubleshoot_roles_cant-assume-role)
+ [AWS アカウントに新しいロールが表示される](#troubleshoot_roles_new-role-appeared)
+ [自分の AWS アカウント でロールを編集または削除できない](#troubleshoot_roles_cant-edit-delete-role)
+ [次のことを実行する権限がない: iam:PassRole](#troubleshoot_roles_not-auth-passrole)
+ [12 時間のセッションに使用するロールを引き受けることができない (AWS CLI、AWS API)](#troubleshoot_roles_cant-set-session)
+ [IAM コンソールでロールを切り替えようとするとエラーが発生する](#troubleshoot_roles_cant-switch-role-console)
+ [ロールには、アクションの実行を許可するポリシーがあるが、「アクセスが拒否されました」というメッセージが表示される](#troubleshoot_roles_session-policy)
+ [サービスがロールのデフォルトのポリシーバージョンを作成しなかった](#troubleshoot_serviceroles_edited-policy)
+ [コンソールにサービスロールのユースケースがない](#troubleshoot_serviceroles_console-use-case)
## ロールを引き受けることができない
以下をチェックしてください:
+ ロールセッション内でユーザーが現在のロールを再び引き受けることができるようにするには、ロール信頼ポリシーでロール ARN または AWS アカウント ARN をプリンシパルとして指定します。Amazon EC2、Amazon ECS、Amazon EKS、Lambda などのコンピューティングリソースを提供する AWS のサービス は、一時的な認証情報を提供し、これらの認証情報を自動的に更新します。これにより、常に有効な認証情報セットを確保できます。これらのサービスでは、一時的な認証情報を取得するために現在のロールを再度引き受ける必要はありません。ただし、[セッションタグ](id_session-tags.md)または[セッションポリシー](access_policies.md#policies_session)を渡す場合は、現在のロールを再度引き受ける必要があります。ロールの信頼ポリシーを変更してプリンシパルロールの ARN または AWS アカウント ARN を追加する方法については、[ロール信頼ポリシーを更新する](id_roles_update-role-trust-policy.md) を参照してください。
+ AWS マネジメントコンソール を使用してロールを引き受ける場合は、必ずロールの正確な名前を使用してください。ロール名では、ロールを引き受けるときに、大文字と小文字が区別されます。
+ AWS STS API または AWS CLI を使用してロールを引き受ける場合は、必ず ARN のロールの正確な名前を使用してください。ロール名では、ロールを引き受けるときに、大文字と小文字が区別されます。
+ SAML ベースのフェデレーテッド ID プロバイダーを使用してロールを引き受け、SAML 暗号化が有効になっている場合は、SAML ID プロバイダーの有効なプライベート復号キーをアップロードしていることを確認してください。詳細については、「[SAML 暗号化キーの管理](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption)」を参照してください。
+ IAM ポリシーによって、引き受けるロールの `sts:AssumeRole` を呼び出すアクセス許可が付与されていることを確認します。IAM ポリシーの `Action` 要素で、`AssumeRole` アクションの呼び出しを許可する必要があります。さらに、IAM ポリシーの `Resource` 要素で、引き受けるロールを指定する必要があります。たとえば、`Resource` エレメントでは Amazon リソースネーム (ARN) またはワイルドカード (\$1) で、ロールを指定できます。たとえば、ユーザーに該当する 1 つ以上のポリシーで、以下のようなアクセス許可を付与する必要があります。
```
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::account_id_number:role/role-name-you-want-to-assume"
```
+ IAM アイデンティティが、IAM ポリシーで義務付けられている任意のタグでタグ付けされていることを確認します。たとえば、次のポリシーのアクセス許可では、`Condition` 要素で、ロールを引き受けることをリクエストするプリンシパルとして、特定のタグを持っていることを義務付けています。`department = HR` または `department = CS` でタグ付けされている必要があります。それ以外の場合は、ロールを引き受けることはできません。IAM ユーザーおよびロールのタグ付けについては、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。
```
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {"StringEquals": {"aws:PrincipalTag/department": [
"HR",
"CS"
]}}
```
+ ロールの信頼ポリシーで指定されているすべての条件が満たされていることを確認します。1 つの `Condition` で、失効日、外部 ID、またはリクエスト発行元の IP アドレスを定義することができます。次の例では、現在の日付が指定日より後の日付である場合、ポリシーが一致しないため、ロールを引き受けるアクセス権限をユーザーに付与できません。
```
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::account_id_number:role/role-name-you-want-to-assume"
"Condition": {
"DateLessThan" : {
"aws:CurrentTime" : "2016-05-01T12:00:00Z"
}
}
```
+ `AssumeRole` の呼び出し元である AWS アカウント が、引き受けようとしているロールにとって信頼されたエンティティであることを確認します。信頼されたエンティティは、ロールの信頼ポリシーで `Principal` として定義されます。次の例は、引き受けるロールにアタッチされている信頼ポリシーです。この例の場合、サインインに使用した IAM ユーザーのアカウント ID が 123456789012 である必要があります。ロールの信頼ポリシーの `Principal` 要素にアカウント番号が表示されていない場合、ロールを引き受けることはできません。アクセスポリシーでどのようなアクセス許可が付与されているかは関係ありません。サンプルポリシーでは、2017 年 7 月 1 日～2017 年 12 月 31 日 (UTC) (この日付を含む) に発生するアクションのアクセス許可のみ付与できます。これらの日付の前後にログインした場合、ポリシーは一致しないため、ロールを引き受けることはできません。
```
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole",
"Condition": {
"DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"},
"DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"}
}
```
+ **ソース ID** — 管理者は、*ソース ID*と呼ばれる AWS でアクションを実行している個人またはアプリケーションを識別するカスタム文字列を渡すように ID を要求するようにロールを構成できます。引き受けるロールがソース ID を設定する必要があるかどうかを確認します。ソース ID の詳細については、「[引き受けたロールで実行されるアクションのモニタリングと制御](id_credentials_temp_control-access_monitor.md)」を参照してください。
## AWS アカウントに新しいロールが表示される
一部の AWS のサービスでは、サービスに直接リンクされた一意のタイプのサービスロールを使用する必要があります。この[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)はサービスによって事前に定義され、サービスで必要なすべてのアクセス許可が含まれます。これにより、必要なアクセス許可を手動で追加する必要がなくなるため、サービスの設定が簡単になります。サービスにリンクされたロールの一般情報については、「[サービスにリンクされたロールの作成](id_roles_create-service-linked-role.md)」を参照してください。
サービスにリンクされたロールのサポートを開始するときに、既にサービスを使用している可能性があります。その場合、アカウントに新しいロールについて伝える E メールが届くことがあります。このロールには、サービスがお客様に代わってアクションを実行するために必要なすべてのアクセス権限が含まれています。このロールをサポートするために、お客様が実行する必要があるアクションはありません。ただし、アカウントからロールを削除しないでください。ロールを削除すると、サービスが AWS リソースにアクセスするために必要なアクセス許可が削除される可能性があります。アカウントのサービスにリンクされたロールを表示するには、IAM コンソールの IAM **ロール**ページに移動します。サービスにリンクされたロールが、テーブルの **[Trusted entities]** (信頼されたエンティティ) 列の **[(Service-linked role)]** ((サービスにリンクされたロール)) に表示されます。
サービスにリンクされたロールをサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。これらのサービスでは、**[Service-Linked Role]** (サービスにリンクされたロール) 列が、**[Yes]** (はい) になっています。サービスにリンクされたロールをサービスで使用するには、[**Yes (はい)**] リンクを選択します。
## 自分の AWS アカウント でロールを編集または削除できない
IAM の「[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)」のアクセス許可を削除または編集することはできません。これらのロールには、サービスがお客様に代わってアクションを実行するために必要な事前定義された信頼とアクセス許可が含まれます。サービスにリンクされたロールの説明は、IAM コンソール、AWS CLI、API のいずれかでのみ編集できます。アカウントのサービスにリンクされたロールを表示するには、コンソールの IAM **ロール** ページに移動します。サービスにリンクされたロールが、テーブルの **[Trusted entities]** (信頼されたエンティティ) 列の **[(Service-linked role)]** ((サービスにリンクされたロール)) に表示されます。ロールの [**Summary (概要)**] ページのバナーにも、そのロールがサービスにリンクされたロールであることが示されています。サービスでアクションがサポートされている場合、リンクされたサービスを通じてのみこれらのロールを管理および削除できます。サービスにリンクされたロールを変更または削除すると、サービスが AWS リソースにアクセスするために必要なアクセス許可が削除される可能性があるので、注意してください。
サービスにリンクされたロールをサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。これらのサービスでは、**[Service-Linked Role]** (サービスにリンクされたロール) 列が、**[Yes]** (はい) になっています。
## 次のことを実行する権限がない: iam:PassRole
リンクされたサービスロールを作成する場合、サービスにそのロールを渡す権限を持っている必要があります。一部のサービスでは、そのサービスでアクションを実行する際にアカウント内にサービスにリンクされたロールが自動的に作成されます。たとえば Amazon EC2 Auto Scaling では、Auto Scaling グループを初めて作成すると、サービスにリンクされたロール `AWSServiceRoleForAutoScaling` が作成されます。`PassRole` アクセス許可がない状態で Auto Scaling グループを作成しようとすると、以下のようなエラーが表示されます。
`ClientError: An error occurred (AccessDenied) when calling the PutLifecycleHook operation: User: arn:aws:sts::111122223333:assumed-role/Testrole/Diego is not authorized to perform: iam:PassRole on resource: arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling`
このエラーを解決するには、自分に `iam:PassRole` アクセス許可を追加するよう管理者に依頼します。
サービスにリンクされたロールをサポートするサービスを確認するには、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。サービスにリンクされたロールをサービスで作成できるかどうかを確認するには、[**はい**] リンクを選択して、該当サービスのサービスにリンクされたロールに関するドキュメントを確認します。
## 12 時間のセッションに使用するロールを引き受けることができない (AWS CLI、AWS API)
AWS STS `AssumeRole*` API または `assume-role*` CLI オペレーションを使用してロールを引き受ける場合は、`DurationSeconds` パラメータの値を指定できます。900 秒 (15 分) からロールの**最大セッション期間**設定までの値を指定できます。この設定よりも高い値を指定した場合、オペレーションは失敗します。この設定の最大値は 12 時間です。たとえば、12 時間のセッションの期間を指定したが、管理者が最大のセッション期間を 6 時間に設定した場合、オペレーションは失敗します。ロールの最大値を確認する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。
[*ロールの連鎖*](id_roles.md#iam-term-role-chaining) (ロールを使用して 2 つ目のロールを引き受ける) を使用している場合、セッションは最大 1 時間に制限されます。この場合 `DurationSeconds` パラメータを使用して 1 時間より大きい値を指定すると、オペレーションは失敗します。
## IAM コンソールでロールを切り替えようとするとエラーが発生する
[**ロールの切り替え**] ページに入力する情報は、ロールの情報と一致している必要があります。そうでない場合は、オペレーションは失敗し、次のエラーが表示されます。
`Invalid information in one or more fields. Check your information or contact your administrator.`
このエラーが表示された場合は、次の情報が正しいことを確認します。
+ **アカウント ID またはエイリアス** - AWS アカウント ID は 12 桁の数字です。アカウントには、AWS アカウント ID の代わりに使用できる会社名などのわかりやすい識別子であるエイリアスがある場合があります。このフィールドでは、アカウント ID またはエイリアスのいずれかを使用できます。
+ **ロール名** – ロール名では、大文字と小文字が区別されます。アカウント ID とロール名は、ロールに対して設定されているものと一致する必要があります。
引き続きエラーメッセージが表示される場合は、管理者に問い合わせて、以前の情報を確認してください。ロールの信頼ポリシーまたは IAM ユーザーポリシーによって、アクセスが制限される場合があります。管理者は、これらのポリシーのアクセス許可を確認できます。
## ロールには、アクションの実行を許可するポリシーがあるが、「アクセスが拒否されました」というメッセージが表示される
ロールセッションはセッションポリシーによって制限される場合があります。AWS STS を使用してプログラムで[一時的なセキュリティ認証情報をリクエストする](id_credentials_temp_request.md)場合は、オプションでインラインまたは管理[セッションポリシー](access_policies.md#policies_session)を渡すことができます。セッションポリシーは、ロールの一時認証情報セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。`Policy` パラメータを使用して単一の JSON インラインセッションポリシードキュメントを渡すことができます。`PolicyArns` パラメータを使用して、最大 10 個の管理セッションポリシーを指定できます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。または、管理者またはカスタムプログラムから一時的な認証情報が提供されている場合は、アクセスを制限するためのセッションポリシーが含まれている可能性があります。
## サービスがロールのデフォルトのポリシーバージョンを作成しなかった
サービスロールは、サービスがお客様に代わってお客様のアカウントでアクションを実行するために引き受けるロールです。AWS のサービス環境には、セットアップ時にサービスが引き受けるロールを定義する必要があるものもあります。場合によっては、サービスによってサービスロールとそのポリシーが IAM に作成されます。IAM 内でサービスロールとそのポリシーを変更または削除することはできますが、AWS では推奨しません。ロールとポリシーは、そのサービスでのみ使用することを目的としています。ポリシーを編集して別の環境を設定した場合、サービスが同じロールとポリシーを使用しようとすると、オペレーションが失敗する可能性があります。
たとえば、AWS CodeBuild を初めて使用する場合、サービスは `codebuild-RWBCore-service-role` という名前のロールを作成します。このサービスロールは、`codebuild-RWBCore-managed-policy` という名前のポリシーを使用します。ポリシーを編集すると、新しいバージョンが作成され、そのバージョンがデフォルトバージョンとして保存されます。AWS CodeBuild で後続のオペレーションを実行すると、サービスがポリシーの更新を試みることがあります。その場合は、次のエラーが表示されます。
`codebuild.amazon.com did not create the default version (V2) of the codebuild-RWBCore-managed-policy policy that is attached to the codebuild-RWBCore-service-role role. To continue, detach the policy from any other identities and then delete the policy and the role.`
このエラーが表示された場合は、サービスオペレーションを続行する前に IAM で変更を行う必要があります。まず、デフォルトポリシーバージョンを V1 に設定し、オペレーションを再試行します。V1 が以前に削除された場合、または V1 を選択しても機能しない場合は、既存のポリシーとロールをクリーンアップして削除します。
管理ポリシーの編集の詳細については、「[カスタマー管理ポリシーの編集 (コンソール)](access_policies_manage-edit-console.md#edit-customer-managed-policy-console)」を参照してください。ポリシーのバージョンの詳細については、「[IAM ポリシーのバージョニング](access_policies_managed-versioning.md)」を参照してください。
**サービスロールとそのポリシーを削除するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. ナビゲーションペインで、**[ポリシー]** を選択します。
1. ポリシーの一覧で、削除するポリシーの名前を選択します。
1. [**アタッチされたエンティティ**] タブを選択して、このポリシーを使用する IAM ユーザー、グループ、またはロールを表示します。これらの ID のいずれかがポリシーを使用する場合は、次のタスクを実行します。
1. 必要なアクセス許可を持つ新しい管理ポリシーを作成します。アクションの前後に ID が同じアクセス許可を持つようにするには、既存のポリシーから JSON ポリシードキュメントをコピーします。次に、新しい管理ポリシーを作成し、[JSON エディタを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)の説明に従って JSON ドキュメントを貼り付けます。
1. 影響を受ける ID ごとに、新しいポリシーをアタッチしてから、古いポリシーをデタッチします。詳細については、「[IAM ID のアクセス許可の追加および削除](access_policies_manage-attach-detach.md)」を参照してください。
1. ナビゲーションペインで **Roles (ロール) ** を選択してください。
1. ロールのリストで、削除するロールの名前を選択します。
1. [**信頼関係**] タブを選択して、ロールを引き受けることができるエンティティを表示します。サービス以外のエンティティが一覧表示されている場合は、次のタスクを実行します。
1. これらのエンティティを信頼する[新しいロールを作成します](id_roles_create_for-user.md#roles-creatingrole-user-console)。
1. 前のステップで作成したポリシー。このステップを省略した場合は、新しい管理ポリシーをここで作成します。
1. ロールを引き受けていたすべてのユーザーに、もう実行できないことを通知します。新しいロールを引き受ける方法と、同じアクセス許可を持つ方法に関する情報を提供します。
1. [ポリシーを削除します](access_policies_manage-delete-console.md#delete-customer-managed-policy-console)。
1. [ロールを削除します](id_roles_manage_delete.md#roles-managingrole-deleting-console)。
## コンソールにサービスロールのユースケースがない
一部のサービスでは、お客様に代わってアクションを実行するサービスアクセス許可を付与するために、サービスロールを手動で作成する必要があります。サービスが IAM コンソールに表示されない場合は、信頼されたプリンシパルとしてサービスを手動で一覧表示する必要があります。使用しているサービスまたは機能のドキュメントに、信頼されたプリンシパルとしてサービスを一覧表示する手順が含まれていない場合は、ページについてのフィードバックを提供します。
サービスロールを手動で作成するには、そのロールを引き受けるサービスの[サービスプリンシパル](reference_policies_elements_principal.md#principal-services)を知っている必要があります。サービスプリンシパルは、サービスにアクセス許可を付与するために使用される識別子です。サービスプリンシパルはサービスによって定義されます。
次の項目を確認することで、一部のサービスのサービスプリンシパルを検索できます。
1. [IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md) を開きます。
1. サービスの **[Service-linked roles]** (サービスにリンクされたロール) 列に **[Yes]** (はい) が表示されているかどうかを確認します。
1. サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。
1. [サービスプリンシパル](reference_policies_elements_principal.md#principal-services)を表示するには、そのサービスの [Service-Linked Role Permissions] (サービスにリンクされたロールのアクセス許可) のセクションを探します。
[AWS CLI コマンド](id_roles_create_for-service.md#roles-creatingrole-service-cli)または [AWS API オペレーション](id_roles_create_for-service.md#roles-creatingrole-service-api)を使用して、サービスロールを手動で作成できます。IAM コンソールを使用してサービスロールを手動で作成するには、次のタスクを実行します。
1. アカウント ID を使用して IAM ロールを作成します。ポリシーをアタッチしたり、アクセス許可を付与したりしないでください。詳細については、「[IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)」を参照してください。
1. ロールを開き、信頼関係を編集します。ロールはアカウントを信頼する代わりに、サービスを信頼する必要があります。例えば、次の `Principal` 要素を更新します。
```
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
```
プリンシパルをサービスの値 ( IAM など) に変更します。
```
"Principal": { "Service": "iam.amazonaws.com" }
```
1. アクセス許可ポリシーをロールにアタッチして、サービスが必要とするアクセス許可を追加します。
1. アクセス許可を必要とするサービスに戻り、文書化されたメソッドを使用して、新しいサービスロールについてサービスに通知します。
# IAM および Amazon EC2 をトラブルシューティングする
以下の情報は、Amazon EC2 で発生した IAM の問題をトラブルシューティングする際に役立ちます。
**Topics**
+ [インスタンスの起動時に、Amazon EC2 コンソールの **[IAM ロール]** リストにロールが表示されない](#troubleshoot_iam-ec2_missingrole)
+ [インスタンスの認証情報が間違ったロールのものになっている](#troubleshoot_iam-ec2_wrongrole)
+ [`AddRoleToInstanceProfile` を呼び出そうとすると、`AccessDenied` エラーが発生する。](#troubleshoot_iam-ec2_access-denied-adding-role)
+ [Amazon EC2: ロールを使用してインスタンスを起動しようとすると、`AccessDenied` エラーが発生する](#troubleshoot_iam-ec2_access-denied-launch)
+ [EC2 インスタンスにある一時的なセキュリティ認証情報にアクセスできない](#troubleshoot_iam-ec2_no-keys)
+ [IAM サブツリーの `info` ドキュメントのエラーは何を意味しますか?](#troubleshoot_iam-ec2_errors-info-doc)
## インスタンスの起動時に、Amazon EC2 コンソールの **[IAM ロール]** リストにロールが表示されない
以下をチェックしてください:
+ IAM ユーザーとしてサインインしている場合、`ListInstanceProfiles` を呼び出す権限があることを確認します。ロールの操作に必要なアクセス許可については、「[Amazon EC2 でのロールの使用に必要なアクセス許可](id_roles_use_switch-role-ec2.md#roles-usingrole-ec2instance-permissions)」を参照してください。ユーザーに権限を付与する方法の詳細については、「[IAM ポリシーを管理する](access_policies_manage.md)」を参照してください。
自身のアクセス許可を修正できない場合は、IAM を操作できる管理者へ問い合わせてアクセス許可を更新する必要があります。
+ IAM CLI または API を使用してロールを作成した場合は、以下のことを確認してください。
+ インスタンスプロファイルを作成し、そのインスタンスプロファイルにロールを追加していること。
+ ロールとインスタンスプロファイルに同じ名前を使用していること。ロールとインスタンスプロファイルに異なる名前を付けた場合は、Amazon EC2 コンソールに正しいロール名が表示されません。
Amazon EC2 コンソールの [**IAMロール**] リストには、ロール名ではなくインスタンスプロファイル名が表示されます。使用するロールが含まれるインスタンスプロファイルの名前を選択する必要があります。インスタンスプロファイルの詳細については、[インスタンスプロファイルを使用する](id_roles_use_switch-role-ec2_instance-profiles.md) を参照してください。
**注記**
IAM コンソールを使用してロールを作成する場合は、インスタンスプロファイルを使用する必要はありません。IAM コンソールで作成する各ロールでは、ロールと同じ名前のインスタンスプロファイルが作成され、ロールは自動的にそのインスタンスプロファイルに追加されます。インスタンスプロファイルに含めることができる IAM ロールは 1 つのみであり、緩和できません。
## インスタンスの認証情報が間違ったロールのものになっている
インスタンスプロファイルのロールが最近置き換えられている可能性があります。その場合は、アプリケーションは自動的に予定された次回の認証情報の更新を終えてからでなければ、ロールの認証情報にアクセスすることはできません。
変更を強制的に実行するには、[インスタンスプロファイル](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html)の関連付けを解除してから、[インスタンスプロファイルを関連付ける](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html)か、インスタンスを停止してから再起動します。
## `AddRoleToInstanceProfile` を呼び出そうとすると、`AccessDenied` エラーが発生する。
IAM ユーザーとしてリクエストを発行する場合は、以下の条件が満たされていることを確認します。
+ `iam:AddRoleToInstanceProfile` でインスタンスプロファイルの ARN (`arn:aws:iam::999999999999:instance-profile/ExampleInstanceProfile` など) に一致するリソースが定義されている。
ロールの操作に必要なアクセス許可の詳細については、「[使用を開始するには](id_roles_use_switch-role-ec2.md#roles-usingrole-ec2instance-get-started)」を参照してください。ユーザーに権限を付与する方法の詳細については、「[IAM ポリシーを管理する](access_policies_manage.md)」を参照してください。
## Amazon EC2: ロールを使用してインスタンスを起動しようとすると、`AccessDenied` エラーが発生する
以下をチェックしてください:
+ インスタンスプロファイルを使用せずにインスタンスを起動します。この作業は、問題が Amazon EC2 インスタンスの IAM ロールに限定していることを確認するものです。
+ IAM ユーザーとしてリクエストを発行する場合は、以下の条件が満たされていることを確認します。
+ `ec2:RunInstances` でリソースがワイルドカード (\$1) で定義されている
+ `iam:PassRole` でロールの ARN (`arn:aws:iam::999999999999:role/ExampleRoleName` など) に一致するリソースが定義されている
+ IAM `GetInstanceProfile` アクションを呼び出し、有効なインスタンスプロファイル名またはインスタンスプロファイル ARN を使用していることを確認します。詳細については、「[Amazon EC2 インスタンスで IAM ロールを使用する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)」を参照してください。
+ IAM `GetInstanceProfile` アクションを呼び出し、インスタンスプロファイルにロールがあることを確認します。空のインスタンスプロファイルは、`AccessDenied` エラーとなります。ロールの作成に関する詳細については、「[IAM ロールの作成](id_roles_create.md)」を参照してください。
ロールの操作に必要なアクセス許可の詳細については、「[使用を開始するには](id_roles_use_switch-role-ec2.md#roles-usingrole-ec2instance-get-started)」を参照してください。ユーザーに権限を付与する方法の詳細については、「[IAM ポリシーを管理する](access_policies_manage.md)」を参照してください。
## EC2 インスタンスにある一時的なセキュリティ認証情報にアクセスできない
EC2 インスタンスの一時的なセキュリティ認証情報にアクセスするには、まず IAM コンソールを使用してロールを作成する必要があります。次に、そのロールを使用する EC2 インスタンスを起動し、実行中のインスタンスを確認します。詳細については、[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する](id_roles_use_switch-role-ec2.md) の「**開始方法**」を参照してください。
引き続き EC2 インスタンスで一時的なセキュリティ認証情報にアクセスできない場合は、以下を確認してください。
+ インスタンスメタデータサービス (IMDS) の他の部分にアクセスできますか? アクセスできない場合、IMDS への要求アクセスを遮断するファイアウォールのルールがないことを確認します。
```
[ec2-user@domU-12-31-39-0A-8D-DE ~]$ GET http://169.254.169.254/latest/meta-data/hostname; echo
```
+ IMDS の `iam` サブツリーは存在していますか? 存在していない場合、EC2 `DescribeInstances` API オペレーションを呼び出すか、`aws ec2 describe-instances` CLI コマンドを使用して、インスタンスに関連する IAM インスタンスプロファイルがあることを確認します。
```
[ec2-user@domU-12-31-39-0A-8D-DE ~]$ GET http://169.254.169.254/latest/meta-data/iam; echo
```
+ IAM サブツリーの `info` ドキュメントにエラーがあるか確認します。エラーがある場合は、[IAM サブツリーの `info` ドキュメントのエラーは何を意味しますか?](#troubleshoot_iam-ec2_errors-info-doc) をご覧ください。
```
[ec2-user@domU-12-31-39-0A-8D-DE ~]$ GET http://169.254.169.254/latest/meta-data/iam/info; echo
```
## IAM サブツリーの `info` ドキュメントのエラーは何を意味しますか?
### `iam/info` ドキュメントで `"Code":"InstanceProfileNotFound"` が表示される
IAM インスタンスプロファイルが削除され、Amazon EC2 がインスタンスに認証情報を発行できません。有効なインスタンスプロファイルを Amazon EC2 インスタンスにアタッチする必要があります。
その名前が付いたインスタンスプロファイルが存在する場合、そのインスタンスプロファイルが削除されておらず、他のプロファイルが同じ名前で作成されていることを確認します。
1. IAM の `GetInstanceProfile` オペレーションを呼び出し、`InstanceProfileId` を取得します。
1. `DescribeInstances` の Amazon EC2 オペレーションを呼び出し、インスタンスの `IamInstanceProfileId` を取得します。
1. IAM オペレーションで取得した `InstanceProfileId` が Amazon EC2 オペレーションで取得した `IamInstanceProfileId` と一致することを確認します。
ID が異なる場合、インスタンスに付属したインスタンスプロファイルはすでに無効になっています。有効なインスタンスプロファイルをインスタンスにアタッチする必要があります。
### `iam/info` ドキュメントには完了と表示されるが、`"Message":"Instance Profile does not contain a role..."` が表示される
IAM の `RemoveRoleFromInstanceProfile` アクションによりロールがインスタンスプロファイルから削除されています。IAM の `AddRoleToInstanceProfile` アクションを使用すると、インスタンスプロファイルにロールをアタッチすることができます。アプリケーションは、次回に予定された更新を終えてからでなければ、ロールの認証情報にアクセスすることはできません。
変更を強制的に実行するには、[インスタンスプロファイル](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html)の関連付けを解除してから、[インスタンスプロファイルを関連付ける](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html)か、インスタンスを停止してから再起動します。
### `iam/security-credentials/[role-name]` ドキュメントで `"Code":"AssumeRoleUnauthorizedAccess"` が表示される
Amazon EC2 にロールを引き受けるアクセス許可がありません。以下の例のように、ロールを引き受けるアクセス許可は、そのロールにアタッチされた信頼ポリシーで管理されます。IAM `UpdateAssumeRolePolicy` API を使用して、信頼ポリシーを更新します。
------
#### [ JSON ]
****
```
{"Version":"2012-10-17", "Statement": [{"Effect": "Allow","Principal": {"Service": ["ec2.amazonaws.com"]},"Action": ["sts:AssumeRole"]}]}
```
------
アプリケーションは、自動的に予定された次回の更新を終えてからでなければ、ロールの認証情報にアクセスすることはできません。
変更を強制的に実行するには、[インスタンスプロファイル](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html)の関連付けを解除してから、[インスタンスプロファイルを関連付ける](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html)か、インスタンスを停止してから再起動します。
# Amazon S3 と IAM をトラブルシューティングする
この情報を使用して、Amazon S3 および IAM を操作する際に発生する可能性がある問題のトラブルシューティングや修復を行います。
## Amazon S3 バケットへの匿名アクセスを付与する方法
`principal` 要素でワイルドカード (\$1) を指定する Amazon S3 バケットポリシーを使用すると、だれでもバケットにアクセスできるようになります。匿名アクセスでは、誰でも (AWS アカウント のないユーザーでも) バケットにアクセスできます。Amazon S3 バケットポリシーの例については、*Amazon Simple Storage Service ユーザーガイド*の「[バケットポリシーの例](https://docs.aws.amazon.com/AmazonS3/latest/dev/AccessPolicyLanguage_UseCases_s3_a.html)」を参照してください。
## AWS アカウントルートユーザーとしてサインインしています。アカウントに属する Amazon S3 バケットにアクセスできないのはなぜですか。
場合によっては、IAM と Amazon S3 へのフルアクセス許可を持つ IAM ユーザーがいる場合があります。IAM ユーザーが Amazon S3 バケットにバケットポリシーを割り当て、 ルートユーザーをプリンシパルとして指定しない場合、ルートユーザーはそのバケットへのアクセスを拒否されます。ただし、ルートユーザーとして、バケットへアクセスすることは可能です。そのためには、Amazon S3 コンソールまたは AWS CLI から アクセスを許可するようにバケットポリシーを変更します。次のプリンシパルを使用します。*123456789012* を AWS アカウント の ID に置き換えます。
```
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
```
# SAML と IAM とのフェデレーションをトラブルシューティングする
この情報を使用して、AWS Identity and Access Management で SAML 2.0 とフェデレーションを操作するときに発生する可能性がある問題を診断して修復します。
**Topics**
+ [エラー: Your request included an invalid SAML response。To logout, click here。](#troubleshoot_saml_invalid-response)
+ [エラー: RoleSessionName is required in AuthnResponse (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)](#troubleshoot_saml_missing-rolesessionname)
+ [エラー: Not authorized to perform sts:AssumeRoleWithSAML (service: AWSSecurityTokenService; status code: 403; error code: AccessDenied)](#troubleshoot_saml_missing-role)
+ [エラー: RoleSessionName in AuthnResponse must match [a-zA-Z\$10-9\$1=,.@-]\$12,64\$1 (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)](#troubleshoot_saml_invalid-rolesessionname)
+ [Error: Source Identity must match [a-zA-Z\$10-9\$1=,.@-]\$12,64\$1 and not begin with `"aws:"` (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)](#troubleshoot_saml_invalid-sourceidentity)
+ [エラー: Response signature invalid (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)](#troubleshoot_saml_invalid-metadata)
+ [エラー: 無効なプライベートキー。](#troubleshoot_saml_invalid-private-key)
+ [エラー: プライベートキーの削除に失敗しました。](#troubleshoot_saml_invalid-remove-key)
+ [エラー: キー ID がプライベートキーと一致しないため、プライベートキーを削除できませんでした。](#troubleshoot_saml_invalid-remove-key-mismatch)
+ [エラー: Failed to assume role: Issuer not present in specified provider (service: AWSOpenIdDiscoveryService; status code: 400; error code: AuthSamlInvalidSamlResponseException)](#troubleshoot_saml_issuer-mismatch)
+ [エラー: Could not parse metadata.](#troubleshoot_saml_issuer-metadata)
+ [エラー: ID プロバイダーを更新できません。メタデータまたは暗号化アサーションの更新が定義されていません。](#troubleshoot_saml_unable-to-update)
+ [エラー: プライベートキーが指定されていないため、アサーション暗号化モードを必須に設定できません。](#troubleshoot_saml_issuer-private-key-required)
+ [エラー: 同じリクエストでプライベートキーを追加および削除することはできません。2 つのパラメータのうち 1 つの値だけを設定します。](#troubleshoot_saml_add-remove-keys)
+ [エラー: Specified provider doesn't exist.](#troubleshoot_saml_provider-doesnotexist)
+ [エラー: Requested DurationSeconds exceeds MaxSessionDuration set for this role.](#troubleshoot_saml_duration-exceeds)
+ [エラー: プライベートキーの上限である 2 に達しました。](#troubleshoot_saml_private-key-exceeds)
+ [エラー: Response does not contain the required audience.](#troubleshoot_saml_required-audience)
## エラー: Your request included an invalid SAML response。To logout, click here。
このエラーは、ID プロバイダーからの SAML レスポンスに、`Name` が `https://aws.amazon.com/SAML/Attributes/Role` に設定された属性が含まれない場合に発生することがあります。属性には、それぞれにカンマ区切りの文字列のペアを持つ、1 つ以上の `AttributeValue` エレメントが含まれている必要があります。
+ ユーザーをマッピングできるロールの ARN
+ SAML プロバイダーの ARN
このエラーは、アイデンティティプロバイダーによって送信された SAML 属性値に先頭または末尾の空白のいずれかが含まれている場合にも発生する可能性があります。または、SAML 属性値にその他の無効の文字が含まれている場合にもエラーが発生する可能性があります。SAML 属性の想定値の詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。
詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。ブラウザで SAML レスポンスを表示するには、「[ブラウザに SAML レスポンスを表示する](troubleshoot_saml_view-saml-response.md)」のステップに従います。
## エラー: RoleSessionName is required in AuthnResponse (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)
このエラーは、ID プロバイダーからの SAML レスポンスに、`Name` が `https://aws.amazon.com/SAML/Attributes/RoleSessionName` に設定された属性が含まれない場合に発生することがあります。属性値は、ユーザーの ID で、通常は ID または E メールアドレスです。
詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。ブラウザで SAML レスポンスを表示するには、「[ブラウザに SAML レスポンスを表示する](troubleshoot_saml_view-saml-response.md)」のステップに従います。
## エラー: Not authorized to perform sts:AssumeRoleWithSAML (service: AWSSecurityTokenService; status code: 403; error code: AccessDenied)
このエラーは、SAML レスポンスで指定された IAM ロールのスペルが間違っているか存在しない場合に発生することがあります。ロール名は大文字と小文字が区別されるため、ロールの正確な名前を使用してください。SAML サービスプロバイダー設定のロール名を修正します。
ロール信頼ポリシーに `sts:AssumeRoleWithSAML` アクションが含まれる場合にのみ、アクセスが許可されます。SAML アサーションが [`PrincipalTag`](id_roles_providers_create_saml_assertions.md#saml_role-session-tags) 属性を使用するように設定されている場合、信頼ポリシーにも `sts:TagSession` アクションを含める必要があります。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
このエラーは、ロール信頼ポリシーに `sts:SetSourceIdentity` アクセス許可がない場合に発生する可能性があります。SAML アサーションが [`SourceIdentity`](id_roles_providers_create_saml_assertions.md#saml_sourceidentity) 属性を使用するように設定されている場合、信頼ポリシーにも `sts:SetSourceIdentity` アクションを含める必要があります。ソース ID の詳細については、「[引き受けたロールで実行されるアクションのモニタリングと制御](id_credentials_temp_control-access_monitor.md)」を参照してください。
このエラーは、フェデレーティッドプリンシパルがロールを引き受けるアクセス許可がない場合に発生することがあります。ロールには、IAM SAML ID プロバイダーの ARN を `Principal` として指定する信頼ポリシーが必要です。ロールには、ロールを引き受けることができるユーザーを管理する条件も含まれています。ユーザーが条件を満たすことを確認します。
このエラーは、SAML レスポンスに `Subject` を含む `NameID` がない場合に発生することがあります。
詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」および「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。ブラウザで SAML レスポンスを表示するには、「[ブラウザに SAML レスポンスを表示する](troubleshoot_saml_view-saml-response.md)」のステップに従います。
## エラー: RoleSessionName in AuthnResponse must match [a-zA-Z\$10-9\$1=,.@-]\$12,64\$1 (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)
このエラーは、`RoleSessionName` 属性値が長すぎるか、無効な文字が含まれる場合に発生することがあります。有効な最大長は 64 文字です。
詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。ブラウザで SAML レスポンスを表示するには、「[ブラウザに SAML レスポンスを表示する](troubleshoot_saml_view-saml-response.md)」のステップに従います。
## Error: Source Identity must match [a-zA-Z\$10-9\$1=,.@-]\$12,64\$1 and not begin with `"aws:"` (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)
このエラーは、`sourceIdentity` 属性値が長すぎるか、無効な文字が含まれる場合に発生することがあります。有効な最大長は 64 文字です。ソース ID の詳細については、「[引き受けたロールで実行されるアクションのモニタリングと制御](id_credentials_temp_control-access_monitor.md)」 を参照してください。
SAML アサーション作成の詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」 を参照してください。ブラウザで SAML レスポンスを表示するには、「[ブラウザに SAML レスポンスを表示する](troubleshoot_saml_view-saml-response.md)」のステップに従います。
## エラー: Response signature invalid (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)
このエラーは、ID プロバイダーのフェデレーションメタデータが、IAM ID プロバイダーのメタデータに一致しない場合に発生することがあります。たとえば、ID サービスプロバイダーのメタデータファイルが、失効した証明書を更新するために変更される場合があります。更新された SAML メタデータファイルを ID サービスプロバイダーからダウンロードします。次に、IAM で定義する AWS ID プロバイダーエンティティで、`aws iam update-saml-provider` クロスプラットフォーム CLI コマンドまたは `Update-IAMSAMLProvider` PowerShell コマンドレットを使ってこれを更新します。
## エラー: 無効なプライベートキー。
このエラーはプライベートキーファイルを適切にフォーマットしてない場合に発生することがあります。このエラーには、プライベートキーが無効である理由に関する詳細が次のように追加されている場合があります。
+ キーが暗号化されています。
+ キー形式が認識されません。プライベートキーファイルは .pem ファイルである必要があります。
AWS マネジメントコンソール で、[IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md) 場合は、ID プロバイダーからプライベートキーをダウンロードして IAM に提供し、暗号化を有効にする必要があります。プライベートキーは、AES-GCM または AES-CBC 暗号化アルゴリズムを使用して SAML アサーションを復号する .pem ファイルである必要があります。
## エラー: プライベートキーの削除に失敗しました。
このエラーは、SAML 暗号化が必須に設定されていて、リクエストによって IAM SAML プロバイダーの唯一のプライベート復号キーが削除された場合に発生する可能性があります。プライベートキーのローテーションの詳細については、「[SAML 暗号化キーの管理](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption)」を参照してください。
## エラー: キー ID がプライベートキーと一致しないため、プライベートキーを削除できませんでした。
このエラーは、プライベートキーの `keyId` 値が、プロバイダーのプライベートキーファイルのキー ID のいずれとも一致しない場合に発生する可能性があります。
[update-saml-provider](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/update-saml-provider.html) または [UpdateSAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html) API オペレーションを使用して SAML 暗号化プライベートキーを削除する場合、`RemovePrivateKey` の値は ID プロバイダーにアタッチされたプライベートキーの有効なキー ID である必要があります。
## エラー: Failed to assume role: Issuer not present in specified provider (service: AWSOpenIdDiscoveryService; status code: 400; error code: AuthSamlInvalidSamlResponseException)
このエラーは、SAML レスポンスの発行元がフェデレーションメタデータファイルで宣言されている発行者と一致しない場合に発生することがあります。メタデータファイルは、ID プロバイダーを IAM で作成したときに AWS にアップロードされました。
## エラー: Could not parse metadata.
このエラーはメタデータファイルを適切にフォーマットしてない場合に発生することがあります。
AWS マネジメントコンソール で、[SAML ID プロバイダーを作成または管理](id_roles_providers_create_saml.md#idp-manage-identityprovider-console)する場合、ID プロバイダーから SAML メタデータドキュメントを取得する必要があります。
このメタデータファイルには発行者の名前、失効情報、およびキーが含まれており、これらを使用して、IdP から受け取った SAML 認証レスポンス (アサーション) を検証できます。メタデータファイルはバイトオーダーマーク (BOM) なしで UTF-8 形式でエンコードする必要があります。BOM を削除するには、Notepad\$1\$1 などのテキスト編集ツールを使用して UTF-8 としてファイルをエンコードできます。
SAML メタデータドキュメントの一部として含まれている X.509 証明書では、少なくとも 1024 ビットのキーサイズを使用する必要があります。また、X.509 証明書には、拡張領域が繰り返されていないことが必要です。拡張領域は使用できますが、証明書に 1 回しか出現できません。X.509 証明書がいずれかの条件を満たしていない場合、IdP の作成は失敗し、「メタデータを解析できない」エラーが返されます。
[SAML V2.0 メタデータ相互運用性プロファイルバージョン 1.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html) で定義されているように、IAM は SAML メタデータドキュメントの X.509 証明書の有効期限で評価したりアクションを実行したりすることはできません。期限切れの X.509 証明書について懸念がある場合は、組織のガバナンスとセキュリティポリシーに従って証明書の有効期限をモニタリングし、証明書をローテーションすることをお勧めします。
## エラー: ID プロバイダーを更新できません。メタデータまたは暗号化アサーションの更新が定義されていません。
このエラーは、`update-saml-provider` CLI または `UpdateSAMLProvider` API オペレーションを使用しているにもかかわらず、リクエストパラメータに更新値を指定していない場合に発生する可能性があります。IAM SAML プロバイダーの更新の詳細については、「[IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md)」を参照してください。
## エラー: プライベートキーが指定されていないため、アサーション暗号化モードを必須に設定できません。
このエラーは、プライベート復号キーを以前にアップロードしておらず、リクエストにプライベートキーを含めずに SAML 暗号化を必須に設定しようとした場合に発生する可能性があります。
`create-saml-provider` CLI、`CreateSAMLProvider` API、`update-saml-provider` CLI、または `UpdateSAMLProvider` API オペレーションを使用して暗号化された SAML アサーションを要求する場合は、IAM SAML プロバイダーにプライベートキーが定義されていることを確認してください。
## エラー: 同じリクエストでプライベートキーを追加および削除することはできません。2 つのパラメータのうち 1 つの値だけを設定します。
このエラーは、プライベートキー値の追加と削除の両方が 1 件のリクエストに含まれている場合に発生する可能性があります。
[update-saml-provider](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/update-saml-provider.html) または [UpdateSAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html) API オペレーションを使用して SAML 暗号化プライベートキーファイルをローテーションする場合、そのリクエストではプライベートキーの追加または削除のいずれかしか実行できません。プライベートキーの削除中にプライベートキーを追加すると、オペレーションは失敗します。プライベートキーのローテーションの詳細については、「[SAML 暗号化キーの管理](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption)」を参照してください。
## エラー: Specified provider doesn't exist.
このエラーは、SAML アサーションのプロバイダーの名前が IAM のプロバイダーの名前と一致しない場合に発生することがあります。プロバイダー名の表示の詳細については、「[IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md)」を参照してください。
## エラー: Requested DurationSeconds exceeds MaxSessionDuration set for this role.
このエラーは、AWS CLI または API からロールを引き受ける場合に発生することがあります。
[assume-role-with-saml](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html) CLI または [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API オペレーションを使用してロールを引き受ける場合は、`DurationSeconds` パラメータの値を指定できます。900 秒 (15 分) からロールの最大セッション期間設定までの値を指定できます。この設定よりも高い値を指定した場合、オペレーションは失敗します。たとえば、12 時間のセッションの期間を指定したが、管理者が最大のセッション期間を 6 時間に設定した場合、オペレーションは失敗します。ロールの最大値を確認する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。
## エラー: プライベートキーの上限である 2 に達しました。
このエラーは、プライベートキーを ID プロバイダーに追加しようとすると発生する可能性があります。
ID プロバイダーごとに保存できるプライベートキーの数は最大 2 つです。[update-saml-provider](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/update-saml-provider.html) または [UpdateSAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html) API オペレーションを使用して 3 つ目のプライベートキーを追加しようとすると、オペレーションは失敗します。
新しいプライベートキーを追加する前に、期限が切れたプライベートキーを削除します。プライベートキーのローテーションの詳細については、「[SAML 暗号化キーの管理](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption)」を参照してください。
## エラー: Response does not contain the required audience.
このエラーは、SAML 設定のオーディエンス URL と ID プロバイダーが一致しない場合に発生する可能性があります。ID プロバイダー (IdP) 依存パーティ識別子が SAML 設定で提供されたオーディエンス URL (エンティティ ID) と完全に一致することを確認してください。