Bonnes pratiques pour la structuration de vos unités organisationnelles avec AWS Organizations

Nos clients cherchent à agir rapidement et en toute sécurité lorsqu’ils lancent de nouvelles innovations. Le framework multi-comptes fournit des conseils pour aider les clients AWS à structurer leur environnement. Ce framework est conçu pour répondre aux besoins de sécurité, tout en conservant la capacité à évoluer et à adapter les environnements Cloud à l’évolution des demandes métiers. La base d’un environnement AWS multi-comptes bien conçu est le service AWS Organizations qui vous permet de gérer de manière centralisée plusieurs comptes AWS.

Cet article approfondit l’architecture recommandée par les bonnes pratiques AWS lorsque vous envisagez de créer votre Organisation AWS. Il détaille et illustre la structure d’Unités Organisationnelles (OU) recommandée et fournira des exemples de mise en œuvre spécifiques. Si vous êtes intéressés par une présentation de haut niveau de ces concepts, nous vous recommandons de consulter la page des Bonnes Pratiques d’établissement de votre environnement AWS.

Pourquoi devons-nous configurer un environnement AWS multi-comptes ?

AWS vous permet d’expérimenter, d’innover et d’évoluer plus rapidement, tout en offrant un environnement Cloud flexible et sécurisé. À mesure que les clients créent et déploient leurs applications, ils ont besoin de mécanismes pour isoler leurs ressources (c’est-à-dire un conteneur de ressources AWS), et cela peut être réalisé à l’aide de plusieurs comptes AWS. Un compte AWS fournit une sécurité naturelle, des limites d’accès et de facturation pour vos ressources AWS, et vous permet de mettre en œuvre l’indépendance et l’isolation de ressources. Par exemple, les utilisateurs en dehors de votre compte n’ont pas accès à vos ressources par défaut. De même, le coût des ressources AWS que vous consommez est alloué uniquement à votre compte. Bien que vous puissiez commencer votre parcours AWS avec un seul compte, AWS vous recommande de configurer plusieurs comptes, à mesure que vos applications augmentent en taille et en complexité. L’utilisation d’un environnement multi-comptes est une bonne pratique qui offre plusieurs avantages :

• Innovation rapide avec des exigences variées : vous pouvez attribuer des comptes AWS à différentes équipes, projets ou produits au sein de votre entreprise. Les comptes séparés fournissent un mécanisme d’innovation rapide, tout en permettant des exigences de sécurité différentes,
• Facturation simplifiée : l’utilisation de plusieurs comptes AWS simplifie la façon dont vous répartissez vos coûts AWS, en vous aidant à identifier le produit ou la ligne de service imputable aux frais AWS,
• Contrôles de sécurité flexibles : vous pouvez utiliser plusieurs comptes AWS pour isoler les applications avec des exigences de sécurité spécifiques, ou qui doivent respecter des directives strictes de conformité, telles que HIPAA ou PCI DSS,
• Adaptation facile aux processus métiers : vous pouvez facilement organiser plusieurs comptes AWS d’une manière qui reflète au mieux les divers besoins des processus métier de votre entreprise, tels que les différentes exigences opérationnelles, réglementaires ou budgétaires.

En fin de compte, un environnement AWS multi-comptes vous permet d’utiliser le Cloud pour progresser plus rapidement et créer des produits et services différenciés, tout en fournissant des mécanismes pour le faire de manière sécurisée, évolutive et résiliente. Mais comment devez-vous créer votre environnement AWS multi-comptes? Vous pouvez avoir des questions, telles que la structure de compte à utiliser, les stratégies et les garde-fous à mettre en œuvre ? ou comment configurer votre environnement pour faciliter son auditabilité ?

Dans cet article, nous vous expliquons les éléments de création d’un environnement AWS multi-comptes sécurisé et productif, souvent appelé «Landing Zone» (zone d’atterrissage), comme recommandé par AWS. Cela représente les meilleures pratiques qui peuvent être utilisées pour créer un framework initial, tout en offrant la flexibilité nécessaire à l’évolution de vos applications au fil du temps.

Bonnes pratiques pour configurer votre environnement AWS multi-comptes

Avant de commencer, familiarisons-nous avec quelques termes. Une Unité Organisationnelle (OU) est un regroupement logique de comptes dans votre organisation AWS. Les Unités Organisationnelles vous permettent d’aménager vos comptes dans une hiérarchie et de faciliter l’application des contrôles de gestion. Les stratégies AWS Organizations sont ce que vous utilisez pour appliquer ces contrôles. Une Service Control Policy (SCP) est une stratégie qui définit les comptes de votre organisation AWS sur lesquels des actions sur un service AWS sont autorisées, telles que le lancement d’instances Amazon EC2.

En premier lieu, considérez les groupes de comptes ou unités organisationnelles que vous devez créer. Les unités organisationnelles vous permettent d’organiser vos comptes AWS par fonction et d’appliquer des politiques communes afin qu’il soit plus facile de partager des ressources gérées de manière centralisée entre des comptes AWS similaires. Vos OU doivent être basées sur une fonction ou un ensemble commun de contrôles, plutôt que de refléter la structure de management de votre entreprise.

Production et cycle de vie de développement logiciel (“Software Development Life Cycle” – SDLC)

Avant de plonger dans l’unité organisationnelle fondamentale, examinons comment le cycle de vie du développement logiciel peut être réalisé. La plupart des entreprises ont des exigences de conformité différentes pour les applications de production, certaines OU peuvent donc avoir des OU imbriquées pour la non-production (SDLC) et la production (Prod). Les comptes de l’OU SDLC hébergent des applications qui ne sont pas en production, c’est-à-dire dev, test et pre-production. Ils ne doivent pas avoir de dépendances sur la production avec d’autres comptes. Les comptes de l’unité organisationnelle Prod, comme leur nom l’indique, hébergent les application de production. Pour les applications et services non développés par vos équipes en interne, les comptes SDLC peuvent modéliser l’environnement de préparation (« staging« ). Par exemple, un produit sur étagère peut être hébergé dans l’environnement de développement, sous l’unité organisationnelle SDLC, et un compte prod sous l’unité organisationnelle « prod« , le tout sous l’unité organisationnelle « Applications » (ou « workloads« ).

S’il est probable que vous puissiez créer une seule OU SDLC pour héberger toutes les étapes de développement dans des comptes AWS, s’il y a des variations dans les stratégies d’OU entre les cycles de vie, l’OU SDLC peut être remplacée par plusieurs OU telles que l’OU Dev et l’OU PreProd. Quoi qu’il en soit, une unité organisationnelle Prod distincte doit généralement exister pour héberger les applications de production.

Appliquez des politiques au niveau de l’unité organisationnelle, pour gouverner les environnements Prod et SDLC, selon vos besoins. En général, il est recommandé d’appliquer des stratégies au niveau de l’unité organisationnelle plutôt qu’au niveau du compte individuel, car cela simplifie la gestion des stratégies et tout travail de diagnostique potentiel.

Unités organisationnelles (OU) fondamentales

AWS vous recommande de commencer avec la sécurité et l’infrastructure à l’esprit. La plupart des entreprises disposent d’équipes centralisées qui servent l’ensemble de l’organisation pour ces besoins. En tant que tel, nous vous recommandons de créer un ensemble d’unités organisationnelles fondamentales pour ces fonctions spécifiques, divisées en unités organisationnelles d’infrastructure et de sécurité, de la manière suivante :

Unité organisationnelle (OU) : Infrastructure

Infrastructure : utilisée pour les services d’infrastructure partagés, tels que les services réseau et IT. Créez des comptes pour chaque type de service d’infrastructure dont vous avez besoin. Par exemple : un client dispose de trois services d’infrastructure et de mise en réseau partagés, fournissant un accès aux réseaux d’entreprise, un service de gestion de message hébergé utilisant RabbitMQ (service de bus de messages) et un compte d’infrastructure partagée générale. La structure de l’unité organisationnelle et des comptes ressemblera alors à ceci :

Unité organisationnelle (OU): Sécurité

L’unité organisationnelle de sécurité est utilisée pour l’hébergement des accès et des services liés à la sécurité. L’unité organisationnelle de sécurité, ainsi que ses unités organisationnelles enfants et les comptes AWS associés doivent être détenus et gérés par votre équipe de sécurité.

Comptes recommandés

Archive de journaux « LogArchive » : un compte AWS qui sert de point de consolidation pour l’accès axé sur la sécurité et les journaux d’audit collectés à partir de tous les comptes AWS de votre environnement,

Sécurité en lecture seule « SecurityReadOnly » (pour les humains) : le but de ce compte AWS est de permettre aux membres de votre équipe de sécurité d’accéder à d’autres comptes AWS dans votre environnement AWS avec des autorisations en lecture seule pour la prise en charge de l’audit, des tests de sécurité exploratoires et des investigations. Par exemple, dans les premières étapes de l’investigation sur un incident de sécurité suspecté, les membres de votre équipe de sécurité accèdent d’abord à ce compte AWS et utilisent un rôle IAM d’accès inter-compte en lecture seule, pour accéder à d’autres comptes AWS pour examiner et surveiller l’état des ressources,

Bris-de-glace sécurité, « SecurityBreakGlass » (pour les humains) : un compte AWS qui sera rarement utilisé, mais disponible pour les membres de votre équipe de sécurité lors d’incidents de sécurité. Ce compte permettra un accès en écriture étendu à vos comptes AWS. Au début d’un incident, une autorisation spéciale sera requise pour qu’un membre de l’équipe de sécurité puisse y accéder. Une fois qu’un incident a été résolu, l’accès temporaire sera révoqué. Tous les accès seront enregistrés en détail,

Outils de sécurité « SecurityTooling » (accès humains minimaux) : un ou plusieurs comptes AWS pour héberger des applications et des services, des outils et des données axés sur la sécurité. Les exemples courants d’outils et de services configurés dans ce compte incluent un compte principal Amazon GuardDuty, un compte principal AWS Security Hub, un compte principal Amazon Detective et des services et outils de surveillance de la sécurité du cloud tiers. L’accès humain à ces comptes AWS à des fins d’administration doit être minimal, ils doivent favoriser l’utilisation de l’infrastructure en tant que code (IaC) et d’autres techniques automatisées. Lorsqu’une administration humaine directe est nécessaire, les administrateurs autorisés doivent disposer d’un accès en écriture suffisant. Au-delà de l’accès administrateur, un accès humain supplémentaire sera probablement nécessaire, afin que les membres de l’équipe de sécurité puissent interagir et éventuellement configurer les fonctionnalités des services de sécurité.

Une fois les services centraux en place, nous vous recommandons de créer des unités organisationnelle directement liées à la création ou à l’exécution de vos produits ou services. De nombreux clients AWS créent les unités organisationnelles répertoriées ci-dessous après avoir établi la fondation décrite ci-dessus.

Unité organisationnelle (OU) : Bac à sable (Sandbox)

Cette OU est destinée aux comptes AWS individuels, dans lesquels les utilisateurs peuvent apprendre et plonger en profondeur dans les services AWS. Il est recommandé de dissocier les comptes de ce bac à sable des réseaux internes du client. L’accès à Internet est nécessaire pour accéder aux services AWS, mais il est recommandé que cela soit limité. Envisagez également une limite de dépenses fixe pour ces comptes, par exemple 100 EUR par mois, qui est signalée au management, pour suivre les valeurs aberrantes et l’utilisation excessive.

Exemple, un client fournit des comptes bac a sable pour tous ses employés :

Unité organisationnelle (OU) : Applications (Workloads)

Ce sont les unités organisationnelles, où les comptes AWS pour le cycle de vie du logiciel sont créés. Il est recommandé de créer des comptes de workload/application pour isoler les services logiciels, plutôt que de refléter l’organisation de vos équipes, afin de rendre l’application déployée plus résiliente aux changements d’organisation interne. Le transfert d’accès à un ensemble de comptes d’une équipe à une autre est facile, tandis que le transfert de services logiciels d’un compte à un autre est une tâche beaucoup plus ardue.

Les comptes dans les unités organisationnelles SDLC/non-prod sont destinés à la mise en place de services logiciels et ne doivent pas dépendre d’autres unités organisationnelles.

Les comptes d’autres OU ne doivent dépendre que des comptes de l’OU applications/prod.

Exemple: un client possède trois unités commerciales différentes, la Production (“Manufacturing”), les Services aux Consommateurs (“Consumer Services”) et le Marketing, qui partagent toutes les mêmes modèles de gouvernance et opérationnels. Les services aux consommateurs ont une version bêta publique, que les unités organisationnelles n’ont pas. Dans ce cas, il est recommandé d’avoir la structure suivante :

À ce stade du processus, les unités organisationnelles de base et orientées métier ont été établies et vous pouvez commencer votre aventure cloud. Voici le framework de départ :

Unité organisationnelle (OU) : Tests de politiques de sécurité (“PolicyStaging”)

Lorsque vous apportez des modifications de stratégie, de politiques ou de structure à une organisation AWS, il est important de vérifier vos modifications avant de les appliquer à grande échelle. Pour vérifier les modifications, un administrateur doit être en mesure de créer et d’appliquer ces modifications qu’il souhaite apporter, sans impact sur la production. L’unité organisationnelle «OU: Tests de politiques» est une unité organisationnelle hors production, qui donne à un administrateur d’organisation un emplacement pour tester une configuration d’OU proposée, afin de vérifier les résultats de l’application d’une politique.

Il est recommandé de créer des unités organisationnelles et des comptes enfants pour tester les modifications. Une fois les changements compris et vérifiés, une stratégie de déploiement peut être employée pour appliquer lentement les changements à l’organisation plus large. Il est recommandé de commencer le déploiement au niveau le plus minimum possible, sur un compte à un emplacement prévu. Promouvoir les changements dans la structure de votre OU à mesure que vous gagnez en confiance. Faire des changements de cette manière minimisera votre périmètre d’impact. Exemple : Une équipe est en charge de la gestion des politiques de sécurité, de l’infrastructure, des applications, du code et du déploiement. Pour effecteur leurs tests, ils ont la structure suivante :

Unité organisationnelle (OU) : « Suspendus »

Elle contient les comptes AWS qui ont été fermés et qui attendent d’être supprimés de l’organisation. Attachez une AWS Service Control Policy (SCP) à cette unité organisationnelle qui refuse toute action. Assurez-vous que les comptes sont étiquetés avec des informations de traçabilité, s’ils doivent être restaurés.

Les comptes détenus par d’anciens employés et les comptes retirés doivent être déplacés vers l’OU « Suspendus ». Les comptes doivent être étiquetés avec des informations, tels que leur provenance, au cas où une restauration serait nécessaire et pour des raisons de traçabilité.

Les comptes fermés pendant 90 jours peuvent être supprimés définitivement, après quoi le compte et ses ressources ne peuvent plus être récupérés. Les comptes fermés sont visibles dans votre organisation, avec l’état « suspendu ». Une fois qu’un compte a été supprimé définitivement, il n’est plus visible dans votre organisation.

Pour plus de détails sur la clôture des comptes, consultez la documentation relative à la clôture d’un compte AWS.

Unité organisationnelle (OU) : Utilisateurs métier individuels

C’est une unité organisationnelle à accès limité contenant des comptes AWS pour les utilisateurs métier qui ne sont pas techniques. Ces utilisateurs peuvent créer des applications liées à la productivité de l’entreprise, par exemple, configurer un compartiment Amazon S3 pour partager des rapports ou partager des fichiers avec un partenaire.

Unité organisationnelle (OU) : Exceptions

Il existe des situations où un cas d’usage métier justifie une exception aux conditions de sécurité ou d’audit définies sous l’OU « Workload“. Lorsqu’un de ces cas est identifié, une exception peut être accordée. Dans ces cas, les comptes recevront une posture de sécurité personnalisée. Les comptes sous l’unité organisationnelle : « Exceptions » ont des Service Control Policy (SCP) appliquées directement au compte au lieu de l’unité organisationnelle, en raison de la nature personnalisée de leurs cas d’utilisation. Les propriétaires de ces comptes peuvent également s’attendre à un examen plus minutieux des systèmes de détection et de réaction en place (via Amazon CloudWatch Events, AWS Config Rules, etc.), afin de mettre en place des contrôles préventifs personnalisés.

Par exemple, les projets top-secret sont un cas particulier qui peut relever de l’unité organisationnelle « Exceptions ». Au final, cela dépend de quels Service Control Policy (SCP) sont définies pour la conformité et la sécurité, et si de nouveaux produits peuvent être lancés selon les directives définies par les Service Control Policy (SCP) associées. Si la sécurité souhaitée autour de la nouvelle initiative est si stricte que les gens estiment que cela justifie une nouvelle organisation distincte, il y a des risques et des coûts supplémentaires liés au retour vers l’organisation principale dans le futur.

Unité organisationnelle (OU) : Deploiements

Contient des comptes AWS destinés aux déploiements CI/CD. Vous pouvez créer cette OU si vous avez une gouvernance et un modèle opérationnel différents pour les déploiements CI/CD, par rapport aux comptes dans les OU d’applications (Prod et SDLC). La distribution de CI/CD permet de réduire la dépendance organisationnelle vis-à-vis d’un environnement CI/CD partagé géré par une équipe centrale. Pour chaque ensemble de comptes AWS, SDLC/Prod pour une application dans l’unité organisationnelle : Applications (workloads), créez un compte pour CI/CD sous l’OU : Déploiements.

Les pipelines de déploiement CI/CD peuvent être les Outils pour Développeurs sur AWS ou des services auto-hébergés. Il est recommandé de distribuer la CI/CD d’une manière qui correspond au modèle opérationnel du service logiciel qu’elle construit et déploie.

Les comptes de l’unité organisationnelle hors production sont destinés à la préparation du service CI/CD et ne doivent avoir aucune dépendance d’autres unités organisationnelles.

Exemple: un client possède trois unités commerciales différentes. Production (“Manufacturing”), qui dispose de services IoT industriels et est autonome avec son propre modèle opérationnel, les Services aux consommateurs (“ConsumerServices”) et le Marketing, qui partagent la gouvernance et les modèles opérationnels. Dans ce cas, il est recommandé d’avoir les unités organisationnelles et les comptes suivants :

Il est recommandé que l’unité organisationnelle de déploiement CI/CD soit séparée en une hiérarchie et des comptes AWS différents, car les modèles de gouvernance et opérationnels diffèrent entre les deux.

Pour chaque service en cours de création, des comptes correspondant au cycle de vie de développement sont créés. L’étape de production sera sous OU: Workloads / OU: Prod. Toutes les autres étapes du cycle de vie du développement seront sous l’OU: Workloads / OU: SDLC.

Pour chaque service (c’est-à-dire ensemble de comptes SDLC), il y aura un compte correspondant pour le déploiement. Ce compte sera placé sous l’OU: Deployments. Par exemple, si un service appelé foo a dev, beta, QA, production, son environnement global serait configuré comme suit :

Nous avons maintenant établi nos unités organisationnelle et nos comptes supplémentaires de la manière suivante :

Conclusion

Une stratégie multi-comptes bien conçue vous aide à innover plus rapidement dans AWS, tout en vous aidant à répondre à vos besoins en matière de sécurité, de gouvernance et d’évolutivité. Le framework décrit dans cet article représente les meilleures pratiques AWS que vous devez utiliser comme point de départ.

Pour commencer à créer votre propre environnement, reportez-vous au Guide de démarrage AWS Organizations. Vous pouvez également utiliser AWS Control Tower pour vous aider à configurer rapidement un environnement AWS initial sécurisé en quelques clics.

Article orginal de Sam Elmalak, Tech Leader  chez AWS et membre de la communauté de sécurité AWS, traduit en français par Djamel Bourokba, Entreprise Solution Architecture, LinkedIn.