Filtragem ponto final do conector (pré-visualização)

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

A filtragem de pontos finais de conectores permite que os administradores controlem a quais endpoints específicos os criadores podem se conectar ao desenvolver apps, fluxos ou chatbots. Ele é configurado dentro de uma política de dados e está disponível exclusivamente para os seguintes conectores:

• HTTP
• HTTP com Microsoft Entra ID (AD)
• Gancho HTTP
• O SQL Server (inclui a utilização do Conector do SQL Server para aceder ao armazém de dados do Azure Synapse)
• Armazenamento de Blobs do Azure
• SMTP
• Automação do navegador
• Automação da interface do usuário

Quando um criador liga a sua aplicação, fluxo ou chatbot a um ponto final bloqueado, vê uma mensagem de erro da política de dados.

Adicionar regras de filtragem de pontos finais às suas políticas de dados

A coluna Ponto final configurável na página Conectores pré-criados em Políticas de Dados indica se a funcionalidade de filtragem de pontos finais é suportada para o conector.

Se o valor da coluna Ponto final configurável for Sim, poderá utilizar esta capacidade ao clicar com o botão direito do rato e selecionar Configurar conector>Pontos finais do conector.

Isso abre um painel lateral onde se 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 para novas políticas de dados, mas você pode marcá-lo como Permitir ou Negar.

Adicionar novas regras

Pode adicionar novas regras ao selecionar Adicionar ponto final. Novas regras são adicionadas ao final da lista de padrões como a penúltima regra. Isto porque * é a última entrada na lista. No entanto, pode atualizar a ordem dos padrões através da lista pendente Ordenar ou selecionar 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, em seguida, selecionando Excluir.

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

Limitações conhecidas

• As regras de filtragem de pontos finais não são aplicadas em variáveis de ambiente, entradas personalizadas e pontos finais vinculados dinamicamente durante o runtime. Só são aplicados pontos finais estáticos que são conhecidos e selecionados durante a criação de uma aplicação, um fluxo ou um chatbot. Isto significa que as regras de filtragem do ponto final do conetor para o SQL Server e o Armazenamento de Blobs do Azure não são aplicadas se as ligaçõ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 das 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 endpoint não são avaliadas e o fluxo de nuvem é executado com êxito.

  

  

• Power Apps publicados antes de 1 de outubro de 2020 têm de ser republicadas para que as regras de ação do conetor da política de dados e as regras do ponto final sejam aplicadas. O script a seguir permite que administradores e criadores identifiquem aplicativos que devem ser republicados para estar em conformidade com essas novas regras de controle granular da 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 pontos finais

Cada conector define um ponto de extremidade de forma diferente, e alguns pontos de extremidade podem estar em vários formatos. Assim, deve introduzir pontos finais em todos os formatos possíveis para bloquear os criadores de os utilizarem quando criam aplicações e fluxos. Os administradores podem inserir o nome completo do ponto de extremidade ou usar a correspondência de padrão 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 final, 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 é a predefinição, que pode ser alterada para Negar.

A seguinte orientação descreve como introduzir pontos finais de conector enquanto cria regras para permitir ou negar.

SQL Server

Liste os pontos de extremidade de conexão do "SQL Server" no formato <Server_name, database_name>. Alguns aspetos a ter em conta:

• Os criadores podem inserir o nome do servidor em vários formatos. Para indicar um endpoint, insira-o em todos os formatos possíveis. Por exemplo, as instâncias no local podem estar no formato <machine_name\named_instance, database_name> ou <IP address, custom port, database_name>. Neste caso, tem de aplicar regras de permissão ou negação em ambos os formatos para um ponto final. Por exemplo:

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

• Nenhuma lógica especial lida com endereços relativos como localhost. Assim, se bloquear *localhost*, bloqueia os criadores de utilizarem quaisquer pontos finais através do localhost como parte do ponto final de SQL Server. No entanto, isto não os impede de aceder ao ponto final através do endereço absoluto, a menos que o endereço absoluto também tenha sido bloqueado pelo administrador.

Eis 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 fabricante no <machine_name\named_instance> formato.)

  1. Permitir 11.22.33*
  2. Negar *

Dataverse

Os pontos de extremidade do Dataverse são representados pelo ID da organização, como 00aa00aa-bb11-cc22-dd33-44ee44ee44ee. Note que apenas o conector regular do Dataverse está atualmente no âmbito para a filtragem de pontos finais. A dinâmica do Dataverse e os conectores atuais do Dataverse não estão incluídos no âmbito de aplicação. Além disso, a instância local do Dataverse (também conhecido como ambiente atual) nunca pode ser bloqueada para utilização num ambiente. Isso significa que os fabricantes sempre podem acessar o ambiente atual do Dataverse em qualquer ambiente.

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 pontos finais do Dataverse para qualquer ambiente específico.

Armazenamento de Blobs do Azure

Os endpoints do Azure Blob Storage usam o nome da conta de armazenamento do Azure.

SMTP

Os pontos finais SMTP estão representados no formato <SMTP server address, port number>.

Veja um cenário de exemplo:

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 Web de HTTP com o conector do Microsoft Entra está fora do âmbito.

Eis um cenário de exemplo:

Permita o acesso apenas à página de subscrições do Azure no https://management.azure.com/.

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

Automação do navegador

Esta funcionalidade permite-lhe controlar as páginas Web a que um fluxo de ambiente de trabalho acede no Power Automate para ambiente de trabalho. Os pontos finais são representados no formato de URL ou no formato de nome de página da Web, e pode utilizar carateres universais para correspondência dinâmica de URL ou nome de página. A validação acontece durante as ações "Iniciar navegador da Web" ou "Ir para página da Web" antes que um fluxo da área de trabalho prossiga com as interações do navegador.

Veja um cenário de exemplo:

Permita o 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

Esta funcionalidade permite-lhe definir com que aplicações e ecrãs um fluxo de ambiente de trabalho pode interagir no Power Automate para ambiente de trabalho. Os pontos de extremidade são especificados usando o nome de processo do aplicativo. Quando o nome do processo é ApplicationFrameHost, Java ou Javaw — indicando uma Plataforma Universal do Windows (UWP) ou aplicativo Java onde 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. Os caracteres universais são suportados 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 (como mostrado pela seta na imagem). Normalmente, o elemento principal dos elementos relacionados da interface de utilizador é usado para determinar se a interação é autorizada.

As regras de filtragem de pontos finais não se aplicam a variáveis ou pontos de extremidade ligados dinamicamente. Se uma expressão incluir algo diferente de uma cadeia de caracteres literal, a filtragem será ignorada, potencialmente permitindo o acesso a argumentos de conector restritos. O comportamento de política predefinida é que todas as políticas de filtragem de ponto final incluem uma regra principal (Permitir * ou Negar *), com predefinição Permitir * (Permitir Tudo).

• Quando Permitir * é usado: os valores dinâmicos não são filtrados. Mesmo que aplicativos específicos sejam restritos, qualquer expressão dinâmica ignora a filtragem de endpoints.
• Quando Negar * é usado: Todos os valores dinâmicos são bloqueados por padrão, garantindo uma aplicação mais rigorosa.

Aqui está um cenário de exemplo. Para permitir o acesso a todos os aplicativos e telas, exceto aqueles em que o atributo Process ou Name é exatamente Calculator ou contém a string Java, você deve configurar as seguintes regras:

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

Suporte do PowerShell para filtragem de pontos finais

Configurar regras de filtragem de pontos finais para uma política

O objeto que contém regras de filtragem de pontos finais para uma política é designado por configurações do conetor.

O objeto de configuração 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
        }
      ) 
    }
  ) 
}

Notas

• A última regra para cada conector deve sempre ser aplicada à URL * para garantir que todas as URLs sejam cobertas pelas regras.
• A propriedade de ordem das regras para cada conector tem de utilizar os números 1 a N, em que N é o número de regras para esse conector.

Obter as configurações de conectores existentes para uma política de gestão de dados

Get-PowerAppDlpPolicyConnectorConfigurations 

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

New-PowerAppDlpPolicyConnectorConfigurations

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

Set-PowerAppDlpPolicyConnectorConfigurations

Exemplo

Objetivo:

Para o conector de SQL Server:

• Negar 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 de servidor: smtp.gmail.com, porta: 587)
• Negar todos os outros endereços

Para o conector HTTP:

• Permitir pontos finais https://mywebsite.com/allowedPath1 e https://mywebsite.com/allowedPath2
• Negar todos os outros 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