Condividi tramite

Strategie di architettura 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 Allineare il ciclo di vita di sviluppo sicuro (SDL) durante tutto il ciclo di vita di sviluppo software (SDLC) per garantire la riservatezza, l'integrità e la disponibilità del software e adottare una mentalità orientata alla sicurezza.

Il codice dell'applicazione è il nucleo di ogni carico di lavoro. Incorporare la sicurezza in SDLC integrando i controlli in più fasi di sviluppo. L'obiettivo è assicurarsi che le decisioni di progettazione non introducono lacune di sicurezza evitabili e che le scelte di codice e configurazione non generino vulnerabilità sfruttabili.

Diagramma del ciclo di sicurezza.

Questa guida descrive le procedure consigliate per la sicurezza per proteggere il codice dell'applicazione e prevenire l'implementazione vulnerabile e l'introduzione di componenti compromessi. Estendere le procedure consigliate ai componenti open source e di terze parti per ridurre il rischio della supply chain. L'attenzione non è sul livello dell'infrastruttura.

Le linee guida sono contenute nelle procedure SDL e presuppongono una conoscenza fondamentale dei principi DevSecOps. Si estende oltre il codice dell'applicazione per affrontare la supply chain completa del software, incluse workstation per sviluppatori, repository di origine, sistemi di compilazione e ambienti di distribuzione.

Terminologia

Termine Definition
Vulnerabilità ed esposizioni comuni (CVE) Un database disponibile pubblicamente di vulnerabilità e esposizione di sicurezza note nei prodotti software e hardware.
Difesa approfondita Una strategia di sicurezza che usa più livelli di protezione per proteggere i sistemi, quindi se un livello ha esito negativo, altri continuano a garantire la sicurezza.
DevSecOps Un approccio che integra le procedure di sicurezza nel processo DevOps, enfatizzando la collaborazione tra team di sviluppo, sicurezza e operazioni durante tutto il ciclo di vita del software.
Test di sicurezza delle applicazioni dinamiche (DAST) Test di sicurezza che analizza le applicazioni durante il runtime per identificare le vulnerabilità simulando scenari di attacco reali.
Identità gestita Funzionalità di Azure che fornisce alle applicazioni un'identità gestita automaticamente in Microsoft Entra ID, eliminando la necessità di archiviare le credenziali nel codice.
Esposizione progressiva Strategia di distribuzione che rilascia gradualmente modifiche ai subset di utenti per ridurre al minimo i rischi e contenere potenziali problemi.
Ciclo di vita dello sviluppo della sicurezza (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.
Test di sicurezza delle applicazioni statiche (SAST) Test di sicurezza che analizza il codice sorgente, il bytecode o i file binari senza eseguire il programma per identificare potenziali vulnerabilità.
STRIDE Metodologia di modellazione delle minacce che classifica le minacce in sei tipi: spoofing, manomissione, ripudio, divulgazione di informazioni, denial of service e elevazione dei privilegi.
Sicurezza della catena di approvvigionamento Protezione dell'intera supply chain software, inclusi componenti di terze parti, strumenti di sviluppo e processi da compromissione o manomissione.
Modellazione delle minacce Processo strutturato per l'identificazione, la valutazione e la mitigazione di potenziali minacce alla sicurezza a un sistema all'inizio della fase di progettazione.

Pensa alla sicurezza da un giorno all'altro

Durante le prime discussioni sulla pianificazione e sull'architettura, definire sia i requisiti di sicurezza funzionali che non funzionali insieme agli obiettivi aziendali. Sovrapporre l'architettura ai controlli di sicurezza. Pensa ai confini di isolamento, all'accesso dall'esterno e dall'interno, e ai livelli di sensibilità applicabili ai dati del carico di lavoro. È consigliabile seguire attentamente l'elenco di controllo per la sicurezza per sviluppare la dimensione di sicurezza dell'architettura. Esaminare anche i modelli di progettazione dell'architettura che supportano la sicurezza.

Per mantenere il team responsabile, le considerazioni e i risultati sulla sicurezza devono essere aggiunti direttamente agli elementi di backlog in modo che siano progettati e forniti come parte del prodotto. Si consideri, ad esempio, un'applicazione che supporta flussi utente critici che consentono agli utenti di caricare e modificare i dati. I risultati finali della sicurezza devono affrontare il modo in cui gli utenti interagiscono con il sistema (applicando l'autenticazione avanzata e l'autorizzazione) per garantire che siano consentite solo le azioni consentite.

Gli architetti devono documentare esplicitamente i compromessi di sicurezza e formalizzare l'accettazione dei rischi per garantire trasparenza e responsabilità. Ad esempio, una decisione di sicurezza potrebbe richiedere misure per bloccare le vulnerabilità OWASP in anticipo. Se gli stakeholder scelgono di non finanziarlo, devono riconoscere e accettare il rischio risultante di attacchi a livello di applicazione.

Scegliere le opzioni tecnologico che supportano la sicurezza

Identificare i controlli di sicurezza necessari per ottenere i risultati desiderati e sfruttare le funzionalità native di Azure laddove possibile. Ad esempio, definire una strategia di segmentazione usando limiti di identità, rete e risorse e selezionare web application firewall (WAF), ad esempio Frontdoor di Azure o gateway applicazione di Azure per proteggere l'applicazione. Quando è necessario un WAF in ingresso, usare questi servizi gestiti invece di replicare le funzionalità nel codice dell'applicazione personalizzato.

Le considerazioni tecniche includono anche la selezione di solo framework, librerie e software della supply chain attendibili, originati da provider verificati. I fornitori di terze parti devono soddisfare i requisiti di sicurezza e mantenere un piano di divulgazione responsabile, segnalando tempestivamente eventuali incidenti di sicurezza. Mantenere un elenco di asset approvati e non consentiti e, ove possibile, applicare protezioni nelle pipeline di sviluppo per impedire l'uso di componenti non approvati. Per le dipendenze approvate, l'analisi automatizzata consente di rilevare le vulnerabilità in anticipo e in modo coerente.

Decidere come archiviare i segreti dell'applicazione e le chiavi precondivie in modo sicuro. Non archiviare mai le credenziali o i segreti nel repository del codice sorgente. Usare strumenti esterni, ad esempio Azure Key Vault, in modo che, anche se il codice sorgente è esposto, gli utenti malintenzionati non possono ottenere l'accesso. Se possibile, evitare di usare completamente i segreti, ad esempio sfruttando le identità gestite. Per altre indicazioni, vedere Raccomandazioni per la gestione dei segreti dell'applicazione.

Rendere la modellazione delle minacce una disciplina di progettazione

La modellazione delle minacce consente di identificare le vulnerabilità, valutare le minacce e definire le mitigazioni nelle fasi iniziali della progettazione. Per iniziare, definire l'ambito: impostare limiti di sistema chiari e inventariare gli asset in modo da concentrarsi sugli aspetti più importanti. Raccogliere informazioni dettagliate su ogni componente, inclusi flussi di dati e dipendenze, e analizzarne ognuno dal punto di vista di un utente malintenzionato per determinare come potrebbe essere sfruttato. Adottare una mentalità di presupporre una violazione : pianificare gli errori di controllo e applicare una difesa approfondita per limitare l'impatto.

Usare una metodologia di settore, ad esempio STRIDE , per classificare le minacce e prendere decisioni di mitigazione. Documentare ogni minaccia identificata, i controlli che lo impediscono e il piano di risposta se tali controlli hanno esito negativo. Definire sequenze temporali chiare e proprietà per correggere rapidamente le vulnerabilità in modo che non rimangano non risolte.

Tenere traccia dei risultati della modellazione delle minacce e rivederli in tutto il ciclo di vita del carico di lavoro. Aggiornare il modello man mano che l'architettura evolve per garantire che le nuove funzionalità e le modifiche non introducono rischi non gestiti.

Fare riferimento a: Microsoft Threat Modeling Tool

Creare competenze di codifica sicure

Assicurarsi che il team di sviluppo completi la formazione formale e specifica del ruolo nelle procedure di codifica sicura. Ad esempio, gli sviluppatori di API e Web devono sapere come evitare scripting tra siti (XSS), mentre gli sviluppatori back-end devono comprendere come attenuare i rischi, ad esempio sql injection e altri attacchi a livello di database. Richiedere agli sviluppatori di completare questo training prima di concedere l'accesso al codice sorgente di produzione. Rafforzare queste competenze tramite revisioni interne del codice peer, che promuovono la responsabilità, la condivisione delle conoscenze e il miglioramento continuo.

Usare i test di sicurezza come controllo strategico

Rendere i test di sicurezza una disciplina centrale dell'ingegneria. Stabilire una strategia di test che valuta in modo continuo l'architettura, il codice e il comportamento di runtime durante tutto il ciclo di vita dello sviluppo. Usare una combinazione di analisi dell'architettura, test statici e dinamici, analisi delle dipendenze e protezioni automatizzate.

Usare test di sicurezza delle applicazioni statici (SAST) per rilevare le vulnerabilità nel codice durante la scrittura da parte degli sviluppatori. Completa questa operazione con test di sicurezza delle applicazioni dinamici (DAST) per valutare l'applicazione in esecuzione e simulare scenari di attacco reali.

Integrare l'analisi automatica della sicurezza nei flussi di lavoro di compilazione e integrazione in modo che la sicurezza diventi un controllo qualitativo. Analizza le dipendenze e i componenti di terze parti continuamente e considera le librerie vulnerabili come rischi per la supply chain che richiedono la gestione attiva. Usare linters e analizzatori di codice per impedire ai dati sensibili, come le credenziali, di entrare nel repository del codice sorgente e rafforzare queste protezioni con i controlli della pipeline che rilevano e bloccano l'esposizione delle informazioni sensibili.

Adottare standard di settore per aumentare la fiducia nella resilienza della sicurezza. Per altre informazioni, vedere la sezione Risorse della community di questo articolo.

Scrivere codice sufficiente

Ogni riga di codice aumenta la superficie di attacco. Classificare in ordine di priorità il riutilizzo rispetto alla reinvenzione. Usare framework e librerie ben consolidati che hanno già subito la convalida della sicurezza anziché duplicare le funzionalità nel codice personalizzato.

Adottare una mentalità che prioritizza la piattaforma. Usare i servizi di Azure gestiti e le funzionalità PaaS, quando possibile, per eseguire l'offload di carichi elevati in Azure, ad esempio l'autenticazione, la crittografia, il ridimensionamento e la protezione in ingresso. Meno logica di sicurezza personalizzata che scrivi, minore sarà il rischio a lungo termine.

Quando si scrive codice, l'impostazione predefinita è negata. Progettare la logica di autorizzazione in modo che l'accesso venga bloccato a meno che non sia consentito in modo esplicito. Usare gli elenchi consentiti per entità specifiche, approvate e assicurarsi che le operazioni con privilegi abbiano esito positivo solo quando sono chiaramente autorizzate.

Ambienti per sviluppatori Fortify

L'ambiente di sviluppo fa parte della superficie di vulnerabilità. Proteggere le workstation per sviluppatori con lo stesso rigore dei sistemi di produzione. Ciò significa applicare controlli di identità sicuri, applicare protezioni di rete e mantenere l'applicazione di patch disciplinate. Una workstation compromessa può diventare un percorso diretto nella codebase e nei sistemi di compilazione.

Il repository del codice sorgente è una risorsa critica. Concedere l'accesso con privilegi minimi, solo quando necessario. Stabilire processi di revisione del codice strutturati e incentrati sulla sicurezza con flussi di lavoro di approvazione chiari associati alla motivazione aziendale. La governance avanzata sui repository e sulle pipeline riduce la probabilità di manomissione e limita l'impatto di una violazione.

Inoltre, l'accesso alla rete deve essere segmentato in modo che gli sviluppatori non abbiano accesso diretto ai sistemi di produzione.

Gli strumenti di sviluppo possono anche contribuire a migliorare la sicurezza usando estensioni IDE che monitorano il codice durante la scrittura e l'analisi delle build locali per individuare le vulnerabilità. Le credenziali devono essere protette assicurandosi che i segreti non vengano archiviati nei file di configurazione e usando i gestori delle credenziali quando è necessario l'accesso ai segreti.

Gli sviluppatori devono seguire gli strumenti di sviluppo approvati e usare installazioni gestite centralmente. Gli ambienti di sviluppo, ad esempio GitHub Codespaces e Microsoft Dev Box, possono applicare la sicurezza fornendo aree di lavoro isolate e gestite centralmente.

I test devono essere eseguiti anche in un ambiente controllato con solo le autorizzazioni minime necessarie.

Proteggere le pipeline di compilazione e distribuzione

Le pipeline di build e distribuzione sono bersagli principali. Gli utenti malintenzionati possono manomettere la pipeline, inserire codice dannoso, accedere ai segreti o compromettere gli ambienti downstream.

Considerare gli agenti di compilazione come asset di valore elevato. Hanno accesso privilegiato al codice sorgente e alle pipeline di compilazione, rendendole destinazioni interessanti. Autenticare e autorizzare l'accesso rigorosamente, segmentarli a livello di rete e sottoporli al monitoraggio continuo della sicurezza. Preferisce gli agenti di compilazione ospitati da Microsoft rispetto a quelli self-hosted per ridurre il rischio operativo e limitare la persistenza, poiché forniscono ambienti puliti per ogni esecuzione della pipeline. Agenti personalizzati aumentano il carico gestionale ed espandono la superficie di attacco.

Proteggere le credenziali di compilazione e rimuovere artefatti temporanei per evitare perdite. Se possibile, isolare gli agenti di compilazione limitando l'accesso in ingresso e consentendo solo la comunicazione in uscita controllata.

Per iniziare, mantenere visibilità e controllo chiari. Mantenere un inventario aggiornato di tutti i componenti e le dipendenze integrati e verificare regolarmente che quello che viene eseguito nella pipeline corrisponda a quanto approvato. Usare solo le attività e le estensioni della pipeline da origini attendibili e convalidate, riconoscendo che vengono eseguite con l'accesso con privilegi.

Proteggere le credenziali eliminando i segreti codificati e privilegiando le identità gestite e gli archivi segreti sicuri.Segmentare le fasi della pipeline per ridurre l'esposizione non necessaria delle risorse sensibili e limitare lo spostamento laterale se una fase viene compromessa.

L'isolamento dell'ambiente è altrettanto essenziale. Separare rigorosamente i sistemi di produzione e non di produzione, evitare di usare i dati di produzione in ambienti inferiori senza protezioni equivalenti e impedire la connettività diretta che potrebbe consentire la diffusione di una violazione. Controllare il rischio attraverso l'esposizione progressiva. Le modifiche al rilascio vengono gradualmente apportate usando flag di funzionalità o implementazioni a fasi, in modo che, se si verifica una vulnerabilità, si contenga l'impatto. Progettare le pipeline per supportare distribuzioni regolari e di emergenza. Le correzioni di sicurezza spesso richiedono una risposta rapida, e il processo deve consentire un rapido roll-forward o rollback senza compromettere la stabilità del sistema. Stabilire procedure chiare di comunicazione e approvazione per accelerare i cambiamenti di emergenza in modo responsabile.

Annotazioni

Assegnare sempre priorità alle correzioni di sicurezza per praticità. Ma non compromettere mai la qualità o introdurre regressioni. Se è necessario accelerare una correzione tramite una pipeline di emergenza, valutare quali test automatizzati possono essere ignorati in modo sicuro. Considerare il compromesso tra il valore di ogni test e il relativo tempo di esecuzione. Ad esempio, gli unit test sono veloci e importanti, mentre l'integrazione o i test end-to-end possono richiedere più tempo, ma forniscono comunque una copertura critica. Prendere queste decisioni intenzionalmente per bilanciare la velocità con la fiducia nella correzione.

Proteggere il codice nell'ambiente di produzione

La produzione è l'ultima linea di difesa per la protezione del codice dello sviluppatore prima che raggiunga gli utenti. I team devono mantenere un record dell'immagine d'oro distribuita nell'ambiente di produzione e mantenere un catalogo di tutti gli asset distribuiti e le relative versioni per supportare la risoluzione dei problemi, la risposta agli eventi imprevisti e la gestione delle vulnerabilità. Può anche influenzare i meccanismi di deriva della configurazione. I controlli automatizzati contro le CVE pubblicate consentono di identificare rapidamente componenti obsoleti o rischiosi.

Gli ambienti di sviluppo non devono avere accesso diretto alla produzione. L'accesso deve essere limitato. Inoltre, ruotare regolarmente segreti e certificati ed eseguire esercizi incentrati sulla sicurezza, ad esempio simulazioni tabletop e red-teaming per convalidare le difese.

Proteggere il codice dallo sviluppo alla decomissione

La protezione del codice è una responsabilità costante. SDLC è iterativo e i requisiti si evolvono, quindi le procedure delle fasi precedenti devono continuare a essere applicate e rafforzate nel tempo.

Mantenere aggiornati tutti i componenti software, librerie e infrastruttura con patch di sicurezza tempestive. Valutare e migliorare continuamente i processi incorporando lezioni da revisioni del codice, feedback, indagini sugli eventi imprevisti e minacce emergenti. Integrare tempestivamente le correzioni dei problemi di produzione nel ciclo di vita di sviluppo per evitare la ricorrenza.

Rimuovere le risorse legacy che non sono più in uso per ridurre la superficie di attacco e semplificare la manutenzione. Perfezionare regolarmente le procedure di codifica sicure per rimanere al passo con le minacce in continua evoluzione, assicurandosi che il comportamento di sicurezza rimanga forte e resiliente per tutto il ciclo di vita.

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:

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:

Elenco di controllo per la sicurezza

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per la sicurezza

  • Last updated on