Contrôlez l’accès à votre site

AWSBeginner
Pratiquer maintenant

Introduction

Retirez puis restaurez une règle EC2 pour observer les connexions réelles tout en conservant SSH.

Terminez les laboratoires précédents du portfolio. Cet environnement fournit ses propres ressources et les capacités antérieures nécessaires. Réutilisez les connaissances, pas les instances, fichiers ou identifiants précédents.

Lien avec la certification

Certification Tâches Pratique
AWS Certified Cloud Practitioner (CLF-C02) Task 3.5 Contrôler les connexions EC2 par un groupe de sécurité.

Vue d’ensemble

Retirez puis restaurez une règle EC2 pour observer les connexions réelles tout en conservant SSH.

Observer une connexion bloquée

Dans cette étape, vous retirerez uniquement la règle du site et comparerez la réponse de la page avec l’état du serveur.

Ce labo fournit un nouveau serveur. Ouvrez le portfolio depuis son AWS View et vérifiez Alex Morgan avant toute modification. Revenez dans Terminal et entrez dans le projet :

cd /home/labex/project

Comme précédemment, source charge les identifiants du serveur actuel. Affichez SECURITY_GROUP_ID, le groupe à modifier :

source website.env
echo "$SECURITY_GROUP_ID"

Un groupe de sécurité contrôle les connexions réseau d’une instance. Une règle entrante autorise une connexion vers elle. Un port désigne le service : SSH utilise 22 et ce site HTTP 8081. D’autres sites utilisent souvent HTTP 80 ou HTTPS 443 ; utilisez ici le port configuré pour cette application.

Lisez le groupe avant de le modifier :

Comme dans le premier labo, --query sélectionne une partie de la réponse. Ici, il garde uniquement les règles entrantes du premier groupe, SecurityGroups[0].IpPermissions, pour se concentrer sur les deux droits utiles.

aws ec2 describe-security-groups \
  --group-ids "$SECURITY_GROUP_ID" \
  --query 'SecurityGroups[0].IpPermissions'

La sortie affiche uniquement les règles entrantes. FromPort et ToPort indiquent la plage. Repérez deux règles, pour 22 et 8081. La source 198.51.100.10/32 représente un visiteur préparé pour cet exercice ; /32 signifie une adresse IPv4. Ce n’est pas l’adresse publique de votre ordinateur : gardez la valeur fournie.

Retirez seulement le droit d’accès web. revoke-security-group-ingress supprime une règle correspondante ; --protocol tcp choisit le protocole, --port 8081 le service web et --cidr la source autorisée :

aws ec2 revoke-security-group-ingress \
  --group-id "$SECURITY_GROUP_ID" \
  --protocol tcp \
  --port 8081 \
  --cidr 198.51.100.10/32

La réponse confirme le changement. Actualisez le portfolio : Website connection unavailable doit apparaître, tandis que l’instance reste running dans AWS View.

Une nouvelle requête échoue après le retrait de la règle web, mais le serveur reste en fonctionnement.

AWS View indique toujours running pendant le blocage web ; les identifiants sont des exemples.

L’application n’est pas désinstallée et le serveur n’est pas arrêté : la règle réseau bloque la connexion. Les groupes suivent les connexions autorisées ; la nouvelle requête de cet exercice teste la règle modifiée. Conservez la règle SSH.

Rétablir l’accès au site

Dans cette étape, vous rétablirez le droit précis et vérifierez que l’application répond de nouveau.

authorize-security-group-ingress ajoute une règle entrante. Utilisez le même groupe, le port TCP et l’adresse du visiteur préparé :

aws ec2 authorize-security-group-ingress \
  --group-id "$SECURITY_GROUP_ID" \
  --protocol tcp \
  --port 8081 \
  --cidr 198.51.100.10/32

Actualisez le portfolio. Alex Morgan et les trois projets doivent revenir, sans réinstallation ni redémarrage. Relisez également le groupe pour vérifier la configuration :

La page réelle répond de nouveau après le rétablissement de la règle prévue.

aws ec2 describe-security-groups \
  --group-ids "$SECURITY_GROUP_ID" \
  --query 'SecurityGroups[0].IpPermissions'

Vérifiez la règle web 8081 et la règle SSH 22 inchangée, toutes deux pour 198.51.100.10/32. 0.0.0.0/0 autoriserait toutes les sources IPv4, au-delà du besoin. Rétablissez la source fournie sans ajouter de droits supplémentaires.

Vous avez vérifié la configuration et son effet réel : la règle attendue existe et la requête du visiteur réussit. Le prochain labo fournit un autre site et introduit le stockage privé de ses ressources.

Résumé

Vous avez retiré puis rétabli une règle web, observé l’échec et la récupération réels et conservé SSH. Vous avez distingué un serveur en fonctionnement d’une application accessible et vérifié que le droit reste limité au visiteur prévu.

Références officielles : security group rules.