El DSPM existe porque los datos confidenciales ya no permanecen estáticos.
Más allá de la base de datos, los datos confidenciales se encuentran en registros, colas, herramientas SaaS, sistemas de asistencia técnica, flujos de análisis, almacenes de datos, copias de seguridad y, ahora, en indicaciones de IA y almacenes vectoriales. Se mueven porque la aplicación los mueve. La dirección de correo electrónico de un cliente puede comenzar en un formulario de registro, pasar por una API, escribirse en Postgres, aparecer en un registro de la aplicación, copiarse en Snowflake, fluir hacia una herramienta de soporte, enviarse a Stripe y, posteriormente, quizá incorporarse a un flujo de trabajo de IA. Y esto se considera un flujo de trabajo bastante normal.
Así pues, cuando se habla de DSPM, o gestión de la postura de seguridad de los datos, la idea básica es bastante sencilla: ayudar a los equipos a comprender dónde se encuentran los datos confidenciales, de qué tipo son, quién o qué puede acceder a ellos, cómo están protegidos y dónde pueden quedar expuestos.
La mayoría de las empresas no disponen de un mapa completo de dónde se almacenan los datos confidenciales. Saben que tienen datos de clientes, datos de pago, tokens, datos de empleados y, ahora, todo tipo de contexto relacionado con la inteligencia artificial. Lo que no siempre saben es dónde han acabado todos esos datos, quién tiene acceso a ellos o si se están gestionando de una forma que se ajuste a sus expectativas en materia de seguridad y cumplimiento normativo.
La visibilidad es el problema que el DSPM tradicional intenta resolver.
El DSPM tradicional comienza en el punto en el que se reciben los datos
La gestión tradicional de datos y información (DSPM) suele comenzar por el inventario de datos. Esto implica, por lo general, realizar un análisis de los sistemas de almacenamiento y las plataformas conectadas: buckets de S3, bases de datos, almacenes de datos, aplicaciones SaaS y copias de seguridad.
La herramienta busca datos confidenciales, los clasifica, comprueba los permisos y el nivel de exposición, y ayuda al equipo de seguridad a priorizar lo que realmente importa. Por ejemplo, podría indicarte que un bucket de S3 contiene información de identificación personal (PII). O que una tabla de un almacén de datos contiene datos relacionados con pagos. O que el acceso a un recurso compartido de archivos es demasiado amplio. O que una copia de seguridad contiene registros de clientes de producción almacenados en un lugar que nadie ha consultado en un año.
Es evidente que eso resulta útil. En los entornos actuales circulan muchos datos confidenciales, y gran parte de ellos se copian, replican, exportan, registran, sincronizan, archivan y acaban cayendo en el olvido. La gestión tradicional de datos, sistemas y políticas (DSPM) ayuda a los equipos a localizarlos. Proporciona al equipo de seguridad una visión más completa del patrimonio de datos real, más allá de los recursos en la nube que lo rodean.
Pero para los desarrolladores y AppSec , eso suele ser solo la segunda parte de la historia.
La primera parte trata de cómo llegaron los datos hasta allí.
Lo que falta es la ruta de código
Una herramienta tradicional de DSPM podría indicar: «Se ha detectado información de carácter personal (PII) en este almacén de registros».
Pero el desarrollador aún tiene que averiguar por qué aparece esa información de carácter personal, qué parte de la aplicación la ha introducido, si ha sido intencionado y qué cambio permitiría solucionarlo realmente. Y para ello hay que revisar el código.
La aplicación recopiló los datos, los procesó y decidió qué campos devolver desde una API. A continuación, registró el cuerpo de la solicitud, envió un token a un trabajador, remitió los metadatos del cliente a un proveedor y elaboró la indicación que incluía información confidencial.
Por lo tanto, la pregunta más propia de un desarrollador debería ir más allá de «¿Dónde se almacenan los datos confidenciales?» y ser más bien del tipo «¿Qué ruta de código ha provocado la exposición?». Esa es la versión «shift-left» del DSPM.
El DSPM basado en código parte de la aplicación, en lugar de la capa de almacenamiento. Analiza las API, los modelos ORM, las llamadas de registro, los consumidores de colas, los flujos de trabajo de CI/CD, las integraciones de IA y mucho más. El objetivo es comprender cómo entran los datos sensibles en el sistema, cómo se mueven, dónde se almacenan, por dónde salen y dónde pueden ser objeto de un manejo inadecuado.
Auditorías de DSPM basadas en código y de exposición de datos
En Aikido, creo que la forma más clara de describir nuestro DSPM basado en código es definirlo como una «auditoría de exposición de datos», que consiste en utilizar la inteligencia artificial para detectar flujos de datos sensibles y riesgos de seguridad en el código.
Una auditoría de exposición de datos es diferente. Analiza el código y examina cómo fluyen los datos sensibles a través de esta aplicación y dónde ese flujo genera riesgos. Abarca la información de identificación personal (PII), la información médica protegida (PHI), los datos sujetos a la normativa PCI, los secretos, los tokens, el contenido de los clientes y el tratamiento de datos relacionados con la inteligencia artificial. Cada resultado va acompañado de pruebas y de una solución en el código, sin necesidad de conectarse directamente a los almacenes de datos.
Al revisar el código también se pueden detectar deficiencias en la protección de datos. Se pueden detectar campos confidenciales almacenados sin cifrado, una clave codificada directamente en el código fuente, el uso de MD5, SHA1 o base64 como si se tratara de un método de cifrado, un secreto almacenado en el repositorio y datos confidenciales enviados a través de un canal no seguro.
Hay otra forma de plantearlo. El DSPM tradicional necesita acceder a tus datos reales, conectándose a buckets de S3, bases de datos y almacenes de datos para analizar su contenido. En cambio, el DSPM basado en código lee el código que crea y mueve esos datos, por lo que nunca solicita acceso ni descarga nada. La lectura a partir del código reduce las dificultades para activarlo, ya que no hay que conceder ningún nuevo acceso de producción.
Eso también lo hace más rápido, ya que no hay que rastrear nada. Además, es más preciso, ya que analiza cómo se utiliza un campo en lugar de dar por sentado que cualquier número de nueve dígitos es un número de la Seguridad Social. El resultado es un mapa que muestra dónde se encuentran los datos sensibles en tu arquitectura y cómo están protegidos, elaborado íntegramente a partir del código.
En el aikido, esto forma parte del análisis de código con IA, por lo que la auditoría de exposición de datos se lleva a cabo junto con el resto de la revisión del código, en lugar de como una integración de acceso a datos independiente.
En qué se diferencia la calidad de los resultados
Tomemos la tala como ejemplo sencillo.
Un producto DSPM tradicional podría indicarte, en su caso, que hay información de identificación personal (PII) en los registros de la aplicación. De nuevo, es útil. Pero ahora alguien tiene que ponerse a buscar el origen.
Una auditoría de exposición de datos basada en el código puede ofrecer una visión más completa al relacionar los datos, la ruta del código, el destino, el riesgo de exposición y la solución. Esto la hace más útil para los desarrolladores.
Por ejemplo, el controlador de pago registra el objeto «billingDetails» completo cuando falla la autorización del pago. Ese objeto incluye el correo electrónico, el número de teléfono, la dirección de facturación y los cuatro últimos dígitos de la tarjeta. Los registros se envían a Datadog. La solución consiste en ocultar esos campos antes de registrarlos y conservar únicamente el ID del cliente, el ID de la intención de pago y el código de error.
Esa información es muy diferente de la que se obtiene con un DSPM tradicional.
Lo mismo ocurre con los secretos y los tokens. Tomemos como ejemplo un token de SCM que se utiliza para leer código de GitHub, GitLab o Bitbucket. Desde una perspectiva centrada en el almacenamiento, cabría preguntarse si el token está cifrado en la base de datos. Sin embargo, esto no es todo.
¿Por dónde entra el token en la plataforma? ¿Es un token OAuth, un token de una aplicación de GitHub o un PAT enviado por el usuario? ¿Qué ámbitos tiene? ¿Cómo se valida? ¿Dónde se cifra? ¿Dónde se almacena? ¿Cuándo se descifra? ¿Se almacena en caché? ¿Está incrustado en una URL de clonación? ¿Se pasa a un worker? ¿Podría filtrarse a través de registros, trazas, errores, argumentos de proceso o telemetría? Se trata de un problema de seguridad de los datos, pero el código nos revela lo que necesitamos saber sobre su recorrido.
Del panel de control a la solución
Aquí es donde creo que el DSPM basado en código se vuelve interesante.
La mejor opción no es otro panel de control que diga: «Tienes datos confidenciales». Eso ya lo sabe todo el mundo. La mejor experiencia consiste en mostrar el inventario de datos confidenciales, el flujo, el riesgo de exposición, los controles pertinentes y el cambio en el código que reduce el riesgo.
Si el código ha provocado el error, probablemente la solución se encuentre en el propio código.
Por lo tanto, el flujo de trabajo habitual de un desarrollador debería ser el siguiente:
- Ocultar los campos confidenciales antes de registrarlos.
- Devuelve un objeto de respuesta de la API más pequeño.
- Añade una comprobación de la titularidad del inquilino.
- Deja de incluir parámetros en las URL.
- Enmascarar los datos de producción antes de restaurarlos en el entorno de prueba.
- Aplica el cifrado antes de guardar los datos.
- Eliminar los datos de los clientes de una solicitud de un modelo de lenguaje grande (LLM).
- Corregir la lógica de eliminación para que los registros posteriores se eliminen realmente.
El ingeniero quiere saber qué ruta de código concreta genera un riesgo específico de exposición de datos y cómo solucionarlo.
Esto también hace que la relación con los marcos de seguridad y cumplimiento normativo sea mucho más concreta. Si un token se gestiona de forma inadecuada, ello puede tener repercusiones en la gestión de los autenticadores, la protección de la transmisión, el principio de privilegios mínimos y la protección de los registros de auditoría. Si la información de identificación personal (PII) se registra sin censurar, esto puede afectar a la privacidad, la retención, la minimización de datos y los controles de supervisión. Si los datos de los clientes se copian a un entorno de prueba sin enmascarar, esto puede afectar al control de acceso, la separación de entornos y las obligaciones de cumplimiento normativo. Si los registros sobreviven a una solicitud de eliminación, o si los datos permanecen más allá de su plazo de retención, esto está directamente relacionado con las obligaciones del RGPD y la CCPA, y debe corregirse en la propia lógica de eliminación y retención.
El hallazgo que simplemente indica «Patrón de registro inseguro» tiene una utilidad bastante limitada. Sin embargo, algo como «La información de carácter personal (PII) de los clientes que llega a los registros a través de esta ruta de código supone un riesgo de exposición de datos, afecta a estos controles y puede solucionarse ocultando estos campos antes de realizar el registro» sí que permite tomar medidas concretas.
Esa es una forma mucho mejor de abordar conjuntamente la ingeniería, AppSec y el cumplimiento normativo.
La versión sencilla
La gestión tradicional de datos y información (DSPM) sigue siendo importante. Ayuda a los equipos a comprender dónde se encuentran los datos confidenciales en el entorno real. Permite detectar «buckets» olvidados, bases de datos expuestas, datos en la sombra y almacenes con permisos excesivos.
Sin embargo, el DSPM basado en código añade la capa de aplicación que faltaba. Ayuda a explicar cómo llegan allí los datos sensibles, cómo se mueven, dónde se encuentra el mecanismo de exposición y qué pueden hacer los desarrolladores al respecto.
Así pues, la versión simplificada queda así:
El DSPM tradicional localiza los datos confidenciales allí donde se encuentran.
El DSPM basado en código detecta cómo se exponen los datos sensibles.
Una auditoría de exposición de datos relaciona ese flujo con el código, la brecha de control y la solución.
Esa es la versión «shift-left» del DSPM. Y, para los desarrolladores y AppSec , probablemente sea la versión que más les ayuda.
Aikido ofrece la primera solución de su clase en DSPM basada en código. Protege y realiza un seguimiento de tus datos, sin necesidad siquiera de conectar tus bases de datos.
