Accesso di rete sicuro per le app per le funzioni

Una Function App con l'autenticazione configurata controlla chi può chiamarla, ma l'endpoint della funzione è comunque raggiungibile da qualsiasi percorso di rete, inclusa Internet pubblica. I controlli di rete aggiungono un livello di imposizione separato: limitare i percorsi di rete che possono raggiungere la funzione e controllare i percorsi di rete usati dalla funzione per le proprie chiamate in uscita. L'autenticazione e l'isolamento della rete sono indipendenti e complementari. Entrambi devono essere presenti per una postura di sicurezza difendibile.

Limitare l'accesso in ingresso con elenchi di indirizzi IP consentiti

Le restrizioni di accesso consentono di definire un elenco ordinato con priorità di regole di autorizzazione e negazione in base all'indirizzo IP di origine, all'intervallo CIDR (Classless Inter-Domain Route) o Azure tag del servizio. Quando esiste una regola esplicita, un rifiuto implicito si applica a tutto il traffico che non corrisponde, non è necessario aggiungere manualmente una regola di negazione.

Per le app per le funzioni che devono accettare solo chiamate in ingresso da servizi di Azure specifici, le regole dei tag di servizio forniscono una soluzione pulita. Ad esempio, per accettare chiamate webhook solo da Griglia di eventi di Azure, aggiungere una regola che consenta il tag del servizio AzureEventGrid e negare tutto il traffico. Il tag del servizio copre l'intera gamma di indirizzi IP usati da tale servizio Azure, pertanto non è necessario gestire singoli intervalli IP per i servizi che usano pool di indirizzi dinamici.

Le restrizioni di accesso sono disponibili in tutti i piani di hosting delle app per le funzioni, tra cui Consumo, Consumo flessibile, Elastic Premium e Dedicato.

Distribuire un endpoint privato per l'accesso in ingresso

Se il traffico di un'app per funzioni non deve mai transitare su Internet pubblico, un endpoint privato rimuove completamente l'endpoint pubblico. Un endpoint privato assegna all'app per le funzioni un indirizzo IP privato all'interno della rete virtuale (rete virtuale). Tutto il traffico in ingresso arriva attraverso l'INDIRIZZO IP privato. I chiamanti esterni non riescono a raggiungere l'URL della funzione da Internet perché non esiste alcuna route pubblica.

Gli endpoint privati per le app per le funzioni sono supportati nei piani di hosting Flex Consumption, Elastic Premium e Dedicated (App Service). Il piano di consumo standard non supporta gli endpoint privati.

Una volta configurato un endpoint privato, i chiamanti all'interno della rete virtuale (VNet) — compresi gli altri servizi Azure connessi alla stessa rete — risolvono il nome host della funzione nell'indirizzo IP privato. Questa risoluzione dei nomi richiede zone private di DNS di Azure. Se la funzione funge da back-end per Gestione API di Azure o per un Application Gateway, tali risorse si connettono all'app per le funzioni tramite l'endpoint privato invece che tramite un URL pubblico, mantenendo tutto il traffico sulla rete backbone di Azure.

Configurare l'integrazione della rete virtuale per il traffico in uscita

Gli endpoint privati controllano l'accesso in entrata, ovvero ciò che può raggiungere l'app Function. L'integrazione della rete virtuale controlla l'accesso in uscita, ovvero ciò che l'app per le funzioni può raggiungere. Si tratta di controlli distinti e servono scopi diversi.

Con l'integrazione della rete virtuale abilitata, l'app per le funzioni instrada le chiamate di rete in uscita tramite una subnet delegata nella rete virtuale. Ciò consente alla funzione di chiamare le risorse che non sono esposte a Internet pubblico: un account Cosmos DB senza accesso pubblico, un account di archiviazione bloccato a subnet di rete virtuali specifiche o un'API REST privata ospitata in una macchina virtuale nella stessa rete.

L'integrazione della rete virtuale a livello di area è disponibile nei piani Flex Consumption, Elastic Premium e Dedicated ed è la configurazione consigliata per la maggior parte degli scenari. L'app per le funzioni e la rete virtuale devono trovarsi nella stessa area Azure. L'integrazione usa una subnet delegata, che non può essere usata per altre risorse, ad esempio macchine virtuali o endpoint privati.

Configurare CORS per i client basati su browser

La condivisione delle risorse tra origini diverse (CORS) si applica quando applicazioni Web eseguite nel browser chiamano direttamente app per le funzioni attivate tramite HTTP. Per impostazione predefinita, i browser bloccano le richieste tra le origini. Funzioni di Azure consente di configurare le origini consentite per effettuare tali richieste.

Nell'ambiente di produzione, specificare le origini consentite esplicite, ad esempio https://contoso-retail.com. Non utilizzare mai il carattere jolly (*) in ambiente di produzione. Una configurazione CORS con caratteri jolly consente a qualsiasi origine di inviare richieste alla tua Function App, eliminando così la protezione cross-origin che CORS garantisce ai client basati su browser.

Le restrizioni CORS si applicano solo ai client HTTP basati su browser. Le chiamate da server a server, dai servizi back-end, dai servizi Azure o dai client HTTP nonbrowser, non sono soggette all'imposizione di CORS. CORS è un meccanismo di sicurezza del browser, non un controllo di accesso lato server.

Fare riferimento ai segreti di Key Vault nelle impostazioni dell'applicazione

Le impostazioni dell'applicazione in Funzioni di Azure sono una delle posizioni più comuni in cui le stringhe di connessione e le chiavi API vengono archiviate in testo normale. Il modello di riferimento di Key Vault sostituisce un valore in testo normale di un'impostazione dell'applicazione con un riferimento che l'app per le funzioni risolve in fase di esecuzione tramite la propria identità gestita.

La sintassi per un riferimento Key Vault in un'impostazione dell'applicazione è:

@Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>/<version>)

Se si omette l'identificatore di versione, l'app per le funzioni risolve la versione più recente del segreto. Questo è utile per i segreti che ruotano regolarmente: la funzione recupera il valore aggiornato entro 24 ore dalla rotazione, senza dover effettuare una nuova distribuzione.

Per usare i riferimenti Key Vault:

1. Abilitare un'identità gestita assegnata dal sistema nell'app per le funzioni.
2. Assegnare il ruolo Utente dei segreti di Key Vault all'identità gestita su Key Vault.
3. Sostituire il valore di testo normale in ogni impostazione dell'applicazione con la sintassi di riferimento @Microsoft.KeyVault(...).

L'app Function risolve il riferimento all'avvio e inserisce il valore segreto come impostazione dell'applicazione. Il codice della funzione legge l'impostazione usando Environment.GetEnvironmentVariable("SETTING_NAME"): la stessa chiamata usata per qualsiasi altra impostazione dell'applicazione, senza conoscere il livello di riferimento Key Vault.