La mayoría de las empresas ya no utilizan una sola cloud. Utilizan dos, tres o más, y cada proveedor tiene su propio modelo de identidades, su propio lenguaje normativo y su propio formato de registro de auditoría. Según Cloud «State of the Cloud 2025» de Flexera, aproximadamente el 70 % de las organizaciones utilizan entornos híbridos ocloud, con una media de 2,4 proveedores públicos cada una. Esa fragmentación es precisamente donde actúan los atacantes. Según el estudio «Cost of a Data Breach» del Ponemon Institute, las filtraciones que abarcan múltiples entornos son las más costosas y las que más tiempo tardan en contenerse, según el informe de 2024.
En esta página se explica qué escloud , en qué se diferencia de cloud híbrida, por qué la federacióncloud es el riesgo principal y cómo la detección unificada permite visualizar uncloud como un único incidente. Es precisamente esa profundidad la que no ofrece la típica «lista de capacidades».
cloud consiste en proteger las cargas de trabajo, los datos y las identidades en dos o más cloud pública —como AWS, Azure y Cloud como si se tratara de una única superficie de ataque, aplicando políticas, visibilidad y detección de amenazas coherentes, aunque cada proveedor cuente con un plano de control independiente. Esta disciplina considera a los proveedores como un único entorno, y no como varios.
Las organizaciones adoptancloud razones de peso: los mejores servicios de cada proveedor, la resiliencia frente a una interrupción del servicio de un único proveedor, la flexibilidad en cuanto a la ubicación de los datos y la ausencia de dependencia de un único proveedor.cloud tambiéncloud mejorar la resiliencia de la seguridad, ya que cloud sola cloud no provoca la caída de todo el sistema. La contrapartida es la complejidad, y el reto de seguridad radica en la brecha entre proveedores, no en una cloud concreta.
Esa complejidad es ahora la norma y no la excepción. El estudio «2025 Cloud Study» de Thales, basado en las respuestas de unos 3.200 participantes, sitúa la media en 2,1 proveedores públicos por organización. Las cifras de adopción varían ampliamente dependiendo de si una encuesta cuenta solo los proveedores públicos o incluye los híbridos —las estimaciones más antiguas alcanzaban hasta el 98 % (Oracle/451 Research, 2023)—, pero los datos actuales de 2025 coinciden en que el modelo operativo estándar es de dos o más proveedores. La conclusión es sencilla: si se gestiona más de una cloud, cloud ya no es opcional, y la tarea consiste en mantener una protección coherente entre proveedores que nunca fueron diseñados para interoperar.
Para profundizar en la categoría de herramientas que ofrecen estas funciones —y en cómo se complementan la gestión de la postura cloud , la protección de cargas de trabajo y la gestión de derechos—, consulta nuestra guía sobre cloud y respuestacloud .
A menudo cloud confunden los conceptos decloud cloud híbrida», pero describen arquitecturas diferentes con distintos puntos débiles.cloud dos o más proveedores públicos que operan en paralelo. El modelo de amenazas es de proveedor a proveedor: gestión de identidades y accesos (IAM) inconsistente, registros fragmentados y confianza de federación que un atacante puede aprovechar para pasar de una cloud otra. cloud híbrida cloud una infraestructura local combinada con cloud, donde las principales preocupaciones son la visibilidad este-oeste y el puente de identidades entre los directorios locales y los proveedores cloud .
Esta distinción es importante porque determina qué controles se necesitan. Un programa híbrido se centra principalmente en supervisar la interfaz entre el centro de datos y la cloud. Uncloud se centra en normalizar la telemetría y correlacionar la actividad de las identidades entre los distintos proveedores que generan datos de diferente naturaleza.
Tabla: cloud entrecloud cloud híbrida en cuanto a alcance y modelo de amenazas.
Esta página trata sobre el modelo de dos o más proveedores. Para lacloud —la detección este-oeste y el puentecloud —, consulta la sección sobre detección cloud híbrida.
cloud más comunescloud no son nada del otro mundo. Son las consecuencias previsibles de combinar proveedores que gestionan la identidad, las políticas y el registro de eventos de forma diferente. Los retos recurrentes son:
La fragmentación de la visibilidad merece una definición, ya que es la causa de muchos otros problemas: se trata del punto ciego de seguridad que se crea cuando cada proveedor registra y genera informes de forma diferente, lo que impide tener una visión global de lo que ocurre en todos ellos. cloud olvidadas cloud suponen un riesgo por una razón similar: una cuenta inactiva con permisos excesivos que nadie supervisa es el punto de entrada ideal para un atacante, y en uncloud esas cuentas se multiplican por cada proveedor.
¿Soncloud más vulnerables a los ciberataques? No de por sí.cloud nocloud menos seguro por naturaleza, pero la visibilidad fragmentada y una gestión inconsistente de la identidad y el acceso (IAM) amplían el margen de tiempo durante el cual un atacante puede actuar sin ser detectado. Los datos sobre los costes lo dejan claro. Según el estudio «Cost of a Data Breach» del Ponemon Institute, en el informe de 2024, las filtraciones que abarcan múltiples entornos son las más costosas —5,05 millones de dólares— y tardaron 283 días en identificarse y contenerse, con un 40 % de las filtraciones afectando a múltiples entornos. La edición de 2025 situó el coste medio global de una filtración en 4,44 millones de dólares, el primer descenso en cinco años. La conclusión es la misma en todas las ediciones: cuando una filtración afecta a varios entornos, cuesta más y se prolonga más tiempo, porque ninguna consola tiene una visión global de la situación.
Para conocer los fundamentos del modelo de responsabilidad compartida y las prácticas básicas que todo cloud debe tener, consulta nuestra guía cloud .
Esta es la parte que suelen omitir las páginas de referencia estándar. Mencionar CSPM, CWPP y CIEM como «funcionalidades» solo te indica qué comprar, pero no cómo lograr una detección coherente cuando AWS CloudTrail, los registros de actividad y de Entra de Azure, y los registros Cloud Google Cloud difieren en cuanto a esquema, latencia y modelo de identidad. La detección unificada normaliza la telemetría de cada proveedor en un único modelo, de modo que uncloud se presenta como una historia correlacionada, y no como una serie de eventos dispersos.
El proceso sigue un flujo de trabajo repetible:

El proceso parte de la realidad del plano de control. Cada proveedor lleva a cabo las auditorías y la autenticación de forma diferente, y un modelo de detección que funciona en una cloud copiarse tal cual en otra. La tabla siguiente muestra las diferencias que debe conciliar una capa unificada.
Tabla: Diferencias en el plano de control y el registro por proveedor que un modelo de detección unificado debe normalizar.
Una vez normalizada la telemetría, la cuestión es dónde se almacena. Un SIEM tradicional ofrece funciones maduras de correlación y generación de informes, pero puede resultar costoso cuando se trata de grandes volúmenescloud . Un lago de datos de seguridad ofrece una retención más económica y consultas flexibles, pero impone a su equipo una mayor carga de trabajo en materia de ingeniería de detección. Muchas empresas utilizan ambas soluciones: un lago de datos para la amplitud y la retención, y una capa de detección unificada para la correlación en tiempo real. La detección y respuesta de red (NDR) y la detección y respuesta ampliadas (XDR) aportan lo que se pierde en una visión basada únicamente en registros: al analizar eventos cloud junto con la telemetría de flujo y de comportamiento, revelancloud que la consola de un único proveedor no puede ver.
La capa de red es un elemento clave en este contexto y merece un análisis en profundidad; para obtener más información sobre la inspección y la segmentación del tráfico entre distintos proveedores, consulte la sección sobre seguridadcloud . Sin embargo, la inversión por sí sola no basta para salvar la brecha. Una encuesta del sectorcloud realizada en 2026 reveló que el 41 % de las organizaciones afirma que las investigaciones de las brechas de seguridad ahora llevan más tiempo, a pesar de que el 93 % había adquirido nuevas herramientas de detección y visibilidad. Un mayor número de herramientas sin una estrategia de unificación genera más ruido, no más claridad.
La identidad es el principal vectorcloud , y la federación es la razón. Cuando un proveedor de identidad central —Entra ID o un servicio de inicio de sesión único de terceros— se federa con AWS, Azure y GCP, una sola vulneración de ese proveedor de identidad puede dar lugar acloud . Una credencial o un token robado en un proveedor otorga acceso federado a otro, y para la consola de cada proveedor parece un evento independiente y sin relación. Esa es la brecha. Dos consolas ven dos inicios de sesión. Solo una capa que correlacione la actividad de identidad entre proveedores detecta un único ataque.
El estudio Cloud de Thales para 2025 señala que las identidades comprometidas están presentes en más del 70 % de cloud , y el 68 % de las organizaciones señala el robo de credenciales o de información confidencial como la táctica de ataque que más rápido está creciendo. ¿Por qué es tan difícil la gestión de identidades encloud ? Porque cada proveedor modela la identidad de forma diferente, es fácil excederse en el alcance de la confianza de federación y la proliferación de identidades —demasiadas cuentas, roles y concesiones repartidas por las nubes— hace que, para empezar, resulte difícil saber qué es lo normal.
El riesgo no es teórico. El aviso conjunto AA24-057A de la CISA y el NCSC-UK, publicado en febrero de 2024, documentó cómo agentes del SVR ruso (APT29) adaptaban sus tácticas para cloud inicial cloud : haciendo uso indebido de cuentas inactivas, robando tokens y ejerciendo presión sobre la autenticación multifactorial para acceder y mantenerse en cloud . Esas técnicas son la materia prima para un pivotecloud . La actividad actual confirma el patrón: una phishing de códigos de dispositivo OAuth de 2026 afectó a más de 340 organizaciones de Microsoft 365 y, dado que un token generado contra un proveedor de identidad central federado con AWS o GCP tienecloud , un solo token robado puede abrir el acceso a múltiples nubes. Es fundamental señalar que la autenticación multifactorial (MFA) no proporcionó protección alguna en esta campaña, y el token de actualización persistió después de que la víctima restableciera su contraseña (Cloud Alliance Labs; FBI IC3 PSA).
La respuesta defensiva es específica. Es mejor revocar los tokens de actualización en lugar de limitarse a restablecer las contraseñas, ya que el simple restablecimiento deja activo el token robado. Hay que considerar el flujo de códigos de dispositivo como un punto de control de acceso condicional y restringirlo o delimitar su alcance. Se debe supervisar la emisión de tokens y la reproducción de los mismos para detectar anomalías. entre distintos proveedores, no una cloud vez. En MITRE ATT&CK , elcloud se corresponde con T1550.001 (Token de acceso de la aplicación) para el movimiento lateral y T1606.002 (Tokens SAML) para el acceso mediante credenciales. Informes independientes han llegado a la misma conclusión: que la proliferación de identidades y el inicio de sesión único federado permiten quecloud pasen desapercibidas en las vistas de una única consola (InformationWeek).

Cerrar esta brecha es un problema de detección de identidades. Para obtener información sobre la disciplina de detección y respuesta ante ataques basados en identidades, consulte «detección y respuesta ante amenazas de identidad» (ITDR); para conocer los perfiles de comportamiento que señalan un inicio de sesión federado anómalo, consulte «análisis de identidades»; y para ver la taxonomía completa de técnicas, consulte MITRE ATT&CK.
Encloud, el cumplimiento normativo no es tanto una cuestión de seguir una lista de verificación como un problema de pruebas. Lo difícil es demostrar una cobertura de controles coherente entre los distintos proveedores, cada uno de los cuales genera pruebas nativas diferentes en distintos formatos. ¿Cómo afectancloud a las auditorías y los informes de cumplimiento normativo? Multiplican el trabajo: hay que demostrar cada control por separado para cada proveedor, a menos que se unifiquen las pruebas.
Así ocurre con el registro unificado más allá de la detección. Cuando la telemetría se centraliza en un único lugar, se puede realizar una prueba de control una sola vez y generar pruebas de auditoría entre proveedores a partir de una única fuente: «una prueba, múltiples cumplimientos». ¿Qué marco se utiliza con mayor frecuencia para el cumplimientocloud ? En la práctica, las organizaciones se basan en el Marco de Ciberseguridad del NIST y la norma ISO/IEC 27001:2022 como referencias, y los operadores de la UE añaden la NIS2.
Tabla: Tabla de correspondencias entrecloud y los principales marcos de trabajo.
Para los operadores de la UE y del Reino Unido, el plazo ya está en vigor. La Directiva NIS2 ya es plenamente aplicable y, según las directrices técnicas de implementación de la ENISA, el plazo para la primera auditoría se ha aplazado hasta el 30 de junio de 2026. Uncloud capaz de generar pruebas unificadas antes de esa fecha se encuentra en una posición mucho más sólida que uno que recopile manualmente los informes de cada proveedor por separado. Para una visión más amplia del programa, consulte el cumplimiento normativo y, para detalles específicos sobre la protección de datos, el cumplimiento del RGPD.
Mantener una pila independiente de detección gestionada, SIEM o NDR para cada punto de control resulta costoso y crea precisamente las brechas que aprovechan los atacantes. El proceso de consolidación es sencillo en teoría: hay que hacer un inventario de las herramientas de cada proveedor que se utilizan actualmente, identificar los solapamientos y consolidar las herramientas puntuales redundantes en una única capa de detección unificada. El resultado es un menor número de consolas, menos puntos ciegos y un menor coste total.
El argumento del coste y el de la seguridad son, en realidad, el mismo argumento. Según el estudio «El coste de una filtración de datos » del Ponemon Institute (informe de 2024), las filtraciones en entornos múltiples alcanzaron los 5,05 millones de dólares y se prolongaron durante 283 días —lo que se debe, en parte, a la visibilidad fragmentada que genera la proliferación de herramientas—. La consolidación acorta ese plazo, y ahí es donde se generan los ahorros. Por eso, el problema de la superposición de herramientas debe abordarse tanto en el contexto presupuestario como en el de la seguridad.
La protección de datos es una disciplina relacionada que merece un tratamiento específico, más allá de un simple párrafo aquí; para conocer los detalles sobre la seguridad cloud , consulta el recurso específico.
¿Qué hay que tener en cuenta en un enfoque modernocloud ? Las capacidades que realmente importan se corresponden directamente con las carencias mencionadas anteriormente:
Los compradores también esperarán funciones relacionadas con cloud : gestión del estado cloud (CSPM), protección cloud (CWPP) y gestión de derechos de acceso cloud (CIEM). Se trata de requisitos mínimos, y las definiciones de estas categorías se recogen en nuestra guía cloud y respuestacloud , por lo que no las redefiniremos aquí.
Varias tendencias están marcando los próximos 12 a 24 meses. La IA se sitúa ahora en ambos bandos de la contienda: por un lado, potencia phishing cada vez más convincentes y, por otro, ayuda a los defensores en la clasificación y la correlación de datos. La identidad ha pasado de ser un riesgo más entre muchos a convertirse en la principal vía de ataque, y las vulnerabilidades en este ámbito se mencionan en aproximadamente el 90 % de las investigaciones de respuesta a incidentes de 2025 (investigación de Unit 42). Y las vulnerabilidades del plano de control por proveedor siguen apareciendo a un ritmo constante; la revisión de mayo de 2026Zero Day catalogó una oleada de CVE críticas cloud de Azure, un recordatorio de que uncloud debe rastrear la exposición en el plano de control de todos los proveedores a la vez. Un Zero Trust —verificar explícitamente, aplicar el principio del privilegio mínimo— es la base arquitectónica que hace que el resto sea viable. Para ver un ejemplo de herramientas de detección nativas de un único proveedor, consulte la detección de amenazas de AWS; para la capa de carga de trabajo y contenedores, consulte la seguridad de Kubernetes.
Vectra AI de una premisa sencilla: la red moderna constituye una única superficie de ataque que abarca entornos locales,cloud, identidades y SaaS; por lo tanto, la resiliencia se basa en la observabilidad unificada, las señales de ataque impulsadas por IA y las medidas fundamentadas, en lugar de en otra consola específica de un proveedor. Bajo la filosofía «Assume Compromise», el objetivo no es afirmar que los atacantes nunca lograrán entrar, sino garantizar que, cuando se produzca uncloud federadocloud , Attack Signal Intelligence lo Attack Signal Intelligence como una historia de ataque correlacionada en lugar de dos eventos de consola inconexos, convirtiendo las alertas dispersas y aisladas por proveedor en una única señal sobre la que un equipo reducido pueda actuar.
cloud no consiste en reforzar la seguridad de cada proveedor de forma aislada. Se trata de subsanar las deficiencias entre los distintos proveedores: los modelos de identidad incoherentes, los registros fragmentados y la confianza en la federación que permite a un atacante desplazarse de una cloud otra mientras que cada consola solo ve una parte. Las organizaciones que gestionan bien cloud tratan a sus proveedores como una única superficie de ataque: normalizan la telemetría en un único modelo de detección, correlacionan la actividad de identidades entre las nubes y generan pruebas unificadas que satisfacen a los auditores de una sola vez, en lugar de tener que hacerlo proveedor por proveedor.
El problema subyacente —el uso indebidocloud — se está agravando, y la inversión en herramientas por sí sola no ha logrado subsanar esta brecha. El camino a seguir es la unificación: una visión global, una señal, una respuesta. Para descubrir cómo la detección unificada y basada en identidades permite visualizar uncloud como una única historia correlacionada, explore el enfoque Vectra AI en materia de cloud y respuesta cloud .
cloud protege a dos o más cloud pública —como AWS, Azure y Cloud que operan en paralelo, donde el riesgo principal es la brecha entre proveedores: una gestión de identidades y accesos (IAM) inconsistente, registros fragmentados y la confianza de federación que un atacante puede aprovechar para desplazarse entre las nubes. cloud híbrida protege la infraestructura local combinada con cloud, donde el enfoque se centra en la visibilidad este-oeste y el puente de identidades entre los directorios locales y los proveedores cloud . La distinción es importante porque determina a qué controles se da prioridad. Uncloud invierte en normalizar la telemetría y correlacionar las identidades entre proveedores; un programa híbrido invierte en supervisar la interfaz entre el centro de datos y la cloud. Para elcloud de lacloud , consulte nuestra guía de detección cloud híbrida.
La gestión de identidades resulta complicada encloud cada proveedor gestiona las identidades de forma diferente, y la confianza federada las vincula entre sí de maneras en las que es fácil perder la perspectiva. Cuando un proveedor de identidades central se federa con varias nubes, una sola vulneración puede afectar a todas ellas; sin embargo, la consola de cada proveedor solo muestra su propia parte de la actividad. La proliferación de identidades agrava el problema: a medida que las cuentas, los roles y las concesiones se multiplican entre los distintos proveedores, resulta difícil establecer qué se considera normal, lo que hace que las anomalías sean más difíciles de detectar. Las identidades comprometidas están implicadas en más del 70 % de cloud , según el estudio «2025 Cloud Study» de Thales. La solución práctica consiste en correlacionar la actividad de las identidades entre los distintos proveedores y supervisar la emisión y la repetición de tokens, en lugar de confiar en la visión aislada cloud una sola cloud.
La mayoría de las organizaciones basancloud en el Marco de Ciberseguridad 2.0 del NIST y la norma ISO/IEC 27001:2022 —concretamente en el control A.5.23, que abarca la seguridad de la información en el uso de cloud — como sus referencias. Los operadores de la UE añaden la Directiva NIS2, cuyas medidas de gestión de riesgos del artículo 21 se aplican a todo el entorno, mientras que el RGPD regula la residencia de los datos. En lugar de tratar cada marco como una lista de verificación independiente, el enfoque más sostenible consiste en mapear los controles una sola vez y generar pruebas de auditoría válidas para todos los proveedores a partir de un registro unificado —una postura de «probar una vez, cumplir en muchos». De este modo, un único conjunto de pruebas normalizadas demuestra el control en todos los proveedores, en lugar de recopilar pruebas separadas por cloud. Consulte nuestra descripción general del cumplimiento para obtener una visión más amplia del programa.
La función más útil de la IA encloud es la clasificación y la correlación. La detección asistida por IA integra señales de diferentes proveedores, agrupa eventos relacionados en un único incidente y reduce el ruido de las alertas que abruma a los equipos pequeños —lo cual es especialmente importante cuando uncloud se manifestaría, de otro modo, como eventos dispersos y sin relación entre sí en las consolas—. La IA también ayuda a establecer patrones de comportamiento de referencia para que un inicio de sesión federado anómalo destaque. La advertencia sincera es que los atacantes también utilizan la IA, generando phishing más convincentes y acelerando el desarrollo de sus herramientas. Por lo tanto, la IA no es una solución milagrosa; es un multiplicador de fuerzas para los defensores que debe combinarse con una visibilidad unificada y una detección centrada en la identidad para aportar valor, en lugar de solo más ruido automatizado.
La seguridad sin agentes recopila datos sobre el estado de seguridad y los registros a través de las API de cada proveedor, en lugar de instalar un agente de software en cada host o carga de trabajo. Se conecta al plano cloud , lee los datos de configuración y auditoría, y evalúa el estado de seguridad en todo el entorno sin la sobrecarga que supone el despliegue de agentes en cada host. Encloud, el atractivo radica en la amplitud: un enfoque sin agentes puede abarcar a todos los proveedores de forma rápida y uniforme, lo cual resulta valioso cuando se trata de supervisar dos o más nubes a la vez. Muchos programas combinan la cobertura sin agentes para obtener una amplia visibilidad con telemetría de tiempo de ejecución específica cuando se necesita una detección más profunda y en tiempo real de las cargas de trabajo, equilibrando así el alcance con la profundidad.
Una solucióncloud debe contar con cinco capacidades fundamentales. En primer lugar,cloud unificadacloud , de modo que cada proveedor aporte una visión global en lugar de consolas independientes. En segundo lugar, una detección centrada en la identidad, ya que la identidad federada es la principal víacloud . En tercer lugar, una ingesta consolidada de datos de SIEM, XDR y NDR que normalice la telemetría de cada proveedor en un único modelo de detección. En cuarto lugar, una aplicación coherente de las políticas y pruebas de cumplimiento entre los distintos proveedores. En quinto lugar, una clasificación asistida por IA para correlacionarcloud y reducir el ruido de las alertas. Se espera que las herramientas de estado de seguridad —CSPM, CWPP y CIEM— sean la base, pero el factor diferenciador es la capacidad de correlacionar la actividad entre los distintos proveedores, de modo que uncloud se interprete como una sola historia. Para las definiciones de la categoría de estado de seguridad, véase cloud y respuesta cloud .