Introducción
La ruta pública de una aplicación de entregas ya funciona, pero la regla proporcionada permite HTTP desde cualquier origen IPv4. Asignarás a la aplicación un grupo de seguridad independiente que permita únicamente el cliente y el puerto previstos. Las solicitudes reales mostrarán cómo las restricciones de origen, de puerto y las respuestas con estado afectan al acceso.
Completa primero «Conectar una subred pública a Internet». Este entorno nuevo proporciona su propia red, dirección pública, rutas y aplicación; no reutiliza tu VM anterior. La CLI ya está configurada. Conserva los recursos proporcionados y la red de referencia ajena al ejercicio. Solo el nuevo grupo de seguridad es un recurso de práctica que debes eliminar.
Relación con certificaciones
Este laboratorio ofrece práctica para los siguientes temas de examen.
- Cloud Practitioner (CLF-C02) · Tarea 3.5: controles de acceso mediante grupos de seguridad en una VPC.
- Solutions Architect – Associate (SAA-C03) · Tarea 1.2: controles básicos de seguridad de aplicaciones por origen, puerto y protocolo de red.
- CloudOps Engineer – Associate (SOA-C03) · Tareas 5.1 y 5.3: configuración básica de grupos de seguridad y comprobación de su efecto en la conectividad.
- Security – Specialty (SCS-C03) · Tarea 3.3: práctica básica para permitir e impedir el tráfico requerido mediante grupos de seguridad.
Asociar un grupo de seguridad de práctica vacío
En este paso, inspeccionarás la aplicación que funciona y sustituirás su grupo de acceso amplio por tu propio grupo vacío.
Ejecuta comandos en Terminal y haz clic en AWS View a su lado. La vista consulta el mismo estado de recursos que la CLI. Muestra application-network, sus subredes pública y privada y una aplicación con dirección privada 10.20.1.10. Su dirección pública y la ruta a la puerta de enlace de Internet ya están proporcionadas; no las cambies.
cd /home/labex/project
Selecciona la VPC por su etiqueta Name. --filters limita los resultados del servidor, --query selecciona el ID y $(...) guarda el resultado en una variable del shell:
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Selecciona la interfaz de la aplicación proporcionada dentro de esa 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 grupo de seguridad controla el tráfico permitido en la interfaz de red del recurso asociado. Las reglas de entrada permiten tráfico que llega a la aplicación; las de salida permiten tráfico que esta inicia. Guarda el ID del único grupo proporcionado para restaurarlo durante la limpieza. [0] selecciona el primer elemento de esta lista de un solo grupo:
SUPPLIED_GROUP_ID=$(aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[0].Groups[0].GroupId' \
--output text)
Lee sus reglas sin modificarlas:
aws ec2 describe-security-groups \
--group-ids "$SUPPLIED_GROUP_ID" \
--query 'SecurityGroups[].{ID:GroupId,Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
El grupo proporcionado permite TCP de entrada al puerto 80 desde 0.0.0.0/0, es decir, cualquier origen IPv4, y permite todo el tráfico de salida. HTTP utiliza solicitudes y respuestas; un puerto identifica el servicio receptor. Esta aplicación sirve HTTP en los puertos TCP 80 y 8081, pero la regla proporcionada solo permite el puerto 80.
En AWS View, haz clic en Request application · client A y después en Request application · client B. Ambos devuelven Success y Application online en el puerto 80. El cliente A usa 198.51.100.10; el B usa 198.51.100.20. Haz clic en Request port 8081; esta solicitud del cliente A falla porque ese puerto no está permitido.
Crea un grupo independiente en la misma VPC. --group-name define el nombre, --description explica su propósito y la especificación de etiquetas entre comillas añade etiquetas de propiedad como un solo argumento. Guarda el nuevo 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 grupo nuevo no tiene permisos de entrada y permite todo el tráfico de salida. Los grupos de seguridad contienen reglas de permiso, no reglas de denegación explícita. El tráfico sin una regla de permiso coincidente se bloquea.
--groups sustituye la lista de grupos de la interfaz. Asocia únicamente tu grupo nuevo; conservar también el grupo amplio combinaría sus permisos y seguiría permitiendo ambos clientes:
aws ec2 modify-network-interface-attribute \
--network-interface-id "$ENI_ID" \
--groups "$GROUP_ID"
Un cambio correcto no produce salida. Confirma que la interfaz ahora tiene solo tu grupo:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,Groups:Groups}' \
--output json
AWS View muestra parcel-web e Inbound · none. Envía nuevas solicitudes de los clientes A y B; ambas pasan a Connection failed. La dirección pública y la ruta siguen presentes, pero el grupo vacío no permite solicitudes de entrada. Mantén abierto este Terminal para conservar los ID guardados.
Permitir únicamente el cliente HTTP previsto
En este paso, darás al cliente A acceso al puerto 80 y comprobarás que el otro origen y el otro puerto siguen bloqueados.
Una regla de entrada especifica un protocolo, un intervalo de puertos y un origen. --protocol tcp selecciona TCP, --port 80 selecciona este único puerto y --cidr 198.51.100.10/32 selecciona solo la dirección IPv4 del cliente A. Un /32 contiene una dirección IPv4 y es más limitado que 0.0.0.0/0.
Añade la regla a tu grupo, no al grupo proporcionado:
aws ec2 authorize-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 80 \
--cidr 198.51.100.10/32
La respuesta indica éxito y puede incluir el ID de la nueva regla. Lee todas las reglas de entrada:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Hay una regla TCP cuyos FromPort y ToPort son 80 y cuyo origen es 198.51.100.10/32. AWS View muestra el mismo origen y puerto de entrada.
Haz clic en Request application · client A. El resultado es Success, origen 198.51.100.10, puerto de destino 80 y cuerpo Application online. Es una respuesta real de la aplicación proporcionada.
Ahora haz clic en Request application · client B y Request port 8081. Ambos devuelven Connection failed. La primera solicitud tiene un origen incorrecto; la segunda usa el cliente A, pero un puerto incorrecto. Una dirección pública y una ruta proporcionan el camino, mientras que el grupo de seguridad decide qué tráfico puede utilizarlo.
Probar y retirar un permiso temporal de puerto
En este paso, demostrarás que un segundo puerto en escucha solo es accesible cuando existe su propia regla y después retirarás el permiso temporal.
La aplicación proporcionada también sirve HTTP en el puerto 8081. Mantén el mismo origen permitido y añade una regla temporal para ese puerto:
aws ec2 authorize-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 8081 \
--cidr 198.51.100.10/32
Vuelve a leer las reglas:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Ahora hay dos reglas TCP: puertos 80 y 8081, ambos restringidos al cliente A. AWS View muestra las dos. Haz clic en Request port 8081. El resultado cambia a Success, con puerto de destino 8081 y cuerpo Application online. Esto confirma que el segundo servicio está funcionando; el fallo anterior era una restricción de la regla de acceso.
Ejemplo de AWS View: aparecen las dos reglas de entrada limitadas y el cliente A recibe la respuesta de la aplicación en el puerto 8081. Los ID generados serán distintos en tu entorno.
El ejercicio solo requiere el puerto 80. Revocar una regla retira su permiso. Especifica el mismo protocolo, puerto y origen para retirar solo la regla temporal:
aws ec2 revoke-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 8081 \
--cidr 198.51.100.10/32
La respuesta indica éxito. Consulta las reglas resultantes:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Solo queda la regla del puerto 80 del cliente A. Cuando AWS View retire la regla de 8081, vuelve a hacer clic en Request port 8081; ahora falla. El puerto 80 del cliente A sigue funcionando y el del cliente B sigue fallando. Has cambiado un permiso de puerto en vez de sustituir la aplicación o su ruta.
Observar respuestas HTTP con estado
En este paso, retirarás la regla de salida predeterminada de tu grupo y confirmarás que las respuestas al HTTP de entrada permitido siguen funcionando.
Los grupos de seguridad mantienen estado: la respuesta a una solicitud de entrada permitida puede salir de la aplicación aunque ninguna regla de salida permita una conexión nueva. Una regla de salida controla el tráfico que la aplicación inicia; no es necesaria para permitir esta respuesta HTTP.
Lee los permisos de salida actuales:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissionsEgress' \
--output json
El grupo nuevo tiene el destino predeterminado para todo el tráfico 0.0.0.0/0. En el siguiente comando, --ip-permissions recibe una lista JSON de especificaciones de reglas como un solo argumento entre comillas. El valor -1 de IpProtocol significa todos los protocolos e IpRanges identifica los destinos de una regla de salida. Retira exactamente esa regla predeterminada:
aws ec2 revoke-security-group-egress \
--group-id "$GROUP_ID" \
--ip-permissions '[{"IpProtocol":"-1","IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'
La respuesta indica éxito. Lee ambas direcciones:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
La entrada sigue permitiendo únicamente el cliente A en el puerto 80; la salida está vacía. AWS View muestra Outbound · none. Haz clic otra vez en Request application · client A. Siguen devolviéndose Success y Application online: la respuesta pertenece a la conexión de entrada permitida.
Vuelve a comprobar Request application · client B y Request port 8081. Ambos siguen fallando. Las respuestas con estado no conceden un acceso de entrada nuevo a otro origen o puerto. Esta prueba demuestra el comportamiento de respuesta; no prueba una conexión de salida nueva iniciada por la aplicación.
Ejemplo de AWS View: la entrada solo permite el cliente A en el puerto 80, la salida está vacía y la respuesta HTTP real sigue teniendo éxito. Los ID generados serán distintos en tu entorno.
Restaurar el grupo proporcionado y eliminar el tuyo
En este paso, restaurarás la asociación original de la aplicación y eliminarás únicamente tu grupo de seguridad de práctica.
No se puede eliminar un grupo asociado a una interfaz de red. Primero sustituye tu grupo por el grupo proporcionado que guardaste; no elimines ni modifiques el grupo proporcionado:
aws ec2 modify-network-interface-attribute \
--network-interface-id "$ENI_ID" \
--groups "$SUPPLIED_GROUP_ID"
Confirma la asociación:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,Groups:Groups}' \
--output json
Solo está asociado el grupo original supplied-application. Ahora elimina tu grupo, que ya no se utiliza:
aws ec2 delete-security-group --group-id "$GROUP_ID"
Una eliminación correcta no produce salida. Consulta el inventario completo de grupos para demostrar la ausencia independientemente de etiquetas que se pueden retirar:
aws ec2 describe-security-groups \
--query 'SecurityGroups[].{ID:GroupId,Name:GroupName,VPC:VpcId}' \
--output table
parcel-web ya no aparece. Los grupos proporcionado y predeterminados siguen presentes, al igual que las VPC, subredes, interfaz de aplicación, dirección pública y rutas. Un fallo al consultar el inventario no demuestra la eliminación.
AWS View vuelve a mostrar supplied-application. Haz clic en los botones de solicitud de los clientes A y B; ambos devuelven Success en el puerto 80, igual que la referencia inicial. Request port 8081 falla porque el grupo proporcionado, que no has cambiado, solo permite el puerto 80.
Ejecuta la comprobación de este paso.
Resumen
Has creado y asociado un grupo de seguridad independiente, permitido solo el cliente A en el puerto TCP 80, probado y revocado un permiso temporal de un segundo puerto y confirmado respuestas HTTP con estado sin permisos de salida. Las solicitudes reales distinguieron tráfico permitido y bloqueado. Finalmente, restauraste el grupo proporcionado y eliminaste solo tu grupo de práctica.
Continúa con «Dar acceso de salida a una subred privada» para construir la ruta de salida de una aplicación privada sin permitir acceso externo no solicitado.
