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. You can use Visual Studio to manage the code review process.
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. Static code analysis uses techniques like taint checking and data flow analysis.
Azure Marketplace offers developer tools that perform static code analysis and assist with code reviews.
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. An application should validate that data is syntactically and semantically valid before the application uses the data in any way (including displaying it back to the user).
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. Escaping, also known as output encoding, is used to help ensure that untrusted data isn't a vehicle for an injection attack. L'escape, combinato con la convalida dei dati, fornisce difese a più livelli per aumentare la sicurezza del sistema nel suo complesso.
Escaping makes sure that everything is displayed as output. Escaping also lets the interpreter know that the data isn't intended to be executed, and this prevents attacks from working. This is another common attack technique called cross-site scripting (XSS).
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. A masked (anonymized) dataset should be used for all development and testing.
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
If your application allows file uploads, consider precautions that you can take for this risky activity. 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. You can install Microsoft Antimalware or a Microsoft partner's endpoint protection solution (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus in Windows, and Endpoint Protection).
Microsoft Antimalware includes features like real-time protection, scheduled scanning, malware remediation, signature updates, engine updates, samples reporting, and exclusion event collection. È 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. If sensitive information (address, credit card details, Social security number, username) is displayed to the user, the information might be stored in the browser's cache and be retrievable by examining the browser's cache or by pressing the browser's Back button.
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.
Perform DAST, preferably with the assistance of a security professional (a penetration tester or vulnerability assessor). 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. See the OWASP site for a list of web application vulnerability scanners.
Eseguire test con dati casuali
In fuzz testing, you induce program failure by deliberately introducing malformed or random data to an application. 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. You can also search the Azure Marketplace for similar developer tools.
Eseguire test di penetrazione della sicurezza
Assicurarsi che l'applicazione sia sicura sia importante quanto testare qualsiasi altra funzionalità. Make penetration testing a standard part of the build and deployment process. 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.
Next steps
Negli articoli seguenti è consigliabile usare controlli di sicurezza e attività che consentono di progettare e distribuire applicazioni sicure.