Protezione di Funzioni di Azure

  • Articolo

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.

Ai componenti della piattaforma di Servizio app di Azure, incluse le macchine virtuali di Azure, l'archiviazione, le connessioni di rete, i framework Web e le funzionalità di gestione e integrazione, viene applicata attivamente una protezione avanzata. Servizio app di Azure viene sottoposto continuamente a rigorosi controlli della conformità per assicurarsi che:

  • Le risorse dell'app siano protette dalle risorse di Azure degli 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 di segreti (ad esempio stringhe di connessione) tra l'app e altre risorse di Azure (ad esempio database SQL) rimanga all'interno di Azure e non superi i confini 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.
  • Tutte le connessioni con strumenti di gestione remota, come Azure PowerShell, l'interfaccia della riga di comando di Azure, Azure SDK e le API REST, siano crittografate.
  • La gestione delle minacce 24 ore su 24 protegga l'infrastruttura e la piattaforma da malware, attacchi Distributed Denial of Service (DDoS), attacchi man-in-the-middle (MITM) e altre minacce.

Per altre informazioni sulla sicurezza della piattaforma e dell'infrastruttura in Azure, vedere 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 for Cloud

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 altre informazioni, vedere Proteggere le app Web e le API del Servizio app di Azure.

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 Che cos'è 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

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 SSL/TLS per garantire una connessione protetta, crittografata e 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 nell'SKU a consumo Linux e non può essere impostata per le app in esecuzione nella versione 1.x di Funzioni di Azure. 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à terzi 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 in Servizio app di Azure e Utilizzo 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 di Azure. 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 di Microsoft Entra ID consente all'app di accedere facilmente ad altre risorse protette da Microsoft Entra, come Azure Key Vault. L'identità viene gestita dalla piattaforma Azure e non è necessario eseguire il provisioning o ruotare alcun segreto. Per altre informazioni sulle identità gestite in Microsoft Entra ID, vedere Identità gestite per le risorse di Azure.

All'applicazione possono essere concessi due tipi di identità:

  • Un'identità assegnata dal sistema viene associata all'applicazione e viene eliminata in caso di eliminazione dell'app. A un'app può essere associata 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 e un'unica 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 Come usare le identità gestite nel servizio app e in 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.

Anche se si tenta di utilizzare un carattere jolly che consente a tutti i siti di accedere all'endpoint, ciò vanifica lo scopo di CORS, cioè impedire attacchi cross-site scripting. 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. In questo modo le credenziali sono disponibili sia per il codice 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

Sebbene le impostazioni applicazione siano sufficienti per la maggior parte delle funzioni, è consigliabile 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 altre informazioni, vedere Usare i riferimenti a Key Vault per Servizio app e Funzioni di Azure.

Connessioni basate su identità

Per la connessione ad alcune risorse è possibile usare identità anziché segreti. Ciò ha il vantaggio di non richiedere la gestione di un segreto e consente un controllo e un controllo degli accessi più granulari.

Quando si scrive codice che crea la connessione a servizi di Azure che supportano l'autenticazione di Microsoft Entra, è possibile scegliere di 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 potrebbe contribuire a ridurre il rischio di esecuzione di un codice dannoso per 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 le associazioni usate dalle funzioni non garantiscono anche la convalida 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 si propagano nell'host e vengono gestiti dal runtime. 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 il debug attivo 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 specificare chiavi gestite dal cliente da usare per la crittografia dei dati BLOB e di file. Queste chiavi devono essere presenti in Azure Key Vault affinché le funzioni possano accedere all'account di archiviazione. Per altre informazioni, vedere Crittografia dei dati inattivi con le chiavi gestite dal cliente.

Un'app per le funzioni dipende spesso da risorse aggiuntive, 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.

Importante

L'account di archiviazione viene usato per archiviare dati importanti dell'app, a volte incluso il codice dell'applicazione stesso. È consigliabile limitare l'accesso da altre app e utenti all'account di 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. Le credenziali per la distribuzione sono gestite dalla piattaforma del Servizio app e vengono crittografate quando sono inattive.

Sono disponibili due tipi di credenziali per la distribuzione:

  • Credenziali a livello di utente: un insieme di credenziali per tutto l'account Azure. Può essere usato per distribuire il Servizio app per qualsiasi app, in tutte le sottoscrizioni a cui l'account di Azure è autorizzato ad accedere. Corrisponde al set predefinito indicato nell'interfaccia utente grafica del portale, ad esempio nelle aree Panoramica e Proprietà della pagina delle risorse dell'app. Quando a un utente viene concesso l'accesso all'app tramite il controllo degli accessi in base al ruolo (RBAC) o le autorizzazioni di co-amministratore, tale utente può usare le proprie credenziali a livello di utente fino a quando non viene revocato l'accesso. Non condividere queste credenziali con altri utenti di Azure.

  • Credenziali a livello di applicazione: un insieme di credenziali per ogni applicazione. Può essere usato per distribuire solo in quella 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 ottenere l'accesso alle credenziali a livello di app tramite il controllo degli accessi in base al ruolo (RBAC), l'utente deve avere il ruolo di Collaboratore o un ruolo superiore per l'app, incluso il ruolo predefinito Collaboratore sito Web. I lettori non sono autorizzati alla pubblicazione e quindi non possono accedere a queste 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 la distribuzione dell'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. Questa operazione viene talvolta chiamata DevSecOps. L'uso di Azure DevOps per la pipeline di distribuzione consente di integrare la convalida nel processo di distribuzione. Per altre informazioni, vedere Informazioni su come aggiungere la convalida della sicurezza continua alla pipeline CI/CD.

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 sfrutta l'infrastruttura del servizio app per consentire alle funzioni di accedere alle risorse senza usare indirizzi instradabili tramite Internet o per limitare l'accesso a Internet a un 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 vengono definite regole, l'app accetterà il traffico da qualsiasi indirizzo. Per altre informazioni, vedere Restrizioni di accesso al servizio app di Azure.

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 di servizio app e Premium.

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. A tale scopo, è necessario conoscere l'indirizzo dell'endpoint privato e quindi puntare l'endpoint che si sta tentando di raggiungere a tale indirizzo usando un record A.
  • 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 Configurazione di un web application firewall (WAF) per l'ambiente del servizio app.

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