スキップしてコンテンツを表示

IAM ロールまたはユーザーを使用して API コールをリクエストしたときの、明示的な拒否エラーメッセージをトラブルシューティングする方法を教えてください。

所要時間3分
0

AWS Identity and Access Management (IAM) ロールまたはユーザーを使用して API コールをリクエストしたときに発生する、明示的な拒否エラーメッセージをトラブルシューティングしたいです。

簡単な説明

IAM エンティティ (ロールまたはユーザー) が正常に API コールを行うには、そのエンティティは次の条件を満たしている必要があります。

  • ロールまたはユーザーに、API コールをリクエストするための適切なアクセス許可がある。
  • リクエストのコンテキストに該当するすべてのポリシーにおいて、すべてのステートメントがそのアクセス許可を拒否していない。

IAM エンティティがこれらの条件を満たさない場合、API コールは失敗し、次のようなエラー (AccessDenied) が返されます。

  • "IAM ユーザーまたはロールに問題が発生しました: arn:XXXXXXXX:iam::XXXXXXXX:role/TestReadOnly"
  • "エラー: RunInstances 操作の呼び出し時にエラー (AccessDenied) が発生しました。 ユーザー arn:aws:iam::XXXXXXXX:user/tester は、ec2:RunInstances on resource の実行を許可されていません。ロール TestReadOnly は明示的に拒否されています"

注: この記事のトラブルシューティング手順は、明示的な拒否エラーを具体的な対象としており、暗黙的な拒否エラーについては扱っていません。暗黙的な拒否エラーの詳細については、「暗黙的な拒否と明示的な拒否の違い」を参照してください。

解決策

明示的な拒否エラーは、次の 1 つ以上のポリシーの問題が原因で発生します。

  • ID ベースのポリシー
  • リソースベースのポリシー
  • アクセス許可の境界
  • サービスコントロールポリシー
  • セッションポリシー

ID ベースのポリシー

ID ベースのポリシーは、エンティティの許可/拒否アクションを制御します。これらのトラブルシューティング手順を使用して、ID ベースのポリシーに関する問題を特定してください。

注: 意図しない特権によるアクセスを防ぐために、条件で DenyStringNotLike を併用するのがベストプラクティスです。

1.ID ベースのポリシーに deny ステートメントがないことを確認します。この例には deny ステートメントが含まれています。

{
  "Effect": "Deny",
  "Action": "iam:DeleteRole"
  "Resource": "*"
}

2.ポリシーに多要素認証 (MFA) が適用されているかどうかを確認します。MFA が適用されているときに IAM エンティティが別の認証要素を使用せずに認証を行うと、そのアクセス許可は拒否されます。たとえば、エンティティが MFA を使用せず、AWS CLI を使用して認証した場合、API コールは拒否されます。次の MFA 適用の例を参照してください。

{
  "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"}
  }
}

このポリシーは、NotAction ポリシー要素に記載されているものを除き、すべての API コールを明示的に拒否します。

3.ポリシーが必須条件をすべて満たしていることを確認してください。ポリシーに複数の条件演算子または複数のキーがある場合、条件は AND ロジックを使用して評価されます。同じ AND ロジックを使用するには、各 RequestTag キーを別々のステートメントで使用する必要があります。これは、API コールが失敗する原因となる一般的な問題の例です。

{
  "Sid": "AllowRunInstancesWithRestrictions2",
  "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 バケットポリシーの評価は次のように行われます。

注: これは、バケット ACL がデフォルトとして設定されていることを前提としています。

  • 同じアカウントのバケットにアクセスするには、IAM エンティティには、IAM ID ベースまたはバケットポリシーのアクセス許可が必要です。
  • 別のアカウントのバケットにアクセスするには、IAM エンティティには、バケットポリシーおよび、アクセスを付与する IAM ID ベースのアクセス許可が必要です。

1.リソースベースのポリシーに deny ステートメントがないかを確認します。次の例は、バケットポリシーの deny ステートメントを示しています。

{
  "Effect": "deny",
  "Principal": {
    "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
  },
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::MyExampleBucket"
}

2.ポリシーに記載されている ARN が正しいことを確認します。

3.バケットポリシーは、現在のユーザーの aws:userid がポリシーで定義されているものと同一ではない場合、アクセスを拒否します。次の例を参照してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::MyExampleBucket",
        "arn:aws:s3:::MyExampleBucket/*"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:userId": [
            "AROAEXAMPLEID:*",
            "AIDAEXAMPLEID",
            "111111111111"
          ]
        }
      }
    }
  ]
}

VPC エンドポイント

VPC エンドポイントポリシーは、エンドポイントにアタッチされている IAM リソースポリシーです。このポリシーにより、IAM ユーザーポリシーまたはサービス固有のポリシー (S3 バケットポリシーなど) が上書きされたり置き換えられたりすることはありません。

インターフェイスエンドポイントを使用して Amazon S3 に接続する場合、Amazon S3 データへのアクセスを制御する方法は 2 通りあります。

  • VPC エンドポイントを使用してエンドポイントサービスにアクセスできる AWS プリンシパル (AWS アカウント、IAM ユーザー、IAM ロール) を制御します。または、
  • Amazon S3 バケットポリシーを使用して、バケットにアクセスできる VPC または VPC エンドポイントを制御します。

以下の例は Amazon S3 バケットポリシーです。このポリシーは、ID vpce-11111 の VPC エンドポイントから、examplebucket という特定のバケットへのアクセスを制限しています。ポリシーは、指定されたエンドポイントを使用していない場合、バケットへのすべてのアクセスを拒否します。aws:SourceVPCE 条件を使用してエンドポイントを指定しています。

{
   "Version": "2012-10-17",
   "Id": "Policy123456789”,
   "Statement": [
     {
       "Sid": "AccessSpecificVPCEOnly",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::examplebucket",
                    "arn:aws:s3:::examplebucket/*"],
       "Condition": {
         "StringNotEqualsIfExists": {
           "aws:SourceVpce": "vpce-11111”
         }
       }
     }
   ]
}

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 ステートメントを変更します。たとえば、この例において、次の SCP は IAM プリンシパルが CloudOps ロールを使用している場合、ec2:RunInstances を拒否しません。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances"     
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/CloudOps"
        }
      }
    }
  ]
}

セッションポリシー

セッションポリシーは、ロールまたはユーザーの一時セッションをプログラムで作成するときにパラメータとして渡す高度なポリシーです。ロールセッションを作成し、AssumeRole、AssumeRoleWithSAML、または AssumeRoleWithWebIdentity API 操作を使用することで、セッションポリシーを渡すことができます。

たとえば、このポリシーでは、ユーザーが RunInstances API コールを行おうとすると、明示的な拒否エラーが生成されます。セッションポリシーの deny ステートメントを必ず確認してください。

{
  "Version": "2012-10-17",

  "Statement": {
    "Effect": "Deny",
    "Action": "ec2:RunInstances",

    "Resource": "*"
  }
}

関連情報

AWS リソースのアクセス管理

サービスコントロールポリシーを使用して AWS Organization のアカウント間にアクセス許可ガードレールを設定する方法

IAM エンティティのアクセス許可の境界

Amazon S3 バケットへのアクセスを特定の IAM ロールに制限する方法

バケットポリシーを使用して VPC エンドポイントからのアクセスを制御する

AWS公式更新しました 1年前
コメントはありません

関連するコンテンツ