Condividi tramite

Proteggere l'accesso e i dati per i flussi di lavoro in App per la logica di Azure

  • Articolo

App per la logica di Azure si basa su Archiviazione di Azure per archiviare e crittografare automaticamente i dati inattivi. Questa crittografia protegge i dati e consente di soddisfare gli obblighi di sicurezza e conformità dell'organizzazione. Per impostazione predefinita, Archiviazione di Azure usa chiavi gestite da Microsoft per crittografare i dati. Per altre informazioni, vedere Crittografia di Archiviazione di Azure per dati inattivi.

Per controllare ulteriormente l'accesso e proteggere i dati sensibili in App per la logica di Azure, è possibile configurare una maggiore sicurezza per queste aree:

Per altre informazioni sulla sicurezza in Azure, vedere questi argomenti:

Accesso alle operazioni di app per la logica

Per le app per la logica a A consumo, prima di poter creare o gestire app per la logica e le relative connessioni, sono necessarie autorizzazioni specifiche, fornite tramite ruoli usando il controllo degli accessi in base al ruolo di Azure (Azure RBAC). È anche possibile configurare le autorizzazioni in modo che solo utenti o gruppi specifici possano eseguire determinate attività, ad esempio la gestione, la modifica e la visualizzazione di app per la logica. Per controllare le autorizzazioni, è possibile assegnare ruoli predefiniti o personalizzati ai membri che hanno accesso alla sottoscrizione di Azure. App per la logica di Azure ha i ruoli specifici seguenti, a seconda che si abbia un flusso di lavoro di app per la logica A consumo o Standard:

Flussi di lavoro A consumo
Ruolo Descrizione
Collaboratore per app per la logica È possibile gestire flussi di lavoro di app per la logica, ma non è possibile modificarne l'accesso.
Operatore per app per la logica È possibile leggere, abilitare e disabilitare flussi di lavoro di app per la logica, ma non è possibile modificarli né aggiornarli.
Collaboratore Accesso completo per la gestione di tutte le risorse, ma non è possibile assegnare ruoli in Controllo degli accessi in base al ruolo (RBAC) di Azure, né gestire le assegnazioni in Azure Blueprints né condividere raccolte di immagini.

Si supponga, ad esempio, di dover usare un flusso di lavoro dell’app per la logica che non è stato creato e autenticare le connessioni usate da tale flusso di lavoro dell'app per la logica. La sottoscrizione di Azure richiede autorizzazioni Collaboratore per il gruppo di risorse contenente la risorsa dell'app per la logica. Se si crea una risorsa dell'app per la logica, si dispone automaticamente dell'accesso Collaboratore.

Per impedire ad altri la modifica o l'eliminazione del flusso di lavoro dell’app per la logica, è possibile usare il Blocco delle risorse di Azure. Questa funzionalità impedisce ad altri utenti di modificare o eliminare le risorse di produzione. Per altre informazioni sulla sicurezza delle connessioni, vedere Configurazione della connessione in App per la logica di Azure e Sicurezza e crittografia delle connessioni.

Flussi di lavoro Standard

Nota

Questa funzionalità è in anteprima ed è soggetta alle Condizioni supplementari per l'utilizzo per le anteprime di Microsoft Azure.

Ruolo Descrizione
Lettore Standard di App per la logica (anteprima) È possibile accedere in sola lettura a tutte le risorse in un'app per la logica Standard e ai flussi di lavoro, incluse le esecuzioni del flusso di lavoro e la relativa cronologia.
Operatore Standard di App per la logica (anteprima) È possibile accedere per abilitare, inviare di nuovo e disabilitare i flussi di lavoro e per creare connessioni a servizi, sistemi e reti per un'app per la logica Standard. Il ruolo Operatore può eseguire attività di amministrazione e supporto nella piattaforma App per la logica di Azure, ma non dispone delle autorizzazioni per modificare flussi di lavoro o impostazioni.
Sviluppatore Standard di App per la logica (anteprima) È possibile accedere per creare e modificare flussi di lavoro, connessioni e impostazioni per un'app per la logica Standard. Il ruolo Sviluppatore non dispone delle autorizzazioni per apportare modifiche all'esterno dell'ambito dei flussi di lavoro, ad esempio modifiche a livello di applicazione, come la configurazione dell'integrazione della rete virtuale. I piani Servizio app non sono supportati.
Collaboratore Standard di App per la logica (anteprima) È possibile accedere per gestire tutti gli aspetti di un'app per la logica Standard, ma non è possibile modificare l'accesso o la proprietà.

Accesso ai dati della cronologia di esecuzione

Durante l'esecuzione di un'app per la logica, tutti i dati vengono crittografati durante il transito tramite Transport Layer Security (TLS) e sono inattivi. Al termine dell'esecuzione dell'app per la logica, è possibile visualizzare la cronologia dell'esecuzione, inclusi i passaggi eseguiti con lo stato, la durata, gli input e gli output per ogni azione. Questo approfondimento fornisce informazioni dettagliate sulle modalità di esecuzione dell'app per la logica e su dove è possibile iniziare la risoluzione dei problemi che si verificano.

Quando si visualizza la cronologia di esecuzione di un'app per la logica, App per la logica di Azure autentica l'accesso e fornisce i collegamenti agli input e agli output per le richieste e le risposte per ogni esecuzione. Tuttavia, per le azioni che gestiscono password, segreti, chiavi o altre informazioni riservate, è opportuno impedire ad altri utenti di visualizzare e accedere a tali dati. Ad esempio, se l'app per la logica ottiene un segreto da Azure Key Vault da usare per l'autenticazione di un'azione HTTP, occorre nascondere tale segreto in modo che non venga visualizzato.

Per controllare l'accesso agli input e agli output nella cronologia di esecuzione dell'app per la logica, sono disponibili le opzioni seguenti:

Limitare l'accesso in base all'intervallo di indirizzi IP

È possibile limitare l'accesso agli input e agli output nella cronologia di esecuzione per i flussi di lavoro dell'app per la logica, in modo che solo le richieste provenienti da intervalli di indirizzi IP specifici possano visualizzare tali dati.

Ad esempio, per impedire a tutti gli utenti di accedere a input e output, specificare un intervallo di indirizzi IP come 0.0.0.0-0.0.0.0. Questa restrizione può essere rimossa solo da una persona con autorizzazioni di amministratore che fornisce l'accesso "just-in-time" ai dati nei flussi di lavoro dell'app per la logica. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x

Per specificare gli intervalli IP consentiti, seguire questa procedura per l'app per la logica A consumo o Standard nel portale di Azure o nel modello di Azure Resource Manager:

Flussi di lavoro A consumo

  1. Nel portale di Azure, aprire il flusso di lavoro dell'app per la logica A consumo nella finestra di progettazione.

  2. Nel menu dell'app per la logica, in Impostazioni, selezionare Impostazioni del flusso di lavoro.

  3. Nella sezione Configurazione del controllo di accesso, in Indirizzi IP in ingresso consentiti, dall'elenco Opzione accesso trigger, selezionare Intervalli IP specifici.

  4. Nella casella Intervalli IP per contenuti, specificare gli intervalli di indirizzi IP che possono accedere ai contenuti da input e output.

Flussi di lavoro Standard

  1. Nel portale di Azure, aprire la risorsa dell’app per la logica Standard.

  2. Nel menu dell'app per la logica, in Impostazioni, selezionare Rete.

  3. Nella sezione Configurazione del traffico in ingresso, accanto ad Accesso alla rete pubblica, selezionare Abilitato senza restrizioni di accesso.

  4. Nella pagina Restrizioni di accesso, in Accesso alle app, selezionare Abilitato da reti virtuali e indirizzi IP selezionati.

  5. In Accesso e regole del sito, nella scheda Sito principale, aggiungere una o più regole alle richieste Consenti o Nega da intervalli IP specifici. È possibile anche usare le impostazioni del filtro intestazione HTTP e le impostazioni di inoltro. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x

    Per altre informazioni, vedere Blocco degli indirizzi IP in ingresso in App per la logica di Azure (Standard).

Proteggere i dati nella cronologia di esecuzione usando l'offuscamento

Molti trigger e azioni hanno impostazioni per la protezione degli input, degli output o di entrambi dalla cronologia di esecuzione di un'app per la logica. Tutti i connettori gestiti e i connettori personalizzati supportano queste opzioni. Tuttavia, le operazioni predefinite seguenti non supportano queste opzioni:

Input sicuri - Non supportato Output sicuri - Non supportato
Accoda a variabile di matrice
Accoda a variabile di stringa
Decrementare una variabile
For each
Se
Incrementare una variabile
Inizializzare una variabile
Ricorrenza
Scope
Impostare una variabile
Opzione
Terminazione
Fino a		 Accoda a variabile di matrice
Accoda a variabile di stringa
Composizione
Decrementare una variabile
For each
Se
Incrementare una variabile
Inizializzare una variabile
Analizzare JSON
Ricorrenza
Risposta
Scope
Impostare una variabile
Opzione
Terminazione
Until
Wait.

Considerazioni sulla protezione di input e output

Prima di usare queste impostazioni per facilitare la protezione di questi dati, esaminare le considerazioni seguenti:

  • Quando si oscurano gli input o gli output in un trigger o un'azione, App per la logica di Azure non invia i dati protetti ad Azure Log Analytics. Non è inoltre possibile aggiungere proprietà rilevate a tale trigger o azione per il monitoraggio.

  • L’API di App per la logica di Azure per la gestione della cronologia del flusso di lavoro non restituisce output protetti.

  • Per proteggere gli output da un'azione che nasconde gli input o nasconde in modo esplicito gli output, attivare manualmente gli output protetti in tale azione.

  • Assicurarsi di attivare gli input protetti o gli output protetti nelle azioni downstream in cui si prevede che la cronologia di esecuzione nasconda i dati.

    Impostazione degli output protetti

    Quando si attivano manualmente gli Output protetti in un trigger o un'azione, App per la logica di Azure nasconde questi output nella cronologia di esecuzione. Se un'azione downstream usa in modo esplicito questi output protetti come input, App per la logica di Azure nasconde gli input di tale azione nella cronologia di esecuzione, ma non abilita l'impostazione Input protetti dell'azione.

    Output protetti come input e effetto downstream sulla maggior parte delle azioni

    Le azioni Compose, Parse JSON e Response hanno solo l'impostazione degliinput protetti. Se attivata, l'impostazione nasconde anche gli output di tali azioni. Se queste azioni usano in modo esplicito gli output protetti upstream come input, App per la logica di Azure nasconde gli input e gli output di tali azioni, ma non abilita l'impostazione Input protetti delle azioni. Se un'azione downstream usa in modo esplicito gli output nascosti delle azioni Compose, Parse JSON o Response come input, App per la logica di Azure non nasconde gli input o gli output di tale azione downstream.

    Output protetti come input con effetto downstream su azioni specifiche

    Impostazione degli input protetti

    Quando si attivano manualmente gli Input protetti in un trigger o un'azione, App per la logica di Azure nasconde questi input nella cronologia di esecuzione. Se un'azione downstream usa in modo esplicito gli output visibili da tale trigger o azione come input, App per la logica di Azure nasconde gli input di tale azione downstream nella cronologia di esecuzione, ma non abilita gli Input protetti in questa azione e non nasconde gli output di tale azione.

    Input protetti e effetto downstream sulla maggior parte delle azioni

    Se le azioni Compose, Parse JSON e Response usano in modo esplicito gli output visibili del trigger o dell'azione con gli input protetti, App per la logica di Azure nasconde gli input e gli output di tali azioni, ma non abilita l'impostazione Input protetti di tali azioni. Se un'azione downstream usa in modo esplicito gli output nascosti delle azioni Compose, Parse JSON o Response come input, App per la logica di Azure non nasconde gli input o gli output di tale azione downstream.

    Input protetti e effetto downstream su azioni specifiche

Proteggere gli input e gli output nella finestra di progettazione

  1. Nel portale di Azure, aprire il flusso di lavoro dell'app per la logica nella finestra di progettazione.

  2. Nella finestra di progettazione, selezionare il trigger o l’azione di cui proteggere dati sensibili.

  3. Nel riquadro delle informazioni visualizzato, selezionare Impostazioni ed espandere Sicurezza.

    Screenshot che mostra il portale di Azure, la finestra di progettazione del flusso di lavoro e il trigger o l'azione con le impostazioni aperte.

  4. Attivare Input protetti, Output protetti o entrambi.

    Screenshot che mostra il flusso di lavoro con le impostazioni Input sicuri e Output sicuri di un'azione abilitate.

    A questo punto, il trigger o l'azione trigger mostra un'icona a forma di lucchetto nella barra del titolo. Anche i token che rappresentano output protetti dalle azioni precedenti mostrano icone a forma di lucchetto. Ad esempio, in un'azione successiva, dopo aver selezionato un token per un output protetto dall'elenco di contenuto dinamico, tale token mostra un'icona a forma di lucchetto.

    Screenshot che mostra un flusso di lavoro con l'elenco di contenuto dinamico di un'azione successiva aperto e il token dell'azione precedente per l'output protetto con l'icona a forma di lucchetto.

  5. Dopo l'esecuzione del flusso di lavoro, è possibile visualizzare la cronologia per tale esecuzione.

    1. Selezionare Panoramica nel menu App per la logica A consumo o nel menu Flusso di lavoro Standard.

    2. In Cronologia esecuzioni, selezionare l'esecuzione da visualizzare.

    3. Nel riquadro della cronologia di esecuzione del flusso di lavoro, selezionare le azioni da esaminare.

      Se si è scelto di nascondere sia gli input che gli output, questi valori ora appaiono nascosti.

      Screenshot che mostra la vista della cronologia di esecuzione del flusso di lavoro Standard con input e output nascosti.

Proteggere gli input e gli output nella visualizzazione codice

Nel trigger sottostante o nella definizione di azione aggiungere o aggiornare la matrice runtimeConfiguration.secureData.properties con uno o entrambi i valori seguenti:

  • "inputs": protegge gli input nella cronologia di esecuzione.
  • "outputs": protegge gli output nella cronologia di esecuzione.
"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Accesso agli input dei parametri

Se si esegue la distribuzione in ambienti diversi, provare a parametrizzare i valori nella definizione del flusso di lavoro che variano in base a tali ambienti. In questo modo, è possibile evitare i dati hardcoded usando un modello di Azure Resource Manager per distribuire l'app per la logica, proteggere i dati sensibili definendo parametri protetti e passare i dati come input distinti tramite i parametri del modello usando un file di parametri.

Ad esempio, se si autenticano azioni HTTP con OAuth con Microsoft Entra ID, è possibile definire e oscurare i parametri che accettano l'ID client e il segreto client usati per l'autenticazione. Per definire questi parametri nel flusso di lavoro dell'app per la logica, usare la sezione parameters nella definizione del flusso di lavoro dell'app per la logica e il modello di Resource Manager per la distribuzione. Per proteggere i valori di parametro che non si vogliono mostrare quando si modifica l'app per la logica o si visualizza la cronologia di esecuzione, definire i parametri usando il tipo securestring o secureobjecte usare la codifica in base alle esigenze. I parametri con questo tipo non vengono restituiti con la definizione della risorsa e non sono accessibili quando si visualizza la risorsa dopo la distribuzione. Per accedere a questi valori di parametro durante la fase di esecuzione, usare l'espressione @parameters('<parameter-name>') all'interno della definizione del flusso di lavoro. Questa espressione viene valutata solo in fase di esecuzione e viene descritta dal linguaggio di definizione del flusso di lavoro.

Nota

Se si usa un parametro nelle intestazioni o nel corpo della richiesta, tale parametro potrebbe essere visibile quando si visualizza la cronologia di esecuzione del flusso di lavoro e la richiesta HTTP in uscita. Assicurarsi anche di configurare di conseguenza i criteri di accesso ai contenuti. È possibile anche usare l'offuscamento per nascondere gli input e gli output nella cronologia di esecuzione. Per impostazione predefinita, le intestazioni Authorization non sono mai visibili tramite input o output. Se quindi viene usato un segreto, questo non sarà recuperabile.

Per altre informazioni, vedere le sezioni in questo argomento:

Se si automatizza la distribuzione per le app per la logica usando i modelli di Resource Manager, è possibile definire i parametri del modello protetti, che vengono valutati in fase di distribuzione, usando i tipi securestring e secureobject. Per definire i parametri del modello, usare la sezione parameters di primo livello del modello, che è separata e diversa dalla sezione parameters della definizione del flusso di lavoro. Per specificare i valori per i parametri del modello, usare un file di parametro separato.

Ad esempio, se si usano i segreti, è possibile definire e usare i parametri di modello protetti che recuperano i segreti da Azure Key Vault in fase di distribuzione. Quindi è possibile fare riferimento all'insieme di credenziali delle chiavi e alla chiave privata nel file dei parametri. Per altre informazioni, vedere questi argomenti:

Proteggere i parametri nelle definizioni del flusso di lavoro (flusso di lavoro A consumo)

Per proteggere informazioni sensibili nella definizione del flusso di lavoro dell'app per la logica, usare parametri protetti in modo che queste informazioni non siano visibili dopo il salvataggio del flusso di lavoro dell'app per la logica. Si supponga, ad esempio, che un'azione HTTP richieda l'autenticazione di base, che usa un nome utente e una password. Nella definizione del flusso di lavoro, la sezione parameters definisce i parametri basicAuthPasswordParam e basicAuthUsernameParam usando il tipo securestring. La definizione dell'azione fa quindi riferimento a questi parametri nella sezione authentication.

"definition": {
   "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
   "actions": {
      "HTTP": {
         "type": "Http",
         "inputs": {
            "method": "GET",
            "uri": "https://www.microsoft.com",
            "authentication": {
               "type": "Basic",
               "username": "@parameters('basicAuthUsernameParam')",
               "password": "@parameters('basicAuthPasswordParam')"
            }
         },
         "runAfter": {}
      }
   },
   "parameters": {
      "basicAuthPasswordParam": {
         "type": "securestring"
      },
      "basicAuthUsernameParam": {
         "type": "securestring"
      }
   },
   "triggers": {
      "manual": {
         "type": "Request",
         "kind": "Http",
         "inputs": {
            "schema": {}
         }
      }
   },
   "contentVersion": "1.0.0.0",
   "outputs": {}
}

Proteggere i parametri nei modelli di Azure Resource Manager (flusso di lavoro A consumo)

Un modello di Resource Manager per una risorsa e un flusso di lavoro di un'app per la logica include più sezioni parameters. Per proteggere password, chiavi, segreti e altre informazioni riservate, definire parametri protetti a livello di modello e di definizione del flusso di lavoro usando il tipo securestring o secureobject. È quindi possibile archiviare questi valori in Azure Key Vault e usare il file di parametri per fare riferimento all'insieme di credenziali delle chiavi e al segreto. Il modello recupera quindi tali informazioni in fase di distribuzione. Per altre informazioni, vedere Passare valori sensibili alla distribuzione usando Azure Key Vault.

Questo elenco include altre informazioni su queste sezioni parameters:

  • Al livello principale del modello, una sezione parameters definisce i parametri per i valori usati dal modello in fase di distribuzione. Questi valori, ad esempio, possono includere stringhe di connessione per un ambiente di distribuzione specifico. È quindi possibile archiviare questi valori in un file di parametro separato, rendendo più semplice la modifica di questi valori.

  • All'interno della definizione di risorsa dell'app per la logica, ma all'esterno della definizione del flusso di lavoro, una sezione parameters specifica i valori per i parametri della definizione del flusso di lavoro. In questa sezione è possibile assegnare questi valori usando espressioni di modello che fanno riferimento ai parametri del modello. Queste espressioni vengono valutate in fase di distribuzione.

  • All'interno della definizione del flusso di lavoro, una sezione parameters definisce i parametri che il flusso di lavoro dell'app per la logica usa in fase di esecuzione. È quindi possibile fare riferimento a questi parametri nel flusso di lavoro dell'app per la logica usando le espressioni di definizione del flusso di lavoro, che vengono valutate in fase di esecuzione.

Questo modello di esempio ha più definizioni di parametro protette che usano il tipo securestring:

Nome parametro Descrizione
TemplatePasswordParam Parametro di modello che accetta una password che viene quindi passata al parametro basicAuthPasswordParam della definizione del flusso di lavoro
TemplateUsernameParam Parametro di modello che accetta un nome utente che viene quindi passato al parametro basicAuthUserNameParam della definizione del flusso di lavoro
basicAuthPasswordParam Parametro di definizione del flusso di lavoro che accetta la password per l'autenticazione di base in un'azione HTTP
basicAuthUserNameParam Parametro di definizione del flusso di lavoro che accetta il nome utente per l'autenticazione di base in un'azione HTTP 
{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {
      "LogicAppName": {
         "type": "string",
         "minLength": 1,
         "maxLength": 80,
         "metadata": {
            "description": "Name of the Logic App."
         }
      },
      "TemplatePasswordParam": {
         "type": "securestring"
      },
      "TemplateUsernameParam": {
         "type": "securestring"
      },
      "LogicAppLocation": {
         "type": "string",
         "defaultValue": "[resourceGroup().location]",
         "allowedValues": [
            "[resourceGroup().location]",
            "eastasia",
            "southeastasia",
            "centralus",
            "eastus",
            "eastus2",
            "westus",
            "northcentralus",
            "southcentralus",
            "northeurope",
            "westeurope",
            "japanwest",
            "japaneast",
            "brazilsouth",
            "australiaeast",
            "australiasoutheast",
            "southindia",
            "centralindia",
            "westindia",
            "canadacentral",
            "canadaeast",
            "uksouth",
            "ukwest",
            "westcentralus",
            "westus2"
         ],
         "metadata": {
            "description": "Location of the Logic App."
         }
      }
   },
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
               "actions": {
                  "HTTP": {
                     "type": "Http",
                     "inputs": {
                        "method": "GET",
                        "uri": "https://www.microsoft.com",
                        "authentication": {
                           "type": "Basic",
                           "username": "@parameters('basicAuthUsernameParam')",
                           "password": "@parameters('basicAuthPasswordParam')"
                        }
                     },
                  "runAfter": {}
                  }
               },
               "parameters": {
                  "basicAuthPasswordParam": {
                     "type": "securestring"
                  },
                  "basicAuthUsernameParam": {
                     "type": "securestring"
                  }
               },
               "triggers": {
                  "manual": {
                     "type": "Request",
                     "kind": "Http",
                     "inputs": {
                        "schema": {}
                     }
                  }
               },
               "contentVersion": "1.0.0.0",
               "outputs": {}
            },
            "parameters": {
               "basicAuthPasswordParam": {
                  "value": "[parameters('TemplatePasswordParam')]"
               },
               "basicAuthUsernameParam": {
                  "value": "[parameters('TemplateUsernameParam')]"
               }
            }
         }
      }
   ],
   "outputs": {}
}

Tipi di autenticazione per i connettori che supportano l'autenticazione

La tabella seguente identifica i tipi di autenticazione disponibili nelle operazioni del connettore in cui è possibile selezionare un tipo di autenticazione:

Tipo di autenticazione App per la logica e connettori supportati
Base Gestione API di Azure, servizio app di Azure, HTTP, HTTP + Swagger, HTTP Webhook
Certificato client Gestione API di Azure, servizio app di Azure, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth - A consumo: Gestione API di Azure, Servizi app di Azure, Funzioni di Azure, HTTP, HTTP + Swagger, Webhook HTTP

- Standard: Automazione di Azure, Archiviazione BLOB di Azure, Hub eventi di Azure, Code di Azure, Bus di servizio di Azure, Tabelle di Azure, HTTP, Webhook HTTP, SQL Server
Raw Gestione API di Azure, servizi app di Azure, Funzioni di Azure, HTTP, HTTP + Swagger, HTTP Webhook
Identità gestita Connettori predefiniti:

- A consumo: Gestione API di Azure, Servizi app di Azure, Funzioni di Azure, HTTP, Webhook HTTP

- Standard: Automazione di Azure, Archiviazione BLOB di Azure, Hub eventi di Azure, Code di Azure, Bus di servizio di Azure, Tabelle di Azure, HTTP, Webhook HTTP, SQL Server

Nota: attualmente, la maggior parte dei connettori predefiniti basati su provider di servizi non supporta la selezione di identità gestite assegnate dall'utente per l'autenticazione.

Connettori gestiti: Servizio app di Azure, Automazione di Azure, Archiviazione BLOB di Azure, Istanza di contenitore di Azure, Azure Cosmos DB, Esplora dati di Azure, Azure Data Factory, Data Lake di Azure, Griglia di eventi di Azure, Hub eventi di Azure, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Code di Azure, Azure Resource Manager, Bus di servizio di Azure, Azure Sentinel, Archiviazione tabelle di Azure, Macchina virtuale di Azure, HTTP con Microsoft Entra ID, SQL Server

Accesso per le chiamate in ingresso ai trigger basati su richiesta

Le chiamate in ingresso ricevute da un'app per la logica tramite un trigger basato su richiesta, ad esempio il trigger Richiesta o il trigger Webhook HTTP, supportano la crittografia e sono protetti con Transport Layer Security (TLS) 1.2 almeno, precedentemente noto come Secure Sockets Layer (SSL). App per la logica di Azure applica questa versione quando viene ricevuta una chiamata in ingresso al trigger Richiesta o un callback al trigger o all'azione Webhook HTTP. Se si verificano errori di handshake TLS, assicurarsi di usare TLS 1.2. Per altre informazioni, vedere Risoluzione del problema relativo a TLS 1.0.

Per le chiamate in ingresso, usare le suite di crittografia seguenti:

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Nota

Per la compatibilità con le versioni precedenti, App per la logica di Azure supporta attualmente alcune suite di crittografia meno recenti. Tuttavia, non usare suite di crittografia meno recenti quando si sviluppano nuove app, perché tali suite potrebbero non essere supportate in futuro.

Ad esempio, è possibile trovare le suite di crittografia seguenti se si esaminano i messaggi di handshake TLS durante l'uso del servizio App per la logica di Azure o usando uno strumento di sicurezza nell'URL dell'app per la logica. Anche in questo caso, non usare queste suite meno recenti:

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

L'elenco seguente include altri modi per limitare l'accesso ai trigger che ricevono chiamate in ingresso all'app per la logica in modo che solo i client autorizzati possano chiamare l'app per la logica:

Generare firme di accesso condiviso (SAS)

Ogni endpoint di richiesta a un'app per la logica ha una firma di accesso condiviso (Shared Access Signature - SAS) come parte dell'URL, che segue il formato seguente:

https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>

Ogni URL contiene i parametri di query sp, sve sig come descritto nella tabella seguente:

Query parameter (Parametro di query) Descrizione
sp Specifica le autorizzazioni per i metodi HTTP consentiti.
sv Specifica la versione usata per generare la firma.
sig Specifica la firma da usare per l'autenticazione dell'accesso al trigger. La firma viene generata attraverso l'algoritmo SHA256 con una chiave di accesso privata in tutti i percorsi e le proprietà dell'URL. Questa chiave viene mantenuta crittografata, archiviata con l’app per la logica, e non viene mai esposta né pubblicata. L'app per la logica autorizza solo i trigger che contengono una firma valida creata con la chiave privata.

Le chiamate in ingresso a un endpoint richiesta possono usare un solo schema di autorizzazione, SAS oppure OAuth con Microsoft Entra ID. Anche se l'uso di uno schema non disabilita l'altro schema, l'uso contemporaneo di entrambi gli schemi causa un errore perché il servizio non riconosce lo schema da scegliere.

Per altre informazioni sulla protezione dell'accesso con SAS, vedere queste sezioni in questo argomento:

Per rigenerare le chiavi di accesso

È possibile generare in qualsiasi momento una nuova chiave di accesso protetta tramite il portale di Azure o API REST. Tutti gli URL generati in precedenza usando la chiave precedente verranno invalidati e non avranno più l'autorizzazione per attivare l'app per la logica. Per accedere agli URL recuperati dopo la rigenerazione, è necessaria la nuova chiave di accesso.

  1. Nel portale di Azure aprire l'app per la logica che contiene la chiave che si desidera rigenerare.

  2. Nel menu della risorsa dell’app per la logica, in Impostazioni selezionare Chiavi di accesso.

  3. Scegliere la chiave da rigenerare e completare il processo.

Creare URL di callback in scadenza

Se si condivide l'URL dell'endpoint per un trigger di richiesta con altre parti è possibile generare gli URL di callback che usano chiavi specifiche e hanno delle date di scadenza. In questo modo è possibile aggiornare le chiavi senza problemi o limitare l'accesso per attivare l'app per la logica sulla base di un determinato lasso di tempo. Per specificare una data di scadenza per un URL, usare l'API REST di App per la logica di Azure, ad esempio:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01

Nel corpo includere la NotAfterproprietà usando una stringa di data JSON. Questa proprietà restituisce un URL di callback valido solo fino a data e ora NotAfter.

Creare URL con una chiave privata primaria o secondaria

Quando si generano URL di callback per i trigger basati su richieste, è possibile specificare la chiave da usare per firmare l'URL. Per generare un URL firmato da una chiave specifica usare l'API REST delle app per la logica, ad esempio:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01

Nel corpo includere la proprietà KeyType come Primary o Secondary. Questa proprietà restituisce un URL firmato dalla chiave di sicurezza specificata.

Abilitare Open Authentication con Microsoft Entra ID (OAuth con Microsoft Entra ID)

In un flusso di lavoro dell'app per la logica A consumo che inizia con un trigger basato su richiesta, è possibile autenticare le chiamate in ingresso inviate all'endpoint creato da tale trigger abilitando OAuth con Microsoft Entra ID. Per configurare questa autenticazione, definire o aggiungere un criterio di autorizzazione a livello di app per la logica. In questo modo, le chiamate in ingresso usano token di accesso OAuth per l'autorizzazione.

Quando il flusso di lavoro dell'app per la logica riceve una richiesta in ingresso che include un token di accesso OAuth, App per la logica di Azure confronta le attestazioni del token con le attestazioni specificate in ogni criterio di autorizzazione. Se esiste una corrispondenza tra le attestazioni del token e tutte le attestazioni in almeno un criterio, l'autorizzazione ha esito positivo per la richiesta in ingresso. Il token può avere più attestazioni rispetto al numero specificato dal criterio di autorizzazione.

In un flusso di lavoro dell'app per la logica Standard che inizia con il trigger Richiesta (ma non con un trigger Webhook), è possibile usare il provisioning di Funzioni di Azure per autenticare le chiamate in ingresso inviate all'endpoint creato da tale trigger usando un'identità gestita. Questo provisioning è noto anche come "Easy Auth". Per altre informazioni, vedere Attivare flussi di lavoro in app per la logica Standard con Easy Auth

Considerazioni prima dell’abilitazione di OAuth con Microsoft Entra ID

  • Una chiamata in ingresso a un endpoint richiesta può usare un solo schema di autorizzazione, OAuth con Microsoft Entra ID o la firma di accesso condiviso (SAS). Anche se l'uso di uno schema non disabilita l'altro schema, l'uso contemporaneo di entrambi gli schemi causa un errore perché App per la logica di Azure non riconosce lo schema da scegliere.

  • App per la logica di Azure supporta gli schemi di autorizzazione tipo Bearer o il tipo Proof-of-Possession (solo app per la logica A consumo) per i token di accesso OAuth con Microsoft Entra ID. Tuttavia, l'intestazione Authorization per il token di accesso deve specificare il tipo Bearer o il tipo PoP. Per altre informazioni su come ottenere e usare un token PoP, vedere Ottenere un token PoP (Proof of Possession).

  • La risorsa dell'app per la logica è limitata a un numero massimo di criteri di autorizzazione. Ogni criterio di autorizzazione ha anche un numero massimo di attestazioni. Per altre informazioni, vedere Limiti e configurazione per App per la logica di Azure.

  • Un criterio di autorizzazione deve includere almeno l'attestazione dell'Emittente, che ha un valore che inizia con https://sts.windows.net/ o https://login.microsoftonline.com/ (OAuth V2) come emittente di Microsoft Entra ID.

    Si supponga, ad esempio, che la risorsa dell'app per la logica disponga di un criterio di autorizzazione che richiede due tipi di attestazione: Destinatari ed Emittente. Questa sezione payload di esempio per un token di accesso decodificato include entrambi i tipi di attestazione, dove aud è il valore di Destinatari e iss è il valore di Emittente:

    {
    "aud": "https://management.core.windows.net/",
    "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/",
    "iat": 1582056988,
    "nbf": 1582056988,
    "exp": 1582060888,
    "_claim_names": {
       "groups": "src1"
    },
    "_claim_sources": {
       "src1": {
          "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects"
       }
    },
    "acr": "1",
    "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=",
    "amr": [
       "rsa",
       "mfa"
    ],
    "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c",
    "appidacr": "2",
    "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab",
    "family_name": "Sophia Owen",
    "given_name": "Sophia Owen (Fabrikam)",
    "ipaddr": "167.220.2.46",
    "name": "sophiaowen",
    "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7",
    "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475",
    "puid": "1003000000098FE48CE",
    "scp": "user_impersonation",
    "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k",
    "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

Abilitare OAuth con Microsoft Entra ID come unica opzione per chiamare un endpoint richiesta

  1. Configurare il trigger Richiesta o Webhook HTTP con la possibilità di controllare il token di accesso OAuth seguendo la procedura per includere l'intestazione "Autorizzazione" negli output del trigger Richiesta o Webhook HTTP.

    Nota

    Questo passaggio rende visibile l'intestazione Authorization nella cronologia di esecuzione del flusso di lavoro e negli output del trigger.

  2. Nel portale di Azure, aprire il flusso di lavoro dell'app per la logica A consumo nella finestra di progettazione.

  3. Nella finestra di progettazione, selezionare il trigger. Nel riquadro delle informazioni visualizzato, selezionare Impostazioni.

  4. In Generale>Condizioni trigger, selezionare Aggiungi. Nella casella condizione del trigger, immettere una delle espressioni seguenti, in base al tipo di token da usare:

    @startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')

    oppure

    @startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')

Se si chiama l'endpoint del trigger senza l'autorizzazione corretta, la cronologia di esecuzione mostra solo il trigger come Skipped senza alcun messaggio che la condizione del trigger non è riuscita.

Ottenere un token Proof-of-Possession (PoP)

Le librerie MSAL (Microsoft Authentication Library) forniscono i token PoP da usare. Se il flusso di lavoro dell'app per la logica da chiamare richiede un token PoP, è possibile ottenere questo token usando le librerie MSAL. Gli esempi seguenti illustrano come acquisire i token PoP:

Per usare il token PoP con il flusso di lavoro dell'app per la logica A consumo, seguire la sezione successiva per configurare OAuth con Microsoft Entra ID.

Abilitare OAuth con Microsoft Entra ID per la risorsa dell'app per la logica A consumo

Seguire questa procedura per il portale di Azure o il modello di Azure Resource Manager:

Nel portale di Azure, aggiungere uno o più criteri di autorizzazione alla risorsa dell'app per la logica A consumo:

  1. Nel portale di Azure, aprire l'app per la logica A consumo nella finestra di progettazione del flusso di lavoro.

  2. Nel menu della risorsa dell’'app per la logica, in Impostazioni, selezionare Autorizzazione. Dopo l'apertura del riquadro Autorizzazione, selezionare Aggiungi criteri.

    Screenshot che mostra il portale di Azure, il menu dell'app per la logica A consumo, la pagina Autorizzazione e il pulsante selezionato per aggiungere il criterio.

  3. Fornire informazioni sul criterio di autorizzazione specificando i tipi di attestazione e i valori previsti dall'app per la logica nel token di accesso presentato da ogni chiamata in ingresso al trigger Richiesta:

    Screenshot che mostra il portale di Azure, la pagina Autorizzazione dell'app per la logica A consumo e le informazioni per un criterio di autorizzazione.

    Proprietà Richiesto Type Descrizione
    Nome del criterio Sì String Il nome da usare per il criterio di autorizzazione
    Tipo di criterio Sì String AAD per i token di tipo bearer o AADPOP per i token di tipo Proof-of-Possession.
    Richieste Sì String Coppia chiave-valore che specifica il tipo di attestazione e il valore previsti dal trigger Richiesta del flusso di lavoro nel token di accesso presentato da ogni chiamata in ingresso al trigger. È possibile aggiungere qualunque attestazione standard desiderata selezionando Aggiungi attestazione standard. Per aggiungere un'attestazione specifica a un token PoP, selezionare Aggiungi attestazione personalizzata.

    Tipi di attestazione standard disponibili:

    - Autorità di certificazione
    - Destinatari
    - Argomento
    - ID JWT (identificatore token JSON Web)

    Requisiti:

    - L'elenco di Attestazioni deve includere almeno l'attestazione dell'Emittente, il cui valore inizia con https://sts.windows.net/ o https://login.microsoftonline.com/ come ID emittente Microsoft Entra.

    - Ogni attestazione deve essere un singolo valore stringa, non una matrice di valori. Ad esempio, è possibile avere un'attestazione con Ruolo come tipo e Sviluppatore come valore. Non è possibile avere un'attestazione con Ruolo come tipo e i valori impostati su Sviluppatore e Program Manager.

    - Il valore dell’attestazione è limitato al numero massimo di caratteri.

    Per altre informazioni su questi tipi di attestazione, vedere Attestazioni nei token di sicurezza di Microsoft Entra. È anche possibile specificare il proprio tipo di attestazione e il proprio valore.

    L'esempio seguente mostra le informazioni per un token PoP:

    Screenshot che mostra il portale di Azure, la pagina Autorizzazione dell'app per la logica A consumo e le informazioni per un criterio proof-of-possession.

  4. Per aggiungere un'altra attestazione, selezionare una delle opzioni seguenti:

    • Per aggiungere un altro tipo di attestazione, selezionare Aggiungi attestazione standard, selezionare il tipo di attestazione e specificare il valore dell'attestazione.

    • Per aggiungere una propria attestazione, selezionare Aggiungi attestazione personalizzata. Per altre informazioni, vedere come fornire attestazioni facoltative all'app. L'attestazione personalizzata, quindi, viene archiviata come parte dell'ID JWT, ad esempio "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47".

  5. Per aggiungere un altro criterio di autorizzazione, selezionare Aggiungi criteri. Ripetere i passaggi precedenti per configurare i criteri.

  6. Al termine, seleziona Salva.

  7. Per includere l'intestazione Authorization dal token di accesso negli output dei trigger basati su richiesta, esaminare Includere l'intestazione “Autorizzazione” negli output dei trigger Richiesta e Webhook HTTP.

Le proprietà del flusso di lavoro, ad esempio i criteri, non appaiono nella visualizzazione del codice del flusso di lavoro nel portale di Azure. Per accedere ai criteri a livello di codice, chiamare l'API seguente tramite Azure Resource Manager: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820. Sostituire i valori segnaposto per l'ID sottoscrizione di Azure, il nome del gruppo di risorse e il nome del flusso di lavoro.

Includere l'intestazione “Autorizzazione” negli output dei trigger Richiesta o Webhook HTTP

Per le app per la logica che abilitano OAuth con Microsoft Entra ID per autorizzare chiamate in ingresso per accedere ai trigger basati su richiesta, è possibile abilitare gli output dei trigger Richiesta o Webhook HTTP per includere l'intestazione Authorization dal token di accesso OAuth. Nella definizione JSON sottostante del trigger, aggiungere la proprietà operationOptions e impostarla su IncludeAuthorizationHeadersInOutputs. Di seguito è riportato un esempio per il trigger Richiesta:

"triggers": {
   "manual": {
      "inputs": {
         "schema": {}
      },
      "kind": "Http",
      "type": "Request",
      "operationOptions": "IncludeAuthorizationHeadersInOutputs"
   }
}

Per altre informazioni, vedere questi argomenti:

Esporre il flusso di lavoro dell'app per la logica con Gestione API

Per altre opzioni e protocolli di autenticazione, valutare l’esposizione del flusso di lavoro dell'app per la logica come API usando Gestione API di Azure. Questo servizio offre funzionalità avanzate di monitoraggio, sicurezza, criteri e documentazione per qualunque endpoint. Gestione API può esporre un endpoint pubblico o privato per l'app per la logica. Per autorizzare l'accesso a questo endpoint, è possibile usare OAuth con Microsoft Entra ID, un certificato client o altri standard di sicurezza. Quando Gestione API riceve una richiesta, il servizio invia la richiesta all'app per la logica ed esegue tutte le trasformazioni o restrizioni necessarie e restrizioni. Per consentire solo a Gestione API di chiamare il flusso di lavoro dell'app per la logica, è possibile limitare gli indirizzi IP in ingresso dell'app per la logica.

Per altre informazioni, consultare la documentazione seguente:

Limitare gli indirizzi IP in ingresso

Oltre alla firma di accesso condiviso (SAS), potrebbe essere opportuno limitare specificamente i client che possono chiamare il flusso di lavoro dell'app per la logica. Ad esempio, se si gestisce l'endpoint richiesta usando Gestione API di Azure, è possibile limitare il flusso di lavoro dell'app per la logica per accettare solo le richieste provenienti dall'indirizzo IP per l’istanza del servizio Gestione API creata.

Indipendentemente dagli indirizzi IP specificati, è comunque possibile eseguire un flusso di lavoro dell'app per la logica con un trigger basato su richiesta usando la richiesta dell’API REST di app per la logica: trigger del flusso di lavoro - Esegui o usando Gestione API. Tuttavia, in questo caso potrebbe essere richiesta l'autenticazione all'API REST di Azure. Tutti gli eventi vengono visualizzati nel log di controllo di Azure. Assicurarsi di impostare i criteri di controllo di accesso di conseguenza.

Per limitare gli indirizzi IP in ingresso per il flusso di lavoro dell'app per la logica, seguire i passaggi corrispondenti per il portale di Azure o il modello di Azure Resource Manager. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x

Nel portale di Azure, la restrizione degli indirizzi IP influisce su trigger e azioni, contrariamente alla descrizione nel portale in Indirizzi IP in ingresso consentiti. Per configurare questo filtro separatamente per trigger e azioni, usare l'oggetto accessControl in un modello di Azure Resource Manager per la risorsa dell'app per la logica o l’API REST di App per la logica di Azure: Flusso di lavoro - Operazione Crea o Aggiorna.

Flussi di lavoro A consumo

  1. Nel portale di Azure, aprire l'app per la logica A consumo nella finestra di progettazione del flusso di lavoro.

  2. Nel menu dell'app per la logica, in Impostazioni, selezionare Impostazioni del flusso di lavoro.

  3. Nella sezione Configurazione controllo di accesso, in Indirizzi IP in ingresso consentiti, scegliere il percorso per lo scenario:

    • Per rendere il flusso di lavoro chiamabile usando l’azione predefinita di App per la logica di Azure, ma solo come flusso di lavoro annidato, selezionare Solo altre app per la logica. Questa opzione funziona solo quando si usa l'azione di App per la logica di Azure per chiamare il flusso di lavoro annidato.

      Questa opzione scrive una matrice vuota nella risorsa dell'app per la logica e richiede che solo le chiamate dai flussi di lavoro padre che usano l’azione di App per la logica di Azure predefinita possono attivare il flusso di lavoro annidato.

    • Per rendere il flusso di lavoro chiamabile usando l'azione HTTP, ma solo come flusso di lavoro annidato, selezionare Intervalli IP specifici. Quando viene visualizzata la casella Intervalli IP per i trigger, immettere gli indirizzi IP in uscita del flusso di lavoro padre. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x

      Nota

      Se si usa l'opzione Solo altre app per la logica e l'azione HTTP per chiamare il flusso di lavoro annidato, la chiamata viene bloccata e si verifica un errore "401 Non autorizzato".

    • Per gli scenari in cui si desidera limitare le chiamate in ingresso da altri IP, quando viene visualizzata la casella Intervalli IP per i trigger, specificare gli intervalli di indirizzi IP accettati dal trigger. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x

  4. Facoltativamente, in Limitare le chiamate per ottenere messaggi di input e output dalla cronologia di esecuzione agli indirizzi IP forniti, è possibile specificare gli intervalli di indirizzi IP per le chiamate in ingresso che possono accedere ai messaggi di input e output nella cronologia di esecuzione.

Flussi di lavoro Standard

  1. Nel portale di Azure, aprire la risorsa dell’app per la logica Standard.

  2. Nel menu dell'app per la logica, in Impostazioni, selezionare Rete.

  3. Nella sezione Configurazione del traffico in ingresso, accanto ad Accesso alla rete pubblica, selezionare Abilitato senza restrizioni di accesso.

  4. Nella pagina Restrizioni di accesso, in Accesso alle app, selezionare Abilitato da reti virtuali e indirizzi IP selezionati.

  5. In Accesso e regole del sito, nella scheda Sito principale, aggiungere una o più regole alle richieste Consenti o Nega da intervalli IP specifici. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x

    Per altre informazioni, vedere Blocco degli indirizzi IP in ingresso in App per la logica di Azure (Standard).

Accesso alle chiamate in uscita ad altri servizi e sistemi

In base alla capacità dell'endpoint di destinazione, le chiamate in uscita inviate dal trigger HTTP o dall'azione HTTP supportano la crittografia e sono protette con Transport Layer Security (TLS) 1.0, 1.1 o 1.2, precedentemente noto come Secure Sockets Layer (SSL). App per la logica di Azure negozia con l'endpoint di destinazione usando la versione più alta supportata. Ad esempio, se l'endpoint di destinazione supporta 1.2, il trigger o l’azione HTTP o usa prima 1.2. In caso contrario, il connettore usa la successiva versione più recente supportata.

Questo elenco include informazioni sui certificati TLS/SSL autofirmati:

  • Per i flussi di lavoro dell’app per la logica A consumo nell'ambiente di App per la logica di Azure multi-tenant, le operazioni HTTP non consentono certificati TLS/SSL autofirmati. Se l'app per la logica effettua una chiamata HTTP a un server e presenta un certificato autofirmato TLS/SSL, la chiamata HTTP non riesce con un errore TrustFailure.

  • Per i flussi di lavoro dell’app per la logica A consumo nell'ambiente di App per la logica di Azure a singolo tenant, le operazioni HTTP supportano certificati TLS/SSL autofirmati. Tuttavia, è necessario completare alcuni passaggi aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Autenticazione del certificato TLS/SSL per App per la logica di Azure a singolo tenant.

    Se si desidera usare il certificato client oppure OAuth con Microsoft Entra ID con il tipo di credenziale Certificato, è comunque necessario completare alcuni passaggi aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Certificato client oppure OAuth con Microsoft Entra ID con il tipo di credenziale "Certificato" per App per la logica di Azure a singolo tenant.

Di seguito sono indicati alcuni modi per facilitare la protezione degli endpoint che gestiscono chiamate inviate dai flussi di lavoro dall'app per la logica:

  • Aggiungere l’autenticazione alle richieste in uscita.

    Quando si usa il trigger o l’azione HTTP per inviare chiamate in uscita, è possibile aggiungere l'autenticazione alla richiesta inviata dall'app per la logica. È ad esempio possibile selezionare i tipi di autenticazione seguenti:

  • Limitare l'accesso dagli indirizzi IP del flusso di lavoro dell’app per la logica.

    Tutte le chiamate agli endpoint dai flussi di lavoro dell’app per la logica provengono da specifici indirizzi IP designati basati sulle aree delle app per la logica. È possibile aggiungere un filtro che accetti le richieste solo da tali indirizzi IP. Per un elenco di questi indirizzi IP, vedere Limiti e configurazione per App per la logica di Azure.

  • Migliorare la sicurezza per le connessioni ai sistemi locali.

    Le app per la logica offrono integrazione con tali servizi per fornire una comunicazione locale più sicura e affidabile.

    • Gateway dati locale

      Molti dei connettori gestiti in App per la logica di Azure offrono una connettività sicura a sistemi locali, tra cui File System, SQL, SharePoint, DB2. Il gateway inoltra i dati da origini locali sui canali crittografati tramite il bus di servizio di Azure. Tutto il traffico ha origine come traffico sicuro in uscita dall'agente di gateway. Altre informazioni su come funziona il gateway dati locale.

    • Connettersi attraverso Gestione API di Azure

      Gestione API di Azure fornisce opzioni di connettività locale, ad esempio una rete privata virtuale da sito a sito e l’integrazione ExpressRoute per proxy e comunicazione sicuri con sistemi locali. Se si dispone di un'API che fornisce l'accesso al sistema locale e tale API è stata esposta creando un'Istanza del servizio Gestione API, è possibile chiamare tale API dal flusso di lavoro dell'app per la logica selezionando l'operazione Gestione API corrispondente nella finestra di progettazione del flusso di lavoro.

      Nota

      Il connettore mostra solo i servizi Gestione API in cui si dispone delle autorizzazioni per la visualizzazione e la connessione, ma non mostra i servizi Gestione API basati sul consumo.

      In base al tipo di risorsa dell'app per la logica, seguire i passaggi corrispondenti:

      Flussi di lavoro A consumo

      1. A seconda che si aggiunga o un trigger o un’azione di Gestione API, seguire questa procedura:

        • Trigger:

          1. Nella finestra di progettazione del flusso di lavoro, selezionare Aggiungi un trigger.

          2. Dopo l’apertura del riquadro Aggiungi un trigger, nella casella di ricerca immettere Gestione API.

          3. Nell'elenco dei risultati del trigger, selezionare Scegli un trigger di Gestione API di Azure.

        • Azione:

          1. Nella finestra di progettazione del flusso di lavoro, selezionare il segno più (+) dove aggiungere l'azione.

          2. Dopo l’apertura del riquadro Aggiungi un’azione, nella casella di ricerca immettere Gestione API.

          3. Nell'elenco dei risultati dell’azione, selezionare Scegli un’azione di Gestione API di Azure.

        L'esempio seguente illustra la ricerca di un trigger di Gestione API di Azure:

        Screenshot che mostra il portale di Azure, la finestra di progettazione del flusso di lavoro A consumo e la ricerca di un trigger di Gestione API.

      2. Dall'elenco dell'istanza del servizio Gestione API, selezionare l'istanza del servizio Gestione API creata in precedenza.

      3. Dall'elenco delle operazioni API, selezionare l'operazione API da chiamare, quindi selezionare Aggiungi azione.

      Flussi di lavoro Standard

      Per i flussi di lavoro Standard, è possibile aggiungere solo azioni di Gestione API, non trigger.

      1. Nella finestra di progettazione del flusso di lavoro, selezionare il segno più (+) dove aggiungere l'azione.

      2. Dopo l’apertura del riquadro Aggiungi un’azione, nella casella di ricerca immettere Gestione API.

      3. Nell'elenco dei risultati dell’azione, selezionare Chiama un’API di Gestione API di Azure.

        Screenshot che mostra il portale di Azure, la finestra di progettazione del flusso di lavoro Standard e l'azione di Gestione API di Azure.

      4. Dall'elenco dell'istanza del servizio Gestione API, selezionare l'istanza del servizio Gestione API creata in precedenza.

      5. Dall'elenco delle operazioni API, selezionare l'operazione API da chiamare, quindi selezionare Crea nuovo.

        Screenshot che mostra il portale di Azure, la finestra di progettazione del flusso di lavoro Standard e l’API selezionata da chiamare.

Aggiunta dell'autenticazione alle chiamate in uscita

Gli endpoint HTTP e HTTPS supportano vari tipi di autenticazione. In alcuni trigger e azioni usati per inviare chiamate o richieste in uscita a questi endpoint, è possibile specificare un tipo di autenticazione. Nella finestra di progettazione del flusso di lavoro, i trigger e le azioni che supportano la scelta di un tipo di autenticazione hanno una proprietà Autenticazione. Tuttavia, questa proprietà potrebbe non apparire sempre per impostazione predefinita. In questi casi, nel trigger o nell'azione aprire l'elenco Aggiungi nuovo parametro e selezionare Autenticazione.

Importante

Per proteggere le informazioni riservate gestite dall'app per la logica, usare i parametri protetti e codificare i dati in base alla necessità. Per altre informazioni sull'uso e sulla protezione dei parametri, vedere Accesso agli input dei parametri.

Autenticazione di base

Se è disponibile l'opzione Basic, specificare i valori delle proprietà seguenti:

Proprietà (progettazione) Proprietà (JSON) Obbligatorio Valore Descrizione
Autenticazione type Sì Di base Tipo di autenticazione da usare
Nome utente username Sì <user-name> Il nome utente per l'autenticazione dell'accesso all'endpoint del servizio di destinazione
Password password Sì <password> La password per l'autenticazione dell'accesso all'endpoint del servizio di destinazione

Quando si usano i parametri protetti per gestire e proteggere le informazioni riservate, ad esempio in un modello di Azure Resource Manager per l'automazione della distribuzione, è possibile usare le espressioni per accedere a questi valori di parametro in fase di esecuzione. Questa definizione di azione HTTP di esempio specifica l'autenticazione type come Basic e usa la funzione dei parametri() per ottenere i valori dei parametri:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Basic",
         "username": "@parameters('userNameParam')",
         "password": "@parameters('passwordParam')"
      }
  },
  "runAfter": {}
}

Autenticazione con certificato client

Se è disponibile l'opzione Certificato client, specificare i valori delle proprietà seguenti:

Proprietà (progettazione) Proprietà (JSON) Obbligatorio Valore Descrizione
Autenticazione type Sì Certificato client
o
ClientCertificate		 Tipo di autenticazione da usare. È possibile gestire i certificati con Gestione API di Azure.

Nota: i connettori personalizzati non supportano l'autenticazione basata su certificati per le chiamate in ingresso e in uscita.
Pfx pfx Sì <encoded-pfx-file-content> Contenuto con codifica base64 del file di scambio di informazioni personali (PFX, Personal Information Exchange)

Per convertire il file PFX in formato con codifica Base64, è possibile usare PowerShell 7 attenendosi alla procedura seguente:

1. Salvare il contenuto del certificato in una variabile:

$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')

2. Convertire il contenuto del certificato usando la funzione ToBase64String() e salvare il contenuto in un file di testo:

[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'

Risoluzione dei problemi: se si usa il comando cert mmc/PowerShell, è possibile che si ottenga questo errore:

Could not load the certificate private key. Please check the authentication certificate password is correct and try again.

Per risolvere questo errore, provare a convertire il file PFX in un file PEM e ripetere l’operazione usando il comando openssl:

openssl pkcs12 -in certificate.pfx -out certificate.pem
openssl pkcs12 -in certificate.pem -export -out certificate2.pfx

Successivamente, quando si ottiene la stringa con codifica base64 per il file PFX appena convertito del certificato, ora la stringa funziona in App per la logica di Azure.
Password password No <password-for-pfx-file> Password per accedere al file PFX.

Nota

Se si tenta di eseguire l'autenticazione con un certificato client usando OpenSSL, è possibile che si ottenga l'errore seguente:

BadRequest: Could not load private key

Per risolvere questo errore, effettuare le operazioni seguenti:

  1. Disinstallare tutte le istanze di OpenSSL.
  2. Installare OpenSSL versione 1.1.1t.
  3. Riassegnare il certificato usando il nuovo aggiornamento.
  4. Aggiungere il nuovo certificato all'operazione HTTP quando si usa l'autenticazione del certificato client.

Quando si usano i parametri protetti per gestire e proteggere le informazioni riservate, ad esempio in un modello di Azure Resource Manager per l'automazione della distribuzione, è possibile usare le espressioni per accedere a questi valori di parametro in fase di esecuzione. Questa definizione di azione HTTP di esempio specifica l'autenticazione type come ClientCertificate e usa la funzione dei parametri() per ottenere i valori dei parametri:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ClientCertificate",
         "pfx": "@parameters('pfxParam')",
         "password": "@parameters('passwordParam')"
      }
   },
   "runAfter": {}
}

Importante

Se si dispone di una risorsa dell'app per la logica Standard in App per la logica di Azure a singolo tenant e si desidera usare un'operazione HTTP con un certificato TSL/SSL, un certificato client o Open Authentication con Microsoft Entra ID (OAuth con Microsoft Entra ID) con il tipo di credenziale Certificate, completare i passaggi di configurazione aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Autenticazione in un ambiente a singolo tenant.

Per altre informazioni sulla protezione dei servizi tramite l'autenticazione del certificato client, vedere gli argomenti seguenti:

Microsoft Identity Platform

Nei trigger Richiesta è possibile usare Microsoft Identity Platform per autenticare le chiamate in ingresso dopo aver configurato i criteri di autorizzazione di Microsoft Entra per l'app per la logica. Per tutti gli altri trigger e azioni che forniscono il tipo di autenticazione Active Directory OAuth da selezionare, specificare i valori delle proprietà seguenti:

Proprietà (progettazione) Proprietà (JSON) Obbligatorio Valore Descrizione
Autenticazione type Sì Active Directory OAuth
o
ActiveDirectoryOAuth		 Tipo di autenticazione da usare. App per la logica di Azure attualmente segue il protocollo OAuth 2.0.
Authority authority No <URL-for-authority-token-issuer> URL dell'autorità che fornisce il token di accesso, ad esempio https://login.microsoftonline.com/ per le aree del servizio globale di Azure. Per altri cloud nazionali, vedere Endpoint di autenticazione di Microsoft Entra - Scelta dell'autorità di identità.
Tenant tenant Sì <tenant-ID> ID del tenant per il tenant di Microsoft Entra
Destinatari audience Sì <resource-to-authorize> La risorsa che si vuole usare per l'autorizzazione, ad esempio https://management.core.windows.net/
ID client clientId Sì <client-ID> L'ID client per l'app richiedente l'autorizzazione
Tipo di credenziali credentialType Sì Certificato
o
Segreto		 Il tipo di credenziale che il client usa per la richiesta di autorizzazione. Questa proprietà e questo valore non vengono visualizzati nella definizione sottostante dell'app per la logica, ma determinano le proprietà che vengono visualizzate per il tipo di credenziale selezionato.
Segreto secret Sì, ma solo per il tipo di credenziale "Segreto" <client-secret> Il segreto client per la richiesta dell'autorizzazione
Pfx pfx Sì, ma solo per il tipo di credenziale "Certificato" <encoded-pfx-file-content> Contenuto con codifica base64 del file di scambio di informazioni personali (PFX, Personal Information Exchange)
Password password Sì, ma solo per il tipo di credenziale "Certificato" <password-for-pfx-file> Password per accedere al file PFX.

Quando si usano i parametri protetti per gestire e proteggere le informazioni riservate, ad esempio in un modello di Azure Resource Manager per l'automazione della distribuzione, è possibile usare le espressioni per accedere a questi valori di parametro in fase di esecuzione. Questa definizione di azione HTTP di esempio specifica l'autenticazione type come ActiveDirectoryOAuth, il tipo di credenziali come Secret e usa la funzione dei parametri() per ottenere i valori dei parametri:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ActiveDirectoryOAuth",
         "tenant": "@parameters('tenantIdParam')",
         "audience": "https://management.core.windows.net/",
         "clientId": "@parameters('clientIdParam')",
         "credentialType": "Secret",
         "secret": "@parameters('secretParam')"
     }
   },
   "runAfter": {}
}

Importante

Se si dispone di una risorsa dell'app per la logica Standard in App per la logica di Azure a singolo tenant e si desidera usare un'operazione HTTP con un certificato TSL/SSL, un certificato client o Open Authentication con Microsoft Entra ID (OAuth con Microsoft Entra ID) con il tipo di credenziale Certificate, completare i passaggi di configurazione aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Autenticazione in un ambiente a singolo tenant.

Autenticazione con dati non elaborati

Se l'opzione Raw è disponibile, è possibile usare questo tipo di autenticazione quando è necessario usare gli schemi di autenticazione che non seguono il protocollo OAuth 2.0. Con questo tipo, si crea manualmente il valore dell'intestazione di autorizzazione inviato con la richiesta in uscita e si specifica il valore dell'intestazione nel trigger o nell'azione.

L’esempio seguente mostra un'intestazione di esempio per una richiesta HTTPS che segue il protocollo OAuth 1.0:

Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131200",
   oauth_nonce="wIjqoS",
   oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
   oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

Nel trigger o nell'azione che supporta l'autenticazione con dati non elaborati specificare i valori delle proprietà seguenti:

Proprietà (progettazione) Proprietà (JSON) Obbligatorio Valore Descrizione
Autenticazione type Sì Raw Tipo di autenticazione da usare
Valore value Sì <authorization-header-value> Valore dell'intestazione di autorizzazione da usare per l'autenticazione

Quando si usano i parametri protetti per gestire e proteggere le informazioni riservate, ad esempio in un modello di Azure Resource Manager per l'automazione della distribuzione, è possibile usare le espressioni per accedere a questi valori di parametro in fase di esecuzione. Questa definizione di azione HTTP di esempio specifica l'autenticazione type come Raw e usa la funzione dei parametri() per ottenere i valori dei parametri:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Raw",
         "value": "@parameters('authHeaderParam')"
      }
   },
   "runAfter": {}
}

Autenticazione identità gestita

Quando l'opzione identità gestita è disponibile nel trigger o nell’azione che supporta l'autenticazione dell'identità gestita, l'app per la logica può usare questa identità per autenticare l'accesso alle risorse di Azure protette da Microsoft Entra ID, anziché credenziali, segreti o token di Microsoft Entra. Azure gestisce automaticamente questa identità e facilita la protezione delle credenziali perché l’utente non deve gestire segreti o usare direttamente token di Microsoft Entra. Sono disponibili altre informazioni sui Servizi di Azure che supportano identità gestite per l'autenticazione di Microsoft Entra.

  • Una risorsa dell'app per la logica A consumo può usare l'identità assegnata dal sistema o una singola identità assegnata dall'utente creata manualmente.

  • Una risorsa dell'app per la logica Standard supporta l’abilitazione contemporanea dell’identità gestita assegnata dal sistema e più identità gestite assegnate dall'utente, anche se è comunque possibile selezionare una sola identità alla volta per l’uso.

    Nota

    Per impostazione predefinita, l'identità assegnata dal sistema è già abilitata per autenticare le connessioni nel runtime. Questa identità è diversa dalle credenziali di autenticazione o dalla stringa di connessione usata quando si crea una connessione. Se si disabilita questa identità, le connessioni non funzioneranno nel runtime. Per visualizzare questa impostazione, nel menu dell'app per la logica, in Impostazioni, selezionare Identità.

  1. Prima che l'app per la logica possa usare un'identità gestita, seguire la procedura descritta in Autenticare l'accesso alle risorse di Azure usando identità gestite in App per la logica di Azure. Questa procedura abilita l'identità gestita nell'app per la logica e imposta l'accesso dell'identità sulla risorsa di destinazione.

  2. Prima che una funzione di Azure possa usare un'identità gestita, abilitare l'autenticazione per le funzioni di Azure.

  3. Nel trigger o nell'azione che supporta l'uso di un'identità gestita, specificare queste informazioni:

    Trigger e azioni predefinite.

    Proprietà (progettazione) Proprietà (JSON) Obbligatorio Valore Descrizione
    Autenticazione type Sì Identità gestita
    o
    ManagedServiceIdentity    		 Tipo di autenticazione da usare
    Identità gestita identity No <ID identità assegnata dall’utente> L’identità gestita assegnata dall'utente da usare. Nota: non includere questa proprietà quando si usa l'identità gestita assegnata dal sistema.
    Destinatari audience Sì <target-resource-ID> L'ID risorsa per la risorsa di destinazione a cui si vuole accedere.

    Ad esempio, https://storage.azure.com/ rende i token di accesso per l'autenticazione validi per tutti gli account di archiviazione. Tuttavia, è anche possibile specificare un URL del servizio radice, ad esempio https://fabrikamstorageaccount.blob.core.windows.net per un account di archiviazione specifico.

    Nota: la proprietà Destinatari potrebbe essere nascosta in alcuni trigger o azioni. Per fare in modo che la proprietà venga visualizzata, nel trigger o nell'azione, aprire l'elenco Aggiungi nuovo parametro e selezionare Destinatari.

    Importante: accertarsi che questo ID della risorsa di destinazione corrisponda esattamente al valore previsto da Microsoft Entra ID, incluse eventuali barre finali necessarie. Quindi, l'ID della risorsa https://storage.azure.com/ per tutti gli account di archiviazione BLOB di Azure richiede una barra finale. Tuttavia, l'ID risorsa per un account di archiviazione specifico non richiede una barra finale. Per trovare questi ID risorsa, vedere Servizi di Azure che supportano Microsoft Entra ID.

    Quando si usano i parametri protetti per gestire e proteggere le informazioni riservate, ad esempio in un modello di Azure Resource Manager per l'automazione della distribuzione, è possibile usare le espressioni per accedere a questi valori di parametro in fase di esecuzione. Ad esempio, questa definizione di azione HTTP specifica l'autenticazione type come ManagedServiceIdentity e usa la funzione parameters() per ottenere i valori dei parametri:

    "HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ManagedServiceIdentity",
         "audience": "https://management.azure.com/"
      },
   },
   "runAfter": {}
}

    Trigger e azioni connettori gestiti

    Proprietà (progettazione) Obbligatorio Valore Descrizione
    Nome connessione Sì <nome connessione>
    Identità gestita Sì Identità gestita assegnata dal sistema
    o
    <Nome identità gestita assegnata dall’utente>    		 Tipo di autenticazione da usare

Creazione di connessioni in blocco

Se l'organizzazione non consente la connessione a risorse specifiche usando i relativi connettori in App per la logica di Azure, è possibile bloccare la capacità di creare tali connessioni per determinati connettori nei flussi di lavoro dell'app per la logica usando Criteri di Azure. Per altre informazioni, vedere Bloccare le connessioni create da connettori specifici in App per la logica di Azure.

Linee guida sull'isolamento per le app per la logica

È possibile usare App per la logica di Azure in Azure per enti pubblici che supporta tutti i livelli di impatto nelle aree descritte dalle Linee guida per l'isolamento al livello di impatto 5 di Azure per enti pubblici. Per soddisfare questi requisiti, App per la logica di Azure supporta la capacità di creare ed eseguire flussi di lavoro in un ambiente con risorse dedicate in modo da ridurre l'impatto sulle prestazioni da parte di altri tenant di Azure nelle app per la logica ed evitare la condivisione delle risorse di calcolo con altri tenant.

Per altre informazioni sull’isolamento, vedere la documentazione seguente:

Passaggi successivi