Protezione di Funzioni di Azure

In molti casi, la pianificazione di sviluppo, distribuzione e funzionamento sicuri delle funzioni serverless è molto simile a quella di qualsiasi applicazione ospitata sul Web o nel cloud. Servizio app di Azure rende disponibile l'infrastruttura di hosting per le app per le funzioni. Questo articolo illustra le strategie di sicurezza per l'esecuzione del codice funzione e le modalità in cui il Servizio app è utile nel proteggere le funzioni.

I componenti della piattaforma del servizio app di Azure, incluse le macchine virtuali di Azure (VM), lo storage, le connessioni di rete, i framework web e le funzionalità di gestione e integrazione sono attivamente sicuri e rinforzati. Servizio app di Azure viene sottoposto continuamente a rigorosi controlli della conformità per assicurarsi che:

• Le risorse dell'app sono protette dalle risorse di Azure di altri clienti.
• Le istanze di macchine virtuali e il software di runtime vengano regolarmente aggiornati in modo da contrastare le vulnerabilità appena individuate.
• La comunicazione dei segreti ,ad esempio le stringhe di connessione, tra l'app e altre risorse di Azure (ad esempio il database SQL di Azure) rimane in Azure e non supera i limiti di rete. I segreti siano sempre crittografati quando vengono archiviati.
• Tutte le comunicazioni tramite le funzionalità di connettività di Servizio app di Azure, ad esempio la connessione ibrida, siano crittografate.
• Le connessioni con strumenti di gestione remota come Azure PowerShell, l'interfaccia della riga di comando di Azure, gli SDK di Azure e le API REST sono tutte crittografate.
• La gestione delle minacce di 24 ore protegge l'infrastruttura e la piattaforma da malware, denial of service distribuito (DDoS), attacchi man-in-the-middle e altre minacce.

Per altre informazioni sulla sicurezza dell'infrastruttura e della piattaforma in Azure, vedere il Centro protezione di Azure.

Per una serie di consigli sulla sicurezza ce seguono il benchmark della sicurezza cloud di Microsoft, vedere Baseline di sicurezza di Azure per Funzioni di Azure.

Utilizzo sicuro

Questa sezione illustra come configurare ed eseguire l'app per le funzioni nel modo più sicuro possibile.

Defender per Cloud di Microsoft

Defender per il cloud si integra con l'app per le funzioni nel portale. Offre gratuitamente una rapida valutazione delle potenziali vulnerabilità della sicurezza relative alla configurazione. Le app per le funzioni in esecuzione in un piano dedicato possono anche usare le funzionalità di sicurezza avanzata di Defender per il cloud a fronte di un costo aggiuntivo. Per ulteriori informazioni, vedere Defender for App Service.

Log e monitoraggio

Una modalità per rilevare attacchi consiste nel monitoraggio delle attività e nell'analisi delle registrazioni. Funzioni si integra con Application Insights per raccogliere i dati di log, prestazioni ed errori per l'app per le funzioni. Application Insights, oltre a rilevare automaticamente le anomalie nelle prestazioni, include strumenti di analisi avanzati che consentono di diagnosticare i problemi e capire come vengono usate le funzioni. Per altre informazioni, vedere Monitorare Funzioni di Azure.

Funzioni si integra anche con i log di Monitoraggio di Azure per consentire all'utente di consolidare i log delle app per le funzioni con gli eventi del sistema e semplificare l'analisi. È possibile usare le impostazioni di diagnostica per configurare l'esportazione di streaming dei log e delle metriche della piattaforma per le funzioni nella destinazione scelta, ad esempio un'area di lavoro Log Analytics. Per altre informazioni, vedere Monitoraggio di Funzioni di Azure con i log di Monitoraggio di Azure.

Per il rilevamento delle minacce a livello aziendale e l'automazione delle risposte, trasmettere i log e gli eventi a un'area di lavoro Log Analytics. È quindi possibile connettere Microsoft Sentinel a questa area di lavoro. Per altre informazioni, vedere Informazioni su Microsoft Sentinel.

Per altre raccomandazioni sulla sicurezza per l'osservabilità, consultare le Informazioni di base sulla sicurezza di Azure per Funzioni di Azure.

Proteggere gli endpoint HTTP

Gli endpoint HTTP esposti pubblicamente forniscono un vettore di attacco per gli attori malintenzionati. Quando si proteggono gli endpoint HTTP, è consigliabile usare un approccio di sicurezza a più livelli. Queste tecniche possono essere usate per ridurre la vulnerabilità degli endpoint HTTP esposti pubblicamente, nell'ordine dalla più semplice alla più sicura e restrittiva:

• Richiedere HTTPS
• Richiedere chiavi di accesso
• Abilitare l'autenticazione/autorizzazione del servizio app
• Usare Gestione API di Azure (APIM) per autenticare le richieste
• Distribuire l'app per le funzioni in una rete virtuale
• Distribuire l'app per le funzioni in isolamento

Richiedere HTTPS

Per impostazione predefinita, i client possono connettersi agli endpoint della funzione tramite HTTP o HTTPS. È consigliabile reindirizzare HTTP a HTTPS perché HTTPS usa il protocollo TLS per fornire una connessione sicura, che è sia crittografata che autenticata. Per informazioni su come fare, vedere Applicare HTTPS.

Quando si richiede HTTPS, è necessario richiedere anche la versione più recente di TLS. Per informazioni su come fare, vedere Applicare versioni di TLS.

Per altre informazioni, vedere Proteggere le connessioni (TLS).

Chiavi di accesso alle funzioni

Funzioni consente di usare le chiavi per rendere più difficile l'accesso agli endpoint di funzione. A meno che il livello di accesso HTTP in una funzione attivata tramite HTTP non sia impostato su anonymous, le richieste devono includere una chiave di accesso. Per altre informazioni, vedere Usare le chiavi di accesso in Funzioni di Azure.

Anche se le chiavi di accesso possono mitigare in qualche modo l'accesso indesiderato, l'unico modo per proteggere in modo sicuro gli endpoint della funzione consiste nell'implementare l'autenticazione positiva dei client che accedono alle funzioni. È quindi possibile prendere decisioni sulle autorizzazioni in base all'identità.

Per il livello di sicurezza più elevato, è anche possibile proteggere l'intera architettura dell'applicazione all'interno di una rete virtuale usando endpoint privati o con l'esecuzione in isolamento..

Disabilitare gli endpoint amministrativi

Le app per le funzioni possono gestire gli endpoint amministrativi nella route /admin che può essere usata per operazioni quali ottenere informazioni sullo stato dell'host ed eseguire chiamate di test. In caso di esposizione, le richieste relative a questi endpoint devono includere la chiave master dell'app. Le operazioni amministrative sono disponibili anche tramite l'API Microsoft.Web/sites di Azure Resource Manager, che offre il controllo degli accessi in base al ruolo di Azure. È possibile disabilitare gli endpoint /admin impostando la proprietà del sito functionsRuntimeAdminIsolationEnabled su true. Questa proprietà non può essere impostata per le app in esecuzione nello SKU di consumo Linux e non può essere impostata per le app in esecuzione su versione 1.x di Azure Functions. Se si usa la versione 1.x, è prima necessario eseguire la migrazione alla versione 4.x.

Abilitare l'autenticazione/autorizzazione di Servizio app di Azure

La piattaforma del servizio app consente di usare Microsoft Entra ID e diversi provider di identità non Microsoft per autenticare i client. È possibile usare questa strategia per implementare regole di autorizzazione personalizzate per le funzioni ed è possibile lavorare con le informazioni utente dal codice di funzione. Per altre informazioni, vedere Autenticazione e autorizzazione nel servizio app di Azure e Uso delle identità client.

Usare Gestione API di Azure (APIM) per autenticare le richieste

Gestione API offre varie opzioni di sicurezza di API per le richieste in ingresso. Per altre informazioni, vedere Criteri di autenticazione di Gestione API. Con APIM, è possibile configurare l'app per le funzioni in modo che accetti le richieste solo dall'indirizzo IP dell'istanza APIM. Per altre informazioni, vedere Restrizioni degli indirizzi IP.

Autorizzazioni

Come per qualsiasi applicazione o servizio, l'obiettivo è eseguire l'app per le funzioni con il minor numero di autorizzazioni possibile.

Autorizzazioni di gestione dell'utente

Funzioni supporta il controllo degli accessi in base al ruolo di Azure (Azure RBAC) predefinito. I ruoli di Azure supportati da Funzioni sono Collaboratore, Proprietario e Lettore.

Le autorizzazioni sono effettive a livello di app per le funzioni. Il ruolo di Collaboratore è necessario per eseguire la maggior parte delle attività a livello di app per le funzioni. È anche necessario il ruolo Collaboratore insieme all'autorizzazione lettore di monitoraggio per poter visualizzare i dati di log in Application Insights. Solo il ruolo di Proprietario può eliminare un'app per le funzioni.

Organizzare le funzioni per privilegio

Le stringhe di connessione e altre credenziali archiviate nelle impostazioni dell'applicazione conferiscono a tutte le funzioni nell'app per le funzioni lo stesso set di autorizzazioni nella risorsa associata. Provare a ridurre al minimo il numero di funzioni con accesso a credenziali specifiche spostando le funzioni che non usano tali credenziali in un'app per le funzioni separata. È sempre possibile usare tecniche come il concatenamento delle funzioni per spostare i dati tra funzioni in app per le funzioni diverse.

Identità gestite

Un'identità gestita da Microsoft Entra ID consente all'app di accedere facilmente ad altre risorse protette da Microsoft Entra, ad esempio Azure Key Vault. La piattaforma Azure gestisce l'identità, quindi non è necessario effettuare il provisioning o aggiornare i segreti. Per altre informazioni sulle identità gestite in Microsoft Entra ID, vedere Identità gestite per le risorse di Azure.

È possibile concedere due tipi di identità all'applicazione:

• Un'identità assegnata dal sistema viene associata all'applicazione e viene eliminata in caso di eliminazione dell'app. Un'app può avere una sola identità assegnata dal sistema.
• Un'identità assegnata dall'utente è una risorsa di Azure autonoma che può essere assegnata all'app. Un'app può avere più identità assegnate dall'utente. Un'identità assegnata dall'utente può essere assegnata a più risorse di Azure, ad esempio due app del servizio app.

Le identità gestite possono essere usate al posto dei segreti per le connessioni da alcuni trigger e associazioni. Vedere Connessioni basate su identità.

Per altre informazioni, vedere Usare le identità gestite per il servizio app e Funzioni di Azure.

Limitare l'accesso CORS

La condivisione di risorse tra le origini (CORS) è un modo per consentire alle app Web in esecuzione in un altro dominio di effettuare richieste agli endpoint del trigger HTTP. Il servizio app offre supporto predefinito per la gestione delle intestazioni CORS necessarie nelle richieste HTTP. Le regole CORS sono definite a livello di app per le funzioni.

È allettante utilizzare un jolly che consente a tutti i siti di accedere al tuo endpoint. Questo approccio sconfigge lo scopo di CORS, che è quello di prevenire attacchi di scripting tra siti. Aggiungere, invece, una voce CORS separata per il dominio di ogni app Web che deve accedere all'endpoint.

Gestione dei segreti

Per potersi connettere ai vari servizi e alle risorse è necessario eseguire il codice, le app per le funzioni devono poter accedere ai segreti, quali le stringhe di connessione e le chiavi del servizio. Questa sezione descrive come archiviare i segreti necessari per le funzioni.

Non archiviare mai segreti nel codice funzione.

Impostazioni delle applicazioni

Per impostazione predefinita, le stringhe di connessione e i segreti usati dall'app per le funzioni e le associazioni vengono archiviati come impostazioni applicazione. Questo approccio rende queste credenziali disponibili sia per il codice della funzione che per le varie associazioni usate dalla funzione. Il nome dell'impostazione applicazione (chiave) viene usato per recuperare il valore effettivo, ovvero il segreto.

Per ogni app per le funzioni, ad esempio, è necessario un account di archiviazione associato, che viene usato dal runtime. Per impostazione predefinita, la connessione a questo account di archiviazione è archiviata in un'impostazione applicazione denominata AzureWebJobsStorage.

Le impostazioni dell'app e le stringhe di connessione vengono archiviate crittografate in Azure. Vengono decrittografate solo prima di essere inserite nella memoria del processo dell'app all'avvio dell'app. Le chiavi di crittografia vengono sottoposte a rotazione regolarmente. Se si preferisce gestire l'archiviazione protetta dei segreti, l'impostazione dell'app deve fare riferimento ai segreti di Azure Key Vault.

È anche possibile crittografare le impostazioni per impostazione predefinita nel file local.settings.json durante lo sviluppo di funzioni nel computer locale. Per altre informazioni, vedere Crittografare il file delle impostazioni locali.

Riferimenti a Key Vault

Anche se le impostazioni dell'applicazione sono sufficienti per la maggior parte delle funzioni, è possibile condividere gli stessi segreti tra più servizi. In questo caso, l'archiviazione ridondante dei segreti comporta un numero maggiore di potenziali vulnerabilità. Un approccio più sicuro prevede l'uso di un servizio di archiviazione segreta centrale e di riferimenti a questo servizio anziché ai segreti stessi.

Azure Key Vault è un servizio che supporta la gestione centralizzata dei segreti con controllo completo sui criteri di accesso e sulla cronologia di controllo. È possibile usare un riferimento a Key Vault invece di una stringa di connessione o di una chiave nelle impostazioni applicazione. Per ulteriori informazioni, vedere Usare i riferimenti a Key Vault per App Service e Funzioni di Azure.

Connessioni basate su identità

Le identità possono essere usate al posto dei segreti per la connessione ad alcune risorse. L'approccio ha il vantaggio di non richiedere la gestione di segreti e offre un controllo dell'accesso e un audit più dettagliato.

Quando si scrive codice che crea la connessione ai servizi di Azure che supportano l'autenticazione di Microsoft Entra, è possibile usare un'identità anziché una stringa di connessione o un segreto. I dettagli per entrambi i metodi di connessione sono descritti nella documentazione per ogni servizio.

Alcune estensioni di associazione di Funzioni di Azure possono essere configurate per accedere ai servizi tramite connessioni basate su identità. Per altre informazioni, vedere Configurare una connessione basata su identità.

Impostare le quote di utilizzo

È consigliabile impostare una quota di utilizzo per le funzioni in esecuzione in un piano a consumo. Quando si imposta un limite giornaliero di GB al secondo per l'esecuzione totale delle funzioni nell'app per le funzioni, l'esecuzione viene arrestata quando si raggiunge il limite. Questo approccio potrebbe contribuire potenzialmente a ridurre il rischio di codice dannoso che esegue le funzioni. Per informazioni su come stimare il consumo per le funzioni, vedere Stima dei costi del piano a consumo.

Convalida dei dati

I trigger e i binding usati dalle funzioni non forniscono alcuna convalida aggiuntiva dei dati. Il codice deve convalidare i dati ricevuti da un trigger o da un'associazione di input. Se un servizio upstream viene compromesso, gli input non convalidati non devono passare nelle funzioni. Ad esempio, se la funzione archivia i dati di una coda di Archiviazione di Azure in un database relazionale, è necessario convalidare i dati e impostare i parametri dei comandi per evitare attacchi intrusivi nel codice SQL.

È consigliabile non dare per scontato che i dati in ingresso nella funzione siano già stati convalidati o puliti. È anche consigliabile verificare che i dati scritti nelle associazioni di output siano validi.

Gestione degli errori

Sebbene sembri banale, è importante scrivere una corretta gestione degli errori nelle funzioni. Gli errori non gestiti vengono propagati all'host e il runtime li gestisce. Le diverse associazioni gestiscono l'elaborazione degli errori in modo diverso. Per altre informazioni, vedere Gestione degli errori di Funzioni di Azure.

Disabilitare il debug remoto

Assicurarsi che il debug remoto sia disabilitato, tranne quando si esegue attivamente il debug delle funzioni. È possibile disabilitare il debug remoto nella scheda Impostazioni generali della Configurazione dell'app per le funzioni nel portale.

Limitare l'accesso CORS

Funzioni di Azure supporta la condivisione di risorse tra origini (CORS, Cross-Origin Resource Sharing). La funzionalità CORS è configurata nel portale e tramite l'interfaccia della riga di comando di Azure. L'elenco delle origini consentite per CORS si applica a livello di app per le funzioni. Con la funzionalità CORS abilitata, le risposte includono l'intestazione Access-Control-Allow-Origin. Per altre informazioni, vedere Utilizzare la condivisione di risorse tra origini.

Non usare caratteri jolly nell'elenco di origini consentite. Elencare invece i domini specifici da cui si prevede di ricevere le richieste.

Archiviare i dati crittografati

Archiviazione di Azure crittografa tutti i dati in un account di archiviazione inattivo. Per altre informazioni, vedere Crittografia di Archiviazione di Azure per dati inattivi.

Per impostazione predefinita, i dati vengono crittografati con chiavi gestite da Microsoft. Per un maggiore controllo sulle chiavi di crittografia, è possibile fornire chiavi gestite dal cliente da usare per la crittografia dei dati di BLOB e file. Queste chiavi devono essere presenti in Azure Key Vault affinché le funzioni possano accedere all'account di archiviazione. Per ulteriori informazioni, consulta Crittografa i dati dell'applicazione a riposo utilizzando chiavi gestite dal cliente.

Proteggere le risorse correlate

Un'app per le funzioni dipende spesso da altre risorse, quindi parte della protezione dell'app protegge queste risorse esterne. La maggior parte delle app per le funzioni include almeno una dipendenza da Application Insights e Archiviazione di Azure. Per indicazioni sulla protezione di queste risorse, vedere Baseline di sicurezza di Azure per Monitoraggio di Azure e Baseline di sicurezza di Azure per l'archiviazione.

È anche consigliabile consultare le indicazioni per qualsiasi tipo di risorsa da cui dipende la logica dell'applicazione, sia come trigger che come binding e dal codice della funzione.

Distribuzione sicura

Gli strumenti e l'integrazione di Funzioni di Azure semplificano la pubblicazione del codice progetto della funzione locale in Azure. È importante comprendere il funzionamento della distribuzione quando si considera la sicurezza per una topologia di Funzioni di Azure.

Credenziali per la distribuzione

Le distribuzioni del servizio app richiedono un insieme di credenziali per la distribuzione. Queste credenziali per la distribuzione vengono usate per proteggere le distribuzioni dell'app per le funzioni. La piattaforma del servizio app gestisce le credenziali di distribuzione. Le credenziali vengono crittografate a riposo.

Sono disponibili due tipi di credenziali per la distribuzione:

• Credenziali a livello di utente: un set di credenziali per l'intero account Azure. Queste credenziali possono essere usate per distribuire il Servizio app per qualsiasi app, in tutte le sottoscrizioni a cui l'account di Azure è autorizzato ad accedere. Questo set di credenziali è l'impostazione predefinita visualizzata nell'ambiente grafico del portale, ad esempio in Panoramica e proprietà nel riquadro delle risorse dell'app. Quando a un utente viene concesso l'accesso alle app tramite il controllo degli accessi in base al ruolo o le autorizzazioni del coamministratore, possono usare le credenziali a livello di utente fino alla revoca dell'accesso. Non condividere queste credenziali con altri utenti di Azure.

• Credenziali a livello di app: un set di credenziali per ogni app. Queste credenziali possono essere usate solo per la distribuzione in tale app. Le credenziali per ogni app vengono generate automaticamente al momento della creazione dell'app. Non possono essere configurate manualmente, ma possono essere reimpostate in qualsiasi momento. Per concedere a un utente l'accesso alle credenziali a livello di app tramite il controllo degli accessi in base al ruolo, tale utente deve disporre del livello Collaboratore o superiori per l'app (incluso il ruolo predefinitoCollaboratore sito Web). I lettori non sono autorizzati a pubblicare e non possono accedere a tali credenziali.

In questo momento, Key Vault non è supportato per le credenziali di distribuzione. Per altre informazioni su come gestire le credenziali per la distribuzione, vedere Configurazione delle credenziali per la distribuzione del Servizio app di Azure.

Disabilitare l'FTP

Per impostazione predefinita, per ogni app per le funzioni è abilitato un endpoint FTP. È possibile accedere all'endpoint FTP usando le credenziali di distribuzione.

L'FTP non è consigliato per la distribuzione del codice funzione. Le distribuzioni FTP sono manuali e richiedono la sincronizzazione dei trigger. Per altre informazioni, vedere Distribuzione FTP.

Quando non si prevede l'uso dell'FTP, è necessario disabilitarlo nel portale. Se si sceglie di usarlo, è necessario applicare FTPS.

Proteggere l'endpoint scm

Ogni app per le funzioni ha un endpoint di servizio scm corrispondente usato dal servizio Strumenti avanzati (Kudu) per le distribuzioni e altre estensioni del sito del Servizio app. L'endpoint scm per un'app per le funzioni è sempre un URL nel formato https://<FUNCTION_APP_NAME>.scm.azurewebsites.net. Quando si usa l'isolamento rete per proteggere le funzioni, è necessario tenere presente anche questo endpoint.

Se si dispone di un endpoint scm separato, è possibile controllare le distribuzioni e altre funzionalità avanzate degli strumenti per le app per le funzioni che sono isolate o in esecuzione in una rete virtuale. L'endpoint scm supporta sia l'autenticazione di base, che usa le credenziali di distribuzione, che il Single Sign-On con le credenziali del portale di Azure. Per altre informazioni, vedere Accesso al servizio Kudu.

Valutazione continua della sicurezza

Poiché la sicurezza deve essere considerata in ogni fase del processo di sviluppo, è opportuno implementare anche la convalida della sicurezza in un ambiente di distribuzione continua. Questo approccio è talvolta denominato DevSecOps. L'uso di Azure DevOps per la pipeline di distribuzione consente di integrare la convalida nel processo di distribuzione. Per altre informazioni, vedere Proteggere Azure Pipelines.

Sicurezza della rete

La limitazione dell'accesso di rete per l'app per le funzioni consente di controllare gli utenti che possono accedere agli endpoint delle funzioni. Funzioni utilizza l'infrastruttura del servizio app per consentire alle funzioni di accedere alle risorse senza usare indirizzi instradabili tramite internet o limitare l'accesso a Internet all'endpoint della funzione. Per altre informazioni su queste opzioni di rete, vedere Opzioni di rete di Funzioni di Azure.

Impostare le restrizioni di accesso

Le restrizioni di accesso consentono di definire gli elenchi di regole Consenti/Nega per controllare il traffico verso l'app. Le regole vengono valutate in ordine di priorità. Se non sono definite regole, l'app accetta il traffico da qualsiasi indirizzo. Per ulteriori informazioni, vedere Restrizioni di accesso al servizio Azure App.

Proteggere l'account di archiviazione

Quando si crea un'app per le funzioni, è necessario creare o collegare un account di archiviazione di Azure di uso generico che supporta l'archiviazione BLOB, Coda e Tabella. È possibile sostituire questo account di archiviazione con uno protetto da una rete virtuale con l'accesso abilitato da endpoint di servizio o endpoint privati. Per altre informazioni, vedere Limitare l'account di archiviazione a una rete virtuale.

Distribuire l'app per le funzioni in una rete virtuale

L'endpoint privato di Azure è un'interfaccia di rete che si connette in modo privato e sicuro a un servizio basato sul collegamento privato di Azure. L'endpoint privato usa un indirizzo IP privato della rete virtuale, portando il servizio nella rete virtuale in modo efficace.

È possibile usare l'endpoint privato per le funzioni ospitate nei piani Flex Consumption, Elastic Premium e Dedicated (App Service).

Se si desidera effettuare chiamate a endpoint privati, è necessario assicurarsi che le ricerche DNS vengano risolte nell'endpoint privato. È possibile applicare questo comportamento in uno dei modi seguenti:

• Eseguire l'integrazione con zone private di DNS di Azure. Quando la rete virtuale non ha un server DNS personalizzato, questa operazione viene eseguita automaticamente.
• Gestire l'endpoint privato nel server DNS usato dall'app. Per gestire un endpoint privato, è necessario conoscere l'indirizzo dell'endpoint e usare un record A per fare riferimento all'endpoint che si sta tentando di raggiungere.
• Configurare il proprio server DNS per l'inoltro alle zone private DNS di Azure.

Per altre informazioni, vedere Uso di endpoint privati per App Web.

Distribuire l'app per le funzioni in isolamento

L'ambiente del servizio app di Azure offre un ambiente di hosting dedicato in cui eseguire le funzioni. Questi ambienti consentono di configurare un singolo gateway front-end che è possibile usare per autenticare tutte le richieste in ingresso. Per altre informazioni, vedere Integrare l'ambiente App Service ILB con il gateway applicazione di Azure.

Usare un servizio gateway

I servizi gateway, quali gateway applicazione di Azure e Frontdoor di Azure consentono di configurare un web application firewall (WAF). Le regole WAF vengono usate per monitorare o bloccare gli attacchi rilevati, offrendo un livello di protezione aggiuntiva per le funzioni. Per configurare un WAF, è necessario che l'app per le funzioni sia in esecuzione in un ambiente del servizio app di Azure o che usi endpoint privati (anteprima). Per altre informazioni, vedere Uso di endpoint privati.

Passaggi successivi

• Baseline di sicurezza di Azure per Funzioni di Azure
• Diagnostica di Funzioni di Azure