コンソールにサインインする
AWS Identity and Access Management
ユーザーガイド

AWS ドキュメント » AWS Identity and Access Management » ユーザーガイド » IAM のトラブルシューティング » 一般的な問題のトラブルシューティング

一般的な問題のトラブルシューティング

この情報を使用して、アクセス拒否された問題や、AWS Identity and Access Management (IAM) を操作するときに発生する可能性のある他の一般的な問題の診断や修復を行います。

アクセスキーを紛失しました

アクセスキーは 2 つのパートで構成されます。

  • アクセスキー識別子。これはシークレットではなく、ユーザー概要ページなど、IAM コンソールでアクセスキーがリストされるすべての場所に表示されます。

  • シークレットアクセスキー。これは最初にアクセスキーペアを作成するときに提供されます。パスワードと同じように、後で取得することはできません。シークレットアクセスキーを紛失した場合は、新しいアクセスキーペアを作成する必要があります。アクセスキーの最大数に達している場合は、既存のペアを削除してから新しいものを作成する必要があります。

詳細については、「紛失したり忘れたりしたパスワードまたはアクセスキーのリセット」を参照してください。

古いアカウントにアクセスする必要があります

AWS アカウントを初めて作成したときに、E メールアドレスとパスワードを指定しました。これらは、AWS アカウントのルートユーザー 認証情報です。パスワードを紛失または忘れたため、アクセスできなくなった古い AWS アカウントがある場合、パスワードを回復することができます。詳細については、「紛失したり忘れたりしたパスワードまたはアクセスキーのリセット」を参照してください。

E メールにアクセスできなくなった場合は、最初に E メールへのアクセス許可を回復します。回復できない場合は、AWS カスタマーサービスにお問い合わせください。

次のいずれかのオプションを使用して、E メールへのアクセス許可の回復を試みることができます。

  • E メールアドレスがホストされているドメインを所有している場合、E メールサーバーに E メールアドレスを追加し直すことができます。または、E メールアカウントのキャッチオールをセットアップできます。ドメインのキャッチオール設定は、メールサーバーに存在しない E メールアドレスに送信されたメッセージを「すべてキャッチ」します。この設定では、特定の E メールアドレスにそれらのメッセージをリダイレクトします。たとえば、AWS アカウントのルートユーザー のE メールアドレスが paulo@sample-domain.com で、ドメインの唯一のE メールアドレスを paulo.santos@sample-domain.com に変更したとします。この場合、新しい E メールをキャッチオールとして設定できます。このようにすると、AWS などだれかが paulo@sample-domain.com またはその他の text@sample-domain.com にメッセージを送信した場合、paulo.santos@sample-domain.com でそのメッセージを受信します。

  • アカウントの E メールアドレスが企業 E メールシステムの一部である場合は、IT システム管理者に連絡することをお勧めします。管理者は、E メールアドレスへのアクセス許可の回復を支援できる可能性があります。

それでも AWS アカウントにアクセスできない場合は、[I'm an AWS customer and I'm looking for billing or account support (AWS を利用しており、請求またはアカウントに関するサポートを必要としています)] メニューを展開し、[お問い合わせ] で別のサポートオプションを見つけることができます。カスタマーサービスに連絡するときは、以下の情報を指定する必要があります。

  • フルネーム、電話番号、住所、E メールアドレス、クレジットカードの最後の 4 桁を含む、アカウントにリストされているすべての詳細情報。カスタマーサービスに連絡するために、新しい AWS アカウントを作成する必要があります。これはリクエストの調査を支援するために必要です。

  • E メールアカウントにアクセスして、パスワードのリセット手順を受信できない理由。

  • アカウントを回復したら、使用していないすべてのアカウントを閉じます。課金される可能性のある、お客様の名前のオープン状態のアカウントを持たないようにすることをお勧めします。詳細については、Billing and Cost Management ユーザーガイドの「アカウントの解約」を参照してください。

自分のアカウントにサインインできません

AWS アカウントを初めて作成したときに、E メールアドレスとパスワードを指定しました。これらは、AWS アカウントのルートユーザー 認証情報です。パスワードを紛失または忘れたためアカウントにアクセスできない場合は、パスワードを回復することが可能です。詳細については、「紛失したり忘れたりしたパスワードまたはアクセスキーのリセット」を参照してください。

アカウントの E メールアドレスとパスワードを提供済みの場合、AWS は 1 回限りの検証コードの提供を必要とすることがあります。検証コードを取得するには、AWS アカウントと関連付けている E メールアドレスに Amazon Web Services からのメッセージが届いているかを確認してください。E メールアドレスには @amazon.com または @aws.amazon.com が含まれています。メッセージに記載されている手順を実行します。アカウントにメッセージが表示されない場合は、スパムフォルダを確認してください。E メールへのアクセス許可がない場合は、「古いアカウントにアクセスする必要があります」を参照してください。

AWS サービスに要求を送信すると "アクセス拒否" が発生します

  • リクエストしたアクションとリソースを呼び出すアイデンティティベースのポリシーのアクセス許可を持っていることを確認します。条件が付けられている場合、要求を送信するにはそれらの条件も満たしている必要があります。IAM ユーザー、グループ、ロールのポリシーの表示や修正の詳細については、「IAM ポリシーを管理する」を参照してください。

  • 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」を参照してください。

  • アクセス許可の境界が設定されている場合は、アクセス許可の境界として使用されているポリシーでリクエストが許可されるかどうかを確認します。リクエストがアイデンティティベースのポリシーでは許可されるが、アクセス許可の境界では許可されない場合、リクエストは拒否されます。アクセス許可の境界は、プリンシパルエンティティ (ユーザーまたはロール) に付与できるアクセス許可の上限を設定します。リソースベースのポリシーは、アクセス許可の境界では制限されません。アクセス許可の境界は一般向けの機能ではありません。AWS でポリシーを評価する詳しい方法については、「ポリシーの評価論理」を参照してください。

  • 手動で要求に署名する (AWS SDK を使用しない) 場合は、正確にリクエストに署名していることを確認します。

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

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

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

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

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

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

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

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

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

    {
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "S3BucketPolicy",
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::111122223333:role/MyRole"]},
    "Action": ["s3:PutObject"],
    "Resource": ["arn:aws:s3:::MyBucket/*"]
  }]
}

ポリシーの変数が機能していません

  • 変数のあるすべてのポリシーで、バージョン番号: "Version": "2012-10-17" がポリシーに含まれていることを確認します。正しいバージョン番号がないと、評価時に変数は置き換えられません。代わりに、変数は逐語的に評価されます。変数の含まれていないポリシーは、最新のバージョン番号が含まれていれば正常に機能します。

    Version ポリシー要素は、ポリシーバージョンとは異なります。Version ポリシーエレメントは、ポリシー内で使用され、ポリシー言語のバージョンを定義します。一方で、ポリシーバージョンは、IAM でカスタマー管理ポリシーを変更すると作成されます。変更されたポリシーによって既存のポリシーが上書きされることはありません。代わりに、IAM は管理ポリシーの新しいバージョンを作成します。Version ポリシーエレメントの詳細については、「IAM JSON ポリシーの要素:Version」を参照してください。ポリシーのバージョンの詳細については、「IAM ポリシーのバージョニング」を参照してください。

  • お客様のポリシーの変数が正しく設定されていることを確認してください。詳細については、「IAM ポリシーエレメント: 変数およびタグ」を参照してください。

行った変更がすぐに表示されないことがあります

世界中のデータセンター内のコンピューターを介してアクセスされるサービスとして、IAM は、結果整合性と呼ばれる分散コンピューティングモデルを採用しています。IAM（または他の AWS サービス）で行った変更は、すべての可能なエンドポイントから認識されるまでに時間がかかります。この遅延は、サーバー間、レプリケーションゾーン間、世界中のリージョン間でのデータ送信にかかる時間から発生している場合もあります。IAM ではパフォーマンス向上のためにキャッシュも使用しているため、これが原因で遅延が発生することがあります。変更は、以前にキャッシュされたデータがタイムアウトになるまで表示されないことがあるためです。

発生する可能性のあるこれらの遅延を考慮して、グローバルなアプリケーションを設計する必要があります。ある場所で行われた変更が他の場所で直ちに表示されない場合でも、正常に動作することを確認します。このような変更には、ユーザー、グループ、ロール、またはポリシーの作成や更新が含まれます。アプリケーションの重要で高可用性のコードパスには、このような IAM の変更を含めないことをお勧めします。代わりに、実行頻度が低い別の初期化またはセットアップルーチンに IAM の変更を加えます。また、本番稼働ワークフローが依存する前に、変更が伝達済みであることを確認します。

AWS の他のいくつかのサービスがこの遅延からどのような影響を受けるかの詳細については、以下のリソースを参照してください。

iam:DeleteVirtualMFADevice を実行する権限がありません

自分自身または他のユーザーに MFA デバイスを割り当てようとすると、次のエラーが発生する場合があります。

User: arn:aws:iam::123456789012:user/Diego is not authorized to perform: iam:DeleteVirtualMFADevice on resource: arn:aws:iam::123456789012:mfa/Diego with an explicit deny

これは、誰かが以前に IAM コンソールでユーザーに仮想 MFA デバイスの割り当てを開始し、プロセスをキャンセルした場合に発生する可能性があります。これにより、IAM でユーザー用の MFA デバイスが作成されますが、ユーザーと完全に関連付けられることはありません。IAM コンソールでは、新しいデバイスをユーザーに関連付ける前に、古い MFA デバイスを削除する必要があります。仮想 MFA デバイスを削除することを許可するポリシーがない場合は、新しい MFA キーをユーザーに関連付けるためのアクセスが拒否されます。