Comment résoudre les problèmes d'accès refusé pour un utilisateur root ou administrateur ?

Lecture de 5 minute(s)
0

J'ai reçu une erreur d'accès refusé pour mon utilisateur root ou mon entité AWS Identity and Access Management (IAM) à laquelle des autorisations administrateur ont été ajoutées. Comment dépanner et résoudre les problèmes d'accès refusé ?

Brève description

Il existe plusieurs raisons pour lesquelles vous pouvez recevoir une erreur d'accès refusé pour votre utilisateur root ou votre entité IAM à laquelle des autorisations administrateur ont été ajoutées. Cela inclut :

  • Une politique de contrôle des services (SCP) restreint votre accès à un service
  • Une politique basée sur des ressources restreint votre accès à une ressource
  • Une limite d'autorisations limite les actions que votre entité peut effectuer
  • Une politique de session est en place et cause un problème d'autorisation
  • Une politique de point de terminaison d'un VPC restreint l'accès à vos entités IAM

Utilisez les étapes de résolution ci-dessous, en fonction de votre cas d'utilisation et de l'erreur que vous recevez.

Solution

Résoudre les problèmes d'autorisation pour les utilisateurs root

Bien que vous ne puissiez pas restreindre les autorisations d'un utilisateur root à l'aide de politiques IAM, vous pouvez restreindre un utilisateur root d'un compte membre d'AWS Organizations à l'aide d'une politique de contrôle des services (SCP). Vérifiez s'il existe des restrictions provenant d'une SCP en utilisant le compte de gestion de votre Organization.

Cet exemple montre une politique de contrôle des services qui refuse l'accès à Amazon Simple Storage Service (Amazon S3) pour un utilisateur root. Pour ce faire, elle utilise la clé de condition aws:PrincipleArn et une valeur qui correspond à l'ARN du root au format arn:aws:iam::<<accountIAD>:root.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "s3:*"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:root"
          ]
        }
      }
    }
  ]
}

Résoudre les problèmes d'autorisation pour les entités IAM avec des autorisations administrateur attribuées

Bien qu'une entité IAM puisse avoir une politique en place qui accorde un accès de niveau administrateur, elle peut également être restreinte par d'autres types de politiques. Pour plus d'informations, consultez Résolution des messages d'erreur d'accès refusé et Types de politiques. Utilisez les instructions suivantes pour comprendre les politiques qui pourraient restreindre l'accès de votre entité IAM :

  • Une SCP d'Organization peut restreindre l'accès aux entités IAM des comptes membres. Vérifiez s'il existe des restrictions provenant d'une SCP en utilisant le compte de gestion de l'Organization.
  • Les politiques basées sur des ressources peuvent restreindre l'accès d'une entité IAM aux ressources. Un exemple de politique basée sur des ressources est une politique de compartiment Amazon S3. Pour suivre la prise en charge des politiques basées sur des ressources par un service, consultez Services AWS qui fonctionnent avec IAM.
  • Une limite d'autorisations définit les autorisations maximales qu'une politique basée sur une identité peut accorder à une entité. Si vous utilisez une limite d'autorisations, l'entité ne peut effectuer que les actions autorisées à la fois dans la politique basée sur une identité et dans la limite d'autorisations. Vérifiez si une limite d'autorisations est affectée à l'utilisateur ou au rôle à l'aide de la console IAM.
  • Les politiques de session peuvent être transmises de manière programmatique lorsque vous créez une session temporaire pour votre rôle IAM pour un utilisateur fédéré. Les autorisations d'une session sont à l'intersection des politiques basées sur une identité attribuées à l'entité IAM pour laquelle la session est créée et de la politique de session elle-même. Vérifiez si une politique de session est passée pour votre session de rôle IAM en utilisant les journaux AWS CloudTrail pour les appels d'API AssumeRole/AssumeRoleWithSAML/AssumeRoleWithWebIdentity. Pour vérifier si des politiques de session ont été passées pour une session d'utilisateur fédéré, consultez les journaux CloudTrail pour les appels d'API GetFederationToken. Pour plus d'informations sur chacun de ces appels d'API, consultez Actions.
  • Une politique de point de terminaison d'un VPC est une politique basée sur des ressources que vous pouvez attacher à un point de terminaison d'un VPC. Elle peut restreindre l'accès aux entités IAM. Si vous acheminez vos requêtes via un point de terminaison d'un VPC, vérifiez s'il existe des restrictions provenant de la politique de point de terminaison d'un VPC associée. Pour plus d'informations, consultez Utilisation des politiques de point de terminaison d'un VPC.

Résoudre les messages d'erreur d'accès refusé pour les ressources Amazon S3

Pour plus d'informations sur la résolution des messages d'erreur d'accès refusé pour les ressources Amazon S3, consultez Comment résoudre les erreurs 403 Access Denied (Accès refusé) d'Amazon S3 ?

Résoudre les problèmes d'autorisation lors de l'accès à la console AWS Billing and Cost Management

Les entités IAM disposant d'autorisations administrateur rencontrent parfois des problèmes d'autorisation lorsqu'elles tentent d'accéder à la console Billing and Cost Management. Activez l'accès de l'utilisateur/rôle IAM à la console Billing and Cost Management, comme indiqué à l'étape 1 du didacticiel IAM : Déléguer l'accès à la console de facturation. L'entité IAM n'est pas capable d'accéder à ces données sans avoir effectué cette étape, ainsi que l'ajout des autorisations IAM nécessaires.

Pour résoudre tout problème d'autorisation connexe, vérifiez si votre entité IAM a été activée en tant qu'utilisateur root.


Informations connexes

Comment résoudre les erreurs 403 Access Denied (Accès refusé) d'Amazon S3 ?

Présentation de la gestion des accès : Autorisations et politiques

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans