Confusión habitual: seguridad como servicio vs. responsabilidad de uso
Una confusión común en implementaciones cloud es pensar que por estar en AWS, Azure o GCP, los datos, aplicaciones y configuraciones ya están automáticamente protegidos. Las empresas asumen que los controles de firewall, identidad, cifrado o monitorización son responsabilidad exclusiva del proveedor. Esto distorsiona el modelo real de responsabilidad compartida y deja huecos críticos.
En una empresa de retail con workloads productivos en AWS, el equipo de desarrollo asumió que IAM era “cosa de la nube”. No implementaron políticas de acceso granular ni rotación de credenciales. La consecuencia: un desarrollador compartió una key con un tercero externo en Slack, sin controles activados. Esto derivó en un acceso no autorizado a un bucket S3 con datos sensibles. AWS no es responsable de controlar qué usuarios se configuran ni cómo se gestionan las credenciales dentro de tu tenant.
La seguridad por parte del proveedor se limita a la infraestructura que ellos operan: data centers físicos, red troncal, hardware y niveles bajos del stack. Lo que tú creas, despliegas y expones es tu responsabilidad directa. No entender esta línea es un patrón frecuente en empresas que migran sin madurez cloud suficiente.
Configuraciones por defecto y su falsa sensación de seguridad
Muchos servicios cloud vienen con defaults funcionales pero no necesariamente seguros. Algunos ejemplos: bucket S3 sin cifrado automatizado, políticas overly permissive generadas por asistentes (“policy generators”), o VM con puertos SSH abiertos a internet. La idea de “todo será seguro desde el inicio” lleva a una operación negligente.
Una aseguradora en LATAM desplegó una arquitectura en GCP con Cloud Storage y Compute Engine. Confiaron en las configuraciones iniciales, asumiendo que los storage buckets estaban protegidos. Tras una auditoría de su equipo de cumplimiento, se detectaron tres buckets con ‘allUsers:READER’ en sus ACLs. La fuga no ocurrió por una falla de GCP, sino por no revisar ni limitar el acceso heredado.
- Archivos compartidos con públicos sin advertencia previa
- Servicios expuestos sin revisar reglas de firewall
- Recursos con roles administradores sin justificación
Cada uno de estos puntos se remonta a una misma raíz: asumir que lo proveído viene ya con intenciones de seguridad decididas por el proveedor, lo cual es incorrecto.
Anti-patrón frecuente: dejar la seguridad “para después” en proyectos cloud
Una práctica bastante extendida en empresas medianas es cerrar proyectos cloud con urgencia y asumir que la seguridad puede «afinarse luego». Bajo presión de negocio, se lanza el MVP omitiendo postureos básicos como hardening de instancias, control de acceso estricto, segregación de cuentas o monitoreo activo de logs. Sin sorpresas: estos entornos devienen en superficies vulnerables sin detección temprana.
En un banco digital en expansión regional, una arquitectura basada en microservicios fue migrada a contenedores en AWS. En la fase inicial no se desplegó ningún control de AWS GuardDuty, no se activaron CloudTrail en todas las regiones y se usaban claves hardcodeadas en variables de entorno. Resultado: actividad sospechosa persistente no fue detectada hasta que las métricas de red alertaron por tráfico inusual.
El error fue asumir que el proveedor «avisaría» ante esas anomalías. Sin configuración activa, no hay alertas, no hay rastreo, y lo que es peor: se pierde la trazabilidad necesaria para investigar post-incidente.
Cómo hacerlo en la práctica: asegurar lo que subes tú
Romper con esta mentalidad implica cambiar el punto de partida: nada de lo que configures en tu cuenta cloud está securizado por defecto para tus casos de uso. El proveedor ofrece herramientas, pero la activación, configuración y contexto son responsabilidad de tu equipo.
- Crear políticas IAM explícitas: Define y asigna roles mínimos, evitando “*” en acciones y recursos. Realiza revisión trimestral.
- Configurar monitorización activamente: Activa CloudTrail, GuardDuty o Cloud Logging según plataforma. Integra con tu SIEM.
- Validar exposición: Usa herramientas como AWS Trusted Advisor o scripts con AWS CLI para detectar recursos públicos no deseados.
- Revisar permisos compartidos: Identifica dónde has usado enlaces públicos, keys no rotadas o credenciales en código fuente.
En auditorías internas, agrega controles como tagging obligatorio para recursos críticos, alertas por creaciones sin cifrado, y políticas SCP en organizaciones AWS que limiten comportamientos peligrosos (p. ej., denegar IAM:CreateAccessKey fuera del entorno seguro).
Recomendaciones para entornos corporativos
No hay atajos en la seguridad cloud. La idea de que “el proveedor ya se encarga” desactiva el músculo operativo de seguridad interno. En proyectos reales, eso se traduce en entornos sin monitoreo, permisos excesivos y datos sensibles mal protegidos.
Para operar en cloud con seguridad real, los equipos deben asumir que todo lo creado, configurado y expuesto corre por cuenta de la organización. Las herramientas están ahí, pero activarlas, afinarlas y mantenerlas es trabajo del cliente. Asigna roles claros, audita continuamente, limita el blast radius y no delegues seguridad por omisión.
El modelo de responsabilidad compartida no es reparto equitativo. Es un contrato en el que el proveedor cuida su stack y tú cuidas el tuyo. Lo que pongas en el cloud será tan seguro como tú lo diseñes.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.