Casi ningún incidente en la nube empieza con un ataque sofisticado a la infraestructura del proveedor. Empieza con una casilla marcada de más, un permiso con asterisco o un puerto que se abrió "un ratito para probar". La nube hace muy fácil crear recursos y muy fácil crearlos mal, así que la revisión de configuración rinde más que casi cualquier otra tarea de seguridad en este terreno.
Qué te toca y qué no
Los proveedores trabajan con un modelo de responsabilidad compartida. Ellos aseguran lo físico y la plataforma base; vos respondés por cómo configurás lo que contratás: quién accede, qué se expone, qué datos se guardan y cómo. El límite exacto se mueve según el tipo de servicio (una máquina virtual deja a tu cargo mucho más que un servicio administrado), por lo que conviene leer qué cubre cada uno en lugar de suponerlo. Una configuración riesgosa nunca es culpa del proveedor en el sentido que importa, porque es tu dato el que queda a la vista.
Almacenamiento público
El caso clásico es el contenedor de almacenamiento de objetos con lectura pública. Se crea para servir imágenes de un sitio, se abre el acceso para que funcione y con el tiempo se le suman respaldos, exportaciones y archivos de clientes. Nadie vuelve a mirar la configuración.
Qué revisar: qué contenedores permiten acceso anónimo, si de verdad lo necesitan, y qué hay adentro. Si el objetivo es servir archivos estáticos, es mejor ponerlos detrás de una red de distribución con acceso restringido al contenedor, y mantener separado lo público de lo privado en contenedores distintos. Muchos proveedores ofrecen un bloqueo de acceso público a nivel de cuenta; si no tenés razones para lo contrario, activalo.
Permisos de identidad demasiado amplios
Para que algo funcione rápido, es habitual asignar un rol de administrador o una política que permite todas las acciones sobre todos los recursos. Después queda así. El problema aparece cuando esa identidad se compromete: una clave filtrada o una aplicación vulnerable hereda todos los poderes de su cuenta de servicio.
Aplicá mínimo privilegio. Cada aplicación y cada persona, con permisos para lo que necesita y sobre los recursos que necesita. Evitá los comodines en acciones y recursos, preferí credenciales temporales a claves de larga vida y revisá periódicamente qué permisos concedidos no se usan hace tiempo. Las cuentas de uso diario no deberían ser la cuenta raíz, y esta última tiene que tener doble factor de autenticación y quedar guardada.
Puertos y paneles expuestos
Una base de datos con dirección pública, un puerto de administración remota abierto a todo internet, un panel de gestión de contenedores sin autenticación. Son hallazgos frecuentes porque los grupos de seguridad y las reglas de firewall se editan a mano y rara vez se limpian.
Revisá las reglas de entrada y pensá cada una: ¿quién necesita llegar a este puerto y desde dónde? Lo que es de administración debería ir por una VPN o un servicio de acceso con identidad, no abierto al mundo. Las bases de datos, en redes privadas. Y los paneles de herramientas internas (monitoreo, colas, paneles de proyectos) se cuelan seguido, porque vienen con una instalación por defecto sin protección.
Segmentación de red
Una red plana, donde cualquier máquina puede hablar con cualquier otra, convierte el compromiso de un componente menor en acceso a todo. Separá entornos (producción, pruebas, desarrollo) en cuentas o proyectos distintos, y dentro de cada uno dividí por función: lo que recibe tráfico de internet en un segmento, la lógica de aplicación en otro, los datos en un tercero, con reglas que permitan solo los flujos necesarios.
Secretos y registros
Las variables de entorno de una función o un contenedor pueden verse desde la consola para cualquiera con acceso de lectura a la configuración. Para credenciales de verdad, usá el gestor de secretos del proveedor o uno propio, y limitá quién puede leerlos.
Y activá los registros de auditoría de la cuenta desde el primer día. Son los que responden quién cambió esa regla, desde dónde y cuándo. Guardalos en un lugar donde un atacante con acceso a tus recursos no pueda borrarlos, y definí al menos unas pocas alertas: creación de claves nuevas, cambios en políticas de acceso, inicios de sesión de la cuenta raíz.
Una rutina que se sostiene
Alcanza con una revisión mensual de media hora con una lista corta: contenedores públicos, reglas abiertas a todo internet, identidades con permisos amplios, claves sin rotar. Muchos proveedores traen un verificador de postura que hace buena parte de ese trabajo. Y cuando automatices la infraestructura con código, esas mismas reglas pueden validarse antes de cada despliegue, de modo que el error no llegue a existir.