MSTech Geeks

Introducción

En los últimos meses Microsoft ha presentado varias demostraciones sobre la integración entre Microsoft Purview DSPM for AI y aplicaciones basadas en Azure AI Foundry. En estas demostraciones se muestra cómo es posible bloquear prompts que contienen información sensible antes de que lleguen al modelo LLM.

En este artículo intento reproducir esta demo en un laboratorio propio para entender cómo funciona realmente esta integración.

Arquitectura de la demo

Básicamente, se trataba de desplegar un modelo LLM  a través de Azure AI Foundry, en segundo lugar, llevar a cabo la implementación web a través de su “playground”, para el que no lo sepa, esto despliega una web app de Azure (chatbot), con todo lo necesario para poder interactuar con el modelo sin necesidad de realizar ningún despliegue (en este sentido) de manera manual.

Por último, en la demo, se veía la creación de una directiva DLP de Purview para bloquear las interacciones de los usuarios con la aplicación, en caso de que el prompt contuviese información confidencial (SIT: Sensitive Information Type) , aunque nos enseñaron como el prompt con dicha información, parecía bloqueado o protegido por el modelo, esta parte no me convenció, más adelante os explicaré el porqué. Una arquitectura simplificada podría tener este aspecto:

Usuario -> Web App (Microsoft Foundry Playground deployment) -> Azure OpenAI /LLM -> Purview DSPM for AI -> Defender for Cloud

Microsoft Foundry: Despliegue del modelo LLM (gpt-4o-mini)

Web App: Interfaz chatbot

Defender for Cloud: Protección de AI Services

Microsoft Purview: Análisis, visibilidad de las interacciones y DLP

Para poder hablar con conocimiento de causa, me he puesto manos a la obra y he intentado recrear dicha demo, tirando de documentación, de IA generativa y como no, paseándome por los blogs de la comunidad.

Antes de hacer vuestras pruebas, os aconsejo que le echéis un vistazo al siguiente link, donde publico como preparar el entorno de DSPM for AI de Purview.

Preparación del entorno

Los requerimientos para poder hacer estas pruebas han sido las siguientes:

• Licenciamiento Microsoft 365 E5
• Tenant con Purview
• Suscripción de Azure
• Microsoft Foundry
• Defender for Cloud AI Protection

Despliegue de la apliación AI

Esta parte es bastante sencilla para el que se haya peleado con Microsoft Foundry.

En mi caso, desplegué en recurso de este tipo en Sweden Central.

A continuación, accedemos al portal de Foundry:

En catálogo de modelos, buscamos por ejemplo gpt-4o-mini y lo desplegamos:

Una vez desplegado, entramos en el área de juegos (playground) y desde esta ventana podremos implementar dicho modelo como una aplicación web:

Una vez implementada, podremos acceder a ella e interactuar con el modelo:

Al desplegar este recurso (Service App) podemos observar que también nos ha creado una identidad administrada asignada por el sistemas, con el nombre de nuestra aplicación web:

Además, la autenticación de nuestro chatbot depende de este Service Principal:

Esta identidad, más adelante nos servirá para configurar nuestra DLP de Purview y hacer referencia a esta aplicación Cloud.

Activando la protección contra amenazas de la IA en Defender for Cloud

Una vez que ya hemos desplegado y configurado nuestra aplicación Cloud, toca el turno de protegerla. Para ello y en primer lugar vamos a hacer uso de “Defender for Cloud for AI Services”. Esta característica de Defender for Cloud usa Azure AI Content Safety Prompt Shields para dicha protección y se integra además con XDR de Defender. Prompt Shield reconoce la siguiente tipología de ataques:

En nuestro caso, activaremos la protección de AI Services en CWPP de Defender for Cloud de la suscripción que contiene nuestro aplicación Cloud:

Dentro de settings de esta protección, también marcaremos la siguiente configuración:

Según la documentación oficial, las funciones admitidas de Microsoft Purview compatibles con Microsoft Foundry, activando esta característica son las siguientes:

Hasta aquí, todo lo que hemos tenido que hacer ha sido bastante sencillo y sin embargo ya tenemos visibilidad de todas las interacciones entre nuestros usuarios empresariales y nuestras aplicaciones de Microsoft Foundry desplegadas en Azure, mediante el explorador de actividad de Purview, podemos observar como las capturas de las interacciones tienen lugar:

Otra vuelta de tuerca: desplegando la regla DLP para bloquear la interacción del usuario

Aquí viene la parte más complicada o por lo menos y hasta el momento yo no he conseguido que funcione. Según documentación oficial:

Partiendo de la aplicación desplegada anteriormente y haciendo uso del cmdlet New-DlpComplianceRule, a través de Powershell, tal y como como se comenta en la documentación, he registrado la siguiente regla DLP:

Este script de powershell genera la siguiente regla DLP:

Una vez sincronizada, la editamos para ver las configuraciones más importantes. Por ejemplo, en locations, vemos como en Managed Cloud Apps:

Asignó el Service Principal de nuestro chatbot:

En cuanto a las reglas DLP, además de la regla de bloquear el SIT del DNI Español, también añadí el de bloquear el correspondiente de las tarjetas de crédito:

Configuración adicional necesaria

Además y como podéis observar en la página de “locations” del wizard de la regla DLP, aparecieron dos advertencias, una sobre crear una directiva de acceso condional y otra sobre los ajustes de protección de Edger for business.

En cuanto a la primera advertencia, tiene sentido prosificar mediante Defender for Cloud Apps, las interacciones de los usuarios con respecto a nuestro chatbot. Así que cree esa directiva de acceso condicional, tal y como la documentación especifica para estos casos.

Además, también activé la protección de Edge for Business

Estos pasos no habían sido completados en la demo de Microsoft, puesto que recuerdo que esos banners amarillos aparecían en el proceso de creación de la DLP. Por otro lado, este tipo de DLP solo pueden crearse a través de powershell como hemos visto anteriormente y según reza en la documentación. Una vez que completamos esos pasos y esperamos unos minutos, si volvemos a acceder a la directiva, los banners amarillos de advertencia desaparecen.

Resultado de las pruebas

Teóricamente ya debería de estar listo para que la regla DLP no permitiese introducir SITs definidos anteriormente en nuestro chatbot:

Sin embargo, aunque el modelo no conteste al prompt anterior, este si está llegando al modelo y bajo mi opinión, ni siquiera debería hacerlo, puesto que la brecha de seguridad ya estaría ocurriendo. En el caso de la protección de DSPM for IA para chatbot públicos, como es el caso de ChatGPT:

La directiva intercepta la interacción del usuario antes de que llegue al modelo y es bloqueada.

Tanto en la demo de Microsoft como en otros laboratorios que he visto publicados en Internet, el comportamiento es el mismo, el prompt llega al modelo LLM y este contesta, es cierto que nunca contesta cuando se trata de datos sensibles pero en mi opinión no es gracias a la directiva configurada anteriormente, que supuestamente debería controlar y bloquear esas interacciones.

Conclusiones

Actualmente la integración entre Purview DSPM for AI y aplicaciones personalizadas basadas en Azure AI Foundry ofrece visibilidad sobre las interacciones con el modelo, pero no proporciona todavía un mecanismo preventivo para bloquear prompts antes de que lleguen al LLM de manera clara. Esto sugiere que para escenarios de alto riesgo podría ser necesario implementar controles adicionales, como proxies de seguridad o middleware que intercepten las peticiones antes de enviarlas al modelo.