IAM ポリシーを使用した際に発生する、アクセス拒否、もしくは、非認証の操作によるエラーをトラブルシュートするにはどうすればよいですか?

所要時間4分
0

AWS リソースでアクションを実行しようとして、「アクセス拒否」または「許可されていないオペレーション」エラーが表示されました。これらの許可に関する問題のトラブルシューティング方法を教えてください。

簡単な説明

AWS Identity and Access Management (IAM) ポリシーの問題をトラブルシューティングするにはどうすればよいですか?

解決方法

API の呼び出し元を特定し、エラーメッセージを理解する

重要:

IAM ポリシーを検証する前に、API コールが正しい IAM エンティティに代わって実行されていることを確認します。API のエラーメッセージに呼び出し元の情報が含まれていない場合、以下の手順に従い API の呼び出し元を特定します。

  1. AWS マネジメントコンソールを開きます。
  2. ページの右上隅で、アカウント情報の隣に表示されている矢印をクリックします。
  3. IAM ロールとしてサインインしている場合は、引き受けたロールの名前については「現在アクティブなユーザー」、アカウント ID については「アカウント ID」を参照してください。
  4. フェデレーティッドユーザーとしてサインインしている場合は、フェデレーションロール名とロールセッション名について「フェデレーティッドユーザー」を参照してください。
  • または -

AWS CLI の get-caller-identity コマンドを使用することで、API のコール元を特定できます。また、AWS CLI コマンドで --debug フラグを使用すると、以下のような出力表示を基に、認証情報の送信元を特定することもできます。

2018-03-13 16:23:57,570 - MainThread - botocore.credentials - INFO - Found credentials in shared credentials file: ~/.aws/credentials

IAM ポリシーの許可を確認する

添付されている IAM ポリシーを確認することで、API のコール元に対し適切な許可が与えられているか検証します。詳細については、アカウント内でのリクエストの許可または拒否の決定を参照してください。

AWS Organizations SCP を評価する

AWS アカウントが AWS 組織の一部である場合、 SCP を階層レベルで適用して、アクションを許可または拒否できます。SCP 許可は、AWS アカウントのすべての IAM エンティティに継承されます。API コール元が SCP で明示的に拒否されていないことを確認します。

コール元に影響する組織の SCP ポリシーで、コールされている API が明示的に拒否されていないことを確認する

アイデンティティベースおよびリソースベースのポリシーを確認する

API コール元の IAM エンティティのアイデンティティベースのポリシーに、明示的な allow ステートメントがあることを確認します。次に、API がリソースレベルの許可をサポートしていることを確認します。API コール元がリソースレベルの許可をサポートしていない場合は、IAM ポリシーステートメントの resource 要素にワイルドカード**「*」** が指定されていることを確認します。

AWS のサービス内のリソースにリソースベースのポリシーを添付して、アクセスを提供できます。詳細については、「アイデンティティベースおよびリソースベースのポリシー」を参照してください。

IAM ポリシー概要を表示するには、以下を実行します。

  1. IAM コンソールを開きます。
  2. ナビゲーションペインで、[ポリシー] をクリックします。
  3. ポリシー名の隣にある矢印をクリックし、ポリシーの詳細表示を展開します。

次の例では、すべての Amazon Elastic Compute Cloud (Amazon EC2) API アクションがリソースレベルの許可をサポートしているわけではないため、ポリシーは機能しません。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SorryThisIsNotGoingToWorkAsExpected",
            "Effect": "Allow",
            "Action": ["ec2:*"],
            "Resource": "arn:aws:ec2:us-east-1:accountid:instance/*"
        }
    ]
}

IAM ユーザーが run-instances AWS CLI コマンドを使用して us-east-1 リージョンで Amazon EC2 インスタンスを起動しようとすると、次のようなエラーメッセージが表示されます。

"An error occurred (UnauthorizedOperation) when calling the RunInstances operation: You are not authorized to perform this operation. Encoded authorization failure message:…"

この問題を解決するには、リソースをワイルドカード**「*」** に変更します。これは、Amazon EC2 では部分的なリソースレベルの許可しかサポートしていないためです。

認証失敗メッセージをデコードして、この失敗の理由に関する詳細を取得するには、次のような DecodeAuthorizationMessage API アクションを使用します。

$ aws sts decode-authorization-message --encoded-message <encoded-message-from-the-error>

許可の境界を確認する

IAM エンティティにアクセス許可の境界がアタッチされている場合、エンティティが持つ最大のアクセス許可はその境界によって設定されます。

セッションポリシーを評価する

API コール元が IAM ロールまたはフェデレーティッドユーザーの場合、セッションの期間中、セッションポリシーが渡されます。セッションの許可は、セッションの作成に使用される IAM エンティティの ID ベースのポリシーとセッションポリシーが交差する部分です。API コールが IAM ポリシーとエンティティに存在することを確認します。

ポリシー内の条件キーが API でサポートされていることを確認する

AWS 条件キーを使用すると、AWS に対して行われた API リクエストの要素と IAM ポリシーで指定されたキー値を比較できます。条件キーは、グローバル条件キーにすることも、AWS のサービスによって定義することもできます。AWS のサービス固有の条件キーは、そのサービス内でのみ使用できます (EC2 API アクションの EC2 条件など)。詳細については、「AWS のサービスのアクション、リソース、条件コンテキストキー」を参照してください。

条件要素には複数の条件を含めることができ、各条件ブロック内に複数のキーと値のペアを含めることができます。詳細については、「複数のキーまたは値を持つ条件を作成する」を参照してください。

このポリシーの例では、IAM の API リクエストが IAM ユーザー admin によりコールされ、なおかつ 送信元 IP アドレスが 1.1.1.0/24 または 2.2.2.0/24 である場合に、条件が適合します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:username": "admin"
        },
        "IpAddress": {
          "aws:SourceIp": [
            "1.1.1.0/24",
            "2.2.2.0/24"
          ]
        }
      }
    }
  ]
}

IAM ポリシーのエラーとトラブルシューティング例

エラーメッセージ、API の呼び出し元、API、および呼び出されているリソースの特定には、次に示す例を参考にしてください。

エラーメッセージの例API の呼び出し元APIリソース発生タイミング
A: 「An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.」不明DescribeInstances不明エラー発生時
B: "An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::123456789012:user/test is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/EC2-FullAccess(AssumeRole 処理の呼び出し中にエラー (AccessDenied) が発生しました: User: ser: arn:aws:iam::123456789012:user/test は resource: arn:aws:iam::123456789012:role/EC2-FullAccess の sts:AssumeRole を実行する権限がありません)"arn:aws:iam::123456789012:user/testAssumeRolearn:aws:iam::123456789012:role/EC2-FullAccessエラー発生時
C: "An error occurred (AccessDenied) when calling the GetSessionToken operation: Cannot call GetSessionToken with session credentials(GetSessionToken 処理の呼び出し中にエラー (AccessDenied) が発生しました: セッションの認証情報で GetSessionToken を呼び出せません)"不明GetSessionToken不明エラー発生時
D: 「An error occurred (UnauthorizedOperation) when calling the AssociateIamInstanceProfile operation: You are not authorized to perform this operation.Encoded authorization failure message: ...(AssociateIamInstanceProfile 処理の呼び出し中にエラー (UnauthorizedOperation) が発生しました: この処理を実行する権限がありません。エンコードされた認証エラーメッセージ: ....) 」不明AssociateIamInstanceProfile不明エラー発生時

さまざまな AWS のサービスで、アクセス許可の問題に関してエラーメッセージを受け取る可能性がありますが、この評価メソッドを利用することで、その原因を特定できます。詳細については、以下のエラーメッセージとトラブルシューティングの手順を参照してください。

エラーメッセージの例 A:

このエラーメッセージは、DescribeInstances API のコール許可がないことを示します。

この問題を解決するには、以下の手順を実行します。

  1. API のコール元を特定します。
  2. どの拒否ステートメントにも、ec2:DescribeInstances API アクションが含まれていないことを確認します。
  3. ec2:DescribeInstances API アクションが許可ステートメントに含まれていることを確認します。
  4. この API アクション用に指定されたリソースが存在しないことを確認します。注意: この API アクションでは、リソースレベルの許可はサポートされません。
  5. 許可ステートメント内で指定したすべての IAM 条件が、DescribeInstances アクションによりサポートされていること、また、条件が適合していることを確認します。

詳細については、DescribeInstanceStatus を参照してください。

エラーメッセージの例 B:

このエラーメッセージには、API の名前、API の呼び出し元、ターゲットリソースが含まれています。API をコールした IAM ID に、リソースに対する正しいアクセス権があることを確認します。以前の評価方法を使用して IAM ポリシーを確認します。

このエラーを解決するには、次の手順に従って IAM ロール EC2-FullAccess の信頼ポリシーを確認します。

  1. arn:aws:iam::123456789012:user/test、または、arn:aws:iam::123456789012:root が、信頼ポリシーのいかなる拒否ステートメントにも含まれていないことを確認します。
  2. arn:aws:iam::123456789012:user/test、または、arn:aws:iam::123456789012:root が、信頼ポリシーの許可ステートメントに含まれていることを確認します。
  3. 許可ステートメント内で指定されたすべての IAM 条件が、sts:AssumeRole API アクションでサポートされており、条件が適合していることを確認します。

API コール元 (arn:aws:iam::123456789012:user/test) に添付された IAM ポリシーを確認するには、次の手順に従います。

  1. sts:AssumeRole API アクションによるどの拒否ステートメントにも、arn:aws:iam::123456789012:role/EC2-FullAccess が含まれていないことを確認します。
  2. arn:aws:iam::123456789012:root が信頼ポリシーの許可ステートメントに含まれる場合は、sts:AssumeRole API アクションを含む IAM ポリシーの許可ステートメントに、arn:aws:iam::123456789012:role/EC2-FullAccess が含まれていることを確認します。
  3. 許可ステートメント内で指定されたすべての IAM 条件が、sts:AssumeRole API アクションでサポートされており、条件が適合していることを確認します。

エラーメッセージの例 C:

このエラーメッセージは、get-session-token一時的な認証情報によりサポートされていないことを示しています。詳細については、AWS STS API オペレーションの比較、を参照してください。

エラーメッセージの例 D:

このエラーメッセージは、認証エラーの詳細を示すエンコードされたメッセージを返しています。エラーメッセージをデコードしてアクセス許可のエラーに関する詳細を知るには、DecodeAuthorizationMessage を参照します。エラーメッセージをデコードした後、API の呼び出し元を特定し、リソースレベルのアクセス許可と条件を確認します。

このエラーを解決するには、次の手順に従って IAM ポリシーの許可を確認します。

  1. エラーメッセージにより、API の拒否が明示的に示されている場合は、適合するステートメントから ec2:AssociateIamInstanceProfile、もしくは、iam:PassRole API アクションを削除します。
  2. ec2:AssociateIamInstanceProfile と iam:PassRole が、サポートされた正しいリソースターゲットとともに、許可ステートメント内にあることを確認します。例えば、ec2:AssociateIamInstanceProfile API アクションのリソースターゲットが EC2 インスタンスであり、iam:PassRole のリソースターゲットが IAM ロールであることを確認します。
  3. ec2:AssociateIamInstanceProfile および iam:PassRole API アクションが同一の許可ステートメント内にある場合は、すべての条件が ec2:AssociateIamInstanceProfile および iam:PassRole API アクションでサポートされていること、また、条件が適合していることを確認します。
  4. ec2:AssociateIamInstanceProfile と iam:PassRole API アクションが、別の許可ステートメント内にある場合は、それぞれの許可ステートメント内で、すべての条件がそのアクションによりサポートされていることと、条件が適合していることを確認します。

詳細については、ポリシー評価ロジックおよびアカウント内でリクエストを許可するか拒否するかを判断するを参照してください。


関連情報

IAM ポリシーのトラブルシューティング

クロスアカウント IAM ロールの継承を試みると、「AccessDenied」または「Invalid information」というエラーが発生するのはなぜですか?

IAM JSON ポリシーの要素のリファレンス

コメントはありません

関連するコンテンツ