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.

Création de votre architecture de sécurité : une approche progressive

L'architecture de sécurité multi-comptes recommandée par l'AWS SRA est une architecture de base qui vous aide à intégrer la sécurité dès le début de votre processus de conception. La transition vers le cloud de chaque entreprise est unique. Pour réussir à faire évoluer votre architecture de sécurité cloud, vous devez définir l'état cible que vous souhaitez atteindre, comprendre votre niveau actuel de préparation au cloud et adopter une approche agile pour combler les lacunes. L'AWS SRA fournit un état cible de référence pour votre architecture de sécurité. La transformation progressive vous permet de démontrer rapidement la valeur ajoutée tout en minimisant le besoin de faire des prévisions ambitieuses.

Le cadre d'adoption du cloud AWS (AWS CAF) recommande quatre phases itératives et incrémentielles de transformation du cloud : Envision, Align, Launch et Scale. Lorsque vous entamez la phase de lancement et que vous vous concentrez sur la mise en œuvre d'initiatives pilotes en production, vous devez vous concentrer sur la création d'une architecture de sécurité solide comme base pour la phase de mise à l'échelle afin de disposer de la capacité technique nécessaire pour migrer et exploiter vos charges de travail les plus critiques en toute confiance. Cette approche progressive est applicable si vous êtes une start-up, une petite ou moyenne entreprise qui souhaite développer ses activités, ou une entreprise qui acquiert de nouvelles unités commerciales ou procède à des fusions et acquisitions. L'AWS SRA vous aide à mettre en place cette architecture de base de sécurité afin que vous puissiez appliquer des contrôles de sécurité de manière uniforme dans l'ensemble de votre organisation en pleine expansion au sein d'AWS Organizations. L'architecture de base comprend plusieurs comptes et services AWS. La planification et la mise en œuvre doivent être un processus en plusieurs phases afin que vous puissiez passer à des étapes plus petites pour atteindre l'objectif global de configuration de votre architecture de sécurité de base. Cette section décrit les phases typiques de votre transition vers le cloud selon une approche structurée. Ces phases sont conformes aux principes de conception de sécurité d'AWS Well-Architected Framework.

Phase 1 : Construisez votre unité d'organisation et votre structure de compte

Une organisation et une structure de compte AWS bien conçues constituent une condition préalable à une base de sécurité solide. Comme expliqué précédemment dans la section relative aux éléments constitutifs de la SRA de ce guide, le fait de disposer de plusieurs comptes AWS vous permet d'isoler les différentes fonctions commerciales et de sécurité dès la conception. Cela peut sembler inutile au début, mais il s'agit d'un investissement pour vous aider à évoluer rapidement et en toute sécurité. Cette section explique également comment vous pouvez utiliser AWS Organizations pour gérer plusieurs comptes AWS, et comment utiliser les fonctionnalités d'accès sécurisé et d'administrateur délégué pour gérer de manière centralisée les services AWS sur ces multiples comptes.

Vous pouvez utiliser AWS Control Tower comme indiqué précédemment dans ce guide pour orchestrer votre zone de landing zone. Si vous utilisez actuellement un seul compte AWS, consultez le guide de transition vers plusieurs comptes AWS pour effectuer la migration vers plusieurs comptes dès que possible. Par exemple, si votre start-up conçoit et prototype actuellement votre produit sur un seul compte AWS, vous devriez envisager d'adopter une stratégie multi-comptes avant de lancer votre produit sur le marché. De même, les petites, moyennes et grandes entreprises devraient commencer à élaborer leur stratégie multi-comptes dès qu'elles planifient leurs charges de travail de production initiales. Commencez par vos unités d'organisation et comptes AWS de base, puis ajoutez vos unités d'organisation et comptes liés à la charge de travail.

Pour les recommandations relatives aux comptes AWS et à la structure de l'unité d'organisation allant au-delà de ce qui est prévu dans l'AWS SRA, consultez le billet de blog sur la stratégie multi-comptes pour les petites et moyennes entreprises. Lorsque vous finalisez votre unité d'organisation et la structure de votre compte, réfléchissez aux contrôles de sécurité de haut niveau à l'échelle de l'organisation que vous souhaiteriez appliquer à l'aide de politiques de contrôle des services (SCP).

Phase 2 : Mettre en place une base d'identité solide

Dès que vous avez créé plusieurs comptes AWS, vous devez donner à vos équipes l'accès aux ressources AWS contenues dans ces comptes. Il existe deux catégories générales de gestion des identités : la gestion des identités et des accès du personnel et la gestion des identités et des accès des clients (CIAM). Workforce IAM est destiné aux entreprises où les employés et les charges de travail automatisées doivent se connecter à AWS pour effectuer leur travail. Le CIAM est utilisé lorsqu'une organisation a besoin d'un moyen d'authentifier les utilisateurs afin de fournir un accès aux applications de l'organisation. Vous avez d'abord besoin d'une stratégie IAM pour le personnel, afin que vos équipes puissent créer et migrer des applications. Vous devez toujours utiliser des rôles IAM plutôt que des utilisateurs IAM pour donner accès à des utilisateurs humains ou à des machines. Suivez les instructions d'AWS SRA pour savoir comment utiliser AWS IAM Identity Center dans les comptes Org Management et Shared Services afin de gérer de manière centralisée l'accès par authentification unique (SSO) à vos comptes AWS. Le guide fournit également des considérations de conception relatives à l'utilisation de la fédération IAM lorsque vous ne pouvez pas utiliser IAM Identity Center.

Lorsque vous utilisez des rôles IAM pour fournir aux utilisateurs un accès aux ressources AWS, vous devez utiliser AWS IAM Access Analyzer et le conseiller d'accès IAM, comme indiqué dans les sections Outils de sécurité et Gestion des organisations de ce guide. Ces services vous aident à obtenir le moindre privilège, ce qui constitue un contrôle préventif important qui vous aide à adopter une bonne posture de sécurité.

Phase 3 : Maintien de la traçabilité

Lorsque vos utilisateurs auront accès à AWS et commenceront à créer, vous voudrez savoir qui fait quoi, quand et d'où. Vous aurez également besoin de visibilité sur les erreurs de configuration, les menaces ou les comportements inattendus potentiels en matière de sécurité. Une meilleure compréhension des menaces de sécurité vous permet de hiérarchiser les contrôles de sécurité appropriés. Pour surveiller l'activité d'AWS, suivez les recommandations d'AWS SRA pour configurer un suivi organisationnel en utilisant AWS CloudTrail et en centralisant vos journaux dans le compte Log Archive. Pour surveiller les événements de sécurité, utilisez AWS Security Hub, Amazon GuardDuty, AWS Config et AWS Security Lake, comme indiqué dans la section relative au compte Security Tooling.

Phase 4 : appliquer la sécurité à tous les niveaux

À ce stade, vous devriez avoir :

Au cours de cette phase, prévoyez d'appliquer la sécurité à d'autres niveaux de votre organisation AWS, comme décrit dans la section Appliquer les services de sécurité au sein de votre organisation AWS. Vous pouvez créer des contrôles de sécurité pour votre couche réseau en utilisant des services tels qu'AWS WAF, AWS Shield, AWS Firewall Manager, AWS Network Firewall, AWS Certificate Manager (ACM), Amazon, Amazon CloudFront, Amazon Route 53 et Amazon VPC, comme indiqué dans la section Compte réseau. Au fur et à mesure que vous avancez dans votre pile technologique, appliquez des contrôles de sécurité spécifiques à votre charge de travail ou à votre pile d'applications. Utilisez les points de terminaison VPC, Amazon Inspector, Amazon Systems Manager, AWS Secrets Manager et Amazon Cognito comme indiqué dans la section Compte de l'application.

Phase 5 : protéger les données en transit et au repos

Les données de votre entreprise et de vos clients sont des actifs précieux que vous devez protéger. AWS fournit divers services et fonctionnalités de sécurité pour protéger les données en mouvement et au repos. Utilisez AWS CloudFront avec AWS Certificate Manager, comme indiqué dans la section Compte réseau, pour protéger les données en mouvement collectées sur Internet. Pour les données en mouvement au sein des réseaux internes, utilisez un Application Load Balancer avec l'autorité de certification privée AWS, comme expliqué dans la section Compte de l'application. AWS KMS et AWS CloudHSM vous aident à gérer les clés cryptographiques afin de protéger les données au repos.

Phase 6 : Préparation aux événements de sécurité

Lorsque vous exploitez votre environnement informatique, vous serez confronté à des événements de sécurité, c'est-à-dire des changements dans le fonctionnement quotidien de votre environnement informatique qui indiquent une violation possible des politiques de sécurité ou une défaillance du contrôle de sécurité. Une traçabilité adéquate est essentielle pour que vous soyez au courant d'un événement de sécurité le plus rapidement possible. Il est tout aussi important d'être prêt à trier et à répondre à de tels événements de sécurité afin de pouvoir prendre les mesures appropriées avant que l'événement de sécurité ne dégénère. La préparation vous aide à trier rapidement un événement de sécurité afin de comprendre son impact potentiel.

L'AWS SRA, grâce à la conception du compte Security Tooling et au déploiement de services de sécurité communs au sein de tous les comptes AWS, vous permet de détecter les événements de sécurité au sein de votre organisation AWS. AWS Detective, intégré au compte Security Tooling, vous aide à trier un événement de sécurité et à en identifier la cause première. Au cours d'une enquête de sécurité, vous devez être en mesure de consulter les journaux pertinents pour enregistrer et comprendre l'ampleur et la chronologie de l'incident. Les journaux sont également nécessaires pour générer des alertes lorsque des actions spécifiques présentant un intérêt se produisent.

L'AWS SRA recommande un compte d'archive de journaux central pour le stockage immuable de tous les journaux opérationnels et de sécurité. Vous pouvez interroger les CloudWatch journaux en utilisant Logs Insights pour les données stockées dans des groupes de CloudWatch journaux, et Amazon Athena et Amazon OpenSearch Service pour les données stockées dans Amazon S3. Utilisez Amazon Security Lake pour centraliser automatiquement les données de sécurité provenant de l'environnement AWS, des fournisseurs de logiciels en tant que service (SaaS), des sites locaux et d'autres fournisseurs de cloud. Configurez les abonnés du compte Security Tooling ou de tout autre compte dédié, comme indiqué par l'AWS SRA, pour interroger ces journaux à des fins d'investigation.