¿Qué es Managed CNAPP?
Managed CNAPP es un modelo de servicio en el que un proveedor opera su plataforma de protección de aplicaciones nativas de la nube (CNAPP) y sus operaciones de seguridad en su nombre. La plataforma sigue siendo suya. También la responsabilidad. Lo que cambia es quién cubre la vigilancia.
El nivel exigido para esa vigilancia ahora está establecido en la política federal. En diciembre de 2024, la Binding Operational Directive 25-01 de CISA ordenó a las agencias civiles federales identificar y corregir configuraciones erróneas en la nube y ejecutar monitoreo continuo en todos sus tenants de nube, después de que controles mal configurados dieran a los atacantes una vía para la exfiltración de datos. Continuo es la palabra clave. Mantener ese nivel de cobertura en cada cuenta que opera es una tarea que pocos equipos reducidos pueden cubrir las 24 horas, y esa brecha es precisamente la que el modelo gestionado existe para cerrar.
Cómo se relaciona Managed CNAPP con la ciberseguridad
La seguridad nativa de la nube abarca configuración, identidad, cargas de trabajo y Kubernetes, y cada capa genera hallazgos las 24 horas.
Una CNAPP reúne esas capas en una sola plataforma. El modelo gestionado añade un equipo operativo detrás de ella, para que la cobertura se mantenga durante la noche y los fines de semana, cuando un bucket de almacenamiento expuesto o un rol con permisos excesivos es tan accesible para un atacante como al mediodía. El proveedor ejecuta las operaciones y, conforme al modelo de responsabilidad compartida, su organización sigue siendo responsable de su postura de seguridad en la nube y del cumplimiento normativo.
Componentes principales de un servicio Managed CNAPP
Un servicio Managed CNAPP tiene dos capas: la plataforma que genera los hallazgos y las personas y procesos que actúan sobre ellos.
Qué cubre la CNAPP subyacente
La plataforma consolida cuatro capacidades, cada una una capa que el proveedor gestionado opera para que su equipo lea el riesgo en la nube en un solo lugar, desde la compilación hasta el runtime:
- Cloud security posture management (CSPM) identifica configuraciones erróneas e infracciones de cumplimiento en toda la infraestructura en la nube, desde buckets de almacenamiento abiertos hasta reglas de firewall permisivas.
- Cloud workload protection (CWP) protege contenedores, máquinas virtuales, funciones serverless y servidores en runtime en entornos públicos, privados e híbridos.
- Cloud infrastructure entitlement management (CIEM) analiza permisos para identidades humanas y no humanas, señalando privilegios excesivos y aplicando políticas de mínimo privilegio.
- Kubernetes security posture management (KSPM) ejecuta comprobaciones de configuración errónea en clústeres de Kubernetes y valida la alineación con el cumplimiento.
En conjunto, responden a cuatro preguntas concretas sobre su nube: qué configuraciones y controles de cumplimiento han derivado (CSPM), qué cargas de trabajo en ejecución están bajo ataque (CWP), qué identidades humanas y no humanas tienen más acceso del que necesitan (CIEM) y qué clústeres de Kubernetes están mal configurados (KSPM).
La plataforma informa continuamente estos hallazgos, pero no los clasifica, no los prioriza por explotabilidad ni los asigna a un responsable. Ese es el trabajo que asume el servicio gestionado.
Qué añade el servicio gestionado
Además de la plataforma licenciada, el proveedor aporta una capa operativa con personal que la ejecuta en el día a día:
| Capa operativa | Qué hace el proveedor |
| Gestión continua de la postura | Supervisa configuraciones y cumplimiento a medida que la infraestructura deriva en las cuentas conectadas. |
| Remediación de configuraciones erróneas | Identifica y prioriza problemas, los asigna al equipo responsable y les da seguimiento hasta su cierre. |
| Gestión de vulnerabilidades y derechos | Escaneo sin agente en sistemas operativos y cargas de trabajo, con análisis CIEM de identidades con privilegios excesivos. |
| Respuesta a amenazas en runtime | Protección basada en agente o sensor que supervisa cargas de trabajo y detiene ataques activos durante la ejecución. |
| Cobertura de analistas | Triaje, filtrado de falsos positivos, escalado de hallazgos confirmados e informes con una cadencia establecida. |
El personal del proveedor y las horas de cobertura definidas son lo que el servicio añade a una plataforma que, de otro modo, podría operar por su cuenta. Si operarla por su cuenta es la decisión correcta es la siguiente pregunta.
Cómo funciona Managed CNAPP
El servicio Managed CNAPP funciona como un ciclo continuo en seis fases. El proveedor es responsable de los pasos operativos. Su equipo entra en el ciclo cuando un hallazgo se convierte en trabajo sobre el que debe actuar, para que sepa exactamente dónde vuelve a recaer la responsabilidad en usted.
- Incorporación e integración. El proveedor se conecta a sus cuentas en la nube en AWS, Azure, GCP y cualquier otro proveedor que utilice. El despliegue completo en todas las cuentas, incluidas las cuentas de desarrolladores, establece la línea base antes de que comience el ajuste.
- Escaneo sin agente y cobertura en runtime. El proveedor activa dos capas de visibilidad. El escaneo sin agente consulta las API del proveedor de nube para evaluar configuraciones, derechos y vulnerabilidades sin instalar software en las cargas de trabajo. La cobertura basada en agente o sensor añade protección en runtime en tiempo real para clústeres de Kubernetes y cargas de trabajo en contenedores o máquinas virtuales (VM).
- Monitoreo continuo. El escaneo se ejecuta de forma continua para que las nuevas cuentas, cargas de trabajo y cambios de configuración entren en cobertura a medida que aparecen. La visión de postura y vulnerabilidades se mantiene actualizada entre puntos de control.
- Triaje y priorización de alertas. El proveedor filtra falsos positivos y clasifica los hallazgos confirmados por explotabilidad y exposición, reflejando el impacto empresarial en la clasificación.
- Remediación y transferencia a respuesta a incidentes. El proveedor asigna los hallazgos priorizados al equipo responsable con el contexto necesario para actuar. El proveedor es responsable de la detección, el triaje y la asignación. Su equipo es responsable de ejecutar la remediación.
- Informes. El proveedor entrega informes con una cadencia definida, con métricas de seguridad vinculadas a resultados de negocio.
El ciclo nunca se detiene. La única pregunta es quién debe ejecutarlo: su propio equipo o un proveedor.
Cuándo externalizar las operaciones de seguridad nativa de la nube
La elección entre ejecutar las operaciones de CNAPP internamente o entregarlas a un proveedor depende del personal de su equipo, su experiencia, sus requisitos de cobertura y sus necesidades de control.
| Condición | Favorece la externalización | Favorece la gestión interna |
| Personal de seguridad en la nube | Equipo reducido con personal dedicado limitado a seguridad en la nube | SOC maduro con ingenieros de seguridad en la nube dedicados |
| Horas de cobertura | Se necesita cobertura continua; el equipo actual solo cubre horario laboral | Ya existe un modelo follow-the-sun o por turnos con personal asignado |
| Tiempo hasta obtener valor | Necesidad de cobertura operativa rápidamente | Hay tiempo para construir y ajustar internamente |
| Complejidad multicloud | Múltiples proveedores de nube, proliferación de cuentas entre unidades de negocio | Entorno de nube única o de doble nube estrechamente controlado |
| Experiencia nativa de la nube | El equipo es sólido on-premises, con profundidad limitada en Kubernetes, contenedores o IAM | Amplia experiencia existente en operaciones de CSPM, CWPP y CIEM |
| Requisitos de control | Disposición a definir un límite de responsabilidad compartida con un proveedor | Mandatos estrictos de residencia de datos, restricciones regulatorias sobre acceso de terceros o políticas contra la externalización de operaciones de seguridad |
| Madurez de herramientas | CNAPP adquirido recientemente o aún no operacionalizado | CNAPP completamente desplegado y ajustado, con el equipo operándolo eficazmente |
Tres modelos de servicio se sitúan a lo largo del espectro de externalización:
- CNAPP autogestionado significa que usted licencia la plataforma y la opera internamente. Sus analistas cubren el monitoreo, ajustan los hallazgos, realizan el triaje de alertas y dirigen la remediación.
- CNAPP cogestionado significa que el proveedor aporta la plataforma y la experiencia operativa, encargándose de la incorporación, el ajuste, la priorización de alertas y el soporte de escalado. Usted conserva la propiedad principal de la investigación y de las decisiones de remediación.
- CNAPP totalmente gestionado significa que el proveedor asume la responsabilidad operativa del monitoreo, el triaje, la investigación y la coordinación de la remediación. Usted conserva la autoridad de gobernanza y la ejecución de la remediación sobre los hallazgos asignados.
Su posición en este espectro determina por qué está pagando y qué sigue siendo suyo. La siguiente pregunta es si un proveedor determinado puede ofrecerlo en todo su entorno de nube.
Qué evaluar en un proveedor de Managed CNAPP
Un proveedor de CNAPP gestionado se evalúa en dos categorías: los compromisos de nivel de servicio que rigen la relación y la integración técnica que determina si puede cubrir su entorno de nube.
Consideraciones sobre SLA
Un acuerdo de nivel de servicio (SLA) medible define compromisos específicos y acotados en el tiempo. Uno vago promete "respuesta rápida" sin decir qué significa rápido. El análisis de MITRE sobre los SLA de nube encontró una variación considerable en cómo se definen los niveles de rendimiento y cómo se comparte el riesgo entre proveedor y consumidor. Lea las definiciones, no los adjetivos.
Cuando evalúe SLA, céntrese en los compromisos que se corresponden con el riesgo operativo:
- Tiempo de respuesta para hallazgos confirmados y el modelo de escalado de guardia
- Horas de cobertura y tiempo de respuesta del triaje de alertas
- Tasa de gestión de falsos positivos y velocidad de asignación para remediación
- Cadencia de informes
Exija SLA contractualmente vinculantes. Confirme si el proveedor informa de forma transparente sobre el rendimiento frente a los SLA y qué ocurre cuando no se cumplen.
Requisitos de integración multicloud
Su proveedor debe conectarse a todos los entornos de nube que usted opera. Evalúe la incorporación sin agente: con qué rapidez puede el proveedor conectarse a sus cuentas de AWS, Azure y GCP y comenzar a escanear. Confirme si la cobertura se extiende a cualquier proveedor de nube adicional que utilice. Singularity™ Cloud de SentinelOne, por ejemplo, cubre AWS, Azure, GCP, Oracle Cloud Infrastructure (OCI) y Alibaba Cloud desde una sola consola.
Evalúe la cobertura de contenedores y Kubernetes: ¿la CNAPP subyacente del proveedor cubre sus clústeres de Kubernetes, registros de contenedores y funciones serverless? Verifique qué datos salen de su entorno, dónde se almacenan y si la arquitectura del proveedor cumple sus requisitos regulatorios.
CIEM debe cubrir la evaluación y remediación de configuraciones erróneas en políticas de gestión de identidades y accesos (IAM).
Desafíos y limitaciones de Managed CNAPP
Externalizar las operaciones de seguridad nativa de la nube introduce restricciones estructurales que persisten incluso cuando la relación está bien gestionada.
- Menor visibilidad directa. Un proveedor que opera su CNAPP se sitúa entre su equipo y los hallazgos sin procesar. El Software Engineering Institute (SEI) de Carnegie Mellon documenta este riesgo en la externalización de la nube: las organizaciones pierden visibilidad y control sobre los activos y operaciones que delegan, y recuperarlos requiere monitoreo y análisis que antes proporcionaban los registros de red on-premises.
- Ambigüedad en el límite de responsabilidad. El modelo de responsabilidad compartida se aplica aquí: el proveedor gestionado opera dentro de su capa de responsabilidad, y su organización sigue siendo responsable ante el proveedor de nube y los reguladores.
- Dependencia del proveedor y lock-in. Los formatos de datos no estándar, las API propietarias y la dependencia de herramientas específicas del proveedor hacen que el coste y el esfuerzo de cambiar de proveedor sean mayores de lo esperado inicialmente.
- El proveedor como riesgo de la cadena de suministro. Conceder a un tercero acceso operativo a su entorno de nube es en sí mismo un riesgo que debe gestionarse. El NCSC del Reino Unido señala que el acceso de terceros no controlado y no observado es un anti-pattern: si externaliza funciones administrativas u operativas, depende de otra organización para mantener seguro su sistema. Restrinja ese acceso. Defina límites de alcance, supervise la actividad del proveedor y revise de forma continua su personal, procesos y tecnología.
- Latencia en la transferencia de alerta a acción. Todo hallazgo que requiere la acción de su equipo pasa por el proceso de triaje y asignación del proveedor. Esa transferencia puede retrasar la remediación.
- Retraso de cobertura en entornos que cambian rápidamente. Nuevas cuentas y cargas de trabajo o servicios aparecen entre ciclos de incorporación, y la cobertura del proveedor refleja el entorno tal como estaba configurado en el último punto de control de integración.
Cada uno de estos es un modo de fallo conocido. Los modos de fallo conocidos pueden diseñarse. Las prácticas siguientes los cierran antes de que le cuesten algo.
Prácticas recomendadas para Managed CNAPP
Las relaciones que se sostienen comparten algunos hábitos operativos. Cada unocierra un modo de fallo que, de otro modo, frena el trabajo de seguridad externalizado.
Defina por escrito el límite de responsabilidad compartida antes de que el proveedor asigne un solo hallazgo. Cuando la propiedad del cierre no se asigna por clase de hallazgo, los resultados quedan sin resolver mientras cada parte asume que la otra se encarga. Esa misma claridad protege su propia responsabilidad: el proveedor ejecuta las operaciones y su organización sigue siendo propietaria de su postura de seguridad en la nube, del cumplimiento normativo y de la ejecución de la remediación.
Integre al proveedor en los flujos de trabajo que ya utiliza. Asigne cada tipo de escalado a un responsable interno dentro de sus runbooks de IR existentes para que los hallazgos del proveedor lleguen como trabajo de respuesta estructurado que encaje en su proceso.
Mantenga también su propio acceso a la consola de CNAPP y a los resultados de informes del proveedor, para que pueda validar de forma independiente el rendimiento del proveedor frente a sus propias cifras. Gestione el resto de la relación con base en cifras que revise con una cadencia establecida:
- Haga seguimiento de los SLA contratados y revíselos según un calendario definido. Un SLA que nadie mide no tiene peso operativo.
- Vincule los informes a resultados de negocio para que cada revisión conecte las métricas de seguridad con el trabajo que protegen.
- Realice auditorías de cobertura sobre su entorno activo, incluidas cuentas de desarrolladores, entornos de staging y cuentas de nube aprovisionadas recientemente.
Seleccionar por precio antes que por cobertura es un atajo costoso: un proveedor de menor coste que solo vigila parte de su entorno deja el resto sin monitoreo.
Guía del comprador de la CNAPP
Aprenda todo lo que necesita saber para encontrar la plataforma de protección de aplicaciones nativas de la nube adecuada para su organización.
Guía de lecturaMejore Managed CNAPP con SentinelOne
Singularity Cloud Security es la CNAPP de SentinelOne. Funciona desde el tiempo de compilación hasta el runtime con gestión de postura sin agente y protección de cargas de trabajo en tiempo real en cuentas de nube, contenedores, Kubernetes, servicios de IA y serverless. Una consola cubre AWS, Azure, GCP, OCI y Alibaba Cloud desde una sola consola.
La capa sin agente, Singularity Cloud Native Security, confirma qué hallazgos son realmente explotables mediante Verified Exploit Paths, para que un proveedor asigne los hallazgos de alto valor al responsable correcto y dedique menos tiempo al ruido. En runtime, las acciones de respuesta automáticas, incluidas la finalización de procesos, el aislamiento de red, la cuarentena de archivos y la desconexión de pods, contienen incidentes antes de que intervenga un analista. La Singularity Platform unifica la telemetría de endpoint, nube e identidad en un solo agente, consola y data lake. Registró un 88% menos de alertas en las Evaluaciones MITRE ATT&CK® 2024 con un 100% de identificación.
Con Purple AI™, la búsqueda de amenazas en lenguaje natural y la investigación agentic reducen el tiempo que los analistas dedican a recopilar evidencias. La instantánea de IDC de abril de 2025 le atribuye una identificación de amenazas un 63% más rápida y una remediación un 55% más rápida. Un proveedor puede ejecutar todo esto en su nombre. Un equipo interno reducido puede operarlo directamente.
Reserve una demo de SentinelOne para ver qué carga elimina Singularity Cloud del trabajo de su equipo.
Demostración de seguridad en la nube
Descubra cómo la seguridad en la nube basada en IA puede proteger su organización en una demostración individual con un experto en productos SentinelOne.
DemostraciónConclusiones clave
Managed CNAPP transfiere la carga operativa de ejecutar una plataforma de protección de aplicaciones nativas de la nube a un proveedor que cubre el monitoreo, el triaje y la asignación para remediación en su nombre. La decisión de externalizar depende del personal de su equipo, de sus necesidades de cobertura y de la complejidad de su entorno de nube.
Las relaciones exitosas se apoyan en un límite de responsabilidad claramente definido, SLA medibles, integración en sus flujos de respuesta a incidentes y validación continua de la cobertura. Si acierta en esos cuatro puntos, la externalización deja de ser una pérdida de control. Usted define el límite, mantiene la gobernanza y deja de ser quien clasifica alertas a las 3 a. m.
Preguntas frecuentes
Managed CNAPP es un modelo de servicio en el que un proveedor opera una plataforma de protección de aplicaciones nativas de la nube en su nombre. El proveedor se encarga de la gestión continua de la postura, la remediación de configuraciones incorrectas, el triaje de alertas y la respuesta a amenazas en tiempo de ejecución en todos sus entornos en la nube.
Usted conserva la autoridad de gobernanza sobre las decisiones de escalamiento y la responsabilidad de la ejecución de la remediación. El modelo transfiere la carga operativa de ejecutar el CNAPP, incluida la dotación de personal de analistas y el trabajo continuo de ajuste de hallazgos, a especialistas externos en seguridad en la nube.
El precio normalmente sigue el tamaño del entorno cubierto: el número de cuentas cloud conectadas, cargas de trabajo protegidas o activos analizados, a menudo en una suscripción por niveles.
Las horas de cobertura y la profundidad del servicio también influyen en la cifra, ya que la cobertura continua y la investigación completa cuestan más que el triaje en horario laboral. Pida a un proveedor que relacione el precio con las cuentas y cargas de trabajo específicas que supervisará, para que la cotización refleje su entorno real.
La conexión sin agente a las cuentas en la nube mediante las API del proveedor habilita la visibilidad de la postura y los permisos en cuestión de horas, ya que no se instala software en las cargas de trabajo. La cobertura en tiempo de ejecución para Kubernetes y las cargas de trabajo de contenedores o VM añade un despliegue de agente o sensor.
El trabajo más prolongado es el ajuste: filtrar falsos positivos y asignar las escalaciones a sus responsables, lo que se estabiliza durante las primeras semanas. La cobertura completa depende de conectar todas las cuentas, incluidos los entornos de desarrollo y de ensayo.
Los proveedores de Managed CNAPP se conectan a cada entorno cloud mediante las API del proveedor cloud. El proveedor de Managed CNAPP mantiene una vista unificada de la postura, los derechos y la protección de cargas de trabajo en todas las cuentas conectadas.
El análisis de CIEM abarca modelos de identidad entre proveedores y señala límites de confianza incoherentes y permisos excesivos. Las auditorías de cobertura deben ejecutarse regularmente para confirmar que el alcance de supervisión del proveedor mantiene el ritmo de las nuevas cuentas y cargas de trabajo en todas las regiones.
No. Un proveedor de CNAPP gestionado ejecuta la operación diaria de su plataforma de protección de aplicaciones nativas de la nube, incluida la supervisión, el triaje y el enrutamiento de hallazgos, mientras que su organización mantiene la autoridad de gobernanza y es responsable de la ejecución de la remediación. Usted sigue siendo responsable de su seguridad en la nube y del cumplimiento normativo.
El modelo añade capacidad operativa y experiencia en entornos nativos de la nube a un equipo reducido, y mantiene la responsabilidad de los resultados de seguridad dentro de su organización.
