Progettare applicazioni sicure in Azure

In questo articolo vengono presentati i controlli e le attività di sicurezza da prendere in considerazione quando si progettano applicazioni per il cloud. Vengono trattate le risorse di training insieme a domande e concetti di sicurezza da considerare durante le fasi di progettazione e requisiti del Ciclo di vita dello sviluppo della sicurezza Microsoft. L'obiettivo è consentire di definire le attività e i servizi di Azure che è possibile usare per progettare un'applicazione più protetta.

Questo articolo tratta le fasi di SDL seguenti:

• Formazione
• Requisiti
• Progettazione

Formazione

Prima di iniziare a sviluppare l'applicazione cloud, dedicare tempo per comprendere la sicurezza e la privacy in Azure. Eseguendo questo passaggio, è possibile ridurre il numero e la gravità delle vulnerabilità sfruttabili nell'applicazione. Sarete più preparati a reagire in modo appropriato al panorama delle minacce in continua evoluzione.

Usare le risorse seguenti durante la fase di training per acquisire familiarità con i servizi di Azure disponibili per gli sviluppatori e con le procedure consigliate per la sicurezza in Azure:

• Guida per gli sviluppatori ad Azure illustra come iniziare a usare Azure. La guida illustra i servizi che è possibile usare per eseguire le applicazioni, archiviare i dati, incorporare intelligenza, compilare app IoT e distribuire le soluzioni in modo più efficiente e sicuro.

• Guida introduttiva per gli sviluppatori di Azure fornisce informazioni essenziali per gli sviluppatori che vogliono iniziare a usare la piattaforma Azure per le proprie esigenze di sviluppo.

• SDK e strumenti descrive gli strumenti disponibili in Azure.

• Azure DevOps Services offre strumenti di collaborazione per lo sviluppo. Gli strumenti includono pipeline ad alte prestazioni, repository Git gratuiti, schede Kanban configurabili e test di carico automatizzati e basati sul cloud completi. DevOps Resource Center combina le risorse per apprendere le procedure DevOps, il controllo della versione Git, i metodi agile, il funzionamento di DevOps in Microsoft e il modo in cui è possibile valutare la propria progressione devOps.

• I primi cinque elementi di sicurezza da considerare prima del push nell'ambiente di produzione illustra come proteggere le applicazioni Web in Azure e proteggere le app dagli attacchi più comuni e pericolosi alle applicazioni Web.

• Secure DevOps Kit per Azure è una raccolta di script, strumenti, estensioni e automazione che soddisfano le esigenze complete di sottoscrizione di Azure e sicurezza delle risorse dei team DevOps che usano un'automazione completa. Secure DevOps Kit per Azure può mostrare come integrare senza problemi la sicurezza nei flussi di lavoro DevOps nativi. Il kit si rivolge a strumenti come i test di verifica della sicurezza (SVT), che consentono agli sviluppatori di scrivere codice sicuro e testare la configurazione sicura delle applicazioni cloud nelle fasi di codifica e sviluppo iniziali.

• Procedure consigliate e modelli di sicurezza di Azure: una raccolta di procedure consigliate per la sicurezza da usare quando si progettano, distribuiscono e gestiscono soluzioni cloud usando Azure. Le linee guida sono destinate a essere una risorsa per professionisti IT. Potrebbe trattarsi di designer, architetti, sviluppatori e tester che creano e distribuiscono soluzioni sicure per Azure.

Requisiti

La fase di definizione dei requisiti è un passaggio fondamentale per definire le operazioni dell'applicazione e le relative operazioni al rilascio. La fase dei requisiti è anche il momento di considerare i controlli di sicurezza compilati nell'applicazione. Durante questa fase si iniziano anche i passaggi da eseguire in SDL per assicurarsi di rilasciare e distribuire un'applicazione sicura.

Prendere in considerazione i problemi di sicurezza e privacy

Questa fase è il momento migliore per considerare problemi fondamentali di sicurezza e privacy. La definizione di livelli accettabili di sicurezza e privacy all'inizio di un progetto aiuta un team:

• Comprendere i rischi associati ai problemi di sicurezza.
• Identificare e correggere i bug di sicurezza durante lo sviluppo.
• Applicare livelli stabiliti di sicurezza e privacy nell'intero progetto.

Quando si scrivono i requisiti per l'applicazione, assicurarsi di prendere in considerazione i controlli di sicurezza che consentono di proteggere l'applicazione e i dati.

Porre domande di sicurezza

Porre domande di sicurezza come:

• L'applicazione contiene dati sensibili?

• L'applicazione raccoglie o archivia i dati che richiedono di rispettare gli standard e i programmi di conformità del settore, ad esempio il Federal Financial Institution Examination Council (FFIEC) o gli Standard di sicurezza dei dati del settore delle carte di pagamento (PCI DSS)?

• L'applicazione raccoglie o contiene dati personali o dei clienti sensibili che è possibile usare, autonomamente o con altre informazioni, per identificare, contattare o individuare una singola persona?

• L'applicazione raccoglie o contiene dati che è possibile usare per accedere alle informazioni mediche, educative, finanziarie o lavorative di un individuo? L'identificazione della riservatezza dei dati durante la fase dei requisiti consente di classificare i dati e identificare il metodo di protezione dei dati usato per l'applicazione.

• Dove e come vengono archiviati i dati? Si consideri come monitorare i servizi di archiviazione usati dall'applicazione per eventuali modifiche impreviste, ad esempio tempi di risposta più lenti. È possibile influenzare la registrazione per raccogliere dati più dettagliati e analizzare un problema in modo approfondito?

• L'applicazione è disponibile per il pubblico (su Internet) o solo internamente? Se l'applicazione è disponibile per il pubblico, come si proteggono i dati che potrebbero essere raccolti in modo errato? Se l'applicazione è disponibile solo internamente, prendere in considerazione chi nell'organizzazione dovrebbe avere accesso all'applicazione e per quanto tempo dovrebbe avere accesso.

• Prima di iniziare a progettare l'applicazione, è necessario comprendere il modello di identità? È possibile determinare che gli utenti sono quelli che dicono di essere e che cosa un utente è autorizzato a eseguire?

• L'applicazione esegue attività sensibili o importanti (ad esempio il trasferimento di denaro, lo sblocco di porte o la consegna di medicinali)? Si consideri il modo in cui si convalida che l'utente che esegue un'attività sensibile sia autorizzato a eseguire l'attività e a come si autentica che la persona sia la persona che dichiara di essere. Per Autorizzazione (AuthZ) si intende la concessione a un'entità di sicurezza autenticata dell'autorizzazione a eseguire determinate operazioni. L'autenticazione (AuthN) è l'atto di sfidare una parte per le credenziali legittime.

• L'applicazione esegue attività software rischiose, ad esempio consentendo agli utenti di caricare o scaricare file o altri dati? Se l'applicazione esegue attività rischiose, valutare il modo in cui l'applicazione protegge gli utenti dalla gestione di file o dati dannosi.

Esaminare OWASP top 10

Valutare la possibilità di esaminare i Primi 10 rischi per la sicurezza delle applicazioni OWASP. OWASP Top 10 risolve i rischi critici per la sicurezza delle applicazioni Web. La consapevolezza di questi rischi per la sicurezza può aiutare a prendere decisioni relative ai requisiti e alla progettazione che riducono al minimo questi rischi nell'applicazione.

È importante considerare i controlli di sicurezza per prevenire le violazioni. Tuttavia, si desidera anche presupporre che si verifichi una violazione. Supponendo che una violazione consenta di rispondere ad alcune domande importanti sulla sicurezza in anticipo, quindi non devono essere risposte in caso di emergenza:

• Come rileverò un attacco?
• Cosa faccio se c'è un attacco o una violazione?
• Come posso recuperare dall'attacco come la perdita o la manomissione dei dati?

Progettazione

La fase di progettazione è fondamentale per stabilire le procedure consigliate per la progettazione e le specifiche funzionali. È anche fondamentale per eseguire l'analisi dei rischi che consente di attenuare i problemi di sicurezza e privacy in un progetto.

Quando si hanno requisiti di sicurezza e si usano concetti di progettazione sicuri, è possibile evitare o ridurre al minimo le opportunità di un difetto di sicurezza. Un difetto di sicurezza è una supervisione nella progettazione dell'applicazione che potrebbe consentire a un utente di eseguire azioni dannose o impreviste dopo il rilascio dell'applicazione.

Durante la fase di progettazione, considerare anche come applicare la sicurezza nei livelli; un livello di difesa non è necessariamente sufficiente. Cosa accade se un utente malintenzionato supera il web application firewall (WAF)? Si desidera che un altro controllo di sicurezza si difenda da tale attacco.

Tenendo presente questo aspetto, vengono illustrati i concetti di progettazione sicuri seguenti e i controlli di sicurezza da affrontare quando si progettano applicazioni sicure:

• Usare una libreria di codifica sicura e un framework software.
• Cercare componenti vulnerabili.
• Usare la modellazione delle minacce durante la progettazione delle applicazioni.
• Ridurre la superficie di attacco.
• Adottare dei criteri di identità come perimetro di sicurezza primario.
• Richiedere la riautenticazione per transazioni importanti.
• Usare una soluzione di gestione delle chiavi per proteggere chiavi, credenziali e altri segreti.
• Proteggere i dati sensibili.
• Implementare misure sicure per gli errori.
• Sfruttare i vantaggi della gestione degli errori e delle eccezioni.
• Usare la registrazione e gli avvisi.

Usare una libreria di codifica sicura e un framework software

Per lo sviluppo, usare una libreria di codifica sicura e un framework software con sicurezza incorporata. Gli sviluppatori possono usare funzionalità esistenti e comprovate (crittografia, servizi igienico-sanitari di input, codifica di output, chiavi o stringhe di connessione e qualsiasi altro elemento che verrebbe considerato un controllo di sicurezza) anziché sviluppare controlli di sicurezza da zero. In questo modo è possibile proteggersi dai difetti di progettazione e implementazione correlati alla sicurezza.

Assicurarsi di usare la versione più recente del framework e tutte le funzionalità di sicurezza disponibili nel framework. Microsoft offre un set completo di strumenti di sviluppo per tutti gli sviluppatori, che lavorano su qualsiasi piattaforma o linguaggio, per distribuire applicazioni cloud. È possibile scrivere codice con il linguaggio preferito scegliendo tra vari SDK. È possibile sfruttare gli ambienti di sviluppo integrato completi (IDE) e gli editor con funzionalità di debug avanzate e supporto predefinito di Azure.

Microsoft offre diversi linguaggi, framework e strumenti che è possibile usare per sviluppare applicazioni in Azure. Un esempio è Azure per sviluppatori .NET e .NET Core. Per ogni linguaggio e framework offerto, è possibile trovare avvii rapidi, esercitazioni e informazioni di riferimento sulle API per iniziare rapidamente.

Azure offre vari servizi che è possibile usare per ospitare siti Web e applicazioni Web. Questi servizi consentono di sviluppare nel linguaggio preferito, ad esempio .NET, .NET Core, Java, Ruby, Node.js, PHP o Python. App Web del Servizio app di Azure (App Web) è uno di questi servizi.

App Web aggiunge la potenza di Microsoft Azure all'applicazione. Include sicurezza, bilanciamento del carico, scalabilità automatica e gestione automatizzata. È anche possibile sfruttare le capacità DevOps in App Web, come ad esempio la gestione dei pacchetti, gli ambienti di staging, i domini personalizzati, i certificati SSL/TSL e la distribuzione continua da Azure DevOps, GitHub, Docker Hub e altre fonti.

Azure offre altri servizi che è possibile usare per ospitare siti Web e applicazioni Web. Per la maggior parte degli scenari App Web è la scelta migliore. Per un'architettura di microservizi, prendere in considerazione Azure Service Fabric. Se è necessario un maggiore controllo sulle VM in cui viene eseguito il codice, prendere in considerazione l'uso delle Macchine virtuali di Azure. Per altre informazioni su come scegliere uno di questi servizi di Azure, vedere Confronto tra Servizio app di Azure, Macchine virtuali, Service Fabric e Servizi cloud.

Applicare gli aggiornamenti ai componenti

Per evitare vulnerabilità, è consigliabile eseguire continuamente l'inventario dei componenti lato client e lato server (ad esempio framework e librerie) e le relative dipendenze per gli aggiornamenti. Le nuove vulnerabilità e le versioni software aggiornate vengono rilasciate continuamente. Assicurarsi di avere un piano in corso per monitorare, valutare e applicare aggiornamenti o modifiche di configurazione alle librerie e ai componenti usati.

Vedere la pagina Apri progetto di sicurezza delle applicazioni Web (OWASP) sull'uso di componenti con vulnerabilità note per i suggerimenti degli strumenti. È anche possibile sottoscrivere avvisi e-mail per le vulnerabilità di sicurezza correlate ai componenti usati.

Usare la modellazione delle minacce durante la progettazione delle applicazioni

La modellazione delle minacce è il processo di identificazione di potenziali minacce alla sicurezza per l'azienda e l'applicazione e quindi di garantire che siano presenti mitigazioni appropriate. SDL specifica che i team devono impegnarsi nella modellazione delle minacce durante la fase di progettazione, quando si risolve potenziali problemi è relativamente semplice e conveniente. L'uso della modellazione delle minacce nella fase di progettazione può ridurre notevolmente il costo totale dello sviluppo.

Per facilitare il processo di modellazione delle minacce, abbiamo progettato SDL Threat Modeling Tool tenendo presenti esperti di non sicurezza. Questo strumento semplifica la modellazione delle minacce per tutti gli sviluppatori fornendo indicazioni chiare su come creare e analizzare modelli di minaccia.

La modellazione della progettazione dell'applicazione e l'enumerazione di minacce STRIDE-Spoofing, manomissioni, ripudi, divulgazioni di informazioni, denial of service e l'elevazione dei privilegi in tutti i limiti di attendibilità hanno dimostrato un modo efficace per rilevare gli errori di progettazione in anticipo. Nella tabella seguente sono elencate le minacce STRIDE e alcuni esempi di mitigazioni dei rischi che usano le funzionalità fornite da Azure. Queste mitigazioni dei rischi non funzionano in tutte le situazioni.

Ridurre la superficie di attacco

Una superficie di attacco è la somma totale della posizione in cui possono verificarsi potenziali vulnerabilità. In questo documento ci concentriamo sulla superficie di attacco di un'applicazione. L'attenzione è la protezione di un'applicazione dall'attacco. Un modo semplice e rapido per ridurre al minimo la superficie di attacco consiste nel rimuovere le risorse inutilizzate e il codice dall'applicazione. Più piccola è la superficie di attacco più piccola. Ad esempio, rimuovere:

• Codice per le funzionalità non ancora rilasciate.
• Codice di supporto per il debug.
• Interfacce di rete e protocolli non usati o deprecati.
• Macchine virtuali e altre risorse che non si usano.

L'esecuzione di una pulizia regolare delle risorse e la necessità di rimuovere il codice inutilizzato sono ottimi modi per garantire un minor numero di opportunità per gli attori malintenzionati da attaccare.

Un modo più dettagliato e approfondito per ridurre la superficie di attacco consiste nel completare un'analisi della superficie di attacco. Un'analisi della superficie di attacco consente di eseguire il mapping delle parti di un sistema che devono essere esaminate e testate per individuare le vulnerabilità di sicurezza.

Lo scopo di un'analisi della superficie di attacco è comprendere le aree di rischio in un'applicazione in modo che gli sviluppatori e gli specialisti della sicurezza siano consapevoli delle parti dell'applicazione aperte agli attacchi. È quindi possibile trovare modi per ridurre al minimo questo potenziale, tenere traccia di quando e come cambia la superficie di attacco e cosa significa da una prospettiva di rischio.

Un'analisi della superficie di attacco consente di identificare:

• Funzioni e parti del sistema che è necessario esaminare e testare le vulnerabilità di sicurezza.
• Aree ad alto rischio di codice che richiedono una protezione avanzata dalla difesa (parti del sistema che è necessario difendere).
• Quando si modifica la superficie di attacco ed è necessario aggiornare una valutazione delle minacce.

Per ridurre le opportunità per gli utenti malintenzionati di sfruttare un potenziale punto debole o una vulnerabilità, è necessario analizzare accuratamente la superficie di attacco complessiva dell'applicazione. Include anche la disabilitazione o la limitazione dell'accesso ai servizi di sistema, l'applicazione del principio dei privilegi minimi e l'uso di difese a più livelli laddove possibile.

Durante la fase di verifica di SDL viene esaminata una superficie di attacco.

Adottare dei criteri di identità come perimetro di sicurezza primario

Quando si progettano applicazioni cloud, è importante espandere lo stato attivo del perimetro di sicurezza da un approccio incentrato sulla rete a un approccio incentrato sulle identità. Storicamente, il perimetro di sicurezza locale principale era la rete di un'organizzazione. La maggior parte delle progettazioni di sicurezza locali usa la rete come pivot di sicurezza principale. Per le applicazioni cloud, è preferibile considerare l'identità come perimetro di sicurezza primario.

È possibile eseguire operazioni per sviluppare un approccio incentrato sulle identità per lo sviluppo di applicazioni Web:

• Imporre l'autenticazione a più fattori per gli utenti.
• usare piattaforme di autenticazione e autorizzazione avanzate.
• Applicare il principio dei privilegi minimi.
• Implementare l'accesso just-in-time.

Imporre l'autenticazione a più fattori per gli utenti

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 di Azure/PowerShell remoto) e ai servizi per i clienti dovrebbe essere progettato e configurato per l'uso di Autenticazione a più fattori di Microsoft Entra.

Usare piattaforme di autenticazione e autorizzazione robuste

Usare i meccanismi di autenticazione e autorizzazione forniti dalla piattaforma invece di un codice personalizzato. Ciò è dovuto al fatto che lo sviluppo di codice di autenticazione personalizzato può essere soggetto a errori. Il codice commerciale (ad esempio, da Microsoft) viene spesso esaminato in modo approfondito per la sicurezza. Microsoft Entra ID (Microsoft Entra ID) è la soluzione Azure per la gestione delle identità e degli accessi. Questi strumenti e servizi Microsoft Entra consentono di sviluppare in modo sicuro:

• Microsoft Identity Platform è un set di componenti usati dagli sviluppatori per creare app che consentono di accedere in modo sicuro agli utenti. La piattaforma aiuta gli sviluppatori che creano app line-of-business (LOB) a tenant singolo e sviluppatori che vogliono sviluppare app multi-tenant. Oltre all'accesso di base, le app create con Microsoft Identity Platform possono chiamare API Microsoft e API personalizzate. Microsoft Identity Platform supporta protocolli standard di settore come OAuth 2.0 e OpenID Connect.

• Azure Active Directory B2C (Azure AD B2C) è un servizio di gestione delle identità che consente di personalizzare e controllare il modo in cui i clienti si iscrivono, accedono e gestiscono i rispettivi profili quando usano le applicazioni. Include ad esempio le applicazioni sviluppate per iOS, Android e .NET. Azure AD B2C abilita queste azioni proteggendo al contempo le identità dei clienti.

Usare il principio dei privilegi minimi

Il concetto di privilegio minimo significa offrire agli utenti il livello preciso di accesso e controllo di cui hanno bisogno per svolgere il proprio lavoro e niente di più.

Uno sviluppatore di software necessita dei diritti di amministratore di dominio? Un assistente amministrativo deve accedere ai controlli amministrativi sul proprio personal computer? La valutazione dell'accesso al software non è diversa. Se si usa il controllo degli accessi in base al ruolo di Azure (Azure RBAC) per offrire agli utenti capacità e autorità diverse nell'applicazione, non si concede a tutti gli utenti l'accesso a tutti gli elementi. Limitando l'accesso a ciò che è necessario per ogni ruolo, è possibile limitare il rischio che si verifichi un problema di sicurezza.

Assicurarsi che l'applicazione applichi privilegi minimi in tutti i modelli di accesso.

Implementare l'accesso JUST-In-Time

Implementare l'accesso Just-In-Time (JIT) per ridurre ulteriormente il tempo di esposizione dei privilegi. Usare Microsoft Entra Privileged Identity Management per:

• Concedere agli utenti le autorizzazioni necessarie solo JIT.
• Assegnare i ruoli per un periodo di tempo ridotto sapendo che i privilegi vengono revocati automaticamente.

Richiedere la riautenticazione per transazioni importanti

La richiesta intersito falsa (nota anche come XSRF o CSRF) è un attacco contro le app ospitate sul Web in cui un'app Web dannosa influenza l'interazione tra un browser client e un'app Web che considera attendibile tale browser. Gli attacchi di richiesta intersito falsi sono possibili perché i Web browser inviano automaticamente alcuni tipi di token di autenticazione con ogni richiesta a un sito Web. Questa forma di sfruttamento è nota anche come attacco con un clic o guida di sessione perché l'attacco sfrutta la sessione autenticata in precedenza dell'utente.

Il modo migliore per difendersi da questo tipo di attacco consiste nel chiedere all'utente qualcosa che solo l'utente può fornire prima di ogni transazione importante, ad esempio un acquisto, una disattivazione dell'account o una modifica della password. È possibile chiedere all'utente di immettere nuovamente la password, completare un captcha o inviare un token segreto che solo l'utente avrebbe. L'approccio più comune è il token segreto.

Usare una soluzione di gestione delle chiavi per proteggere chiavi, credenziali e altri segreti

Perdere chiavi e credenziali è un problema comune. un rischio ben peggiore della perdita di chiavi e credenziali consiste negli accessi non autorizzati. Gli utenti malintenzionati possono sfruttare tecniche automatizzate e manuali per trovare chiavi e segreti archiviati in repository di codice come GitHub. Non inserire chiavi e segreti in questi repository di codice pubblico o in qualsiasi altro server.

Inserire sempre chiavi, certificati, segreti e stringhe di connessione in una soluzione di gestione delle chiavi. È possibile usare una soluzione centralizzata in cui le chiavi e i segreti sono archiviati in moduli di protezione hardware (HSM). Azure offre un modulo di protezione hardware nel cloud con Azure Key Vault.

Key Vault è un archivio di segreti: è un servizio cloud centralizzato per l'archiviazione dei segreti dell'applicazione. Key Vault mantiene i dati riservati al sicuro mantenendo i segreti dell'applicazione in un'unica posizione centrale e fornendo accesso sicuro, controllo delle autorizzazioni e registrazione degli accessi.

I segreti vengono archiviati in singoli insiemi di credenziali. Ogni insieme di credenziali ha i propri criteri di configurazione e sicurezza per controllare l'accesso. È possibile accedere ai dati tramite un'API REST o tramite un SDK client disponibile per la maggior parte dei linguaggi di programmazione.

Proteggere i dati sensibili

La protezione dei dati è una parte essenziale della strategia di sicurezza. La classificazione dei dati e l'identificazione delle esigenze di protezione dei dati consente di progettare l'app tenendo conto della sicurezza dei dati. La classificazione (categorizzazione) dei dati archiviati in base alla riservatezza e all'impatto aziendale consente agli sviluppatori di determinare i rischi associati ai dati.

Etichettare tutti i dati applicabili come sensibili quando si progettano i formati di dati. Assicurarsi che l'applicazione consideri i dati applicabili come sensibili. Queste procedure consentono di proteggere i dati sensibili:

• Usare la crittografia.
• Evitare segreti hardcoded come chiavi e password.
• Assicurarsi che siano presenti controlli di accesso e audit.

Usare la crittografia

La protezione dei dati dovrebbe essere una parte essenziale della strategia di sicurezza. Se i dati vengono archiviati in un database o se si spostano avanti e indietro tra posizioni, usare la crittografia dei dati inattivi (mentre nel database) e la crittografia dei dati in transito (in transito da e verso l'utente, il database, un'API o un endpoint di servizio). È consigliabile usare sempre protocolli SSL/TLS per scambiare dati. Assicurarsi di usare la versione più recente di TLS per la crittografia (attualmente questa è la versione 1.2).

Evitare il hardcoded

Alcune cose non dovrebbero mai essere hardcoded nel software. Alcuni esempi sono nomi host o indirizzi IP, URL, indirizzi e-mail, nomi utente, password, chiavi dell'account di archiviazione e altre chiavi crittografiche. Prendere in considerazione l'implementazione dei requisiti relativi a ciò che può o non può essere hardcoded nel codice, incluse le sezioni di commento del codice.

Quando si inseriscono commenti nel codice, assicurarsi di non salvare informazioni riservate. Sono inclusi l'indirizzo e-mail, le password, le stringhe di connessione, le informazioni sull'applicazione che sarebbero note solo da un utente dell'organizzazione e qualsiasi altro elemento che potrebbe offrire a un utente malintenzionato un vantaggio nell'attaccare l'applicazione o l'organizzazione.

In pratica, si supponga che tutto il contenuto del progetto di sviluppo sia una conoscenza pubblica quando viene distribuito. Evitare di includere dati sensibili di qualsiasi tipo nel progetto.

In precedenza è stato illustrato Azure Key Vault. È possibile usare Key Vault per archiviare segreti come chiavi e password anziché hardcoded. Quando si usa Key Vault in combinazione con le identità gestite per le risorse di Azure, l'app Web di Azure può accedere ai valori di configurazione dei segreti in modo semplice e sicuro senza archiviare segreti nel controllo del codice sorgente o nella configurazione. Per altre informazioni, vedere Gestire i segreti nelle app server con Azure Key Vault.

Implementare misure sicure per gli errori

L'applicazione deve essere in grado di gestire gli errori che si verificano durante l'esecuzione in modo coerente. L'applicazione dovrebbe intercettare tutti gli errori e non riuscire o chiudere.

È anche necessario assicurarsi che gli errori vengano registrati con un contesto utente sufficiente per identificare attività sospette o dannose. I log devono essere conservati per un tempo sufficiente per consentire l'analisi forense ritardata. I log devono essere in un formato facilmente utilizzato da una soluzione di gestione dei log. Assicurarsi che vengano attivati avvisi relativi agli errori relativi alla sicurezza. La registrazione e il monitoraggio insufficienti consentono agli utenti malintenzionati di continuare a gestire i sistemi di attacco e mantenere la persistenza.

Sfruttare i vantaggi della gestione degli errori e delle eccezioni

L'implementazione di una gestione corretta degli errori e delle eccezioni è una parte importante della codifica difensiva. La gestione degli errori e delle eccezioni è fondamentale per rendere un sistema affidabile e sicuro. Gli errori nella gestione degli errori possono causare diversi tipi di vulnerabilità di sicurezza, ad esempio la perdita di informazioni agli utenti malintenzionati e l'aiuto degli utenti malintenzionati a comprendere meglio la piattaforma e la progettazione.

Assicurarsi che:

• Le eccezioni vengono gestite in modo centralizzato per evitare blocchi Try/Catch duplicati nel codice.

• Tutti i comportamenti imprevisti vengono gestiti all'interno dell'applicazione.

• I messaggi visualizzati agli utenti non perdono dati critici, ma forniscono informazioni sufficienti per spiegare il problema.

• Le eccezioni vengono registrate e forniscono informazioni sufficienti per i team forensi o di risposta agli incidenti da analizzare.

App per la logica di Azure offre un'esperienza di prima classe per la gestione degli errori e delle eccezioni causati dai sistemi dipendenti. È possibile usare App per la logica per creare flussi di lavoro per automatizzare attività e processi che integrano app, dati, sistemi e servizi in aziende e organizzazioni.

Usare la registrazione e gli avvisi

Registrare i problemi di sicurezza per le indagini sulla sicurezza e attivare avvisi relativi ai problemi per assicurarsi che gli utenti sappiano dei problemi in modo tempestivo. Abilitare il controllo e la registrazione su tutti i componenti. I log di audit devono acquisire il contesto utente e identificare tutti gli eventi importanti.

Verificare di non registrare nei log i dati sensibili che un utente invia al sito. Esempi di dati sensibili:

• Credenziali dell'utente
• Numeri di previdenza sociale o altre informazioni di identificazione
• Numeri di carta di credito o altre informazioni finanziarie
• Informazioni sulla salute
• Chiavi private o altri dati che è possibile usare per decrittografare le informazioni crittografate
• Informazioni sul sistema o sull'applicazione che possono essere usate per attaccare l'applicazione in modo più efficace

Assicurarsi che l'applicazione monitori gli eventi di gestione degli utenti, quali gli accessi utente riusciti e non riusciti, le reimpostazioni e le modifiche delle password, il blocco degli account e la registrazione degli utenti. La registrazione di questi eventi consente di rilevare e reagire a comportamenti potenzialmente sospetti. Consente anche di raccogliere dati sulle operazioni, ad esempio chi accede all'applicazione.

Passaggi successivi

Negli articoli seguenti si consigliano controlli di sicurezza e attività che consentono di sviluppare e distribuire applicazioni sicure.

• Sviluppare applicazioni sicure
• Distribuire applicazioni sicure