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
Ruolo | Descrizione |
---|---|
Collaboratore per app per la logica | È possibile gestire flussi di lavoro di app per la logica, ma non è possibile modificarne l'accesso. |
Operatore per app per la logica | È possibile leggere, abilitare e disabilitare flussi di lavoro di app per la logica, ma non è possibile modificarli né aggiornarli. |
Collaboratore | Accesso completo per la gestione di tutte le risorse, ma non è possibile assegnare ruoli in Controllo degli accessi in base al ruolo (RBAC) di Azure, né gestire le assegnazioni in Azure Blueprints né condividere raccolte di immagini. |
Si supponga, ad esempio, di dover usare un flusso di lavoro dell’app per la logica che non è stato creato e autenticare le connessioni usate da tale flusso di lavoro dell'app per la logica. La sottoscrizione di Azure richiede autorizzazioni Collaboratore per il gruppo di risorse contenente la risorsa dell'app per la logica. Se si crea una risorsa dell'app per la logica, si dispone automaticamente dell'accesso Collaboratore.
Per impedire ad altri la modifica o l'eliminazione del flusso di lavoro dell’app per la logica, è possibile usare il Blocco delle risorse di Azure. Questa funzionalità impedisce ad altri utenti di modificare o eliminare le risorse di produzione. Per altre informazioni sulla sicurezza delle connessioni, vedere Configurazione della connessione in App per la logica di Azure e Sicurezza e crittografia delle connessioni.
Flussi di lavoro Standard
Nota
Questa funzionalità è in anteprima ed è soggetta alle Condizioni supplementari per l'utilizzo per le anteprime di Microsoft Azure.
Ruolo | Descrizione |
---|---|
Lettore Standard di App per la logica (anteprima) | È possibile accedere in sola lettura a tutte le risorse in un'app per la logica Standard e ai flussi di lavoro, incluse le esecuzioni del flusso di lavoro e la relativa cronologia. |
Operatore Standard di App per la logica (anteprima) | È possibile accedere per abilitare, inviare di nuovo e disabilitare i flussi di lavoro e per creare connessioni a servizi, sistemi e reti per un'app per la logica Standard. Il ruolo Operatore può eseguire attività di amministrazione e supporto nella piattaforma App per la logica di Azure, ma non dispone delle autorizzazioni per modificare flussi di lavoro o impostazioni. |
Sviluppatore Standard di App per la logica (anteprima) | È possibile accedere per creare e modificare flussi di lavoro, connessioni e impostazioni per un'app per la logica Standard. Il ruolo Sviluppatore non dispone delle autorizzazioni per apportare modifiche all'esterno dell'ambito dei flussi di lavoro, ad esempio modifiche a livello di applicazione, come la configurazione dell'integrazione della rete virtuale. I piani Servizio app non sono supportati. |
Collaboratore Standard di App per la logica (anteprima) | È possibile accedere per gestire tutti gli aspetti di un'app per la logica Standard, ma non è possibile modificare l'accesso o la proprietà. |
Accesso ai dati della cronologia di esecuzione
Durante l'esecuzione di un'app per la logica, tutti i dati vengono crittografati durante il transito tramite Transport Layer Security (TLS) e sono inattivi. Al termine dell'esecuzione dell'app per la logica, è possibile visualizzare la cronologia dell'esecuzione, inclusi i passaggi eseguiti con lo stato, la durata, gli input e gli output per ogni azione. Questo approfondimento fornisce informazioni dettagliate sulle modalità di esecuzione dell'app per la logica e su dove è possibile iniziare la risoluzione dei problemi che si verificano.
Quando si visualizza la cronologia di esecuzione di un'app per la logica, App per la logica di Azure autentica l'accesso e fornisce i collegamenti agli input e agli output per le richieste e le risposte per ogni esecuzione. Tuttavia, per le azioni che gestiscono password, segreti, chiavi o altre informazioni riservate, è opportuno impedire ad altri utenti di visualizzare e accedere a tali dati. Ad esempio, se l'app per la logica ottiene un segreto da Azure Key Vault da usare per l'autenticazione di un'azione HTTP, occorre nascondere tale segreto in modo che non venga visualizzato.
Per controllare l'accesso agli input e agli output nella cronologia di esecuzione dell'app per la logica, sono disponibili le opzioni seguenti:
Limitare l'accesso in base all'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:
Flussi di lavoro A consumo
Nel portale di Azure, aprire il flusso di lavoro dell'app per la logica A consumo nella finestra di progettazione.
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, dall'elenco Opzione accesso trigger, selezionare Intervalli IP specifici.
Nella casella Intervalli IP per contenuti, specificare gli intervalli di indirizzi IP che possono accedere ai contenuti da input e output.
Flussi di lavoro Standard
Nel portale di Azure, aprire la risorsa dell’app per la logica Standard.
Nel menu dell'app per la logica, in Impostazioni, selezionare Rete.
Nella sezione Configurazione del traffico in ingresso, accanto ad Accesso alla rete pubblica, selezionare Abilitato senza restrizioni di accesso.
Nella pagina Restrizioni di accesso, in Accesso alle app, selezionare Abilitato da reti virtuali e indirizzi IP selezionati.
In Accesso e regole del sito, nella scheda Sito principale, aggiungere una o più regole alle richieste Consenti o Nega da intervalli IP specifici. È possibile anche usare le impostazioni del filtro intestazione HTTP e le impostazioni di inoltro. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x
Per altre informazioni, vedere Blocco degli indirizzi IP in ingresso in App per la logica di Azure (Standard).
Proteggere i dati nella cronologia di esecuzione usando l'offuscamento
Molti trigger e azioni hanno impostazioni per la protezione degli input, degli output o di entrambi dalla cronologia di esecuzione di un'app per la logica. Tutti i connettori gestiti e i connettori personalizzati supportano queste opzioni. Tuttavia, le operazioni predefinite seguenti non supportano queste opzioni:
Input sicuri - Non supportato | Output sicuri - Non supportato |
---|---|
Accoda a variabile di matrice Accoda a variabile di stringa Decrementare una variabile For each Se Incrementare una variabile Inizializzare una variabile Ricorrenza Scope Impostare una variabile Opzione Terminazione Fino a |
Accoda a variabile di matrice Accoda a variabile di stringa Composizione Decrementare una variabile For each Se Incrementare una variabile Inizializzare una variabile Analizzare JSON Ricorrenza Risposta Scope Impostare una variabile Opzione Terminazione Until Wait. |
Considerazioni sulla protezione di input e output
Prima di usare queste impostazioni per facilitare la protezione di questi dati, esaminare le considerazioni seguenti:
Quando si oscurano gli input o gli output in un trigger o un'azione, App per la logica di Azure non invia i dati protetti ad Azure Log Analytics. Non è inoltre possibile aggiungere proprietà rilevate a tale trigger o azione per il monitoraggio.
L’API di App per la logica di Azure per la gestione della cronologia del flusso di lavoro non restituisce output protetti.
Per proteggere gli output da un'azione che nasconde gli input o nasconde in modo esplicito gli output, attivare manualmente gli output protetti in tale azione.
Assicurarsi di attivare gli input protetti o gli output protetti nelle azioni downstream in cui si prevede che la cronologia di esecuzione nasconda i dati.
Impostazione degli output protetti
Quando si attivano manualmente gli Output protetti in un trigger o un'azione, App per la logica di Azure nasconde questi output nella cronologia di esecuzione. Se un'azione downstream usa in modo esplicito questi output protetti come input, App per la logica di Azure nasconde gli input di tale azione nella cronologia di esecuzione, ma non abilita l'impostazione Input protetti dell'azione.
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
Nel 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 di cui proteggere dati sensibili.
Nel riquadro delle informazioni visualizzato, selezionare Impostazioni ed espandere Sicurezza.
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.
Dopo l'esecuzione del flusso di lavoro, è possibile visualizzare la cronologia per tale 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 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 secureobject
e usare la codifica in base alle esigenze. I parametri con questo tipo non vengono restituiti con la definizione della risorsa e non sono accessibili quando si visualizza la risorsa dopo la distribuzione. Per accedere a questi valori di parametro durante la fase di esecuzione, usare l'espressione @parameters('<parameter-name>')
all'interno della definizione del flusso di lavoro. Questa espressione viene valutata solo in fase di esecuzione e viene descritta dal linguaggio di definizione del flusso di lavoro.
Nota
Se si usa un parametro nelle intestazioni o nel corpo della richiesta, tale parametro potrebbe essere visibile quando si visualizza la cronologia di esecuzione del flusso di lavoro e la richiesta HTTP in uscita. Assicurarsi anche di configurare di conseguenza i criteri di accesso ai contenuti. È possibile anche usare l'offuscamento per nascondere gli input e gli output nella cronologia di esecuzione.
Per impostazione predefinita, le intestazioni Authorization
non sono mai visibili tramite input o output.
Se quindi viene usato un segreto, questo non sarà recuperabile.
Per altre informazioni, vedere le sezioni in questo argomento:
- 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
:
Nome parametro | Descrizione |
---|---|
TemplatePasswordParam |
Parametro di modello che accetta una password che viene quindi passata al parametro basicAuthPasswordParam della definizione del flusso di lavoro |
TemplateUsernameParam |
Parametro di modello che accetta un nome utente che viene quindi passato al parametro basicAuthUserNameParam della definizione del flusso di lavoro |
basicAuthPasswordParam |
Parametro di definizione del flusso di lavoro che accetta la password per l'autenticazione di base in un'azione HTTP |
basicAuthUserNameParam |
Parametro di definizione del flusso di lavoro che accetta il nome utente per l'autenticazione di base in un'azione HTTP |
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"LogicAppName": {
"type": "string",
"minLength": 1,
"maxLength": 80,
"metadata": {
"description": "Name of the Logic App."
}
},
"TemplatePasswordParam": {
"type": "securestring"
},
"TemplateUsernameParam": {
"type": "securestring"
},
"LogicAppLocation": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"allowedValues": [
"[resourceGroup().location]",
"eastasia",
"southeastasia",
"centralus",
"eastus",
"eastus2",
"westus",
"northcentralus",
"southcentralus",
"northeurope",
"westeurope",
"japanwest",
"japaneast",
"brazilsouth",
"australiaeast",
"australiasoutheast",
"southindia",
"centralindia",
"westindia",
"canadacentral",
"canadaeast",
"uksouth",
"ukwest",
"westcentralus",
"westus2"
],
"metadata": {
"description": "Location of the Logic App."
}
}
},
"variables": {},
"resources": [
{
"name": "[parameters('LogicAppName')]",
"type": "Microsoft.Logic/workflows",
"location": "[parameters('LogicAppLocation')]",
"tags": {
"displayName": "LogicApp"
},
"apiVersion": "2016-06-01",
"properties": {
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://www.microsoft.com",
"authentication": {
"type": "Basic",
"username": "@parameters('basicAuthUsernameParam')",
"password": "@parameters('basicAuthPasswordParam')"
}
},
"runAfter": {}
}
},
"parameters": {
"basicAuthPasswordParam": {
"type": "securestring"
},
"basicAuthUsernameParam": {
"type": "securestring"
}
},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"schema": {}
}
}
},
"contentVersion": "1.0.0.0",
"outputs": {}
},
"parameters": {
"basicAuthPasswordParam": {
"value": "[parameters('TemplatePasswordParam')]"
},
"basicAuthUsernameParam": {
"value": "[parameters('TemplateUsernameParam')]"
}
}
}
}
],
"outputs": {}
}
Tipi di autenticazione per i connettori che supportano l'autenticazione
La tabella seguente identifica i tipi di autenticazione disponibili nelle operazioni del connettore in cui è possibile selezionare un tipo di autenticazione:
Tipo di autenticazione | App per la logica e connettori supportati |
---|---|
Base | Gestione API di Azure, servizio app di Azure, HTTP, HTTP + Swagger, HTTP Webhook |
Certificato client | Gestione API di Azure, servizio app di Azure, HTTP, HTTP + Swagger, HTTP Webhook |
Active Directory OAuth | - A consumo: Gestione API di Azure, Servizi app di Azure, Funzioni di Azure, HTTP, HTTP + Swagger, Webhook HTTP - Standard: Automazione di Azure, Archiviazione BLOB di Azure, Hub eventi di Azure, Code di Azure, Bus di servizio di Azure, Tabelle di Azure, HTTP, Webhook HTTP, SQL Server |
Raw | Gestione API di Azure, servizi app di Azure, Funzioni di Azure, HTTP, HTTP + Swagger, HTTP Webhook |
Identità gestita | Connettori predefiniti: - A consumo: Gestione API di Azure, Servizi app di Azure, Funzioni di Azure, HTTP, Webhook HTTP - Standard: Automazione di Azure, Archiviazione BLOB di Azure, Hub eventi di Azure, Code di Azure, Bus di servizio di Azure, Tabelle di Azure, HTTP, Webhook HTTP, SQL Server Nota: attualmente, la maggior parte dei connettori predefiniti basati su provider di servizi non supporta la selezione di identità gestite assegnate dall'utente per l'autenticazione. Connettori gestiti: Servizio app di Azure, Automazione di Azure, Archiviazione BLOB di Azure, Istanza di contenitore di Azure, Azure Cosmos DB, Esplora dati di Azure, Azure Data Factory, Data Lake di Azure, Griglia di eventi di Azure, Hub eventi di Azure, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Code di Azure, Azure Resource Manager, Bus di servizio di Azure, Azure Sentinel, Archiviazione tabelle di Azure, Macchina virtuale di Azure, HTTP con Microsoft Entra ID, SQL Server |
Accesso per le chiamate in ingresso ai trigger basati su richiesta
Le chiamate in ingresso ricevute da un'app per la logica tramite un trigger basato su richiesta, ad esempio il trigger Richiesta o il trigger Webhook HTTP, supportano la crittografia e sono protetti con Transport Layer Security (TLS) 1.2 almeno, precedentemente noto come Secure Sockets Layer (SSL). App per la logica di Azure applica questa versione quando viene ricevuta una chiamata in ingresso al trigger Richiesta o un callback al trigger o all'azione Webhook HTTP. Se si verificano errori di handshake TLS, assicurarsi di usare TLS 1.2. Per altre informazioni, vedere Risoluzione del problema relativo a TLS 1.0.
Per le chiamate in ingresso, usare le suite di crittografia seguenti:
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Nota
Per la compatibilità con le versioni precedenti, App per la logica di Azure supporta attualmente alcune suite di crittografia meno recenti. Tuttavia, non usare suite di crittografia meno recenti quando si sviluppano nuove app, perché tali suite potrebbero non essere supportate in futuro.
Ad esempio, è possibile trovare le suite di crittografia seguenti se si esaminano i messaggi di handshake TLS durante l'uso del servizio App per la logica di Azure o usando uno strumento di sicurezza nell'URL dell'app per la logica. Anche in questo caso, non usare queste suite meno recenti:
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
L'elenco seguente include altri modi per limitare l'accesso ai trigger che ricevono chiamate in ingresso all'app per la logica in modo che solo i client autorizzati possano chiamare l'app per la logica:
- Generare firme di accesso condiviso (SAS)
- Abilitare OAuth con Microsoft Entra ID
- Esporre l'app per la logica con Gestione API di Azure
- 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
, sv
e sig
come descritto nella tabella seguente:
Query parameter (Parametro di query) | Descrizione |
---|---|
sp |
Specifica le autorizzazioni per i metodi HTTP consentiti. |
sv |
Specifica la versione usata per generare la firma. |
sig |
Specifica la firma da usare per l'autenticazione dell'accesso al trigger. La firma viene generata attraverso l'algoritmo SHA256 con una chiave di accesso privata in tutti i percorsi e le proprietà dell'URL. Questa chiave viene mantenuta crittografata, archiviata con l’app per la logica, e non viene mai esposta né pubblicata. L'app per la logica autorizza solo i trigger che contengono una firma valida creata con la chiave privata. |
Le chiamate in ingresso a un endpoint richiesta possono usare un solo schema di autorizzazione, SAS oppure OAuth con Microsoft Entra ID. Anche se l'uso di uno schema non disabilita l'altro schema, l'uso contemporaneo di entrambi gli schemi causa un errore perché il servizio non riconosce lo schema da scegliere.
Per altre informazioni sulla protezione dell'accesso con SAS, vedere queste sezioni in questo argomento:
- Per rigenerare le chiavi di accesso
- 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 della risorsa 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 di App per la logica di Azure, ad esempio:
POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01
Nel corpo includere la NotAfter
proprietà usando una stringa di data JSON. Questa proprietà restituisce un URL di callback valido solo fino a data e ora NotAfter
.
Creare URL con una chiave privata primaria o secondaria
Quando si generano URL di callback per i trigger basati su richieste, è possibile specificare la chiave da usare per firmare l'URL. Per generare un URL firmato da una chiave specifica usare l'API REST delle app per la logica, ad esempio:
POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01
Nel corpo includere la proprietà KeyType
come Primary
o Secondary
. Questa proprietà restituisce un URL firmato dalla chiave di sicurezza specificata.
Abilitare Open Authentication con Microsoft Entra ID (OAuth con Microsoft Entra ID)
In un flusso di lavoro dell'app per la logica A consumo che inizia con un trigger basato su richiesta, è possibile autenticare le chiamate in ingresso inviate all'endpoint creato da tale trigger abilitando OAuth con Microsoft Entra ID. Per configurare questa autenticazione, definire o aggiungere un criterio di autorizzazione a livello di app per la logica. In questo modo, le chiamate in ingresso usano token di accesso OAuth per l'autorizzazione.
Quando il flusso di lavoro dell'app per la logica riceve una richiesta in ingresso che include un token di accesso OAuth, App per la logica di Azure confronta le attestazioni del token con le attestazioni specificate in ogni criterio di autorizzazione. Se esiste una corrispondenza tra le attestazioni del token e tutte le attestazioni in almeno un criterio, l'autorizzazione ha esito positivo per la richiesta in ingresso. Il token può avere più attestazioni rispetto al numero specificato dal criterio di autorizzazione.
In un flusso di lavoro dell'app per la logica Standard che inizia con il trigger Richiesta (ma non con un trigger Webhook), è possibile usare il provisioning di Funzioni di Azure per autenticare le chiamate in ingresso inviate all'endpoint creato da tale trigger usando un'identità gestita. Questo provisioning è noto anche come "Easy Auth". Per altre informazioni, vedere Attivare flussi di lavoro in app per la logica Standard con Easy Auth
Considerazioni prima dell’abilitazione di OAuth con Microsoft Entra ID
Una chiamata in ingresso a un endpoint richiesta può usare un solo schema di autorizzazione, OAuth con Microsoft Entra ID o la firma di accesso condiviso (SAS). Anche se l'uso di uno schema non disabilita l'altro schema, l'uso contemporaneo di entrambi gli schemi causa un errore perché App per la logica di Azure non riconosce lo schema da scegliere.
App per la logica di Azure supporta gli schemi di autorizzazione tipo Bearer o il tipo Proof-of-Possession (solo app per la logica A consumo) per i token di accesso OAuth con Microsoft Entra ID. Tuttavia, l'intestazione
Authorization
per il token di accesso deve specificare il tipoBearer
o il tipoPoP
. Per altre informazioni su come ottenere e usare un token PoP, vedere Ottenere un token PoP (Proof of Possession).La risorsa dell'app per la logica è limitata a un numero massimo di criteri di autorizzazione. Ogni criterio di autorizzazione ha anche un numero massimo di attestazioni. Per altre informazioni, vedere Limiti e configurazione per App per la logica di Azure.
Un criterio di autorizzazione deve includere almeno l'attestazione dell'Emittente, che ha un valore che inizia con
https://sts.windows.net/
ohttps://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 eiss
è il valore di Emittente:{ "aud": "https://management.core.windows.net/", "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/", "iat": 1582056988, "nbf": 1582056988, "exp": 1582060888, "_claim_names": { "groups": "src1" }, "_claim_sources": { "src1": { "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects" } }, "acr": "1", "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=", "amr": [ "rsa", "mfa" ], "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c", "appidacr": "2", "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab", "family_name": "Sophia Owen", "given_name": "Sophia Owen (Fabrikam)", "ipaddr": "167.220.2.46", "name": "sophiaowen", "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7", "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475", "puid": "1003000000098FE48CE", "scp": "user_impersonation", "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k", "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47", "unique_name": "SophiaOwen@fabrikam.com", "upn": "SophiaOwen@fabrikam.com", "uti": "TPJ7nNNMMZkOSx6_uVczUAA", "ver": "1.0" }
Abilitare OAuth con Microsoft Entra ID come unica opzione per chiamare un endpoint richiesta
Configurare il trigger Richiesta o Webhook HTTP con la possibilità di controllare il token di accesso OAuth seguendo la procedura per includere l'intestazione "Autorizzazione" negli output del trigger Richiesta o Webhook HTTP.
Nota
Questo passaggio rende visibile l'intestazione
Authorization
nella cronologia di esecuzione del flusso di lavoro e negli output del trigger.Nel 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 delle informazioni visualizzato, selezionare Impostazioni.
In Generale>Condizioni trigger, selezionare Aggiungi. Nella casella condizione del trigger, immettere una delle espressioni seguenti, in base al tipo di token da usare:
@startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')
oppure
@startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')
Se si chiama l'endpoint del trigger senza l'autorizzazione corretta, la cronologia di esecuzione mostra solo il trigger come Skipped
senza alcun messaggio che la condizione del trigger non è riuscita.
Ottenere un token Proof-of-Possession (PoP)
Le librerie MSAL (Microsoft Authentication Library) forniscono i token PoP da usare. Se il flusso di lavoro dell'app per la logica da chiamare richiede un token PoP, è possibile ottenere questo token usando le librerie MSAL. Gli esempi seguenti illustrano come acquisire i token PoP:
Per usare il token PoP con il flusso di lavoro dell'app per la logica A consumo, seguire la sezione successiva per configurare OAuth con Microsoft Entra ID.
Abilitare OAuth con Microsoft Entra ID per la risorsa dell'app per la logica A consumo
Seguire questa procedura per il portale di Azure o il modello di Azure Resource Manager:
Nel portale di Azure, aggiungere uno o più criteri di autorizzazione alla risorsa dell'app per la logica A consumo:
Nel portale di Azure, aprire l'app per la logica A consumo nella finestra di progettazione del flusso di lavoro.
Nel menu della risorsa dell’'app per la logica, in Impostazioni, selezionare Autorizzazione. Dopo l'apertura del riquadro Autorizzazione, selezionare Aggiungi criteri.
Fornire informazioni sul criterio di autorizzazione specificando i tipi di attestazione e i valori previsti dall'app per la logica nel token di accesso presentato da ogni chiamata in ingresso al trigger Richiesta:
Proprietà Richiesto Type Descrizione Nome del criterio Sì String Il nome da usare per il criterio di autorizzazione Tipo di criterio Sì String AAD per i token di tipo bearer o AADPOP per i token di tipo Proof-of-Possession. Richieste Sì String Coppia chiave-valore che specifica il tipo di attestazione e il valore previsti dal trigger Richiesta del flusso di lavoro nel token di accesso presentato da ogni chiamata in ingresso al trigger. È possibile aggiungere qualunque attestazione standard desiderata selezionando Aggiungi attestazione standard. Per aggiungere un'attestazione specifica a un token PoP, selezionare Aggiungi attestazione personalizzata.
Tipi di attestazione standard disponibili:
- Autorità di certificazione
- Destinatari
- Argomento
- ID JWT (identificatore token JSON Web)
Requisiti:
- L'elenco di Attestazioni deve includere almeno l'attestazione dell'Emittente, il cui valore inizia conhttps://sts.windows.net/
ohttps://login.microsoftonline.com/
come ID emittente Microsoft Entra.
- Ogni attestazione deve essere un singolo valore stringa, non una matrice di valori. Ad esempio, è possibile avere un'attestazione con Ruolo come tipo e Sviluppatore come valore. Non è possibile avere un'attestazione con Ruolo come tipo e i valori impostati su Sviluppatore e Program Manager.
- Il valore dell’attestazione è limitato al numero massimo di caratteri.
Per altre informazioni su questi tipi di attestazione, vedere Attestazioni nei token di sicurezza di Microsoft Entra. È anche possibile specificare il proprio tipo di attestazione e il proprio valore.L'esempio seguente mostra le informazioni per un token PoP:
Per aggiungere un'altra attestazione, selezionare una delle opzioni seguenti:
Per aggiungere un altro tipo di attestazione, selezionare Aggiungi attestazione standard, selezionare il tipo di attestazione e specificare il valore dell'attestazione.
Per aggiungere una propria attestazione, selezionare Aggiungi attestazione personalizzata. Per altre informazioni, vedere come fornire attestazioni facoltative all'app. L'attestazione personalizzata, quindi, viene archiviata come parte dell'ID JWT, ad esempio
"tid": "72f988bf-86f1-41af-91ab-2d7cd011db47"
.
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
Authorization
dal token di accesso negli output dei trigger basati su richiesta, esaminare Includere l'intestazione “Autorizzazione” negli output dei trigger Richiesta e Webhook HTTP.
Le proprietà del flusso di lavoro, ad esempio i criteri, non appaiono nella visualizzazione del codice del flusso di lavoro nel portale di Azure. Per accedere ai criteri a livello di codice, chiamare l'API seguente tramite Azure Resource Manager: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820
. Sostituire i valori segnaposto per l'ID sottoscrizione di Azure, il nome del gruppo di risorse e il nome del flusso di lavoro.
Includere l'intestazione “Autorizzazione” negli output dei trigger Richiesta o Webhook HTTP
Per le app per la logica che abilitano OAuth con Microsoft Entra ID per autorizzare chiamate in ingresso per accedere ai trigger basati su richiesta, è possibile abilitare gli output dei trigger Richiesta o Webhook HTTP per includere l'intestazione Authorization
dal token di accesso OAuth. Nella definizione JSON sottostante del trigger, aggiungere la proprietà operationOptions
e impostarla su IncludeAuthorizationHeadersInOutputs
. Di seguito è riportato un esempio per il trigger Richiesta:
"triggers": {
"manual": {
"inputs": {
"schema": {}
},
"kind": "Http",
"type": "Request",
"operationOptions": "IncludeAuthorizationHeadersInOutputs"
}
}
Per altre informazioni, vedere questi argomenti:
- 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
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 dell’API REST di app per la logica: trigger del flusso di lavoro - Esegui o usando Gestione API. Tuttavia, in questo caso potrebbe essere richiesta l'autenticazione all'API REST di Azure. Tutti gli eventi vengono visualizzati nel log di controllo di Azure. Assicurarsi di impostare i criteri di controllo di accesso di conseguenza.
Per limitare gli indirizzi IP in ingresso per il flusso di lavoro dell'app per la logica, seguire i passaggi corrispondenti per il portale di Azure o il modello di Azure Resource Manager. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x
Nel portale di Azure, la restrizione degli indirizzi IP influisce su trigger e azioni, contrariamente alla descrizione nel portale in Indirizzi IP in ingresso consentiti. Per configurare questo filtro separatamente per trigger e azioni, usare l'oggetto accessControl
in un modello di Azure Resource Manager per la risorsa dell'app per la logica o l’API REST di App per la logica di Azure: Flusso di lavoro - Operazione Crea o Aggiorna.
Flussi di lavoro A consumo
Nel 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 controllo di accesso, in Indirizzi IP in ingresso consentiti, scegliere il percorso per lo scenario:
Per rendere il flusso di lavoro chiamabile usando l’azione predefinita di App per la logica di Azure, ma solo come flusso di lavoro annidato, selezionare Solo altre app per la logica. Questa opzione funziona solo quando si usa l'azione di App per la logica di Azure per chiamare il flusso di lavoro annidato.
Questa opzione scrive una matrice vuota nella risorsa dell'app per la logica e richiede che solo le chiamate dai flussi di lavoro padre che usano l’azione di App per la logica di Azure predefinita possono attivare il flusso di lavoro annidato.
Per rendere il flusso di lavoro chiamabile usando l'azione HTTP, ma solo come flusso di lavoro annidato, selezionare Intervalli IP specifici. Quando viene visualizzata la casella Intervalli IP per i trigger, immettere gli indirizzi IP in uscita del flusso di lavoro padre. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x
Nota
Se si usa l'opzione Solo altre app per la logica e l'azione HTTP per chiamare il flusso di lavoro annidato, la chiamata viene bloccata e si verifica un errore "401 Non autorizzato".
Per gli scenari in cui si desidera limitare le chiamate in ingresso da altri IP, quando viene visualizzata la casella Intervalli IP per i trigger, specificare gli intervalli di indirizzi IP accettati dal trigger. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x
Facoltativamente, in Limitare le chiamate per ottenere messaggi di input e output dalla cronologia di esecuzione agli indirizzi IP forniti, è possibile specificare gli intervalli di indirizzi IP per le chiamate in ingresso che possono accedere ai messaggi di input e output nella cronologia di esecuzione.
Flussi di lavoro Standard
Nel portale di Azure, aprire la risorsa dell’app per la logica Standard.
Nel menu dell'app per la logica, in Impostazioni, selezionare Rete.
Nella sezione Configurazione del traffico in ingresso, accanto ad Accesso alla rete pubblica, selezionare Abilitato senza restrizioni di accesso.
Nella pagina Restrizioni di accesso, in Accesso alle app, selezionare Abilitato da reti virtuali e indirizzi IP selezionati.
In Accesso e regole del sito, nella scheda Sito principale, aggiungere una o più regole alle richieste Consenti o Nega da intervalli IP specifici. Un intervallo IP valido usa questi formati: x.x.x.x/x o x.x.x.x-x.x.x.x
Per altre informazioni, vedere Blocco degli indirizzi IP in ingresso in App per la logica di Azure (Standard).
Accesso alle chiamate in uscita ad altri servizi e sistemi
In base alla capacità dell'endpoint di destinazione, le chiamate in uscita inviate dal trigger HTTP o dall'azione HTTP supportano la crittografia e sono protette con Transport Layer Security (TLS) 1.0, 1.1 o 1.2, precedentemente noto come Secure Sockets Layer (SSL). App per la logica di Azure negozia con l'endpoint di destinazione usando la versione più alta supportata. Ad esempio, se l'endpoint di destinazione supporta 1.2, il trigger o l’azione HTTP o usa prima 1.2. In caso contrario, il connettore usa la successiva versione più recente supportata.
Questo elenco include informazioni sui certificati TLS/SSL autofirmati:
Per i flussi di lavoro dell’app per la logica A consumo nell'ambiente di App per la logica di Azure multi-tenant, le operazioni HTTP non consentono certificati TLS/SSL autofirmati. Se l'app per la logica effettua una chiamata HTTP a un server e presenta un certificato autofirmato TLS/SSL, la chiamata HTTP non riesce con un errore
TrustFailure
.Per i flussi di lavoro dell’app per la logica A consumo nell'ambiente di App per la logica di Azure a singolo tenant, le operazioni HTTP supportano certificati TLS/SSL autofirmati. Tuttavia, è necessario completare alcuni passaggi aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Autenticazione del certificato TLS/SSL per App per la logica di Azure a singolo tenant.
Se si desidera usare il certificato client oppure OAuth con Microsoft Entra ID con il tipo di credenziale Certificato, è comunque necessario completare alcuni passaggi aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Certificato client oppure OAuth con Microsoft Entra ID con il tipo di credenziale "Certificato" per App per la logica di Azure a singolo tenant.
Di seguito sono indicati alcuni modi per facilitare la protezione degli endpoint che gestiscono chiamate inviate dai flussi di lavoro dall'app per la logica:
Aggiungere l’autenticazione alle richieste in uscita.
Quando si usa il trigger o l’azione HTTP per inviare chiamate in uscita, è possibile aggiungere l'autenticazione alla richiesta inviata dall'app per la logica. È ad esempio possibile selezionare i tipi di autenticazione seguenti:
Limitare l'accesso dagli indirizzi IP del flusso di lavoro dell’app per la logica.
Tutte le chiamate agli endpoint dai flussi di lavoro dell’app per la logica provengono da specifici indirizzi IP designati basati sulle aree delle app per la logica. È possibile aggiungere un filtro che accetti le richieste solo da tali indirizzi IP. Per un elenco di questi indirizzi IP, vedere Limiti e configurazione per App per la logica di Azure.
Migliorare la sicurezza per le connessioni ai sistemi locali.
Le app per la logica offrono integrazione con tali servizi per fornire una comunicazione locale più sicura e affidabile.
Gateway dati locale
Molti dei connettori gestiti in App per la logica di Azure offrono una connettività sicura a sistemi locali, tra cui File System, SQL, SharePoint, DB2. Il gateway inoltra i dati da origini locali sui canali crittografati tramite il bus di servizio di Azure. Tutto il traffico ha origine come traffico sicuro in uscita dall'agente di gateway. Altre informazioni su come funziona il gateway dati locale.
Connettersi attraverso Gestione API di Azure
Gestione API di Azure fornisce opzioni di connettività locale, ad esempio una rete privata virtuale da sito a sito e l’integrazione ExpressRoute per proxy e comunicazione sicuri con sistemi locali. Se si dispone di un'API che fornisce l'accesso al sistema locale e tale API è stata esposta creando un'Istanza del servizio Gestione API, è possibile chiamare tale API dal flusso di lavoro dell'app per la logica selezionando l'operazione Gestione API corrispondente nella finestra di progettazione del flusso di lavoro.
Nota
Il connettore mostra solo i servizi Gestione API in cui si dispone delle autorizzazioni per la visualizzazione e la connessione, ma non mostra i servizi Gestione API basati sul consumo.
In base al tipo di risorsa dell'app per la logica, seguire i passaggi corrispondenti:
Flussi di lavoro A consumo
A seconda che si aggiunga o un trigger o un’azione di Gestione API, seguire questa procedura:
Trigger:
Nella finestra di progettazione del flusso di lavoro, selezionare Aggiungi un trigger.
Dopo l’apertura del riquadro Aggiungi un trigger, nella casella di ricerca immettere Gestione API.
Nell'elenco dei risultati del trigger, selezionare Scegli un trigger di Gestione API di Azure.
Azione:
Nella finestra di progettazione del flusso di lavoro, selezionare il segno più (+) dove aggiungere l'azione.
Dopo l’apertura del riquadro Aggiungi un’azione, nella casella di ricerca immettere Gestione API.
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:
Dall'elenco dell'istanza del servizio Gestione API, selezionare l'istanza del servizio Gestione API creata in precedenza.
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.
Nella finestra di progettazione del flusso di lavoro, selezionare il segno più (+) dove aggiungere l'azione.
Dopo l’apertura del riquadro Aggiungi un’azione, nella casella di ricerca immettere Gestione API.
Nell'elenco dei risultati dell’azione, selezionare Chiama un’API di Gestione API di Azure.
Dall'elenco dell'istanza del servizio Gestione API, selezionare l'istanza del servizio Gestione API creata in precedenza.
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 Aggiungi nuovo parametro e selezionare Autenticazione.
Importante
Per proteggere le informazioni riservate gestite dall'app per la logica, usare i parametri protetti e codificare i dati in base alla necessità. Per altre informazioni sull'uso e sulla protezione dei parametri, vedere Accesso agli input dei parametri.
Autenticazione di base
Se è disponibile l'opzione Basic, specificare i valori delle proprietà seguenti:
Proprietà (progettazione) | Proprietà (JSON) | Obbligatorio | Valore | Descrizione |
---|---|---|---|---|
Autenticazione | type |
Sì | Di base | Tipo di autenticazione da usare |
Nome utente | username |
Sì | <user-name> | Il nome utente per l'autenticazione dell'accesso all'endpoint del servizio di destinazione |
Password | password |
Sì | <password> | La password per l'autenticazione dell'accesso all'endpoint del servizio di destinazione |
Quando si usano i parametri protetti per gestire e proteggere le informazioni riservate, ad esempio in un modello di Azure Resource Manager per l'automazione della distribuzione, è possibile usare le espressioni per accedere a questi valori di parametro in fase di esecuzione. Questa definizione di azione HTTP di esempio specifica l'autenticazione type
come Basic
e usa la funzione dei parametri() per ottenere i valori dei parametri:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "Basic",
"username": "@parameters('userNameParam')",
"password": "@parameters('passwordParam')"
}
},
"runAfter": {}
}
Autenticazione con certificato client
Se è disponibile l'opzione Certificato client, specificare i valori delle proprietà seguenti:
Proprietà (progettazione) | Proprietà (JSON) | Obbligatorio | Valore | Descrizione |
---|---|---|---|---|
Autenticazione | type |
Sì | Certificato client o ClientCertificate |
Tipo di autenticazione da usare. È possibile gestire i certificati con Gestione API di Azure. Nota: i connettori personalizzati non supportano l'autenticazione basata su certificati per le chiamate in ingresso e in uscita. |
Pfx | pfx |
Sì | <encoded-pfx-file-content> | Contenuto con codifica base64 del file di scambio di informazioni personali (PFX, Personal Information Exchange) Per convertire il file PFX in formato con codifica Base64, è possibile usare PowerShell 7 attenendosi alla procedura seguente: 1. Salvare il contenuto del certificato in una variabile: $pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx') 2. Convertire il contenuto del certificato usando la funzione ToBase64String() e salvare il contenuto in un file di testo: [System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt' Risoluzione dei problemi: se si usa il comando cert mmc/PowerShell , è possibile che si ottenga questo errore: Could not load the certificate private key. Please check the authentication certificate password is correct and try again. Per risolvere questo errore, provare a convertire il file PFX in un file PEM e ripetere l’operazione usando il comando openssl : openssl pkcs12 -in certificate.pfx -out certificate.pem openssl pkcs12 -in certificate.pem -export -out certificate2.pfx Successivamente, quando si ottiene la stringa con codifica base64 per il file PFX appena convertito del certificato, ora la stringa funziona in App per la logica di Azure. |
Password | password |
No | <password-for-pfx-file> | Password per accedere al file PFX. |
Nota
Se si tenta di eseguire l'autenticazione con un certificato client usando OpenSSL, è possibile che si ottenga l'errore seguente:
BadRequest: Could not load private key
Per risolvere questo errore, effettuare le operazioni seguenti:
- 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 singolo tenant e si desidera usare un'operazione HTTP con un certificato TSL/SSL, un certificato client o Open Authentication con Microsoft Entra ID (OAuth con Microsoft Entra ID) con il tipo di credenziale Certificate
, completare i passaggi di configurazione aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Autenticazione in un ambiente a singolo tenant.
Per altre informazioni sulla protezione dei servizi tramite l'autenticazione del certificato client, vedere gli argomenti seguenti:
- 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 Richiesta è possibile usare Microsoft Identity Platform per autenticare le chiamate in ingresso dopo aver configurato i criteri di autorizzazione di Microsoft Entra per l'app per la logica. Per tutti gli altri trigger e azioni che forniscono il tipo di autenticazione Active Directory OAuth da selezionare, specificare i valori delle proprietà seguenti:
Proprietà (progettazione) | Proprietà (JSON) | Obbligatorio | Valore | Descrizione |
---|---|---|---|---|
Autenticazione | type |
Sì | Active Directory OAuth o ActiveDirectoryOAuth |
Tipo di autenticazione da usare. App per la logica di Azure attualmente segue il protocollo OAuth 2.0. |
Authority | authority |
No | <URL-for-authority-token-issuer> | URL dell'autorità che fornisce il token di accesso, ad esempio https://login.microsoftonline.com/ per le aree del servizio globale di Azure. Per altri cloud nazionali, vedere Endpoint di autenticazione di Microsoft Entra - Scelta dell'autorità di identità. |
Tenant | tenant |
Sì | <tenant-ID> | ID del tenant per il tenant di Microsoft Entra |
Destinatari | audience |
Sì | <resource-to-authorize> | La risorsa che si vuole usare per l'autorizzazione, ad esempio https://management.core.windows.net/ |
ID client | clientId |
Sì | <client-ID> | L'ID client per l'app richiedente l'autorizzazione |
Tipo di credenziali | credentialType |
Sì | Certificato o Segreto |
Il tipo di credenziale che il client usa per la richiesta di autorizzazione. Questa proprietà e questo valore non vengono visualizzati nella definizione sottostante dell'app per la logica, ma determinano le proprietà che vengono visualizzate per il tipo di credenziale selezionato. |
Segreto | secret |
Sì, ma solo per il tipo di credenziale "Segreto" | <client-secret> | Il segreto client per la richiesta dell'autorizzazione |
Pfx | pfx |
Sì, ma solo per il tipo di credenziale "Certificato" | <encoded-pfx-file-content> | Contenuto con codifica base64 del file di scambio di informazioni personali (PFX, Personal Information Exchange) |
Password | password |
Sì, ma solo per il tipo di credenziale "Certificato" | <password-for-pfx-file> | Password per accedere al file PFX. |
Quando si usano i parametri protetti per gestire e proteggere le informazioni riservate, ad esempio in un modello di Azure Resource Manager per l'automazione della distribuzione, è possibile usare le espressioni per accedere a questi valori di parametro in fase di esecuzione. Questa definizione di azione HTTP di esempio specifica l'autenticazione type
come ActiveDirectoryOAuth
, il tipo di credenziali come Secret
e usa la funzione dei parametri() per ottenere i valori dei parametri:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "ActiveDirectoryOAuth",
"tenant": "@parameters('tenantIdParam')",
"audience": "https://management.core.windows.net/",
"clientId": "@parameters('clientIdParam')",
"credentialType": "Secret",
"secret": "@parameters('secretParam')"
}
},
"runAfter": {}
}
Importante
Se si dispone di una risorsa dell'app per la logica Standard in App per la logica di Azure a singolo tenant e si desidera usare un'operazione HTTP con un certificato TSL/SSL, un certificato client o Open Authentication con Microsoft Entra ID (OAuth con Microsoft Entra ID) con il tipo di credenziale Certificate
, completare i passaggi di configurazione aggiuntivi per questo tipo di autenticazione. In caso contrario, la chiamata non riesce. Per altre informazioni, vedere Autenticazione in un ambiente a singolo tenant.
Autenticazione con dati non elaborati
Se l'opzione Raw è disponibile, è possibile usare questo tipo di autenticazione quando è necessario usare gli schemi di autenticazione che non seguono il protocollo OAuth 2.0. Con questo tipo, si crea manualmente il valore dell'intestazione di autorizzazione inviato con la richiesta in uscita e si specifica il valore dell'intestazione nel trigger o nell'azione.
L’esempio seguente mostra un'intestazione di esempio per una richiesta HTTPS che segue il protocollo OAuth 1.0:
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131200",
oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
Nel trigger o nell'azione che supporta l'autenticazione con dati non elaborati specificare i valori delle proprietà seguenti:
Proprietà (progettazione) | Proprietà (JSON) | Obbligatorio | Valore | Descrizione |
---|---|---|---|---|
Autenticazione | type |
Sì | Raw | Tipo di autenticazione da usare |
Valore | value |
Sì | <authorization-header-value> | Valore dell'intestazione di autorizzazione da usare per l'autenticazione |
Quando si usano i parametri protetti per gestire e proteggere le informazioni riservate, ad esempio in un modello di Azure Resource Manager per l'automazione della distribuzione, è possibile usare le espressioni per accedere a questi valori di parametro in fase di esecuzione. Questa definizione di azione HTTP di esempio specifica l'autenticazione type
come Raw
e usa la funzione dei parametri() per ottenere i valori dei parametri:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "Raw",
"value": "@parameters('authHeaderParam')"
}
},
"runAfter": {}
}
Autenticazione identità gestita
Quando l'opzione identità gestita è disponibile nel trigger o nell’azione che supporta l'autenticazione dell'identità gestita, l'app per la logica può usare questa identità per autenticare l'accesso alle risorse di Azure protette da Microsoft Entra ID, anziché credenziali, segreti o token di Microsoft Entra. Azure gestisce automaticamente questa identità e facilita la protezione delle credenziali perché l’utente non deve gestire segreti o usare direttamente token di Microsoft Entra. Sono disponibili altre informazioni sui Servizi di Azure che supportano identità gestite per l'autenticazione di Microsoft Entra.
Una risorsa dell'app per la logica A consumo può usare l'identità assegnata dal sistema o una singola identità assegnata dall'utente creata manualmente.
Una risorsa dell'app per la logica Standard supporta l’abilitazione contemporanea dell’identità gestita assegnata dal sistema e più identità gestite assegnate dall'utente, anche se è comunque possibile selezionare una sola identità alla volta per l’uso.
Nota
Per impostazione predefinita, l'identità assegnata dal sistema è già abilitata per autenticare le connessioni nel runtime. Questa identità è diversa dalle credenziali di autenticazione o dalla stringa di connessione usata quando si crea una connessione. Se si disabilita questa identità, le connessioni non funzioneranno nel runtime. Per visualizzare questa impostazione, nel menu dell'app per la logica, in Impostazioni, selezionare Identità.
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 predefinite.
Proprietà (progettazione) Proprietà (JSON) Obbligatorio Valore Descrizione Autenticazione type
Sì Identità gestita
oManagedServiceIdentity
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 esempiohttps://fabrikamstorageaccount.blob.core.windows.net
per un account di archiviazione specifico.
Nota: la proprietà Destinatari potrebbe essere nascosta in alcuni trigger o azioni. Per fare in modo che la proprietà venga visualizzata, nel trigger o nell'azione, aprire l'elenco Aggiungi nuovo parametro e selezionare Destinatari.
Importante: accertarsi che questo ID della risorsa di destinazione corrisponda esattamente al valore previsto da Microsoft Entra ID, incluse eventuali barre finali necessarie. Quindi, l'ID della 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
type
comeManagedServiceIdentity
e usa la funzione parameters() per ottenere i valori dei parametri:"HTTP": { "type": "Http", "inputs": { "method": "GET", "uri": "@parameters('endpointUrlParam')", "authentication": { "type": "ManagedServiceIdentity", "audience": "https://management.azure.com/" }, }, "runAfter": {} }
Trigger e azioni connettori gestiti
Proprietà (progettazione) Obbligatorio Valore Descrizione Nome connessione Sì <nome connessione> Identità gestita Sì Identità gestita assegnata dal sistema
o
<Nome identità gestita assegnata dall’utente>Tipo di autenticazione da usare
Creazione di connessioni in blocco
Se l'organizzazione non consente la connessione a risorse specifiche usando i relativi connettori in App per la logica di Azure, è possibile bloccare la capacità di creare tali connessioni per determinati connettori nei flussi di lavoro dell'app per la logica usando Criteri di Azure. Per altre informazioni, vedere Bloccare le connessioni create da connettori specifici in App per la logica di Azure.
Linee guida sull'isolamento per le app per la logica
È possibile usare App per la logica di Azure in Azure per enti pubblici che supporta tutti i livelli di impatto nelle aree descritte dalle Linee guida per l'isolamento al livello di impatto 5 di Azure per enti pubblici. Per soddisfare questi requisiti, App per la logica di Azure supporta la capacità di creare ed eseguire flussi di lavoro in un ambiente con risorse dedicate in modo da ridurre l'impatto sulle prestazioni da parte di altri tenant di Azure nelle app per la logica ed evitare la condivisione delle risorse di calcolo con altri tenant.
Per 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:
A seconda che si disponga di flussi di lavoro dell’app per la logica A consumo o Standard, sono disponibili le seguenti opzioni:
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.
I flussi di lavoro delle app per la logica A consumo possono essere eseguiti in un ambiente del servizio di integrazione (ISE) in cui possono usare risorse dedicate e accedere alle risorse protette da una rete virtuale di Azure. Tuttavia, la risorsa ISE viene ritirata il 31 agosto 2024 a causa della dipendenza da Servizi cloud di Azure (versione classica) che si ritira contemporaneamente.
Importante
Alcune reti virtuali di Azure usano endpoint privati (Collegamento privato di Azure) per fornire l'accesso a servizi PaaS di Azure, ad esempio Archiviazione di Azure, Azure Cosmos DB o Database SQL di Azure, servizi partner o servizi di clienti ospitati in Azure.
Per creare flussi di lavoro dell'app per la logica A consumo che devono accedere a reti virtuali con endpoint privati, è necessario creare ed eseguire i flussi di lavoro A consumo in un ISE. In alternativa, è possibile creare flussi di lavoro Standard, che non richiedono un ISE. I flussi di lavoro possono comunicare in maniera privata e sicura con reti virtuali di Azure 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 singolo tenant usando endpoint privati.
Per altre informazioni sull’isolamento, vedere la documentazione seguente: