Protezione delle distribuzioni PaaS

In questo articolo vengono fornite informazioni che consentono di:

  • Comprendere i vantaggi di sicurezza dell'hosting delle applicazioni nel cloud
  • Valutare i vantaggi di sicurezza del modello di piattaforma distribuita come servizio (PaaS, Platform as a Service) rispetto ad altri modelli di servizio cloud
  • Modificare l'attenzione verso la sicurezza, da un approccio di sicurezza del perimetro incentrato sulla rete a uno incentrato sulle identità
  • Implementare le procedure consigliate per la sicurezza del modello PaaS

Sviluppare applicazioni sicure in Azure è una guida generale alle domande e ai controlli di sicurezza da considerare in ogni fase del ciclo di vita di sviluppo software durante lo sviluppo di applicazioni per il cloud.

Vantaggi della sicurezza cloud

È importante comprendere la divisione della responsabilità tra l'utente e Microsoft. In locale, si è proprietari dell'intero stack ma, con lo spostamento nel cloud, alcune responsabilità vengono trasferite a Microsoft.

Esistono vantaggi per la sicurezza nel cloud. In un ambiente locale, le organizzazioni hanno probabilmente responsabilità non soddisfatte e risorse limitate da investire nella sicurezza, dando così vita a un ambiente in cui gli utenti malintenzionati sono in grado di sfruttare le vulnerabilità a tutti i livelli.

Le organizzazioni sono in grado di migliorare il rilevamento delle minacce e i tempi di risposta usando le funzionalità di sicurezza basate sul cloud e l'intelligence sul cloud di un provider. Trasferendo le responsabilità al provider di servizi cloud, le organizzazioni possono ottenere una maggiore copertura di sicurezza, che consente di riallocare le risorse di sicurezza e il budget ad altre priorità aziendali.

Vantaggi di sicurezza di un modello di servizio cloud PaaS

Verranno ora illustrati i vantaggi di sicurezza di una distribuzione PaaS di Azure rispetto a una locale.

Security advantages of PaaS

Microsoft consente di ridurre i rischi e le responsabilità comuni già a partire dal fondo dello stack, ovvero l'infrastruttura fisica. Poiché viene costantemente monitorato da Microsoft stessa, il cloud di Microsoft è estremamente resistente agli attacchi. Per un utente malintenzionato non ha senso scegliere come obiettivo il cloud Microsoft. A meno che non disponga di parecchio denaro e parecchie risorse, un malintenzionato sceglierà più probabilmente altri obiettivi.

Al centro dello stack non c'è differenza tra una distribuzione PaaS e una locale. I rischi sono simili a livello di applicazione e a livello di gestione dell'account e degli accessi. Nella sezione dell'articolo dedicata ai passaggi successivi verranno illustrate le procedure consigliate per eliminare o ridurre al minimo tali rischi.

Nella parte superiore dello stack, governance dei dati e Rights Management, è possibile ridurre un rischio grazie alla gestione delle chiavi, La gestione delle chiavi (trattata nella sezione relativa alle procedure consigliate), è una responsabilità aggiuntiva, ma d'altro canto una distribuzione PaaS elimina la necessità di gestire alcune aree, consentendo così di dedicare le risorse alla gestione delle chiavi.

La piattaforma di Azure offre inoltre una protezione avanzata dagli attacchi DDoS grazie a varie tecnologie basate su rete. Tuttavia, tutti i tipi di protezione da attacchi DDoS basati su rete hanno vari limiti per quanto riguarda collegamenti e data center. Per evitare le problematiche legate agli attacchi DDoS di vasta portata, è possibile sfruttare un'importante funzionalità cloud di Azure, ovvero la possibilità di aumentare rapidamente e automaticamente le risorse per difendersi da questi attacchi. Negli articoli sulle procedure consigliate verranno illustrati in dettaglio i vari passaggi.

Modernizzazione della mentalità del Defender per il cloud

Le distribuzioni PaaS impongono un cambiamento dell'approccio generale verso la sicurezza. Si passa da un controllo autonomo sostanzialmente totale alla condivisione di alcune responsabilità con Microsoft.

Un'altra differenza significativa tra le distribuzioni PaaS e quelle locali tradizionali consiste in una nuova visione di ciò che compone il perimetro di sicurezza primario. In passato, il perimetro di sicurezza locale primario era rappresentato dalla rete, con la maggior parte delle progettazioni di sicurezza locali che la usava come risorsa di sicurezza primaria. Per le distribuzioni PaaS, è consigliabile passare all'identità come perimetro di sicurezza primario.

Adottare dei criteri di identità come perimetro di sicurezza primario

Una delle cinque caratteristiche essenziali del cloud computing consiste nell'ampio accesso alla rete, cosa che rende meno efficace un approccio incentrato su di essa. L'obiettivo della maggior parte del cloud computing è consentire l'accesso agli utenti a prescindere dalla loro posizione. La maggior parte di loro si troverà da qualche parte in Internet.

Nella figura seguente viene illustrata l'evoluzione del perimetro di sicurezza, da perimetro di rete a perimetro di identità. La sicurezza consiste sempre meno nel difendere la rete e sempre più nel difendere i dati e nel gestire la sicurezza di app e utenti. La differenza principale sta nel voler avvicinare il più possibile la sicurezza alle priorità dell'azienda.

Identity as new security perimeter

Inizialmente, i servizi PaaS di Azure come i ruoli Web e SQL di Azure non offrivano difese con perimetri di rete tradizionali. Questo perché si presupponeva che l'esposizione a Internet fosse proprio lo scopo del ruolo Web e che l'autenticazione fosse essa stessa il nuovo perimetro, ad esempio BLOB o Azure SQL.

Le procedure di sicurezza moderne presuppongono che un malintenzionato abbia violato il perimetro di rete. Pertanto, le procedure di difesa moderne si sono focalizzate sull'identità. Le organizzazioni devono stabilire un perimetro di sicurezza basato sull'identità con procedure consigliate di autenticazione e autorizzazione estremamente robuste.

I principi e i modelli per i perimetri di rete sono disponibili da molto tempo, tuttavia nel settore c'è meno esperienza riguardo l'uso dell'identità come perimetro di sicurezza primario. Ciò premesso, l'esperienza accumulata è comunque sufficiente per dare alcuni consigli generali la cui efficacia è comprovata sul campo, applicabili a quasi tutti i servizi PaaS.

Di seguito sono illustrate le procedure consigliate per la gestione del perimetro di identità.

Procedura consigliata: proteggere le chiavi e le credenziali per proteggere la distribuzione PaaS. Dettagli: la perdita delle chiavi e delle credenziali è un problema comune. È possibile usare una soluzione centralizzata in cui le chiavi e i segreti possono essere archiviati nei moduli di protezione hardware . Azure Key Vault protegge le chiavi e i segreti crittografando chiavi di autenticazione, chiavi dell'account di archiviazione, chiavi di crittografia dei dati, file pfx e password usando chiavi protette dai moduli di protezione hardware.

Procedura consigliata: non inserire credenziali e altri segreti nel codice sorgente o in GitHub. Dettagli: un rischio ben peggiore della perdita di chiavi e credenziali consiste negli accessi non autorizzati. Gli utenti malintenzionati possono sfruttare le tecnologie bot per trovare chiavi e segreti archiviati in repository di codice come GitHub. Si consiglia pertanto di non inserire chiavi e segreti in questi archivi di codice pubblici.

Procedura consigliata: proteggere le interfacce di gestione della macchina virtuale nei servizi ibridi PaaS e IaaS usando un'interfaccia di gestione che consenta all'utente di gestire direttamente in remoto le macchine virtuali. Dettagli: possono essere usati i protocolli di gestione remota come SSH, RDP e Comunicazione remota di PowerShell. In generale, è consigliabile non abilitare l'accesso remoto diretto alle macchine virtuali da Internet.

Se possibile, usare approcci alternativi come l'uso di reti private virtuali in una rete virtuale di Azure. Se non sono disponibili approcci alternativi, assicurarsi di usare passphrase complesse e l'autenticazione a due fattori, ad esempio l'autenticazione a più fattori di Microsoft Entra.

Procedura consigliata: usare piattaforme di autenticazione e autorizzazione robuste. Dettagli: usare le identità federate in Microsoft Entra ID anziché gli archivi utente personalizzati. Quando si usano identità federate, è possibile sfruttare un approccio basato sulla piattaforma e delegare ai partner la gestione delle identità autorizzate. Un approccio con identità federate è particolarmente importante quando i dipendenti vengono rimossi e le modifiche devono essere applicate in più sistemi di identità e autorizzazioni.

Usare i meccanismi di autenticazione e autorizzazione forniti dalla piattaforma invece di un codice personalizzato. poiché sviluppare un codice di autenticazione personalizzato può dare luogo a errori. La maggior parte degli sviluppatori non sarà esperta in sicurezza e probabilmente non conoscerà tutte le sfaccettature e gli ultimi sviluppi legati ad autenticazione e autorizzazione. Il codice commerciale, ad esempio quello di Microsoft, è spesso soggetto a rigorose analisi di sicurezza.

Usare l'autenticazione a due fattori. L'autenticazione a due fattori è lo standard attuale per l'autenticazione e l'autorizzazione, in quanto permette di evitare le lacune di sicurezza intrinseche nei tipi di autenticazione basati su nome utente e password. L'accesso alle interfacce di gestione di Azure (portale/PowerShell remoto) e ai servizi rivolti ai clienti deve essere progettato e configurato per l'uso dell'autenticazione a più fattori Di Microsoft Entra.

Usare protocolli di autenticazione standard come OAuth2 e Kerberos. Questi protocolli sono stati ampiamente analizzati e sono probabilmente implementati come parte delle librerie della piattaforma per autenticazione e autorizzazione.

Usare la modellazione delle minacce durante la progettazione delle applicazioni

Security Development Lifecycle di Microsoft specifica che i team devono sviluppare un processo denominato modellazione delle minacce durante la fase di progettazione. Per semplificare questo processo, Microsoft ha creato SDL Threat Modeling Tool. Modellando la progettazione dell'applicazione ed enumerando le minacce STRIDE in tutti i limiti di trust, sarà possibile rilevare errori di progettazione sin dall'inizio.

Nella tabella seguente sono elencate le minacce STRIDE e alcuni esempi di mitigazioni dei rischi che usano le funzionalità di Azure. Queste mitigazioni non funzioneranno in ogni situazione.

Minaccia Proprietà di sicurezza Potenziali mitigazioni della piattaforma di Azure
Spoofing Authentication Richiede connessioni HTTPS.
Manomissione Integrità Convalidare i certificati TLS/SSL.
Ripudio Non ripudio Abilitazione del monitoraggio e diagnostica di Azure.
Diffusione di informazioni Riservatezza Crittografare i dati sensibili inattivi tramite certificati di servizio.
Denial of Service Disponibilità Monitorare le metriche delle prestazioni per le potenziali condizioni di Denial of service. Implementare i filtri di connessione.
Elevazione dei privilegi Autorizzazione Usare Privileged Identity Management.

Sviluppare nel Servizio app di Azure

Servizio app di Azure è una soluzione PaaS che consente di creare applicazioni Web e per dispositivi mobili per qualsiasi piattaforma o dispositivo e di connettersi ai dati ovunque, nel cloud o in locale. Il servizio app include le funzionalità Web e per dispositivi mobili prima fornite separatamente come Siti Web di Azure e Servizi mobili di Azure. Include anche nuove funzionalità per l'automazione dei processi aziendali e l'hosting di API cloud. Il servizio app è un singolo servizio integrato che offre un set completo di funzionalità per scenari Web, per dispositivi mobili e di integrazione.

Di seguito sono illustrate le procedure consigliate per l'uso della cache locale del servizio app.

Procedura consigliata: eseguire l'autenticazione tramite Microsoft Entra ID. Dettagli: il servizio app fornisce un servizio OAuth 2.0 per il provider di identità. OAuth 2.0 è incentrato sulla semplicità di sviluppo client fornendo i flussi di autorizzazione specifici per le applicazioni Web, applicazioni desktop e telefoni cellulari. Microsoft Entra ID usa OAuth 2.0 per consentire di autorizzare l'accesso alle applicazioni per dispositivi mobili e Web.

Procedura consigliata: limitare l'accesso in base al principio di necessità e al principio dei privilegi minimi in materia di sicurezza. Dettagli: la limitazione degli accessi è fondamentale per le organizzazioni che intendono applicare criteri di sicurezza per l'accesso ai dati. È possibile usare il controllo degli accessi in base al ruolo di Azure per assegnare autorizzazioni a utenti, gruppi e applicazioni in un determinato ambito. Per altre informazioni sulla concessione agli utenti dell'accesso alle applicazioni, vedere la sezione relativa all'introduzione alla gestione degli accessi.

Procedura consigliata: proteggere le chiavi. Dettagli: Azure Key Vault consente di proteggere i segreti e le chiavi di crittografia usati da servizi e applicazioni cloud. Con Key Vault è possibile crittografare chiavi e segreti (ad esempio, chiavi di autenticazione, chiavi dell'account di archiviazione, chiavi di crittografia dati, file PFX e password) usando chiavi protette da moduli di protezione hardware (HSM). Per una maggiore sicurezza, è possibile importare o generare le chiavi in moduli di protezione hardware. Per ulteriori informazioni, vedere Azure Key Vault. È anche possibile utilizzare Azure Key Vault per gestire i certificati TLS con il rinnovo automatico.

Procedura consigliata: limitare gli indirizzi IP di origine in ingresso. Dettagli: L'ambiente del servizio app ha una funzionalità di integrazione di rete virtuale che consente di limitare gli indirizzi IP di origine in ingresso tramite gruppi di sicurezza di rete (NSG). Le reti virtuali consentono di posizionare le risorse di Azure in una rete instradabile non Internet di cui si controlla l'accesso. Per altre informazioni, vedere Integrare un'app in una rete virtuale di Azure.

Procedura consigliata: monitorare lo stato di sicurezza degli ambienti del Servizio app di Azure. Dettagli: usare Microsoft Defender per il cloud per monitorare gli ambienti di servizio app. Quando Defender per il cloud identifica potenziali vulnerabilità di sicurezza, crea raccomandazioni che guidano il processo di configurazione dei controlli necessari.

Servizi cloud di Azure

Azure Servizi cloud è un esempio di PaaS. Analogamente a Servizio app di Azure, questa tecnologia è stata progettata per supportare applicazioni scalabili, attendibili ed economicamente efficienti. Proprio come Servizio app, anche Servizi cloud di Azure è ospitato in macchine virtuali (VM). Tuttavia, il controllo sulle macchine virtuali è maggiore. È possibile installare software personalizzato nelle macchine virtuali che usano Servizi cloud di Azure e accedervi in remoto.

Installare un web application firewall

Le applicazioni Web sono sempre più vittime di attacchi che sfruttano le più comuni vulnerabilità note. Per citarne alcuni, tra i più comuni troviamo gli attacchi SQL injection e gli attacchi di scripting intersito. Impedire questo tipo di attacchi nel codice dell'applicazione può essere un'operazione complessa e potrebbe richiedere una manutenzione rigorosa, l'applicazione di patch e il monitoraggio a più livelli della topologia dell'applicazione. Un Web application firewall centralizzato semplifica notevolmente la gestione della sicurezza e offre agli amministratori delle applicazioni migliori garanzie contro le minacce o le intrusioni. Una soluzione WAF è anche in grado di reagire più velocemente a una minaccia alla sicurezza tramite l'applicazione di patch su una vulnerabilità nota in una posizione centrale, anziché proteggere ogni singola applicazione Web.

Web application firewall (WAF) offre una protezione centralizzata delle applicazioni Web da exploit e vulnerabilità comuni.

Protezione DDoS

Protezione DDoS di Azure, combinata con le procedure consigliate per la progettazione delle applicazioni, offre funzionalità avanzate di mitigazione DDoS per offrire una maggiore difesa dagli attacchi DDoS. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.

Monitorare le prestazioni delle applicazioni

Il monitoraggio comporta la raccolta e l'analisi dei dati per determinare le prestazioni, l'integrità e la disponibilità dell'applicazione. Una strategia di monitoraggio efficace aiuta a comprendere il funzionamento dettagliato dei componenti dell'applicazione. Contribuisce ad aumentare il tempo di attività tramite notifiche degli aspetti critici, in modo da poterli risolvere prima che diventino effettivi problemi. Consente inoltre di rilevare le anomalie che potrebbero essere correlate alla sicurezza.

Usare Azure Application Insights per monitorare disponibilità, prestazioni e utilizzo dell'applicazione, indipendentemente dal fatto che sia ospitata nel cloud o in locale. Con Application Insights è anche possibile identificare e diagnosticare rapidamente gli errori nell'applicazione senza attendere che vengano segnalati da un utente. Con le informazioni raccolte, è possibile prendere decisioni informate sulla manutenzione dell'applicazione e sui miglioramenti da apportare.

Application Insights include strumenti estensivi per l'interazione con i dati raccolti dal servizio stesso. Application Insights archivia questi dati in un repository comune. Può sfruttare le funzionalità condivise, ad esempio avvisi, dashboard e analisi approfondita con il linguaggio di query Kusto.

Eseguire test di penetrazione della sicurezza

La convalida delle difese di sicurezza è importante quanto il test di qualsiasi altra funzionalità. È necessario rendere i test di penetrazione parte integrante del processo di compilazione e distribuzione. Pianificare test di sicurezza e analisi delle vulnerabilità periodici sulle applicazioni distribuite, monitorando eventuali porte aperte, endpoint e attacchi.

Il test Fuzz è un metodo per trovare gli errori del programma (errori di codice) fornendo dati di input in formato non valido alle interfacce di programma (punti di ingresso) che analizzano e utilizzano questi dati.

Passaggi successivi

In questo articolo sono stati illustrati i vantaggi di sicurezza di una distribuzione PaaS di Azure e le procedure consigliate per le applicazioni cloud. Il passaggio successivo è costituito dall'approfondimento delle procedure consigliate per proteggere le soluzioni PaaS Web e mobili usando servizi di Azure specifici. Si inizierà con app Azure Service, database SQL di Azure e Azure Synapse Analytics, Archiviazione di Azure e Azure Servizi cloud. Non appena saranno disponibili le procedure consigliate per altri servizi Azure, nell'elenco seguente verranno inseriti i relativi collegamenti:

Vedere Sviluppare applicazioni sicure in Azure per domande e controlli di sicurezza da considerare in ogni fase del ciclo di vita di sviluppo software durante lo sviluppo di applicazioni per il cloud.

Per altre procedure di sicurezza consigliate da usare nella progettazione, distribuzione e gestione di soluzioni cloud tramite Azure, vedere Procedure consigliate e modelli per la sicurezza di Azure.

Le risorse seguenti offrono altre informazioni più generali sulla sicurezza di Azure e sui servizi Microsoft correlati:

  • Ciclo di vita del prodotto Microsoft: per linee guida coerenti e prevedibili per il supporto per tutta la durata di un prodotto
  • Microsoft Security Response Center: consente di segnalare le vulnerabilità della sicurezza di Microsoft, inclusi i problemi relativi ad Azure, tramite posta elettronica all'indirizzo secure@microsoft.com