La valeur du AWS SRA

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 Compte AWS) influence-t-il 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 document 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 s'aligner et se connecter au mieux AWS Config aux 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.

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

Que vous commenciez tout juste votre AWS Cloud parcours (création de votre premier ensemble de comptes) ou que vous envisagiez d'améliorer un AWS environnement établi, la AWS SRA est le point de départ idéal pour 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 de la 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 la 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 à la AWS SRA. Le 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 AWS SRA, vous pouvez être plus sûr de suivre les meilleures pratiques lors de l'utilisation Services AWS. Si vos conceptions de sécurité divergent ou ne sont pas conformes aux directives de la 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 meilleures pratiques de la 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, au lieu de l'utiliser Services AWS, vous pouvez avoir une préférence de fonctionnalité pour un produit AWS Partner Network ou 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 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 sous forme de 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 de la AWS SRA, mais ils intègrent également les contrôles de sécurité recommandés tels que les politiques de mot de passe IAM, l'accès public aux comptes de blocage Amazon Simple Storage Service (Amazon S3), le chiffrement Amazon Elastic Block Store ( EC2 Amazon EBS) par défaut d'Amazon, et l'intégration AWS Control Tower afin que les contrôles soient appliqués ou supprimés au fur et à mesure que les nouveaux sont intégrés ou mis hors service. Comptes AWS

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

Les conseils et les discussions au sein de la AWS SRA incluent des fonctionnalités importantes ainsi que des considérations relatives au déploiement et à la gestion de la AWS sécurité individuelle et des services liés à la sécurité. L'une des caractéristiques du 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 Cloud Security Posture Management (AWS Security Hub CSPM) intègre les résultats de sécurité provenant de divers AWS Partner produits Services AWS, voire 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 AWS Key Management Service (AWS KMS) les clés 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 le SRA à vos besoins. AWS À 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. Le AWS SRA peut être un moyen d'identifier et d'éclairer ces discussions.

AWS Organizations et une stratégie multi-comptes appropriée sont des éléments nécessaires 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 AWS Organizations structure, 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. Le AWS SRA montre comment les différentes Services AWS fonctions varient selon les couches AWS technologiques et comment l'utilisation combinée de ces services peut vous aider à y parvenir 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 Services AWS fonctionnalités pour créer une infrastructure cloud robuste et résiliente. Lorsque vous adaptez le AWS SRA à vos besoins particuliers, tenez compte non seulement de la fonction Services AWS et des fonctionnalités principales (par exemple, authentification, chiffrement, surveillance, politique d'autorisation), mais également de la manière dont elles s'intègrent 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-le pour chaque compte (distribué plutôt Services AWS que centralisé) et créez un ensemble cohérent de garde-fous partagés qui peuvent aider à protéger vos charges de travail contre toute utilisation abusive et à réduire l'impact des événements de sécurité. La AWS SRA utilise AWS Security Hub CSPM (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 Services AWS base à déployer dans tous les domaines. Compte AWS

Utilisez la fonctionnalité d'administration déléguée de 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 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, pour gérer l' Services AWS ensemble de l'environnement. En outre, le recours à un administrateur délégué vous permet de limiter l'accès au compte de gestion et de gérer le surcroît d'autorisations associé AWS Organizations à ce compte.

Mettez en œuvre une surveillance, une gestion et une gouvernance centralisées au sein de vos AWS organisations. En utilisant Services AWS cette prise en charge de l'agrégation multicompte (et parfois multirégionale), 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).

AWS Control Tower À utiliser pour configurer et gérer votre AWS environnement multi-comptes grâce à la mise en œuvre de contrôles de sécurité prédéfinis pour démarrer la création de votre architecture de référence de sécurité. AWS Control 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 définir les comptes gérés par des contrôles de sécurité, AWS Control Tower 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 AWS organisations. Vous pouvez également étendre la gouvernance à une personne existante en l' Compte AWS inscrivant dans une unité organisationnelle (UO) déjà gouvernée 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 AWS Organizations multi-comptes avec ou sans. AWS Control Tower Les solutions requises dans ce référentiel AWS Control Tower ont été déployées et testées dans un AWS Control Tower environnement à l'aide de AWS CloudFormation et de personnalisations pour AWS Control Tower (CfCT). Les solutions qui n'en nécessitent pas AWS Control Tower ont été testées dans un AWS Organizations environnement à l'aide de AWS CloudFormation. Si vous ne l'utilisez pas AWS Control Tower, vous pouvez utiliser la solution de déploiement AWS Organizations basée.