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.
La valeur du AWS SRA
| Influencez le futur de l'architecture de référence de AWS sécurité (AWS SRA) en répondant à une courte enquête |
AWSdispose d'un ensemble important (et croissant) de services liés à la sécurité
-
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 AWS de sécurité 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 AWS compte) 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 voir différentes perspectives pour organiser de manière logique les nombreux services de AWS sécurité. 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 AWS environnement.
-
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 AWS de sécurité s'appuie sur les autres services de sécurité ou les prend en charge.
Nous abordons chacun de ces points dans le AWSSRA. 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 d'AWSOrganizations recommandée et une account-by-account description des services destinés à chacun. 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é dans l'ensemble de votre AWS organisation. Cette section décrit un moyen de regrouper les services de sécurité en fonction de la structure des éléments de votre AWS organisation. En outre, ces mêmes idées se reflètent dans la discussion sur le compte d'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 (AmazonEC2), les réseaux Amazon Virtual Private Cloud (AmazonVPC) 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 détaillées des comptes de cette documentation et dans le code contenu dans le référentiel de codes. AWS SRA
Comment utiliser le AWS SRA
Il existe différentes manières de l'utiliser AWS SRA en fonction de l'étape dans laquelle vous vous trouvez dans votre parcours d'adoption du cloud. Voici une liste des moyens de tirer le meilleur parti des AWS SRA actifs (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 AWS vers le cloud (création de votre premier ensemble de comptes) ou que vous envisagiez d'améliorer un AWS environnement établi, AWS SRA c'est ici que vous devez 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 de nouvelles charges de travail, vous pouvez utiliser votre version personnalisée du 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 le AWSSRA, 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 au AWSSRA. AWSSRAIl est conçu pour être complet et fournit une base de diagnostic pour évaluer votre propre sécurité. Lorsque vos conceptions de sécurité s'alignent sur les AWSSRA, vous pouvez être plus sûr de suivre les meilleures pratiques lors de l'utilisation AWS des services. Si vos conceptions de sécurité divergent ou ne sont pas conformes aux instructions contenues dans le AWSSRA, 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 AWS SRA meilleures pratiques. 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, au lieu d'utiliser des AWS services, vous pouvez avoir une préférence de fonctionnalité pour un produit du réseau de AWS partenaires ou pour une application personnalisée que vous avez créée et gérée. Parfois, au cours de cet examen, vous découvrirez peut-être que vos décisions précédentes ont été prises en fonction de technologies, de AWS fonctionnalités ou de contraintes commerciales plus anciennes 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 la AWSSRA, 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 AWS SRA d'infrastructure sous forme de code (IaC) 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
-
En savoir plus sur les services et fonctionnalités de AWS sécurité.
Les conseils et les discussions contenus dans le document AWS SRA incluent des fonctionnalités importantes ainsi que des considérations relatives au déploiement et à la gestion des différents AWS services liés à la sécurité. L'une de ses caractéristiques AWS SRA est qu'il fournit une introduction de haut niveau à l'étendue des services de AWS sécurité 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 AWS services, de produits AWS partenaires 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 des AWS clés du service de gestion des clés (AWSKMS) 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 à les adapter AWS SRA au mieux à 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. AWSrecommande 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. Ils AWS SRA peuvent être un moyen d'identifier et d'éclairer ces discussions.
Principales directives de mise en œuvre du AWS SRA
Voici huit points essentiels à retenir lors de la conception et AWS SRA de la mise en œuvre de votre sécurité.
-
AWSOrganisations et 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.
-
Defense-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 des AWS Organisations, 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. Il AWS SRA montre comment les différents AWS services fonctionnent à différentes couches de la pile AWS technologique et comment l'utilisation combinée de ces services peut vous aider à atteindre vos objectifs defense-in-depth. Ce defense-in-depth concept 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é de composants de sécurité associés à de multiples AWS services et fonctionnalités pour créer une infrastructure cloud robuste et résiliente. Lorsque vous les adaptez AWS SRA à vos besoins particuliers, tenez compte non seulement de la fonction principale des AWS services et des fonctionnalités (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 AWS organisation. 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 des AWS services qui peuvent être déployés sur chaque compte (distribués plutôt que centralisés) et créez un ensemble cohérent de garde-fous partagés qui peuvent contribuer à protéger vos charges de travail contre toute utilisation abusive et à réduire l'impact des événements de sécurité. Il AWS SRA utilise AWS Security Hub (surveillance centralisée des recherches 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 (enregistrement de l'APIactivité des services dans votre environnement) et Amazon Macie (classification des données) comme ensemble AWS de base de services à déployer sur chaque compte. AWS
-
Utilisez la fonctionnalité d'administration déléguée d'AWSOrganizations, 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 AWS membre 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 AWS services 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 des 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 AWS organisations. En utilisant AWS des services qui prennent en charge l'agrégation multi-comptes (et parfois multirégions), ainsi que des fonctionnalités d'administration déléguée, vous permettez à vos équipes centrales chargées de la sécurité, du réseau et du cloud d'avoir une visibilité et 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 AWS environnement multi-comptes en mettant en œuvre des contrôles de sécurité prédéfinis pour démarrer la création de votre architecture de référence de sécurité. AWSControl Tower fournit un plan pour assurer la gestion des identités, l'accès fédéré aux comptes, la 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 AWS SRA code. La fonctionnalité Account Factory approvisionne automatiquement les nouveaux comptes avec des modèles configurables basés sur une configuration de compte approuvée afin de standardiser les comptes au sein de vos AWS Organisations. Vous pouvez également étendre la gouvernance à un AWS compte individuel existant en l'inscrivant dans une unité organisationnelle (UO) déjà gouvernée par AWS Control Tower. -
Les exemples de AWS SRA code montrent comment automatiser la mise en œuvre de modèles dans le AWS SRA guide 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. L'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 SRA code peuvent être déployés dans un environnement multi-comptes d'AWSOrganizations 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 en utilisant AWS CloudFormation et Customizations for AWS Control Tower (CfCT)
. Les solutions qui ne nécessitent pas AWS de Control Tower ont été testées dans un environnement AWS Organizations en utilisant AWS CloudFormation. Si vous n'utilisez pas AWS Control Tower, vous pouvez utiliser la solution de déploiement AWS basée sur les organisations .
