Generador de Reglas de Grupo de Seguridad AWS

Genera reglas de Grupo de Seguridad AWS desde CSV

Security Group Rules

Generated Output

Enter rules to generate AWS Security Group config

El Generador de reglas de AWS Security Group crea reglas de security group para EC2 a partir de entrada CSV estructurada. Ingresa reglas como filas con columnas de dirección, protocolo, rango de puertos, origen/destino y descripción, y obtén comandos de AWS CLI, recursos Terraform aws_security_group_rule o fragmentos de plantillas CloudFormation listos para despliegues automatizados y repetibles.

Entendiendo los AWS Security Groups

Si ejecutas cargas de trabajo en AWS, los security groups son el mecanismo principal para controlar el acceso de red a tus instancias EC2, bases de datos RDS, funciones Lambda y la mayoría de los otros recursos conectados en red. A diferencia de los firewalls tradicionales que se ubican frente a tu red, los security groups se adjuntan directamente a las interfaces de red y siguen a tus instancias a donde vayan -- si detienes y reinicias una instancia o la adjuntas a una subnet diferente, sus security groups viajan con ella.

Lo más importante que debes entender sobre los AWS security groups es que son stateful y solo de permiso. Stateful significa que si permites tráfico entrante en el puerto 443, el tráfico de retorno para esa conexión se permite automáticamente independientemente de las reglas de salida. Solo de permiso significa que no hay acción "deny" -- no puedes escribir una regla que bloquee explícitamente una IP específica. Si una dirección IP no coincide con ninguna regla de permiso, se deniega implícitamente. Esto es fundamentalmente diferente de iptables o Azure NSGs donde puedes escribir reglas de denegación explícitas, y significa que los security groups son más adecuados para definir lo que quieres permitir en lugar de lo que quieres bloquear. Para denegaciones explícitas, necesitas Network ACLs a nivel de subnet.

Administrar security groups a través de la consola de AWS funciona para un puñado de reglas, pero se desmorona rápidamente en entornos de producción. Una aplicación web típica de tres niveles podría tener security groups separados para el load balancer, servidores web, servidores de aplicación y base de datos -- cada uno con cinco a diez reglas. Los cambios hechos a través de la consola no se rastrean, no pueden revisarse antes del despliegue y son difíciles de replicar en múltiples entornos. Este generador habilita un flujo de trabajo de Infraestructura como Código: define tus reglas en una hoja de cálculo, genera comandos CLI o código Terraform, revisa en un pull request y despliega de forma consistente en desarrollo, staging y producción.

Cómo generar reglas de AWS Security Group

  1. Prepara tus datos de reglas en formato CSV con columnas: dirección, protocolo, rango de puertos, origen/destino y descripción.
  2. Pega o sube el CSV al generador.
  3. Selecciona el formato de salida: AWS CLI, Terraform HCL o CloudFormation JSON/YAML.
  4. Ingresa el ID del security group objetivo (por ejemplo, sg-0123456789abcdef0).
  5. Copia los comandos o bloques de configuración generados para el despliegue.

Formato de entrada CSV y salida generada

Entrada CSV

direction,protocol,from_port,to_port,source,description
ingress,tcp,443,443,0.0.0.0/0,HTTPS from internet
ingress,tcp,22,22,10.0.0.0/8,SSH from internal
ingress,tcp,3306,3306,sg-0abcdef1234567890,MySQL from app tier
egress,tcp,443,443,0.0.0.0/0,HTTPS outbound
ingress,-1,-1,-1,sg-0abcdef1234567890,All traffic from app tier

Salida AWS CLI

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":443,"ToPort":443,"IpRanges":[{"CidrIp":"0.0.0.0/0","Description":"HTTPS from internet"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":22,"ToPort":22,"IpRanges":[{"CidrIp":"10.0.0.0/8","Description":"SSH from internal"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":3306,"ToPort":3306,"UserIdGroupPairs":[{"GroupId":"sg-0abcdef1234567890","Description":"MySQL from app tier"}]}]'

Salida Terraform

resource "aws_security_group_rule" "https_from_internet" {
  type              = "ingress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = "sg-0123456789abcdef0"
  description       = "HTTPS from internet"
}

resource "aws_security_group_rule" "ssh_from_internal" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["10.0.0.0/8"]
  security_group_id = "sg-0123456789abcdef0"
  description       = "SSH from internal"
}

Tipos de origen en AWS Security Groups

Tipo de origenValor CSVDescripción
Bloque CIDR (IPv4)10.0.0.0/8Notación CIDR estándar de IPv4
Bloque CIDR (IPv6)::/0Notación CIDR de IPv6
Security groupsg-0abcdef1234567890Referencia cruzada de grupo dentro de la misma VPC
Lista de prefijospl-0123456789abcdef0Rangos de IP administrados por AWS (por ejemplo, S3, DynamoDB)
Todo el tráficoProtocolo -1Usa -1 para protocolo, -1 para rango de puertos

Cuándo usar el generador de AWS Security Group

  • Construcción de VPC -- Genera todas las reglas de security group para un nuevo despliegue de VPC desde un solo documento CSV de planificación.
  • Automatización de cumplimiento -- Convierte hojas de cálculo de políticas de seguridad en comandos de AWS CLI o código Terraform ejecutables.
  • Consistencia multi-cuenta -- Genera conjuntos de reglas de security group idénticos para despliegue en cuentas de desarrollo, staging y producción.
  • Migración desde on-premises -- Traduce reglas existentes de iptables o firewall a formato de AWS security group durante la migración a la nube.
  • Auditoría y documentación -- Exporta reglas existentes como CSV, revísalas y regenera configuraciones limpias.

Cómo funcionan los AWS Security Groups

Comportamiento stateful

Los AWS security groups son stateful -- si permites tráfico entrante en el puerto 443, el tráfico de retorno se permite automáticamente independientemente de las reglas de salida. Esto es diferente de iptables o nftables donde debes permitir explícitamente el tráfico de retorno o usar seguimiento de conexiones.

Límites de reglas

Cada security group soporta hasta 60 reglas de entrada y 60 reglas de salida por defecto (ajustable mediante solicitud de aumento de cuota). Cada bloque CIDR, referencia de security group o lista de prefijos cuenta como una regla. Usa el Allowlist Builder para minimizar el número de entradas CIDR.

Evaluación

Todas las reglas en un security group se evalúan juntas -- no hay ordenamiento. Si alguna regla permite el tráfico, se permite. No hay acción "deny" en los security groups; la ausencia de una regla de permiso coincidente es una denegación implícita. Para reglas de denegación explícita, usa Network ACLs en su lugar.

Referencias a Security Groups

Una de las características más poderosas de los AWS security groups es la capacidad de referenciar otros security groups como orígenes o destinos. En lugar de especificar bloques CIDR para tus servidores de aplicación, referencias el ID del security group del nivel de aplicación. Esto significa que cuando agregas o eliminas instancias del nivel de aplicación, el security group de la base de datos automáticamente permite o revoca el acceso sin ningún cambio de regla.

Consejos prácticos para AWS Security Groups

El error más común en la gestión de security groups es usar 0.0.0.0/0 (todo el tráfico) demasiado liberalmente. Con prisa por hacer que las cosas funcionen, los ingenieros abren SSH (puerto 22) a 0.0.0.0/0 "temporalmente" y olvidan restringirlo después. AWS Security Hub y Config Rules pueden detectar esto, pero la prevención es mejor que la detección. Usa referencias de security group para la comunicación entre niveles, restringe SSH al security group de tu VPN o bastión, y limita 0.0.0.0/0 a puertos que genuinamente necesitan acceso público (típicamente solo 80 y 443 en load balancers).

Al trabajar con Terraform, prefiere usar recursos aws_security_group_rule (que es lo que produce este generador) sobre bloques inline ingress y egress dentro de un recurso aws_security_group. Las reglas inline y los recursos de regla separados entran en conflicto entre sí, y los recursos separados son más fáciles de administrar, revisar y aplicar condicionalmente. También previenen el problema de "todas las reglas cambian cuando una cambia" que causan los bloques inline.

Las descripciones de las reglas no son opcionales -- son la documentación para tu yo futuro. AWS muestra las descripciones en la consola, y aparecen en auditorías de seguridad e informes de cumplimiento. Cada regla debe responder "por qué" existe este acceso: "SSH from VPN gateway" es mejor que "SSH" o ninguna descripción. El generador preserva tus descripciones del CSV en la salida, así que tómate el tiempo de escribir unas significativas.

Preguntas frecuentes

¿Qué significa protocolo -1 en los AWS security groups? Protocolo -1 significa "todo el tráfico" -- coincide con TCP, UDP, ICMP y todos los demás protocolos IP. Al usar protocolo -1, establece tanto from_port como to_port en -1 también. Así es como AWS representa una regla de "permitir todo".

¿Puedo referenciar un security group en una VPC diferente? Sí, para VPCs emparejadas. Usa el ID completo del security group y asegúrate de que el peering de VPC esté configurado. El generador produce la referencia GroupId; para referencias entre cuentas, también necesitas el ID del propietario de la cuenta.

¿Cómo manejo bloques CIDR tanto IPv4 como IPv6? El generador produce entradas separadas IpRanges (para IPv4) e Ipv6Ranges (para IPv6) automáticamente basándose en el formato de la dirección. Una regla para 0.0.0.0/0 solo cubre IPv4; agrega una regla separada para ::/0 para cubrir IPv6.

¿Cuál es la diferencia entre security groups y Network ACLs? Los security groups son stateful, a nivel de instancia y solo de permiso. Las Network ACLs son stateless, a nivel de subnet y soportan reglas de denegación explícita. La mayoría de las configuraciones usan security groups como control principal y Network ACLs para defensa en profundidad adicional.

¿Cómo me mantengo dentro del límite de 60 reglas? Agrega bloques CIDR usando el Allowlist Builder, usa referencias de security group en lugar de IPs individuales para la comunicación entre niveles, y combina rangos de puertos donde sea posible (por ejemplo, from_port: 8000, to_port: 8080 en lugar de 80 reglas individuales). También puedes solicitar un aumento de cuota a través de la consola de AWS Service Quotas.

¿Puedo generar reglas para múltiples security groups a la vez? El generador apunta a un solo security group por ejecución. Para configuraciones multi-grupo, ejecútalo una vez por security group con las reglas apropiadas para cada nivel. Esto coincide con las mejores prácticas de separación de responsabilidades en el diseño de security groups.

Herramientas relacionadas

IPparse•Herramientas gratuitas de cálculo de redes y subredes

© 2026 IPparse. All tools run locally in your browser.

100% Privacy-First • No Data Collected