Seguridad cloud: tu datos en la nube están tan protegidos como la configuración que hiciste

La conversación ha cambiado. Hace unos años, las empresas me decían que no se iban a la nube por miedo a la seguridad. Hoy me encuentro el problema contrario: empresas que se han ido a la nube asumiendo que el proveedor se encarga de todo. Y no es así.

Amazon, Microsoft y Google protegen su infraestructura con recursos que ninguna empresa mediana podría permitirse. Pero no protegen la configuración que haces tú. El bucket S3 que dejaste público, la base de datos sin cifrar, las credenciales de acceso embebidas en el código. Eso es responsabilidad tuya. Y es donde ocurren la mayoría de las brechas.

Los fallos más comunes que veo en auditorías

El bucket S3 público. Es un clásico que sigue ocurriendo. Un bucket configurado para acceso público de lectura, a veces de escritura, que contiene backups de bases de datos, documentos internos o archivos de configuración con credenciales. En 2024, un análisis de seguridad encontró que el 6% de todos los buckets S3 del mundo eran públicamente accesibles. El 6% de millones de buckets. Haz los números.

Las credenciales en el código. Un desarrollador necesita acceder a un servicio desde su entorno local y mete las claves de acceso en un archivo de configuración. El archivo acaba en un repositorio de GitHub, público o privado. Un atacante escanea repositorios en busca de patrones que parezcan credenciales. Las encuentra. Entra.

Los permisos IAM demasiado amplios. Por comodidad, se asignan políticas como "AdministratorAccess" a roles que solo necesitan leer de un bucket concreto. Si esas credenciales se ven comprometidas, el atacante no tiene acceso a un servicio. Tiene acceso a todo.

Los grupos de seguridad con reglas demasiado permisivas. Un puerto SSH abierto a todo internet (0.0.0.0/0) en lugar de a una IP específica. Un puerto de base de datos accesible desde fuera de la VPC. Configuraciones que llevan segundos en corregir y que nadie revisa.

El modelo de responsabilidad compartida

Los tres grandes proveedores cloud operan bajo lo que llaman el modelo de responsabilidad compartida. Ellos son responsables de la seguridad de la nube: el hardware, el software de virtualización, la seguridad física de los centros de datos. Tú eres responsable de la seguridad en la nube: la configuración de los servicios que usas, la gestión de accesos, el cifrado de los datos, la monitorización de actividad sospechosa.

El problema es que muchos clientes no entienden este reparto. Asumen que si los datos están en AWS, AWS los protege. Pero AWS no sabe si tu bucket S3 debería ser público o privado. Eso lo decides tú.

Cómo auditar tu seguridad cloud

Lo primero es activar los servicios nativos de auditoría: AWS CloudTrail, Azure Monitor, Google Cloud Logging. Registran cada acción que se realiza en tu cuenta. Si alguien crea un bucket público, queda registrado. Si alguien modifica un grupo de seguridad, queda registrado. Tener los logs es el primer paso para detectar anomalías.

Lo segundo es usar herramientas de gestión de la postura de seguridad cloud (CSPM). Soluciones como AWS Security Hub, Azure Security Center o herramientas de terceros analizan automáticamente tu configuración y detectan desviaciones respecto a las buenas prácticas. Un bucket público, un puerto abierto, un usuario con permisos excesivos. Te avisan.

Lo tercero es revisar los permisos IAM con el principio de mínimo privilegio como guía. Cada usuario, cada rol, cada servicio debe tener los permisos mínimos necesarios para funcionar. Nada más. Si una credencial se ve comprometida, que el daño esté limitado.

---

En NCR Consulting auditamos la configuración de seguridad de entornos cloud (AWS, Azure, Google Cloud). Identificamos vulnerabilidades, corregimos configuraciones inseguras y formamos a los equipos para mantener la seguridad a largo plazo.

Solicita una auditoría de seguridad cloud gratuita y descubre cuántos buckets públicos tienes sin saberlo.

Casos prácticos

El bucket que cualquiera podía leer. En una auditoría apareció un contenedor de almacenamiento en la nube con acceso de lectura público: documentos internos indexables por buscadores. El problema no era la nube, era la configuración. Se cerró el acceso, se activaron los logs y se definió quién puede leer qué. Coste de la auditoría: una mañana. Coste de no hacerla: incalculable.

El backup que nunca se restauró. Una pyme hacía copias automáticas diarias... y nunca las había probado. Cuando un ransomware cifró el servidor, descubrieron que las copias llevaban semanas fallando en silencio. La lección está en el checklist: una copia que no se restaura no es una copia. La prueba de restauración mensual es tan importante como el backup en sí.

Preguntas frecuentes

¿Mi pyme es objetivo de ciberataques? Sí, y más que una grande: las pymes tienen menos protecciones y son el objetivo preferido del ransomware. El ataque no distingue tamaño, distingue vulnerabilidad.

¿Necesito un experto para asegurar mi nube? Para el día a día, no: el checklist de ciberseguridad cubre el 80% de los fallos comunes (doble factor, gestor de contraseñas, copias verificadas, actualizaciones). Para la auditoría inicial y el plan de respuesta, una revisión puntual con un consultor cierra el resto.

¿Qué hago si me atacan? Tener el plan escrito antes del ataque: a quién avisar, qué desconectar, qué restaurar y en qué orden. Sin plan, el pánico decide por ti. La auditoría de seguridad incluye ese plan.

¿Cumplo el RGPD con los datos en la nube? Depende de la configuración: la nube opera con el modelo de responsabilidad compartida. El proveedor protege la infraestructura; tú proteges la configuración, los accesos y las copias. Esa parte no la hace nadie por ti.