IAM ロールまたはユーザーを使用して API コールをリクエストしたときの、明示的な拒否エラーメッセージをトラブルシューティングする方法を教えてください。
AWS Identity and Access Management (IAM) ロールまたはユーザーを使用して API コールを行ったときに発生する、明示的な拒否エラーメッセージをトラブルシューティングしたいです。
簡単な説明
IAM ロールまたはユーザーが正常に API コールを行うには、そのエンティティは次の条件を満たしている必要があります。
- ロールまたはユーザーに、API コールをリクエストするための適切なアクセス許可がある。
- リクエストコンテキストに適用されるポリシーに、アクセス許可を拒否するステートメントがない。
IAM エンティティがこれらの条件を満たさない場合、API コールは失敗し、次のようなアクセス拒否エラーが返されます。
- "IAM user or role that has the issue: arn:aws:iam::444455556666:role/ExampleRole"
- "Error: An error occurred (AccessDenied) when calling the RunInstances operation: User: arn:aws:iam::444455556666:user/ExampleUser is not authorized to perform: ec2:RunInstances on resource: arn:aws:ec2:us-east-1:444455556666:volume/* with an explicit deny"
注: この記事のトラブルシューティング手順は、明示的な拒否エラーを具体的な対象としており、暗黙的な拒否エラーについては扱っていません。暗黙的な拒否エラーの詳細については、「暗黙的な拒否と明示的な拒否の違い」を参照してください。
解決策
明示的な拒否エラーは、次の 1 つ以上のポリシーの問題が原因で発生します。
- ID ベースのポリシー
- リソースベースのポリシー
- アクセス許可の境界
- サービスコントロールポリシー
- リソースコントロールポリシー
- セッションポリシー
ID ベースのポリシー
ID ベースのポリシーは、エンティティの許可/拒否アクションを制御します。これらのトラブルシューティング手順を使用して、ID ベースのポリシーに関する問題を特定してください。
注: 意図しないロックアウトを防ぐために、条件で Deny と StringNotLike を併用するのがベストプラクティスです。
-
ID ベースのポリシーに deny ステートメントがないことを確認します。この例には deny ステートメントが含まれています。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "iam:DeleteRole", "Resource": "*" } ] } -
ポリシーに多要素認証 (MFA) が適用されているかどうかを確認します。IAM エンティティが MFA なしで認証され、MFA 強制ポリシーが適用される場合、アクセス許可は拒否されます。次の MFA 適用の例を参照してください。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAllExceptListedIfNoMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } ] }このポリシーは、IAM エンティティが MFA で認証されていない場合に NotAction ポリシー要素に記載されているものを除き、すべての API コールを明示的に拒否します。
-
ポリシーが必須条件をすべて満たしていることを確認してください。ポリシーに複数の条件演算子または複数のキーがある場合、AWS は AND ロジックを使用して条件を評価します。同じ AND ロジックを得るには、各条件コンテキストキーを別々のステートメントで使用する必要があります。これは、API コールが失敗する原因となる一般的な問題の例です。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowRunInstancesWithRestrictions", "Effect": "Deny", "Action": [ "ec2:CreateVolume", "ec2:RunInstances" ], "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:instance/*" ], "Condition": { "ForAllValues:StringNotLike": { "aws:TagKeys": "Production" }, "StringEquals": { "ec2:InstanceType": "t2.micro" } } } ] }これらの API コールで明示的なアクセス拒否エラーが発生しないようにするには、必ず条件を満たしていることを確認してください。
注: aws: TagKeys の条件では、大文字と小文字が区別されます。
リソースベースのポリシー
リソースベースのポリシーは、リソースへのアクセスを許可または拒否します。統一された IAM ID ベースのポリシーとは異なり、サービスはリソースベースのポリシーを設計します。以下のトラブルシューティング手順では、Amazon Simple Storage Service (Amazon S3) のリソースベースのポリシーと VPC エンドポイントポリシーを例として使用します。
S3 バケットポリシーの評価
Amazon S3 バケットポリシーの評価は次のように行われます。
- 同じアカウントのバケットにアクセスするには、IAM エンティティには、IAM ID ベースのポリシーまたはバケットポリシーのアクセス許可が必要です。
- 別のアカウントのバケットにアクセスするには、IAM エンティティには、バケットポリシーおよび、アクセスを付与する IAM ID ベースのポリシーのアクセス許可が必要です。
注: これは、バケット ACL がデフォルトとして設定されていることを前提としています。
-
リソースベースのポリシーに deny ステートメントがないかを確認します。次の例は、バケットポリシーの deny ステートメントを示しています。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::444455556666:role/Role" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example-bucket" } ] } -
ポリシーの ARN が正しいことを確認します。
-
バケットポリシーは、現在のユーザーの aws:userid がポリシーで定義されているものと同一ではない場合、アクセスを拒否します。次の例を参照してください。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::example-bucket", "arn:aws:s3:::example-bucket/*" ], "Condition": { "StringNotLike": { "aws:userid": [ "AROAEXAMPLEID:*", "AIDAEXAMPLEID", "444455556666" ] } } } ] }
VPC エンドポイント
VPC エンドポイントポリシーは、エンドポイントにアタッチされている IAM リソースポリシーです。このポリシーにより、IAM ユーザーポリシーまたはサービス固有のポリシー (S3 バケットポリシーなど) が上書きされたり置き換えられたりすることはありません。
インターフェイスエンドポイントを使用して Amazon S3 に接続する場合、Amazon S3 データへのアクセスを制御する方法は 2 通りあります。
- VPC エンドポイントを使用してエンドポイントサービスにアクセスできる AWS プリンシパル (AWS アカウント、IAM ユーザー、IAM ロール) を制御します。または、
- Amazon S3 バケットポリシーを使用して、バケットにアクセスできる VPC または VPC エンドポイントを制御します。
以下の例は Amazon S3 バケットポリシーです。このポリシーは、ID vpce-1a2b3c4d の VPC エンドポイントから、example-bucket という特定のバケットへのアクセスを制限しています。ポリシーは、指定されたエンドポイントを使用していない場合、バケットへのすべてのアクセスを拒否します。aws:SourceVpce 条件によってエンドポイントが指定されます。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AccessSpecificVPCEOnly", "Principal": "*", "Action": "s3:*", "Effect": "Deny", "Resource": [ "arn:aws:s3:::example-bucket", "arn:aws:s3:::example-bucket/*" ], "Condition": { "StringNotEqualsIfExists": { "aws:SourceVpce": "vpce-1a2b3c4d" } } } ] }
VPC エンドポイントがリソースへのアクセスを明示的に拒否していないことを常に確認してください。
アクセス許可の境界
アクセス許可の境界は、ID ベースのポリシーが IAM エンティティに付与できる最大アクセス許可を設定するマネージドポリシーです。このマネージドポリシーにより、エンティティへのアクセス許可が制限されることで、明示的な拒否エラーメッセージが表示される場合があります。
この例は、IAM ポリシーでは許可されているが、アクセス許可の境界では明示的に拒否されるアクションを示しています。次のアクセス許可の境界を参照してください。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:*", "Resource": "*" } ] }
ユーザーには次のアクセス許可があります。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*" } ] }
ユーザーには RunInstances アクセス許可がありますが、それをリクエストすると明示的な拒否メッセージが表示されます。このエラーを解決するには、アクセス許可の境界と IAM ポリシーの両方がこのアクションを明示的に許可していることを確認してください。
サービスコントロールポリシー
サービスコントロールポリシー (SCP) により、組織内のアクセス許可を管理できます。次の例は、SCP の deny ステートメントを示しています。この例では、SCP はメンバーアカウントまたは特定の組織単位 (OU) に接続されています。RunInstances アクションへのアクセスを明示的に拒否しています。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "*" } ] }
明示的な拒否エラーを解決するには、アカウントからサービスコントロールポリシー (SCP) をデタッチします。または、一部のユースケースを除外する条件を deny ステートメントに追加します。
例えば、この例において、IAM プリンシパルが ExampleCloudOps ロールを使用している場合、SCP は ec2:RunInstances を拒否しません。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "*", "Condition": { "ArnNotLike": { "aws:PrincipalARN": "arn:aws:iam::444455556666:role/ExampleCloudOps" } } } ] }
リソースコントロールポリシー
リソースコントロールポリシー (RCP) を使用すると、組織内のリソースで使用できる最大アクセス許可を一元的に制御できます。RCP は次のリソースタイプでサポートされています。
- Amazon S3
- AWS Security Token サービス
- AWS Key Management Service
- Amazon SQS
- AWS Secrets Manager
- Amazon Elastic Container Registry
- Amazon OpenSearch Serverless
この例では、RCP を組織単位 (OU) またはメンバーアカウントにアタッチします。すべての S3 バケットでの DeleteObject アクションが明示的に拒否されます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:DeleteObject", "Resource": "*" } ] }
明示的な拒否エラーを解決するには、アカウントからリソースコントロールポリシー (RCP) をデタッチします。または、一部のユースケースを除外する条件を deny ステートメントに追加します。
例えば、この例において、IAM プリンシパルが ExampleCloudOps ロールを使用している場合、RCP は ec2:RunInstances を拒否しません。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "*", "Condition": { "ArnNotLike": { "aws:PrincipalARN": "arn:aws:iam::444455556666:role/ExampleCloudOps" } } } ] }
セッションポリシー
セッションポリシーは、ロールまたはユーザーの一時セッションをプログラムで作成するときにパラメータとして渡す高度なポリシーです。ロールセッションを作成し、AssumeRole、AssumeRoleWithSAML、または AssumeRoleWithWebIdentity API 操作を使用することで、セッションポリシーを渡すことができます。
例えば、このポリシーでは、ユーザーが RunInstances API コールを行おうとすると、明示的な拒否エラーが生成されます。セッションポリシーの deny ステートメントを必ず確認してください。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "*" } ] }
関連情報
サービスコントロールポリシーを使用して AWS Organization のアカウント間にアクセス許可ガードレールを設定する方法
- 言語
- 日本語
