アクセス拒否エラーメッセージをトラブルシューティングする - AWS Identity and Access Management
AWS サービスに要求を送信すると "アクセス拒否" が発生する一時的な認証情報を使用して要求を送信すると "アクセス拒否" が発生するアクセス拒否の例

アクセス拒否エラーメッセージをトラブルシューティングする

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 アカウントにまだログインできない] を選択してから、表示されているサポートオプションのいずれかを選択します。

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 SDK を使用しない) 場合は、正確にリクエストに署名していることを確認します。

一時的な認証情報を使用して要求を送信すると "アクセス拒否" が発生する

  • まず、一時的な認証情報とは別の理由でアクセスが拒否されていないことを確認してください。詳細については、「AWS サービスに要求を送信すると "アクセス拒否" が発生する」を参照してください。

  • サービスが一時的セキュリティ認証情報を受け入れることを確認します。「IAM と連携する AWS のサービス」を参照してください。

  • リクエストが正しく署名されており、そのリクエストの形式が整っていることを確認します。詳細については、ツールキットドキュメントまたは「AWS リソースで一時的な認証情報を使用する」を参照してください。

  • 一時的な認証情報が失効していないことを確認します。詳細については、「IAM の一時的な認証情報」を参照してください。

  • IAM ユーザーまたはロールに正しいアクセス権限があるかどうかを確認します。一時的なセキュリティ認証情報のアクセス許可は IAM ユーザーまたはロールから取得されます。その結果、アクセス許可は、一時的な認証情報を引き受けたロールに付与されているものに制限されます。一時的なセキュリティ認証情報に対するアクセス許可の決定方法の詳細については、「一時的なセキュリティ認証情報のアクセス許可」を参照してください。

  • ロールを引き受ける場合は、ロールセッションはセッションポリシーによって制限される場合があります。AWS STS を使用してプログラムで一時的なセキュリティ認証情報をリクエストする場合は、オプションでインラインまたは管理セッションポリシーを渡すことができます。セッションポリシーは、ロールの一時認証情報セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。Policy パラメータを使用して単一の JSON インラインセッションポリシードキュメントを渡すことができます。PolicyArns パラメータを使用して、最大 10 個の管理セッションポリシーを指定できます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。または、管理者またはカスタムプログラムから一時的な認証情報が提供されている場合は、アクセスを制限するためのセッションポリシーが含まれている可能性があります。

  • フェデレーティッドユーザーの場合は、セッションはセッションポリシーによって制限される場合があります。AWS に IAM ユーザーとしてサインインしてフェデレーショントークンをリクエストすることでフェデレーティッドユーザーになります。フェデレーティッドユーザーの詳細については、「カスタム ID ブローカーを通じた認証情報のリクエスト」を参照してください。フェデレーショントークンをリクエスト中に ID ブローカーがセッションポリシーに合格した場合、セッションはそれらのポリシーによって制限されます。結果として得られるセッションのアクセス許可は、IAM ユーザーの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーの詳細については、「セッションポリシー」を参照してください。

  • ロールを使用してリソースベースのポリシーのあるリソースへアクセスする場合は、ポリシーからロールにアクセス権限が付与されていることを確認します。たとえば、次のポリシーではアカウント MyRole からの 111122223333 の amzn-s3-demo-bucket へのアクセスを許可しています。

    {
  "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/*"]
  }]
}

アクセス拒否エラーメッセージの例

ほとんどのアクセス拒否のエラーメッセージは、User user is not authorized to perform action on resource because context の形式です。この例では、ユーザーはアクセスを受信しない Amazon リソースネーム (ARN) であり、アクションはポリシーが拒否するサービスアクションであり、リソースは、ポリシーが作用するリソースの ARN です。[context] (コンテキスト) フィールドには、ポリシータイプについての追加のコンテキストが表示され、ポリシーがアクセスを拒否した理由が説明されています。

ポリシー内の Deny ステートメントによって明示的にポリシーが拒否された場合、AWS はアクセス拒否エラーメッセージに with an explicit deny in a type policy を含めます。ポリシーが暗黙的に拒否された場合は、AWS はアクセス拒否エラーメッセージに文字列 because no type policy allows the action action を含めます。

注記

AWS のサービスによっては、このアクセス拒否エラーメッセージ形式をサポートしていません。アクセス拒否エラーメッセージの内容は、認証リクエストを行うサービスによって異なる場合があります。

次の例では、アクセス拒否エラーメッセージの形式のタイプを示します。

サービスコントロールポリシーによるアクセスの拒否 - 暗黙的な拒否

  1. サービスコントロールポリシー (SCP) のアクションで、Allow ステートメントが欠けていないかを確認します。次の例では、codecommit:ListRepositories がアクションです。

  2. 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

サービスコントロールポリシーによるアクセスの拒否 - 明示的な拒否

  1. サービスコントロールポリシー (SCP) のアクションで、Deny ステートメントを確認します。次の例では、codecommit:ListRepositories がアクションです。

  2. 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 エンドポイントポリシーによるアクセスの拒否 – 暗黙的な拒否

  1. 仮想プライベートクラウド (VPC) エンドポイントポリシーのアクションで、Allow ステートメントが欠落していないかを確認してください。次の例では、codecommit:ListRepositories がアクションです。

  2. 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 エンドポイントポリシーによるアクセスの拒否 – 明示的拒否

  1. 仮想プライベートクラウド (VPC) エンドポイントポリシーにあるアクションに対する明示的 Deny ステートメントがあるのかを確認してください。次の例では、codedeploy:ListDeployments がアクションです。

  2. 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

アクセス許可の境界によりアクセスの拒否 – 暗黙的な拒否

  1. アクセス許可の境界にあるアクションで、Allow ステートメントが欠落してないかを確認してください。次の例では、codedeploy:ListDeployments がアクションです。

  2. 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

アクセス許可の境界によりアクセスの拒否 – 明示的拒否

  1. アクセス許可の境界にあるアクションで、明示的な Deny ステートメントを確認してください。次の例では、sagemaker:ListModels がアクションです。

  2. 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

セッションポリシーによるアクセスの拒否 – 暗黙的な拒否

  1. セッションポリシーにあるアクションで、Allow ステートメントが欠落していないかを確認してください。次の例では、codecommit:ListRepositories がアクションです。

  2. 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

セッションポリシーによるアクセスの拒否 – 明示的拒否

  1. セッションポリシーにあるアクションで、明示的な Deny ステートメントがあるのかを確認してください。次の例では、codedeploy:ListDeployments がアクションです。

  2. 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

リソースベースのポリシーによるアクセスの拒否 – 暗黙的な拒否

  1. リソースベースのポリシーにあるアクションで、Allow ステートメントが欠落してないかを確認してください。次の例では、secretsmanager:GetSecretValue がアクションです。

  2. 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

リソースベースのポリシーによるアクセスの拒否 – 明示的拒否

  1. リソースベースのポリシーにあるアクションで、明示的な Deny ステートメントがあるのかを確認してください。次の例では、secretsmanager:GetSecretValue がアクションです。

  2. 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

ロール信頼ポリシーによるアクセスの拒否 – 暗黙的な拒否

  1. ロール信頼ポリシーにあるアクションで、Allow ステートメントが欠落していないかを確認してください。次の例では、sts:AssumeRole がアクションです。

  2. 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

ロール信頼ポリシーによるアクセスの拒否 – 明示的拒否

  1. ロール信頼ポリシーにあるアクションで、明示的な Deny ステートメントがあるのかを確認してください。次の例では、sts:AssumeRole がアクションです。

  2. 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 ベースのポリシーによるアクセスの拒否 – 暗黙的な拒否

  1. ID にアタッチされた ID ベースのポリシーにあるアクションに対して、Allow ステートメントが欠落していないかを確認してください。次の例では、ロール HR にアタッチされた codecommit:ListRepositories がアクションです。

  2. 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 ベースのポリシーによるアクセスの拒否 – 明示的な拒否

  1. ID にアタッチされた ID ベースのポリシーにあるアクションに対して、明示的な Deny ステートメントがあるのかを確認してください。次の例では、ロール HR にアタッチされた codedeploy:ListDeployments がアクションです。

  2. 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 リクエストが失敗した場合のアクセス拒否

  1. サービスコントロールポリシー (SCP) にあるアクションで、明示的な Deny ステートメントがあるのかを確認してください。次の例では、SNS:Publish がアクションです。

  2. 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