Introduction
Le chemin public d’une application de livraison fonctionne déjà, mais sa règle fournie autorise HTTP depuis toute source IPv4. Vous attribuerez à l’application un groupe de sécurité distinct qui n’autorise que le client et le port prévus. Des requêtes réelles montreront l’effet des restrictions de source, de port et des réponses avec état sur l’accès.
Terminez d’abord « Connecter un sous-réseau public à Internet ». Cet environnement neuf fournit son propre réseau, sa propre adresse publique, ses routes et son application ; il ne réutilise pas votre VM précédente. La CLI est déjà configurée. Conservez les ressources fournies et le réseau de référence sans rapport avec l’exercice. Seul votre nouveau groupe de sécurité est une ressource d’exercice à supprimer.
Liens avec les certifications
Ce laboratoire propose une pratique des sujets d’examen suivants.
- Cloud Practitioner (CLF-C02) · Tâche 3.5 : contrôles d’accès par groupes de sécurité dans un VPC.
- Solutions Architect – Associate (SAA-C03) · Tâche 1.2 : contrôles de sécurité applicative de base selon les sources réseau, les ports et les protocoles.
- CloudOps Engineer – Associate (SOA-C03) · Tâches 5.1 et 5.3 : configuration de base des groupes de sécurité et vérification de leur effet sur la connectivité.
- Security – Specialty (SCS-C03) · Tâche 3.3 : pratique élémentaire de l’autorisation et du blocage du trafic requis avec des groupes de sécurité.
Associer un groupe de sécurité d’exercice vide
Dans cette étape, vous inspecterez l’application fonctionnelle et remplacerez son groupe d’accès large par votre propre groupe vide.
Exécutez les commandes dans Terminal et cliquez sur AWS View à côté. La vue lit le même état des ressources que la CLI. Elle montre application-network, ses sous-réseaux public et privé et une application à l’adresse privée 10.20.1.10. Son adresse publique et sa route vers la passerelle Internet sont déjà fournies ; ne les modifiez pas.
cd /home/labex/project
Sélectionnez le VPC par son étiquette Name. --filters limite les résultats du serveur, --query sélectionne l’ID et $(...) enregistre le résultat dans une variable du shell :
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Sélectionnez l’interface d’application fournie dans ce VPC :
ENI_ID=$(aws ec2 describe-network-interfaces \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=application-interface \
--query 'NetworkInterfaces[0].NetworkInterfaceId' \
--output text)
Un groupe de sécurité contrôle le trafic autorisé sur l’interface réseau de la ressource associée. Les règles entrantes autorisent le trafic qui arrive à l’application ; les règles sortantes autorisent le trafic qu’elle initie. Enregistrez l’ID de l’unique groupe fourni pour le restaurer lors du nettoyage. [0] sélectionne le premier élément de cette liste à un seul groupe :
SUPPLIED_GROUP_ID=$(aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[0].Groups[0].GroupId' \
--output text)
Lisez ses règles sans les modifier :
aws ec2 describe-security-groups \
--group-ids "$SUPPLIED_GROUP_ID" \
--query 'SecurityGroups[].{ID:GroupId,Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
Le groupe fourni autorise le port TCP entrant 80 depuis 0.0.0.0/0, soit toute source IPv4, et tout le trafic sortant. HTTP utilise des requêtes et des réponses ; un port identifie le service destinataire. Cette application sert HTTP sur les ports TCP 80 et 8081, mais la règle fournie n’autorise que le port 80.
Dans AWS View, cliquez sur Request application · client A, puis sur Request application · client B. Les deux renvoient Success et Application online sur le port 80. Le client A utilise 198.51.100.10 ; le client B utilise 198.51.100.20. Cliquez sur Request port 8081 ; cette requête du client A échoue parce que ce port n’est pas autorisé.
Créez un groupe distinct dans le même VPC. --group-name définit son nom, --description explique son rôle et la spécification d’étiquettes entre guillemets ajoute les étiquettes de propriété dans un seul argument. Enregistrez le nouvel ID :
GROUP_ID=$(aws ec2 create-security-group \
--group-name parcel-web \
--description "Parcel HTTP access" \
--vpc-id "$VPC_ID" \
--tag-specifications 'ResourceType=security-group,Tags=[{Key=Name,Value=parcel-web},{Key=Project,Value=parcel}]' \
--query 'GroupId' \
--output text)
Un groupe neuf n’accorde aucun accès entrant et autorise tout le trafic sortant. Les groupes de sécurité contiennent des règles d’autorisation, pas de refus explicites. Le trafic sans règle d’autorisation correspondante est bloqué.
--groups remplace la liste des groupes de l’interface. Associez seulement votre nouveau groupe ; conserver le groupe large à ses côtés cumulerait leurs autorisations et permettrait encore l’accès aux deux clients :
aws ec2 modify-network-interface-attribute \
--network-interface-id "$ENI_ID" \
--groups "$GROUP_ID"
Une modification réussie ne produit aucune sortie. Confirmez que l’interface n’a maintenant que votre groupe :
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,Groups:Groups}' \
--output json
AWS View affiche maintenant parcel-web et Inbound · none. Envoyez de nouvelles requêtes des clients A et B ; les deux deviennent Connection failed. L’adresse publique et la route restent présentes, mais le groupe vide n’autorise aucune requête entrante. Gardez ce Terminal ouvert pour conserver les ID enregistrés.
Autoriser uniquement le client HTTP prévu
Dans cette étape, vous accorderez au client A l’accès au port 80 et vérifierez que l’autre source et l’autre port restent bloqués.
Une règle entrante indique un protocole, une plage de ports et une source. --protocol tcp sélectionne TCP, --port 80 sélectionne ce seul port et --cidr 198.51.100.10/32 sélectionne uniquement l’adresse IPv4 du client A. Un /32 contient une adresse IPv4 ; sa portée est plus restreinte que 0.0.0.0/0.
Ajoutez la règle à votre groupe, pas au groupe fourni :
aws ec2 authorize-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 80 \
--cidr 198.51.100.10/32
La réponse indique la réussite et peut contenir l’ID de la nouvelle règle. Lisez toutes les règles entrantes :
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Il existe une règle TCP dont FromPort et ToPort valent tous deux 80, avec la source 198.51.100.10/32. AWS View affiche la même source et le même port entrants.
Cliquez sur Request application · client A. Le résultat est Success, avec la source 198.51.100.10, le port de destination 80 et le corps Application online. Il s’agit d’une réponse réelle de l’application fournie.
Cliquez ensuite sur Request application · client B et Request port 8081. Les deux renvoient Connection failed. La première requête a une source incorrecte ; la seconde utilise le client A, mais le mauvais port. Une adresse publique et une route fournissent un chemin, tandis que le groupe de sécurité décide quel trafic peut l’emprunter.
Tester et retirer une autorisation temporaire de port
Dans cette étape, vous démontrerez qu’un second port d’écoute n’est accessible que lorsque sa propre règle existe, puis retirerez cette autorisation temporaire.
L’application fournie sert également HTTP sur le port 8081. Conservez la même source autorisée et ajoutez une règle temporaire pour ce port :
aws ec2 authorize-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 8081 \
--cidr 198.51.100.10/32
Relisez les règles :
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Il existe maintenant deux règles TCP : les ports 80 et 8081, chacun limité au client A. AWS View affiche les deux. Cliquez sur Request port 8081. Le résultat devient Success, avec le port de destination 8081 et le corps Application online. Cela confirme que le second service fonctionne ; l’échec précédent était une restriction de la règle d’accès.
Exemple AWS View : les deux règles entrantes restreintes sont présentes et le client A reçoit la réponse de l’application sur le port 8081. Les ID générés diffèrent dans votre environnement.
L’exercice ne nécessite que le port 80. Révoquer une règle retire son autorisation. Indiquez le même protocole, le même port et la même source pour retirer uniquement la règle temporaire :
aws ec2 revoke-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 8081 \
--cidr 198.51.100.10/32
La réponse indique la réussite. Consultez les règles obtenues :
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Seule la règle du port 80 du client A reste présente. Lorsque AWS View retire la règle 8081, cliquez à nouveau sur Request port 8081 ; la requête échoue désormais. Le client A réussit toujours sur le port 80, et le client B échoue toujours sur le port 80. Vous avez changé une seule autorisation de port sans remplacer l’application ni sa route.
Observer les réponses HTTP avec état
Dans cette étape, vous retirerez la règle sortante par défaut de votre groupe et confirmerez que les réponses au HTTP entrant autorisé fonctionnent toujours.
Les groupes de sécurité conservent l’état des connexions : une réponse à une requête entrante autorisée peut quitter l’application même si aucune règle sortante n’autorise une nouvelle connexion. Une règle sortante régit le trafic initié par l’application ; elle n’est pas nécessaire pour autoriser cette réponse HTTP.
Lisez vos autorisations sortantes actuelles :
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissionsEgress' \
--output json
Le nouveau groupe a la destination par défaut pour tout le trafic 0.0.0.0/0. Dans la commande suivante, --ip-permissions reçoit une liste JSON de spécifications de règles comme un seul argument entre guillemets. La valeur -1 de IpProtocol signifie tous les protocoles, et IpRanges identifie les destinations d’une règle sortante. Retirez exactement cette règle par défaut :
aws ec2 revoke-security-group-egress \
--group-id "$GROUP_ID" \
--ip-permissions '[{"IpProtocol":"-1","IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'
La réponse indique la réussite. Lisez les deux sens :
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
L’entrée autorise toujours uniquement le client A sur le port 80 ; la sortie est vide. AWS View affiche Outbound · none. Cliquez à nouveau sur Request application · client A. Success et Application online reviennent toujours : la réponse appartient à la connexion entrante autorisée.
Revérifiez Request application · client B et Request port 8081. Les deux échouent toujours. Les réponses avec état n’accordent pas de nouvel accès entrant à une autre source ou à un autre port. Ce test établit le comportement des réponses ; il ne teste pas une nouvelle connexion sortante initiée par l’application.
Exemple AWS View : l’entrée n’autorise que le client A sur le port 80, la sortie est vide et la réponse HTTP réelle réussit toujours. Les ID générés diffèrent dans votre environnement.
Restaurer le groupe fourni et supprimer le vôtre
Dans cette étape, vous restaurerez l’association d’origine de l’application et supprimerez uniquement votre groupe de sécurité d’exercice.
Un groupe associé à une interface réseau ne peut pas être supprimé. Remplacez d’abord votre groupe par le groupe fourni enregistré ; ne supprimez ni ne modifiez le groupe fourni :
aws ec2 modify-network-interface-attribute \
--network-interface-id "$ENI_ID" \
--groups "$SUPPLIED_GROUP_ID"
Confirmez l’association :
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,Groups:Groups}' \
--output json
Seul le groupe d’origine supplied-application est associé. Supprimez maintenant votre groupe inutilisé :
aws ec2 delete-security-group --group-id "$GROUP_ID"
Une suppression réussie ne produit aucune sortie. Consultez l’inventaire complet des groupes pour établir l’absence indépendamment d’étiquettes qui peuvent être retirées :
aws ec2 describe-security-groups \
--query 'SecurityGroups[].{ID:GroupId,Name:GroupName,VPC:VpcId}' \
--output table
parcel-web est absent. Les groupes fourni et par défaut restent présents, tout comme les VPC, sous-réseaux, interface d’application, adresse publique et routes. Un échec de consultation de l’inventaire ne prouve pas la suppression.
AWS View affiche à nouveau supplied-application. Cliquez sur les boutons de requête des clients A et B ; les deux requêtes au port 80 renvoient Success, comme au départ. Request port 8081 échoue parce que le groupe fourni inchangé n’autorise que le port 80.
Exécutez la vérification de cette étape.
Résumé
Vous avez créé et associé un groupe de sécurité distinct, autorisé uniquement le client A sur le port TCP 80, testé puis révoqué une autorisation temporaire pour un second port, et confirmé les réponses HTTP avec état sans autorisation sortante. Des requêtes réelles ont distingué le trafic permis du trafic bloqué. Enfin, vous avez restauré le groupe fourni et supprimé seulement votre groupe d’exercice.
Continuez avec « Donner un accès sortant à un sous-réseau privé » pour construire le chemin sortant d’une application privée sans autoriser d’accès externe non sollicité.
