Compartir a través de


Filtrado de extremo de conector (versión preliminar)

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

El filtrado de extremo de conector permite a los administradores controlar a qué extremos específicos pueden conectarse los creadores al crear aplicaciones, flujos o chatbots. Se configura dentro de una directiva de prevención de pérdidas de datos (DLP), y está disponible exclusivamente para seis conectores:

  • HTTP
  • HTTP con Microsoft Entra ID (AD)
  • HTTP Webhook
  • SQL Server (incluye el uso de SQL Server Connector para acceder al almacén de datos de Azure Synapse)
  • Almacenamiento de blobs de Azure
  • SMTP

Cuando un creador intenta conectar su aplicación, flujo o chatbot a un extremo bloqueado, encontrará un mensaje de error de DLP.

Advertencia

Las reglas de filtrado de extremos no son obligatorias en las variables de entorno, entradas personalizadas y los extremos creados dinámicamente en tiempo de ejecución. Solo los extremos estáticos se evalúan en los diseñadores de aplicaciones, flujos o chatbots. Para más información, consulte Limitaciones conocidas.

Importante

Las características en versión preliminar no se han diseñado para un uso de producción y pueden tener una funcionalidad restringida. Estas características están disponibles antes del lanzamiento oficial para que los clientes puedan tener un acceso anticipado y proporcionar comentarios.

Agregar reglas de filtrado extremos a sus directivas de DLP

La columna Extremo configurable en la página Conectores prediseñados en Directivas de datos indica si la capacidad de filtrado del extremo es compatible con el conector.

Extremo configurable en la página Conectores prediseñados.

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

Configure el conector > Puntos de conexión del conector.

Esto abre un panel lateral donde puede especificar una lista ordenada de patrones de Permitir o Denegar URL. La última fila de la lista será siempre una regla para el carácter comodín (*), que se aplica a todos los extremos de ese conector. De manera predeterminada, el patrón * está configurado como Permitir para las nuevas directivas DLP, pero se puede etiquetar como Permitir o Denegar.

Especifique una lista ordenada de patrones de URL de Permitir y Denegar para conectores personalizados.

Agregar nuevas reglas

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

Seleccionar Agregar extremo para agregar nuevas reglas.

Una vez que se ha agregado un patrón, puede editar o eliminar estos patrones seleccionando una fila específica y seleccionando Eliminar.

Eliminar un patrón.

Después de guardar las reglas de filtrado del extremo del conector y la directiva de DLP en la que están definidas, se aplican instantáneamente en los entornos de destino. A continuación se muestra un ejemplo en el que un creador intentó conectar su flujo de nube a un extremo HTTP que no está permitido.

Error de DLP debido a las reglas de filtrado de extremo.

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 el tiempo de ejecución. Solo se aplican los puntos de conexión estáticos conocidos y seleccionados al crear una aplicación, un flujo o un bot de chat durante el tiempo de diseño. Esto implica que el conector de filtrado reglas del punto de conexión para SQL Server y Azure Blob Storage no son obligatorias si las conexiones se autentican con Microsoft Entra ID. En las dos capturas de pantalla a continuación, un creador ha creado un flujo de nube que define el servidor SQL y la base de datos dentro de las variables, y luego usa esas variables como entrada para la definición de la conexión. Por tanto, las reglas de filtrado de extremo no se evalúan y el flujo de nube puede ejecutarse correctamente.

    El flujo de nube usa variables para conectarse a SQL.El flujo de nube se ejecuta correctamente.

  • Algunas aplicaciones de Power Apps publicadas antes del 1 de octubre de 2020 deben volver a publicarse para que se apliquen las reglas de acción y las reglas de extremo del conector de DLP. La siguiente secuencia de comandos permite a los administradores y creadores identificar aplicaciones que deben volver a publicarse para respetar estas nuevas reglas de control granular de DLP:

    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 be Granular DLP compliant: " $app.AppName " "  $app.Internal.properties.displayName " " $app.Internal.properties.owner.email
        } 
        Else{ 
            Write-Host "App is already Granular DLP compliant: " $app.AppName 
        }
    }
    

Formatos de entrada de extremo y ejemplos

Cada conector tiene una noción diferente de lo que significa un extremo. Además, algunos extremos se pueden definir en varios formatos. Por lo tanto, los extremos deben introducirse en todos los formatos posibles para evitar que los fabricantes los usen mientras crean aplicaciones y flujos. Los administradores pueden introducir el nombre completo del punto final o utilizar la coincidencia de patrones con el carácter comodín (*) al crear una regla de filtrado de extremos. Estas reglas se introducen y se presentan en una lista ordenada de patrones de extremos, lo que significa que se evaluarán en orden ascendente por número. Tenga en cuenta que 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

Los extremos de conexión de SQL Server deben estar listados en formato <Server_name, database_name>. Algunas cosas a tener en cuenta:

  • Los creadores pueden introducir el nombre del servidor en varios formatos. Por lo tanto, para abordar realmente un extremo, debe introducirse 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, deberá aplicar reglas de permitir o bloquear en ambos formatos para un extremo. Por ejemplo:

    • Bloquear WS12875676\Servername1,MktingDB
    • Bloquear 11.22.33.444,1401,MktingDB
  • No hay una lógica especial para manejar direcciones relativas como localhost. Por lo tanto, si bloquea *localhost*, evitará que los creadores utilicen extremos mediante el uso de localhost como parte del extremo de SQL Server. Sin embargo, no impedirá 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 rango específico de IP: (tenga en cuenta que las direcciones IP que no están permitidas todavía pueden ser introducidas por el fabricante en formato <machine_name\named_instance>.)

    1. Permitir 11.22.33*
    2. Denegar *

Dataverse

Los extremos de Dataverse están representados por el Id. de organización, como 7b97cd5c-ce38-4930-9497-eec2a95bf5f7. Tenga en cuenta que actualmente sólo el conector normal de Dataverse está en el ámbito del filtrado de extremos. Los conectores actuales de Dataverse Dynamics y Dataverse no están dentro del alcance. Además, la instancia local de Dataverse (también conocido como el entorno actual) nunca se puede bloquear para su uso dentro de un entorno. Esto significa que dentro de cualquier entorno, los creadores siempre pueden tener acceso al entorno actual de Dataverse.

Por tanto, una regla que dice lo siguiente:

  1. Permitir 7b97cd5c-ce38-4930-9497-eec2a95bf5f7
  2. Denegar *

En realidad significa:

  1. Permitir Dataverse current environment
  2. Permitir 7b97cd5c-ce38-4930-9497-eec2a95bf5f7
  3. Denegar *

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

Azure Blob Storage

Los extremos de Azure Blob Storage están representados por el nombre de la cuenta de Azure Storage.

SMTP

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

A continuación se expone un escenario de ejemplo.

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

HTTP con Microsoft Entra ID, HTTP Webhook y conectores HTTP

Los extremos de todos los conectores HTTP están representados por un patrón de URL. La acción Obtener recurso web de HTTP con el conector de Microsoft Entra está fuera de alcance.

A continuación se expone 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 *

Soporte de PowerShell para el filtrado del extremo

Configurar las reglas de filtrado de extremo para una directiva

El objeto que contiene las reglas de filtrado del extremo para una política se denomina a continuación configuraciones de 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 debe aplicarse siempre a la URL *, para garantizar que todas las URL estén cubiertas por las reglas.
  • La propiedad de orden de las reglas para cada conector debe rellenarse con números del 1 al N, donde N es el número de reglas para ese conector.

Recuperar configuraciones de conector existentes para una política DLP

Get-PowerAppDlpPolicyConnectorConfigurations 

Crear configuraciones de conector para una política DLP

New-PowerAppDlpPolicyConnectorConfigurations

Actualizar las configuraciones del conector para una política DLP

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 otras 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

Nota

En el siguiente cmdlet, PolicyName se refiere al GUID único. Puede recuperar el GUID de DLP ejecutando el cmdlet Get-DlpPolicy.

$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