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

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:

• Accesso alle operazioni di app per la logica
• Accesso agli input e agli output della cronologia di esecuzione
• Accesso agli input dei parametri
• Tipi di autenticazione per trigger e azioni che supportano l'autenticazione
• Accesso per le chiamate in ingresso ai trigger basati su richiesta
• Accesso alle chiamate in uscita ad altri servizi e sistemi
• Bloccare la creazione di connessioni per connettori specifici
• Linee guida sull'isolamento per le app per la logica
• Baseline di sicurezza di Azure per le App per la logica di Azure

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

• Panoramica della crittografia di Azure
• Crittografia dei dati inattivi di Azure
• Microsoft Cloud Security Benchmark

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

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

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'indirizzo IP.

  Questa opzione consente di proteggere l'accesso alla cronologia di esecuzione in base alle richieste provenienti da un intervallo di indirizzi IP specifico.

• Proteggere i dati nella cronologia di esecuzione usando l'offuscamento.

  In molti trigger e azioni è possibile proteggere gli input, gli output o entrambi nella cronologia di esecuzione di un'app per la logica.

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:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {<workflow-definition>},
            "parameters": {},
            "accessControl": {
               "contents": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     },
                     {
                        "addressRange": "2001:0db8::/64"
                     }
                  ]
               }
            }
         }
      }
   ],
   "outputs": {}
}

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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:

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.

  

  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.

  

  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.

  

  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.

  

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.

   

4. Attivare Input protetti, Output protetti o entrambi.

   

   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.

   

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.

      

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.

Per altre informazioni, vedere le sezioni in questo argomento:

• Proteggere i parametri nelle definizioni del flusso di lavoro
• Proteggere i dati nella cronologia di esecuzione usando l'offuscamento

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:

• Passare i valori sensibili alla distribuzione usando Azure Key Vault
• Proteggere i parametri nei modelli di Azure Resource Manager più avanti in questo argomento

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:

{
   "$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:

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 Richiedi o il trigger Webhook HTTP, supportano la crittografia e sono protetti con almeno Transport Layer Security (TLS) 1.2, 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 Richiedi o un callback al trigger o all'azione Webhook HTTP.

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

L'elenco seguente include modi per limitare l'accesso ai trigger che ricevono chiamate in ingresso al flusso di lavoro dell'app per la logica in modo che solo i client autorizzati possano chiamare il flusso di lavoro:

• Abilitare OAuth con Microsoft Entra ID
• Generare chiavi o token di firma di accesso condiviso (SAS)
• Disabilita autenticazione con firma di accesso condiviso (SAS)
• Limitare gli indirizzi IP in ingresso
• Esporre l'app per la logica con Gestione API di Azure

Abilitare OAuth 2.0con Microsoft Entra ID

In un flusso di lavoro A consumo che inizia con un trigger basato su richiesta, è possibile autenticare e autorizzare le chiamate in ingresso inviate all'endpoint creato da tale trigger abilitando OAuth 2.0 con Microsoft Entra ID. Per configurare questa autenticazione, definire o aggiungere un criterio di autorizzazione a livello di risorse dell'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 Standard che inizia con il trigger Richiedi (ma non con un trigger Webhook), è possibile usare il provisioning di Funzioni di Azure per autenticare le chiamate in ingresso inviate all'endpoint creato dal trigger Richiedi 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 di abilitare OAuth 2.0 con Microsoft Entra ID

• Per una protezione ottimale, Microsoft consiglia di usare Microsoft Entra ID con identità gestite per l'autenticazione, ove possibile. Questa opzione offre una sicurezza superiore senza bisogno di fornire le credenziali. Azure gestisce questa identità e aiuta a proteggere le informazioni di autenticazione, in modo che non sia necessario gestire questi dati riservati. Per configurare un'identità gestita per App per la logica di Azure, vedere Autenticare l'accesso e le connessioni alle risorse di Azure con identità gestite in App per la logica di Azure.

• Nei flussi di lavoro A consumo, le chiamate in ingresso all'URL dell'endpoint per un trigger basato su richiesta possono usare un solo schema di autorizzazione, OAuth 2.0 con ID Microsoft Entra o Firma di accesso condiviso (SAS). Anche se l'uso di uno schema non disabilita l'altro schema, se si usano contemporaneamente entrambi gli schemi, App per la logica di Azure causa un errore perché il servizio non riconosce lo schema da scegliere. Se il flusso di lavoro A consumo inizia con il trigger Richiedi, è possibile disabilitare l'autenticazione SAS e limitare l'autorizzazione all'uso solo di OAuth 2.0 con Microsoft Entra ID. Per i flussi di lavoro Standard, è possibile usare altri tipi di autenticazione senza disabilitare la firma di accesso condiviso.

• 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 A consumo è 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": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
      "unique_name": "SophiaOwen@fabrikam.com",
      "upn": "SophiaOwen@fabrikam.com",
      "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
      "ver": "1.0"
  }
  

Abilitare OAuth 2.0 con Microsoft Entra ID come unica opzione per chiamare un endpoint di richiesta (solo A consumo)

Per gli endpoint basati su richiesta, è possibile limitare l'autorizzazione all'uso solo di OAuth 2.0 con Microsoft Entra ID. Questa opzione funziona anche se si disabilita anche l'autenticazione della firma di accesso condiviso (SAS).

1. Per il flusso di lavoro A consumo, configurare il trigger Richiedi 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 Richiedi 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 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 A consumo da chiamare richiede un token PoP, è possibile ottenere questo token usando le librerie MSAL. Gli esempi seguenti illustrano come acquisire i token PoP:

• Un'applicazione della console daemon .NET Core che chiama un'API Web protetta con una propria identità

• SignedHttpRequest, noto anche come PoP (Proof of Possession)

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

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

Per aggiungere un criterio di autorizzazione all'app per la logica A consumo, seguire la procedura per il portale di Azure o il modello di Azure Resource Manager:

"resources": [
   {
      // Start logic app resource definition
      "properties": {
         "state": "<Enabled-or-Disabled>",
         "definition": {<workflow-definition>},
         "parameters": {<workflow-definition-parameter-values>},
         "accessControl": {
            "triggers": {
               "openAuthenticationPolicies": {
                  "policies": {
                     "<policy-name>": {
                        "type": "AAD",
                        "claims": [
                           {
                              "name": "<claim-name>",
                              "value": "<claim-value>"
                           }
                        ]
                     }
                  }
               }
            },
         },
      },
      "name": "[parameters('LogicAppName')]",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('LogicAppLocation')]",
      "apiVersion": "2016-06-01",
      "dependsOn": [
      ]
   }
   // End logic app resource definition
],

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 Richiedi 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 Richiedi:

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

Per altre informazioni, vedere questi argomenti:

• Riferimento allo schema per tipi di trigger e azioni - Trigger Richiesta
• Riferimento allo schema per tipi di trigger e azioni - Trigger Webhook HTTP
• Riferimento allo schema per tipi di trigger e azioni - Opzioni Operazione

Generare una chiave o un token di firma di accesso condiviso

Quando un flusso di lavoro inizia con un trigger basato su richiesta e si salva tale flusso di lavoro per la prima volta, App per la logica di Azure crea un endpoint chiamabile in tale trigger. Questo endpoint ha un URL che può ricevere chiamate in ingresso o richieste per avviare il flusso di lavoro. L'URL include una firma di accesso condiviso (SAS),ovvero una chiave o un token che concede autorizzazioni, ad esempio, ai servizi di archiviazione. Questo URL dell'endpoint usa il formato seguente:

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

Ad esempio, per visualizzare questo URL in un trigger Richiedi, trovare la proprietà URL HTTP del trigger:

L'URL completo è simile all'esempio seguente:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

La firma di accesso condiviso nell'URL include parametri di query, descritti nella tabella seguente:

Le chiamate in ingresso all'endpoint in un trigger basato su richiesta possono usare un solo schema di autorizzazione, SAS o OAuth 2.0 con Microsoft Entra ID. Anche se l'uso di uno schema non disabilita l'altro, se si usano contemporaneamente entrambi gli schemi, App per la logica di Azure causa un errore perché il servizio non riconosce lo schema da scegliere.

Se si dispone di un flusso di lavoro a consumo che inizia con il trigger richiesta , è possibile disabilitare l'autenticazione sas. Questa opzione funziona anche se si limita anche l'autorizzazione all'uso solo di OAuth 2.0 con Microsoft Entra ID. Per i flussi di lavoro Standard, è possibile usare altri tipi di autenticazione senza disabilitare la firma di accesso condiviso.

Per altre informazioni sulla sicurezza quando si usa una chiave di firma di accesso condiviso, vedere le sezioni seguenti in questa guida:

• Per rigenerare le chiavi di accesso
• Creare URL di callback in scadenza
• Creare URL con una chiave primaria o secondaria

Disabilitare l'autenticazione con firma di accesso condiviso (solo A consumo)

Per impostazione predefinita, per un trigger basato su richiesta è abilitata l'autenticazione SAS. L'URL dell'endpoint del trigger include una SAS, a partire dai parametri di query, sp-<permissions>sv-<SAS-version>sig=<signature>, ad esempio:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Se il flusso di lavoro A consumo inizia con il trigger Richiedi e si vuole usare OAuth con Microsoft Entra ID, è possibile disabilitare l'autenticazione SAS per evitare errori e problemi durante l'esecuzione del flusso di lavoro. È anche possibile aggiungere un livello di sicurezza rimuovendo la dipendenza dai segreti, riducendo così il rischio di registrazione o perdita di segreti.

Questa opzione funziona anche se si abilita anche OAuth 2.0 con Microsoft Entra ID come unica opzione per chiamare un endpoint basato su richiesta. Per i flussi di lavoro Standard, è possibile usare altri tipi di autenticazione senza disabilitare la firma di accesso condiviso.

Dopo aver disabilitato l'autenticazione SAS, l'URL dell'endpoint per il trigger Richiedi non include più la chiave SAS, ad esempio:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01

Prerequisiti

Per questa attività, è necessario uno strumento per inviare chiamate API REST, ad esempio:

• Visual Studio Code con un'estensione da Visual Studio Marketplace
• Invoke-RestMethod di PowerShell
• Microsoft Edge - Strumento console di rete
• Bruno
• curl

Verificare la presenza di trigger con firma di accesso condiviso abilitato o disabilitato

Quando l'autenticazione SAS è disabilitata, l'URL dell'endpoint del trigger non include più la chiave di firma di accesso condiviso. Inoltre, la definizione del flusso di lavoro A consumo include l'oggetto JSON sasAuthenticationPolicy. Questo oggetto ha una proprietà di stato impostata su Disabilitato, ad esempio:

"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

Per trovare flussi di lavoro A consumo in cui la firma di accesso condiviso è abilitata o disabilitata, controllare se la definizione del flusso di lavoro include l'oggetto sasAuthenticationPolicy in cui la proprietà di stato è impostata su Disabilitato.

1. Con lo strumento che invia chiamate API REST, ottenere informazioni sul flusso di lavoro eseguendo l'operazione Flusso di lavoro - Ottieni richiesta GET seguente, ad esempio:

   GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

2. Eseguire l'output dell'operazione Flusso di lavoro - Ottieni e verificare se è presente l'oggetto sasAuthenticationPolicy in cui la proprietà stato è impostata su Disabilitata.

Aggiungere la proprietà sasAuthenticationPolicy alla definizione del flusso di lavoro

Per Flussi di lavoro A consumo in cui si vuole disabilitare l'autenticazione SAS, seguire questa procedura:

1. Se non è già stato fatto, ottenere informazioni sul flusso di lavoro eseguendo l'operazione Flusso di lavoro - Ottieni usando la richiesta GET seguente, ad esempio:

   GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

2. Eseguire l'output dell'operazione Flusso di lavoro - Ottieni e aggiungere manualmente gli elementi seguenti:

   1. Nell'oggetto properties aggiungere un accessControl oggetto che contiene un triggers oggetto, se non esiste.

   2. Nell'oggetto triggers aggiungere un oggetto sasAuthenticationPolicy contenente la proprietà state impostata su Disabled.

   Al termine, la parte modificata è simile all'esempio seguente:

   "properties": {
       "accessControl": {
           "triggers": {
               "sasAuthenticationPolicy": {
                   "state": "Disabled"
               }
           }
       }
   }
   

3. Inviare un'altra richiesta per aggiornare il flusso di lavoro con l'output modificato, usato come input nel corpo della richiesta, eseguendo l'operazione Workflow - Update usando la richiesta PUT seguente, ad esempio:

   PUT https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

4. Nel portale di Azure andare al flusso di lavoro A consumo nella finestra di progettazione e verificare che l'URL del trigger Richiedi non includa più la SAS.

5. Per abilitare OAuth 2.0 con Microsoft Entra ID, a livello di risorsa dell'app per la logica aggiungere un criterio di autorizzazione per OAuth con Microsoft Entra ID.

   Per altre informazioni, vedere Abilitare OAuth 2.0 con Microsoft Entra ID.

Per rigenerare le chiavi di accesso

Per mantenere la sicurezza e proteggere l'accesso al flusso di lavoro dell'app per la logica, rigenerare le chiavi di accesso in base a una pianificazione regolare in quanto potrebbero dover rispettare i criteri di sicurezza o diventare compromessi. In questo modo, è possibile assicurarsi che solo le richieste autorizzate possano attivare il flusso di lavoro, che protegge i dati e i processi dall'accesso non autorizzato.

Per generare una nuova chiave di accesso in qualsiasi momento, usare l'API REST di Azure o portale di Azure. Tutti gli URL o gli URL generati in precedenza che usano la chiave precedente vengono invalidati e non hanno più l'autorizzazione per attivare il flusso di lavoro dell'app per la logica. Gli URI recuperati dopo la rigenerazione vengono firmati con la nuova chiave di accesso.

1. Nella portale di Azure aprire la risorsa dell'app per la logica che usa la chiave da 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/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

Nel corpo includere la proprietà NotAfter 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 di Azure, ad esempio:

POST /subscriptions/{subscription-ID}/resourceGroups/{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.

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:

• Informazioni su Gestione API
• Proteggere un back-end API Web in Gestione API di Azure usando l'autorizzazione OAuth 2.0 con Microsoft Entra ID
• Proteggere le API usando l'autenticazione del certificato client in Gestione API
• Criteri di autenticazione di Gestione API di Azure

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 operazione Trigger dei flussi di lavoro - Esegui o 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

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": []
               },
               "actions": {
                  "allowedCallerIpAddresses": []
               },
               // Optional
               "contents": {
                  "allowedCallerIpAddresses": []
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               },
               "actions": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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:

  • Autenticazione di base

  • Autenticazione con certificato client

  • Autenticazione Active Directory OAuth (OAuth 2.0 con Microsoft Entra ID)

  • Autenticazione identità gestita

• 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:

       

    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.

       

    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.

       

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 Parametri avanzati e selezionare Autenticazione.

Autenticazione di base

Per le chiamate HTTP, l'autenticazione di base usa una stringa con codifica base64 che contiene un nome utente e una password per effettuare una richiesta. Questo metodo trasmette le credenziali senza crittografia e comporta maggiori rischi per la sicurezza, a meno che non si usi questa opzione con il protocollo HTTPS/SSL.

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

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

L'autenticazione del certificato client consente o richiede agli utenti di eseguire l'autenticazione direttamente con i certificati X.509 con Microsoft Entra ID per le applicazioni e l'accesso al browser. Questa funzionalità consente di adottare un'autenticazione resistente al phishing e di eseguire l'autenticazione con un certificato X.509 con l'infrastruttura a chiave pubblica (PKI).

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

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": {}
}

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

• Migliorare la sicurezza per le API usando l'autenticazione con certificati client in Gestione API di Azure
• Migliorare la sicurezza dei servizi back-end usando l'autenticazione con certificati client in Gestione API di Azure
• Migliorare la sicurezza per il servizio RESTful usando certificati client
• Credenziali del certificato per l'autenticazione dell'applicazione
• Usare un certificato TLS/SSL nel codice nel Servizio app di Azure

Piattaforma Microsoft Entra

Nel trigger Richiedi è possibile usare la piattaforma Microsoft Entra per autenticare le chiamate in ingresso dopo aver configurato i criteri di autorizzazione di Microsoft Entra per l'app per la logica.

In tutti gli altri trigger e azioni che supportano il tipo di autenticazione OAuth di Active Directory (OAuth 2.0 con Microsoft Entra ID), specificare questi valori di proprietà:

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": {}
}

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:

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 Parametri avanzati 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.

• I flussi di lavoro dell’app per la logica Standard possono comunicare in maniera privata e sicura con una rete virtuale di Azure tramite endpoint privati configurati per il traffico in ingresso e l’integrazione della rete virtuale per il traffico in uscita. Per altre informazioni, vedere Proteggere il traffico tra reti virtuali e App per la logica di Azure a singolo tenant usando endpoint privati.

• Per eseguire codice personalizzato o la trasformazione XML, creare e chiamare una funzione di Azure anziché usare rispettivamente la funzionalità codice inline o fornire assembly da usare come mappe. Configurare, inoltre, l'ambiente host per l'app per le funzioni in modo che sia conforme ai requisiti di isolamento.

  Ad esempio, per soddisfare i requisiti del livello di impatto 5, creare l'app per le funzioni con il piano di Servizio app usando il piano tariffario Isolato insieme a un ambiente del servizio app (ASE) che usa anch’esso il piano tariffario Isolato. In questo ambiente, le app per le funzioni vengono eseguite in macchine virtuali di Azure dedicate e reti virtuali di Azure dedicate, che forniscono l’isolamento rete oltre all'isolamento dell’ambiente di calcolo per le app e le massime capacità di scale-out.

  Per altre informazioni, vedere la documentazione seguente:

  • Piani di Servizio app di Azure
  • Opzioni di rete di Funzioni di Azure
  • Host dedicati di Azure per macchine virtuali
  • Isolamento delle macchine virtuali in Azure
  • Distribuire servizi di Azure dedicati in reti virtuali

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

• Isolamento nel cloud pubblico di Azure
• Sicurezza per app IaaS altamente sensibili in Azure

Contenuto correlato

• Baseline di sicurezza di Azure per App per la logica di Azure
• Automatizzare la distribuzione per le app per la logica di Azure
• Monitorare le app per la logica