La stratégie multicompte AWS est une méthode puissante de gestion de plusieurs comptes AWS au sein d’une organisation. Il est conçu pour aider les organisations à faire évoluer et à gérer plus efficacement leur infrastructure cloud tout en maintenant la sécurité et la conformité. Dans cet article, nous allons explorer les composants clés d’une stratégie multicompte AWS et comment elle peut être mise en œuvre pour obtenir un meilleur contrôle et une meilleure efficacité dans la gestion des ressources cloud.
Pourquoi plusieurs comptes ?
- Contrôles de sécurité: Chaque application peut avoir des contrôles de sécurité différents, comme au sein d’une même organisation, PCI-DSS aura des contrôles de sécurité différents des autres applications.
- Isolement: L’isolation est cruciale pour prévenir les risques potentiels et les menaces de sécurité pouvant découler de la présence de plusieurs applications dans le même compte.
- De nombreuses équipes: L’utilisation de plusieurs comptes empêche les interférences d’équipe, car les équipes ayant des responsabilités et des besoins en ressources différents sont séparées.
- Isolement des données: Isoler les magasins de données à un compte limite l’accès et la gestion des données à quelques privilégiés, réduisant ainsi le risque d’exposition non autorisée d’informations sensibles.
- Processus d’affaires: Des comptes individuels peuvent être créés pour répondre à des besoins commerciaux spécifiques, car les unités commerciales ou les produits ont souvent des objectifs et des processus différents.
- Facturation: L’approche multi-comptes permet la création d’éléments facturables distincts à travers les unités commerciales, les équipes fonctionnelles ou les utilisateurs individuels.
- Répartition des quotas: Chaque compte, y compris les projets, a un quota bien défini et individuel puisque les quotas AWS sont établis par compte.
Concevoir la structure de l’unité d’organisation
Une unité organisationnelle (UO) est un regroupement logique de comptes dans votre organisation, créé à l’aide d’organisations AWS. Les unités d’organisation vous permettent d’organiser vos comptes dans une hiérarchie et vous facilitent l’application des contrôles de gestion. Les stratégies des organisations AWS sont ce que vous utilisez pour appliquer ces contrôles. Une politique de contrôle de service (SCP) est une politique qui définit les actions de service AWS.
Lors de la construction de cette structure, un principe clé est de réduire les frais généraux opérationnels liés à la gestion de la structure. Pour y parvenir, nous avons minimisé la profondeur de la hiérarchie globale et l’endroit où les politiques sont appliquées. Par exemple, les politiques de contrôle des services (SCP) sont principalement appliquées au niveau de l’UO, pour faciliter le dépannage, plutôt qu’au niveau du compte.
Les SCP sont utilisées pour appliquer les stratégies organisationnelles qui s’appliquent à plusieurs comptes, et elles sont créées et appliquées au niveau de l’unité organisationnelle (UO). En utilisant le balisage AWS, vous pouvez appliquer des politiques à des ressources spécifiques en fonction de leurs balises, ce qui peut vous aider à gérer et à sécuriser plus efficacement vos ressources.
Le diagramme suivant illustre la structure d’unité d’organisation commune pour les entreprises.
Concevoir un pare-feu central et un réseau
De nombreux clients AWS adoptent AWS Control Tower comme élément clé de leur stratégie multi-comptes, visant à atteindre l’agilité commerciale et la gouvernance centralisée. Une fois déployés, les clients cherchent à tirer parti des avantages d’AWS Control Tower, tels que la création d’une architecture réseau sécurisée et évolutive, qui peut être intégrée de manière transparente aux nouveaux comptes et VPC.
Pour obtenir une architecture multi-comptes et multi-VPC évolutive, les clients peuvent utiliser AWS Transit Gateway. Ils peuvent également utiliser des VPC d’entrée et de sortie pour contrôler la connectivité à Internet et au réseau sur site via une connexion AWS Site-to-Site VPN ou AWS Direct Connect. Cela centralise la gouvernance et le contrôle du réseau, car toutes les exigences de mise en réseau sont gérées à partir d’un emplacement central : le compte réseau.
Ces composants sont intégrés afin que tout le trafic provenant des VPC soit dirigé vers AWS Network Firewall avant d’être envoyé vers sa destination finale, qu’il s’agisse d’un autre VPC, d’un réseau sur site ou d’Internet via le VPC de sortie. De même, tout le trafic provenant d’Internet vers un VPC via le VPC d’entrée est d’abord acheminé vers AWS Network Firewall pour inspection avant d’être envoyé via la passerelle de transit vers le VPC de destination.
Le schéma suivant illustre le pare-feu d’inspection central dans le compte réseau.
Gestion des identités et des accès
AWS Federation permet aux organisations de simplifier la gestion des utilisateurs, d’améliorer la sécurité et de faciliter l’audit et la conformité en s’intégrant à un fournisseur d’identité comme Okta, Azure AD. Cette intégration permet aux utilisateurs d’utiliser un seul ensemble d’informations d’identification pour accéder aux ressources Azure et AWS, tout en permettant aux administrateurs de contrôler l’accès des utilisateurs aux ressources AWS en fonction de leur rôle ou de leur fonction.
AWS Federation avec Azure est une méthode permettant aux utilisateurs d’accéder aux ressources sur Amazon Web Services (AWS) à l’aide de leurs informations d’identification à partir de Microsoft Azure Active Directory (Azure AD). Cette intégration permet aux organisations de fournir une expérience transparente à leurs utilisateurs, qui peuvent utiliser un seul ensemble d’informations d’identification pour accéder aux ressources Azure et AWS.
L’intégration implique la configuration d’Azure AD en tant que fournisseur d’identité pour AWS, la configuration des rôles et des autorisations, et le test de la configuration pour s’assurer qu’elle fonctionne comme prévu. En utilisant Azure AD comme fournisseur d’identité avec AWS SSO, les organisations peuvent centraliser la gestion des comptes d’utilisateurs et améliorer la sécurité, car l’accès aux ressources n’est accordé qu’aux utilisateurs autorisés.
Le diagramme suivant illustre l’intégration d’Azure AD avec le compte principal AWS.
Concevoir un DNS central
Une zone hébergée privée centrale dans Route 53 est une zone hébergée partagée entre plusieurs comptes AWS. Il vous permet de créer un espace de noms DNS unique pouvant être utilisé sur tous les VPC et comptes de votre organisation. Cela signifie que vous pouvez utiliser les mêmes noms de domaine et enregistrements DNS pour référencer des ressources dans différents comptes ou VPC, sans avoir à créer des zones hébergées en double ou à configurer un accès entre comptes.
Pour créer une zone hébergée privée centrale dans Route 53, vous devez d’abord créer la zone hébergée dans l’un de vos comptes AWS. Vous pouvez ensuite partager la zone hébergée avec d’autres comptes AWS en créant un partage de ressources dans AWS Resource Access Manager (RAM). Une fois le partage de ressources créé, vous pouvez inviter d’autres comptes AWS à rejoindre le partage de ressources et leur fournir les autorisations nécessaires pour gérer la zone hébergée.
Vous pouvez utiliser des résolveurs entrants et sortants pour envoyer et recevoir du trafic DNS à partir de n’importe quel serveur DNS sur site.
Le schéma suivant illustre le serveur DNS central dans AWS.
Automatisation des infrastructures
L’infrastructure en tant que code (IaC) est une méthodologie permettant de définir et de gérer l’infrastructure et l’architecture des applications dans le code. AWS CloudFormation ou Terraform peuvent être utilisés pour définir l’infrastructure et l’architecture de l’application dans le code, qui peut ensuite être enregistré dans un système de contrôle de version comme AWS CodeCommit, Git.
Pour gérer et modifier le code stocké dans AWS CodeCommit, utilisez AWS Cloud9, qui fournit un environnement de développement basé sur le cloud accessible depuis n’importe où.
AWS CodeBuild peut être utilisé pour créer automatiquement le code chaque fois que des modifications sont apportées au code dans AWS CodeCommit. Il peut compiler, tester et empaqueter du code. AWS CodeDeploy peut être configuré pour déployer automatiquement le code sur l’infrastructure chaque fois qu’une génération réussie est effectuée par AWS CodeBuild.
Pour intégrer tous les outils ci-dessus, configurez un pipeline CI/CD qui utilise AWS CodePipeline pour automatiser le processus et faciliter la gestion de l’ensemble du pipeline. AWS CodePipeline vous permet de définir les étapes de votre pipeline, les actions qui se déroulent à chaque étape et les déclencheurs qui démarrent chaque étape.
Une fois l’infrastructure provisionnée à l’aide d’AWS CloudFormation ou de Terraform, exécutez des tests d’intégration sur l’application déployée pour vérifier sa fonctionnalité. Enfin, déployez l’application en production à l’aide du pipeline CI/CD, qui peut déclencher automatiquement le déploiement en fonction de règles prédéfinies ou d’une approbation manuelle.
Le schéma suivant illustre l’infrastructure CI-CD pour AWS.
En outre, des services AWS comme AWS Security Hub et AWS Config Rules pour automatiser les contrôles de sécurité et garantir que vos comptes sont toujours conformes à vos politiques de sécurité.
Sauvegardes centrales
La sauvegarde centrale peut être mise en œuvre de différentes manières, par exemple en utilisant un serveur de sauvegarde ou des solutions de sauvegarde basées sur le cloud comme AWS Backup. Avec AWS Backup, les utilisateurs peuvent créer des politiques de sauvegarde pour plusieurs comptes et régions et les gérer de manière centralisée à partir d’une seule AWS Management Console. Cette approche garantit la cohérence et la fiabilité des politiques de sauvegarde, tout en simplifiant la gestion et en réduisant la probabilité d’erreurs.
Avec AWS Backup, vous pouvez automatiser la planification des sauvegardes, les politiques de rétention et la gestion du cycle de vie des données pour diverses ressources AWS telles que les volumes EBS, les bases de données RDS, les tables DynamoDB, les systèmes de fichiers EFS, etc.
Pour configurer une sauvegarde centrale à l’aide d’AWS Backup, vous devez créer un coffre-fort de sauvegarde, créer un plan de sauvegarde, attribuer des ressources au plan de sauvegarde, surveiller vos sauvegardes et restaurer vos données si nécessaire. AWS Backup fournit une vue consolidée de l’activité de sauvegarde dans l’ensemble de votre environnement AWS, ce qui facilite la gestion et la surveillance de vos sauvegardes.
Le diagramme suivant illustre la sauvegarde centrale.
Journalisation centrale
AWS Central Logging est un service qui vous permet de collecter, stocker et analyser les journaux générés par diverses ressources de votre environnement AWS. Il fournit un emplacement centralisé pour stocker les journaux, qui peuvent être consultés et analysés par les utilisateurs autorisés.
Pour utiliser AWS Central Logging, vous devez d’abord configurer une destination de journalisation, comme Amazon S3 ou Amazon CloudWatch Logs. Vous devez ensuite configurer vos ressources AWS pour envoyer leurs journaux à la destination de journalisation comme AWS Opensearch.
Une fois les journaux envoyés à la destination de journalisation, vous pouvez utiliser AWS Central Logging pour analyser et interroger les journaux. Cela peut vous aider à résoudre les problèmes, à surveiller les performances et à détecter les menaces de sécurité.
Amazon OpenSearch est un service de recherche et d’analyse géré qui vous permet de rechercher, d’analyser et de visualiser des données. Il est basé sur les logiciels open source populaires Elasticsearch et Kibana, et est entièrement compatible avec le…