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é
Lorsque vous créez des systèmes sur l'infrastructure AWS, les responsabilités en matière de sécurité sont partagées entre vous et AWS. Ce modèle de responsabilité partagée
Rôles IAM
Les rôles AWS Identity and Access Management (IAM) permettent aux clients d'attribuer des politiques d'accès et des autorisations détaillées aux services et aux utilisateurs sur le cloud AWS. Cette solution crée des rôles IAM qui accordent aux fonctions AWS Lambda de la solution l'accès pour créer des ressources régionales.
Amazon CloudFront
Cette solution déploie une interface utilisateur Web hébergée dans un compartiment Amazon S3, distribué par Amazon CloudFront. Afin de réduire le temps de latence et d'améliorer la sécurité, cette solution inclut une CloudFront distribution dotée d'une identité d'accès d'origine, à savoir un CloudFront utilisateur fournissant un accès public au contenu du bucket du site Web de la solution. Par défaut, la CloudFront distribution utilise le protocole TLS 1.2 pour appliquer le plus haut niveau de protocole de sécurité. Pour plus d'informations, reportez-vous à la section Restreindre l'accès à une origine Amazon S3 dans le manuel Amazon CloudFront Developer Guide.
CloudFront active des mesures de sécurité supplémentaires pour ajouter des en-têtes de sécurité HTTP à chaque réponse du spectateur. Pour plus d'informations, reportez-vous à la section Ajout ou suppression d'en-têtes HTTP dans les CloudFront réponses.
Cette solution utilise le CloudFront certificat par défaut, dont le protocole de sécurité minimum pris en charge est TLS v1.0. Pour imposer l'utilisation de TLS v1.2 ou TLS v1.3, vous devez utiliser un certificat SSL personnalisé au lieu du certificat par défaut. CloudFront Pour plus d'informations, reportez-vous à Comment configurer ma CloudFront distribution pour utiliser un SSL/TLS certificat
Amazon API Gateway
Cette solution déploie des points de terminaison Amazon API Gateway optimisés pour les périphériques afin de fournir des API RESTful pour la fonctionnalité de test de charge en utilisant le point de terminaison API Gateway par défaut plutôt qu'un domaine personnalisé. Pour les API optimisées en périphérie utilisant le point de terminaison par défaut, API Gateway utilise la politique de TLS-1-0 sécurité. Pour plus d'informations, consultez la section Working with REST APIs du manuel Amazon API Gateway Developer Guide.
Cette solution utilise le certificat API Gateway par défaut, dont le protocole de sécurité minimum pris en charge est TLS v1.0. Pour imposer l'utilisation de TLS v1.2 ou TLS v1.3, vous devez utiliser un domaine personnalisé avec un certificat SSL personnalisé au lieu du certificat API Gateway par défaut. Pour plus d'informations, reportez-vous à la section Configuration de noms de domaine personnalisés pour les API REST.
Groupe de sécurité AWS Fargate
Par défaut, cette solution ouvre la règle sortante du groupe de sécurité AWS Fargate au public. Si vous souhaitez empêcher AWS Fargate d'envoyer du trafic partout, remplacez la règle sortante par un routage sans Inter-Domain classe (CIDR) spécifique.
Ce groupe de sécurité inclut également une règle entrante qui autorise le trafic local sur le port 50 000 à destination de toute source appartenant au même groupe de sécurité. Ceci est utilisé pour permettre aux conteneurs de communiquer entre eux.
Amazon VPC
VPC : un cloud privé virtuel (VPC) basé sur le service Amazon VPC vous fournit un réseau privé et logiquement isolé dans le cloud AWS.
Vous pouvez spécifier votre propre VPC dans les CloudFormation paramètres AWS lors du déploiement. Le VPC est utilisé exclusivement par les tâches ECS qui génèrent de la charge ; la console Web et l'API ne sont pas déployées au sein de ce VPC. Si vous ne spécifiez aucun VPC existant, la solution créera un nouveau VPC avec la configuration réseau requise. Si vous choisissez d'utiliser un VPC existant, celui-ci doit répondre aux exigences suivantes pour exécuter correctement les tâches de test de charge.
Exigences du VPC
Les exigences minimales pour qu'un VPC soit utilisé dans le cadre de tests de charge distribués sur AWS sont répertoriées ci-dessous.
-
Le VPC doit contenir au moins deux AZ
-
Le VPC doit contenir au moins deux sous-réseaux, chacun dans un AZ distinct
-
Les sous-réseaux VPC peuvent être publics ou privés, mais ils doivent utiliser la même configuration (publique OU privée)
-
Le VPC doit fournir un accès aux points de terminaison pour ECR, CloudWatch Logs, S3 et IoT Core.
-
Le VPC doit fournir un accès au (x) service (s) ciblé (s) par les tests de charge.
Note
Si aucun VPC ne répond à ces critères, vous pouvez créer rapidement un VPC à l'aide de l'assistant VPC. Pour plus d’informations, consultez Création d’un VPC.
Les sous-réseaux publics peuvent répondre à ces exigences en incluant les éléments suivants :
-
Une passerelle Internet attachée au VPC
-
Une route vers la passerelle Internet (0.0.0. 0/0)
Les sous-réseaux privés peuvent répondre à ces exigences grâce à l'utilisation de passerelles NAT ou de points de terminaison VPC, comme décrit ci-dessous.
Option 1 : passerelle NAT
-
Déployez une passerelle NAT dans chaque AZ avec des sous-réseaux privés
-
Configurer les tables de routage pour acheminer le trafic Internet (0.0.0). 0/0) via la passerelle NAT
Option 2 : points de terminaison VPC
Créez les points de terminaison VPC suivants dans votre VPC :
-
Point de terminaison de l'API Amazon ECR :
com.amazonaws.<region>.ecr.api -
Point de terminaison Amazon ECR DKR :
com.amazonaws.<region>.ecr.dkr -
Point de terminaison Amazon CloudWatch Logs :
com.amazonaws.<region>.logs -
Point de terminaison Amazon S3 Gateway :
com.amazonaws.<region>.s3 -
Point de terminaison AWS IoT Core (obligatoire si vous utilisez les graphiques de données en temps réel)
com.amazonaws.<region>.iot.data
D'autres configurations VPC peuvent également fonctionner.
Important
Le groupe de sécurité attaché à chaque interface de point de terminaison VPC doit autoriser le trafic TCP entrant sur le port 443 en provenance du groupe de sécurité des tâches ECS.
Configuration du groupe de sécurité
Pendant le déploiement, la solution créera un groupe de sécurité au sein de votre VPC pour autoriser le trafic suivant avec des tâches dans le cluster ECS :
-
Tout le trafic sortant
-
Trafic entrant sur le port 50000 en provenance d'autres tâches du même groupe de sécurité, afin de faciliter la coordination entre les tâches du travailleur et du responsable.
Test de stress du réseau
Vous êtes responsable de l'utilisation de cette solution conformément à la politique de test Amazon EC2
Restreindre l'accès à l'interface utilisateur publique
L'approche à adopter pour restreindre l'accès à la console Web dépend de l'option de déploiement que vous choisissez.
Déploiement par défaut (CloudFront + S3) — Pour restreindre l'accès à l'interface utilisateur destinée au public au-delà des mécanismes d'authentification et d'autorisation fournis par IAM et Amazon Cognito, vous pouvez associer une ACL Web AWS WAF à la distribution. CloudFront Envisagez d'utiliser la solution AWS WAF Security Automations
Déploiement ALB + ECS Fargate — La solution déploie automatiquement une ACL Web AWS WAF devant l'ALB avec des règles gérées qui fournissent une protection de base contre les attaques Web courantes. Vous pouvez personnaliser les règles du WAF pour répondre à vos exigences de sécurité spécifiques, notamment en ajoutant des listes d' IP-based autorisation ou de blocage, des restrictions géographiques, des limites de débit ou des groupes de règles supplémentaires gérés par AWS. Pour obtenir des instructions sur la modification de la configuration du WAF, reportez-vous à la section sur l'intégration du WAF dans les instructions de déploiement.
Sécurité du serveur MCP (facultatif)
Si vous déployez l'intégration optionnelle du serveur MCP, la solution utilise Amazon Bedrock AgentCore Gateway pour fournir un accès sécurisé aux données de test de charge pour les agents d'intelligence artificielle. AgentCore Gateway valide les jetons d'authentification Amazon Cognito pour chaque demande, garantissant ainsi que seuls les utilisateurs autorisés peuvent accéder au serveur MCP. La fonction Lambda du serveur MCP implémente des modèles d'accès en lecture seule, empêchant les agents d'intelligence artificielle de modifier les configurations ou les résultats des tests. Toutes les interactions avec le serveur MCP utilisent les mêmes limites d'autorisation et les mêmes contrôles d'accès que ceux de la console Web.
Sécurité de la console Web hébergée ALB + ECS Fargate (facultatif)
Si vous choisissez l'option de déploiement ALB + ECS Fargate, les considérations de sécurité suivantes s'appliquent :
-
Compatibilité avec l'accès public par blocs VPC — L'option Fargate ALB + ECS est conçue pour les environnements dans lesquels les politiques BPA (VPC Block Public Access) bloquent le trafic provenant des distributions publiques. CloudFront L'ALB peut être déployé en tant qu'équilibreur de charge interne au sein de votre VPC, accessible uniquement via votre réseau d'entreprise, VPN ou AWS PrivateLink, répondant ainsi aux exigences d'absence d'exposition à Internet public.
-
Gestion des certificats ACM — L'ALB utilise un certificat ACM pour la terminaison HTTPS. Il vous incombe de vous assurer que le certificat reste valide et qu'il est renouvelé avant son expiration. ACM renouvelle automatiquement les certificats qu'elle gère, mais les certificats importés doivent être renouvelés manuellement. Pour plus d'informations, reportez-vous à la section Gestion du renouvellement des certificats dans le guide de l'utilisateur d'AWS Certificate Manager.
-
Protection AWS WAF — Le WAF est déployé par défaut avec le modèle Fargate ALB + ECS. Pour plus de détails, reportez-vous à la section Restreindre l'accès à l'interface utilisateur publique.
Sécurité Headless (apportez votre propre serveur Web) (facultatif)
Si vous choisissez l'option de déploiement sans interface et que vous hébergez la console Web sur votre propre serveur Web, vous êtes responsable des considérations de sécurité suivantes :
-
Configuration HTTPS — Nous vous recommandons vivement de configurer le protocole HTTPS sur votre serveur Web.
-
Contrôles d'accès — Vous êtes responsable de la mise en œuvre des contrôles d'accès, des règles de pare-feu et de la sécurité du réseau sur votre serveur Web.
-
Renforcement de la sécurité : appliquez les normes de renforcement de la sécurité de votre entreprise au serveur Web, notamment en matière de correctifs, de surveillance et de détection des intrusions.
Third-party cadres de test
Les tests de charge distribués sur AWS regroupent trois frameworks de test tiers : Apache JMeter, Grafana K6 et Locust. Dans le cadre du modèle de responsabilité partagée d'AWS
Pour plus de détails sur le moment où chaque framework est installé et comment il est provisionné, consultez la section Tester le provisionnement du framework.
Apache JMeter
La version intégrée d'Apache JMeter présente des failles de sécurité connues qui ne peuvent pas être entièrement corrigées en externe sans compromettre la compatibilité avec le framework d'automatisation des tests Taurus et l'écosystème de plugins JMeter dont dépend la solution. Avant d'exécuter des tests de charge, consultez les avis de sécurité d'Apache JMeter
Note
Apache JMeter fonctionne également sous le capot pour le type de test de point de terminaison HTTP unique. Lorsque vous configurez une URL, une méthode, des en-têtes et une charge utile corporelle dans la console Web, la solution génère un plan de test JMeter et l'exécute avec le binaire JMeter fourni. Les considérations de sécurité de JMeter décrites dans cette section s'appliquent donc également aux tests de point de terminaison HTTP unique.
Si vous avez besoin d'une version corrigée de JMeter, deux options s'offrent à vous. Les deux options nécessitent une archive de test et ne sont disponibles que pour le type de test JMeter :
-
Fournissez un binaire JMeter patché — Incluez un binaire JMeter corrigé dans votre archive de test. La solution utilise votre binaire à la place de la version groupée.
-
Remplacer les fichiers JAR de chaque plugin : utilisez le mécanisme de remplacement du plug-in pour remplacer les fichiers JAR vulnérables spécifiques par des versions corrigées. Pour plus d'informations, reportez-vous aux tests JMeter.
Le type de test Single HTTP Endpoint n'accepte pas d'archive de test et ne peut donc pas remplacer le binaire ou les plugins JMeter fournis. Si vous devez exécuter des tests de point de terminaison HTTP avec un JMeter corrigé, utilisez le type de test JMeter et fournissez un script JMeter (.jmx) ou une archive .zip qui inclut votre binaire JMeter corrigé ou les fichiers JAR de votre plugin.
Grafana K6
K6 est publié sous AGPL-3.0 licence
Criquet
Aucune vulnérabilité de sécurité connue n'a été identifiée dans la version intégrée de Locust au moment de la sortie de cette solution. La solution ne surveille pas Locust en permanence pour détecter de nouvelles vulnérabilités ; vous êtes responsable de l'évaluation de Locust par rapport à vos exigences de sécurité tout au long de son utilisation.
