TÉCNICO-GERENCIAL · SEGURIDAD CLOUD · CONFIGURACIONES
Ayer planteé que migrar a la nube no transfiere la responsabilidad de seguridad al proveedor: la redistribuye. Hoy quiero bajar eso a los casos concretos más frecuentes en entornos cloud de organizaciones medianas, las configuraciones que generan exposición real pero que el proveedor no marca como error porque técnicamente hacen exactamente lo que se les pidió que hicieran.
Ese es el punto central de hoy: el proveedor cloud no tiene forma de saber si una configuración es correcta para el contexto de negocio de la organización. Solo sabe si la configuración es técnicamente válida. Un bucket con acceso público es una configuración perfectamente válida en Azure o AWS. Si ese bucket contiene datos de clientes que no deberían ser públicos, el problema no es del proveedor. Es de quien configuró el acceso sin considerar qué había adentro.
CONFIG 1: ALMACENAMIENTO CON ACCESO PÚBLICO
Los buckets de almacenamiento con acceso público han sido el origen de algunos de los incidentes de exposición de datos más grandes de los últimos años en organizaciones de todos los tamaños. El mecanismo es simple: durante una migración o una prueba, alguien habilita el acceso público a un contenedor de almacenamiento para facilitar el trabajo, con la intención de restringirlo después. Después no llega, o llega demasiado tarde.
En Azure, un blob storage con acceso público anónimo es un recurso completamente accesible desde internet para cualquier persona que conozca o pueda descubrir la URL. En AWS, un S3 bucket con acceso público tiene el mismo resultado. El proveedor no alerta porque el acceso público es una funcionalidad legítima que tiene casos de uso válidos: distribución de contenido estático, assets de sitios web públicos, archivos descargables. El problema ocurre cuando esa configuración se aplica por error o por urgencia a contenedores que tienen datos que no deberían ser accesibles.
La revisión de este punto no requiere herramientas sofisticadas: requiere listar todos los contenedores de almacenamiento activos y verificar cuáles tienen acceso público habilitado, luego validar que el contenido de cada uno justifica esa configuración.
CONFIG 2: CUENTAS DE SERVICIO CON PRIVILEGIOS EXCESIVOS
El privilege creep que describí en la semana de identidad on-premise tiene un equivalente cloud con características propias. En entornos cloud, las cuentas de servicio, que son identidades usadas por aplicaciones y servicios automatizados para autenticarse contra recursos cloud, frecuentemente se crean con el rol de Owner o Contributor a nivel de suscripción o de grupo de recursos, porque es la forma más rápida de que la aplicación funcione sin errores de permisos.
Una cuenta de servicio con permisos de Owner sobre la suscripción completa de Azure puede hacer prácticamente cualquier cosa en el entorno cloud de la organización. Si esa cuenta de servicio es comprometida, el atacante tiene acceso equivalente al de un administrador global sobre todos los recursos cloud. El principio de mínimo privilegio aplica aquí con especial importancia: esa cuenta de servicio probablemente solo necesita acceso a un recurso específico o a un conjunto acotado de operaciones, no a toda la suscripción.
El proveedor no reporta esto como error porque una cuenta de servicio con permisos de Owner es una configuración técnicamente válida. Auditar los roles asignados a las cuentas de servicio y reducirlos al mínimo necesario es trabajo de revisión que el equipo tiene que hacer activamente.
ERROR COMÚN
Asumir que porque una aplicación "funciona" en el entorno cloud, los permisos están bien configurados. Una aplicación funciona cuando tiene suficientes permisos para ejecutar sus tareas. No cuando tiene exactamente los permisos necesarios y nada más. La diferencia entre esas dos condiciones define la superficie de ataque disponible si esa aplicación o sus credenciales son comprometidas.
CONFIG 3: REGLAS DE RED VIRTUAL DEMASIADO PERMISIVAS
Los Network Security Groups en Azure o los Security Groups en AWS son el equivalente cloud de las reglas de firewall. Durante una migración bajo urgencia, es frecuente crear reglas que permiten acceso desde cualquier origen (0.0.0.0/0) a puertos de administración como el 22 (SSH) o el 3389 (RDP), para poder conectarse a las máquinas virtuales sin restricciones y resolver problemas rápidamente.
Esa regla, que en el contexto de la urgencia era conveniente, convierte a esas máquinas virtuales en objetivos directamente accesibles desde internet para cualquier atacante que esté escaneando rangos de IP en busca de puertos abiertos. En producción, el acceso SSH o RDP debería estar restringido a rangos de IP específicos, a través de un bastion host o una VPN, nunca abierto al mundo.
La naturaleza del problema es idéntica al caso del bucket: el proveedor no alerta porque una regla que permite todo el tráfico entrante en un puerto específico es técnicamente válida. Es la organización la que tiene que determinar si esa configuración es apropiada para ese recurso en producción.
CONFIGS 4, 5 Y 6: VISIBILIDAD, CREDENCIALES Y AUTENTICACIÓN
Los logs de auditoría deshabilitados son una configuración frecuente en entornos cloud donde se redujo el costo de almacenamiento apagando servicios de logging. El problema es que sin esos logs, la organización no tiene visibilidad sobre qué ocurre en su entorno cloud: quién accedió a qué recurso, qué cambios de configuración se hicieron, qué operaciones ejecutó cada cuenta de servicio. En caso de incidente, la investigación forense es prácticamente imposible sin esos registros.
Las credenciales hardcodeadas en código son un problema que se agravó con la adopción de cloud. Durante el desarrollo o la migración bajo urgencia, es tentador incluir directamente las access keys o connection strings en el código o en archivos de configuración para que todo funcione rápido. Si ese código termina en un repositorio, las credenciales quedan expuestas para cualquiera que tenga acceso al repositorio. Incluso en repositorios privados, una brecha en el control de acceso expone todas las credenciales que el código contenga.
La ausencia de MFA en cuentas administrativas cloud es la brecha que con más frecuencia facilita el compromiso inicial de un entorno cloud. Una contraseña robada o filtrada es suficiente para acceder a una cuenta de administrador cloud si no hay un segundo factor. El proveedor ofrece MFA como opción, generalmente sin costo adicional, pero no lo exige por defecto. La decisión de habilitarlo es de la organización, y en entornos cloud creados bajo urgencia es frecuente que esa decisión no se tome en el momento inicial.
DECISIÓN QUE DEBE TOMAR EL CIO
Revisar estas seis configuraciones en el entorno cloud actual. No como un proyecto de seguridad cloud de largo plazo sino como un diagnóstico de una tarde: ¿hay almacenamiento con acceso público? ¿Hay cuentas de servicio con permisos de Owner? ¿Hay puertos de administración abiertos al mundo? ¿Están habilitados los logs de auditoría? ¿Hay credenciales en repositorios de código? ¿Tienen MFA las cuentas administrativas? Las respuestas a esas seis preguntas ya definen los riesgos más urgentes del entorno cloud.
¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?
Lo que tienen en común estas seis configuraciones es que ninguna de ellas es un error técnico. Son decisiones de configuración que el entorno cloud ejecuta correctamente. El problema no está en la herramienta: está en la decisión que se tomó cuando se configuró, generalmente bajo presión y sin tiempo de considerar las implicaciones de seguridad.
En entornos cloud creados bajo urgencia, como el de TechCorp Latam después del ransomware, la probabilidad de que alguna de estas configuraciones esté presente es alta. No porque el equipo sea descuidado, sino porque bajo urgencia las prioridades son distintas. El jueves voy a ver exactamente qué configuraciones quedaron pendientes en el entorno cloud de TechCorp Latam y qué papel jugaron en la tensión posterior entre seguridad y costos.
El proveedor cloud no puede decirte si una configuración es correcta para tu contexto de negocio. Solo puede decirte si es técnicamente válida. La diferencia entre esas dos condiciones es exactamente el espacio donde viven la mayoría de los incidentes cloud.
Artículo núcleo de la semana: Seguridad en la nube: las decisiones que se toman mal cuando la infraestructura deja de ser tuya. Mañana: identidad y acceso en entornos cloud.
#SeguridadCloud #CloudSecurity #Azure #AWS #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #IAM #NISTCSF #ISO27001 #Misconfiguration
Comentarios
Publicar un comentario