Gouvernance de compte rapide et sécurisée avec la solution de personnalisation pour AWS Control Tower

Nos clients apprécient avoir un environnement AWS sécurisé et bien architecturé qui constitue une base solide pour leurs opérations dans le cloud. Ils souhaitent avoir une stratégie multi-comptes qui assure l’excellence opérationnelle, la sécurité, la fiabilité, la performance et l’optimisation des coûts de leurs ressources AWS, aujourd’hui et à l’avenir.

AWS Control Tower répond à cette stratégie multi-comptes en orchestrant divers services AWS. Ce service met en place une Landing Zone en utilisant AWS Organizations et AWS Service Catalog. Une zone d’atterrissage (landing zone en anglais) fournit un environnement AWS multi-comptes avec une structure de comptes, une gouvernance, une topologie réseau et des standards de sécurité. Au fil du temps, à mesure que votre organisation se développe, la Landing Zone doit évoluer pour sécuriser et organiser vos applications et vos ressources.

Dans cet article,  nous vous montrerons comment personnaliser votre Landing Zone pour l’aligner sur les besoins de votre entreprise en utilisant une solution AWS appelée Configurations personnalisées d’AWS Control Tower

Présentation de l’architecture

Lorsque vous déployez AWS Control Tower, elle crée deux unités organisationnelles (OU) dans votre environnement. L’une est destinée aux comptes partagés, et l’autre aux comptes provisionnés par vos utilisateurs. Une OU est une construction permettant de regrouper des comptes à des fins de gouvernance. Vous pouvez créer votre propre OU et y ajouter des comptes existants ou nouveaux.

Les configurations personnalisées pour AWS Control Tower vous permettent de déployer des ressources et une gouvernance à l’échelle dans votre zone d’atterrissage gérée par AWS Control Tower.

Figure 1 – Architecture pour les personnalisations de AWS Control Tower

La solution doit être déployée à l’aide d’un modèle AWS CloudFormation dans la même région AWS et le même compte de gestion que votre zone d’atterrissage AWS Control Tower. Une fois déployée, vous pouvez configurer la solution selon vos besoins à l’aide d’un package de configuration. Ce package contient un fichier manifeste, des modèles et des fichiers connexes qui sont stockés par défaut dans Amazon Simple Storage Service (Amazon S3). Vous pouvez choisir AWS CodeCommit comme référentiel de sources au lieu d’Amazon S3 au moment du déploiement. Ce manifeste décrit les ressources AWS à déployer dans votre OU, ou vos comptes dans des régions AWS spécifiques. Il pointe vers le modèle CloudFormation pour les ressources, et un fichier JSON pour les politiques de contrôle de service (SCP) des organisations AWS. La solution déploie des StackSets dans AWS CloudFormation et des SCP dans AWS Organizations sur plusieurs comptes et régions.

La solution adopte une approche DevOps lors du déploiement en utilisant AWS CodePipeline pour l’intégration et la livraison continues. CodePipeline extrait le contenu du paquet stocké dans votre référentiel de sources et lance le processus de construction et de déploiement. Si une étape d’approbation manuelle est nécessaire, vous pouvez configurer le pipeline pour en inclure une.

Lorsque vous créez un nouveau compte géré à l’aide de AWS Control Tower Account Factory, la solution utilise l’événement de cycle de vie (Lifecycle Event) de AWS Control Tower pour invoquer le flux de travail CodePipeline. Le flux de travail déploie la stack existante de ressources AWS sur le nouveau compte.

Remarque: la solution utilise AWS Key Management Service (AWS KMS) pour chiffrer le fichier ZIP de configuration dans S3. Modifiez la politique de clés pour accorder au rôle ou à l’utilisateur AWS IAM (AWS Identity and Access Management) l’autorisation de télécharger/verser le fichier ZIP.

Matrice des cas d’utilisation

Examinons maintenant quelques scénarios classiques. La matrice ci-dessous montre le comportement de la solution face aux modifications apportées à la landing zone gérée par AWS Control Tower.

Commençons par définir les termes utilisés :

• Nouvelle OU : une OU personnalisée que vous créez dans votre zone d’atterrissage. Supposons qu’il n’y ait pas de comptes AWS associés à cette OU,
• OU existante : Une OU qui a été créée par AWS Control Tower, ou une OU qui a été placée sous sa gestion. Supposons que des comptes soient associés à cette OU,
• Nouveau compte : Compte créé à l’aide de AWS Control Tower Account Factory,
• Compte existant : Un compte qui a été précédemment provisionné à l’aide de l’Account Factory ou inscrit dans Control Tower.

Figure 2. Matrice des cas d’utilisation

Découvrons maintenant des cas d’utilisation à l’aide d’exemples concrets.

Déploiement des ressources et gouvernance des comptes

Considérons une organisation avec plusieurs projets comprenant plusieurs équipes.

La figure 3 montre chaque projet associé à un OU. Une OU de projet a des équipes avec des comptes AWS dédiés.

Figure 3. Exemple de zone d’atterrissage gérée par AWS Control Tower – Etat actuel

L’OU Project1 a un compte Team1 avec des ressources de stockage et de calcul. Team1 utilise Amazon S3 pour stocker les fichiers et Amazon Elastic Compute Cloud (Amazon EC2) pour les traiter. L’administrateur définit ces ressources dans un modèle CloudFormation et les inclut dans le paquet de configuration prêt à être déployé pour les nouveaux comptes. L’OU Project1 a mis en place la stratégie de contrôle de service SCP1 qui refuse l’accès public aux buckets S3 et permet de lancer uniquement des types d’instances EC2 spécifiques. La SCP1 régit le compte Team1.

L’OU Project2 a deux comptes d’équipe, Team3 et Team4. Team3 travaille avec des technologies sans serveur (serverless) et utilise AWS Lambda. Team4 n’a pas encore décidé d’une stratégie de calcul. Project2 OU a mis en place SCP2 qui refuse l’accès public aux buckets S3. La stratégie de contrôle de service SCP2 régit les comptes de Team3 et Team4.

Nouveau compte ajouté à un OU existant

Considérons un scénario futur où Projet1 s’étend et engage une deuxième équipe.

Figure 4. Mise à jour de la zone d’atterrissage – Compte Team2 ajouté à l’OU Project1

Un compte est provisionné pour l’équipe 2 en utilisant AWS Control Tower Account Factory. Ceci invoque un événement du cycle de vie de la tour de contrôle AWS qui déploie la pile existante de ressources de stockage et de calcul vers le compte Team2. La gouvernance de l’OU Project1 s’étend maintenant au compte Team2. Cela garantit un ensemble cohérent de ressources et de politiques à travers les comptes

Nouvelles ressources ajoutées à un compte existant

L’équipe 4 décide d’une stratégie de calcul et souhaite utiliser des conteneurs pour ses applications. Elle souhaite lancer des clusters Amazon Elastic Container Service (Amazon ECS) dans deux régions AWS différentes.

Figure 5. Mise à jour de la zone d’atterrissage – Nouvelles ressources ajoutées au compte Team4

L’administrateur définit les ressources dans un modèle CloudFormation et met à jour le manifeste pour inclure le modèle, le compte cible Team4 et les Régions cibles. Le téléchargement du paquet vers le bucket S3 de configuration déclenche le workflow CodePipeline qui déploie les ressources du conteneur vers le compte Team4 dans les régions spécifiées. Si nécessaire, l’administrateur peut ajouter des SCP supplémentaires à l’OU Project2 pour gérer les ressources de calcul.

Les bonnes pratiques

• Commencez par un exemple de manifeste présent dans le GitHub de la solution pour vous lancer rapidement,
• Pour stocker vos personnalisations, adoptez une structure de fichiers cohérente qui comprend le manifeste, les modèles, les politiques et les paramètres,
• Lorsque vous ajoutez ou modifiez des SCP, examinez attentivement les politiques existantes pour éviter tout conflit. N’oubliez pas que les SCP fonctionnent avec vos politiques AWS IAM et qu’un refus explicite prévaut sur une autorisation explicite, selon la logique d’évaluation des politiques AWS IAM,
• Vérifiez votre fichier manifeste pour vous assurer qu’il reflète le(s) compte(s) cible(s) et la(les) région(s) correcte(s). Cela permet d’éviter des modifications involontaires des ressources de votre compte.

Conclusion

Dans cet article, nous avons mis en évidence quelques cas d’utilisation de la solution, Customizations for AWS Control Tower. Vous pouvez utiliser la solution pour déployer vos ressources et votre gouvernance à l’échelle en utilisant les meilleures pratiques recommandées. Les workflows DevOps intégrés offrent une agilité et une fiabilité commerciale. Le résultat est un environnement AWS multi-comptes sécurisé et évolutif qui vous prépare à la croissance et au succès dans le cloud.

Article orginal de Mrudhula Balasubramanyan, Principal Developer Advocate chez AWS, traduit en français par Baptiste Michaud, Senior Solution Architect dans les équipes AWS France.

TAGS: aws solutions