Sécurité périmétrique - AWS Conseils prescriptifs
Déploiement de services de périmètre dans un seul compte réseauDéploiement de services de périmètre dans des comptes d'applications individuelsAWSServices supplémentaires pour les configurations de sécurité périmétrique

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 étend les AWS SRA directives pour fournir des recommandations pour la construction d'un périmètre sécuriséAWS. Il examine en profondeur les services AWS périmétriques et leur intégration dans OUs les services définis par le AWSSRA.

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 applicative et l'atténuation des attaques par déni de service distribué (DDoS). AWSles services périmétriques incluent Amazon CloudFront AWSWAF, 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 AWS ressources 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 la base de référence AWS SRA 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 ou les DNS enregistrements du réseau de diffusion de contenu (CDN), 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 HTTP terminaux publics connectés à Internet, nous vous recommandons de les utiliser CloudFront pour distribuer votre contenu connecté à 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 combiné à des AWS WAF fonctions périphériques telles que Lambda @Edge et à 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 (WebACL) 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

AWSWAFest un pare-feu d'applications Web qui vous permet de surveiller les HTTPS demandes HTTP et les demandes qui sont transmises à vos ressources d'applications 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. AWSWAFpeut aider à protéger les types de ressources suivants : CloudFront distributions, Amazon API Gateway RESTAPIs, équilibreurs de charge d'application, AWS AppSync APIs GraphQL, groupes d'utilisateurs Amazon CognitoAWS, AWS services App Runner et instances Verified Access.

Dans cette architecture de déploiement, elle AWS WAF est attachée 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 plutôt qu'à l'applicationVPC. 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 le Web ACLs soit déployé dans le compte réseau, nous vous recommandons d'utiliser AWS Firewall Manager pour gérer le Web de manière centralisée ACLs 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 faire en sorte que toutes les CloudFront distributions (ou certaines d'entre elles) de votre compte soient associées à une connexion WebACL.

Vous pouvez envoyer AWS WAF des journaux complets vers un compartiment S3 dans le compte Log Archive en configurant l'accès entre comptes au compartiment S3. Pour plus d'informations, consultez l'article AWS Re:Post à ce sujet.

AWSContrôles de santé du Shield et de la AWS Route 53

AWSShield Standard et AWS Shield Advanced fournissent des protections contre les attaques par déni de service distribué (DDoS) visant les AWS ressources des couches réseau et transport (couches 3 et 4) et de la couche application (couche 7). Shield Standard est automatiquement inclus sans frais supplémentaires au-delà de ce que vous avez déjà payé AWS WAF et de vos autres AWS services. Shield Advanced fournit une protection étendue contre les DDoS événements pour vos EC2 instances Amazon, vos équilibreurs de charge Elastic Load Balancing, vos CloudFront distributions et les zones hébergées Route 53. Si vous possédez des sites Web très visibles ou si vos applications sont sujettes à des DDoS événements 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 le support de Shield Response Team (SRT) et fournissez les autorisations nécessaires pour que l'SRTéquipe puisse accéder à votre site Web ACLs lors d'un DDoS événement. Vous pouvez les contacter SRT à tout moment pour créer et gérer des mesures d'atténuation personnalisées pour votre application lors d'un DDoS événement actif. La configuration préalable de l'accès permet SRT de déboguer et de réviser le Web ACLs 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 fonction d'engagement proactif pour vous SRT permettre 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 indicateurs appropriés pour les bilans de santé, consultez la section Meilleures pratiques d'utilisation des bilans de santé avec Shield Advanced dans la AWS documentation. Si vous détectez une DDoS tentative, vous pouvez contacter le SRT et choisir le niveau de gravité le plus élevé disponible pour votre plan de support.

AWSCertificate Manager et AWS Route 53

AWSCertificate Manager (ACM) vous aide à provisionner, gérer et renouveler les certificats TLS X.509 publics et privésSSL. Lorsque vous gérez des certificats, les clés privées des certificats sont protégées et stockées de manière sécurisée en utilisant un cryptage renforcé et les meilleures pratiques de gestion des clés. ACM

ACMest déployé dans le compte réseau afin de générer un TLS certificat public pour les CloudFront distributions. TLSdes certificats sont nécessaires pour établir une HTTPS connexion entre les spectateurs et CloudFront. Pour plus d'informations, consultez la CloudFront documentation. ACMfournit une DNS validation par e-mail pour valider la propriété du domaine. Nous vous recommandons d'utiliser la DNS validation plutôt que la validation par e-mail, car en utilisant Route 53 pour gérer vos DNS archives publiques, vous pouvez les mettre à jour ACM directement. ACMrenouvelle automatiquement les certificats DNS validés tant qu'un certificat est utilisé et que l'DNSenregistrement est en place.

CloudFront journaux d'accès et AWS WAF journaux

Par défaut, les journaux CloudFront d'accès sont stockés dans le compte réseau et les AWS WAF journaux sont agrégés dans le compte Security Tooling à l'aide de l'option de journalisation de 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, correspondent au nombre maximal de ressources ou d'opérations de service pour votre AWS compte. Pour plus d'informations, consultez la section Quotas de AWS service dans la AWS documentation.

  • 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 l'utiliser 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 réseau centrale.

  • En décentralisant la mise en œuvre de l'entrée et de la sortie du réseau, tout en disposant de contrôles logiques communs (en utilisant des services tels que AWS Firewall Manager), vous pouvez adapter les contrôles réseau à des charges de travail spécifiques tout en continuant à respecter un niveau minimum 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, elle AWSWAFest attachée 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 le Web de manière centralisée ACLs et vous assurer que toutes les ressources sont conformes. Des AWS WAF règles communes telles que l'ensemble de règles de base AWS gérées et la liste de réputation d'Amazon IP 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 des AWS WAF règles relatives à la sécurité de ses applications sur le WebACL. 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 chargée des applications est autorisée à consulter les AWS WAF tableaux de bord de son application. Vous pouvez configurer le tableau de bord à l'aide d'un service tel qu'Amazon QuickSight. Si des faux positifs sont identifiés ou si d'autres mises à jour des AWS WAF règles sont nécessaires, vous pouvez ajouter des AWS WAF règles au niveau de l'application sur le Web ACL déployées 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

AWSGlobal 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 AWS régions. Vous pouvez associer ces adresses à des AWS ressources ou à des points de terminaison régionaux, tels que les équilibreurs de charge d'application, les équilibreurs de charge réseau, les EC2 instances et les adresses IP élastiques. Cela permet au trafic d'accéder au réseau AWS mondial le plus près 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.

AWSContrôles de santé Shield Advanced et AWS Route 53

Pour configurer AWSShield 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 à la Shield Response Team (SRT) 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 à l'application, tels que API des sous-domaines statiques. Le compte ACM intégré à chaque compte permet à chaque compte d'application de gérer les processus de validation 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 AWS WAF journaux

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 ou le PII brouillage des données.

Les AWS WAF journaux complets sont stockés dans les compartiments S3 du compte Log Archive à 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 d'application a accès aux AWSWAFjournaux é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 AWS WAF ressources et vos distributions. 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 AWS CloudTrail surveillance pour détecter les erreurs de configuration.

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

AWSServices 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 HTTP en-tête 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 personnalisé. HTTP

  • Utilisez une liste de préfixes AWS gérée pour le groupe CloudFront de sécurité Application Load Balancer. Cela limite le trafic HTTP entrant/le HTTPS trafic vers votre Application Load Balancer provenant uniquement 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 Amazon S3 ou AWS Elemental MediaStore Origins 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

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

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

Utilisez la journalisation de Firewall Manager pour centraliser AWS WAF les journaux dans un compartiment S3 du compte Security Tooling, et répliquez les journaux sur le compte Log Archive afin de pouvoir les archiver à des fins d'enquêtes 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 DDoS les notifications dans Security Hub.

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

AWS Security Hub

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

  • Ressources qui ne sont pas correctement protégées par des AWS WAF règles

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

  • Résultats de Shield Advanced indiquant qu'une DDoS attaque 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 AWSSecurity Hub dans la section relative au compte Security Tooling de ce guide.

Amazon GuardDuty

Vous pouvez utiliser les informations sur les menaces fournies par Amazon GuardDuty pour mettre à jour automatiquement le Web ACLs 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'AWSWAFadresses IP et appliquer le AWS WAF Web ACLs 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'AWSWAFadresses IP dans le compte d'application.

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

AWSConfig

AWSConfig est une condition préalable à Firewall Manager et est déployée dans AWS les comptes, y compris le compte réseau et le compte 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 à un site WebACL, 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, voir AWSConfig dans la section relative au compte Security Tooling de ce guide.