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 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 consumo, prima di poter creare o gestire app per la logica e le relative connessioni, sono necessarie autorizzazioni specifiche, fornite tramite ruoli tramite il controllo degli accessi in base al ruolo di Azure. È anche possibile configurare le autorizzazioni in modo che solo utenti o gruppi specifici possano eseguire attività specifiche, ad esempio la gestione, la modifica e la visualizzazione delle 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, in base al fatto che si disponga di un flusso di lavoro dell'app per la logica a consumo o standard:
Flussi di lavoro a consumo
| Ruolo | Descrizione |
|---|---|
| Collaboratore per app per la logica | È possibile gestire i flussi di lavoro delle app per la logica, ma non è possibile modificarli. |
| Operatore per app per la logica | È possibile leggere, abilitare e disabilitare i flussi di lavoro delle app per la logica, ma non è possibile modificarli o aggiornarli. |
| Collaboratore | Si ha accesso completo per gestire tutte le risorse, ma non è possibile assegnare ruoli in Controllo degli accessi in base al ruolo di Azure, gestire le assegnazioni in Azure Blueprints o condividere raccolte di immagini. |
Si supponga, ad esempio, di dover usare un flusso di lavoro dell'app per la logica che non è stato creato ed autenticare le connessioni usate dal flusso di lavoro dell'app per la logica. La sottoscrizione di Azure richiede autorizzazioni di collaboratore per il gruppo di risorse che contiene 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 utenti di modificare o eliminare il flusso di lavoro dell'app per la logica, è possibile usare Il blocco 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 di Connessione ion in App per la logica di Azure e sicurezza e crittografia di Connessione ion.
Flussi di lavoro standard
Nota
Questa funzionalità è disponibile in anteprima ed è soggetta alle Condizioni per l'utilizzo supplementari 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 a 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, ad esempio configurare l'integrazione della rete virtuale. servizio app Piani 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 dell'app per la logica, App per la logica di Azure autentica l'accesso e quindi fornisce 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. Solo una persona con autorizzazioni di amministratore può rimuovere questa restrizione, che offre la possibilità di accedere "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 il portale di Azure o il modello di Azure Resource Manager:
Flussi di lavoro a consumo
Nella portale di Azure aprire il flusso di lavoro dell'app per la logica nella finestra di progettazione.
Nel menu dell'app per la logica, in Impostazioni, selezionare Impostazioni del flusso di lavoro.
In Configurazione del controllo di accesso>Indirizzi IP in ingresso consentiti selezionare Intervalli IP specifici.
In Intervalli IP per i contenuti, specificare gli intervalli di indirizzi IP che possono accedere al contenuto da input e output.
Flussi di lavoro standard
Nella portale di Azure aprire la risorsa dell'app per la logica.
Nel menu dell'app per la logica, in Impostazioni, selezionare Rete.
Nella sezione Traffico in ingresso selezionare Restrizione di accesso.
Creare una o più regole per consentire o negare le richieste da intervalli IP specifici. È anche possibile usare le impostazioni del filtro intestazione HTTP e le impostazioni di inoltro.
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 operazionipredefinite seguenti non supportano queste opzioni:
| Input sicuri - Non supportato | Output sicuri - Non supportato |
|---|---|
| Accodare alla variabile di matrice Accodare alla variabile stringa Variabile di decremento Per ogni Se Variabile incrementa Inizializzare la variabile Ricorrenza Ambito Imposta variabile Interruttore Terminare Fino a |
Accodare alla variabile di matrice Accodare alla variabile stringa Comporre Variabile di decremento Per ogni Se Variabile incrementa Inizializzare la variabile Analizzare JSON Ricorrenza Risposta Ambito Imposta variabile Interruttore Terminare Fino a Wait. |
Considerazioni sulla protezione di input e output
Prima di usare queste impostazioni per proteggere questi dati, esaminare queste considerazioni:
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 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 output sicuri in un trigger o in 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 questa azione nella cronologia di esecuzione, ma non abilita l'impostazione Input sicuri 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 queste azioni, ma non abilita l'impostazione Input sicuri di queste azioni. Se un'azione downstream usa in modo esplicito gli output nascosti dalle azioni Compose, Parse JSON o Response come input, App per la logica di Azure non nasconde gli input o gli output dell'azione downstream.
Impostazione degli input protetti
Quando si attiva manualmente input protetti in un trigger o in 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 di tale trigger o azione come input, App per la logica di Azure nasconde gli input dell'azione downstream nella cronologia di esecuzione, ma non abilitainput sicuri in questa azione e non nasconde gli output di questa 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 queste azioni, ma non abilita l'impostazione Input sicuri di queste azioni. Se un'azione downstream usa in modo esplicito gli output nascosti dalle azioni Compose, Parse JSON o Response come input, App per la logica di Azure non nasconde gli input o gli output dell'azione downstream.
Proteggere gli input e gli output nella finestra di progettazione
Nella portale di Azure aprire il flusso di lavoro dell'app per la logica nella finestra di progettazione.
Nella finestra di progettazione selezionare il trigger o l'azione in cui si vogliono proteggere i dati sensibili.
Nel riquadro informazioni visualizzato selezionare Impostazioni ed espandere Sicurezza.
Attivare Input protetti, Output protetti o entrambi.
Il trigger o l'azione mostra ora un'icona di blocco nella barra del titolo. Tutti i token che rappresentano output protetti dalle azioni precedenti mostrano anche le icone di blocco. 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 di blocco.
Dopo l'esecuzione del flusso di lavoro, è possibile visualizzare la cronologia per l'esecuzione.
Selezionare Panoramica nel menu App per la logica a consumo o nel menu Flusso di lavoro Standard.
In Cronologia esecuzioni selezionare l'esecuzione da visualizzare.
Nel riquadro cronologia di esecuzione del flusso di lavoro selezionare le azioni da esaminare.
Se si sceglie di nascondere sia gli input che gli output, questi valori vengono ora visualizzati 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 le azioni HTTP con OAuth con Microsoft Entra ID, è possibile definire e nascondere 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 nella definizione del flusso di lavoro dell'app per la parameters logica e nel 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 in un'intestazione o in un 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, Authorization le intestazioni non sono visibili tramite input o output.
Se quindi viene usato un segreto, questo non sarà recuperabile.
Per altre informazioni, vedere queste 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 le informazioni riservate nella definizione del flusso di lavoro dell'app per la logica, usare i parametri protetti in modo che queste informazioni non siano visibili dopo aver salvato il 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 dell'app per la logica e un flusso di lavoro include più parameters sezioni. 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 sulle sezioni seguenti parameters :
Al livello principale del modello, una sezione
parametersdefinisce 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
parametersspecifica 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
parameterssezione definisce i parametri usati dal flusso di lavoro dell'app per la logica 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 | - Consumo: Azure Gestione API, servizi app 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: - Consumo: Azure Gestione API, servizi app 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 delle identità gestite assegnate dall'utente per l'autenticazione. Connettori gestiti: servizio app Azure, Automazione di Azure, Archiviazione BLOB di Azure, istanza di Azure Container, Azure Cosmos DB, Azure Esplora dati, Azure Data Factory, Azure Data Lake, 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
Chiamate in ingresso ricevute da un'app per la logica tramite un trigger basato su richiesta, ad esempio il trigger request o il trigger Webhook HTTP, supportano la crittografia e sono protetti con Transport Layer Security (TLS) 1.2 almeno, noto in precedenza come Secure Sockets Layer (SSL). App per la logica di Azure applica questa versione quando si riceve una chiamata in ingresso al trigger di 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 di 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 pacchetti di crittografia meno recenti quando si sviluppano nuove app perché tali suite potrebbero non essere supportate in futuro.
Ad esempio, è possibile trovare i pacchetti 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
- Abilitare OAuth con Microsoft Entra ID
- Esporre l'app per la logica con Azure Gestione API
- Limitare gli indirizzi IP in ingresso
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 da usare. |
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 o 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 di richiesta possono usare un solo schema di autorizzazione, sas o OAuth con ID Microsoft Entra. Anche se l'uso di uno schema non disabilita l'altro schema, l'uso di entrambi gli schemi contemporaneamente causa un errore perché il servizio non conosce lo schema da scegliere.
Per altre informazioni sulla protezione dell'accesso con firma di accesso condiviso, vedere queste sezioni in questo argomento:
- Per rigenerare le chiavi di accesso
- Creare URL di callback in scadenza
- Creare URL con una chiave primaria o secondaria
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.
Nel portale di Azure aprire l'app per la logica che contiene la chiave che si desidera rigenerare.
Nel menu delle risorse dell'app per la logica, in Impostazioni, selezionare Chiavi di accesso.
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 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 Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth)
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 Microsoft Entra ID OAuth. Per configurare questa autenticazione, definire o aggiungere criteri 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 rispetto alle attestazioni specificate da 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 di richiesta (ma non con un trigger webhook), è possibile usare il provisioning 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 nelle app per la logica Standard con Easy Auth.
Considerazioni prima di abilitare Microsoft Entra ID OAuth
Una chiamata in ingresso all'endpoint della richiesta può usare un solo schema di autorizzazione, OAuth con l'ID Microsoft Entra o la firma di accesso condiviso. Anche se l'uso di uno schema non disabilita l'altro schema, l'uso di entrambi gli schemi contemporaneamente causa un errore perché App per la logica di Azure non sa quale schema scegliere.
App per la logica di Azure supporta gli schemi di autorizzazione di tipo bearer o proof-of-possession (solo app per la logica a consumo) per i token di accesso OAuth dell'ID Microsoft Entra. Tuttavia, l'intestazione
Authorizationper il token di accesso deve specificare il tipo oPoPilBearertipo. 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 Issuer, che ha un valore che inizia con
https://sts.windows.net/ohttps://login.microsoftonline.com/(OAuth V2) come ID autorità di certificazione Microsoft Entra.Si supponga, ad esempio, che la risorsa dell'app per la logica abbia criteri di autorizzazione che richiedono due tipi di attestazione, Audience e Issuer. Questa sezione di payload di esempio per un token di accesso decodificato include entrambi i tipi di attestazione dove
audè il valore Audience eissè il valore Issuer:{ "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 Microsoft Entra ID OAuth come unica opzione per chiamare un endpoint della richiesta
Configurare il trigger webhook Request o HTTP con la possibilità di controllare il token di accesso OAuth seguendo la procedura per includere l'intestazione "Authorization" negli output del trigger di webhook REQUEST o HTTP.
Nota
Questo passaggio rende visibile l'intestazione
Authorizationnella cronologia di esecuzione del flusso di lavoro e negli output del trigger.Nella portale di Azure aprire il flusso di lavoro dell'app per la logica a consumo nella finestra di progettazione.
Nella finestra di progettazione selezionare il trigger. Nel riquadro informazioni visualizzato selezionare Impostazioni.
In Condizioni generali>del trigger selezionare Aggiungi. Nella casella condizione del trigger immettere una delle espressioni seguenti, in base al tipo di token che si vuole 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 indica che la condizione del trigger non è riuscita.
Ottenere un token di verifica del possesso (PoP)
Le librerie di Microsoft Authentication Library (MSAL) forniscono token PoP da usare. Se il flusso di lavoro dell'app per la logica che si vuole chiamare richiede un token PoP, è possibile ottenere questo token usando le librerie MSAL. Gli esempi seguenti illustrano come acquisire i token PoP:
Un'applicazione console daemon .NET Core che chiama un'API Web protetta con la 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 sezione successiva per configurare OAuth con Microsoft Entra ID.
Abilitare Microsoft Entra ID OAuth per la risorsa dell'app per la logica di consumo
Seguire questa procedura per il portale di Azure o il modello di Azure Resource Manager:
Nella portale di Azure aggiungere uno o più criteri di autorizzazione alla risorsa dell'app per la logica a consumo:
Nella portale di Azure aprire l'app per la logica a consumo nella finestra di progettazione del flusso di lavoro.
Nel menu delle risorse dell'app per la logica, in Impostazioni selezionare Autorizzazione. Dopo l'apertura del riquadro Autorizzazione, selezionare Aggiungi criteri.
Fornire informazioni sui criteri 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:
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 di connessione 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 Request del flusso di lavoro nel token di accesso presentato da ogni chiamata in ingresso al trigger. È possibile aggiungere qualsiasi attestazione standard desiderata selezionando Aggiungi attestazione standard. Per aggiungere un'attestazione specifica di un token PoP, selezionare Aggiungi attestazione personalizzata.
Tipi di attestazione standard disponibili:
- Autorità di certificazione
- Destinatari
- Argomento
- ID JWT (identificatore del token Web JSON)
Requisiti:
- Come minimo, l'elenco Attestazioni deve includere l'attestazione Issuer , che ha un valore che inizia conhttps://sts.windows.net/ohttps://login.microsoftonline.com/come ID autorità di certificazione Microsoft Entra.
- Ogni attestazione deve essere un singolo valore stringa, non una matrice di valori. Ad esempio, è possibile avere un'attestazione con Role come tipo e Developer come valore. Non è possibile avere un'attestazione con Role come tipo e i valori impostati su Developer e Program Manager.
- Il valore dell'attestazione è limitato a un 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:
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 un'attestazione personalizzata, selezionare Aggiungi attestazione personalizzata. Per altre informazioni, vedere come fornire attestazioni facoltative all'app. L'attestazione personalizzata viene quindi archiviata come parte dell'ID JWT; ad esempio .
"tid": "72f988bf-86f1-41af-91ab-2d7cd011db47"
Per aggiungere un altro criterio di autorizzazione, selezionare Aggiungi criteri. Ripetere i passaggi precedenti per configurare i criteri.
Al termine, seleziona Salva.
Per includere l'intestazione del token di accesso negli output dei trigger basati su richiesta, vedere Includere l'intestazione
Authorization'Authorization' negli output dei trigger di richiesta e webhook HTTP.
Le proprietà del flusso di lavoro, ad esempio i criteri, non vengono visualizzate nella visualizzazione codice del flusso di lavoro nella 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. Assicurarsi di 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 'Authorization' negli output del trigger di webhook HTTP o della richiesta
Per le app per la logica che abilitano OAuth con MICROSOFT Entra ID per l'autorizzazione delle chiamate in ingresso per accedere ai trigger basati su richiesta, è possibile abilitare gli output del trigger request o del webhook HTTP per includere l'intestazione Authorization dal token di accesso OAuth. Nella definizione JSON sottostante del trigger aggiungere e impostare la operationOptions proprietà 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:
- Informazioni di riferimento sullo schema per i tipi di trigger e azione - Trigger di richiesta
- Informazioni di riferimento sullo schema per i tipi di trigger e azione - Trigger Webhook HTTP
- Informazioni di riferimento sullo schema per i tipi di trigger e azione - Opzioni dell'operazione
Esporre il flusso di lavoro dell'app per la logica con Azure Gestione API
Per altre opzioni e protocolli di autenticazione, è consigliabile esporre il flusso di lavoro dell'app per la logica come API usando Azure Gestione API. Questo servizio offre funzionalità avanzate di monitoraggio, sicurezza, criteri e documentazione per qualsiasi 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, certificato client o altri standard di sicurezza. Quando Gestione API riceve una richiesta, il servizio invia la richiesta all'app per la logica e apporta tutte le trasformazioni o le restrizioni necessarie lungo il percorso. Per consentire solo Gestione API 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 dell'API Web in Azure Gestione API 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
Insieme alla firma di accesso condiviso, è possibile limitare in modo specifico i client che possono chiamare il flusso di lavoro dell'app per la logica. Ad esempio, se si gestisce l'endpoint della richiesta usando Azure Gestione API, è possibile limitare il flusso di lavoro dell'app per la logica per accettare richieste solo 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 l'API REST di App per la logica: Trigger del flusso di lavoro - Esegui richiesta 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
Nella portale di Azure, la restrizione degli indirizzi IP influisce sia sui trigger che sulle azioni, contrariamente alla descrizione nel portale in Indirizzi IP in ingresso consentiti. Per configurare questo filtro separatamente per i trigger e per le azioni, usare l'oggetto accessControl in un modello di Azure Resource Manager per la risorsa dell'app per la logica o l'API REST App per la logica di Azure: Flusso di lavoro - Creazione o aggiornamento.
Flussi di lavoro a consumo
Nella portale di Azure aprire l'app per la logica a consumo nella finestra di progettazione del flusso di lavoro.
Nel menu dell'app per la logica, in Impostazioni, selezionare Impostazioni del flusso di lavoro.
Nella sezione Configurazione del 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 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 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 predefinita App per la logica di Azure possano 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 viene visualizzato un errore "401 Non autorizzato".
Per gli scenari in cui si desidera limitare le chiamate in ingresso da altri indirizzi 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
Facoltativamente, in Limita chiamate per ottenere messaggi di input e output dalla cronologia di esecuzione agli indirizzi IP specificati, è 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
Nella portale di Azure aprire la risorsa dell'app per la logica.
Nel menu dell'app per la logica, in Impostazioni, selezionare Rete.
Nella sezione Traffico in ingresso selezionare Restrizione di accesso.
Creare una o più regole per consentire o negare le richieste da intervalli IP specifici. È anche possibile 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).
Accesso alle chiamate in uscita ad altri servizi e sistemi
In base alla funzionalità 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, noto in precedenza come Secure Sockets Layer (SSL). App per la logica di Azure negozia con l'endpoint di destinazione usando la versione più alta possibile supportata. Ad esempio, se l'endpoint di destinazione supporta 1.2, il trigger HTTP o l'azione usa prima la versione 1.2. In caso contrario, il connettore usa la versione più recente supportata successiva.
Questo elenco include informazioni sui certificati tls/SSL autofirmato:
Per i flussi di lavoro delle app per la logica a consumo nell'ambiente multi-tenant App per la logica di Azure, le operazioni HTTP non consentono certificati TLS/SSL autofirmato. 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
TrustFailureerrore.Per i flussi di lavoro dell'app per la logica Standard nell'ambiente di App per la logica di Azure a tenant singolo, le operazioni HTTP supportano i certificati TLS/SSL autofirmato. 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 tenant singolo.
Se si vuole usare il certificato client o 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 o OAuth con ID Microsoft Entra con il tipo di credenziale "Certificato" per App per la logica di Azure a tenant singolo.
Ecco altri modi per proteggere gli endpoint che gestiscono le chiamate inviate dai flussi di lavoro dell'app per la logica:
Aggiungere l'autenticazione alle richieste in uscita.
Quando si usa il trigger HTTP o l'azione 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 indirizzi IP designati specifici basati sulle aree delle app per la logica. È possibile aggiungere un filtro che accetti le richieste solo da tali indirizzi IP. Per ottenere 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
Azure Gestione API offre opzioni di connessione locali, ad esempio la rete privata virtuale da sito a sito e l'integrazione di ExpressRoute per il proxy protetto e la comunicazione con i sistemi locali. Se si dispone di un'API che fornisce l'accesso al sistema locale ed è stata esposta tale API 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 visualizzare e connettersi, ma non mostra i servizi di 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
In base al fatto che si stia aggiungendo un trigger o un'azione Gestione API, seguire questa procedura:
Trigger:
Nella finestra di progettazione del flusso di lavoro selezionare Aggiungi un trigger.
Dopo aver aperto il riquadro Aggiungi un trigger, nella casella di ricerca immettere Gestione API.
Nell'elenco dei risultati del trigger selezionare Scegliere un trigger di azure Gestione API.
Azione:
Nella finestra di progettazione del flusso di lavoro selezionare il segno più (+) in cui si vuole aggiungere l'azione.
Dopo aver aperto il riquadro Aggiungi un'azione, nella casella di ricerca immettere Gestione API.
Nell'elenco dei risultati dell'azione selezionare Scegliere un'azione Gestione API di Azure.
L'esempio seguente mostra la ricerca di un trigger di azure Gestione API:
Nell'elenco Gestione API'istanza del servizio selezionare l'istanza del servizio Gestione API creata in precedenza.
Nell'elenco operazioni API selezionare l'operazione API da chiamare e quindi selezionare Aggiungi azione.
Flussi di lavoro standard
Per i flussi di lavoro Standard, è possibile aggiungere solo azioni Gestione API, non trigger.
Nella finestra di progettazione del flusso di lavoro selezionare il segno più (+) in cui si vuole aggiungere l'azione.
Dopo aver aperto il riquadro Aggiungi un'azione, nella casella di ricerca immettere Gestione API.
Nell'elenco dei risultati dell'azione selezionare Chiamare un'API Gestione API di Azure.
Nell'elenco Gestione API'istanza del servizio selezionare l'istanza del servizio Gestione API creata in precedenza.
Nell'elenco Operazioni API selezionare l'operazione API da chiamare e 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à Authentication . Tuttavia, questa proprietà potrebbe non essere sempre visualizzata 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 alle esigenze. Per altre informazioni sull'uso e la protezione dei parametri, vedere Accedere 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 Azure Gestione API. 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 da un file PFX (Personal Information Exchange) Per convertire il file PFX in formato con codifica Base64, è possibile usare PowerShell 7 seguendo questa procedura: 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 ToBase64String() funzione 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 cert mmc/PowerShell comando , è possibile che venga visualizzato 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 di nuovo usando il openssl comando : 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, la stringa ora 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 venga visualizzato l'errore seguente:
BadRequest: Could not load private key
Per risolvere questo errore, effettuare le operazioni seguenti:
- Disinstallare tutte le istanze di OpenSSL.
- Installare OpenSSL versione 1.1.1t.
- Riassegnare il certificato usando il nuovo aggiornamento.
- 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 tenant singolo e si vuole usare un'operazione HTTP con un certificato TSL/SSL, un certificato client o Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) con il Certificate tipo di credenziale, assicurarsi di completare i passaggi di configurazione aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Autenticazione nell'ambiente a tenant singolo.
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
Microsoft Identity Platform
Nei trigger di richiesta è possibile usare Microsoft Identity Platform per l'autenticazione delle 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 segue attualmente 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 gestione delle identità. |
| Tenant | tenant |
Sì | <tenant-ID> | ID 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 tenant singolo e si vuole usare un'operazione HTTP con un certificato TSL/SSL, un certificato client o Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) con il Certificate tipo di credenziale, assicurarsi di completare i passaggi di configurazione aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Autenticazione nell'ambiente a tenant singolo.
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 dell'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 Microsoft Entra. Azure gestisce automaticamente questa identità e consente di proteggere le credenziali perché non è necessario gestire i segreti o usare direttamente i token di Microsoft Entra. Altre informazioni sui servizi di Azure che supportano le 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 contemporaneamente dell'identità gestita assegnata dal sistema e più identità gestite assegnate dall'utente, anche se è comunque possibile selezionare solo un'identità da usare in qualsiasi momento.
Nota
Per impostazione predefinita, l'identità assegnata dal sistema è già abilitata per autenticare le connessioni in fase di esecuzione. Questa identità è diversa dalle credenziali di autenticazione o stringa di connessione usate quando si crea una connessione. Se si disabilita questa identità, le connessioni non funzioneranno in fase di esecuzione. Per visualizzare questa impostazione, nel menu dell'app per la logica, in Impostazioni selezionare Identità.
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.
Prima che una funzione di Azure possa usare un'identità gestita, abilitare l'autenticazione per le funzioni di Azure.
Nel trigger o nell'azione che supporta l'uso di un'identità gestita specificare queste informazioni:
Trigger e azioni predefiniti
Proprietà (progettazione) Proprietà (JSON) Obbligatorio Valore Descrizione Autenticazione typeSì Identità gestita
OManagedServiceIdentityTipo di autenticazione da usare Identità gestita identityNo <user-assigned-identity-ID> Identità gestita assegnata dall'utente da usare. Nota: non includere questa proprietà quando si usa l'identità gestita assegnata dal sistema. Destinatari audienceSì <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 esempiohttps://fabrikamstorageaccount.blob.core.windows.netper un account di archiviazione specifico.
Nota: la proprietà Audience 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: assicurarsi che questo ID risorsa di destinazione corrisponda esattamente al valore previsto dall'ID Microsoft Entra, incluse le barre finali necessarie. Quindi, l'ID della risorsahttps://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
typecomeManagedServiceIdentitye 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 del connettore gestito
Proprietà (progettazione) Obbligatorio Valore Descrizione Nome connessione Sì <nome connessione> Identità gestita Sì Identità gestita assegnata dal sistema
O
<user-assigned-managed-identity-name>Tipo di autenticazione da usare
Creazione di connessioni in blocco
Se l'organizzazione non consente la connessione a risorse specifiche usando i connettori in App per la logica di Azure, è possibile bloccare la possibilità di creare tali connessioni per connettori specifici 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 supportare tutti i livelli di impatto nelle aree descritte nelle linee guida per l'isolamento del livello di impatto 5 Azure per enti pubblici. Per soddisfare questi requisiti, App per la logica di Azure supporta la possibilità 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 di condividere risorse di calcolo con altri tenant.
Per eseguire codice personalizzato o eseguire la trasformazione XML, creare e chiamare una funzione di Azure, anziché usare rispettivamente la funzionalità di codice inline o fornire assembly da usare come mappe. Configurare anche l'ambiente di hosting 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 tariffario servizio app usando il piano tariffario Isolato insieme a un ambiente del servizio app (A edizione Standard) che usa anche 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 offrono isolamento di rete oltre all'isolamento di calcolo per le app e le funzionalità di scalabilità orizzontale massime.
Per altre informazioni, vedere la documentazione seguente:
In base al fatto che si disponga di flussi di lavoro di app per la logica a consumo o standard, sono disponibili queste opzioni:
I flussi di lavoro delle app per la logica standard possono comunicare privatamente e in modo sicuro 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 tenant singolo usando endpoint privati.
I flussi di lavoro delle app per la logica di consumo possono essere eseguiti in un ambiente del servizio di integrazione (I edizione Standard) in cui possono usare risorse dedicate e accedere alle risorse protette da una rete virtuale di Azure. Tuttavia, la risorsa I edizione Standard si ritira il 31 agosto 2024, a causa della dipendenza da Azure Servizi cloud (versione classica), che si ritira contemporaneamente.
Importante
Alcune reti virtuali di Azure usano endpoint privati (collegamento privato di Azure) per fornire l'accesso ai servizi PaaS di Azure, ad esempio Archiviazione di Azure, Azure Cosmos DB o database SQL di Azure, servizi partner o servizi clienti ospitati in Azure.
Per creare flussi di lavoro dell'app per la logica a consumo che devono accedere alle reti virtuali con endpoint privati, è necessario creare ed eseguire i flussi di lavoro a consumo in un edizione Standard. In alternativa, è possibile creare flussi di lavoro Standard, che non necessitano di un edizione Standard. I flussi di lavoro possono invece comunicare privatamente e in modo sicuro con le reti virtuali usando endpoint privati 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 tenant singolo usando endpoint privati.
Per altre informazioni sull'isolamento, vedere la documentazione seguente: