一般的な IAM の問題のトラブルシューティング - AWS Identity and Access Management
自分の AWS アカウントにサインインできませんアクセスキーを紛失したAWS サービスに要求を送信すると "アクセス拒否" が発生する。一時的な認証情報を使用して要求を送信すると "アクセス拒否" が発生するポリシーの変数が機能していない行った変更がすぐに表示されないことがあるiam:DeleteVirtualMFADevice を実行する権限がありませんIAM ユーザーを安全に作成するにはどうすればよいですか?

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

この情報を使用して、 AWS Identity and Access Management (IAM) を使用する際のアクセス拒否などの一般的な問題の診断と修正を行います。

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

正しい認証情報を持っていること、およびサインインに正しい方法を使用していることを確認します。詳細については、「AWS サインインまたはアカウントの問題のトラブルシューティング」をご参照ください。

アクセスキーを紛失した

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

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

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

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

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

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

  • AWS Management Console から、アクションを実行する権限がない旨のメッセージが返された場合、管理者に問い合わせて、サポートを依頼する必要があります。管理者からサインイン認証情報またはサインインリンクが提供されました。

    以下の例のエラーは、mateojackson IAM ユーザーがコンソールを使用して、架空の my-example-widget リソースの詳細を表示しようとしているが、架空の widgets:GetWidget 許可がない場合に発生します。 

    User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: widgets:GetWidget on resource: my-example-widget

    この場合、Mateo は、widgets:GetWidget アクションを使用して my-example-widget リソースにアクセスできるようにポリシーを更新してもらうよう依頼する必要があります。

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

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

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

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

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

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

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

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

  • 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 デバイスが作成されますが、アクティブ化されることはありません。新しいデバイスをユーザーに関連付ける前に、既存の MFA デバイスを削除する必要があります。

AWS では、MFA を使用して認証された場合にのみ、ユーザーが自分の仮想 MFA デバイスを削除できるようにするポリシーを推奨しています。詳細については、「AWS: MFA で認証された IAM ユーザーが [My Security Credentials] (マイセキュリティ資格情報) ページで自分の認証情報を管理できるようにする」をご参照ください。

この問題を修正するために、管理者はポリシーのアクセス許可を編集しないでください。代わりに、管理者は AWS CLI または AWS API を使用して、既存の非アクティブ化されたデバイスを削除する必要があります。

既存の非アクティブ化された MFA デバイスを削除するには

  1. アカウントの仮想 MFA デバイスを表示します。

  2. レスポンスで、修正しようとしているユーザーの仮想デバイスの ARN を見つけます。

  3. デバイスを削除します。

IAM ユーザーを安全に作成するにはどうすればよいですか?

AWS へのアクセスを必要とする従業員がいる場合は、IAM ユーザーを作成するか、認証に AWS SSO を使用するかを選択できます。IAM を使用する場合、AWS では、IAM ユーザーを作成し、その認証情報を従業員に安全に伝達することを推奨しています。従業員の隣に物理的に配置されていない場合は、安全なワークフローを使用して、従業員に認証情報を伝達します。

IAM で新しいユーザーを安全に作成するには、次のワークフローを使用します。

  1. AWS Management Console を使用して新しいユーザーを作成します。自動生成されたパスワードを使用して AWS Management Console アクセス権を付与することを選択します。必要に応じて、[Users must create a new password at next sign-in] (ユーザーは次回サインイン時に新しいパスワードを作成する必要があります) のチェックボックスをオンにします。ユーザーがパスワードを変更するまで、アクセス許可ポリシーをユーザーに追加しないでください。

  2. ユーザーを追加したら、新しいユーザーのサインイン URL、ユーザー名、およびパスワードをコピーします。パスワードを表示するには、[Show] (表示) を選択します。

  3. E メール、チャット、チケットシステムなど、社内の安全な通信方法を使用して、従業員にパスワードを送信します。別途、IAM ユーザーコンソールのリンクおよびユーザー名をユーザーに提供します。アクセス許可を付与する前に、正常にサインインできることを確認するよう従業員に伝えます。

  4. 従業員が確認したら、必要なアクセス許可を追加します。セキュリティのベストプラクティスとして、認証情報を管理するために MFA を使用した認証をユーザーに要求するポリシーを追加します。ポリシーの例については、「AWS: MFA で認証された IAM ユーザーが [My Security Credentials] (マイセキュリティ資格情報) ページで自分の認証情報を管理できるようにする」を参照してください。