La valeur de l'AWS SRA

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

AWS dispose d'un ensemble important (et croissant) de services liés à la sécurité et à la sécurité. Les clients ont exprimé leur appréciation pour les informations détaillées disponibles dans la documentation de notre service, nos articles de blog, nos tutoriels, nos sommets et nos conférences. Ils nous disent également qu'ils souhaitent mieux comprendre la situation dans son ensemble et avoir une vision stratégique des services de sécurité AWS. Lorsque nous travaillons avec les clients pour mieux comprendre leurs besoins, trois priorités se dégagent :

• Les clients souhaitent obtenir plus d'informations et des modèles recommandés sur la manière dont ils peuvent déployer, configurer et exploiter les services de sécurité AWS de manière globale. Dans quels comptes et pour quels objectifs de sécurité les services doivent-ils être déployés et gérés ?  Existe-t-il un compte de sécurité sur lequel tous les services ou la plupart des services devraient fonctionner ?  Comment le choix de l'emplacement (unité organisationnelle ou compte AWS) influe-t-il sur les objectifs de sécurité ? Quels compromis (considérations de conception) les clients doivent-ils prendre en compte ?

• Les clients souhaitent découvrir différentes perspectives pour organiser de manière logique les nombreux services de sécurité AWS. Au-delà de la fonction principale de chaque service (par exemple, les services d'identité ou les services de journalisation), ces points de vue alternatifs aident les clients à planifier, concevoir et mettre en œuvre leur architecture de sécurité. Un exemple présenté plus loin dans ce guide regroupe les services en fonction des couches de protection alignées sur la structure recommandée de votre environnement AWS.

• Les clients recherchent des conseils et des exemples pour intégrer les services de sécurité de la manière la plus efficace possible. Par exemple, comment devraient-ils aligner et connecter au mieux AWS Config à d'autres services pour effectuer le gros du travail dans les pipelines d'audit et de surveillance automatisés ?  Les clients demandent des conseils sur la manière dont chaque service de sécurité AWS s'appuie sur d'autres services de sécurité ou les prend en charge.

Nous abordons chacune de ces questions dans l'AWS SRA. La première priorité de la liste (où vont les choses) est au centre du schéma d'architecture principal et des discussions qui l'accompagnent dans ce document. Nous fournissons une architecture AWS Organizations recommandée et une account-by-account description des services destinés à chaque destination.  Pour commencer avec la deuxième priorité de la liste (comment envisager l'ensemble complet des services de sécurité), lisez la section Appliquer les services de sécurité au sein de votre organisation AWS. Cette section décrit un moyen de regrouper les services de sécurité en fonction de la structure des éléments de votre organisation AWS. En outre, ces mêmes idées se reflètent dans la discussion sur le compte de l'application, qui met en évidence la manière dont les services de sécurité peuvent être gérés de manière à se concentrer sur certaines couches du compte : les instances Amazon Elastic Compute Cloud (Amazon EC2), les réseaux Amazon Virtual Private Cloud (Amazon VPC) et le compte au sens large. Enfin, la troisième priorité (intégration des services) est reflétée tout au long du guide, en particulier dans la discussion sur les différents services dans les sections de cette documentation consacrées aux comptes et dans le code du référentiel de code AWS SRA.

Comment utiliser l'AWS SRA

Il existe différentes manières d'utiliser l'AWS SRA en fonction de l'état d'avancement de votre parcours d'adoption du cloud. Voici une liste des moyens de tirer le meilleur parti des ressources AWS SRA (schéma d'architecture, conseils écrits et exemples de code).

• Définissez l'état cible de votre propre architecture de sécurité.

Que vous commenciez tout juste votre transition vers le cloud AWS, en configurant votre premier ensemble de comptes, ou que vous envisagiez d'améliorer un environnement AWS établi, l'AWS SRA est l'endroit idéal pour commencer à créer votre architecture de sécurité. Commencez par une base complète de structure de compte et de services de sécurité, puis ajustez en fonction de votre infrastructure technologique, de vos compétences, de vos objectifs de sécurité et de vos exigences de conformité spécifiques. Si vous savez que vous allez créer et lancer davantage de charges de travail, vous pouvez utiliser votre version personnalisée d'AWS SRA comme base pour l'architecture de référence de sécurité de votre organisation. Pour savoir comment atteindre l'état cible décrit par l'AWS SRA, consultez la section Création de votre architecture de sécurité — Une approche progressive.

• Passez en revue (et révisez) les conceptions et les fonctionnalités que vous avez déjà mises en œuvre.

Si vous avez déjà une conception et une mise en œuvre de la sécurité, il vaut la peine de prendre le temps de comparer ce que vous avez avec l'AWS SRA. L'AWS SRA est conçu pour être complet et fournit une base de diagnostic pour évaluer votre propre sécurité. Lorsque vos conceptions de sécurité sont conformes à la norme AWS SRA, vous pouvez être plus sûr de suivre les meilleures pratiques lors de l'utilisation des services AWS. Si vos conceptions de sécurité divergent ou ne sont pas conformes aux directives de l'AWS SRA, cela ne signifie pas nécessairement que vous faites quelque chose de mal. Cette observation vous donne plutôt l'occasion de revoir votre processus de décision. Il existe des raisons commerciales et technologiques légitimes pour lesquelles vous pourriez vous écarter des bonnes pratiques AWS SRA. Peut-être que vos exigences spécifiques en matière de conformité, de réglementation ou de sécurité organisationnelle nécessitent des configurations de service spécifiques. Ou bien, au lieu d'utiliser les services AWS, vous pouvez avoir une préférence de fonctionnalité pour un produit du réseau de partenaires AWS ou pour une application personnalisée que vous avez créée et gérée. Au cours de cet examen, vous découvrirez peut-être que vos décisions précédentes ont été prises en fonction de technologies plus anciennes, de fonctionnalités AWS ou de contraintes commerciales qui ne s'appliquent plus. C'est une bonne occasion de passer en revue les mises à jour, de les classer par ordre de priorité et de les ajouter à l'endroit approprié de votre carnet de commandes d'ingénierie. Quoi que vous découvriez en évaluant votre architecture de sécurité à la lumière de l'AWS SRA, il vous sera utile de documenter cette analyse. Le fait de disposer de cet historique des décisions et de leurs justifications peut aider à éclairer et à prioriser les décisions futures.

• Démarrez la mise en œuvre de votre propre architecture de sécurité.

Les modules d'infrastructure en tant que code (IaC) AWS SRA constituent un moyen rapide et fiable de commencer à créer et à mettre en œuvre votre architecture de sécurité. Ces modules sont décrits plus en détail dans la section du référentiel de code et dans le GitHub référentiel public. Ils permettent non seulement aux ingénieurs de s'appuyer sur des exemples de haute qualité des modèles présentés dans les directives AWS SRA, mais ils intègrent également les contrôles de sécurité recommandés tels que les politiques de mot de passe AWS Identity and Access Management (IAM), l'accès public aux comptes de blocage Amazon Simple Storage Service (Amazon S3), le chiffrement Amazon Elastic Block Store (Amazon EBS) par défaut d'Amazon EC2, et intégration à AWS Control Tower afin que les contrôles soient appliqués ou supprimés à mesure que de nouveaux comptes AWS sont intégrés ou mis hors service.

• En savoir plus sur les services et fonctionnalités de sécurité d'AWS.

Les conseils et les discussions au sein de l'AWS SRA incluent des fonctionnalités importantes ainsi que des considérations relatives au déploiement et à la gestion pour les différents services liés à la sécurité AWS. L'une des caractéristiques de l'AWS SRA est qu'il fournit une introduction de haut niveau à l'étendue des services de sécurité AWS et à la manière dont ils fonctionnent ensemble dans un environnement multi-comptes. Cela complète l'étude approfondie des fonctionnalités et de la configuration de chaque service trouvée dans d'autres sources. La discussion sur la manière dont AWS Security Hub intègre les résultats de sécurité provenant de divers services AWS, de produits de partenaires AWS et même de vos propres applications en est un exemple.

• Menez une discussion sur la gouvernance organisationnelle et les responsabilités en matière de sécurité.

Un élément important de la conception et de la mise en œuvre de toute architecture ou stratégie de sécurité consiste à comprendre qui au sein de votre organisation a quelles responsabilités en matière de sécurité. Par exemple, la question de savoir où agréger et surveiller les résultats de sécurité est liée à la question de savoir quelle équipe sera responsable de cette activité. Tous les résultats de l'organisation sont-ils surveillés par une équipe centrale qui a besoin d'accéder à un compte Security Tooling dédié ? Ou bien les équipes d'application individuelles (ou unités commerciales) sont-elles responsables de certaines activités de surveillance et ont-elles donc besoin d'accéder à certains outils d'alerte et de surveillance ? Autre exemple, si votre organisation dispose d'un groupe qui gère toutes les clés de chiffrement de manière centralisée, cela influencera les personnes autorisées à créer les clés AWS Key Management Service (AWS KMS) et les comptes dans lesquels ces clés seront gérées. Comprendre les caractéristiques de votre organisation (les différentes équipes et responsabilités) vous aidera à adapter l'AWS SRA à vos besoins. À l'inverse, la discussion sur l'architecture de sécurité donne parfois lieu à une discussion sur les responsabilités organisationnelles existantes et à la prise en compte des changements potentiels. AWS recommande un processus décisionnel décentralisé dans le cadre duquel les équipes chargées de la charge de travail sont chargées de définir les contrôles de sécurité en fonction de leurs fonctions et exigences en matière de charge de travail. L'objectif d'une équipe de sécurité et de gouvernance centralisée est de créer un système permettant aux responsables de la charge de travail de prendre des décisions éclairées et à toutes les parties d'avoir une visibilité sur la configuration, les résultats et les événements. L'AWS SRA peut être un moyen d'identifier et d'éclairer ces discussions.

Principales directives de mise en œuvre de l'AWS SRA

Voici huit points essentiels à retenir de l'AWS SRA à prendre en compte lors de la conception et de la mise en œuvre de votre sécurité.   

• AWS Organizations et une stratégie multi-comptes appropriée sont des éléments essentiels de votre architecture de sécurité. La séparation correcte des charges de travail, des équipes et des fonctions constitue le fondement de la séparation des tâches et des defense-in-depth stratégies. Le guide aborde cette question plus en détail dans une section ultérieure.

• D efense-in-depth est une considération de conception importante lors de la sélection des contrôles de sécurité pour votre organisation. Il vous aide à injecter les contrôles de sécurité appropriés aux différentes couches de la structure d'AWS Organizations, ce qui permet de minimiser l'impact d'un problème : en cas de problème avec une couche, des contrôles sont en place pour isoler d'autres ressources informatiques précieuses. L'AWS SRA montre comment les différents services AWS fonctionnent à différentes couches de la pile technologique AWS, et comment l'utilisation combinée de ces services peut vous aider à y parvenir defense-in-depth. Ce defense-in-depth concept sur AWS est discuté plus en détail dans une section ultérieure avec des exemples de conception présentés sous Compte d'application.

• Utilisez la grande variété d'éléments de sécurité présents dans les multiples services et fonctionnalités AWS pour créer une infrastructure cloud robuste et résiliente. Lorsque vous adaptez l'AWS SRA à vos besoins particuliers, tenez compte non seulement de la fonction principale des services et fonctionnalités AWS (par exemple, authentification, chiffrement, surveillance, politique d'autorisation), mais également de leur intégration dans la structure de votre architecture. Une section ultérieure du guide décrit le fonctionnement de certains services dans l'ensemble de votre organisation AWS. D'autres services fonctionnent mieux avec un seul compte, et certains sont conçus pour accorder ou refuser l'autorisation à des directeurs individuels. La prise en compte de ces deux points de vue vous aide à élaborer une approche de sécurité à plusieurs niveaux plus flexible.

• Dans la mesure du possible (comme indiqué dans les sections suivantes), utilisez les services AWS qui peuvent être déployés sur chaque compte (distribués plutôt que centralisés) et créez un ensemble cohérent de barrières de sécurité partagées qui peuvent vous aider à protéger vos charges de travail contre toute utilisation abusive et à réduire l'impact des événements de sécurité. L'AWS SRA utilise AWS Security Hub (surveillance centralisée des résultats et contrôles de conformité), Amazon GuardDuty (détection des menaces et détection des anomalies), AWS Config (surveillance des ressources et détection des modifications), IAM Access Analyzer (surveillance de l'accès aux ressources), AWS CloudTrail (activité des API du service de journalisation dans votre environnement) et Amazon Macie (classification des données) comme ensemble de base de services AWS à déployer sur chaque compte AWS.

• Utilisez la fonctionnalité d'administration déléguée d'AWS Organizations, lorsqu'elle est prise en charge, comme expliqué plus loin dans la section Administration déléguée du guide. Cela vous permet d'enregistrer un compte de membre AWS en tant qu'administrateur pour les services pris en charge. L'administration déléguée permet aux différentes équipes de votre entreprise d'utiliser des comptes distincts, en fonction de leurs responsabilités, afin de gérer les services AWS dans l'ensemble de l'environnement. En outre, le recours à un administrateur délégué vous permet de limiter l'accès au compte de gestion AWS Organizations et de gérer le surcroît d'autorisations associé à ce compte.

• Mettez en œuvre une surveillance, une gestion et une gouvernance centralisées au sein de vos organisations AWS. En utilisant les services AWS qui prennent en charge l'agrégation multicompte (et parfois multirégionale), ainsi que les fonctionnalités d'administration déléguée, vous permettez à vos équipes d'ingénierie centralisées chargées de la sécurité, du réseau et du cloud de bénéficier d'une visibilité et d'un contrôle étendus sur la configuration de sécurité et la collecte de données appropriées. En outre, les données peuvent être renvoyées aux équipes chargées de la charge de travail pour leur permettre de prendre des décisions de sécurité efficaces plus tôt dans le cycle de vie du développement logiciel (SDLC).

• Utilisez AWS Control Tower pour configurer et gérer votre environnement AWS multi-comptes en mettant en œuvre des contrôles de sécurité prédéfinis pour démarrer le développement de votre architecture de référence en matière de sécurité. AWS Control Tower fournit un plan pour assurer la gestion des identités, un accès fédéré aux comptes, une journalisation centralisée et des flux de travail définis pour le provisionnement de comptes supplémentaires. Vous pouvez ensuite utiliser la solution Customizations for AWS Control Tower (CfCT) pour référencer les comptes gérés par AWS Control Tower avec des contrôles de sécurité, des configurations de service et une gouvernance supplémentaires, comme le montre le référentiel de code AWS SRA. La fonctionnalité Account Factory fournit automatiquement aux nouveaux comptes des modèles configurables basés sur une configuration de compte approuvée afin de standardiser les comptes au sein de vos organisations AWS. Vous pouvez également étendre la gouvernance à un compte AWS individuel existant en l'inscrivant dans une unité organisationnelle (UO) déjà régie par AWS Control Tower.

• Les exemples de code AWS SRA montrent comment automatiser la mise en œuvre de modèles dans le guide AWS SRA en utilisant l'infrastructure en tant que code (IaC). En codifiant les modèles, vous pouvez traiter IaC comme les autres applications de votre organisation et automatiser les tests avant de déployer le code. IaC contribue également à garantir la cohérence et la répétabilité en déployant des garde-fous dans plusieurs environnements (par exemple, SDLC ou spécifiques à une région). Les exemples de code SRA peuvent être déployés dans un environnement multi-comptes AWS Organizations avec ou sans AWS Control Tower. Les solutions de ce référentiel qui nécessitent AWS Control Tower ont été déployées et testées dans un environnement AWS Control Tower à l'aide d'AWS CloudFormation et de Customizations for AWS Control Tower (CfCT). Les solutions qui ne nécessitent pas AWS Control Tower ont été testées dans un environnement AWS Organizations à l'aide d'AWS CloudFormation. Si vous n'utilisez pas AWS Control Tower, vous pouvez utiliser la solution de déploiement basée sur AWS Organizations.