AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post

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: ロール TestReadOnly (明示的な拒否)

**注:**この記事のトラブルシューティング手順では、特に暗黙的な拒否エラーではなく、明示的な拒否エラーを扱います。暗黙的な拒否エラーの詳細については、「暗黙的な拒否と明示的な拒否の違い」を参照してください。

解決方法

明示的な拒否エラーは、次のポリシーに 1 つでも問題があると発生します。

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

アイデンティティベースのポリシー

アイデンティティベースのポリシーは、エンティティの許可/拒否アクションを制御します。これらのトラブルシューティング手順を踏んで、アイデンティティベースのポリシーに関する問題を特定します。

注: 特権アクセスを誤って付与しないように、StringNotLike で Deny を使用するのがベストプラクティスです。

1.    アイデンティティベースのポリシーに拒否ステートメントがないことを確認します。この例には拒否ステートメントが含まれています。

{
  "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 アイデンティティベースのポリシーとは異なり、リソースベースのポリシーはサービスごとに設計されています。次のトラブルシューティング手順では、Amazon Simple Storage Service (Amazon S3) のリソースベースのポリシーと VPC エンドポイントポリシーを例として使用します。

S3 バケットポリシー評価

Amazon S3 バケットポリシー評価は次のように機能します。

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

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

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

{
  "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 エンドポイントがリソースへのアクセスを明示的に拒否していないことを常に確認してください。

アクセス許可の境界

アクセス許可の境界は、アイデンティティベースのポリシーが 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 はメンバーアカウントまたは特定の組織単位 (OU) に関連付けられています。これは、RunInstances アクションへのアクセスを明示的に拒否します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:RunInstances"

      "Resource": "*"
    }
  ]
}

明示的な拒否エラーを解決するには、次のいずれかのアクションを実行します。

  • SCP をアカウントから切り離します。
  • 一部のユースケースを除外する条件を追加して、拒否ステートメントを変更します。例えば、この例のこの 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 呼び出しを行おうとすると、明示的な拒否エラーを生成します。セッションポリシーの拒否ステートメントを常にチェックします。

{
  "Version": "2012-10-17",
  
  "Statement": {
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    
    "Resource": "*"
  }
}

関連情報

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

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

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

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

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

トピック
セキュリティ、アイデンティティ、コンプライアンス
タグ
AWS Identity and Access Management
言語
日本語
AWS公式
AWS公式更新しました 2年前
コメントはありません

関連するコンテンツ