Sécurité périmétrique - AWS Directives prescriptives

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.

Sécurité périmétrique

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

Cette section développe le guide AWS SRA afin de fournir des recommandations pour la création d'un périmètre de sécurité sur AWS. Il approfondit les services de périmètre AWS et la manière dont ils s'intègrent dans les unités d'organisation définies par l'AWS SRA.

Dans le contexte de ce guide, un périmètre est défini comme la limite à laquelle vos applications se connectent à Internet. La sécurité du périmètre inclut la diffusion sécurisée du contenu, la protection de la couche d'application et l'atténuation des attaques par déni de service distribué (DDoS). Les services périmétriques AWS incluent Amazon CloudFront, AWS WAF, AWS Shield, Amazon Route 53 et AWS Global Accelerator. Ces services sont conçus pour fournir un accès sécurisé, à faible latence et à haute performance aux ressources AWS et à la diffusion de contenu. Vous pouvez utiliser ces services de périmètre avec d'autres services de sécurité tels qu'Amazon GuardDuty et AWS Firewall Manager pour vous aider à créer un périmètre sécurisé pour vos applications.

Il existe plusieurs modèles d'architecture pour la sécurité périmétrique afin de répondre aux différents besoins des organisations. Cette section se concentre sur deux modèles courants : le déploiement des services de périmètre dans un compte central (réseau) et le déploiement de certains services de périmètre dans des comptes de charge de travail individuels (application). Cette section présente les avantages des deux architectures et leurs principales considérations.

Déploiement de services de périmètre dans un seul compte réseau

Le schéma suivant s'appuie sur l'AWS SRA de base pour illustrer l'architecture dans laquelle les services de périmètre sont déployés dans le compte réseau.

Déploiement de services de périmètre dans un compte réseau

Le déploiement des services de périmètre dans un seul compte réseau présente plusieurs avantages :

  • Ce modèle prend en charge des cas d'utilisation tels que les secteurs hautement réglementés, dans lesquels vous souhaitez limiter l'administration des services de périmètre au sein de votre organisation à une seule équipe spécialisée.

  • Il simplifie la configuration nécessaire pour limiter la création, la modification et la suppression de composants de réseau.

  • Il simplifie la détection, car l'inspection s'effectue en un seul endroit, ce qui réduit le nombre de points d'agrégation des journaux.

  • Vous pouvez créer des ressources personnalisées relatives aux meilleures pratiques, telles que des CloudFront politiques et des fonctions périphériques, et les partager entre les distributions d'un même compte.

  • Il simplifie la gestion des ressources critiques sensibles aux erreurs de configuration, telles que les paramètres de cache du réseau de diffusion de contenu (CDN) ou les enregistrements DNS, en réduisant le nombre d'emplacements où ces modifications sont mises en œuvre.

Les sections suivantes abordent chaque service et les considérations architecturales.

Amazon CloudFront

Amazon CloudFront est un service de réseau de diffusion de contenu (CDN) conçu pour optimiser les performances, la sécurité et le confort des développeurs. Pour les points de terminaison HTTP publics accessibles à Internet, nous vous recommandons de les utiliser CloudFront pour distribuer votre contenu accessible sur Internet. CloudFront est un proxy inverse qui sert de point d'entrée unique pour votre application dans le monde entier. Il peut également être associé à AWS WAF et à des fonctions périphériques telles que Lambda @Edge, ainsi qu'à des CloudFront fonctions permettant de créer des solutions sécurisées et personnalisables pour la diffusion de contenu.

Dans cette architecture de déploiement, toutes les CloudFront configurations, y compris les fonctions de périphérie, sont déployées dans le compte réseau et gérées par une équipe réseau centralisée. Seuls les employés autorisés de l'équipe de mise en réseau doivent avoir accès à ce compte. Les équipes d'application qui souhaitent apporter des modifications à leur CloudFront configuration ou à leur liste de contrôle d'accès Web (ACL Web) pour AWS WAF doivent demander ces modifications à l'équipe réseau. Nous vous recommandons d'établir un flux de travail, tel qu'un système de tickets, pour que les équipes chargées des applications puissent demander des modifications de configuration.

Dans ce modèle, les origines dynamiques et statiques sont situées dans les comptes d'application individuels. L'accès à ces origines nécessite donc des autorisations et des rôles entre comptes. Les journaux des CloudFront distributions sont configurés pour être envoyés au compte Log Archive.

AWS WAF

AWS WAF est un pare-feu d'application Web qui vous permet de surveiller les requêtes HTTP et HTTPS qui sont transmises à vos ressources d'application Web protégées. Ce service peut contribuer à protéger vos ressources contre les attaques Web courantes et les menaces volumétriques, ainsi que contre les menaces plus sophistiquées telles que la fraude liée à la création de comptes, l'accès non autorisé aux comptes d'utilisateurs et les robots qui tentent d'échapper à la détection. AWS WAF peut aider à protéger les types de ressources suivants : CloudFront distributions, API REST Amazon API Gateway, équilibreurs de charge d'application, API AWS AppSync GraphQL, groupes d'utilisateurs Amazon Cognito, services AWS App Runner et instances AWS Verified Access.

Dans cette architecture de déploiement, AWS WAF est associé aux CloudFront distributions configurées dans le compte réseau. Lorsque vous configurez AWS WAF avec CloudFront, l'empreinte périmétrique est étendue aux emplacements CloudFront périphériques au lieu du VPC de l'application. Cela permet de rapprocher le filtrage du trafic malveillant de la source de ce trafic et d'empêcher le trafic malveillant d'entrer dans votre réseau central.

Bien que les listes ACL Web soient déployées dans le compte réseau, nous vous recommandons d'utiliser AWS Firewall Manager pour gérer de manière centralisée les listes ACL Web et vous assurer que toutes les ressources sont conformes. Définissez le compte d'outils de sécurité comme compte administrateur pour Firewall Manager. Déployez les politiques de Firewall Manager avec correction automatique pour garantir qu'une ACL Web soit attachée à toutes les CloudFront distributions (ou à certaines d'entre elles) de votre compte.

Vous pouvez envoyer des journaux AWS WAF complets vers un compartiment S3 du compte d’archivage des journaux en configurant l’accès intercompte au compartiment S3. Pour plus d'informations, consultez l'article AWS re:Post à ce sujet.

Surveillances de l'état AWS Shield et AWS Route 53

AWS Shield Standard et AWS Shield Advanced offrent des protections contre les attaques par déni de service distribué (DDoS) pour les ressources AWS au niveau des couches réseau et transport (couches 3 et 4) et de la couche application (couche 7). Shield Standard est inclus automatiquement, sans frais supplémentaires au-delà de ce que vous avez déjà payé pour AWS WAF et vos autres services AWS. Shield Advanced fournit une protection étendue contre les événements DDoS pour vos instances Amazon EC2, vos équilibreurs de charge Elastic Load Balancing CloudFront , vos distributions et vos zones hébergées Route 53. Si vous possédez des sites Web à haute visibilité ou si vos applications sont sujettes à des événements DDoS fréquents, pensez aux fonctionnalités supplémentaires proposées par Shield Advanced.

Cette section se concentre sur les configurations de Shield Advanced, car Shield Standard n'est pas configurable par l'utilisateur.

Pour configurer Shield Advanced afin de protéger vos CloudFront distributions, abonnez le compte réseau à Shield Advanced. Dans le compte, ajoutez l'assistance de l'équipe SRT (Shield Response Team) et accordez les autorisations nécessaires à l'équipe SRT pour accéder à vos listes ACL Web lors d'un événement DDoS. Vous pouvez contacter l'équipe SRT à tout moment pour créer et gérer des mesures d'atténuation personnalisées pour votre application lors d'un événement DDoS actif. La configuration préalable de l'accès donne à l'équipe SRT la flexibilité nécessaire pour déboguer et réviser les listes ACL Web sans avoir à gérer les autorisations lors d'un événement.

Utilisez Firewall Manager avec correction automatique pour ajouter vos CloudFront distributions en tant que ressources protégées. Si vous disposez d'autres ressources accessibles sur Internet, telles que les Application Load Balancers, vous pouvez envisager de les ajouter en tant que ressources protégées par Shield Advanced. Toutefois, si le flux de données contient plusieurs ressources protégées par Shield Advanced (par exemple, votre Application Load Balancer en est l'origine CloudFront), nous vous recommandons de n'utiliser que le point d'entrée comme ressource protégée afin de réduire les frais de double transfert de données sortants (DTO) pour Shield Advanced.

Activez la fonctionnalité d'engagement proactif pour permettre à l'équipe SRT de surveiller de manière proactive vos ressources protégées et de vous contacter si nécessaire. Pour configurer efficacement la fonctionnalité d'engagement proactif, créez des bilans de santé Route 53 pour votre application et associez-les aux CloudFront distributions. Shield Advanced utilise les surveillances de l'état comme point de données supplémentaire lorsqu'il évalue un événement. Les surveillances de l'état doivent être correctement définies afin de réduire le nombre de faux positifs lors de la détection. Pour plus d'informations sur l'identification des métriques appropriées pour les surveillances de l'état, consultez Best practices for using health checks with Shield Advanced dans la documentation AWS. Si vous détectez une tentative de DDoS, vous pouvez contacter l'équipe SRT et choisir le niveau de gravité le plus élevé disponible pour votre plan de support.

AWS Certificate Manager et AWS Route 53

AWS Certificate Manager (ACM) vous aide à allouer, gérer et renouveler les certificats X.509 SSL/TLS publics et privés. Lorsque vous utilisez ACM pour gérer des certificats, les clés privées des certificats sont protégées et stockées de manière sécurisée grâce à un chiffrement renforcé et aux meilleures pratiques de gestion des clés.

ACM est déployé dans le compte réseau afin de générer un certificat TLS public pour CloudFront les distributions. Des certificats TLS sont nécessaires pour établir une connexion HTTPS entre les spectateurs et CloudFront. Pour plus d'informations, consultez la CloudFront documentation. ACM fournit une validation DNS ou par e-mail pour valider la propriété du domaine. Nous vous recommandons d'utiliser la validation DNS plutôt que la validation par e-mail, car en utilisant Route 53 pour gérer vos enregistrements DNS publics, vous pouvez mettre à jour vos enregistrements directement via ACM. ACM renouvelle automatiquement les certificats qui ont fait l'objet d'une validation DNS tant que le certificat est utilisé et que l'enregistrement DNS est en place.

CloudFront journaux d'accès et journaux AWS WAF

Par défaut, les journaux CloudFront d'accès sont stockés dans le compte réseau et les journaux AWS WAF sont agrégés dans le compte Security Tooling à l'aide de l'option de journalisation Firewall Manager. Nous vous recommandons de répliquer ces journaux dans le compte d'archivage des journaux afin que les équipes de sécurité centralisées puissent y accéder à des fins de surveillance.

Considérations relatives à la conception
  • Dans cette architecture, le grand nombre de dépendances à l'égard d'une seule équipe réseau peut affecter votre capacité à apporter des modifications rapidement.

  • Surveillez les quotas de service pour chaque compte. Les quotas de service, également appelés limites, représentent le nombre maximal de ressources ou d'opérations de service pour votre compte AWS. Pour plus d'informations, consultez AWS service quotas dans la documentation AWS.

  • Fournir des métriques spécifiques aux équipes responsables de la charge de travail peut s'avérer complexe.

  • Les équipes chargées des applications ont un accès limité aux configurations, ce qui peut entraîner une surcharge de travail en attendant que les équipes chargées des réseaux mettent en œuvre les changements en leur nom.

  • Les équipes qui partagent les ressources d'un même compte peuvent se disputer les mêmes ressources et les mêmes budgets, ce qui peut entraîner des problèmes d'affectation des ressources. Nous vous recommandons de mettre en place des mécanismes de remboursement par les équipes d'application qui utilisent les services de périmètre déployés dans le compte de mise en réseau.

Déploiement de services de périmètre dans des comptes d'applications individuels

Le schéma suivant illustre le modèle d'architecture dans lequel les services de périmètre sont déployés et gérés indépendamment dans des comptes d'application individuels.

Déploiement de services de périmètre dans des comptes d'applications individuels

Le déploiement des services de périmètre dans les comptes d'applications présente plusieurs avantages :

  • Cette conception permet aux comptes de charge de travail individuels de personnaliser les configurations de service en fonction de leurs besoins. Cette approche supprime la dépendance à l'égard d'une équipe spécialisée pour mettre en œuvre les modifications apportées aux ressources d'un compte partagé, et permet aux développeurs de chaque équipe de gérer les configurations de manière indépendante.

  • Chaque compte possède ses propres quotas de service, de sorte que les propriétaires d'applications n'ont pas à respecter les quotas d'un compte partagé.

  • Cette conception permet de contenir l'impact des activités malveillantes en les limitant à un compte particulier et en empêchant l'attaque de se propager à d'autres charges de travail.

  • Cela élimine les risques liés au changement, car l'impact est limité à la charge de travail en question. Vous pouvez également utiliser l'IAM pour limiter le nombre d'équipes habilitées à mettre en œuvre des changements, afin d'établir une séparation logique entre les équipes chargées de la charge de travail et l'équipe de mise en réseau centrale.

  • En décentralisant la mise en œuvre des entrées et sorties du réseau, tout en disposant de contrôles logiques communs (en utilisant des services tels qu'AWS Firewall Manager), vous pouvez ajuster les contrôles du réseau à des charges de travail spécifiques tout en continuant à respecter une norme minimale d'objectifs de contrôle.

Les sections suivantes abordent chaque service et les considérations architecturales.

Amazon CloudFront

Dans cette architecture de déploiement, les CloudFront configurations Amazon, y compris les fonctions de périphérie, sont gérées et déployées dans les comptes d'applications individuels. Cela permet de vérifier que chaque propriétaire d'application et chaque compte de charge de travail disposent de l'autonomie nécessaire pour configurer les services de périmètre en fonction des besoins de leur application.

Les origines dynamiques et statiques se trouvent dans le même compte d'application, et les CloudFront distributions ont un accès à ces origines au niveau du compte. Les journaux des CloudFront distributions sont stockés localement dans chaque compte d'application. Les journaux peuvent être répliqués sur le compte d'archivage des journaux pour répondre aux besoins de conformité et de réglementation.

AWS WAF

Dans cette architecture de déploiement, AWS WAF est associé aux CloudFront distributions configurées dans le compte d'application. Comme pour le modèle précédent, nous vous recommandons d'utiliser AWS Firewall Manager pour gérer de manière centralisée les listes ACL Web et vous assurer que toutes les ressources sont conformes. Les règles AWS WAF courantes, telles que le groupe de règle de base géré par AWS et la liste de réputation d'adresses IP Amazon, doivent être ajoutées par défaut. Ces règles sont automatiquement appliquées à toute ressource éligible dans le compte de l'application.

Outre les règles appliquées par Firewall Manager, chaque propriétaire d'application peut ajouter à la liste ACL Web des règles AWS WAF pertinentes pour la sécurité de son application. Cela permet une certaine flexibilité dans chaque compte d'application tout en conservant le contrôle global du compte d'outils de sécurité.

Utilisez l'option de journalisation de Firewall Manager pour centraliser les journaux et les envoyer vers un compartiment S3 du compte d'outils de sécurité. Chaque équipe d'application a accès aux tableaux de bord AWS WAF pour son application. Vous pouvez configurer le tableau de bord à l'aide d'un service tel qu'Amazon QuickSight. Si de faux positifs sont identifiés ou si d'autres mises à jour des règles AWS WAF sont nécessaires, vous pouvez ajouter des règles AWS WAF au niveau de l'application à la liste ACL Web déployée par Firewall Manager. Les journaux sont répliqués sur le compte d'archivage des journaux et archivés pour les investigations de sécurité.

AWS Global Accelerator

AWS Global Accelerator vous permet de créer des accélérateurs afin d'améliorer les performances de vos applications pour les utilisateurs locaux et internationaux. Global Accelerator vous fournit des adresses IP statiques qui servent de points d'entrée fixes à vos applications hébergées dans une ou plusieurs Régions AWS. Vous pouvez associer ces adresses aux ressources ou points de terminaison AWS régionaux, tels que les Application Load Balancers, les Network Load Balancers, les instances EC2 et les adresses IP Elastic. Cela permet au trafic d'entrer dans le réseau mondial AWS aussi près que possible de vos utilisateurs.

Global Accelerator ne prend actuellement pas en charge les origines entre comptes. Par conséquent, il est déployé sur le même compte que le point de terminaison d'origine. Déployez les accélérateurs dans chaque compte d'application et ajoutez-les en tant que ressources protégées pour AWS Shield Advanced dans le même compte. Les mesures d'atténuation de Shield Advanced ne permettent qu'au trafic valide d'atteindre les points de terminaison d'écouteur de Global Accelerator.

Surveillances de l'état AWS Shield Advanced et AWS Route 53

Pour configurer AWS Shield Advanced afin de protéger vos CloudFront distributions, vous devez abonner chaque compte d'application à Shield Advanced. Vous devez configurer des fonctionnalités telles que l'accès à l'équipe SRT (Shield Response Time) et l'engagement proactif au niveau du compte, car elles doivent être configurées dans le même compte que la ressource. Utilisez Firewall Manager avec correction automatique pour ajouter vos CloudFront distributions en tant que ressources protégées et appliquez la politique à chaque compte. Les bilans de santé de Route 53 pour chaque CloudFront distribution doivent être déployés dans le même compte et associés à la ressource.

Zones Amazon Route 53 et ACM

Lorsque vous utilisez des services tels qu'Amazon CloudFront, les comptes d'application doivent accéder au compte qui héberge le domaine racine afin de créer des sous-domaines personnalisés et d'appliquer des certificats émis par Amazon Certificate Manager (ACM) ou un certificat tiers. Vous pouvez déléguer un domaine public du compte de services partagés central à des comptes d'application individuels en utilisant la délégation de zone Amazon Route 53. La délégation de zone permet à chaque compte de créer et de gérer des sous-domaines spécifiques à une application, tels que des API ou des sous-domaines statiques. L'ACM de chaque compte permet à chaque compte d'application de gérer les processus d'approbation et de vérification des certificats (validation de l'organisation, validation étendue ou validation du domaine) en fonction de ses besoins.

CloudFront journaux d'accès, journaux de flux de Global Accelerator et journaux AWS WAF

Dans ce modèle, nous configurons les journaux CloudFront d'accès et les journaux de flux Global Accelerator dans des compartiments S3 dans des comptes d'application individuels. Les développeurs qui souhaitent analyser les journaux pour améliorer les performances ou réduire les faux positifs auront un accès direct à ces journaux sans avoir à demander l'accès à une archive de journaux centrale. Les journaux stockés localement peuvent également répondre aux exigences de conformité régionales telles que la résidence des données ou le masquage des données d'identification personnelle.

Les journaux AWS WAF complets sont stockés dans les compartiments S3 du compte d'archivage de journaux à l'aide de la journalisation Firewall Manager. Les équipes chargées des applications peuvent consulter les journaux à l'aide de tableaux de bord configurés à l'aide d'un service tel qu'Amazon QuickSight. En outre, chaque équipe chargée des applications a accès aux journaux AWS WAF échantillonnés depuis son propre compte pour un débogage rapide.

Nous vous recommandons de répliquer les journaux dans un lac de données centralisé situé dans le compte d'archivage de journaux. L'agrégation des journaux dans un lac de données centralisé vous donne une vue complète de l'ensemble du trafic vers vos ressources et distributions AWS WAF. Cela permet aux équipes de sécurité d'analyser et de répondre de manière centralisée aux modèles de menaces de sécurité globales.

Considérations relatives à la conception
  • Ce modèle transfère la responsabilité de l'administration du réseau et de la sécurité aux propriétaires de comptes et aux développeurs, ce qui peut alourdir le processus de développement.

  • Il peut y avoir des incohérences dans la prise de décisions. Vous devez mettre en place des communications, des modèles et des formations efficaces pour vous assurer que les services sont configurés correctement et suivent les recommandations de sécurité.

  • Il existe une dépendance à l'égard de l'automatisation et des attentes claires à l'égard des contrôles de sécurité de base combinés aux contrôles spécifiques à l'application.

  • Utilisez des services tels que Firewall Manager et AWS Config pour vous assurer que l'architecture déployée est conforme aux meilleures pratiques de sécurité. Configurez également la CloudTrail surveillance AWS pour détecter toute erreur de configuration.

  • L'agrégation des journaux et des métriques en un lieu central à des fins d'analyse peut s'avérer complexe.

Services AWS supplémentaires pour les configurations de sécurité périmétrique

Origines dynamiques : Application Load Balancers

Vous pouvez configurer Amazon CloudFront pour utiliser les origines d'Application Load Balancer pour la diffusion dynamique de contenu. Cette configuration vous permet d'acheminer les demandes vers différentes origines d'Application Load Balancer en fonction de divers facteurs tels que le chemin de la demande, le nom d'hôte ou les paramètres de chaîne de requête.

Les origines d'Application Load Balancer sont déployées dans le compte d'application. Si vos CloudFront distributions se trouvent dans le compte réseau, vous devez configurer des autorisations entre comptes pour que la CloudFront distribution puisse accéder à l'origine de l'Application Load Balancer. Les journaux de l'Application Load Balancer sont envoyés au compte d'archivage de journaux.

Pour empêcher les utilisateurs d'accéder directement à un Application Load Balancer sans passer par celui-ci CloudFront, procédez comme suit :

  • Configurez CloudFront pour ajouter un en-tête HTTP personnalisé aux demandes qu'il envoie à l'Application Load Balancer, et configurez l'Application Load Balancer pour transférer uniquement les demandes contenant l'en-tête HTTP personnalisé.

  • Utilisez une liste de préfixes gérée par AWS pour le groupe CloudFront de sécurité Application Load Balancer. Cela limite le trafic HTTP/HTTPS entrant vers votre Application Load Balancer uniquement à partir des adresses IP appartenant CloudFront aux serveurs d'origine.

Pour plus d'informations, consultez la section Restreindre l'accès aux équilibreurs de charge d'application dans la CloudFront documentation.

Origines statiques : Amazon S3 et AWS Elemental MediaStore

Vous pouvez configurer CloudFront pour utiliser les MediaStore origines Amazon S3 ou AWS Elemental pour la diffusion de contenu statique. Ces origines sont déployées dans le compte d'application. Si vos CloudFront distributions se trouvent dans le compte réseau, vous devez configurer des autorisations entre comptes pour la CloudFront distribution dans le compte réseau afin d'accéder aux origines.

Pour vérifier que vos points de terminaison d'origine statiques ne sont accessibles que via CloudFront et non directement via l'Internet public, vous pouvez utiliser des configurations de contrôle d'accès à l'origine (OAC). Pour plus d'informations sur la restriction de l'accès, consultez Restreindre l'accès à une origine Amazon S3 et Restreindre l'accès à une MediaStore origine dans la CloudFront documentation.

AWS Firewall Manager

AWS Firewall Manager simplifie les tâches d'administration et de maintenance sur de multiples comptes et ressources, notamment AWS WAF, AWS Shield Advanced, les groupes de sécurité Amazon VPC, AWS Network Firewall et Amazon Route 53 Resolver DNS Firewall, pour une variété de protections.

Déléguez le compte d'outils de sécurité en tant que compte administrateur par défaut de Firewall Manager et utilisez-le pour gérer de manière centralisée les règles AWS WAF et les protections Shield Advanced au sein des comptes de votre organisation. Utilisez Firewall Manager pour gérer de manière centralisée les règles AWS WAF communes tout en donnant à chaque équipe chargée des applications la flexibilité d'ajouter des règles spécifiques à l'application à la liste ACL Web. Cela permet d'appliquer les stratégies de sécurité à l'échelle de l'organisation, telles que la protection contre les vulnérabilités courantes, tout en permettant aux équipes chargées des applications d'ajouter des règles AWS WAF spécifiques à leur application.

Utilisez la journalisation de Firewall Manager pour centraliser les journaux AWS WAF dans un compartiment S3 du compte d'outils de sécurité, puis répliquez les journaux sur le compte d'archivage de journaux afin de pouvoir les archiver pour des investigations de sécurité. En outre, intégrez Firewall Manager à AWS Security Hub pour visualiser de manière centralisée les détails de configuration et les notifications DDoS dans Security Hub.

Pour des recommandations supplémentaires, consultez AWS Firewall Manager dans la section Compte d'outils de sécurité de ce guide.

AWS Security Hub

L'intégration entre Firewall Manager et Security Hub envoie quatre types de résultats à Security Hub :

  • Les ressources qui ne sont pas correctement protégées par les règles AWS WAF

  • Les ressources qui ne sont pas correctement protégées par AWS Shield Advanced

  • Les résultats de Shield Advanced qui indiquent qu'une attaque DDoS est en cours

  • Les groupes de sécurité utilisés de manière incorrecte

Ces résultats provenant de tous les comptes des membres de l'organisation sont regroupés dans le compte de l'administrateur délégué du Security Hub (outils de sécurité). Le compte d'outils de sécurité regroupe, organise et hiérarchise vos alertes de sécurité ou résultats en un seul endroit. Utilisez les règles Amazon CloudWatch Events pour envoyer les résultats aux systèmes de billetterie ou créer des solutions automatiques telles que le blocage de plages d'adresses IP malveillantes.

Pour des recommandations supplémentaires, consultez AWS Security Hub dans la section Compte d'outils de sécurité de ce guide.

Amazon GuardDuty

Vous pouvez utiliser les informations sur les menaces fournies par Amazon GuardDuty pour mettre à jour automatiquement les ACL Web en réponse aux GuardDuty résultats. Par exemple, si une activité suspecte est GuardDuty détectée, l'automatisation peut être utilisée pour mettre à jour l'entrée dans les ensembles d'adresses IP AWS WAF et appliquer les ACL Web AWS WAF aux ressources concernées afin de bloquer les communications en provenance de l'hôte suspect pendant que vous effectuez des recherches et des mesures correctives supplémentaires. Le compte Security Tooling est le compte d'administrateur délégué pour GuardDuty. Par conséquent, vous devez utiliser une fonction AWS Lambda avec des autorisations entre comptes pour mettre à jour les ensembles d'adresses IP AWS WAF dans le compte d'application.

Pour des recommandations supplémentaires, consultez Amazon GuardDuty dans la section relative au compte Security Tooling de ce guide.

AWS Config

AWS Config est un prérequis pour Firewall Manager et est déployé dans les comptes AWS, y compris le compte réseau et le compte d'application. En outre, utilisez les règles AWS Config pour vérifier que les ressources déployées sont conformes aux meilleures pratiques de sécurité. Par exemple, vous pouvez utiliser une règle AWS Config pour vérifier si chaque CloudFront distribution est associée à une ACL Web, ou faire en sorte que toutes les CloudFront distributions soient configurées pour fournir des journaux d'accès à un compartiment S3.

Pour des recommandations générales, consultez AWS Config dans la section Compte d'outils de sécurité de ce guide.