El ámbito de aplicación de Purview se limita a M365. Sus datos, no.

Si entra en casi cualquier empresa del segmento medio, encontrará la misma configuración de seguridad: Microsoft 365 con cierto nivel de cobertura de Purview, quizá Defender, y una casilla marcada junto a «protección de datos» en el último cuestionario de auditoría. 

A continuación, fíjese en la huella real del SaaS. 

Confluence. Salesforce. Box. GitHub. Jira. Slack. Workday. Notion. Zendesk. DocuSign. Asana. Un puñado de herramientas departamentales que nadie en el departamento de TI recuerda haber aprobado. 

Ahí es donde realmente residen ahora los datos confidenciales. Y, para la mayoría de los equipos de seguridad de las medianas empresas, es un agujero negro. 

Lo que cubre realmente Purview 

Purview es una herramienta razonable para lo que es: una capa de gobernanza de datos y DLP para Microsoft 365. Si dispone del nivel de licencia adecuado —normalmente E5 o el complemento independiente de cumplimiento normativo—, puede clasificar datos en SharePoint, OneDrive, Exchange y Teams. Puede redactar políticas de DLP. Puede ver cómo se propagan algunas etiquetas de confidencialidad. 

Purview no cubre su canal de ventas de Salesforce. No puede indicarle quién tiene acceso permanente a la carpeta de Box donde el departamento de finanzas almacena las previsiones trimestrales. No detecta la herramienta de RR. HH., la de selección de personal, la de asistencia técnica ni la docena de lugares adicionales en los que residen datos confidenciales. 

Si sus datos solo residieran en Microsoft, esto no supondría ningún problema. Sus datos no se encuentran únicamente en Microsoft 365. 

La pila tecnológica real del mercado medio 

Una empresa típica de entre 500 y 3.000 empleados utiliza entre 50 y 200 aplicaciones SaaS. Una parte significativa de ellas contiene datos confidenciales: información personal identificable (PII) de clientes, datos financieros, código fuente, registros de RR. HH., información sanitaria, contratos y credenciales. 

La mayor parte de esos datos: 

• Compartidos de forma generalizada por defecto (las aplicaciones SaaS están optimizadas para la colaboración, no para el principio de privilegios mínimos) 
• Accesibles a muchas más personas de lo que nadie imagina 
• Invisible para las herramientas de seguridad con las que ya cuenta la empresa 
• Aumenta en volumen y sensibilidad cada trimestre 

Nadie lo había previsto. Ocurrió porque los equipos de negocio adquirieron herramientas a un ritmo más rápido del que la seguridad podía inventariarlas, y porque la gestión de los servicios SaaS ajenos a Microsoft siempre ha sido un problema ajeno. 

Por qué el DSPM existente no resuelve el problema 

La respuesta obvia es el DSPM. Estas plataformas existen específicamente para detectar, clasificar y gestionar datos en entornos SaaS, IaaS y almacenes no estructurados. 

He aquí el problema: ninguna de ellas se diseñó para el mercado medio. 

Se diseñaron para compradores de empresas de la lista Fortune 500 con presupuestos de seis cifras, equipos dedicados a la seguridad de los datos y margen suficiente para llevar a cabo implementaciones prolongadas. Si le pide a una empresa de 400 empleados que implemente un proveedor de DSPM empresarial, lo normal es que obtenga tres reacciones en este orden: el presupuesto, el silencio y un «no» cortés. 

Las barreras concretas: 

• Coste. La mayoría de las plataformas DSPM tienen un coste anual que parte de la mitad de las seis cifras. Para los presupuestos de seguridad del mercado medio, eso supone la totalidad de la partida destinada a herramientas. 
• Complejidad de la implementación. Cada aplicación SaaS requiere una integración, cada integración necesita credenciales y ámbitos, y cada ámbito requiere una revisión de seguridad. Un equipo reducido no puede dedicar un trimestre a configurar conectores. 
• Gastos generales operativos. El DSPM genera hallazgos. Los hallazgos requieren una clasificación. La clasificación requiere analistas. Los equipos de las medianas empresas no cuentan con analistas: disponen de un único responsable de seguridad que también se encarga de la gestión de identidades y accesos (IAM), aplica parches a los servidores y dirige el programa de formación sobre phishing.&
• Sesgo empresarial integrado en el producto. La interfaz de usuario da por hecho que cuenta con un analista de seguridad de datos que la interprete. Las políticas dan por hecho que se dispone de un equipo para ajustarlas. Las alertas dan por hecho que alguien tiene tiempo para investigarlas. 

El resultado: las empresas del mercado medio o bien pagan por herramientas empresariales que no pueden poner en práctica, o bien prescinden de ellas y se limitan a esperar lo mejor. 

El riesgo no es teórico 

He observado este patrón en repetidas ocasiones: 

• Un colaborador externo sigue teniendo acceso a Salesforce 90 días después de su baja porque nadie se encarga de la lista de comprobación de retirada de acceso para aplicaciones que no son de IdP. 
• Un ingeniero exporta una lista de clientes desde HubSpot a su Google Drive personal «solo para trabajar sin conexión». 
• Un comercial que abandona la empresa descarga tres años de datos de cuentas de Gong antes de su último día. 
• Una carpeta de Box mal configurada que contiene pruebas de SOC 2 se comparte con «cualquier persona que tenga el enlace» durante 14 meses. 

Ninguno de estos casos saldría a la luz en Purview. Ninguno saldría a la luz en un SIEM sin un trabajo personalizado que nadie tiene tiempo de realizar. Y la mayoría tampoco saldría a la luz en los DSPM existentes, ya que el cliente no podía permitirse implementarlo para esa aplicación SaaS en primer lugar. 

No se trata de ataques hipotéticos. Son los incidentes reales con los que las empresas del mercado medio lidian en silencio: aquellos que aparecen en un análisis a posteriori en lugar de en un panel de control. 

Por qué sigue sin resolverse 

La brecha persiste porque la economía no cuadra en el modelo tradicional de DSPM. Crear un escáner para cada aplicación SaaS, mantener conectores, gestionar los límites de tasa de las API y clasificar datos a gran escala supone una ingeniería costosa, y los proveedores fijan sus precios en consecuencia. Los compradores del mercado medio quedan excluidos por los precios, y los proveedores se orientan hacia el segmento de gama alta para conseguir contratos más importantes. El ciclo continúa. 

Mientras tanto, la presencia del SaaS sigue creciendo. Cada nueva herramienta departamental, cada adquisición, cada compra del tipo «solo necesitamos esto para el equipo» añade otro foco de datos confidenciales que nadie supervisa. La brecha no se está cerrando. Se está ampliando. 

Los equipos de seguridad del mercado medio lo saben. No son ingenuos. Se encuentran atrapados entre herramientas con precios pensados para otros y un problema que no deja de empeorar. La mayoría se ha resignado a ello, del mismo modo que uno se resigna ante cualquier riesgo que no puede permitirse solucionar: lo documentan, esperan lo mejor y siguen adelante. 

Esa es la realidad de la gestión de la seguridad de los datos fuera de Microsoft 365 para la mayor parte del mercado medio. No está resuelta. Ni mucho menos.  Y no es algo que Purview vaya a solucionar.