Grupos de seguridad y pares de claves

Un security group es un firewall virtual con estado que controla el tráfico entrante y saliente hacia y desde una instancia de EC2 (u otros recursos de AWS, como RDS, Lambda y ELB). Los security groups funcionan en el nivel de instancia: cada regla especifica un protocolo (TCP/UDP/ICMP), un rango de puertos y un origen o destino (un rango de IP o otro security group). A diferencia de los firewalls tradicionales, los security groups tienen estado: si permite el tráfico entrante, el tráfico de respuesta saliente se permite automáticamente sin necesidad de una regla explícita.

Los security groups tienen conjuntos de reglas entrantes y salientes separados. Las reglas entrantes controlan el tráfico que llega a la instancia; de forma predeterminada, se deniega todo el tráfico entrante. Las reglas salientes controlan el tráfico que sale de la instancia; de forma predeterminada, se permite todo el tráfico saliente. Usted agrega reglas explícitas de Allow; los security groups no tienen reglas explícitas de Deny (utilice Network ACLs para las denegaciones explícitas). Todas las reglas de un security group se evalúan conjuntamente mediante un OR lógico: cualquier regla Allow coincidente permite el tráfico.

Los security groups admiten referencias a security groups como origen o destino, lo que resulta más flexible y seguro que especificar rangos de IP. Por ejemplo, el security group de un ALB permite 0.0.0.0/0 en el puerto 443. El security group de las instancias EC2 permite el puerto entrante 8080 únicamente desde el ID del security group del ALB, no desde ninguna IP. Si se reemplaza o escala un ALB, la regla sigue aplicándose correctamente sin cambios de IP. Este patrón crea una defensa por capas y dinámica para arquitecturas multinivel.

Tener estado significa que el security group realiza un seguimiento del estado de la conexión. Si la regla entrante permite el puerto TCP 80 desde Internet y un cliente realiza una solicitud, los paquetes de respuesta (salientes) se permiten automáticamente de vuelta al cliente, incluso si no existe una regla saliente para el puerto 80. Esto es fundamentalmente diferente de las Network ACLs, que no tienen estado y requieren reglas explícitas para ambas direcciones del tráfico. El estado facilita la configuración de los security groups para los patrones habituales de tráfico de las aplicaciones.

Puede asociar varios security groups a una sola instancia EC2 (hasta 5 de forma predeterminada, aunque este límite se puede ajustar). Las reglas de todos los security groups asociados se combinan mediante una unión (lógica OR): si cualquier security group permite una solicitud, esta se permite. Esto significa que los security groups solo pueden agregar permisos, nunca restringirlos. Si desea limitar el acceso, debe eliminar o modificar reglas, no agregar un security group más restrictivo. Tenga presente este comportamiento aditivo en las preguntas de examen sobre restricción de acceso.

Cada VPC incluye un security group predeterminado. Sus reglas predeterminadas son las siguientes: permite todo el tráfico entrante procedente de otras instancias que también estén en el security group predeterminado y permite todo el tráfico saliente hacia cualquier destino. Esto es deliberadamente permisivo para que las nuevas instancias puedan comunicarse de forma predeterminada. En entornos de producción, cree un security group personalizado con un conjunto de reglas entrantes restringido y elimine las asociaciones de las instancias con el security group predeterminado para evitar exposiciones accidentales.

Los key pairs de EC2 utilizan criptografía asimétrica para la autenticación SSH. AWS genera el par de claves (o usted importa su propia clave pública): AWS almacena la clave pública y la inserta en la instancia durante el lanzamiento; usted descarga y almacena la clave privada (archivo .pem), que AWS nunca almacena. SSH utiliza la clave privada para demostrar su identidad al servidor sin transmitir una contraseña. La clave privada debe tener permisos restrictivos (chmod 400); de lo contrario, SSH se negará a utilizarla.

Si pierde la clave privada de una instancia Linux de EC2, no podrá conectarse mediante SSH de la forma habitual. Entre las opciones de recuperación se incluyen: Systems Manager Session Manager (si el agente de SSM está en ejecución y hay un rol de IAM asociado; no se necesita ninguna clave), EC2 Instance Connect (inserta una clave temporal mediante el navegador o la CLI; requiere un puerto SSH abierto y permisos de EIC) o detener la instancia, separar el volumen EBS raíz, asociarlo a otra instancia, modificar el archivo authorized_keys, volver a asociarlo y reiniciar. En Windows, utilice Systems Manager para recuperar la contraseña.

Dejar SSH (puerto 22) abierto a 0.0.0.0/0 expone su instancia a ataques de fuerza bruta y de relleno de credenciales desde cualquier lugar de Internet. Prácticas recomendadas: restrinja SSH a su rango de IP corporativo específico o utilice un host bastión (jump box) en una subred pública con un security group estrictamente controlado y, después, conéctese por SSH desde el bastión a las instancias privadas. Mejor aún, utilice Systems Manager Session Manager para eliminar por completo la exposición del puerto SSH; no necesitará ninguna regla entrante.

Límites predeterminados importantes para los security groups (ajustables mediante Service Quotas): hasta 2500 security groups por VPC, 60 reglas entrantes y 60 reglas salientes por security group y 5 security groups por interfaz de red. Al hacer referencia a otro security group como origen, cada combinación de security group referenciado y regla cuenta como una regla. Si alcanza los límites de reglas, consolide las reglas haciendo referencia a los ID de los security groups en lugar de rangos de IP individuales, o utilice prefix lists para agrupar varios CIDR en una sola entidad administrable.

Una managed prefix list es un conjunto de bloques CIDR al que puede hacer referencia en las reglas de los security groups o en las tablas de enrutamiento. AWS mantiene AWS-managed prefix lists para servicios como S3 y CloudFront, de modo que puede permitir tráfico hacia estos servicios y desde ellos sin mantener usted mismo los rangos de IP, que cambian con el tiempo. También puede crear customer-managed prefix lists para agrupar sus rangos de IP corporativos; actualice la prefix list en un solo lugar y todos los security groups que hagan referencia a ella heredarán el cambio automáticamente.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección aprendió que: los security groups son firewalls virtuales con estado que deniegan el tráfico de forma predeterminada; encadenar security groups mediante su ID es más seguro y flexible que utilizar rangos de IP; y los key pairs proporcionan autenticación SSH asimétrica, mientras que Systems Manager Session Manager elimina la necesidad de mantener puertos SSH abiertos. A continuación, cubriremos las opciones de almacenamiento de EC2: Instance Store frente a EBS.