Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Contrôle de l'accès à la console à l'aide de politiques basées sur les ressources et de politiques de contrôle des ressources

AWS Sign-In prend en charge les politiques basées sur les ressources et les politiques de contrôle des ressources (RCP) pour contrôler l'accès à. AWS Sign-In Utilisez ces politiques pour vérifier l'identité de l'utilisateur et l'emplacement du réseau tout au long de l' AWS Management Console accès, avant, pendant et après l'authentification. Pour les utilisateurs root, ces politiques valident l'emplacement du réseau et l'identité de l'utilisateur avant le début de la collecte des informations d'identification. Les informations d'identification ne peuvent être saisies que lorsque l'accès provient des réseaux attendus.

AWS Sign-In politiques basées sur les ressources :

Politiques de contrôle des ressources (RCP) :

Les deux types de politique vérifient l'accès avant l'authentification. Cela empêche les principaux d'accéder à la page de connexion depuis des réseaux inattendus.

Ces politiques ne remplacent pas les politiques basées sur l'identité IAM, qui continuent de s'appliquer.

AWS Sign-In les politiques basées sur les ressources et les RCP s'appliquent aux méthodes d'authentification suivantes :

Ces contrôles ne s'appliquent pas à l'accès programmatique à l'aide de clés d'accès (AWS SDK ou appels d'API signés avec SigV4).

Comment ? AWS Sign-In évalue les politiques basées sur les ressources

AWS Sign-In évalue les politiques basées sur les ressources ou les politiques de contrôle des ressources (RCP) applicables à deux moments lors de l'accès à la console : avant l'authentification (phase de pré-authentification) et après authentification réussie (phase de post-authentification). Chaque évaluation vérifie les clés de condition définies dans votre politique. Les touches disponibles dépendent de la phase et de l'action. Pour en savoir plus, consultez Clés de condition prises en charge.

Après l'authentification, l'évaluation prend également en compte les politiques basées sur l'identité du principal. Une politique IAM qui refuse l'action de connexion appropriée peut empêcher l'octroi de la session de console, même lorsque les conditions du réseau sont remplies.

Actions prises en charge

AWS Sign-In les politiques relatives aux ressources (politiques basées sur les ressources et RCP) soutiennent les actions suivantes :

Clés de condition prises en charge

AWS Sign-In prend en charge les clés de condition suivantes dans les politiques basées sur les ressources et les politiques de contrôle des ressources (RCP). Utilisez ces touches pour contrôler l'accès à la console en fonction de l'emplacement du réseau et de l'identité principale :

Pour les règles d'utilisation détaillées, la compatibilité des opérateurs, les restrictions de combinaison et la matrice de disponibilité par action, voirAWS Sign-In référence des clés de condition.

Commencer à contrôler l'accès à la console à l'aide de politiques de ressources

Conditions préalables

Spécifiez toutes --region us-east-1 les opérations d'écriture sur AWS Sign-In les politiques. AWS reproduit les politiques de cette région dans le monde entier. Les opérations de lecture peuvent cibler n'importe quelle région.

Étape 1 : créer des déclarations d'autorisation relatives aux ressources

Créez des déclarations d'autorisation qui définissent vos contrôles d'accès. Toutes les opérations d'écriture sont requises --region us-east-1 (le AWS Sign-In service accepte les modifications de politique uniquement dans cette région). Les autres paramètres (--source-vpc,--source-ip,--requested-region,--excluded-principal) définissent les conditions de votre politique. Par exemple, --requested-region us-west-2 ajoute une condition limitant la connexion au point de terminaison de connexion régional us-west-2.

Exemple — Restreindre l'accès au VPC d'entreprise :

aws signin put-resource-permission-statement \
  --source-vpc vpc-0abc123def456789 \
  --requested-region us-west-2 \
  --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \
  --client-token unique-request-id-12345 \
  --region us-east-1

Exemple — Restreindre l'accès à une plage d'adresses IP spécifique :

aws signin put-resource-permission-statement \
  --source-ip "IP_ADDRESS" \
  --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \
  --region us-east-1

Étape 2 : activer la configuration des autorisations de console

L'étape suivante active l'application des politiques pour le processus de connexion à la console sur votre compte ou votre organisation. Les déclarations d'autorisation des ressources peuvent être créées à tout moment, mais elles ne sont pas évaluées tant que l'autorisation de la console n'est pas activée.

Pour les comptes autonomes :

aws signin put-console-authorization-configuration \
  --target-id <your-aws-account-id> \
  --region us-east-1

Pour les organisations AWS :

aws signin put-console-authorization-configuration \
  --target-id <your-aws-organization-id> \
  --region us-east-1

Vérifiez la configuration :

aws signin get-console-authorization-configuration \
  --target-id <your-target-id> \
  --region <your-region>

Supprimez la configuration d'autorisation de la console :

aws signin delete-console-authorization-configuration \
  --target-id <your-target-id> \
  --region us-east-1

Étape 3 : Vérifiez votre politique

Répertoriez toutes les déclarations d'autorisation :

aws signin list-resource-permission-statements \
  --max-results 50 \
  --region <your-region>

Récupérez la politique consolidée complète :

aws signin get-resource-policy \
  --region <your-region>

La get-resource-policy commande renvoie la politique complète basée sur les ressources composée de toutes vos déclarations d'autorisation. Passez en revue cette politique pour vous assurer qu'elle reflète les contrôles d'accès prévus avant de tester l'accès à la console.

Disponibilité par région

Les API d'autorisation de console sont disponibles dans toutes les régions AWS commerciales. Vous pouvez appeler ces API depuis n'importe quelle région dans laquelle vous opérez.

Comprendre la structure des politiques

AWS Sign-In les politiques contiennent deux instructions qui protègent les différentes phases du flux de connexion à la console :

Les deux instructions sont obligatoires car la connexion à la console utilise OAuth 2.0, qui exécute les trois actions de manière séquentielle. Une politique comportant une seule déclaration laisse l'autre phase sans protection. signin:PrincipalArnprend en charge les types d'utilisateur root, d'utilisateur IAM et de rôle principal. aws:PrincipalArnprend en charge tous les principaux types (utilisateur root, utilisateur IAM, utilisateur fédéré, rôle).

Exemples de politiques

Exemple 1 : RCP avec périmètre réseau et principaux exclus

La politique de contrôle des ressources (RCP) suivante interdit la AWS Management Console connexion depuis l'extérieur de votre réseau d'entreprise pour tous les comptes de votre organisation. Les principaux exclus désignés sont exemptés en cas d'accès d'urgence. Étant donné que les identifiants VPC ne sont uniques qu'au sein d'une région, la politique inclut une troisième instruction qui identifie l' VPC-based accès à la région attendue.

La EnforceNetworkPerimeterPreAuth déclaration est utilisée signin:PrincipalArn pour exempter les principaux exclus pendant la phase de pré-authentification. La EnforceNetworkPerimeterPostAuth déclaration est utilisée aws:PrincipalArn pour exempter les principaux exclus après authentification. L'EnforceSourceVPCRegioninstruction garantit que la région de demande correspond à la région VPC, en limitant l'accès à la région attendue pour le VPC spécifié.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceNetworkPerimeterPreAuth",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["signin:Authenticate"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "signin:PrincipalArn": [
            "arn:aws:iam::111122223333:root",
            "arn:aws:iam::444455556666:root",
            "arn:aws:iam::777788889999:user/EmergencyUser",
            "arn:aws:iam::777788889999:role/OrgBreakGlassRole"
          ]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringNotEquals": {
          "aws:SourceVpc": "<my-vpc>"
        }
      }
    },
    {
      "Sid": "EnforceNetworkPerimeterPostAuth",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::111122223333:root",
            "arn:aws:iam::444455556666:root",
            "arn:aws:iam::777788889999:user/EmergencyUser",
            "arn:aws:iam::777788889999:role/OrgBreakGlassRole"
          ]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringNotEquals": {
          "aws:SourceVpc": "<my-vpc>"
        }
      }
    },
    {
      "Sid": "EnforceSourceVPCRegion",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "signin:Authenticate",
        "signin:CreateOAuth2Token",
        "signin:AuthorizeOAuth2Access"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "<my-vpc>"
        },
        "StringNotEqualsIfExists": {
          "aws:RequestedRegion": "<my-vpc-region>"
        }
      }
    }
  ]
}

Cette politique :

Exemple 2 : Resource-based politique d' IP-based accès avec principal exclu

La politique basée sur les ressources suivante refuse l'accès à la console à tous les principaux effectuant des demandes en dehors de la plage d'adresses IP spécifiée, les principaux exclus étant exemptés. La politique contient deux instructions : une instruction de pré-authentification qui utilise la signin:PrincipalArn clé spécifique au service et une instruction de post-authentification qui utilise la clé globale. aws:PrincipalArn

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": ["signin:Authenticate"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "signin:PrincipalArn": "<excluded-principal-arn>"
        },
        "NotIpAddress": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringEquals": {
          "aws:ResourceAccount": "<my-aws-account-id>"
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": { "AWS": "*" },
      "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
      "Resource": "*",
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "<excluded-principal-arn>"
        },
        "NotIpAddress": {
          "aws:SourceIp": "<my-corporate-cidr>"
        },
        "StringEquals": {
          "aws:ResourceAccount": "<my-aws-account-id>"
        }
      }
    }
  ]
}

Cette politique :

Bonnes pratiques

Configurer les principaux exclus pour un accès de restauration d'urgence

AWS recommande de configurer au moins un utilisateur exclu avant d'appliquer les politiques d'autorisation de console en production. Au stade de la pré-authentification, la clé de signin:PrincipalArn condition exempte l'utilisateur root, l'utilisateur IAM et les principaux de rôle. Au stade de la post-authentification, la clé de aws:PrincipalArn condition exempte tous les types principaux (utilisateur root, utilisateur IAM, utilisateur fédéré, rôle).

Les principaux exclus sont facultatifs, mais leur omission augmente le risque de verrouillage du compte si les conditions du réseau changent de façon inattendue ou si les politiques sont mal configurées.

Étapes de configuration principales exclues recommandées :

Gérez les chemins d'accès à la restauration

Outre le principal exclu décrit ci-dessus, assurez-vous que d'autres méthodes d'accès sont disponibles au cas où les politiques d'autorisation de la console bloqueraient la connexion de manière inattendue :

Test avant le déploiement en production

AWS recommande de ne pas associer de RCP restrictifs à la racine de votre organisation sans avoir testé de manière approfondie l'impact de la politique sur les comptes. Créez plutôt une unité d'organisation dans laquelle vous pouvez déplacer vos comptes un par un, ou du moins en petit nombre, afin de ne pas empêcher les utilisateurs d'accéder à des comptes clés par inadvertance.

Flux de travail de test :

Conception avec défense en profondeur

Utilisez les politiques AWS Sign-In basées sur les ressources et les politiques de contrôle des ressources comme couche dans le cadre d'une stratégie de sécurité plus large. AWS Sign-In les politiques limitent l'accès à la console en fonction de l'emplacement du réseau et de l'identité principale. Combinez-les avec d'autres types de politiques pour créer des contrôles d'accès complets :

Surveiller et auditer en permanence

AWS CloudTrail enregistre automatiquement toutes les évaluations des AWS Sign-In politiques et les modifications de configuration. Consultez ces CloudTrail événements dans l'historique des événements pendant 90 jours maximum. Pour une rétention plus longue, transmettez les événements à Amazon S3 en créant un suivi (voir Création d'un suivi). Pour des alertes en temps réel, créez des EventBridge règles Amazon adaptées aux AWS Sign-In événements, configurez votre journal pour qu'il soit envoyé à un groupe de CloudWatch journaux pour les alarmes basées sur des filtres métriques, ou transférez les événements vers votre solution SIEM existante.

Cas d’utilisation

Résolution des problèmes liés au contrôle d'accès à

Je ne peux pas me connecter en raison de l'état du réseau dans les politiques basées sur les Sign-in ressources

L'un des messages d'erreur suivants peut s'afficher lorsque l'accès est refusé par une AWS Sign-In politique :

Si vous constatez l'une de ces erreurs et pensez que votre accès devrait être autorisé, contactez votre AWS administrateur. Ils peuvent consulter CloudTrail les journaux pour détecter les ConsoleLogin événements portant la mention errorMessage « Autorisation refusée en raison d'une politique basée sur les ressources » ou « Autorisation refusée en raison d'une politique de contrôle des ressources » afin d'identifier la déclaration de politique refusant l'accès.

Causes possibles :

Résolution :

Pour les administrateurs diagnostiquant ce problème :

L'accès à mon compte est bloqué après avoir activé l'autorisation de la console

Si vous avez configuré l'autorisation de console et que vous ne pouvez plus accéder à votre compte, il se peut que vous n'ayez pas configuré les principaux exclus avant d'appliquer la politique.

Il existe plusieurs moyens de récupérer l'accès, en fonction du type de compte et des informations d'identification disponibles.

Option 1 : Utiliser l'accès par programmation (AWS CLI ou SDK)

Les politiques d'autorisation de console s'appliquent uniquement à la connexion à la console interactive. Ils ne s'appliquent pas aux demandes d'API signées avec SigV4. Si vous disposez d'un accès programmatique (par exemple, des clés d'accès existantes, un rôle multicompte), utilisez-le pour appeler signin:DeleteConsoleAuthorizationConfiguration et supprimer la politique de restriction. Les informations d'identification que vous utilisez doivent être autorisées à appelersignin:DeleteConsoleAuthorizationConfiguration. La politique AWSSignInResourcePolicyManagement gérée inclut cette autorisation. AWS recommande des informations d'identification temporaires plutôt que des clés d'accès utilisateur IAM à long terme. Pour les comptes membres, les administrateurs des comptes de gestion peuvent OrganizationAccountAccessRole accéder au compte membre pour obtenir des informations d'identification temporaires. Ce rôle n'est pas créé automatiquement dans les comptes invités à rejoindre l'organisation.

aws signin delete-console-authorization-configuration \
  --target-id <your-aws-account-id> \
  --region us-east-1

Ou supprimez des déclarations d'autorisation spécifiques :

# First, list statements to get the statement ID
aws signin list-resource-permission-statements \
  --region us-east-1

# Then delete the problematic statement
aws signin delete-resource-permission-statement \
  --statement-id <statement-id> \
  --region us-east-1

Option 2 : Contacter le AWS Support

Si vous ne disposez pas d'un accès programmatique et que vous ne pouvez pas utiliser le OrganizationAccountAccessRole pour accéder au compte, contactez le AWS Support pour lancer le processus de rétablissement du verrouillage.

Le processus de restauration fonctionne comme suit :

Le lien du portail de restauration expire 72 heures après son partage par le AWS Support. Si vous n'effectuez pas la restauration dans cette fenêtre, contactez le AWS Support pour relancer le processus.

Une fois l'accès rétabli :

Les modifications que j'apporte ne sont pas toujours visibles immédiatement

Les modifications de politique sont répliquées à l'échelle mondiale, mais la réplication peut prendre quelques minutes.

Résolution :

aws signin get-resource-policy --region <your-region>

Problèmes courants liés à la réplication des politiques :