Security Groups de EC2 con mínimo privilegio

Abrir 0.0.0.0/0 en puertos administrativos aumenta el riesgo de fuerza bruta y exposición accidental. En servicios web sobre EC2, una regla demasiado amplia puede convertir una configuración funcional en una superficie de ataque innecesaria.

Este artículo propone una guía práctica para diseñar security groups con mínimo privilegio: cambios verificables, comandos claros, advertencias antes de acciones sensibles y una validación final para detectar errores antes de mover tráfico o datos reales.

Qué vas a construir

Vas a preparar una configuración base de security groups para servicios web en AWS EC2, adaptable a un Cloud Server de DonWeb Cloud, a una instancia Linux propia o a un entorno de laboratorio.

El resultado esperado es una configuración documentada, con comandos de prueba y recomendaciones para pasar de laboratorio a producción con mayor control.

Cuándo conviene usar este enfoque

Cuando necesitas una solución operativa y repetible, no solo una explicación conceptual.
Cuando el servicio va a vivir en un servidor cloud y requiere seguridad básica desde el primer despliegue.
Cuando necesitas dejar evidencia de configuración, pruebas y criterios de mantenimiento.
Cuando quieres reducir configuraciones manuales difíciles de auditar.

Requisitos previos

Antes de empezar, asegúrate de contar con:

Cloud Server o servidor Ubuntu/Debian actualizado.
Usuario con permisos sudo o rol equivalente.
Acceso SSH o consola segura.
Backup previo si el servidor ya tiene datos o tráfico real.
Dominio o subdominio si vas a publicar un servicio web.
Credenciales con mínimo privilegio si vas a usar comandos AWS.
Ventana de mantenimiento para cambios de red, firewall, runtime, base de datos o credenciales.

Flujo de trabajo recomendado

El flujo recomendado es:

Preparar el entorno.
Revisar los security groups existentes.
Aplicar reglas mínimas para tráfico web.
Restringir accesos administrativos.
Validar reglas, instancias asociadas y mantenimiento.

Evita cambiar varias capas a la vez. Si algo falla, una modificación incremental es más fácil de revisar y revertir.

Comandos principales

Revisar un security group existente:

aws ec2 describe-security-groups --group-ids sg-xxxx

Autorizar entrada pública por HTTPS:

aws ec2 authorize-security-group-ingress --group-id sg-xxxx --protocol tcp --port 443 --cidr 0.0.0.0/0

Revocar acceso SSH abierto a internet:

aws ec2 revoke-security-group-ingress --group-id sg-xxxx --protocol tcp --port 22 --cidr 0.0.0.0/0

Ver instancias asociadas a un security group:

aws ec2 describe-instances --filters Name=instance.group-id,Values=sg-xxxx

Revisar reglas del security group:

aws ec2 describe-security-group-rules --filters Name=group-id,Values=sg-xxxx

Configuración base

Una configuración conservadora para un servicio web debería partir de esta idea:

Entrada pública: 80/443
SSH: solo IP administrativa o Session Manager
Salida: limitar cuando haya dependencias conocidas

Paso 1: preparar el entorno

Antes de ejecutar este paso, revisa que estás trabajando sobre el servidor, la cuenta o el entorno correcto. Si el servicio ya recibe tráfico, usa una ventana de mantenimiento.

Primero, inspecciona el security group actual:

aws ec2 describe-security-groups --group-ids sg-xxxx

Verifica la salida antes de continuar. Si detectas reglas amplias o permisos que no reconoces, documenta el estado actual antes de modificarlo.

Paso 2: habilitar solo el tráfico web necesario

Para un servicio web público, la entrada desde internet debería concentrarse en los puertos necesarios para HTTP y HTTPS.

Autoriza HTTPS público:

aws ec2 authorize-security-group-ingress --group-id sg-xxxx --protocol tcp --port 443 --cidr 0.0.0.0/0

Si también necesitas HTTP, aplica el mismo criterio para el puerto 80.

Antes de continuar, valida que la regla agregada corresponde al security group correcto y que no abriste puertos administrativos por error.

Paso 3: restringir accesos administrativos

El acceso SSH no debería quedar abierto a 0.0.0.0/0. Una configuración más segura es limitarlo a una IP administrativa o usar Session Manager.

La base recomendada es:

Entrada pública: 80/443
SSH: solo IP administrativa o Session Manager
Salida: limitar cuando haya dependencias conocidas

Si el security group tiene SSH abierto a internet, revoca esa regla:

aws ec2 revoke-security-group-ingress --group-id sg-xxxx --protocol tcp --port 22 --cidr 0.0.0.0/0

Antes de aplicar cambios de acceso, confirma que conservarás una vía segura para administrar la instancia.

Paso 4: comprobar instancias asociadas

Después de ajustar reglas, revisa qué instancias están usando el security group:

aws ec2 describe-instances --filters Name=instance.group-id,Values=sg-xxxx

Esta validación ayuda a evitar cambios no deseados sobre servidores que comparten el mismo grupo de seguridad.

Paso 5: revisar reglas y dejar mantenimiento documentado

Por último, inspecciona las reglas activas:

aws ec2 describe-security-group-rules --filters Name=group-id,Values=sg-xxxx

Deja documentado:

Qué puertos están abiertos.
Desde qué orígenes se permite el acceso.
Qué instancia o servicio depende del security group.
Quién puede aprobar cambios futuros.
Qué evidencia debe quedar después de modificar reglas.

Problemas frecuentes

Permisos insuficientes: revisa el usuario, el grupo, el rol IAM o el contexto de Kubernetes antes de repetir comandos con más privilegios.

Puerto ocupado o cerrado: valida con ss -tulpn, reglas de firewall y security groups antes de asumir que falló la aplicación.

Variables de entorno ausentes: confirma .env, secretos del orquestador y que no se impriman credenciales en logs.

El servicio inicia pero no responde: revisa healthchecks, logs, dependencia de base de datos y resolución DNS.

Rollback no definido: conserva la versión anterior, snapshot, backup o manifiesto previo antes de aplicar cambios sensibles.

Buenas prácticas para producción

Usa mínimo privilegio para usuarios, roles, contenedores y reglas de red.
Versiona configuraciones sin incluir secretos.
Prueba restauraciones de backup, no solo la creación del archivo.
Activa logs y alertas antes de necesitar diagnosticar un incidente.
Documenta quién puede ejecutar cambios y qué evidencia debe quedar.
Revisa periódicamente dependencias, imágenes y paquetes del sistema.

Advertencias de seguridad

No ejecutes estos pasos contra infraestructura de terceros ni contra producción sin autorización.

Los comandos de seguridad se orientan a defensa, mitigación y auditoría autorizada. Si detectas credenciales expuestas, rota primero y luego investiga el alcance.

Estado técnico

Probado en entorno aislado: no.
Validado contra documentación oficial: sí.
Pendiente de validación: ejecutar el procedimiento completo en un servidor de laboratorio antes de publicarlo como probado.

Observaciones

Antes de publicarlo como procedimiento probado, conviene ejecutar el flujo completo en una cuenta AWS o servidor de laboratorio.
La infografía de apoyo fue generada como una sola imagen con los cinco pasos del procedimiento.