Progettare applicazioni sicure in Azure

Articolo
09/26/2023

In questo articolo vengono presentate le attività di sicurezza e i controlli da considerare 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 è definire le attività e i servizi di Azure che è possibile usare per progettare un'applicazione più sicura.

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 descrivono 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 illustrano 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 possono essere usati, autonomamente o con altre informazioni, per identificare, contattare o individuare una singola persona?
L'applicazione raccoglie o contiene dati che possono essere utilizzati 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 deve avere accesso all'applicazione e per quanto tempo deve 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. L'autorizzazione (AuthZ) è l'atto di concedere a un'entità di sicurezza autenticata l'autorizzazione per eseguire un'operazione. 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 vuole 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 vuole 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 dell'applicazione.
Ridurre la superficie di attacco.
Adottare un criterio 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 l'invio di 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 stringa di connessione e qualsiasi altro elemento considerato un controllo di sicurezza) invece di 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 tecnico di Azure predefiniti.

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 guide introduttive, 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 Azure service App Web (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 funzionalità devOps in App Web, ad esempio la gestione dei pacchetti, gli ambienti di gestione temporanea, i domini personalizzati, i certificati SSL/TLS e la distribuzione continua da Azure DevOps, GitHub, Docker Hub e altre origini.

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 tra questi servizi di Azure, vedere un confronto tra servizi app 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 Open Web Application Security Project (OWASP) (Apri progetto di sicurezza delle applicazioni Web) sull'uso di componenti con vulnerabilità note per i suggerimenti degli strumenti. È anche possibile sottoscrivere avvisi di posta elettronica 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 , manomissione, ripudio, divulgazione di informazioni, denial of service e elevazione dei privilegi in tutti i limiti di attendibilità ha dimostrato un modo efficace per rilevare gli errori di progettazione in anticipo. La tabella seguente elenca le minacce STRIDE e fornisce alcune mitigazioni di esempio che usano le funzionalità fornite da Azure. Queste mitigazioni non funzionano in ogni situazione.

Minaccia	Proprietà di sicurezza	Potenziale mitigazione della piattaforma Azure
Spoofing	Authentication	Richiedere connessioni HTTPS.
Manomissione	Integrità	Convalidare i certificati SSL/TLS. Le applicazioni che usano SSL/TLS devono verificare completamente i certificati X.509 delle entità a cui si connettono. Usare i certificati di Azure Key Vault per gestire i certificati x509.
Ripudio	Non ripudio	Abilitazione del monitoraggio e diagnostica di Azure.
Diffusione di informazioni	Riservatezza	Crittografare i dati sensibili inattivi e in transito.
Denial of Service	Disponibilità	Monitorare le metriche delle prestazioni per individuare potenziali condizioni denial of service. Implementare i filtri di connessione. La protezione DDoS di Azure, combinata con le procedure consigliate per la progettazione delle applicazioni, fornisce la difesa dagli attacchi DDoS.
Elevazione dei privilegi	Autorizzazione	Usare Microsoft Entra ID Privileged Identity Management.

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.
Debug del codice di supporto.
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.

Nota

Qual è la differenza tra la modellazione delle minacce e l'analisi della superficie di attacco? La modellazione delle minacce è il processo di identificazione di potenziali minacce alla sicurezza per l'applicazione e garantisce che siano presenti mitigazioni appropriate contro le minacce. L'analisi della superficie di attacco identifica le aree a rischio elevato di codice che sono aperte all'attacco. Implica la ricerca di modi per difendere le aree ad alto rischio dell'applicazione ed esaminare e testare tali aree di codice prima di distribuire l'applicazione.

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.

Applicare l'autenticazione a più fattori per gli utenti

Usare l'autenticazione a due fattori. L'autenticazione a due fattori è lo standard corrente per l'autenticazione e l'autorizzazione, perché evita i punti deboli di sicurezza intrinseci nei tipi di autenticazione di nome utente e password. L'accesso alle interfacce di gestione di Azure (portale di Azure/Remote PowerShell) e ai servizi rivolti ai clienti deve essere progettato e configurato per l'uso dell'autenticazione a più fattori 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 del settore come OAuth 2.0 e OpenID Connessione.
Azure Active Directory B2C (Azure AD B2C) è un servizio di gestione delle identità usato per personalizzare e controllare il modo in cui i clienti eseguono l'iscrizione, l'accesso e la gestione dei profili quando usano le applicazioni. Sono incluse le applicazioni sviluppate per iOS, Android e .NET, tra le altre. Azure AD B2C abilita queste azioni proteggendo al contempo le identità dei clienti.

Applicare 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 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.

Nota

Le regole dei privilegi minimi devono essere applicate al software e alle persone che creano il software. Gli sviluppatori di software possono essere un rischio enorme per la sicurezza IT se hanno troppo accesso. Le conseguenze possono essere gravi se uno sviluppatore ha finalità dannose o viene concesso troppo accesso. È consigliabile applicare le regole dei privilegi minimi agli sviluppatori per tutto il ciclo di vita di sviluppo.

Implementare l'accesso JUST-In-Time

Implementare l'accesso JIT (Just-In-Time ) 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 stringa di connessione in una soluzione di gestione delle chiavi. È possibile usare una soluzione centralizzata in cui le chiavi e i segreti vengono archiviati nei moduli di protezione hardware . Azure offre un modulo di protezione hardware nel cloud con Azure Key Vault.

Key Vault è un archivio segreto: è 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.

Importante

Azure Key Vault è progettato per archiviare i segreti di configurazione per le applicazioni server. Non è destinato all'archiviazione dei dati appartenenti agli utenti dell'app. Ciò si riflette nelle caratteristiche di prestazioni, nell'API e nel modello di costi.

I dati utente devono essere archiviati altrove, ad esempio in un'istanza di database SQL di Azure con Transparent Data Encryption (TDE) o in un account di archiviazione che usa Archiviazione di Azure Crittografia del servizio. I segreti usati dall'applicazione per accedere a questi archivi dati possono essere conservati in Azure Key Vault.

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 controllo.

Usare la crittografia

La protezione dei dati deve 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 di posta elettronica, 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 di posta elettronica, le password, le stringa 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 deve 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 eventi imprevisti da analizzare.

App per la logica di Azure offre un'esperienza di prima classe per la gestione di errori ed eccezioni causati da 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 controllo devono acquisire il contesto utente e identificare tutti gli eventi importanti.

Verificare di non registrare dati sensibili inviati da un utente 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 possono essere usati 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, ad esempio accessi utente riusciti e non riusciti, reimpostazioni delle password, modifiche della password, blocco dell'account e registrazione utente. 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 è consigliabile usare controlli di sicurezza e attività che consentono di sviluppare e distribuire applicazioni sicure.