Filtrado de extremo de conector (versión preliminar)

[Este artículo es documentación preliminar y está sujeto a modificaciones].

El filtrado de puntos de conexión del conector permite a los administradores controlar a qué creadores pueden conectarse a puntos de conexión específicos al crear aplicaciones, flujos o bots de chat. Está configurado dentro de una directiva de datos y está disponible exclusivamente para los siguientes conectores:

• HTTP
• HTTP con Microsoft Entra ID (AD)
• Webhook de HTTP (un mecanismo que permite a una aplicación enviar datos a otra en tiempo real)
• SQL Server (incluye el uso del Conector de SQL Server para acceder al almacén de datos de Azure Synapse)
• Almacenamiento de blobs de Azure
• SMTP
• Automatización del explorador
• Automatización de la interfaz de usuario

Cuando un creador conecta su aplicación, flujo o bot de chat a un punto de conexión bloqueado, verá un mensaje de error de directiva de datos.

Adición de reglas de filtrado de puntos de conexión a las directivas de datos

La columna Punto de conexión configurable de la página Conectores predefinidos en Directivas de datos indica si se admite la funcionalidad de filtrado de puntos de conexión para el conector.

Si el valor de la columna Punto de conexión configurable es Sí, puede utilizar esta capacidad haciendo clic con el botón derecho y después seleccionando Configurar conector>Puntos de conexión de conector.

Se abre un panel lateral donde se especifica una lista ordenada de patrones de URL para permitir o denegar. La última fila de la lista es una regla para el carácter comodín (*) que se aplica a todos los puntos de conexión de ese conector. De forma predeterminada, el * patrón se configura como Permitir para nuevas directivas de datos, pero puede etiquetarlo como Permitir o Denegar.

Agregar nuevas reglas

Puede agregar nuevas reglas seleccionando Agregar extremo. Las nuevas reglas se agregan al final de la lista de patrones como penúltima regla. Esto se debe a * que es la última entrada de la lista. No obstante, también puede actualizar el orden de los patrones utilizando la lista desplegable Orden o seleccionando Subir o Bajar.

Después de agregar un patrón, puede editarlo o eliminarlo seleccionando una fila específica y seleccionando Eliminar.

Después de guardar las reglas de filtrado del punto de conexión del conector y la directiva de datos donde se definen, se aplican al instante en los entornos de destino. En la imagen siguiente se muestra un ejemplo en el que un creador intenta conectar su flujo de nube a un punto de conexión HTTP que no está permitido.

Limitaciones conocidas

• Las reglas de filtrado de puntos de conexión no son obligatorias en las variables de entorno, entradas personalizadas y los extremos vinculados dinámicamente durante runtime. Solo se aplican puntos de conexión estáticos conocidos y seleccionados al crear una aplicación, un flujo o un bot de chat durante la fase de diseño. Esto significa que las reglas de filtrado de puntos de conexión del conector para SQL Server y Azure Blob Storage no se aplican si las conexiones se autentican con el identificador de Microsoft Entra. En las dos capturas de pantalla siguientes, un creador crea un flujo en la nube que define el SQL Server y la base de datos dentro de las variables y, a continuación, utiliza esas variables como entrada para la definición de conexión. Como resultado, las reglas de filtrado de puntos de conexión no se evalúan y el flujo de nube se ejecuta correctamente.

  

  

• Las Power Apps publicadas antes del 1 de octubre de 2020 deben volver a publicarse para que se apliquen las reglas de acción del conector de directiva de datos y las reglas de punto de conexión. El siguiente script permite a los administradores y creadores identificar las aplicaciones que se deben volver a publicar para cumplir estas nuevas reglas de control granulares de directiva de datos:

  Add-PowerAppsAccount
  
  $GranularDLPDate = Get-Date -Date "2020-10-01 00:00:00Z"
  
  ForEach ($app in Get-AdminPowerApp){
  
      $versionAsDate = [datetime]::Parse($app.LastModifiedTime)
  
      $olderApp = $versionAsDate -lt $GranularDLPDate
  
      $wasBackfilled = $app.Internal.properties.executionRestrictions -ne $null -and $app.Internal.properties.executionRestrictions.dataLossPreventionEvaluationResult -ne $null -and ![string]::IsNullOrEmpty($app.Internal.properties.executionRestrictions.dataLossPreventionEvaluationResult.lastAdvancedBackfillDate) 
  
      If($($olderApp -and !$wasBackfilled)){
          Write-Host "App must be republished to comply with granular data policy: " $app.AppName " "  $app.Internal.properties.displayName " " $app.Internal.properties.owner.email
      } 
      Else{ 
          Write-Host "App is already Granular data policy compliant: " $app.AppName 
      }
  }
  

Formatos de entrada de extremo y ejemplos

Cada conector define un punto de conexión de forma diferente y algunos puntos de conexión pueden tener varios formatos. Por lo tanto, debe introducir los puntos de conexión en todos los formatos posibles para evitar que los creadores los usen al crear aplicaciones y flujos. Los administradores pueden escribir el nombre completo del punto de conexión o usar la coincidencia de patrones con el carácter comodín (*) para crear una regla de filtrado de puntos de conexión. Estas reglas se introducen y se presentan en una lista ordenada de patrones de extremos, lo que significa que se evalúan en orden ascendente por número. La última regla para cualquier conector dado es siempre * Permitir o * Denegar. Permitir es el valor predeterminado, que se puede cambiar a Denegar.

La siguiente guía describe cómo introducir extremos de conector al crear reglas para permitirlos o denegarlos.

SQL Server

Enumere los puntos de conexión de SQL Server en <Server_name, database_name> formato. Algunas cosas a tener en cuenta:

• Los creadores pueden escribir el nombre del servidor en varios formatos. Para especificar un endpoint, introdúzcalo en todos los formatos posibles. Por ejemplo, las instancias locales pueden estar en formato <machine_name\named_instance, database_name> o <IP address, custom port, database_name>. En este caso, debe aplicar reglas de permitir o bloquear en ambos formatos para un punto de conexión. Por ejemplo:

  • Bloquear WS12875676\Servername1,MktingDB
  • Bloquear 11.22.33.444,1401,MktingDB

• Ninguna lógica especial controla direcciones relativas como localhost. Por lo tanto, si bloquea *localhost*, evita que los creadores utilicen puntos de conexión mediante el uso de localhost como parte del punto de conexión de SQL Server. Sin embargo, no impide que accedan al extremo usando la dirección absoluta, a menos que el administrador también haya bloqueado la dirección absoluta.

Estos son algunos ejemplos:

• Permitir solo instancias de Azure SQL Server:

  1. Permitir *.database.windows.net*
  2. Denegar *

• Permitir solo un intervalo IP específico: (El creador todavía puede escribir las direcciones IP que no están permitidas en <machine_name\named_instance> formato).

  1. Permitir 11.22.33*
  2. Denegar *

Dataverse

Los puntos de conexión de Dataverse se representan mediante el identificador de la organización, como 00aa00aa-bb11-cc22-dd33-44ee44ee44ee. Tenga en cuenta que actualmente solo el conector normal de Dataverse se encuentra en el ámbito del filtrado de puntos de conexión. La dinámica de Dataverse y los conectores actuales de Dataverse no se encuentran dentro del ámbito. Además, la instancia local de Dataverse (también conocida como el entorno actual) nunca se puede bloquear para su uso dentro de un entorno. Esto significa que los creadores siempre pueden acceder al entorno actual de Dataverse dentro de cualquier entorno determinado.

Por lo tanto, una regla que dice:

1. Permitir 00aa00aa-bb11-cc22-dd33-44ee44ee44ee
2. Denegar *

En realidad significa:

1. Permitir Dataverse current environment
2. Permitir 00aa00aa-bb11-cc22-dd33-44ee44ee44ee
3. Denegar *

Permitir Dataverse current environment es siempre implícitamente la primera regla en el punto de conexión de Dataverse en la lista de filtrado para cualquier entorno determinado.

Almacenamiento de blobs de Azure

Los puntos de conexión de Azure Blob Storage usan el nombre de la cuenta de Azure Storage.

SMTP

Los extremos SMTP están representados en formato <SMTP server address, port number>.

Este es un escenario de ejemplo:

1. Denegar smtp.gmail.com,587
2. Permitir *

HTTP con Microsoft Entra ID, HTTP Webhook y conectores HTTP

Los puntos de conexión del conector HTTP usan un patrón de dirección URL. La acción Obtener recurso web de HTTP con el conector de Microsoft Entra está fuera de alcance.

Este es un escenario de ejemplo:

Permita el acceso solo a la página de suscripciones de Azure dentro de https://management.azure.com/.

1. Permitir https://management.azure.com/subscriptions*
2. Denegar https://management.azure.com/*
3. Denegar *

Automatización del explorador

Esta característica le permite controlar las páginas web a las que accede un flujo de escritorio en Power Automate para escritorio. Los puntos de conexión se representan en formato de URL o formato de nombre de página web, y puede utilizar comodines para la coincidencia dinámica de URL o nombre de página. La validación se produce durante las acciones "Iniciar explorador web" o "Ir a la página web" antes de que un flujo de escritorio continúe con las interacciones del explorador.

Este es un escenario de ejemplo:

Permitir el acceso a todas las páginas web excepto la URL https://www.microsoft.com/ y cualquier URL o página web que contenga la cadena powerplatform.

1. Denegar https://www.microsoft.com/
2. Denegar *powerplatform*
3. Permitir *

Automatización de la interfaz de usuario

Esta característica le permite definir con qué aplicaciones y pantallas puede interactuar un flujo de escritorio en Power Automate para escritorio. Los puntos de conexión se especifican mediante el nombre del proceso de la aplicación. Cuando el nombre del proceso es ApplicationFrameHost, Java o Javaw, que indica una aplicación para la Plataforma universal de Windows (UWP) o Java donde varias instancias pueden compartir el mismo nombre: Power Automate para escritorio usa el nombre del proceso y el nombre para mostrar de la ventana para identificar con precisión el destino. Los caracteres comodín permiten coincidencia flexible.

La validación se produce en cualquier acción dentro del grupo de automatización de la interfaz de usuario. Comprueba el atributo Process (indicado por el número 1 de la imagen) o el atributo Name (indicado por el número 2 de la imagen) en el selector de la pantalla de destino (como se muestra en la flecha de la imagen). Normalmente, el elemento primario de los elementos de interfaz de usuario relacionados se usa para determinar si se permite la interacción.

Las reglas de filtrado de puntos de conexión no se aplican a variables ni a puntos de conexión enlazados dinámicamente. Si una expresión incluye algo distinto de una cadena literal, se omite el filtrado, lo que podría permitir el acceso a argumentos de conector restringidos. El comportamiento predeterminado de directiva es que todas las directivas de filtrado de puntos de conexión incluyen una regla principal (Permitir * o Denegar *), de forma predeterminada Permitir * (Permitir todo).

• Cuando se usa Allow * : los valores dinámicos no se filtran. Cualquier expresión dinámica omite el filtrado de puntos de conexión, incluso si hay aplicaciones específicas restringidas.
• Cuando se usa Deny * : todos los valores dinámicos están bloqueados de forma predeterminada, lo que garantiza un cumplimiento más estricto.

Este es un escenario de ejemplo. Para permitir el acceso a todas las aplicaciones y pantallas, excepto aquellos en los que el atributo Process o Name es exactamente Calculator o contiene la cadena Java, configuraría las reglas siguientes:

1. Denegar Calculator
2. Denegar *Java*
3. Permitir *

Soporte de PowerShell para el filtrado del extremo

Configurar las reglas de filtrado de extremo para una directiva

El objeto que contiene reglas de filtrado de puntos de conexión para una directiva se denomina configuraciones del conector.

El objeto de configuraciones de conector tiene la siguiente estructura:

$ConnectorConfigurations = @{ 
  connectorActionConfigurations = @() # used for connector action rules
  endpointConfigurations = @( # array – one entry per 
    @{  
      connectorId # string
      endpointRules = @( # array – one entry per rule 
        @{ 
          order # number 
          endpoint # string
          behavior # supported values: Allow/Deny
        }
      ) 
    }
  ) 
}

Notas:

• La última regla de cada conector siempre debe aplicarse a la dirección URL * para asegurarse de que todas las direcciones URL están cubiertas por las reglas.
• La propiedad de orden de las reglas para cada conector debe usar números del 1 al N, donde N es el número de reglas para ese conector.

Recuperación de configuraciones de conector existentes para una directiva de datos

Get-PowerAppDlpPolicyConnectorConfigurations 

Creación de configuraciones de conector para una directiva de datos

New-PowerAppDlpPolicyConnectorConfigurations

Actualización de las configuraciones del conector para una directiva de datos

Set-PowerAppDlpPolicyConnectorConfigurations

Ejemplo

Objetivo:

Para el conector de SQL Server:

• Denegar la base de datos "testdatabase" del servidor "myservername.database.windows.net"
• Permitir todas las demás bases de datos del servidor "myservername.database.windows.net"
• Denegar todos los otros servidores

Para el conector SMTP:

• Permitir Gmail (dirección del servidor: smtp.gmail.com, port: 587)
• Denegar todas las otras direcciones

Para el conector HTTP:

• Permitir extremos https://mywebsite.com/allowedPath1 y https://mywebsite.com/allowedPath2
• Denegar todas las otras URL

$ConnectorConfigurations = @{ 
  endpointConfigurations = @(
    @{  
      connectorId = "/providers/Microsoft.PowerApps/apis/shared_sql" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "myservername.database.windows.net,testdatabase" 
          behavior = "Deny"
        }, 
        @{ 
          order = 2 
          endpoint = "myservername.database.windows.net,*" 
          behavior = "Allow"
        }, 
        @{ 
          order = 3
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    }, 
    @{  
      connectorId = "/providers/Microsoft.PowerApps/apis/shared_smtp" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "smtp.gmail.com,587" 
          behavior = "Allow"
        }, 
        @{ 
          order = 2 
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    },
    @{  
      connectorId = "http" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "https://mywebsite.com/allowedPath1" 
          behavior = "Allow"
        }, 
        @{ 
          order = 2
          endpoint = "https://mywebsite.com/allowedPath2" 
          behavior = "Allow"
        }, 
        @{ 
          order = 3
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    } 
  ) 
}
New-PowerAppDlpPolicyConnectorConfigurations -TenantId $TenantId -PolicyName $PolicyName -NewDlpPolicyConnectorConfigurations $ConnectorConfigurations