Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In questo articolo vengono presentate attività di sicurezza e controlli da considerare quando si sviluppano applicazioni per il cloud. Le domande e i concetti di sicurezza da considerare durante le fasi di implementazione e verifica del ciclo di vita di sviluppo della sicurezza Microsoft (SDL) sono trattati. L'obiettivo è quello di definire attività e servizi di Azure che è possibile usare per sviluppare un'applicazione più sicura.
Le fasi SDL seguenti sono descritte in questo articolo:
- Implementation
- Verification
Implementation
L'obiettivo della fase di implementazione è stabilire le procedure consigliate per la prevenzione anticipata e per rilevare e rimuovere i problemi di sicurezza dal codice. Si supponga che l'applicazione venga usata nei modi in cui non si intende usarla. Ciò consente di evitare un uso improprio accidentale o intenzionale dell'applicazione.
Eseguire revisioni del codice
Prima di archiviare il codice, eseguire revisioni del codice per aumentare la qualità complessiva del codice e ridurre il rischio di creazione di bug. È possibile usare Visual Studio per gestire il processo di revisione del codice.
Eseguire l'analisi statica del codice
L'analisi statica del codice (nota anche come analisi del codice sorgente) viene eseguita come parte di una revisione del codice. L'analisi statica del codice si riferisce in genere all'esecuzione di strumenti di analisi del codice statico per individuare potenziali vulnerabilità nel codice non in esecuzione. L'analisi statica del codice usa tecniche come il controllo taint e l'analisi del flusso di dati.
Azure Marketplace offre strumenti di sviluppo che eseguono l'analisi statica del codice e supportano le revisioni del codice.
Convalidare e purificare ogni input per l'applicazione
Considerare tutti gli input come non attendibili per proteggere l'applicazione dalle vulnerabilità più comuni dell'applicazione Web. I dati non attendibili sono un veicolo per attacchi di iniezione. L'input per l'applicazione include i parametri nell'URL, l'input dell'utente, i dati del database o da un'API e qualsiasi elemento passato che un utente potrebbe potenzialmente modificare. Un'applicazione deve verificare che i dati siano sintatticamente e semanticamente validi prima che l'applicazione usi i dati in qualsiasi modo (inclusa la visualizzazione all'utente).
Convalidare l'input all'inizio del flusso di dati per assicurarsi che solo i dati correttamente formati entrino nel flusso di lavoro. Non si desidera mantenere dati malformati nel database o causare un malfunzionamento in un componente a valle.
L'elenco di elementi bloccati e l'elenco di elementi consentiti sono due approcci generali per l'esecuzione della convalida della sintassi di input:
L'elenco di elementi bloccati tenta di verificare che un input utente specificato non contenga contenuto "noto come dannoso".
Allowlisting tenta di verificare che un determinato input utente corrisponda a un set di input "noti validi". L'elenco di elementi consentiti basato su caratteri è una forma di elenco di elementi consentiti in cui un'applicazione verifica che l'input dell'utente contenga solo caratteri validi noti o che l'input corrisponda a un formato noto.
Ad esempio, questo potrebbe comportare la verifica che un nome utente contenga solo caratteri alfanumerici o che contenga esattamente due numeri.
Allowlisting è l'approccio preferito per la creazione di software sicuro. L'inserimento nella blacklist è soggetto a errori perché è impossibile concepire un elenco completo di input potenzialmente dannosi.
Eseguire questa operazione sul server, non sul lato client (o sul server e sul lato client).
Verificare gli output dell'applicazione
Qualsiasi output presentato in modo visivo o all'interno di un documento deve essere sempre codificato e preceduto da un carattere di escape. L'escape, noto anche come codifica di output, viene usato per garantire che i dati non attendibili non siano un veicolo per un attacco injection. L'escape, combinato con la convalida dei dati, fornisce difese a più livelli per aumentare la sicurezza del sistema nel suo complesso.
L'escape assicura che tutti gli elementi siano visualizzati come output. L'escape consente anche all'interprete di sapere che i dati non devono essere eseguiti e questo impedisce il funzionamento degli attacchi. Si tratta di un'altra tecnica di attacco comune denominata xss (cross-site scripting ).
Se si usa un framework Web di terze parti, è possibile verificare le opzioni per la codifica di output nei siti Web usando il foglio informativo sulla prevenzione XSS OWASP.
Usate query con parametri quando contattate il database
Non creare mai una query di database inline "in tempo reale" nel codice e inviarla direttamente al database. Il codice dannoso inserito nell'applicazione potrebbe causare il furto, la cancellazione o la modifica del database. L'applicazione può essere usata anche per eseguire comandi dannosi del sistema operativo nel sistema operativo che ospita il database.
Invece, usare query con parametri o procedure memorizzate. Quando si usano query con parametri, è possibile richiamare la routine dal codice in modo sicuro e passarla una stringa senza preoccuparsi che venga considerata come parte dell'istruzione di query.
Rimuovi intestazioni server standard
Le intestazioni come Server, X-Powered-By e X-AspNet-Version rivelano informazioni sul server e sulle tecnologie sottostanti. È consigliabile eliminare queste intestazioni per evitare l'impronta digitale dell'applicazione. Vedere Rimozione di intestazioni server standard nei siti Web di Azure.
Separare i dati di produzione
I dati di produzione o i dati "reali" non devono essere usati per lo sviluppo, il test o qualsiasi altro scopo rispetto a quello previsto dall'azienda. È consigliabile usare un set di dati mascherato (anonimizzato) per tutti gli sviluppi e i test.
Ciò significa che un numero inferiore di persone ha accesso ai dati reali, riducendo così la superficie di attacco. Significa anche un minor numero di dipendenti che vedono i dati personali, eliminando una potenziale violazione della riservatezza.
Implementare una politica di password robuste
Per difendersi da un'ipotesi basata su forza bruta e dizionario, è necessario implementare criteri password complessi per garantire che gli utenti creino una password complessa (ad esempio, una lunghezza minima di 12 caratteri e che richieda caratteri alfanumerici e speciali).
Microsoft Entra External ID nei tenant esterni consente di gestire la password offrendo la reimpostazione della password self-service e altro ancora.
Per difendersi dagli attacchi agli account predefiniti, verificare che tutte le chiavi e le password siano sostituibili e che vengano generate o sostituite dopo l'installazione delle risorse.
Se l'applicazione deve generare automaticamente le password, assicurarsi che le password generate siano casuali e che abbiano un'entropia elevata.
Convalidare i caricamenti dei file
Se l'applicazione consente caricamenti di file, prendere in considerazione le precauzioni che è possibile adottare per questa attività rischiosa. Il primo passaggio in molti attacchi è quello di ottenere codice dannoso in un sistema sotto attacco. L'uso di un caricamento di file consente all'utente malintenzionato di eseguire questa operazione. OWASP offre soluzioni per la convalida di un file per assicurarsi che il file che si sta caricando sia sicuro.
La protezione antimalware consente di identificare e rimuovere virus, spyware e altro software dannoso. È possibile installare Microsoft Antimalware o una soluzione di endpoint protection del partner Microsoft (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus in Windows e Endpoint Protection).
Microsoft Antimalware include funzionalità come la protezione in tempo reale, l'analisi pianificata, la correzione del malware, gli aggiornamenti delle firme, gli aggiornamenti del motore, la creazione di report di esempi e la raccolta di eventi di esclusione. È possibile integrare Microsoft Antimalware e soluzioni partner con Microsoft Defender per il cloud per facilitare la distribuzione e i rilevamenti predefiniti (avvisi ed eventi imprevisti).
Non memorizzare nella cache il contenuto sensibile
Non memorizzare nella cache il contenuto sensibile nel browser. I browser possono archiviare informazioni per la memorizzazione nella cache e la cronologia. I file memorizzati nella cache vengono archiviati in una cartella come la cartella File Internet temporanei, nel caso di Internet Explorer. Quando si fa di nuovo riferimento a queste pagine, il browser visualizza le pagine dalla cache. Se all'utente vengono visualizzate informazioni riservate (indirizzo, dettagli della carta di credito, numero di previdenza sociale, nome utente), le informazioni potrebbero essere archiviate nella cache del browser e recuperabili esaminando la cache del browser o premendo il pulsante Indietro del browser.
Verification
La fase di verifica prevede un impegno completo per garantire che il codice soddisfi i set di sicurezza e privacy stabiliti nelle fasi precedenti.
Individuare e correggere le vulnerabilità nelle dipendenze dell'applicazione
È possibile analizzare l'applicazione e le relative librerie dipendenti per identificare eventuali componenti vulnerabili noti. I prodotti disponibili per eseguire questa analisi includono Controllo dipendenze OWASP, Snyk e Black Duck.
Testare l'applicazione in uno stato operativo
Il test di sicurezza delle applicazioni dinamiche (DAST) è un processo di test di un'applicazione in uno stato operativo per individuare le vulnerabilità di sicurezza. Gli strumenti DAST analizzano i programmi durante l'esecuzione per individuare vulnerabilità di sicurezza, ad esempio danneggiamento della memoria, configurazione server non sicura, scripting tra siti, problemi relativi ai privilegi utente, inserimento SQL e altri problemi di sicurezza critici.
DAST è diverso da quello dei test di sicurezza delle applicazioni statici (SAST). Gli strumenti SAST analizzano il codice sorgente o le versioni compilate del codice quando il codice non è in esecuzione per individuare i difetti di sicurezza.
Eseguire DAST, preferibilmente con l'assistenza di un professionista della sicurezza (un tester di penetrazione o un valutatore di vulnerabilità). Se un professionista della sicurezza non è disponibile, è possibile eseguire manualmente DAST con uno scanner proxy Web e alcuni training. Collegare uno scanner DAST all'inizio per assicurarsi di non introdurre problemi di sicurezza evidenti nel codice. Per un elenco degli scanner di vulnerabilità delle applicazioni Web, vedere il sito OWASP .
Eseguire test con dati casuali
Nei test fuzz si provoca un errore del programma introducendo deliberatamente dati in formato non valido o casuali in un'applicazione. L'induzione dell'errore del programma consente di rivelare potenziali problemi di sicurezza prima del rilascio dell'applicazione.
Il rilevamento dei rischi per la sicurezza è il servizio di test fuzz univoco di Microsoft per trovare bug critici per la sicurezza nel software.
Eseguire la verifica della superficie di attacco
La revisione della superficie di attacco dopo il completamento del codice consente di assicurarsi che siano state prese in considerazione tutte le modifiche di progettazione o implementazione a un'applicazione o a un sistema. Consente di garantire che tutti i nuovi vettori di attacco creati in seguito alle modifiche, inclusi i modelli di minaccia, siano stati esaminati e mitigati.
È possibile creare un'immagine della superficie di attacco analizzando l'applicazione. Microsoft offre uno strumento di analisi della superficie di attacco denominato Attack Surface Analyzer. È possibile scegliere tra molti strumenti o servizi commerciali di analisi dinamica delle vulnerabilità, tra cui OWASP Attack Surface Detector, Arachni e w3af. Questi strumenti di analisi eseguono l'indicizzazione dell'applicazione e mappano le parti dell'applicazione accessibili sul Web. È anche possibile cercare strumenti di sviluppo simili in Azure Marketplace.
Eseguire test di penetrazione della sicurezza
Assicurarsi che l'applicazione sia sicura sia importante quanto testare qualsiasi altra funzionalità. Eseguire test di penetrazione come parte standard 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.
Eseguire test di verifica della sicurezza
La soluzione Azure Tenant Security Solution (AzTS) del Secure DevOps Kit per Azure (AzSK) contiene SVTs per diversi servizi della piattaforma Azure. Questi file SVT vengono eseguiti periodicamente per assicurarsi che la sottoscrizione di Azure e le diverse risorse che costituiscono l'applicazione siano in uno stato sicuro. È anche possibile automatizzare questi test usando la funzionalità di integrazione continua/distribuzione continua (CI/CD) di AzSK, che rende disponibili i file SVT come estensione di Visual Studio.
Passaggi successivi
Negli articoli seguenti è consigliabile usare controlli di sicurezza e attività che consentono di progettare e distribuire applicazioni sicure.