Définition de permissions pour activer les comptes pour les nouvelles régions AWS

A la date de publication de l’article, Le cloud AWS comprend de 22 régions et 69 zones de disponibilité. Rendez-vous sur la page dédiée aux différentes régions pour les derniers déploiements de services et projets d’expansion. Dans ce contexte en perpétuelle évolution, nos clients nous ont exprimé le souhait d’avoir un moyen plus facile de contrôler les régions où leurs comptes AWS sont exploités. Sur la base de ces retours, AWS modifie le comportement par défaut pour toutes les futures régions afin que les clients puissent choisir les comptes qu’ils souhaitent opérer dans chaque nouvelle région.

Pour les nouvelles régions AWS, les ressources de gestion des identités et des accès (IAM) telles que les utilisateurs et les rôles ne seront transmises qu’aux régions que vous activez.

Au lancement d’une nouvelle région, vous devrez l’activer pour votre compte avant de pouvoir créer et gérer des ressources dans cette région. Vous pouvez l’activer via la Console AWS dans : Mon compte > Paramètre Régions AWS.
Pour le moment, il n’y a aucun changement aux régions AWS existantes.

Nous vous recommandons de vérifier qui, dans votre compte, aura accès à l’activation et à la désactivation des régions AWS. En plus, vous pouvez vous préparer à ce changement en définissant des permissions pour que seuls les administrateurs de compte approuvés puissent activer et désactiver les régions AWS. Vous pouvez dès à présent utiliser les politiques de permissions IAM pour contrôler quels sont les principaux IAM (utilisateurs et rôles) qui peuvent effectuer ces actions.

Dans ce post, nous décrivons les nouvelles permissions de compte pour l’activation et la désactivation des nouvelles régions AWS ainsi que les mises à jour que nous avons effectuées pour refuser ces permissions dans la politique PowerUserAccess gérée par AWS que de nombreux clients utilisent pour restreindre l’accès aux actions administratives. Pour les clients qui utilisent des politiques personnalisées pour gérer l’accès administratif, nous montrerons comment sécuriser l’accès pour activer et désactiver les nouvelles régions AWS en utilisant les politiques de permissions IAM et les politiques de contrôle des services dans les organisations AWS. Enfin, nous expliquerons la compatibilité des jetons de session STS (Security Token Service) avec les Régions.

1. Permissions IAM pour activer et désactiver les nouvelles régions AWS pour votre compte

Pour contrôler l’accès afin d’activer et de désactiver les nouvelles régions AWS pour votre compte, vous pouvez définir les permissions IAM en utilisant deux nouvelles actions de compte. Par défaut, IAM refuse l’accès aux nouvelles actions à moins que vous n’ayez explicitement autorisé ces permissions dans une politique existante. Vous pouvez utiliser les politiques de permissions IAM pour autoriser ou refuser les actions d’activation et de désactivation des régions aux principaux IAM dans votre compte. Les nouvelles actions sont :

account:EnableRegion : vous permet de choisir d’ouvrir un compte dans une nouvelle région AWS (pour les régions lancées après le 20 mars 2019). Cette action propage vos ressources IAM telles que les utilisateurs et les rôles à la Région,
account:DisableRegion : vous permet de refuser un compte dans une nouvelle région AWS (pour les régions lancées après le 20 mars 2019). Cette action supprime vos ressources IAM telles que les utilisateurs et les rôles de la région.

Lors de l’octroi de permissions à l’aide des politiques IAM, certains administrateurs peuvent avoir accordé un accès sans restriction aux services AWS, sauf pour les services administratifs tels que IAM et AWS Organizations. Ces principaux IAM auront automatiquement accès aux nouvelles actions administratives de votre compte pour activer et désactiver les régions AWS. Si vous préférez ne pas fournir d’autorisations de compte pour activer ou désactiver les régions AWS à ces identités, nous vous recommandons d’ajouter une instruction à vos politiques pour refuser l’accès aux autorisations de compte. Pour ce faire, vous pouvez ajouter une instruction Deny pour toutes les actions account:*. Et au lancement de nouvelles Régions, vous pourrez spécifier les Régions où ces permissions sont accordées ou refusées.

À ce stade, les actions du compte pour activer et désactiver les régions AWS s’appliquent à toutes les régions AWS à venir lancées après le 20 mars 2019. Pour en savoir plus sur la gestion de l’accès aux régions AWS existantes, consultez le blog post suivant : Easier way to control access to AWS regions using IAM policies.

2. Mises à jour de la politique PowerUserAccess gérée par AWS

Si vous utilisez la politique PowerUserAccess gérée par AWS pour accorder des permissions aux services AWS sans accorder l’accès aux actions administratives pour IAM et Organizations, nous avons mis à jour cette politique pour exclure l’accès aux actions de compte pour activer et désactiver les nouvelles régions AWS. Vous n’avez pas besoin de prendre d’autres mesures pour restreindre ces actions aux principaux IAM auxquels cette politique s’applique. (vous pouvez voir les modifications ci-dessous).

Nous avons mis à jour le premier bloc d’instructions de la politique, qui permet maintenant l’accès à toutes les actions existantes et futures des services AWS, à l’exception de IAM, AWS Organizations, et des comptes. Nous avons également mis à jour le deuxième bloc d’instructions de la politique pour permettre l’action de lister les regions en lecture seule. Le reste de la politique reste inchangé.

{ "Version": "2012-10-17",
    "Statement":
    [
        {
        "Effect": "Allow",
        "NotAction": [
                "iam:*",
                "organizations:*",
                "account:*"
                ],
                "Resource": "*"
        },
        {
        "Effect": "Allow",
        "Action": [ 
              "iam:CreateServiceLinkedRole",
              "iam:DeleteServiceLinkedRole",
              "iam:ListRoles",
              "organizations:DescribeOrganization",
              "account:ListRegions"
              ],
         "Resource": "*" 
         }
    ]
}

3. Limiter les autorisations de régions sur plusieurs comptes à l’aide des politiques de contrôle des services (SCP) dans AWS Organizations

Les politiques de contrôle des services (Service Control Policies) permettent aux administrateurs de définir des garde-fous ou “guardrails” d’autorisation qui s’appliquent aux comptes de votre organisation ou d’une unité organisationnelle. Pour en savoir plus sur les SCP et sur la façon de les créer et de les attacher, consultez la section Stratégies de contrôle des services.
En utilisant les SCPs, vous pouvez restreindre les actions d’activation et de désactivation des regions d’une manière centralisée pour tous les principaux de tous les comptes de AWS Organization. Les SCP sont à utiliser pour restreindre cet accès si vous ne prévoyez pas d’utiliser de nouvelles régions.

Ce qui suit, montre l’utilisation de SCP pour restreindre les actions d’activation et de désactivation de la Région pour les comptes d’une AWS Organizations. Dans la stratégie ci-dessous, on utilise un Deny explicite dans le bloc Effect. Et dans le bloc Action, on ajoute les nouvelles permissions account:EnableRegion et account:DisableRegion.

{ "Version": "2012-10-17", 
  "Statement": [ 
      { "Effect": "Deny", 
        "Action": [ "account:EnableRegion", "account:DisableRegion" ],
        "Resource": "*"
      } 
      ] 
}

Une fois la politique créée, vous pouvez la joindre à la racine de votre organisation. Cela limitera les permissions à tous les comptes de votre organisation.

4. Vérifier si les utilisateurs ont les permissions d’activer ou de désactiver les nouvelles régions AWS de mon compte

Vous pouvez utiliser IAM Policy Simulator pour vérifier si l’un des identités IAM de votre compte a accès aux nouvelles actions du compte pour activer et désactiver les Régions. Le simulateur évalue les politiques que vous choisissez pour un utilisateur ou un rôle et détermine les permissions effectives pour chacune des actions que vous spécifiez. Voir le lien suivant pour en savoir plus sur l’utilisation du IAM Policy Simulator.

5. Compatibilité de région pour les jetons de session AWS STS

Pour les nouvelles régions AWS, nous modifions également la compatibilité des régions pour les jetons de session à partir du point de terminaison global AWS Security Token Service (STS). D’une manière générale, il est recommandé d’utiliser les points de terminaison STS régionaux pour réduire le temps de latence. Si vous utilisez des points de terminaison STS régionaux ou ne prévoyez pas d’opérer dans de nouvelles régions AWS, le changement suivant ne s’applique pas à vous et aucune action n’est requise.

Si vous utilisez le point de terminaison STS global (https://sts.amazonaws.com) pour les jetons de session et prévoyez de déployer dans de nouvelles régions AWS, la taille du jeton de session augmentera de sorte qu’elle sera de la même taille que le jeton de session émis par les points de présence STS régionaux. Cela peut avoir un impact sur les fonctionnalités si vous stockez des jetons de session sur l’un de vos systèmes. Pour vous assurer que vos systèmes fonctionnent avec cette modification, nous vous recommandons de mettre à jour vos systèmes existants pour qu’ils utilisent des points de terminaison STS régionaux à l’aide du kit AWS SDK.

Synthèse

AWS change le comportement par défaut pour toutes les nouvelles régions à venir. Pour les nouvelles régions AWS, vous devrez choisir maintenant d’autoriser votre compte à fonctionner dans ces régions. Cela facilite la sélection des régions dans lesquelles vous pouvez créer et gérer des ressources AWS. Pour préparer les prochains lancements de région, nous vous recommandons de valider la possibilité d’activer et de désactiver les régions AWS en s’assurant que seuls les principaux IAM approuvés peuvent activer et désactiver les régions AWS pour votre compte.

Article posté originellement par Sulay Shah, Product Manager pour les services IAM d’AWS et traduit en anglais par Walid Benabderrahmane, Entreprise Solutions Architect en France, LinkedIn

Article initial en anglais : https://thinkwithwp.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/

Le Blog Amazon Web Services