Seguridad en AWS: guía práctica de por dónde empezar

El modelo de responsabilidad compartida, en términos simples

AWS es responsable de la seguridad de la nube: los centros de datos físicos, la infraestructura de red, el hardware. Tú eres responsable de la seguridad en la nube: cómo configuras tus accesos, qué puertos dejas abiertos, si cifras tus datos, quién tiene acceso a qué.

En la práctica, esto significa que la inmensa mayoría de los incidentes de seguridad en AWS no son fallas de AWS — son configuraciones que el cliente dejó abiertas: buckets S3 públicos por error, datos sin cifrar, credenciales hardcodeadas en el código, o simplemente nadie revisando qué está pasando en la cuenta.

Por dónde empezar: las áreas que revisamos primero

Antes de entrar en cifrado, monitoreo y cumplimiento, hay una base que tiene que estar resuelta: quién puede hacer qué dentro de la cuenta — mínimo privilegio, MFA en las cuentas con privilegios y credenciales temporales en vez de llaves permanentes. Ese tema es lo suficientemente extenso como para tener su propia guía completa: revisa 5 errores de IAM en AWS que ponen en riesgo a una pyme si todavía no lo has hecho. Aquí nos enfocamos en lo que sigue después de resolver identidades y accesos.

Cifrado de datos

Cifrar no es un proyecto de meses — en la mayoría de los servicios de AWS es una casilla de configuración que se activa antes de que el recurso empiece a recibir datos. El problema típico no es técnico, es de antigüedad: recursos creados hace años, antes de que el cifrado fuera la opción por defecto, que nadie volvió a revisar.

• En reposo: habilita cifrado con AWS KMS en S3, RDS, EBS y cualquier almacenamiento que contenga datos sensibles. Configúralo como política por defecto para cuentas y buckets nuevos, no como una revisión manual caso por caso.
• En tránsito: fuerza TLS en todas las conexiones, tanto entre el usuario final y tu aplicación como entre tus propios servicios internos.
• Gestión de llaves: usa KMS en vez de manejar llaves de cifrado manualmente, y separa quién puede usar una llave de quién puede administrarla. Rota las llaves periódicamente y audita su uso igual que auditarías un permiso de IAM.

Monitoreo y detección de amenazas

Tener buenos controles no sirve de mucho si nadie se entera cuando algo sale mal. Estos tres servicios cubren capas distintas y se complementan entre sí.

Cumplimiento y gobernanza

• Define un baseline de seguridad documentado — qué controles son obligatorios para cualquier cuenta nueva que se cree, para que no dependan de que alguien recuerde configurarlos a mano.
• Haz revisiones periódicas, no solo una vez al contratar el servicio. La configuración de una cuenta AWS cambia constantemente a medida que el equipo despliega cosas nuevas; un baseline que no se revisa cada cierto tiempo se vuelve obsoleto rápido.
• Si manejas datos personales o de salud, estos controles no son opcionales — son la base para cumplir con habeas data en Colombia o normativas equivalentes en otros países de la región.

Un caso típico

Una empresa mediana que llega a nosotros con «queremos una revisión de seguridad» casi siempre tiene la misma combinación de hallazgos: volúmenes EBS o buckets S3 creados antes de que el cifrado fuera el estándar y que nadie volvió a revisar, CloudTrail activo pero sin ninguna alerta configurada sobre él, GuardDuty nunca activado porque «no sabíamos que existía» a pesar de costar poco frente a lo que detecta, y ningún baseline documentado — cada cuenta nueva hereda lo que alguien recordó configurar manualmente. Ninguno de estos hallazgos es exótico: son los mismos tres o cuatro patrones, una y otra vez.

Lo que no es realista prometer

Ninguna configuración de seguridad, por buena que sea, elimina el riesgo por completo. Cualquier proveedor que prometa «seguridad total» o «cero riesgo de incidentes» está vendiendo humo. Lo que sí es realista es reducir la superficie de ataque, detectar rápido cuando algo pasa, y tener un plan claro de respuesta — que es exactamente donde vale la pena invertir el esfuerzo.