Création de votre architecture de sécurité : une approche progressive - AWS Conseils prescriptifs

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

Influencez le futur de l'architecture de référence de AWS sécurité (AWS SRA) en répondant à une courte enquête.

L'architecture de sécurité multi-comptes recommandée par le 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. AWSSRAfournit 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 (AWSCAF) 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. AWSSRACela 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 organisation en pleine expansion dans AWS Organizations. L'architecture de base comprend plusieurs AWS comptes et 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 AWSsé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 consacrée aux SRAéléments de base de ce guide, le fait d'avoir plusieurs AWS comptes 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 AWS comptes, 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 AWS services sur ces multiples comptes.

Vous pouvez utiliser AWSControl Tower comme indiqué précédemment dans ce guide pour orchestrer votre zone de landing zone. Si vous utilisez actuellement un seul AWS compte, consultez le guide de transition vers plusieurs AWS comptes 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 AWS compte, 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 OUs et vos AWS comptes, puis ajoutez vos comptes liés à la charge de travailOUs.

Pour des recommandations sur la structure des AWS comptes et des unités d'organisation autres que celles fournies dans le AWSSRA, 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 (). SCPs

Considération relative à la conception
  • Ne reproduisez pas la structure hiérarchique de votre entreprise lorsque vous concevez votre unité d'organisation et votre structure de compte. Vous OUs devez vous baser sur les fonctions de charge de travail et sur un ensemble commun de contrôles de sécurité applicables aux charges de travail. N'essayez pas de concevoir la structure complète de votre compte dès le début. Concentrez-vous sur les éléments fondamentauxOUs, puis ajoutez de la charge de travail OUs selon vos besoins. Vous pouvez déplacer des comptes entre OUs eux pour expérimenter d'autres approches dès les premières étapes de votre conception. Cependant, cela peut entraîner une certaine surcharge liée à la gestion des autorisations logiques, en fonction SCPs des IAM conditions basées sur les chemins d'unité d'organisation et de compte.

Exemple de mise en œuvre

La bibliothèque de AWS SRA code fournit un exemple d'implémentation de Account Alternate Contacts. Cette solution définit les contacts alternatifs de facturation, d'exploitation et de sécurité pour tous les comptes d'une organisation.

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

Dès que vous avez créé plusieurs AWS comptes, 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. CIAMest 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 IAM stratégie en matière de personnel, afin que vos équipes puissent créer et migrer des applications. Vous devez toujours utiliser IAM des rôles plutôt que des IAM utilisateurs pour donner accès à des utilisateurs humains ou à des machines. Suivez les AWS SRA instructions relatives à l'utilisation AWS IAM d'Identity Center dans les comptes Org Management et Shared Services pour gérer de manière centralisée l'accès par authentification unique (SSO) à vos AWS comptes. Le guide fournit également des considérations de conception relatives à l'utilisation de IAM la fédération lorsque vous ne pouvez pas utiliser IAM Identity Center.

Lorsque vous utilisez IAM des rôles pour fournir aux utilisateurs un accès aux AWS ressources, vous devez utiliser AWS IAM Access Analyzer et IAM Access Advisor, 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é.

Considération relative à la conception
  • Pour obtenir le moindre privilège, concevez des processus permettant d'examiner et de comprendre régulièrement les relations entre vos identités et les autorisations dont elles ont besoin pour fonctionner correctement. Au fur et à mesure que vous apprenez, affinez ces autorisations et réduisez-les progressivement au minimum d'autorisations possible. Pour ce qui est de l'évolutivité, cette responsabilité doit être partagée entre vos équipes centrales chargées de la sécurité et des applications. Utilisez des fonctionnalités telles que les politiques basées sur les ressources, les limites d'autorisation, les contrôles d'accès basés sur les attributs et les politiques de session pour aider les propriétaires d'applications à définir un contrôle d'accès précis.

Exemples de mise en œuvre

La bibliothèque de AWS SRA code fournit deux exemples d'implémentations qui s'appliquent à cette phase :

  • IAMLa politique de mot de passe définit la politique de mot de passe du compte pour les utilisateurs afin de l'aligner sur les normes de conformité communes.

  • Access Analyzer configure un analyseur au niveau de l'organisation dans un compte d'administrateur délégué et un analyseur au niveau du compte dans chaque compte.

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 AWS SRA recommandations relatives à la mise en place d'un suivi organisationnel en utilisant AWS CloudTrailet 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.

Considération relative à la conception
  • Lorsque vous commencez à utiliser de nouveaux AWS services, veillez à activer les journaux spécifiques au service et à les stocker dans votre référentiel de journaux central.

Exemples de mise en œuvre

La bibliothèque de AWS SRA code fournit les exemples d'implémentations suivants qui s'appliquent à cette phase :

  • L'organisation CloudTrail crée un journal organisationnel et définit des paramètres par défaut pour configurer les événements de données (par exemple, dans Amazon S3 et AWS Lambda) afin de réduire CloudTrail la duplication des données configurées par Control Tower. AWS Cette solution fournit des options pour configurer les événements de gestion.

  • AWSLe compte de gestion Config Control Tower permet à AWS Config in the Management de surveiller la conformité des ressources.

  • Les règles d'organisation du pack de conformité déploient un pack de conformité sur les comptes et les régions spécifiées au sein d'une organisation.

  • AWSConfig Aggregator déploie un agrégateur en déléguant l'administration à un compte membre autre que le compte d'audit.

  • Security Hub Organization configure Security Hub au sein d'un compte d'administrateur délégué pour les comptes et les régions gouvernées au sein de l'organisation.

  • GuardDuty L'organisation effectue les GuardDuty configurations au sein d'un compte d'administrateur délégué pour les comptes d'une organisation.

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

À ce stade, vous devriez avoir :

  • Les contrôles de sécurité appropriés pour vos AWS comptes.

  • Une structure de compte et d'unité d'organisation bien définie avec des contrôles préventifs définis par le biais de IAM rôles SCPs et de politiques relatifs au moindre privilège.

  • Possibilité de consigner les AWS activités en utilisant AWS CloudTrail ; de détecter les événements de sécurité à l'aide de AWS Security Hub GuardDuty, Amazon et AWS Config ; et d'effectuer des analyses avancées sur un lac de données spécialement conçu à des fins de sécurité à l'aide d'Amazon Security Lake.

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 mettre en place des contrôles de sécurité pour votre couche réseau en utilisant des services tels que AWS Shield AWSWAF, AWS Firewall Manager, AWS Network Firewall, AWS Certificate Manager (ACM) CloudFront, Amazon, Amazon Route 53 et AmazonVPC, 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 VPC points de terminaison, Amazon Inspector, Amazon Systems Manager, AWS Secrets Manager et Amazon Cognito, comme indiqué dans la section Compte de l'application.

Considération relative à la conception
  • Lorsque vous concevez vos contrôles de sécurité « Defense in Depth » (DiD), tenez compte des facteurs d'échelle. Votre équipe de sécurité centrale n'aura pas la bande passante ou ne comprendra pas parfaitement le comportement de chaque application dans votre environnement. Donnez à vos équipes d'application les moyens d'être responsables et responsables de l'identification et de la conception des contrôles de sécurité appropriés pour leurs applications. L'équipe de sécurité centrale doit se concentrer sur la fourniture des outils et des conseils appropriés pour aider les équipes chargées des applications. Pour comprendre les mécanismes de mise à l'échelle AWS utilisés pour adopter une approche de sécurité davantage axée sur la gauche, consultez le billet de blog How AWS built the Security Guardians program, a mechanism to distribute security ownership.

Exemples de mise en œuvre

La bibliothèque de AWS SRA code fournit les exemples d'implémentations suivants qui s'appliquent à cette phase :

  • EC2Le EBSchiffrement par défaut configure le chiffrement par défaut d'Amazon Elastic Block Store (AmazonEBS) dans Amazon EC2 afin d'utiliser la AWS KMS clé par défaut dans les AWS régions fournies.

  • S3 Block Account Public Access configure les paramètres Block Public Access (BPA) au niveau du compte dans Amazon S3 pour les comptes au sein de l'organisation.

  • Firewall Manager explique comment configurer une stratégie de groupe de sécurité et des AWS WAF politiques pour les comptes au sein d'une organisation.

  • Inspector Organization configure Amazon Inspector au sein d'un compte d'administrateur délégué pour les comptes et les régions gouvernées au sein de l'organisation.

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. AWSfournit divers services et fonctionnalités de sécurité pour protéger les données en mouvement et au repos. AWS CloudFront À utiliser 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 doté d'une autorité de certification AWS privée, comme expliqué dans la section Compte de l'application. AWSKMSet AWS le cloud vous HSM 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.

Grâce à la conception du compte Security Tooling et au déploiement de services de sécurité communs au sein de tous les AWS comptes, vous pouvez détecter les événements de sécurité au sein de votre AWS organisation. AWS SRA AWSDetective du 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.

AWSSRAIl recommande un compte d'archivage des journaux central pour le stockage immuable de tous les journaux de sécurité et opérationnels. 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'AWSenvironnement, 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 le AWSSRA, pour interroger ces journaux à des fins d'investigation.

Considérations relatives à la conception
  • Vous devez commencer à vous préparer à détecter les événements de sécurité et à y répondre dès le début de votre transition vers le cloud. Pour mieux utiliser les ressources limitées, assignez les données et l'importance commerciale à vos AWS ressources afin que, lorsque vous détectez un événement de sécurité, vous puissiez hiérarchiser le triage et la réponse en fonction de l'importance des ressources impliquées.

  • Les phases de création de votre architecture de sécurité cloud, décrites dans cette section, sont de nature séquentielle. Cependant, il n'est pas nécessaire d'attendre la fin complète d'une phase avant de passer à la phase suivante. Nous vous recommandons d'adopter une approche itérative, dans le cadre de laquelle vous commencez à travailler sur plusieurs phases en parallèle et faites évoluer chaque phase au fur et à mesure de l'évolution de votre posture de sécurité dans le cloud. Au fur et à mesure que vous traverserez les différentes phases, votre design évoluera. Pensez à adapter la séquence suggérée dans le schéma suivant à vos besoins particuliers.

Phases séquentielles et itératives de création d'une architecture de sécurité cloud
Exemple de mise en œuvre

La bibliothèque de AWS SRA code fournit un exemple d'implémentation de Detective Organization, qui active automatiquement Detective en déléguant l'administration à un compte (par exemple, Audit ou Security Tooling) et configure Detective pour les comptes AWS Organizations existants et futurs.