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 la 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. Le 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 AWS cloud (AWS CAF) recommande quatre phases itératives et incrémentielles de transformation du cloud : conception, alignement, lancement et mise à l'échelle. 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. Le AWS SRA vous aide à mettre en place cette architecture de base de sécurité afin que vous puissiez appliquer les contrôles de sécurité de manière uniforme au sein de votre entreprise en pleine expansion. AWS Organizations L'architecture de base comprend plusieurs Comptes AWS services. 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 AWS sécurité du Well-Architected Framework.  

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

Une AWS organisation et une structure de comptes 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 d'en avoir plusieurs vous Comptes AWS 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 gérer plusieurs comptes et AWS Organizations comment utiliser Comptes AWS les fonctionnalités d'accès sécurisé et d'administrateur délégué pour gérer de manière Services AWS centralisée ces multiples comptes.

Vous pouvez l'utiliser AWS Control Towercomme indiqué précédemment dans ce guide pour orchestrer votre zone d'atterrissage. Si vous utilisez actuellement un compte unique Compte AWS, consultez le Comptes AWS guide Transitioning to multiple pour migrer vers plusieurs comptes dès que possible. Par exemple, si votre start-up conçoit et prototype actuellement votre produit en un seul produit 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 votre fondation Comptes AWS, OUs puis ajoutez vos comptes et comptes liés à la charge de travail OUs .

Pour Compte AWS des recommandations sur la structure de l'UO allant au-delà de ce qui est prévu dans la 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 votre structure de compte, réfléchissez aux contrôles de sécurité de haut niveau à l'échelle de l'organisation que vous souhaiteriez appliquer en utilisant des politiques de contrôle des services (SCPs), des politiques de contrôle des ressources (RCPs) et des politiques déclaratives.

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

Dès que vous en avez créé plusieurs Comptes AWS, vous devez donner à vos équipes l'accès aux AWS ressources de 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 organisations où les employés et les charges de travail automatisées doivent se connecter AWS pour faire 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 directives de la AWS SRA sur la façon de les utiliser AWS IAM Identity Center dans les comptes Org Management et Shared Services pour gérer de manière centralisée l'accès à votre compte avec authentification unique (SSO). 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 AWS ressources, vous devez utiliser 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 AWS l'activité, suivez les recommandations de la AWS SRA concernant la mise en place d'un suivi organisationnel en utilisant AWS CloudTrailet en centralisant vos journaux dans le compte Log Archive. Pour la surveillance des événements de sécurité AWS Security Hub CSPM, utilisez Amazon GuardDuty et Amazon Security Lake AWS Config, 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 AWS organisation, comme décrit dans la section Appliquer les services de sécurité dans l'ensemble de votre AWS organisation. Vous pouvez créer des contrôles de sécurité pour votre couche réseau en utilisant des services tels que AWS WAF AWS Shield, AWS Firewall Manager, AWS Network Firewall,, AWS Certificate Manager (ACM), 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 et Amazon Cognito AWS Systems ManagerAWS Secrets Manager, 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 Amazon 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 AWS Autorité de certification privée, comme expliqué dans la section Compte de l'application. AWS KMS et vous AWS CloudHSM 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 également 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 ne dégénère. La préparation vous aide à trier rapidement un événement de sécurité afin de comprendre son impact potentiel.

Le AWS SRA, grâce à la conception du compte Security Tooling et au déploiement de services de sécurité communs au sein de tous Comptes AWS, vous permet de détecter les événements de sécurité au sein de votre AWS organisation. Amazon 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. La AWS SRA recommande un compte central d'archivage des journaux 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' AWS environnement, 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 la AWS SRA, pour interroger ces journaux à des fins d'investigation. 

Réponse aux incidents de sécurité AWSvous aide à automatiser la réponse, l'investigation et la correction des incidents de sécurité. Il fournit des playbooks et des flux de travail prédéfinis pour vous aider à répondre aux événements de sécurité rapidement et de manière cohérente. Lorsque la fonctionnalité de réponse proactive est activée, Security Incident Response s'intègre à Security Hub CSPM et déclenche automatiquement des flux GuardDuty de travail de réponse lorsque des résultats de sécurité sont détectés. Le service vous aide à normaliser et à automatiser vos processus de réponse aux incidents au sein de votre AWS organisation. Si vous avez besoin d'une assistance supplémentaire, vous pouvez ouvrir un dossier pris en charge par le service pour contacter l'équipe de réponse aux incidents AWS clients (CIRT).