Los puntos ciegos de la multicloud dejan expuestos a los equipos de seguridad.

La mayoría de las empresas no eligieron la multinube como una estrategia deliberada. Simplemente la implementaron: una adquisición les trajo una empresa que ya operaba con otro proveedor; un equipo optó por Amazon Web Services (AWS) por ser la plataforma que conocían; otro desarrolló proyectos en Microsoft Azure porque se incluía con las licencias existentes; y un tercero, discretamente, desarrolló soluciones en Google Cloud Platform (GCP) porque a un desarrollador le gustaban las herramientas.

Nadie diseñó esto de forma planificada. Y nadie se hizo responsable de las brechas entre las distintas partes. Ese es el verdadero riesgo. No reside en un único proveedor de nube, sino en las interconexiones entre ellos.

¿Por qué las interconexiones son el problema?

Cada proveedor de nube tiene su propio modelo de gestión de identidades y accesos (IAM), su propia configuración predeterminada y su propia forma de estructurar permisos y recursos. Una política de seguridad que funciona a la perfección en AWS no tiene automáticamente el mismo efecto en Azure, aunque conceptualmente parezcan similares sobre el papel.

Los equipos que dan por sentada la paridad entre proveedores, considerando que «lo hemos protegido en una nube» equivale a «lo hemos protegido en todas partes», suelen equivocarse sin darse cuenta, porque los modelos subyacentes simplemente no se corresponden uno a uno.

Esta no es una preocupación hipotética. Es la realidad subyacente a muchos de los incidentes que se reportan a posteriori: no se trata de un fallo espectacular aislado, sino de una brecha entre dos sistemas que nadie se encargó de verificar.