Filtraggio endpoint connettore (anteprima)

[Questo articolo fa parte della documentazione non definitiva, pertanto è soggetto a modifiche.]

Il filtro del connettore endpoint consente agli amministratori di determinare a quali specifici produttori di endpoint possono connettersi durante la creazione di app, flussi o chatbot. È configurato all'interno di un criterio di prevenzione della perdita di dati (DLP) ed è disponibile esclusivamente per sei connettori:

• HTTP
• HTTP con Microsoft Entra ID (AD)
• Webhook HTTP
• SQL Server (include l'utilizzo di SQL Server Connector per accedere data warehouse Azure Synapse)
• Spazio di Archiviazione BLOB di Azure
• SMTP

Quando un produttore tenta di connettere la propria app, flusso o chatbot a un endpoint bloccato, incontrerà un messaggio di errore DLP.

Aggiungi regole di filtraggio endpoint ai tuoi criteri DLP

La colonna Endpoint configurabile nella pagina Connettori predefiniti in Criteri dati indica se la funzionalità di filtro di endpoint è supportata per il connettore

Se il valore della colonna Endpoint configurabile è Sì, puoi utilizzare questa funzionalità facendo clic con il pulsante destro del mouse e scegliendo Configura connettore>Endpoint connettore.

Si apre un pannello laterale in cui è possibile specificare un elenco ordinato di modelli Consenti o Nega URL. L'ultima riga dell'elenco sarà sempre una regola per il carattere jolly (*), che si applica a tutti gli endpoint in quel connettore. Per impostazione predefinita, il modello * è Consenti nuovi criteri DLP, ma puoi contrassegnarlo come Consenti o Nega.

Aggiungi nuove regole

Puoi aggiungere nuove regole selezionando Aggiungi endpoint. Le nuove regole vengono aggiunte alla fine dell'elenco di modelli come penultima regola. Questo è perché * sarà sempre l'ultima voce nell'elenco. Tuttavia, puoi aggiornare l'ordine dei modelli utilizzando l'elenco a discesa Ordina o selezionando Sposta su o Sposta giù.

Dopo aver aggiunto un modello, puoi modificare o eliminare questi modelli selezionando una riga specifica e quindi Elimina.

Dopo aver salvato le regole di filtro degli endpoint del connettore e il criterio DLP in cui sono definite, vengono immediatamente applicate agli ambienti di destinazione. Di seguito è riportato un esempio in cui un produttore ha tentato di connettere il proprio flusso cloud a un HTTP endpoint non consentito.

Limitazioni note

• Le regole dei filtri endpoint non vengono applicate nelle variabili di ambiente, input personalizzati e negli endpoint associati dinamicamente durante il runtime. Vengono applicati solo gli endpoint statici noti selezionati durante la creazione di un'app, un flusso o un chatbot durante la fase di progettazione. Ciò implica che le regole dei filtri dell'endpoint del connettore per SQL Server e Azure Blob Storage non vengano applicate se le connessioni vengono autenticate con Microsoft Entra ID. Nei due screenshot seguenti, un autore ha creato un flusso cloud che definisce SQL Server e il database all'interno delle variabili, quindi utilizza tali variabili come input per la definizione della connessione. Pertanto, le regole di filtro endpoint non vengono valutate e il flusso cloud può essere eseguito correttamente.

  

• Alcune app Power Apps pubblicate prima del 1° ottobre 2020 devono essere ripubblicate per applicare le regole di azione e le regole endpoint del connettore DLP. Lo script seguente consente ad amministratori e autori di identificare le app che devono essere ripubblicate per rispettare queste nuove regole di controllo granulare 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 
      }
  }
  

Formati di input di endpoint ed esempi

Ogni connettore ha una nozione differente del significato di un endpoint. Inoltre, alcuni endpoint possono essere definiti in più formati. Di conseguenza gli endpoint devono essere immessi in tutti i formati possibili per impedire ai creatori di utilizzarli durante la creazione di app e flussi. Gli amministratori possono immettere il nome completo di un endpoint o utilizzare la corrispondenza del modello con il carattere jolly (*) durante la creazione di una regola di filtro di endpoint. Queste regole vengono immesse e presentate in un elenco ordinato di modelli endpoint, il che significa che verranno valutate in ordine crescente per numero. Si noti che l'ultima regola per ogni dato connettore è sempre * Consenti o * Nega. Consenti è l'impostazione predefinita, che può essere modificata in Nega.

Le istruzioni seguenti descrivono come immettere endpoint di connettore durante la creazione di regole per consentirli o negarli.

SQL Server

Gli endpoint di connessione di SQL Server devono essere elencati nel formato <Server_name, database_name>. Alcuni aspetti da tenere a mente:

• Il nome del server può essere immesso in vari formati dai creatori. Pertanto, per definire effettivamente un endpoint, questo deve essere immesso in tutti i formati possibili. Ad esempio, le istanze locali possono essere nel formato <machine_name\named_instance, database_name> o <IP address, custom port, database_name>. In questo caso, dovrai applicare regole di autorizzazione o blocco in entrambi i formati per un endpoint. Ad esempio:

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

• Non esiste una logica speciale per gestire indirizzi relativi come localhost. Pertanto, se blocchi *localhost*, impedirà ai creatori di utilizzare qualsiasi endpoint utilizzando localhost come parte dell'endpoint SQL Server. Tuttavia, non gli impedirà di accedere all'endpoint utilizzando l'indirizzo assoluto, a meno che anche l'indirizzo assoluto non sia stato bloccato dall'amministratore.

Di seguito sono illustrati alcuni esempi:

• Consentire solo istanze di Azure SQL Server:

  1. Consenti *.database.windows.net*
  2. Nega *

• Consenti solo un intervallo IP specifico: nota che gli indirizzi IP non consentiti possono comunque essere immessi dall'autore nel formato <machine_name\named_instance>:

  1. Consenti 11.22.33*
  2. Nega *

Dataverse

Gli endpoint Dataverse sono rappresentati da ID organizzazione, ad esempio, 7b97cd5c-ce38-4930-9497-eec2a95bf5f7. Nota che solo il connettore Dataverse normale rientra attualmente nell'ambito del filtro di endpoint. I connettori correnti Dataverse Dynamics e Dataverse non rientrano nell'ambito. Inoltre, l'istanza locale di Dataverse (nota anche come ambiente corrente) non può mai essere bloccata per l'uso in un ambiente. Ciò significa che in un determinato ambiente, i creatori possono sempre accedere all'ambiente Dataverse corrente.

Pertanto, una regola che indica quanto segue:

1. Consenti 7b97cd5c-ce38-4930-9497-eec2a95bf5f7
2. Nega *

In realtà significa:

1. Consenti Dataverse current environment
2. Consenti 7b97cd5c-ce38-4930-9497-eec2a95bf5f7
3. Nega *

Consenti Dataverse current environment è sempre implicitamente la prima regola nell'elenco di filtro di endpoint Dataverse per qualsiasi dato ambiente.

Spazio di Archiviazione BLOB di Azure

Gli endpoint di Archiviazione BLOB di Azure sono rappresentati dal nome dell'account di archiviazione di Azure.

SMTP

Gli endpoint SMTP sono rappresentati nel formato <SMTP server address, port number>.

Di seguito è riportato uno scenario di esempio:

1. Nega smtp.gmail.com,587
2. Consenti *

Connettori HTTP with Microsoft Entra ID, HTTP Webhook e HTTP

Gli endpoint per tutti i connettori HTTP sono rappresentati da un modello URL. L'azione Recupera risorsa Web del connettore HTTP con Microsoft Entra è fuori ambito.

Di seguito è riportato uno scenario di esempio:

Consentire l'accesso solo alla pagina degli abbonamenti di Azure in https://management.azure.com/.

1. Consenti https://management.azure.com/subscriptions*
2. Nega https://management.azure.com/*
3. Nega *

Supporto PowerShell per il filtro di endpoint

Configurare regole di filtro di endpoint per un criterio

L'oggetto che contiene regole di filtro di endpoint per un criterio è indicato di seguito come configurazioni del connettore.

L'oggetto configurazioni del connettore ha la seguente struttura:

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

Appunti

• Per garantire che le regole siano applicate a tutti gli URL *, l'ultima regola di ogni connettore deve sempre essere applicata all'URL.
• La proprietà order delle regole di ogni connettore deve essere popolata con numeri da 1 a N, dove N è il numero di regole per quel connettore.

Recupera le configurazioni dei connettori esistenti per una policy DLP

Get-PowerAppDlpPolicyConnectorConfigurations 

Creare configurazioni di connettori per una policy DLP

New-PowerAppDlpPolicyConnectorConfigurations

Aggiornare le configurazioni del connettore per una policy DLP

Set-PowerAppDlpPolicyConnectorConfigurations

Esempio

Obiettivo:

Per il connettore SQL Server:

• Nega database "testdatabase" del server "myservername.database.windows.net"
• Consenti tutti gli altri database del server "myservername.database.windows.net"
• Nega tutti gli altri server

Per il connettore SMTP:

• Consenti Gmail (indirizzo del server: smtp.gmail.com, porta: 587)
• Nega tutti gli altri indirizzi

Per il connettore HTTP:

• Consenti gli endpoint https://mywebsite.com/allowedPath1 e https://mywebsite.com/allowedPath2
• Nega tutti gli altri 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