Filtragem de ponto de extremidade de conector (versão preliminar)

[Este artigo faz parte da documentação de pré-lançamento e está sujeito a alterações.]

A filtragem de ponto de extremidade do conector permite que os administradores controlem a quais pontos de extremidade específicos os criadores podem se conectar ao criar aplicativos, fluxos ou chatbots. Ele está configurado em uma política de dados e está disponível exclusivamente para os seguintes conectores:

• HTTP
• HTTP com Microsoft Entra ID (AD)
• HTTP Webhook
• SQL Server (inclui o uso do Conector do SQL Server para acessar o data warehouse do Azure Synapse)
• Armazenamento de Blobs do Azure
• SMTP
• Automação do navegador
• Automação da interface do usuário

Quando um criador conecta seu aplicativo, fluxo ou chatbot a um ponto de extremidade bloqueado, ele vê uma mensagem de erro de política de dados.

Adicionar regras de filtragem de endpoint às políticas de dados

A coluna de ponto de extremidade configurável na página Conectores Predefinidos em Políticas de Dados indica se o recurso de filtragem de ponto de extremidade tem suporte para o conector.

Se o valor da coluna Ponto de extremidade configurável for Sim, você poderá usar esse recurso clicando com o botão direito e selecionando Configurar conector>Pontos de extremidade do conector.

Isso abre um painel lateral em que você especifica uma lista ordenada de padrões de URL Allow ou Deny. A última linha da lista é uma regra para o caractere curinga (*) que se aplica a todos os pontos de extremidade nesse conector. Por padrão, o * padrão é configurado como Permitir novas políticas de dados, mas você pode marcá-lo como Permitir ou Negar.

Adicionar novas regras

Você pode adicionar novas regras selecionando Adicionar ponto de extremidade. Novas regras são adicionadas ao final da lista de padrões como a última regra. Isso ocorre porque * é a última entrada na lista. No entanto, você pode atualizar a ordem dos padrões usando a lista suspensa Ordem ou selecionando Mover para cima ou Mover para baixo.

Depois de adicionar um padrão, você pode editá-lo ou excluí-lo selecionando uma linha específica e selecionando Excluir.

Depois de salvar as regras de filtragem do ponto de extremidade do conector e a política de dados em que elas são definidas, elas serão aplicadas instantaneamente nos ambientes de destino. A imagem a seguir mostra um exemplo em que um usuário tenta conectar seu fluxo de nuvem a um endpoint HTTP que não é permitido.

Limitações conhecidas

• As regras da filtragem de ponto de extremidade não são impostas em variáveis de ambiente, entradas personalizadas e pontos de extremidade limitados dinamicamente durante o runtime. Apenas pontos de extremidade estáticos conhecidos e selecionados ao criar um aplicativo, fluxo ou chatbot durante o tempo de design são impostos. Isso significa que as regras de filtragem de ponto de extremidade do conector para o SQL Server e o Armazenamento de Blobs do Azure não serão impostas quando as conexões forem autenticadas com o Microsoft Entra ID. Nas duas capturas de tela a seguir, um criador cria um fluxo de nuvem que define o SQL Server e o banco de dados dentro de variáveis e, em seguida, usa essas variáveis como entrada para a definição de conexão. Como resultado, as regras de filtragem de ponto de extremidade não são avaliadas e o fluxo de nuvem é executado com êxito.

  

  

• O Power Apps publicado antes de 1º de outubro de 2020 precisa ser republicado para que as regras de ação do conector de política de dados e as regras de ponto de extremidade sejam impostas. O script a seguir permite que administradores e criadores identifiquem aplicativos que devem ser republicados para cumprir estas novas regras de controle granular de política de dados:

  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 e exemplos de entrada de ponto de extremidade

Cada conector define um ponto de extremidade de forma diferente e alguns pontos de extremidade podem estar em vários formatos. Portanto, você deve inserir pontos de extremidade em todos os formatos possíveis para impedir que os criadores os usem ao criar aplicativos e fluxos. Os administradores podem inserir o nome completo do ponto de extremidade ou usar a correspondência de padrões com o caractere curinga (*) para criar uma regra de filtragem de ponto de extremidade. Essas regras são inseridas e apresentadas em uma lista ordenada de padrões de ponto de extremidade, o que significa que elas são avaliadas em ordem crescente por número. A última regra para qualquer conector é sempre * Permitir ou * Negar. Permitir é o padrão, que pode ser alterado para Negar.

A orientação a seguir descreve como inserir pontos de extremidade do conector ao criar regras para permiti-los ou negá-los.

SQL Server

Listar em formato <Server_name, database_name> os pontos de extremidade de conexão do SQL Server. Algumas considerações:

• Os criadores podem inserir o nome do servidor em vários formatos. Para tratar um ponto de extremidade, insira-o em todos os formatos possíveis. Por exemplo, instâncias locais podem estar no formato <machine_name\named_instance, database_name> ou <IP address, custom port, database_name>. Nesse caso, será preciso aplicar regras de permissão ou bloqueio em ambos os formatos para um ponto de extremidade. Por exemplo:

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

• Nenhuma lógica especial manipula endereços relativos como localhost. Portanto, se você bloquear *localhost*, isso impedirá que os criadores usem qualquer ponto de extremidade usando localhost como parte do ponto de extremidade do SQL Server. Mas, isso não os impedirá de acessar o ponto de extremidade usando o endereço absoluto, a menos que o endereço absoluto também tenha sido bloqueado pelo administrador.

Aqui estão alguns exemplos:

• Permitir apenas instâncias do Azure SQL Server:

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

• Permitir apenas um intervalo de IP específico: (Os endereços IP que não são permitidos ainda podem ser inseridos pelo criador no <machine_name\named_instance> formato.)

  1. Permitir 11.22.33*
  2. Negar *

Dataverse

Os pontos de extremidade do Dataverse são representados pela ID da organização, como 00aa00aa-bb11-cc22-dd33-44ee44ee44ee. Observe que apenas o conector regular do Dataverse está no escopo, no momento, para filtragem de ponto de extremidade. Conectores atuais e dinâmicos do Dataverse não estão no escopo. Além disso, a instância local do Dataverse (também conhecido como ambiente atual) nunca pode ser bloqueada para uso em um ambiente. Isso significa que os criadores sempre podem acessar o ambiente atual do Dataverse em qualquer ambiente específico.

Portanto, uma regra que diz:

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

Na verdade significa:

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

Permitir Dataverse current environment é sempre implicitamente a primeira regra na lista de filtragem de ponto de extremidade do Dataverse para qualquer ambiente.

Armazenamento de Blobs do Azure

Os endpoints do Armazenamento de Blobs do Azure usam o nome da conta de armazenamento do Azure.

SMTP

Pontos de extremidade do SMTP são representados no formato <SMTP server address, port number>.

Veja um exemplo de cenário:

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

HTTP com conectores do Microsoft Entra ID, HTTP Webhook e HTTP

Os pontos de extremidade do conector HTTP usam um padrão de URL. A ação Obter recurso da Web do HTTP com conector do Microsoft Entra está fora do escopo.

Veja um cenário de exemplo:

Permitir acesso apenas à página Assinaturas do Azure em https://management.azure.com/.

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

Automação do navegador

Esse recurso permite controlar as páginas da Web que um fluxo de área de trabalho acessa no Power Automate para desktop. Os pontos de extremidade são representados no formato de URL ou no formato de nome de página da Web, e você pode usar curingas para correspondência dinâmica de URL ou nome de página. A validação ocorre durante as ações "Iniciar Navegador da Web" ou "Ir para a página da Web" antes que um fluxo de área de trabalho prossiga com as interações do navegador.

Veja um exemplo de cenário:

Permitir acesso a todas as páginas da Web, exceto a URL https://www.microsoft.com/ e qualquer URL ou página da Web que contenha a cadeia de caracteres powerplatform.

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

Automação da interface do usuário

Esse recurso permite definir com quais aplicativos e telas um fluxo de área de trabalho pode interagir no Power Automate para área de trabalho. Os endpoints são especificados usando o nome do processo do aplicativo. Quando o nome do processo é ApplicationFrameHost, Java ou Javaw — indicando um aplicativo UWP (Plataforma Universal do Windows) ou Java em que várias instâncias podem compartilhar o mesmo nome– o Power Automate para desktop usa o nome do processo e o nome de exibição da janela para identificar com precisão o destino. Há suporte para curingas para correspondência flexível.

A validação ocorre em qualquer ação dentro do grupo de automação da interface do usuário. Ele verifica o atributo Process (indicado pelo número 1 na imagem) ou o atributo Name (indicado pelo número 2 na imagem) no seletor da tela de destino (conforme mostrado pela seta na imagem). Geralmente, utiliza-se o pai dos elementos de interface do usuário relacionados para determinar se a interação é permitida.

As regras de filtragem de ponto de extremidade não se aplicam a variáveis ou pontos de extremidade associados dinamicamente. Se uma expressão incluir qualquer outra coisa que não seja uma cadeia de caracteres literal, a filtragem será ignorada, permitindo potencialmente o acesso a argumentos de conector restritos. O comportamento da política padrão é que todas as políticas de filtragem de ponto de extremidade incluem uma regra principal (Permitir * ou Negar *), sendo o padrão Permitir * (Permitir Todos).

• Quando Allow * é usado: valores dinâmicos não são filtrados. Qualquer expressão dinâmica ignora a filtragem de endpoint, mesmo que aplicativos específicos estejam restritos.
• Quando Deny * é usado: todos os valores dinâmicos são bloqueados por padrão, garantindo uma imposição mais rigorosa.

Este é um cenário de exemplo. Para permitir o acesso a todos os aplicativos e telas, exceto aqueles em que o atributo Processo ou Nome é exatamente Calculadora ou contém a cadeia de caracteres Java, você configuraria as seguintes regras:

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

Suporte do PowerShell para filtragem de ponto de extremidade

Configurar regras de filtragem de ponto de extremidade para uma política

O objeto que contém regras de filtragem de ponto de extremidade para uma política é chamado de configurações do conector.

O objeto de configurações do conector tem a seguinte estrutura:

$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
        }
      ) 
    }
  ) 
}

Anotações

• A última regra para cada conector deve sempre se aplicar à URL * para garantir que todas as URLs sejam cobertas pelas regras.
• A propriedade de ordem das regras para cada conector deve usar números de 1 a N, onde N é o número de regras desse conector.

Obter configurações de conectores existentes para uma política de dados

Get-PowerAppDlpPolicyConnectorConfigurations 

Criar configurações de conectores para uma política de dados

New-PowerAppDlpPolicyConnectorConfigurations

Atualizar as configurações do conector para uma política de dados

Set-PowerAppDlpPolicyConnectorConfigurations

Exemplo

Meta:

Para o conector do SQL Server:

• Negar o banco de dados "testdatabase" do servidor "myservername.database.windows.net"
• Permitir todos os outros bancos de dados do servidor "myservername.database.windows.net"
• Negar todos os outros servidores

Para o conector SMTP:

• Permitir Gmail (endereço do servidor: smtp.gmail.com, porta: 587)
• Negar todos os outros endereços

Para o conector HTTP:

• Permitir pontos de extremidade https://mywebsite.com/allowedPath1 e https://mywebsite.com/allowedPath2
• Negar todas as outras URLs

$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