アクセス拒否エラーメッセージをトラブルシューティングする
AWS Identity and Access Management で発生したアクセス拒否エラーを識別し、診断して解決する場合は、以下の情報を参照すると便利です。アクセス拒否エラーは、AWS が認証リクエストを明示的または暗黙的に拒否した場合に表示されます。
-
明示的な拒否は、特定の AWS アクションに対する
Deny
ステートメントがポリシーに含まれている場合に発生します。 -
該当する
Deny
ステートメントがなく、該当するAllow
ステートメントもない場合に、暗黙的な拒否が発生します。IAM ポリシーはデフォルトで IAM プリンシパルを拒否するため、ポリシーではプリンシパルにアクションの実行を明示的に許可する必要があります。それ以外の場合、ポリシーは暗黙的にアクセスを拒否します。詳細については、「明示的な拒否と暗黙的な拒否の違い」を参照してください。
サービスやリソースにリクエストを送信するときに、複数のポリシーがそのリクエストに適用されることがあります。エラーメッセージで指定されたポリシーだけでなく、適用可能なポリシーをすべて確認してください。
-
ポリシータイプが同じである複数のポリシーがリクエストを拒否した場合、アクセス拒否エラーメッセージには評価されたポリシーの番号が指定されません。
-
複数のポリシータイプが原因で認証リクエストが拒否された場合、AWS は、これらのポリシータイプのうち 1 つだけをエラーメッセージに含めます。
重要
AWS へのサインインに問題がある場合 ユーザーのタイプに応じて正しい AWS サインインページが表示されていることを確認します。AWS アカウントのルートユーザー (アカウント所有者) の場合は、AWS アカウント の作成時に設定した認証情報を使用して AWS にサインインできます。IAM ユーザーの場合、アカウント管理者から AWS サインイン認証情報を付与してもらうことができます。サポートをリクエストする必要がある場合は、このページのフィードバックリンクを使用しないでください。フォームは、AWS Support ではなく AWS ドキュメントチームに届きます。代わりに、「お問い合わせ
AWS サービスに要求を送信すると "アクセス拒否" が発生する
-
エラーメッセージに、アクセスを拒否するポリシーの種類が含まれているかどうかを確認します。たとえば、サービス制御ポリシー (SCP) によりアクセスが拒否されたというエラーが表示された場合は、SCP の問題のトラブルシューティングに集中できます。ポリシータイプを特定したら、そのポリシータイプで拒否ステートメントがあるかどうかや、許可アクションが欠落していないかを確認できます。エラーメッセージに、アクセスを拒否するポリシーの種類が記載されていない場合は、このセクションの残りのガイドラインを参考にして、さらにトラブルシューティングを行ってください。
-
リクエストしたアクションとリソースを呼び出すアイデンティティベースのポリシーのアクセス許可を持っていることを確認します。条件が付けられている場合、要求を送信するにはそれらの条件も満たしている必要があります。IAM ユーザー、グループ、ロールのポリシーの表示や修正の詳細については、「IAM ポリシーを管理する」を参照してください。
-
AWS Management Console から、アクションを実行する権限がないと通知された場合、管理者に問い合わせ、サポートを依頼する必要があります。管理者からサインイン資格情報またはサインインリンクが提供されました。
以下のエラー例は、
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 などのリソースベースのポリシーをサポートするサービスにアクセスしようとしていますか。その場合は、ポリシーでお客様がプリンシパルに指定されていて、アクセス権限を付与されていることを確認します。アカウント内のサービスにリクエストする場合は、アイデンティティベースのポリシーまたはリソースベースのポリシーを使用して、アクセス許可を付与することができます。別のアカウントのサービスにリクエストする場合は、アイデンティティベースのポリシーとリソースベースのポリシーの両方でアクセス許可を付与する必要があります。リソースベースのポリシーをサポートするサービスを確認するには、「IAM と連携する AWS のサービス」を参照してください。
-
キーバリューのペアを持つ条件がポリシーに含まれている場合は、そのポリシーを慎重に確認します。この例には、aws:RequestTag/tag-key グローバル条件キー、AWS KMS
kms:EncryptionContext:
、および複数のサービスでサポートされているencryption_context_key
ResourceTag/
条件キーが含まれます。キー名が複数の結果に一致しないことを確認します。条件キー名では大文字と小文字が区別されないため、tag-key
foo
というキーを確認する条件は、foo
、Foo
、またはFOO
に一致します。リクエストに複数のキーバリューのペアが含まれていて、キー名の大文字と小文字のみが異なる場合、アクセスは予期せず拒否される可能性があります。詳細については、「IAM JSON ポリシー要素Condition」を参照してください。 -
アクセス許可の境界が設定されている場合は、アクセス許可の境界として使用されているポリシーでリクエストが許可されるかどうかを確認します。リクエストがアイデンティティベースのポリシーでは許可されるが、アクセス許可の境界では許可されない場合、リクエストは拒否されます。アクセス許可の境界は、IAM プリンシパル (ユーザーまたはロール) に付与できるアクセス許可の上限を設定します。リソースベースのポリシーは、アクセス許可の境界では制限されません。アクセス許可の境界は一般向けの機能ではありません。AWS によるポリシーの評価方法の詳細については、「ポリシーの評価論理」を参照してください。
一時的な認証情報を使用して要求を送信すると "アクセス拒否" が発生する
-
まず、一時的な認証情報とは別の理由でアクセスが拒否されていないことを確認してください。詳細については、「AWS サービスに要求を送信すると "アクセス拒否" が発生する」を参照してください。
-
サービスが一時的セキュリティ認証情報を受け入れることを確認します。「IAM と連携する AWS のサービス」を参照してください。
-
リクエストが正しく署名されており、そのリクエストの形式が整っていることを確認します。詳細については、ツールキット
ドキュメントまたは「AWS リソースを使用した一時的な認証情報の使用」を参照してください。 -
一時的な認証情報が失効していないことを確認します。詳細については、「IAM の一時的な認証情報」を参照してください。
-
IAM ユーザーまたはロールに正しいアクセス権限があるかどうかを確認します。一時的なセキュリティ認証情報のアクセス許可は IAM ユーザーまたはロールから取得されます。その結果、アクセス許可は、一時的な認証情報を引き受けたロールに付与されているものに制限されます。一時的なセキュリティ認証情報に対するアクセス許可の決定方法の詳細については、「一時的なセキュリティ認証情報のアクセス権限を制御する」を参照してください。
-
ロールを引き受ける場合は、ロールセッションはセッションポリシーによって制限される場合があります。AWS STS を使用してプログラムで一時的なセキュリティ認証情報をリクエストする場合は、オプションでインラインまたは管理セッションポリシーを渡すことができます。セッションポリシーは、ロールの一時認証情報セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。
Policy
パラメータを使用して単一の JSON インラインセッションポリシードキュメントを渡すことができます。PolicyArns
パラメータを使用して、最大 10 個の管理セッションポリシーを指定できます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。または、管理者またはカスタムプログラムから一時的な認証情報が提供されている場合は、アクセスを制限するためのセッションポリシーが含まれている可能性があります。 -
フェデレーティッドユーザーの場合は、セッションはセッションポリシーによって制限される場合があります。AWS に IAM ユーザーとしてサインインしてフェデレーショントークンをリクエストすることでフェデレーティッドユーザーになります。フェデレーティッドユーザーの詳細については、「GetFederationToken — カスタム ID ブローカーを介したフェデレーション」を参照してください。フェデレーショントークンをリクエスト中に ID ブローカーがセッションポリシーに合格した場合、セッションはそれらのポリシーによって制限されます。結果として得られるセッションのアクセス許可は、IAM ユーザーの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーの詳細については、「セッションポリシー」を参照してください。
-
ロールを使用してリソースベースのポリシーのあるリソースへアクセスする場合は、ポリシーからロールにアクセス権限が付与されていることを確認します。たとえば、次のポリシーではアカウント
MyRole
からの111122223333
のMyBucket
へのアクセスを許可しています。{ "Version": "2012-10-17", "Statement": [{ "Sid": "S3BucketPolicy", "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::111122223333:role/MyRole"]}, "Action": ["s3:PutObject"], "Resource": ["arn:aws:s3:::MyBucket/*"] }] }
アクセス拒否エラーメッセージの例
ほとんどのアクセス拒否のエラーメッセージは、User
の形式です。この例では、user
is not authorized to perform
action
on resource
because
context
ユーザー
はアクセスを受信しない Amazon リソースネーム (ARN) であり、アクション
はポリシーが拒否するサービスアクションであり、リソース
は、ポリシーが作用するリソースの ARN です。[context]
(コンテキスト) フィールドには、ポリシータイプについての追加のコンテキストが表示され、ポリシーがアクセスを拒否した理由が説明されています。
ポリシー内の Deny
ステートメントによって明示的にポリシーが拒否された場合、AWS はアクセス拒否エラーメッセージに with an explicit deny in a
を含めます。ポリシーが暗黙的に拒否された場合は、AWS はアクセス拒否エラーメッセージに文字列 type
policybecause no
を含めます。type
policy allows the
action
action
注記
AWS のサービスによっては、このアクセス拒否エラーメッセージ形式をサポートしていません。アクセス拒否エラーメッセージの内容は、認証リクエストを行うサービスによって異なる場合があります。
次の例では、アクセス拒否エラーメッセージの形式のタイプを示します。
サービスコントロールポリシーによるアクセスの拒否 - 暗黙的な拒否
-
サービスコントロールポリシー (SCP) のアクションで、
Allow
ステートメントが欠けていないかを確認します。次の例では、codecommit:ListRepositories
がアクションです。 -
Allow
ステートメントを追加して、ポリシーを更新してください。詳細については、「AWS Organizations ユーザーガイド」の「SCP の更新」を参照してください。
User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform: codecommit:ListRepositories because no service control policy allows the codecommit:ListRespositories action
サービスコントロールポリシーによるアクセスの拒否 - 明示的な拒否
-
サービスコントロールポリシー (SCP) のアクションで、
Deny
ステートメントを確認します。次の例では、codecommit:ListRepositories
がアクションです。 -
Deny
ステートメントを削除して、SCP を更新してください。詳細については、「AWS Organizations ユーザーガイド」の「SCP の更新」を参照してください。
User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform: codecommit:ListRepositories with an explicit deny in a service control policy
VPC エンドポイントポリシーによるアクセスの拒否 – 暗黙的な拒否
-
仮想プライベートクラウド (VPC) エンドポイントポリシーのアクションで、
Allow
ステートメントが欠落していないかを確認してください。次の例では、codecommit:ListRepositories
がアクションです。 -
Allow
ステートメントを追加して、VPC エンドポイントポリシーを更新します。詳細については、「AWS PrivateLink ガイド」の「VPC エンドポイントポリシーを更新する」を参照してください。
User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: codecommit:ListRepositories because no VPC endpoint policy allows the codecommit:ListRepositories action
VPC エンドポイントポリシーによるアクセスの拒否 – 明示的拒否
-
仮想プライベートクラウド (VPC) エンドポイントポリシーにあるアクションに対する明示的
Deny
ステートメントがあるのかを確認してください。次の例では、codedeploy:ListDeployments
がアクションです。 -
Deny
ステートメントを削除して、VPC エンドポイントポリシーを更新してください。詳細については、「AWS PrivateLink ガイド」の「VPC エンドポイントポリシーを更新する」を参照してください。
User: arn:aws:iam::123456789012:user/JohnDoe 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
アクセス許可の境界によりアクセスの拒否 – 暗黙的な拒否
-
アクセス許可の境界にあるアクションで、
Allow
ステートメントが欠落してないかを確認してください。次の例では、codedeploy:ListDeployments
がアクションです。 -
IAM ポリシーに
Allow
ステートメントを追加して、アクセス許可の境界を更新してください。詳細については、「IAM エンティティのアクセス許可境界」および「IAM ポリシーの編集」を参照してください。
User: arn:aws:iam::123456789012:user/JohnDoe 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
アクセス許可の境界によりアクセスの拒否 – 明示的拒否
-
アクセス許可の境界にあるアクションで、明示的な
Deny
ステートメントを確認してください。次の例では、sagemaker:ListModels
がアクションです。 -
IAM ポリシーから
Deny
ステートメントを削除して、アクセス許可の境界を更新してください。詳細については、IAM エンティティのアクセス許可境界およびIAM ポリシーの編集を参照してください。
User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform: sagemaker:ListModels with an explicit deny in a permissions boundary
セッションポリシーによるアクセスの拒否 – 暗黙的な拒否
-
セッションポリシーにあるアクションで、
Allow
ステートメントが欠落していないかを確認してください。次の例では、codecommit:ListRepositories
がアクションです。 -
Allow
ステートメントを追加して、セッションポリシーを更新してください。詳細については、「セッションポリシー」と「IAM ポリシーの編集」を参照してください。
User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: codecommit:ListRepositories because no session policy allows the codecommit:ListRepositories action
セッションポリシーによるアクセスの拒否 – 明示的拒否
-
セッションポリシーにあるアクションで、明示的な
Deny
ステートメントがあるのかを確認してください。次の例では、codedeploy:ListDeployments
がアクションです。 -
Deny
ステートメントを削除して、セッションポリシーを更新してください。詳細については、「セッションポリシー」と「IAM ポリシーの編集」を参照してください。
User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: codedeploy:ListDeployments on resource: arn:aws:codedeploy:us-east-1:123456789012:deploymentgroup:* with an explicit deny in a sessions policy
リソースベースのポリシーによるアクセスの拒否 – 暗黙的な拒否
-
リソースベースのポリシーにあるアクションで、
Allow
ステートメントが欠落してないかを確認してください。次の例では、secretsmanager:GetSecretValue
がアクションです。 -
Allow
ステートメントを追加して、ポリシーを更新してください。詳細については、「リソースベースのポリシー」と「IAM ポリシーの編集」を参照してください。
User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: secretsmanager:GetSecretValue because no resource-based policy allows the secretsmanager:GetSecretValue action
リソースベースのポリシーによるアクセスの拒否 – 明示的拒否
-
リソースベースのポリシーにあるアクションで、明示的な
Deny
ステートメントがあるのかを確認してください。次の例では、secretsmanager:GetSecretValue
がアクションです。 -
Deny
ステートメントを削除して、ポリシーを更新してください。詳細については、「リソースベースのポリシー」と「IAM ポリシーの編集」を参照してください。
User: arn:aws:iam::123456789012:user/JohnDoe 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
ロール信頼ポリシーによるアクセスの拒否 – 暗黙的な拒否
-
ロール信頼ポリシーにあるアクションで、
Allow
ステートメントが欠落していないかを確認してください。次の例では、sts:AssumeRole
がアクションです。 -
Allow
ステートメントを追加して、ポリシーを更新してください。詳細については、「リソースベースのポリシー」と「IAM ポリシーの編集」を参照してください。
User: arn:aws:iam::123456789012:user/JohnDoe is not authorized to perform: sts:AssumeRole because no role trust policy allows the sts:AssumeRole action
ロール信頼ポリシーによるアクセスの拒否 – 明示的拒否
-
ロール信頼ポリシーにあるアクションで、明示的な
Deny
ステートメントがあるのかを確認してください。次の例では、sts:AssumeRole
がアクションです。 -
Deny
ステートメントを削除して、ポリシーを更新してください。詳細については、「リソースベースのポリシー」と「IAM ポリシーの編集」を参照してください。
User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform: sts:AssumeRole with an explicit deny in the role trust policy
ID ベースのポリシーによるアクセスの拒否 – 暗黙的な拒否
-
ID にアタッチされた ID ベースのポリシーにあるアクションに対して、
Allow
ステートメントが欠落していないかを確認してください。次の例では、ロールHR
にアタッチされたcodecommit:ListRepositories
がアクションです。 -
Allow
ステートメントを追加して、ポリシーを更新してください。詳細については、「アイデンティティベースのポリシー」と IAM ポリシーの編集 を参照してください。
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 ベースのポリシーによるアクセスの拒否 – 明示的な拒否
-
ID にアタッチされた ID ベースのポリシーにあるアクションに対して、明示的な
Deny
ステートメントがあるのかを確認してください。次の例では、ロールHR
にアタッチされたcodedeploy:ListDeployments
がアクションです。 -
Deny
ステートメントを削除して、ポリシーを更新してください。詳細については、「アイデンティティベースのポリシー」と IAM ポリシーの編集 を参照してください。
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
別のポリシーが原因で VPC リクエストが失敗した場合のアクセス拒否
-
サービスコントロールポリシー (SCP) にあるアクションで、明示的な
Deny
ステートメントがあるのかを確認してください。次の例では、SNS:Publish
がアクションです。 -
Deny
ステートメントを削除して、SCP を更新してください。詳細については、「AWS IAM Identity Center ユーザーガイド」の「SCP の更新」を参照してください。
User: arn:aws:sts::111122223333:assumed-role/
role-name
/role-session-name
is not authorized to perform: SNS:Publish on resource: arn:aws:sns:us-east-1:444455556666:role-name-2
with an explicit deny in a VPC endpoint policy transitively through a service control policy