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 la localisation réseau tout au long de l' Console de gestion AWS accès, avant, pendant et après l'authentification. Pour les utilisateurs root, ces politiques valident la localisation 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 prévus.

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

Politiques de contrôle des ressources (RCP) :

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

Ces politiques ne remplacent pas les politiques IAM basées sur l'identité, 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 fondé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 une 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 du directeur fondées sur l'identité. 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 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 réseau et de l'identité principale :

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

Premiers pas avec le contrôle d'accès à la console à l'aide de politiques de ressources

Conditions préalables

Spécifiez --region us-east-1 pour toutes les opérations d'écriture sur AWS Sign-In les politiques. AWS reproduit les politiques de cette région à l'échelle mondiale. Les opérations de lecture peuvent cibler n'importe quelle région.

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

Créez des déclarations d'autorisation qui définissent vos contrôles d'accès. Toutes les opérations d'écriture sont --region us-east-1 obligatoires (le AWS Sign-In service accepte les changements 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 de l'autorisation de la console

L'étape suivante active l'application des politiques pour le processus de connexion à la console de votre compte ou de votre organisation. Les instructions 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. Consultez 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 exercez vos activités.

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 effectue 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 types principaux (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 Console de gestion AWS connexion depuis l'extérieur de votre réseau d'entreprise pour tous les comptes de votre organisation. Les directeurs d'école exclus désignés sont exemptés pour l'accès d'urgence. Étant donné que les ID VPC ne sont uniques qu'au sein d'une région, la politique inclut une troisième instruction qui épingle l' VPC-based accès à la région attendue.

La EnforceNetworkPerimeterPreAuth déclaration est utilisée signin:PrincipalArn pour exempter les mandants exclus pendant la phase de pré-authentification. La EnforceNetworkPerimeterPostAuth déclaration est utilisée aws:PrincipalArn pour exempter les mandants exclus après authentification. L'EnforceSourceVPCRegioninstruction garantit que la région de demande correspond à la région VPC, limitant ainsi 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 un principal exclu

La politique basée sur les ressources suivante refuse l'accès à la console à tous les principaux effectuant des demandes depuis l'extérieur de la plage IP spécifiée, un principal exclu étant exempté. 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 la 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 rôles. Au stade de 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 principaux exclus sont facultatifs, mais leur omission augmente le risque de verrouillage du compte si les conditions du réseau changent de manière inattendue ou si les politiques sont mal configurées.

Étapes de configuration recommandées pour les principaux exclus :

Gérer 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 vous 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 vers un seul compte à la fois, ou du moins en petit nombre, afin de ne pas empêcher par inadvertance les utilisateurs d'accéder à des comptes clés.

Flux de travail de test :

Concevez avec une défense en profondeur

Utilisez les politiques AWS Sign-In basées sur les ressources et les politiques de contrôle des ressources comme une seule couche au sein 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 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. Affichez ces CloudTrail événements dans l'historique des événements pendant 90 jours maximum. Pour une rétention plus longue, diffusez des événements sur Amazon S3 en créant un historique (voir Création d'un historique). Pour les alertes en temps réel, créez des EventBridge règles Amazon qui correspondent aux AWS Sign-In événements, configurez votre historique pour qu'il soit transmis à un groupe de CloudWatch journaux Logs 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 l'une de ces erreurs s'affiche et que vous pensez que votre accès doit ê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 quelle déclaration de politique a refusé l'accès.

Causes possibles :

Résolution :

Utilisateurs du portail IAM Identity Center : l'accès à la console via le portail IAM Identity Center n'est actuellement pas compatible avec AWS Sign-In les politiques qui limitent l'accès en fonction des clés de condition réseau. Pour rétablir l'accès des utilisateurs à IAM Identity Center, supprimez ou modifiez les clés de condition basées sur le réseau dans votre politique, ou demandez à ces utilisateurs de se connecter via une autre méthode d'authentification.

Pour les administrateurs qui diagnostiquent 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 la console et que vous ne pouvez plus accéder à votre compte, il est possible que vous n'ayez pas configuré les principaux exclus avant d'appliquer la politique.

Il existe plusieurs moyens de rétablir l'accès, en fonction de votre 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 la 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 par programmation (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 utiliser le compte membre pour obtenir des informations d'identification temporaires. Ce rôle n'est pas automatiquement créé dans les comptes qui ont été 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 par programmation et que vous ne pouvez pas l'utiliser OrganizationAccountAccessRole pour accéder à votre compte, contactez le AWS support pour lancer le processus de restauration du verrouillage.

Le processus de restauration fonctionne comme suit :

Le lien du portail de restauration expire 72 heures après que AWS Support l'ait partagé. Si vous ne terminez pas la restauration dans cette fenêtre, contactez le AWS support pour relancer le processus.

Après avoir rétabli l'accès :

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

Les modifications de politique sont répliquées dans le monde entier, 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 :