Seguridad en AWS: IAM, VPC y Security Groups para startups

La seguridad en AWS no es un producto que compras. Es un conjunto de configuraciones que tu equipo debe implementar correctamente desde el primer día. AWS opera bajo un modelo de responsabilidad compartida: AWS asegura la infraestructura física y los servicios base. Tu empresa asegura todo lo que construye encima: las configuraciones de IAM, las redes virtuales, los datos, el acceso de usuarios y el código.

El problema es que la mayoría de startups priorizan velocidad sobre seguridad. Y es comprensible: cuando tienes 6 meses de runway, la seguridad no parece urgente. Hasta que lo es. Un bucket S3 público con datos de clientes, una clave de acceso comprometida o una base de datos accesible desde internet pueden destruir la confianza de tus usuarios y, con ella, tu empresa.

Este artículo cubre los tres pilares fundamentales de la seguridad en AWS (IAM, VPC y Security Groups) con la profundidad suficiente para implementarlos correctamente, sin la complejidad innecesaria que hace que muchos equipos los configuren mal o los ignoren.

IAM: la piedra angular de la seguridad en AWS

Qué es IAM y por qué es el servicio más importante

IAM (Identity and Access Management) controla quién puede hacer qué en tu cuenta de AWS. Cada acción en AWS, desde lanzar una instancia EC2 hasta leer un objeto en S3, pasa por IAM. Si IAM está mal configurado, nada más importa. Es como tener una cerradura de alta seguridad en la puerta principal pero dejar las ventanas abiertas.

IAM tiene cuatro componentes principales:

• Usuarios: Identidades permanentes para personas que acceden a AWS. Cada persona del equipo debería tener su propio usuario IAM.
• Grupos: Colecciones de usuarios que comparten los mismos permisos. “Developers”, “DevOps”, “Billing” son ejemplos típicos.
• Roles: Identidades temporales que los servicios o personas asumen para realizar acciones específicas. Un rol no tiene credenciales permanentes.
• Políticas: Documentos JSON que definen permisos. Especifican qué acciones se permiten o deniegan sobre qué recursos.

El principio de menor privilegio

El principio fundamental de IAM es: cada identidad debe tener exclusivamente los permisos que necesita para hacer su trabajo. Nada más.

En la práctica, esto significa:

No uses el usuario root: La cuenta root tiene acceso ilimitado a todo. Crea un usuario IAM con permisos de administrador para el día a día y guarda las credenciales root en un lugar seguro. Activa MFA en la cuenta root. Mejor aún, usa AWS Organizations y no crees recursos en la cuenta root.

No uses AdministratorAccess para desarrolladores: Es tentador dar a todos acceso de administrador “para no bloquear a nadie”. Pero un desarrollador con AdministratorAccess puede, por error o por compromiso de credenciales, borrar bases de datos de producción, modificar configuraciones de red o crear recursos en regiones que no monitorizas.

Crea políticas específicas: En lugar de "Action": "*", define exactamente qué acciones necesita cada rol:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::mi-bucket-produccion", "arn:aws:s3:::mi-bucket-produccion/*"]
    }
  ]
}

Esta política permite leer y escribir objetos en un bucket específico. Nada más. No permite borrar el bucket, no permite acceder a otros buckets, no permite modificar la configuración del bucket.

IAM Roles para servicios

Los servicios de AWS (Lambda, EC2, ECS) necesitan permisos para interactuar con otros servicios. Nunca uses access keys estáticas para esto. Usa IAM Roles.

Ejemplo: Lambda que lee de DynamoDB:

1. Crea un IAM Role con una política que permita dynamodb:GetItem y dynamodb:Query en la tabla específica.
2. Asigna el rol a la función Lambda.
3. Lambda asume el rol automáticamente y recibe credenciales temporales.

Las credenciales temporales de los roles se rotan automáticamente. Las access keys estáticas no. Si una access key se filtra (en un commit de Git, en un log, en una variable de entorno expuesta), el atacante tiene acceso hasta que la revoques. Con roles, las credenciales expiran en minutos u horas.

IAM Access Analyzer

IAM Access Analyzer es un servicio gratuito que identifica recursos compartidos con entidades externas a tu cuenta. Detecta:

• Buckets S3 con políticas que permiten acceso público.
• Roles IAM que pueden ser asumidos por cuentas externas.
• Claves KMS accesibles desde fuera de la cuenta.
• Colas SQS y topics SNS con permisos abiertos.

Actívalo desde el primer día. Es gratuito y te avisa de configuraciones que probablemente no pretendías hacer públicas.

MFA: no es opcional

Multi-Factor Authentication debería estar activo en todas las cuentas de usuario IAM con acceso a la consola. Sin MFA, una contraseña comprometida es suficiente para acceder a toda la cuenta.

Configuración recomendada:

• MFA obligatorio para el usuario root (hardware key si es posible).
• MFA obligatorio para todos los usuarios con acceso a consola.
• Política IAM que deniega todas las acciones si MFA no está activo (excepto la acción de configurar MFA).

VPC: la red privada en la nube

Qué es una VPC

Una VPC (Virtual Private Cloud) es una red virtual aislada dentro de AWS. Es tu propio espacio de red donde lanzas recursos. Por defecto, nada dentro de una VPC es accesible desde internet a menos que tú lo configures explícitamente.

Diseño de subnets

Una VPC bien diseñada tiene al menos tres tipos de subnets:

Subnets públicas: Recursos con acceso directo a internet a través de un Internet Gateway. Solo deberían estar aquí:

• Load balancers (ALB, NLB).
• Bastión hosts (si los usas, aunque Session Manager es preferible).
• NAT Gateways.

Subnets privadas: Recursos sin acceso directo desde internet. Pueden acceder a internet a través de un NAT Gateway. Aquí van:

• Instancias EC2 de aplicación.
• Contenedores (ECS, EKS).
• Funciones Lambda que necesitan acceso a la VPC.

Subnets aisladas (data tier): Subnets sin acceso a internet, ni siquiera a través de NAT Gateway. Para:

• Bases de datos (RDS, ElastiCache, OpenSearch).
• Cualquier recurso que almacene datos sensibles.

Arquitectura de VPC recomendada

VPC: 10.0.0.0/16

Zona de Disponibilidad A:
  - Subnet pública:  10.0.1.0/24  (ALB, NAT GW)
  - Subnet privada:  10.0.10.0/24 (App servers)
  - Subnet aislada:  10.0.100.0/24 (Databases)

Zona de Disponibilidad B:
  - Subnet pública:  10.0.2.0/24  (ALB, NAT GW)
  - Subnet privada:  10.0.20.0/24 (App servers)
  - Subnet aislada:  10.0.200.0/24 (Databases)

Regla fundamental: Usa al menos 2 zonas de disponibilidad para alta disponibilidad. Los ALBs requieren subnets en al menos 2 AZs.

NAT Gateway vs NAT Instance

Los recursos en subnets privadas necesitan acceso a internet (para descargar parches, llamar a APIs externas, etc.) pero no deben ser accesibles desde internet. El NAT Gateway resuelve esto.

NAT Gateway (recomendado):

• Servicio gestionado por AWS.
• Alta disponibilidad dentro de una AZ.
• Ancho de banda hasta 100 Gbps.
• Coste: 0,045 dolares/hora + 0,045 dolares/GB procesado.
• Para alta disponibilidad: un NAT Gateway por AZ.

NAT Instance (alternativa económica):

• Una instancia EC2 que actúa como NAT.
• Tu equipo la gestiona (parches, escalado, disponibilidad).
• Más económica para tráfico bajo.
• No recomendada para producción a menos que el presupuesto sea extremadamente limitado.

VPC Endpoints: tráfico privado con servicios AWS

Por defecto, cuando tu instancia EC2 en una subnet privada llama a S3, el tráfico sale por el NAT Gateway a internet y vuelve a AWS. Estás pagando por NAT Gateway y exponiendo tráfico innecesariamente.

Los VPC Endpoints permiten que tus recursos accedan a servicios AWS sin salir de la red privada:

Gateway Endpoints (gratuitos): Para S3 y DynamoDB. Se añaden como entrada en la tabla de rutas. Todo el tráfico a S3/DynamoDB se redirige por la red privada de AWS.

Interface Endpoints (con coste): Para el resto de servicios AWS (SQS, SNS, Secrets Manager, CloudWatch, etc.). Crean una ENI en tu subnet con una IP privada. Coste: 0,01 dolares/hora por AZ + 0,01 dolares/GB procesado.

Recomendación: Como mínimo, crea Gateway Endpoints para S3 y DynamoDB. Son gratuitos y reducen el tráfico por NAT Gateway. Para servicios que manejan datos sensibles (Secrets Manager, KMS), los Interface Endpoints añaden una capa de seguridad al mantener el tráfico dentro de la red privada.

Security Groups: el firewall por instancia

Cómo funcionan

Los Security Groups son firewalls stateful que controlan el tráfico entrante (inbound) y saliente (outbound) a nivel de instancia o ENI. “Stateful” significa que si permites tráfico entrante en un puerto, el tráfico de respuesta se permite automáticamente sin necesidad de una regla de salida explícita.

Reglas fundamentales

Por defecto, todo el tráfico entrante está bloqueado: Un Security Group sin reglas de entrada no permite ninguna conexión.

Por defecto, todo el tráfico saliente está permitido: Un Security Group nuevo permite todo el tráfico de salida. En la mayoría de casos, esto es aceptable. Para entornos con requisitos de compliance estrictos, restringe también el tráfico de salida.

Los Security Groups referencian otros Security Groups: Esta es la característica más poderosa. En lugar de abrir un puerto a una IP o rango CIDR, puedes abrir un puerto “al Security Group del ALB”. Esto significa que solo las instancias que pertenecen al Security Group del ALB pueden comunicarse con tu servicio.

Diseño de Security Groups por capas

Security Group del ALB:

Inbound:
  - Puerto 443 (HTTPS) desde 0.0.0.0/0 (internet)
  - Puerto 80 (HTTP) desde 0.0.0.0/0 (para redirección a HTTPS)
Outbound:
  - Todo el tráfico (default)

Security Group de la aplicación:

Inbound:
  - Puerto 8080 desde sg-alb (solo el ALB puede hablar con la app)
Outbound:
  - Todo el tráfico (default)

Security Group de la base de datos:

Inbound:
  - Puerto 5432 (PostgreSQL) desde sg-app (solo la app puede hablar con la BD)
Outbound:
  - Sin reglas (la BD no necesita iniciar conexiones)

Esta configuración crea una cadena de confianza: internet solo habla con el ALB, el ALB solo habla con la aplicación, y la aplicación solo habla con la base de datos. Un atacante que comprometa el ALB no puede acceder directamente a la base de datos.

Network ACLs vs Security Groups

Las Network ACLs (NACLs) operan a nivel de subnet, no de instancia. Son stateless (necesitas reglas explícitas de entrada y salida) y se evalúan por orden numérico.

Recomendación: Usa Security Groups como primera línea de defensa. Usa NACLs como segunda capa para bloquear rangos de IP conocidos como maliciosos o para cumplir requisitos de compliance que exigen defense in depth.

Errores de seguridad comunes en startups

1. Access keys en repositorios de código

Es el error más frecuente y más peligroso. Un access key de AWS publicado en GitHub es detectado por bots automatizados en minutos. Esos bots lanzan instancias para minería de criptomonedas que pueden generar facturas de miles de euros en horas.

Solución: Nunca uses access keys en código. Usa IAM Roles para servicios, variables de entorno cifradas para aplicaciones locales y AWS Secrets Manager para gestión centralizada de secretos. Activa las notificaciones de AWS sobre access keys expuestas.

2. Buckets S3 públicos

S3 bloquea el acceso público por defecto desde abril de 2023. Pero si desactivas esa protección “porque algo no funciona”, estás exponiendo datos. Usa S3 Block Public Access a nivel de cuenta y nunca lo desactives.

3. Bases de datos con acceso público

RDS permite la opción “Publicly Accessible” durante la creación. Si la activas, tu base de datos tiene una IP pública. Aunque los Security Groups limiten el acceso, la exposición es innecesaria y aumenta la superficie de ataque.

Solución: Bases de datos siempre en subnets privadas. Acceso mediante bastión host, Session Manager o VPN.

4. Una sola cuenta AWS para todo

Desarrollo, staging y producción en la misma cuenta. Un error en desarrollo puede afectar a producción. Un desarrollador junior con acceso a desarrollo tiene, potencialmente, acceso a datos de producción.

Solución: AWS Organizations con cuentas separadas por entorno. SCPs para limitar lo que cada cuenta puede hacer. AWS Control Tower para automatizar la configuración.

5. Logs desactivados

CloudTrail desactivado o configurado solo en una región. Sin CloudTrail, no hay registro de quién hizo qué. Investigar un incidente de seguridad sin logs es como investigar un crimen sin evidencias.

Solución: CloudTrail activado en todas las regiones, con logs enviados a un bucket S3 en una cuenta de logs separada con protección contra borrado.

Herramientas de detección y respuesta

AWS GuardDuty

GuardDuty es un servicio de detección de amenazas que analiza logs de CloudTrail, VPC Flow Logs y DNS Logs para identificar actividad sospechosa. Detecta:

• Instancias EC2 comunicándose con IPs conocidas como maliciosas.
• Acceso inusual a credenciales IAM desde ubicaciones geográficas nuevas.
• Intentos de exfiltración de datos desde buckets S3.
• Minería de criptomonedas en tus instancias.
• Patrones de reconocimiento (port scanning, API enumeration).

Coste: Basado en el volumen de datos analizados. Para una cuenta con actividad moderada, espera entre 5 y 30 dolares al mes. Activarlo es una de las acciones de seguridad con mejor relación coste-beneficio.

AWS Security Hub

Security Hub agrega findings de GuardDuty, IAM Access Analyzer, Inspector, Firewall Manager y Config en un único panel. También evalúa tu cuenta contra estándares de compliance:

• AWS Foundational Security Best Practices: 200+ comprobaciones de seguridad.
• CIS AWS Foundations Benchmark: Estándar de la industria para configuración segura de AWS.
• PCI DSS: Para empresas que procesan datos de tarjetas de crédito.

Security Hub no es gratuito (se cobra por finding y por comprobación), pero para empresas con requisitos de compliance, centraliza la gestión de seguridad de forma significativa.

AWS Config

Config monitoriza y registra la configuración de todos tus recursos AWS. Permite crear reglas que evalúan si los recursos cumplen con tus políticas:

• “Todos los buckets S3 deben tener cifrado activado.”
• “Ningún Security Group debe permitir tráfico entrante desde 0.0.0.0/0 en el puerto 22.”
• “Todas las instancias RDS deben tener Multi-AZ activado.”

Cuando un recurso no cumple, Config genera un finding y puede ejecutar una acción de remediación automática (a través de Systems Manager Automation).

Cifrado: en tránsito y en reposo

Cifrado en tránsito

Todo el tráfico entre servicios debe usar TLS. En AWS:

• Los ALBs terminan TLS con certificados de ACM (AWS Certificate Manager), que son gratuitos y se renuevan automáticamente.
• El tráfico entre ALB y las instancias de aplicación también debería usar TLS (end-to-end encryption), aunque muchos equipos lo omiten para simplificar.
• Las conexiones a RDS, ElastiCache y OpenSearch soportan TLS. Actívalo siempre.

Cifrado en reposo

AWS KMS (Key Management Service) gestiona las claves de cifrado:

• Claves gestionadas por AWS (aws/s3, aws/ebs): Gratuitas, AWS gestiona la rotación.
• Claves gestionadas por el cliente (CMK): 1 dolar al mes por clave + 0,03 dolares por cada 10.000 operaciones. Necesarias si quieres control sobre la política de la clave (quién puede usarla, cuándo se rota, etc.).

Servicios que deben tener cifrado en reposo activado:

• S3: SSE-S3 (por defecto desde enero de 2023) o SSE-KMS.
• EBS: Cifrado por defecto activado a nivel de cuenta.
• RDS: Cifrado activado al crear la instancia (no se puede activar después).
• DynamoDB: Cifrado activado por defecto.

Plan de seguridad para startups: los primeros 30 días

Semana 1: identidad y acceso

• Activar MFA en la cuenta root.
• Crear usuarios IAM individuales para cada persona del equipo.
• Crear grupos IAM con políticas de menor privilegio.
• Desactivar las access keys del usuario root.
• Activar IAM Access Analyzer.

Semana 2: red y aislamiento

• Diseñar la VPC con subnets públicas, privadas y aisladas.
• Crear Security Groups por capa (ALB, app, datos).
• Crear Gateway Endpoints para S3 y DynamoDB.
• Verificar que ninguna base de datos tiene acceso público.

Semana 3: detección y monitorización

• Activar CloudTrail en todas las regiones.
• Activar GuardDuty para detección de amenazas.
• Configurar AWS Config con reglas básicas de compliance.
• Crear alertas en CloudWatch para actividad sospechosa.

Semana 4: gestión de secretos y cifrado

• Migrar todos los secretos a AWS Secrets Manager.
• Activar cifrado con KMS para S3, EBS y RDS.
• Configurar rotación automática de secretos.
• Revisar que todo el tráfico usa TLS.

Conclusión

La seguridad en AWS no es un proyecto con fecha de fin. Es una práctica continua que evoluciona con tu infraestructura. Pero los fundamentos son simples: IAM con menor privilegio, VPC bien diseñada y Security Groups correctos cubren el 80% de los riesgos a los que se enfrenta una startup.

El coste de implementar estas prácticas desde el principio es mínimo. El coste de no hacerlo puede ser existencial.

Si no estás seguro del estado de seguridad de tu infraestructura AWS, en NERVICO realizamos auditorías de seguridad que cubren IAM, networking, cifrado y compliance. Solicita una auditoría gratuita y te mostramos exactamente dónde están los riesgos.