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.
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 un set di raccomandazioni sulla sicurezza che seguono il benchmark della sicurezza cloud 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 avanzate di Defender per il cloud per un costo aggiuntivo. Per altre informazioni, vedere Proteggere le app Web e le API del Servizio app di Azure.
Log e monitoraggio
Un modo per rilevare gli attacchi consiste nel monitoraggio delle attività e nell'analisi della registrazione. Le funzioni si integrano con Application Insights per raccogliere dati di log, prestazioni e 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.
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 Connessioni sicure (TLS).
Chiavi di accesso alle funzioni
Funzioni consente di usare in fase di sviluppo le chiavi che rendono più difficile accedere agli endpoint di funzione HTTP. 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 all'API.
Sebbene le chiavi forniscano un meccanismo di sicurezza predefinito, è consigliabile prendere in considerazione altre opzioni per proteggere un endpoint HTTP nell'ambiente di produzione. Ad esempio, non è consigliabile distribuire il segreto condiviso nelle app pubbliche. Se la funzione viene chiamata da un client pubblico, è consigliabile prendere in considerazione l'implementazione di un altro meccanismo di sicurezza. Per altre informazioni, vedere Proteggere un endpoint HTTP nell'ambiente di produzione.
Quando si rinnovano i valori della chiave di funzione, è necessario ridistribuire manualmente i valori di chiave aggiornati a tutti i client che chiamano la funzione.
Ambiti di autorizzazione (a livello di funzione)
Sono disponibili due ambiti dell'accesso per le chiavi a livello di funzione:
Funzione: queste chiavi si applicano solo alle funzioni specifiche in cui sono definite. Quando vengono usate come chiave API, consentono l'accesso solo a tale funzione.
Host: le chiavi con un ambito host possono essere usate per accedere a tutte le funzioni all'interno dell'app per le funzioni. Quando vengono usate come chiave API, consentono l'accesso a tutte le funzioni nell'app per le funzioni.
Ogni chiave viene denominata per riferimento ed è presente una chiave predefinita (denominata "default") a livello di funzione e host. Le chiavi di funzione hanno la precedenza sulle chiavi host. Se sono definite due chiavi con lo stesso nome, viene usata sempre la chiave di funzione.
Chiave master (a livello di amministratore)
Ogni app per le funzioni dispone anche di una chiave host a livello di amministratore denominata _master. Oltre a fornire l'accesso a livello di host a tutte le funzioni nell'app, la chiave master offre anche l'accesso amministrativo alle API REST di runtime. Questa chiave non può essere revocata. Quando si imposta un livello di accesso admin, le richieste devono usare la chiave master. Qualsiasi altra chiave provoca un errore di accesso.
Attenzione
A causa delle autorizzazioni elevate nell'app per le funzioni concesse dalla chiave master, non è consigliabile condividere questa chiave con terze parti o distribuirla nelle applicazioni client native. Fare attenzione quando si sceglie il livello di accesso di amministratore.
Chiave di sistema
Le estensioni specifiche possono richiedere una chiave gestita dal sistema per accedere agli endpoint del webhook. Le chiavi di sistema sono progettate per endpoint di funzione specifici dell'estensione che vengono chiamati dai componenti interni. Ad esempio, per il trigger della Griglia di eventi è necessario che la sottoscrizione usi una chiave di sistema durante la chiamata all'endpoint del trigger. Durable Functions usa anche chiavi di sistema per chiamare le API dell'estensione Durable Task.
L'ambito delle chiavi di sistema è determinato dall'estensione, ma in genere si applica all'intera app per le funzioni. Le chiavi di sistema possono essere create solo da estensioni specifiche e non è possibile impostarne i relativi valori in modo esplicito. Analogamente ad altre chiavi, è possibile generare un nuovo valore per la chiave nel portale o usando le API della chiave.
Confronto tra le chiavi
La tabella seguente confronta gli utilizzi per diversi tipi di chiavi di accesso:
| Azione | Ambito | Tasti validi |
|---|---|---|
| Eseguire una funzione | Funzione specifica | Funzione |
| Eseguire una funzione | Qualsiasi funzione | Funzione o host |
| Chiamare un endpoint amministratore | App per le funzioni | Host (solo master) |
| Chiamare le API dell'estensione Durable Task | App per le funzioni1 | Sistema2 |
| Chiamare un webhook specifico per l'estensione (interno) | App per le funzioni1 | sistema2 |
1Ambito determinato dall'estensione.
2Nomi specifici impostati per estensione.
Per altre informazioni sulle chiavi di accesso, vedere l'articolo sull'associazione di trigger HTTP.
Repository segreti
Per impostazione predefinita, le chiavi vengono archiviate in un contenitore di archiviazione BLOB nell'account fornito dall'impostazione AzureWebJobsStorage . È possibile usare l'impostazione AzureWebJobsSecret Archiviazione Type per eseguire l'override di questo comportamento e archiviare le chiavi in un percorso diverso.
| Ufficio | Valore | Descrizione |
|---|---|---|
| Secondo account di archiviazione | blob |
Archivia le chiavi nell'archiviazione BLOB di un account di archiviazione diverso, in base all'URL della firma di accesso condiviso in AzureWebJobsSecretStorageSas. |
| File system | files |
Le chiavi vengono salvate in modo permanente nel file system, ovvero l'impostazione predefinita in Funzioni v1.x. |
| Insieme di credenziali chiave di Azure | keyvault |
L'insieme di credenziali delle chiavi impostato in AzureWebJobsSecretStorageKeyVaultUri viene usato per archiviare le chiavi. |
| Segreti di Kubernetes | kubernetes |
Il set di risorse in AzureWebJobsKubernetesSecretName viene usato per archiviare le chiavi. Supportato solo quando si esegue il runtime di Funzioni in Kubernetes. Azure Functions Core Tools genera automaticamente i valori durante la distribuzione in Kubernetes. |
Quando si usa Key Vault per l'archiviazione delle chiavi, le impostazioni dell'app necessarie dipendono dal tipo di identità gestita. Il runtime di Funzioni versione 3.x supporta solo le identità gestite assegnate dal sistema.
| Nome impostazione | Assegnata dal sistema | Assegnata dall'utente | Registrazione app |
|---|---|---|---|
| AzureWebJobsSecret Archiviazione KeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecret Archiviazione KeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecret Archiviazione KeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecret Archiviazione KeyVaultTenantId | X | X | ✓ |
Autenticazione/autorizzazione
Anche se le chiavi della funzione 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à.
Abilitare l'autenticazione/autorizzazione di Servizio app di Azure
La piattaforma servizio app consente di usare Microsoft Entra ID e diversi provider di identità di terze parti 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
APIM offre un'ampia gamma di 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 predefinito. I ruoli di Azure supportati dalle 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 di Microsoft Entra, ad esempio 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.
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 è tentata l'uso di un carattere jolly che consente a tutti i siti di accedere all'endpoint, questo sconfigge lo scopo di CORS, che è quello di impedire 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 applicazione
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 invece si preferisce gestire l'archiviazione protetta dei segreti, l'impostazione dell'app deve fare riferimento ad 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à
Le identità possono essere usate al posto dei segreti per la connessione ad alcune risorse. Ciò ha il vantaggio di non richiedere la gestione di un segreto e offre un controllo e un controllo di accesso più granulari.
Quando si scrive codice che crea la connessione ai servizi di Azure che supportano l'autenticazione di Microsoft Entra, è possibile scegliere di usare un'identità anziché un segreto o un stringa di connessione. I dettagli per entrambi i metodi di connessione sono descritti nella documentazione per ogni servizio.
Alcune estensioni di trigger e binding Funzioni di Azure possono essere configurate usando una connessione basata su identità. Attualmente, sono incluse le estensioni BLOB di Azure e Code di Azure. Per informazioni su come configurare queste estensioni per l'uso di un'identità, vedere Come usare connessioni basate su identità in Funzioni di Azure.
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 la somma dell'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.
Proteggere le risorse correlate
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 La baseline di sicurezza di Azure per Monitoraggio di Azure e la baseline di sicurezza di Azure per 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 associazioni 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 passaggio del processo di sviluppo, è opportuno implementare anche le convalide di 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 di 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 è stata definita alcuna regola, l'app accetterà il traffico da qualsiasi indirizzo. Per altre informazioni, vedere app Azure Restrizioni di accesso al servizio.
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 con endpoint di servizio o endpoint privati. Per altre informazioni, vedere Limitare l'account di archiviazione a una rete virtuale.
Accesso al sito privato
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 Premium e servizio app.
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. L'ASE consente 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.