Políticas de datos prevención de pérdidas (DLP)

La prevención de pérdida de datos (DLP) es un aspecto crítico para mantener la seguridad y el cumplimiento de los datos dentro del ecosistema de Microsoft Power Platform.

Puede crear directivas de datos que pueden actuar como barreras para reducir el riesgo de que los usuarios expongan involuntariamente los datos de la organización. Un componente central de Power Apps, Power Automate, y Microsoft Copilot Studio es el uso de conectores para enumerar, completar, enviar y extraer datos. Directivas de datos en el centro de administración de Power Platform permite a los administradores controlar el acceso a estos conectores de varias maneras para ayudar a reducir el riesgo en su organización.

Esta descripción general describe algunos conceptos de alto nivel relacionados con los conectores y varias consideraciones importantes a tener en cuenta al configurar sus directivas o realizar cambios en las directivas.

Conectores

Los conectores, en su nivel más básico, son representaciones fuertemente tipadas de interfaces de programación de aplicaciones tranquilas, también conocidas como API. Por ejemplo, el API Power Platform proporciona varias operaciones relacionadas con la funcionalidad en el centro de administración de Power Platform.

Muestra una página de referencia de API tranquila con parámetros de cadena de consulta opcionales.

Al envolver el API Power Platform en un conector, resulta más fácil para los creadores y desarrolladores civiles utilizar la API en sus aplicaciones, flujos de trabajo y bots de chat con poco código. Por ejemplo, el conector Power Platform for Admins V2 es la representación del API Power Platform y vemos que la acción "Obtener recomendaciones" simplemente se arrastra y se suelta en el flujo:

Muestra el conector en un flujo de trabajo de Power Automate.

Hay varios tipos de conectores mencionados en este artículo y cada uno tiene capacidades dentro de las directivas de datos.

Conectores certificados

Los conectores certificados se refieren a conectores que se han sometido a rigurosos procesos de prueba y certificación para garantizar que cumplen con los estándares de seguridad, fiabilidad y cumplimiento de Microsoft. Estos conectores ofrecen a los usuarios un medio fiable para integrarse con otros servicios de Microsoft y servicios externos, al mismo tiempo que mantienen la integridad y seguridad de los datos.

Para obtener más información sobre conectores certificados, consulte Directrices para la presentación de certificaciones.

Conectores personalizados

Los conectores personalizados permiten a los creadores crear sus propios conectores para integrarlos con sistemas o servicios externos no cubiertos por el conjunto estándar de conectores certificados. Si bien ofrecen flexibilidad y opciones de personalización, los conectores personalizados requieren una consideración cuidadosa para garantizar que cumplan con las directivas de datos y no comprometan la seguridad de los datos.

Más información crear y administrar conectores personalizados.

Conectores virtuales

Los conectores virtuales son conectores que se muestran en las directivas de datos para que los administradores los controlen, sin embargo, no se basan en una API silenciosa. La proliferación de conectores virtuales se debe a que las directivas de datos son uno de los controles de gobernanza más populares en Power Platform. Se espera que surjan más de estos tipos de capacidades "activadas/desactivadas" como reglas dentro de los grupos de entornos.

Se proporcionan varios conectores virtuales para gobernar Microsoft Copilot Studio. Estos conectores facilitan la posibilidad de desactivar varias funciones de Copilot y bots de chat.

Explore los conectores virtuales y su función en prevención de pérdida de datos en Microsoft Copilot Studio.

Conexiones

Cuando un creador está creando una aplicación o un flujo y necesita conectarse a datos, puede usar uno de los tipos de conectores anteriores. Cuando se agrega un conector por primera vez a una aplicación, se establece una conexión utilizando los protocolos de autenticación admitidos por ese conector en particular. Estas conexiones representan una credencial guardada y se almacenan dentro del entorno que aloja la aplicación o el flujo. Para más información, sobre la autenticación de conectores, consulte Conexión y autenticación a orígenes de datos.

Tiempo de diseño frente a runtime

Cuando un Administrador elige limitar el acceso a un conector completo o a acciones específicas de un conector, hay impactos tanto en la experiencia del creador como en la ejecución de aplicaciones, flujos y bots de chat creados previamente.

Las experiencias de los creadores, a menudo denominadas experiencias de tiempo de diseño, limitan los conectores con los que los creadores pueden interactuar. Si una directiva de datos bloqueó el uso del conector MSN Weather, entonces un creador no puede guardar su flujo o aplicación que lo utiliza y, en su lugar, recibe un mensaje de error que indica que el conector ha sido bloqueado por la directiva.

Las experiencias en las que se ejecuta una aplicación o un flujo en un horario predefinido, como todos los días a las 3:00 a. m., a menudo se denominan experiencias de runtime. Continuando con el ejemplo anterior, si la conexión se desactivó mediante el proceso en segundo plano que se describe a continuación, el resultado es que la aplicación o el flujo proporciona un mensaje de error indicando que la conexión de MSN Weather está rota y necesita resolución. Cuando el creador intenta actualizar su conexión para solucionarlo, recibe un error en la experiencia en tiempo de diseño que indica que el conector está bloqueado por una directiva.

Proceso para cambios de directivas

A medida que se crean nuevas directivas de datos, o cuando se actualizan las directivas existentes, se activa un proceso específico dentro del ecosistema de servicios de Power Platform que ayuda a que esas directivas se apliquen en todo el conjunto de recursos que un cliente tiene en su inquilino. Este proceso implica los siguientes pasos.

  1. La configuración de la directiva de datos se guarda en el nivel de gestión de clientes.
  2. Las configuraciones se distribuyen en cascada hasta cada entorno del inquilino del cliente.
  3. Los recursos de cada entorno (como aplicaciones, flujos y bots de chat) comprueban periódicamente las configuraciones de directivas actualizadas.
  4. Cuando se detecta un cambio de configuración, cada aplicación, flujo y chatbot se evalúa para ver si viola la directiva.
  5. Si se produce una infracción, la aplicación, el flujo o el bot de chat se ponen en un estado suspendido o cuarentena para que no pueda funcionar.
  6. Se escanean las conexiones. Si la directiva bloquea todo el conector, entonces la conexión se establece en un estado deshabilitado para que no pueda funcionar.
  7. Cualquier recurso que se esté ejecutando e intentando utilizar una conexión inactiva falla en tiempo de ejecución.

Importante

La aplicación del tiempo de ejecución depende del estado de la conexión. Si aún no está desactivado o aún no se ha escaneado, entonces la conexión aún se puede ejecutar en tiempo de ejecución sin errores.

Consideraciones de latencia

El tiempo que lleva implementar directivas de datos de manera efectiva varía de un cliente a otro según su volumen de entornos y recursos dentro de esos entornos. Cuantas más aplicaciones, flujos y bots de chat tenga un cliente, más tiempo tardarán los cambios en las directivas en surtir efecto. Para los casos más extremos, la latencia para la aplicación total es de 24 horas. En la mayoría de los casos es dentro de una hora.

Consulte también