Suggerimenti per la protezione di un ciclo di vita di sviluppo
Si applica a questa raccomandazione dell'elenco di controllo per la sicurezza di Azure Well-Architected Framework:
SE:02 | Mantenere un ciclo di vita di sviluppo sicuro usando una catena di approvvigionamento software avanzata, per lo più automatizzata e controllabile. Incorporare una progettazione sicura usando la modellazione delle minacce per proteggersi dalle implementazioni di sicurezza che sconfiggono. |
---|
Guida correlata: Analisi delle minacce
Questa guida descrive le raccomandazioni per la protezione avanzata del codice, dell'ambiente di sviluppo e della supply chain del software applicando le procedure consigliate per la sicurezza durante il ciclo di sviluppo. Per comprendere queste indicazioni, è necessario conoscere DevSecOps.
DevSecOps integra la sicurezza nei processi DevOps tramite:
Automazione dei test e della convalida della sicurezza.
Implementazione di strumenti come le pipeline di sicurezza per analizzare il codice e l'infrastruttura come codice (IaC) per individuare le vulnerabilità.
Al centro di un carico di lavoro è il codice dell'applicazione che implementa la logica di business. Il codice e il processo di sviluppo del codice devono essere privi di difetti di sicurezza per garantire riservatezza, integrità e disponibilità.
Non è sufficiente proteggere solo il piano dell'infrastruttura usando controlli sull'identità e sulla rete e altre misure. Impedire un'implementazione errata del codice o un blocco di codice compromesso per rafforzare il comportamento di sicurezza complessivo. Anche il piano di utilizzo, ovvero il codice dell'applicazione, deve essere sottoposto a protezione avanzata. Il processo di integrazione della sicurezza nel ciclo di vita di sviluppo è essenzialmente un processo di protezione avanzata. Analogamente alla protezione avanzata delle risorse, l'estensione dello sviluppo del codice è anche indipendente dal contesto. L'obiettivo è migliorare la sicurezza e non i requisiti funzionali dell'applicazione. Per informazioni relative alla protezione avanzata, vedere Raccomandazioni per la protezione avanzata delle risorse.
Definizioni
Termine | Definizione |
---|---|
Security Development Lifecycle (SDL) | Set di procedure fornite da Microsoft che supportano i requisiti di sicurezza e conformità. |
Ciclo di vita dello sviluppo software (SDLC) | Un processo multistage e sistematico per lo sviluppo di sistemi software. |
Strategie di progettazione chiave
Le misure di sicurezza devono essere integrate in più punti nel ciclo di vita di sviluppo software (SDLC) esistente per garantire:
Le scelte di progettazione non comportano lacune di sicurezza.
Il codice e la configurazione dell'applicazione non creano vulnerabilità a causa di implementazioni sfruttabili e procedure di codifica non appropriate.
Il software acquisito tramite la supply chain non introduce minacce alla sicurezza.
Il codice dell'applicazione, la compilazione e i processi di distribuzione non vengono manomessi.
Le vulnerabilità rivelate tramite eventi imprevisti vengono attenuate.
Le risorse inutilizzate vengono rimosse correttamente.
I requisiti di conformità non vengono compromessi o ridotti.
La registrazione di controllo viene implementata negli ambienti di sviluppo.
Le sezioni seguenti forniscono strategie di sicurezza per le fasi comunemente praticate di SDLC.
Raccogliere e documentare i requisiti di sicurezza
L'obiettivo della fase dei requisiti è raccogliere e analizzare i requisiti funzionali e non funzionali per un'applicazione o una nuova funzionalità di un'applicazione. Questa fase è importante perché facilita la creazione di protezioni personalizzate in base agli obiettivi dell'applicazione. La protezione dei dati e dell'integrità dell'applicazione deve essere un requisito fondamentale per ogni fase del ciclo di vita di sviluppo.
Si consideri, ad esempio, un'applicazione che deve supportare flussi utente critici che consentono all'utente di caricare e modificare i dati. Le scelte di progettazione della sicurezza devono coprire le garanzie per l'interazione dell'utente con l'applicazione, ad esempio l'autenticazione e l'autorizzazione dell'identità utente, consentendo solo le azioni consentite sui dati e impedendo l'inserimento di SQL. Analogamente, coprire i requisiti non funzionali, ad esempio disponibilità, scalabilità e gestibilità. Le scelte di sicurezza devono includere limiti di segmentazione, ingresso e uscita del firewall e altri problemi di sicurezza trasversali.
Tutte queste decisioni devono portare a una buona definizione del comportamento di sicurezza dell'applicazione. Documentare i requisiti di sicurezza in una specifica concordata e rifletterlo nel backlog. Deve dichiarare in modo esplicito gli investimenti per la sicurezza e i compromessi e i rischi che l'azienda è disposta a intraprendere se gli investimenti non sono approvati dagli stakeholder aziendali. Ad esempio, è possibile documentare la necessità di usare un web application firewall (WAF) davanti all'applicazione, ad esempio Frontdoor di Azure o app Azure lication Gateway. Se gli stakeholder aziendali non sono pronti ad accettare il costo aggiuntivo dell'esecuzione di un WAF, devono accettare il rischio che gli attacchi a livello di applicazione possano essere indirizzati all'applicazione.
La raccolta dei requisiti di sicurezza è una parte fondamentale di questa fase. Senza questo sforzo, le fasi di progettazione e implementazione saranno basate su scelte non dichiarate, che possono causare lacune di sicurezza. Potrebbe essere necessario modificare l'implementazione in un secondo momento in modo da supportare la sicurezza, che può risultare costosa.
Convertire i requisiti di sicurezza in requisiti tecnici
Durante la fase di progettazione, i requisiti di sicurezza vengono convertiti in requisiti tecnici. Nella specifica tecnica documentare tutte le decisioni di progettazione per evitare ambiguità durante l'implementazione. Ecco alcune attività tipiche:
Definire la dimensione di sicurezza dell'architettura di sistema
Sovrapporre l'architettura ai controlli di sicurezza. Ad esempio, i controlli pratici sui limiti di isolamento in base alla strategia di segmentazione, i tipi di identità necessari per i componenti dell'applicazione e il tipo di metodi di crittografia da usare. Per alcune architetture di esempio, vedere le illustrazioni nelle sezioni Esempio della gestione delle identità e degli accessi e della rete.
Valutare gli inviti forniti dalla piattaforma
È importante comprendere la divisione delle responsabilità tra l'utente e il provider di servizi cloud. Evitare sovrapposizioni con i controlli di sicurezza nativi di Azure, ad esempio. Si otterrà una migliore copertura della sicurezza e sarà possibile riallocare le risorse di sviluppo alle esigenze dell'applicazione.
Ad esempio, se le chiamate di progettazione per un web application firewall in ingresso, è possibile scaricare tale responsabilità in un servizio di bilanciamento del carico, ad esempio gateway applicazione o Frontdoor di Azure. Evitare di replicare le funzionalità come codice personalizzato nell'applicazione.
Scegliere solo framework, librerie e software della supply chain attendibili. La progettazione deve anche specificare il controllo della versione sicuro. Le dipendenze dell'applicazione devono essere generate da parti attendibili. I fornitori di terze parti devono essere in grado di soddisfare i requisiti di sicurezza e condividere il piano di divulgazione responsabile. Eventuali eventi imprevisti di sicurezza devono essere segnalati tempestivamente in modo da poter eseguire le azioni necessarie. Inoltre, alcune librerie potrebbero essere vietate dall'organizzazione. Ad esempio, il software potrebbe essere protetto da vulnerabilità, ma comunque non consentito a causa di restrizioni di licenza.
Per assicurarsi che queste linee guida siano seguite da tutti i collaboratori al software, mantenere un elenco di framework, librerie e fornitori approvati e/o non approvati. Quando possibile, posizionare le protezioni nelle pipeline di sviluppo per supportare l'elenco. Il più possibile, automatizzare l'uso degli strumenti per analizzare le dipendenze per individuare le vulnerabilità.
Determinare i modelli di progettazione della sicurezza che il codice dell'applicazione deve implementare.
I modelli possono supportare problemi di sicurezza come la segmentazione e l'isolamento, l'autorizzazione avanzata, la sicurezza uniforme delle applicazioni e i protocolli moderni. Alcuni modelli operativi, ad esempio il modello di quarantena, possono aiutare a verificare e bloccare l'uso del software che potrebbe potenzialmente introdurre vulnerabilità di sicurezza.
Per altre informazioni, vedere Modelli di progettazione cloud che supportano la sicurezza.
Archiviare i segreti dell'applicazione in modo sicuro
Implementare in modo sicuro l'uso dei segreti dell'applicazione e delle chiavi precondivie usate dall'applicazione. Le credenziali e i segreti dell'applicazione non devono mai essere archiviati nell'albero del codice sorgente. Usare risorse esterne come Azure Key Vault per assicurarsi che, se il codice sorgente diventa disponibile per un potenziale utente malintenzionato, non è possibile ottenere altri accessi. In generale, trovare modi per evitare segreti. L'uso delle identità gestite, quando possibile, è un modo per raggiungere tale obiettivo. Per altre informazioni, vedere Raccomandazioni per la gestione dei segreti dell'applicazione.
Definire i piani di test
Definire test case chiari per i requisiti di sicurezza. Valutare se è possibile automatizzare tali test nelle pipeline. Se il team ha processi per i test manuali, includere i requisiti di sicurezza per tali test.
Nota
Eseguire la modellazione delle minacce durante questa fase. La modellazione delle minacce può confermare che le scelte di progettazione sono allineate ai requisiti di sicurezza ed espongono lacune da attenuare. Se il carico di lavoro gestisce dati altamente sensibili, investire in esperti di sicurezza che possono aiutare a condurre la modellazione delle minacce.
L'esercizio iniziale di modellazione delle minacce deve verificarsi durante la fase di progettazione quando viene definita l'architettura del software e la progettazione di alto livello. Questa operazione durante questa fase consente di identificare potenziali problemi di sicurezza prima che vengano incorporati nella struttura del sistema. Tuttavia, questo esercizio non è un'attività monouso. Si tratta di un processo continuo che deve continuare in tutta l'evoluzione del software.
Per altre informazioni, vedere Raccomandazioni per l'analisi delle minacce.
Procedure di sviluppo e test sicure
Durante la fase di sviluppo e test, l'obiettivo è prevenire difetti di sicurezza e manomissioni nel codice, nella compilazione e nelle pipeline di distribuzione.
Essere ben addestrati nelle procedure di codice sicure
Il team di sviluppo deve avere una formazione formale e specializzata in procedure di codifica sicure. Ad esempio, gli sviluppatori di API e Web potrebbero richiedere un training specifico per la protezione dagli attacchi di scripting tra siti e gli sviluppatori back-end possono trarre vantaggio dal training approfondito per evitare attacchi a livello di database come attacchi SQL injection.
Gli sviluppatori devono essere tenuti a completare questo training prima di poter accedere al codice sorgente di produzione.
È anche consigliabile eseguire revisioni interne del codice peer per promuovere l'apprendimento continuo.
Usare gli strumenti di test di sicurezza
Eseguire la modellazione delle minacce per valutare la sicurezza dell'architettura dell'applicazione.
Usare test di sicurezza delle applicazioni statici (SAST) per analizzare il codice per individuare le vulnerabilità. Integrare questa metodologia nell'ambiente di sviluppo per rilevare le vulnerabilità in tempo reale.
Usare test di sicurezza delle applicazioni dinamici (DAST) durante il runtime. Questa catena di strumenti può verificare la presenza di errori nei domini di sicurezza e simulare un set di attacchi per testare la resilienza della sicurezza dell'applicazione. Quando possibile, integrare questo strumento nelle pipeline di compilazione.
Seguire gli standard di settore per procedure di codifica sicure. Per altre informazioni, vedere la sezione Risorse della community di questo articolo.
Usare gli analizzatori di codice e linters per impedire il push delle credenziali nel repository del codice sorgente. Ad esempio, gli analizzatori .NET Compiler Platform (Roslyn) controllano il codice dell'applicazione.
Durante il processo di compilazione, usare i componenti aggiuntivi della pipeline per intercettare le credenziali nel codice sorgente. Analizzare tutte le dipendenze, ad esempio librerie di terze parti e componenti del framework, come parte del processo di integrazione continua. Analizzare i componenti vulnerabili contrassegnati dallo strumento. Combinare questa attività con altre attività di analisi del codice che controllano la varianza del codice, i risultati dei test e il code coverage.
Usare una combinazione di test. Per informazioni sui test di sicurezza in generale, vedere Raccomandazioni per i test di sicurezza.
Scrivere codice sufficiente
Quando si riduce il footprint del codice, si riducono anche le probabilità di difetti di sicurezza. Riutilizzare codice e librerie già in uso e che sono state eseguite tramite convalide di sicurezza anziché duplicare il codice.
Sfruttare le funzionalità di Azure è un altro modo per evitare codice non necessario. Un modo consiste nell'usare i servizi gestiti. Per maggiori informazioni, vedere Usare opzioni platform as a service (PaaS).
Scrivere codice con un approccio deny-all per impostazione predefinita. Creare elenchi consentiti solo per le entità che richiedono l'accesso. Ad esempio, se si dispone di codice che deve determinare se un'operazione con privilegi deve essere consentita, è necessario scriverla in modo che il risultato di negazione sia il caso predefinito e il risultato di autorizzazione si verifica solo quando è consentito in modo specifico dal codice.
Proteggere gli ambienti di sviluppo
Le workstation per sviluppatori devono essere protette con controlli di rete e identità sicuri per evitare l'esposizione. Assicurarsi che gli aggiornamenti della sicurezza vengano applicati in modo diligente.
Gli agenti di compilazione hanno privilegi elevati e hanno accesso al server di compilazione e al codice. Devono essere protetti con lo stesso rigore dei componenti del carico di lavoro. Ciò significa che l'accesso agli agenti di compilazione deve essere autenticato e autorizzato, deve essere segmentato dalla rete con controlli firewall, deve essere soggetto all'analisi delle vulnerabilità e così via. Gli agenti di compilazione ospitati da Microsoft devono essere preferiti rispetto agli agenti di compilazione self-hosted. Gli agenti ospitati da Microsoft offrono vantaggi come le macchine virtuali pulite per ogni esecuzione di una pipeline.
Gli agenti di compilazione personalizzati aggiungono complessità di gestione e possono diventare un vettore di attacco. Le credenziali del computer di compilazione devono essere archiviate in modo sicuro ed è necessario rimuovere regolarmente tutti gli artefatti di compilazione temporanei dal file system. È possibile ottenere l'isolamento della rete consentendo solo il traffico in uscita dall'agente di compilazione, perché usa il modello pull di comunicazione con Azure DevOps.
È necessario proteggere anche il repository del codice sorgente. Concedere l'accesso ai repository di codice in base alla necessità e ridurre il più possibile l'esposizione delle vulnerabilità per evitare attacchi. Eseguire un processo completo per esaminare il codice per individuare le vulnerabilità di sicurezza. Usare i gruppi di sicurezza a tale scopo e implementare un processo di approvazione basato sulle motivazioni aziendali.
Proteggere il codice nelle pipeline di distribuzione
Non è sufficiente proteggere il codice. Se viene eseguito in pipeline sfruttabili, tutte le attività di sicurezza sono inutili e incomplete. Gli ambienti di compilazione e rilascio devono essere protetti anche perché si vuole impedire agli attori malintenzionati di eseguire codice dannoso nella pipeline.
Gestire un inventario aggiornato di ogni componente integrato nell'applicazione
Ogni nuovo componente integrato in un'applicazione aumenta la superficie di attacco. Per garantire la responsabilità e l'invio di avvisi appropriati quando vengono aggiunti o aggiornati nuovi componenti, è necessario disporre di un inventario di questi componenti. Archiviarlo all'esterno dell'ambiente di compilazione. A intervalli regolari, verificare che il manifesto corrisponda a ciò che si trova nel processo di compilazione. In questo modo si garantisce che non vengano aggiunti in modo imprevisto nuovi componenti che contengono backdoor o altri malware.
Attività della pipeline
Eseguire il pull delle attività nella pipeline da origini attendibili, ad esempio Azure Marketplace. Eseguire attività scritte dal fornitore della pipeline. È consigliabile eseguire attività di GitHub o GitHub Actions. Se si usano flussi di lavoro GitHub, preferire le attività create da Microsoft. Convalidare anche le attività perché vengono eseguite nel contesto di sicurezza della pipeline.
Segreti della pipeline. Gli asset di distribuzione eseguiti all'interno di una pipeline hanno accesso a tutti i segreti in tale pipeline. Disporre di una segmentazione appropriata per diverse fasi della pipeline per evitare l'esposizione non necessaria. Usare gli archivi segreti incorporati nella pipeline. Tenere presente che è possibile evitare di usare i segreti in alcune situazioni. Esplorare l'uso delle identità del carico di lavoro (per l'autenticazione della pipeline) e delle identità gestite (per l'autenticazione da servizio a servizio).
Mantenere separati ambienti diversi
I dati usati in ambienti diversi devono essere mantenuti separati. I dati di produzione non devono essere usati in ambienti inferiori perché questi ambienti potrebbero non avere i controlli di sicurezza rigorosi di cui dispone la produzione. Evitare di connettersi da un'applicazione non di produzione a un database di produzione ed evitare di connettere componenti non di produzione alle reti di produzione.
Esposizione progressiva
Usare l'esposizione progressiva per rilasciare le funzionalità in un subset di utenti in base ai criteri scelti. In caso di problemi, l'impatto viene ridotto a icona a tali utenti. Questo approccio è una strategia di mitigazione dei rischi comune perché riduce la superficie di attacco. Man mano che la funzionalità si matura e si ha maggiore fiducia nelle garanzie di sicurezza, è possibile rilasciarla gradualmente a un set più ampio di utenti.
Proteggere il codice nell'ambiente di produzione
La fase di produzione presenta l'ultima opportunità responsabile di correggere i gap di sicurezza. Mantenere un record dell'immagine d'oro rilasciata nell'ambiente di produzione.
Mantenere gli artefatti con controllo delle versioni
Mantenere un catalogo di tutti gli asset distribuiti e le relative versioni. Queste informazioni sono utili durante la valutazione degli eventi imprevisti, quando si attenuano i problemi e quando si ripristina lo stato di funzionamento del sistema. Gli asset con controllo delle versioni possono anche essere confrontati con gli avvisi CVE (Common Vulnerabilities and Exposures) pubblicati. È consigliabile usare l'automazione per eseguire questi confronti.
Correzioni di emergenza
La progettazione automatizzata della pipeline deve avere la flessibilità necessaria per supportare distribuzioni regolari e di emergenza. Questa flessibilità è importante per supportare correzioni di sicurezza rapide e responsabili.
Una versione è in genere associata a più controlli di approvazione. Prendere in considerazione la creazione di un processo di emergenza per accelerare le correzioni di sicurezza. Il processo potrebbe comportare la comunicazione tra i team. La pipeline deve consentire distribuzioni rapide di rollforward e rollback che consentono correzioni di sicurezza, bug critici e aggiornamenti del codice che si verificano al di fuori del normale ciclo di vita della distribuzione.
Nota
Assegnare sempre priorità alle correzioni di sicurezza per praticità. Una correzione di sicurezza non deve introdurre una regressione o un bug. Se si vuole accelerare la correzione tramite una pipeline di emergenza, valutare attentamente quali test automatizzati possono essere ignorati. Valutare il valore di ogni test rispetto al tempo di esecuzione. Ad esempio, gli unit test vengono in genere completati rapidamente. I test end-to-end o di integrazione possono essere eseguiti per molto tempo.
Mantenere la sicurezza del codice per tutto il ciclo di vita
L'obiettivo di questa fase è assicurarsi che il comportamento di sicurezza non decadi nel tempo. SDLC è un processo agile in corso. I concetti trattati nelle fasi precedenti si applicano a questa fase perché i requisiti cambiano nel tempo.
Gestione delle patch. Mantenere aggiornati software, librerie e componenti dell'infrastruttura con patch e aggiornamenti di sicurezza.
Miglioramento continuo. Valutare e migliorare continuamente la sicurezza del processo di sviluppo software tenendo conto di revisioni del codice, feedback, lezioni apprese e minacce in continua evoluzione.
Rimuovere le autorizzazioni degli asset legacy non aggiornati o non più in uso. In questo modo si riduce la superficie di attacco dell'applicazione.
La manutenzione include anche correzioni degli eventi imprevisti. Se i problemi vengono rilevati nell'ambiente di produzione, devono essere immediatamente integrati nel processo in modo che non si verifichino di nuovo.
Migliorare continuamente le procedure di codifica sicure per tenere il passo con il panorama delle minacce.
Facilitazione di Azure
Microsoft Security Development Lifecycle (SDL) consiglia procedure sicure che è possibile applicare al ciclo di vita di sviluppo. Per altre informazioni, vedere Ciclo di vita dello sviluppo della sicurezza Microsoft.
Defender per DevOps e gli strumenti SAST sono inclusi come parte di GitHub Advanced Security o Azure DevOps. Questi strumenti consentono di tenere traccia di un punteggio di sicurezza per l'organizzazione.
Seguire le raccomandazioni sulla sicurezza di Azure descritte in queste risorse:
Collegamenti della community
Per trovare le credenziali nel codice sorgente, è consigliabile usare strumenti come GitHub Advanced Security e strumenti di analisi del codice sorgente OWASP.
Convalidare la sicurezza di qualsiasi codice open source nell'applicazione. Questi strumenti e risorse gratuiti possono essere utili per la valutazione:
- Bullone mend
- npm-audit
- Verifica delle dipendenze OWASP
- GitHub Dependabot
- Estensione Microsoft Security DevOps di Azure DevOps
- Procedure di codifica sicura OWASP
- OWASP Top Ten
Collegamenti correlati
- Modelli di progettazione cloud che supportano la sicurezza
- Progettare applicazioni sicure in Azure
- Distribuire applicazioni sicure in Azure
- Sviluppare applicazioni sicure in Azure
- Microsoft Security Development Lifecycle
- Raccomandazioni per la creazione di una strategia di segmentazione
- Raccomandazioni per la protezione avanzata delle risorse
- Raccomandazioni per la gestione dei segreti dell'applicazione
- Raccomandazioni per i test di sicurezza
- Raccomandazioni per l'analisi delle minacce
- Procedure consigliate per lo sviluppo sicuro in Azure
- Formazione: Informazioni su come Microsoft supporta lo sviluppo di software sicuro come parte di una soluzione di cybersecurity
- Usare le opzioni della piattaforma distribuita come servizio (PaaS)
Elenco di controllo relativo alla sicurezza
Fare riferimento al set completo di raccomandazioni.